16:05:18 #startmeeting docinstallteam 16:05:18 Meeting started Tue Feb 9 16:05:18 2016 UTC and is due to finish in 60 minutes. The chair is Sam-I-Am. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:05:20 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:05:22 The meeting name has been set to 'docinstallteam' 16:05:32 It's important to me that we get a manila install guide into Mitaka 16:05:46 we'll talk about it in a bit 16:06:05 #topic updates for mitaka 16:06:35 the spec hasn't been approved yet. please review if you get a chance. 16:06:38 #link https://review.openstack.org/#/c/274231/ 16:06:48 keep in mind that it only covers updates for existing services 16:07:31 #topic testing mitaka 16:07:59 looks like ubuntu has milestone 1 packages out in the cloud-archive ppa. not terribly useful yet. i'd wait until at least milestone 3. 16:08:20 rdo packages from trunk, so those are up for testing anytime and probably getting close to milestone 3 16:08:36 i havent looked at suse 16:08:56 #topic new services for mitaka 16:09:13 this would be you, bswartz 16:09:20 okay 16:09:22 i see a blueprint, but not a spec 16:09:52 yes there is a BP and a proposed change 16:09:59 #link https://blueprints.launchpad.net/openstack-manuals/+spec/create-manila-install-guide 16:10:04 #link https://review.openstack.org/#/c/273724/ 16:10:08 i found those 16:10:17 both of these occured without my knowledge 16:10:33 I'm not sure who Denis Cavalcante is 16:10:48 but I want to help ensure this lands 16:10:59 so I'm asking what do I need to do? 16:11:07 what deadlines exist for this change? 16:11:32 generally speaking, we need everything for mitaka tested prior to release 16:11:38 if a spec is needed, what should it look like? (I haven't read any documentation specs before) 16:11:41 this includes existing and new services 16:12:16 the spec just says you want to add a service, explains any required architectural changes, limitations, etc. 16:12:38 for example, if manila requires that we add/change the install guide architecture, its a bigger deal than a service that just works 16:13:00 yes I don't believe we should require any large changes like that 16:13:14 manila very much fits in the mold of cinder 16:13:24 this patch contains a 'share node' 16:13:32 which it piggybacks on the compute node, which we can't do 16:13:45 unless the reference architecture for manila deploys share nodes on compute nodes 16:13:56 where do you see that? 16:14:03 https://review.openstack.org/#/c/273724/2/doc/install-guide/source/manila-share-install.rst 16:14:07 this is why we have specs... 16:14:26 so this stuff gets discussed before someone goes through the effort of writing the patch 16:14:34 yeah, as I said this whole thing was a surprise to me 16:14:54 i've heard on and off about it, but thought i'd see a spec before a patch 16:14:58 the bp isnt approved either 16:15:16 the content is here, so i'm not going to -2 it, but we'll need to address the problems 16:15:28 I entered the Mitaka release believing that any install guide documentation would need to be somewhere other than the "official" install guide, due to an email thread where loquacities basically said that 16:15:48 i think i was around for that thread 16:16:18 I prefer the approach dencaval seems to be taking 16:16:24 but I haven't yet spoken to him 16:16:32 so I guess I need to sync up with him first 16:16:42 and help him address these issues or work on them myself 16:17:08 to answer your earlier question about the "share node" 16:17:23 I think he's just referring to the node on which the services are installed 16:17:25 the qualifications for something going into the official install guide are generally these - a) does it work on a minimal amount of hw? b) do all distros package it? c) can we fully test it prior to release? 16:17:31 it would be no different than cinder 16:17:50 we do have a cinder storage node, so maybe we can re-use that for the share node? 16:17:59 yes I think so 16:18:10 thats something to consider 16:18:31 what does the install guide test procedure look like? 16:18:33 usually the big hold up for new services is all distros including packages, followed by sufficient testing on all of them 16:18:47 some reads the doc and manually performs all the operations? 16:18:55 follow the guide to the point where you can install/use your service, try the instructions for your service. 16:18:57 /some/someone/ 16:18:58 yeah 16:18:59 its all manual 16:19:06 because thats what our audience does 16:19:13 of course 16:19:43 so my guess is manila becomes an optional service that references the cinder storage node bits, or something 16:19:50 okay well my next step will be to sync up with dencaval 16:19:55 yep 16:20:14 a spec would be nice for tracking purposes 16:20:25 can you link the repo for that spec? 16:21:01 #link http://specs.openstack.org/openstack/docs-specs/ 16:21:02 and 16:21:18 #link https://github.com/openstack/docs-specs 16:21:26 thanks 16:22:04 i can help with that too 16:22:12 you can take a look at some of the existing install guide spec in there 16:22:25 yes that's what I'm doing 16:23:12 I'll find out from dencaval how much help he needs and I'm happy to write the spec if it would help (even though it's a backwards process) 16:23:54 that's all I had 16:23:57 usually its not backwards :) 16:24:17 yes i mean backwards in this case 16:24:26 spec should have come first 16:24:37 yeah. i'm not going to hold this patch up because of the spec. 16:24:47 i'd just like it there for tracking and historical purposes 16:25:57 okay anything else I should know about? 16:26:13 what is the deadline for the change to merge? 16:26:49 well, we can test the patch before the majority of it merges 16:26:57 then tweak later as newer versions of packages come out 16:27:16 so i'd say we want the main patch to merge between milestone 3 and rc 1 16:27:27 k 16:27:30 which implies it can be tested on ubuntu, rh, and suse 16:27:54 and you'd do testing with m-3 versions of the packages? 16:28:12 thats where i like to start because its feature freeze 16:28:12 or earlier versions work just as well? 16:28:16 things mostly work by then 16:28:17 k 16:28:25 depends on how involved you are with the project 16:28:34 if you think m1 or m2 works sufficiently, then use it 16:29:06 well I'm the PTL for Manila, but not directly involved with packaging or docs 16:29:15 so I'll have to ping some people 16:29:28 we track testing here - https://wiki.openstack.org/wiki/MitakaDocTesting 16:29:44 we'll need to add row for manila 16:29:47 broken link? 16:30:04 there's nothing on that page 16:30:05 wat 16:30:10 i submitted that last week 16:30:11 sigh 16:30:13 i hate wikis 16:30:33 https://wiki.openstack.org/wiki/Documentation/MitakaDocTesting 16:30:43 better! 16:31:30 okay thanks 16:32:20 yeah, so thats how we track stuff 16:32:39 it should be all green within 1-2 weeks after all distros release final packages 16:32:48 which is sometimes a couple of weeks after actual release 16:33:05 so we don't end up freezing the guide until maybe a month or so after release to facilitate updates without backports 16:33:13 I see 16:34:41 yep 16:34:49 anything else for manila? 16:35:09 nope 16:35:14 cool 16:35:18 glad we could chat 16:35:29 yes thank you 16:35:42 guess we can call the meeting since no one else is here 16:35:53 alright 16:36:02 thanks 16:36:04 it's lunch time here anyways 16:36:07 #endmeeting