17:00:55 #startmeeting training-manuals 17:00:56 Meeting started Mon Jun 23 17:00:55 2014 UTC and is due to finish in 60 minutes. The chair is sarob. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:58 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:00 The meeting name has been set to 'training_manuals' 17:01:07 Roll call 17:01:15 hi 17:01:18 hey 17:01:19 guys 17:01:24 hi all :) greet from jakarta 17:01:30 Evening 17:01:35 hi all 17:01:43 Helloooo 17:01:54 Let's start 17:02:15 I want to spend half the meeting on 17:02:43 Current stable, testing, infra 17:02:58 Then last half on developer guide design 17:03:10 +1 17:03:22 #topic stable team 17:03:54 current focus is on install guide 17:04:11 also fixing a few things from Associate and Operator guides 17:04:31 to have better collaboration we had a meeting with Comcast guys over hangouts 17:04:58 Etherpad Link for Install Guides : https://etherpad.openstack.org/p/training-guides-install-guide 17:05:05 I need to port my notes here 17:05:51 I am planning to use Etherpad for keeping various information about install guides 17:06:10 which sections to break from openstack-manuals and how to assemble them 17:06:19 so we could also use this to show it to guys who maintain install guides 17:06:35 Sounds good 17:06:35 any suggestions? 17:07:16 any idea to break from os-manual, but keep linked? 17:07:28 I'd reach out to Sam-I-am and others active on the install guides 17:07:30 so we can know, this content from which chapter and section 17:07:56 sarob: I plan to do that as soon as we are prepared with the changes to install guide on manuals 17:08:02 fthamura: we are already doing that, it is possible 17:08:11 he, sorry I'm late 17:08:15 will catch up next 17:08:26 Annegent_ no prob 17:09:13 i can see training manual have pattern, can we make template for all modules, apt-get, setting .conf, keystone create, load content, list, restart. ? 17:09:42 and this pattern linked to openstack-manual, and we can have like matrix installation 17:09:44 i am working on that 17:09:51 fthamura: that's pretty much the install pattern isn't it? 17:09:53 fthamura: we will keep skeleton/basic framework and reuse the actual content from install guides from openstack-manuals 17:10:02 fthamura: the goal is to not replicate 17:10:13 fthamura: the distro switch and the content will be re-used 17:10:20 we dont need to do the same thing again 17:10:25 annegent_: this pattern help student to learn, and how easy install openstack 17:10:31 dguitarbite: right!! :) 17:10:34 fthamura: the install guide already does that 17:10:59 fthamura: our goal with the install guide matches learning and easy installation, the training project will enhance it for a training lab setting 17:11:19 annegent_: yup, already, and find nova db sync vs keystone db_sync / glance db_sync -> i think must submit bugs because different way of sync 17:11:43 fthamura: that is out of documentation's domain 17:12:12 dguitarbite: agreed, and yes fthamura I also agree that docs can push dev to be better about consistency but we have to document reality 17:12:15 dguitarbite: +1, based on doc i can find input for developer and future version 17:12:22 fthamura: you need to talk to the specific projects developers 17:13:02 dguitarbite: working on it, and will update shortly, and hope this patch will make new revision for better doc/training manual instruction, the pattern become standard for next new openstack's project 17:13:08 Dguitarbite what's the plan for icehouse bugs? 17:13:28 sarob: I need to take a look into it 17:13:37 sarob: I have to step away for about 15 minutes, are we talking about -specs later in the meeting? 17:13:51 Yup 17:14:00 I do not have any idea about the number of bugs now 17:14:19 sarob: any thing specific about bugs? 17:14:36 Dguitarbite I'm looking for a timeline to review the current state of two books 17:14:57 Dguitarbite create the icehouse bugs along the way 17:15:12 hmm, can I do some background checks and give you a realistic date in a day or two? 17:15:19 Dguitarbite so we can start handing out the big work 17:15:23 Bug 17:15:59 Dguitarbite okay. We not want to lose our audience by being out of date 17:16:14 Moving on? 17:16:24 yes 17:16:36 I will start a conversation in the docs mailing list soon 17:16:41 in a day mostly 17:16:45 *days time 17:17:00 #action dguitarbite icehouse bug plan 17:17:17 #topic testing team 17:17:19 #action dguitarbite will check the bugs for operators and associate guides 17:17:35 There is some overlap in responsibilities regarding quizzes/questions between Testing subgroup and Development/Stable Subgroup 17:17:46 We should write content of the guide first, quizzes second, with a separate BP, right? 17:18:08 You need to see the content before you write quizzes about it… Otherwise, there could be a mismatch between content and quizzes… 17:18:31 Matjazp_ maybe. You can dig through the icehouse install guides 17:19:10 Matjazp_ but I get your point. Maybe you can help dguitarbite get the icehouse bugs out 17:19:30 sarob: that would be great 17:19:31 Also... what is the BP granularity: write a separate BP for each chapter in each Guide? Or one BP for One Guide... 17:19:47 matjazp_: I think keep it logically seperate 17:20:04 if one blueprint delivers the points, it should be good enough 17:20:14 Matjazp_ id like to have blueprints very task specific 17:20:25 OK... many BPs than, one for each quizz 17:20:49 Matjazp_ think agile, blueprints as your backlog task 17:20:55 Card 17:21:03 who is quizz team? can i part of ? and where the discussion discuss regarding question bank creation? 17:21:04 -specs usage will be discussed later? 17:21:21 Matjazp_ in a few min 17:21:34 fthamura: sure... I'll make BPs as soon as we agree on spec usage 17:21:49 matjazp_ what's the plan with LPI ? 17:22:10 Matjazp_ can they be of help to us? 17:22:16 sarob: can't say it yet... Will update as soon it is official 17:22:40 matjazp_ okay. Anything else? 17:22:53 no 17:22:58 #topic infrastructure team 17:23:46 We have the content getting updated 17:23:53 Good work 17:24:05 We are almost done with the generic scripts 17:24:21 kudos to rleuthi 17:24:30 we need to start thinking about new Jenkins jobs 17:24:40 Like lang builders 17:24:47 yes, but there is still some time for that 17:25:04 we need to get the install scripts for OpenStack running 17:25:19 Openstack-manuals already has the ja out there 17:25:36 Dguitarbite understood 17:25:52 rluethi: any thing on infra? 17:26:10 you covered it pretty much. scripts are ready for testing. 17:26:31 #action new Jenkins jobs after trainer scripts completed 17:26:49 I am concerned that nobody understood the magic that made Jenkins work all of a sudden. 17:27:05 Rluethi me too 17:27:26 me too 17:27:34 CI is super critical and not well understood 17:27:43 * dguitarbite wondering if theres a god of binaries 17:28:05 We should study our tests well 17:28:20 Anything else? 17:28:27 dguitarbite: sure it is.. it's often on infra channel ;) 17:28:48 I may not have been magical, we changed the tox.ini which is referred by jenkins to run the CI jobs 17:29:04 Jenkins may be updating the tox.ini every * hours or so 17:29:09 we need to confirm that 17:29:21 since there was no other change and Rogers patch on infra was not merged 17:29:29 Dguitarbite that makes more sense 17:29:34 but I couldn't find the actual copy job in the Jenkins config. 17:29:42 can we use the install script in installation guide? or just jenkin specific? 17:29:55 Publish isn't it? 17:30:34 rluethi: need to take a look into it 17:30:44 Fthamura Jenkins is the tool that builds the guides, verifies the code 17:30:47 dguitarbite: yeah, we should. 17:31:03 it very well can be a trigger from manuals which is copying it, which would be bad since we need to control that 17:31:33 rluethi: you want to take up the investigation? 17:32:01 fthamura: http://jenkins-ci.org/ 17:32:11 dguitarbite: I can take another look, and then we can discuss the findings. how's that? 17:32:27 sounds good 17:32:35 rluethi: how about infra channel? just post there? 17:33:02 matjazp_: we need to make sure that we are doing it right from our end before approacing infra with this issue, what do you guys think? 17:33:27 #action dguitarbite rluethi investigate jenkins jobs for training-guides 17:33:31 dguitarbite: agreed 17:33:37 Docs people understand their jobs a lot better than infra 17:33:47 I'd start there 17:33:56 andreas is back :) 17:34:04 +1 agree, doc make we are more structured and organized :) 17:34:06 Righto 17:34:24 Move on? 17:34:31 one more thing 17:34:47 we need the server for setting up ZNC 17:34:50 for our core reviewers 17:35:00 Ah boy 17:35:04 I dropped that 17:35:05 ZNC? 17:35:13 Irc bouncer 17:35:35 fthamura: http://wiki.znc.in/ZNC 17:35:41 Dguitarbite I'll forward user info today 17:35:46 sure 17:35:50 Me flake 17:35:54 Ill ping you on skype after I wake up 17:35:59 sarob: no issues 17:36:02 :) 17:36:13 #topic spec, blueprint, how to 17:36:28 Annegentle around ? 17:36:55 Let's start with our team 17:37:03 #link https://review.openstack.org/#/c/100993/ 17:37:16 annegent_: specs/BP talk? 17:37:43 so just wanted to say, I like the idea of specs, but that I want them organized a particular way, so I wanted to talk about that here 17:37:47 I started writing up spec patches for our team to debate and review 17:38:13 and on the mailing list -- 17:38:21 annegent_: what's you proposal? 17:38:30 sarob: yes, but the doc program does not current have specs, and we run specs through the program. 17:39:02 so what I'd like is a doc-specs repo with training in one directory, api in another, users in another, and admin or ops in another 17:39:13 I can propose this to the list but wanted your take 17:39:28 Annegentl_ hmm, okay. We haven't discussed training guide books as the larger team before 17:39:36 sarob: which larger team? 17:39:38 annegent_: +1 for docs-specs repo 17:39:46 other projects have seperate repo for specs 17:39:52 I guess better for managing the History 17:39:55 dguitarbite: yep 17:40:03 Annegentl_ I'm happy to do it 17:40:15 out of the summit I figured the roadmaps would be enough for docs, but now I think doc-specs is what we need 17:40:32 annegent_ it would be great to get broad input on design 17:40:41 doc-specs should also help with the install guide reuse, that sort of thing 17:41:04 annegent_ I like it. Team? 17:41:14 sarob: annegent_: in the mean time, we can still use "our" specs? 17:41:15 and I want you guys to think of yourselves as a team within the Documentation Program 17:41:15 +1 for doc-specs repo 17:41:25 +1 17:41:29 * rluethi shrugs 17:41:31 sure 17:41:31 matjazp_: sarob: it just means moving to another repo is all 17:42:00 anngent_ can I get the new repo going today? 17:42:09 matjazp_: it will not make any difference for the blueprints, just change it from backend 17:42:24 Dguitarbite agreed 17:42:40 sarob: what I asked last week was a mailing list post, can you start there and point to a patch that contains the new repo? (double up for efficiency) 17:43:26 Annegent_ does the docs-spec repo exist? 17:43:50 sarob: no it does not 17:44:00 sarob: that's what we're discussing now, whether to create it 17:44:34 I also think we'll need to talk about whether the dev specs template is what we want 17:44:50 or if we need a different template 17:44:57 annegent_ okay, so I will post our list of specs to the docs ML to add to the overall discussion 17:45:21 I also don't know if you can have a separate review team per directory in a repo 17:45:33 sarob: ok, so discussion and voting will be on ML? 17:45:39 Annegentl_ why not? 17:46:06 sarob: I think it'd be great to have a separate review team per directory but I don't know if it's technologically feasible already 17:46:08 Matjazp_ voting needs to be gerrit 17:46:10 matjazp_: for the initial Repo setup, yes 17:46:18 but once the specs repo is setup 17:46:25 it will be similar to code review 17:46:27 on gerrit 17:46:40 dguitarbite: of course.. was talking about first setup and proposed layout of specs 17:46:51 we're talking about something like nova-specs https://review.openstack.org/#/q/project:openstack/nova-specs,n,z 17:47:07 Annegent_ we just follow this #link https://wiki.openstack.org/wiki/Training-guides#Create_a_Blueprint 17:47:09 matjazp_: I guess, the discussion will start from there, but the initial setup is also a commit to the new repo 17:47:17 it should use gerrit 17:47:44 sarob: but you just made that process up, right? we need to think of the bigger picture and existing patterns that people will recognize 17:47:58 annegent_ well yes we made it 17:48:38 sarob: right, so I'm asking that you bring this pattern to the docs mailing list -- I think it's a match and I don't want a one-off process so hence my request 17:48:46 Annegent_ we start there is what I am pointing out. 17:49:49 #action sarob post current training guides specs to the docs ML 17:49:54 sarob: what we do currently is step 1 but then step 2 forward is all done on the wiki. I'm asking for step 2 to be in a doc-spec repo 17:50:28 sarob: no the action is for you to post a proposal to use a doc-specs repo 17:50:41 sarob: is it possible to revise actions? I dunno meetbot :) 17:51:05 annegent_: I think its above meetbots pay grade ;) 17:51:20 #action sarob propose docs-spec repo to docs ML 17:51:22 dguitarbite: heh. 17:51:23 is there doc-spec's draft? so i can know, what will be inside? 17:51:39 fthamura: that's also part of the discussion, is the dev template appropriate for us? 17:51:45 actually, there should be #undo 17:51:54 but it works on the last item, so too late now. 17:52:04 #undo stupid stuff 17:52:05 Removing item from minutes: 17:52:31 OOO ahhhh 17:52:37 ooo! 17:52:41 sarob: :)) 17:52:43 irobot do you? :) 17:52:48 nice one roger 17:52:50 :) 17:53:03 annegent_: what do u mean of "is appropirate for us?"? 17:53:08 * rluethi bows 17:53:52 * dguitarbite bows back 17:53:53 fthamura: the template is here: https://review.openstack.org/#/c/87596/7/specs/template.rst 17:53:56 #link https://review.openstack.org/#/c/87596/7/specs/template.rst 17:54:08 #action sarob propose docs-spec repo to doc ML 17:54:09 #action Anne to respond to sarob's post with discussion about the template 17:54:30 I really want us to go in this direction, let's make it happen this week 17:54:31 I think we are good now 17:54:51 Annegent_ this morning 17:55:07 #topic any other business 17:55:11 ok.. so I'll delay new BPs for few days 17:55:16 5 minute warning 17:55:32 sarob: gogogo 17:55:45 matjazp_: what is BPs? i see several time mentioned here. 17:55:52 Matjazp_ put the details into the wiki for right now 17:55:56 BP=BluePrint 17:56:06 sarob: its already there 17:56:17 I guess, we meet later for discussing about Developer Guides design 17:56:18 Matjazp sweet 17:56:20 fthamura: https://wiki.openstack.org/wiki/Blueprints 17:56:27 aha :) thx ;) 17:57:05 Dguitarbite yes, it's gotten mixed up in this process change 17:57:05 or discuss in the blueprint :) 17:57:26 sarob: yeah, lets discuss the time then or keep it for next week? 17:57:42 Next week I think 17:57:51 ok 17:57:59 We can start a doc ML thread in the mean time 17:58:07 * dguitarbite +1 17:58:12 sarob: agree 17:58:19 Coolo 17:58:37 Anything else ? 17:59:14 silence = acceptance 17:59:21 Cheers people 17:59:21 that's all I got 17:59:27 bye 17:59:30 thanks sarob dguitarbite matjazp_ rluethi fthamura :) 17:59:31 bye 17:59:31 bye 17:59:31 bye 17:59:36 bye ;) 17:59:37 thanks for attending the meeting :) 17:59:44 #endmeeting