19:02:03 #startmeeting infra 19:02:03 Meeting started Tue Nov 18 19:02:03 2014 UTC and is due to finish in 60 minutes. The chair is fungi. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:02:04 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:02:06 The meeting name has been set to 'infra' 19:02:21 #link https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting 19:02:30 o/ 19:02:34 o/ 19:02:37 we've got what looks like a very long and detailed agenda 19:02:42 o/ 19:03:03 i'm going to be cruel and drop the "moar reviews please" entries for the sake of getting issues/progress discussed 19:03:35 * sdague can lurk again, now that CSA season is over 19:03:37 apologies to those who are not getting enough reviews on their patches though, let's cover that in #openstack-infra later 19:03:42 #topic Actions from last meeting 19:04:05 there wer ejust the two for me and clark carried over from two meetings prior, and i'll repost those in hopes we get to them 19:04:38 #action clarkb figure out gerrit per project third party voting ACLs and third party accounts via openid 19:04:43 I have not gotten to that yet 19:04:49 #action fungi draft initial third-party liaisons description, to later be amended as needed before publication 19:04:53 nor have i that one 19:05:00 but now that I am back from summiting I should definitely have much more time to do that thing 19:05:14 #topic Priority Efforts (Swift logs) 19:05:24 nothing new on this front i'm aware of 19:05:25 what do we need from a third party liaisons description? 19:05:35 they all do something different 19:05:47 anteaya: yep, we can talk about it after the meeting 19:05:53 kk 19:05:59 jhesketh: around? 19:06:10 iirc jhesketh is on vacation in europe for a couple more weeks 19:06:14 ahh, righth-o 19:06:16 moving on then 19:06:25 sorry "holiday" 19:06:33 o/ 19:06:38 o/ 19:06:39 yep, last i recall we still needed some performance profiling 19:06:51 presumably that's where we still are 19:06:59 #topic Priority Efforts (Puppet module split) 19:07:11 asselin: great work on the jenkins module split 19:07:21 thanks :) 19:07:22 yay asselin 19:07:38 o/ 19:07:42 lessons learned there and in the previous module translated into some more improvements to the instructions in the spec 19:07:46 process is getting ironed out. 19:08:19 but all in all that one was not terribly painful except that the project creation change got approved after changes were approved to the same module in system-config 19:08:28 'last' question is regarding module file. project page and issues_url 19:08:36 so i ended up needing to force-push a new repo state into it once asselin prepared it 19:08:53 how are we avoiding that in future? 19:09:03 anteaya: clearer commit messages 19:09:04 and I had to re-subtree and push to my temp repo. not too difficult 19:09:08 awesome 19:09:16 anteaya, I added a not in the spec about it 19:09:21 note* 19:09:25 great 19:09:50 asselin: i was good with your proposed metadata, but still need a second core vote on https://review.openstack.org/134373 and https://review.openstack.org/134393 19:10:07 git merge is also terrible at figuring out how to merge yaml i guess, so after every module split lands we have to rebase the rest 19:10:11 not a big deal tho 19:10:16 asselin: anything else on teh jenkins module or lessons we learned there? 19:10:17 I can review those today 19:10:41 no, just review and look at the comments. not 100% clear what the issues url should be 19:11:06 nibalizer: you have some items for the github and pip modules yeah? 19:11:07 ya thats a question 19:11:24 just notes that they're ready if corse want to do them 19:11:31 do we have a storyboard for each puppet module? 19:11:42 asselin: we automatically get that with sb 19:11:43 but asselin's question should be discussed 19:12:52 oh, though i guess no storyboard project has appeared yet for openstack-infra/puppet-jenkins 19:12:56 so there isn't a storyboard for every module right now 19:13:13 do you need a uses storyboard flag to be set on the new projects? 19:13:19 ahh, yeah we flag them in projects.yaml 19:13:27 so there's a to-do item 19:13:36 okay 19:13:39 wfm 19:13:45 but i agree we should have a sb project for each of them (for every one of our git repos ideally?) 19:14:20 ya and ensure they are part of the correct storyboard group(s) 19:14:37 okay, sounds good 19:14:51 fungi: does that include subunit2sql? That's under openstack-infra too... 19:15:11 #agreed each puppet module needs a storyboard project 19:15:18 ok I will update docs and jenkins to use-storyboard: true 19:15:26 #agreed each puppet module needs to be associated with the infra project group 19:15:32 and that will be the bug reporting url for the metadata.json 19:15:42 mtreinish: yeah, in my opinion it's the same for any infra project 19:15:53 ++ 19:16:40 when do we delete the upstream git repo? 19:16:50 whenever now 19:17:01 fungi: hmm, ok I guess I can get my feet wet using it for that then 19:17:02 as soon as it's safely imported, you can delete the original 19:17:04 though there really isn't much reason too (so doesn't need to be a priority) 19:17:35 okay, also nibalizer has a proposed change to improve the module inclusion list for our puppet apply integration test 19:17:52 yep 19:18:05 i'll link the related reviews for this topic before i forget 19:18:14 basically just sources modules.env so we we dont have to keep two lists 19:18:24 #link https://review.openstack.org/134373 19:18:28 #link https://review.openstack.org/134393 19:18:38 #link https://review.openstack.org/134723 19:18:48 sounds fine to me 19:19:02 anything else on the puppet module split-out spec? 19:19:11 we need shepherds for the pip and github modules i guess 19:19:28 i'm happy to work with you on those this week unless someone else wants a turn 19:19:48 I can start the 'next' module. not sure which 19:20:15 fungi: awesome 19:20:22 nothing else for module split for me 19:20:24 thanks fungi for shepharding this one 19:21:01 #action fungi nibalizer get pip and github modules split out 19:21:28 #topic Priority Efforts (Nodepool DIB) 19:21:38 no news on this front, right? 19:21:50 nope, but I intend on reloading nodepool as trusty real soon now 19:22:01 okay cool 19:22:03 probably after jeblair gets back just in case anything goes really sideways 19:22:06 trusty++ 19:22:10 sounds good to me 19:22:14 and once I have done that we can really start moving on dib again as we will have the things we need to do that 19:22:28 #topic Priority Efforts (Docs publishing) 19:22:38 woowoo 19:22:43 i believe this is also waiting on people to be done travelling and get back into the swing of things 19:22:51 and swift logs 19:22:57 * annegent_ is just happy it's a priority effort 19:23:16 ya there is a spec up. I know I reviewed one version of it at least 19:23:16 right, well at least it's tied in with any adjustments we end up making to the swift log publication process 19:23:41 #link http://specs.openstack.org/openstack-infra/infra-specs/specs/doc-publishing.html 19:23:47 clarkb: that one, or something new? 19:24:01 thats the one 19:24:20 (which includes the proposed change if anyone is interested in implementing it) 19:24:35 okay, cool. so real soon now i guess, for some definition of real, soon and now 19:24:56 #topic Priority Efforts (Jobs on trusty) 19:25:04 #link https://etherpad.openstack.org/p/py34-transition 19:25:18 the good news is now we're really just down to the ubuntu backports we need 19:25:36 the bad news is there's been no visible movement on those bug reports for a month or more 19:25:59 :( 19:26:06 zul suggested i should pester barry about it, so i guess that's the next step 19:26:56 i think we really just need bug 1348954 worked, which would backport the most python recent 3.4.x to trusty 19:26:57 Launchpad bug 1348954 in python3.4 "update Python3 for trusty" [Undecided,Confirmed] https://launchpad.net/bugs/1348954 19:27:18 #topic puppet-httpd (ianw 11/18) 19:27:46 so looks like the project was created as an empty project/imported an empty repo? 19:28:03 ya 19:28:05 we didn't import 19:28:11 and there's some desire to get an initial puppet-apache module codebase imported as of the 1.0 tag? 19:28:16 which after it landed i was like *facepalm* 19:28:28 i've submitted a review to add the 0.0.4 code 19:28:38 oh, 0.0.4 19:28:50 oh wow it fails lint 19:28:51 haha 19:28:52 https://review.openstack.org/#/c/135369/ 19:28:55 i _can_ just git push --force that and preserve the upstream commit history, which would be nicer 19:28:57 thats amazing 19:29:05 fungi: ++ to that 19:29:33 then we can add a first commit to fix all the linting problems 19:29:35 and then your first change can be limited to whatever refactoring and cleanup is necessary to get jobs passing on it 19:29:38 yeah, that 19:29:40 okay 19:30:05 #action fungi push puppet-apache 0.0.4 into puppet-httpd master 19:30:28 woot 19:30:45 i can look at the issues after that's in 19:30:45 ianw: if you're around, anything else on this? 19:30:52 aha, awesome 19:31:00 no, that's all 19:31:12 ianw: so does that solve your concerns with the initial repo state? 19:31:23 then later (next week maybe) we can replace plabs apache with openstackci-httpd in modules.env 19:31:28 fungi: yep 19:31:29 perfect 19:31:54 oh, i skipped a very important priority effort, so rewinding to that topic group for a sec 19:31:56 apologies 19:32:13 #topic Priority Efforts (Storyboard migration) 19:32:19 its happening! \o/ 19:32:20 i meant to hit this right after the module split-outs 19:32:24 Yes! 19:32:30 #link https://etherpad.openstack.org/p/infra-storyboard-migration 19:32:37 #link https://etherpad.openstack.org/p/storyboard-migration-email 19:33:01 the last two docs update changes related to this are slowly getting in. pypi-mirror is part of the integrated gate 19:33:04 so next steps there are to get the remaining documentation updates approved/merged (are there any left?) 19:33:06 (it shouldn't be, but is) 19:33:14 yeah, that 19:33:24 There’s a couple. 19:33:33 and git-review change had a -1 for that test bug so it is making its way through rechecks 19:33:45 and then i need to do one last catch-up pass of imports, locking down lp bugs for each corresponding project as i go 19:34:01 and then krotscheck can send the notice to our community 19:34:04 WooooO! 19:34:10 And then the firestorm starts. 19:34:18 and then we get to fix all the new problems we're going to encounter, yes ;) 19:34:31 but it really is happening. super excited 19:34:36 items worth noting... 19:34:40 I have storyboard in a pinned tab already 19:35:14 first off, elastic-recheck needs to continue using the lp openstack-ci project for bugs for some indeterminate period 19:35:40 so i won't lock that down, and will probably need to periodically refresh the storyboard openstack-infra/system-config bug import 19:36:12 we _think_ the import script will handle that gracefully, based on incremental use of it so far 19:36:31 at least we have evidence that it works like we'll want 19:36:33 Yep. It just won’t eb fast. 19:36:46 i don't care about fast. i have computers 19:36:53 I like things that eb slow 19:37:42 other issue, as was mentioned in the summit session, is that e-mail notification isn't implemented yet. i know there has been some concern expressed that end users opening bugs may miss noticing updates 19:38:10 projects which are especially concerned by this should consider helping to get that storyboard spec implemented 19:39:09 #action fungi refresh storyboard imports and lock lp bugs 19:39:29 That’d be nice. 19:39:30 #action krotscheck announce infra projects migration to storyboard 19:40:05 anybody have anything else on the sb migration front? 19:40:38 #topic Puppet module maturity (nibalizer) 19:40:47 'sup nibalizer? 19:40:56 so id like to take a few steps to up our puppet module maintainer game 19:41:14 first is adding forge uploads into the same kindof workflow we do for other things 19:41:24 so tag, sign, push, then boom forge reease 19:41:31 i think i've got the engineering part of that figure out 19:41:57 https://review.openstack.org/134835 and https://review.openstack.org/134834 19:42:11 im looking to this group to say 'yea thats a good idea lets do it!' 19:42:20 also there was a credential issue raised, from what i saw with your discussion with crinkle yesterday 19:42:38 well so yes kindof 19:42:46 im speaking in this context only about openstackci modules 19:42:56 (around stackforge namespace and the current openstack puppet module community) 19:43:09 yea they have a different namespace 19:43:19 and im comfortable dealing with that down the road 19:43:24 okay, so not relevant for stackforge puppet modules, but openstack-infra yes 19:43:39 now historically we've submitted infra puppet modules to the openstackci namespace on the forge 19:43:56 and we translate openstack-infra/puppet-(.*) to openstackci/\1? 19:44:06 but i've got the impression we want to be openstack-infra not openstaci? can someone explain the context there? 19:44:10 what name should we use on the forge? 19:44:44 i'm not one for bikeshed arguments, if the current name is entrenched and not entirely confusing, then i'm in favor of continuing to use it 19:44:52 works for me 19:44:59 who has the password for that? 19:45:11 and can those keys get added to hiera? 19:45:14 i think all our root admins do, but i'll double check 19:45:19 okay 19:45:26 and yeah we would copy that into hiera if needed for upload jobs 19:45:37 ya we should all have access to it as rooters 19:45:58 next puppet has a tool that can generate pretty documenation, id like to start doing that and uploading it somewhere 19:46:12 and after that i'd like to start adding tests to the modules 19:46:24 wfm 19:46:26 and after that i'd like to add a section to the infra-manual about these modules 19:46:54 so thats my plan, questions? comments? concerns? 19:47:09 all sounds fine to me 19:47:18 okay sweet, im done then 19:47:20 do attend the manual sprint and we can find the right way to do that 19:47:51 #link https://wiki.openstack.org/wiki/VirtualSprints 19:47:53 as for the module uploading, a spec might be warranted 19:47:54 anteaya: ok 19:48:19 though if it's likely to be a smallish patch, we could probably dispense with the spec formality 19:48:32 fungi: ya especially since its a thing we do for pypi and maven stuff already 19:48:35 and the method should be similar 19:48:36 we already have some existing patterns which can be mostly copied to achieve this 19:48:44 fungi: the patch is also linked up there, so we can discuss it in the patch 19:48:45 right, that's what i was thinkingh 19:49:10 nibalizer: okay, should be fine to move forward there then 19:49:26 the thing to note is that puppet forge uploader ( a tool called blacksmith) doesnt run arbitrary code, it just tars and updates, so its all being done on the trusted node 19:49:40 anyways we can have that conversation in gerrit and not eat meeting time 19:49:42 #link https://review.openstack.org/134834 19:49:43 thats it for me 19:49:45 #link https://review.openstack.org/134835 19:49:58 #topic Review requests 19:50:26 ianw wants you all to know he has some nifty changes to review (see meeting agenda for various links) 19:50:44 also hashar says reviews on openstack-infra/zuul are piling up 19:50:46 go checkout the multi node testing devstack gate changes too ;) 19:50:59 i think nothing too controversial, just some stuff that has been sitting there 19:51:03 right. we have lots of stuff that needs reviewing, so, um, let's do all that 19:51:19 #topic Open discussion 19:51:25 so I will admit that I am doing my best to focus on the priority related things 19:51:28 the floor is open for any other concerns 19:51:32 because they are priorities and I only have so much time 19:51:38 clarkb: yep, me too 19:53:09 okay, if there's nothing else, we also need to talk about project renames 19:53:29 i assume any time before next meeting is not terribly convenient, but maybe next week it needs to come up on our agenda 19:54:15 oh, and we have a sizable backlog of third-party ci account requests 19:54:16 ya this week and next are actually pretty bad 19:54:26 since we have turkey day and I am still recovering from 2 weeks of afk 19:54:27 some contentious, hence i started a thread on the infra ml 19:54:35 #link http://lists.openstack.org/pipermail/openstack-infra/2014-November/002126.html 19:55:08 i could use hlp with the beaker-rspec stuff, if a rooter has some time to 1:1 and nodepool hold 19:55:21 i'd like to go ahead and service the pending requests where possible, but we need to try to achieve some consensus on where our naming rules need to be strictly applied and where we can loosen them 19:55:31 nibalizer: I don't have context there, but happy to do that 19:55:46 clarkb: that would be amazing 19:55:54 fungi: I am with you. I think stackforge should be allowed to wild west within reason 19:56:04 and hving third party tests for stackforge things is reasonable 19:56:30 well, reasonable and something which a number of them already do and have accounts grandfathered in for 19:56:33 ya 19:56:37 I can respond to the list 19:56:42 appreciated 19:57:42 okay, if that's all, i'll wrap the meeting and let ttx have the channel 19:58:04 thanks everyone! 19:58:07 #endmeeting