19:03:52 #startmeeting infra 19:03:52 Meeting started Tue Nov 12 19:03:52 2013 UTC and is due to finish in 60 minutes. The chair is fungi. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:03:53 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:03:55 The meeting name has been set to 'infra' 19:03:58 o/ 19:04:00 #link https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting 19:04:26 #link http://eavesdrop.openstack.org/meetings/infra/2013/infra.2013-10-29-19.03.html 19:04:41 #topic Actions from last meeting 19:05:01 #action jeblair move tarballs.o.o and include 50gb space for heat/trove images 19:05:14 clarkb: decommission old etherpad server eventually (after the summit) 19:05:23 add to the to do pile i guess 19:05:33 carry forward? 19:05:38 yup, I hadn't planned on getting to that today, but do plan on doing it this week 19:05:39 * ttx lurks 19:05:46 so by the time of next meeting that should be done 19:05:48 #action clarkb decommission old etherpad server eventually (after the summit) 19:06:03 #topic Trove testing (mordred, hub_cap) 19:06:22 status changes there we should be aware of? 19:06:36 fungi: last words on this were at the summit, which I missed (damn press briefings) 19:06:39 clarkb: btw we got the go-ahead to EOL folsom 19:07:04 i'll tack that onto the agenda 19:07:56 anyone have a tl;dr redux of the summit session for trove testing? i think i was in a different session as well 19:07:56 ttx: great 19:08:06 I was in a different session too 19:08:09 hub_cap: ^ 19:08:20 http://princessleia.com/ods/icehouse/TroveTempestTesting.txt 19:08:23 fungi: jeblair said there was nothing new or earthshattering 19:08:27 ooh 19:08:30 notes 19:08:30 wfm 19:08:30 ^^ snapshot of notes from etherpad 19:08:31 hub_cap is not around, losing big in Vegas 19:08:50 if you're gonna lose, lose big 19:09:03 but yeah, nothing crazy, publish images to tarballs.o.o and go from there 19:09:10 okay cool 19:09:16 moving along then... 19:09:21 #topic Tripleo testing (lifeless, pleia2) 19:09:42 i KNOW there was a lot discussed for this 19:09:54 lots of chats about this at the summit, I'm now kanbaning it with dprince and derekh 19:10:13 (derekh made a trello board for it this morning) 19:10:21 you just gerunded a borrowed word ;) 19:10:31 hehe 19:10:48 sorry, grammar thread on the ml has gotten to me 19:10:49 wow 19:10:56 pleia2: we are looking for you to fill in some of the gaps on the board while we get ramped up 19:11:04 that's twice today trello has been brought up in an infra context 19:11:06 dprince: great, will do 19:11:15 pleia2: anything derek and I can work on in parallel, etc 19:11:18 mordred: tripleo bleeding over in this case :) 19:11:20 * mordred imagines somewhere in china, jeblair felt a sharp pain 19:11:21 pleia2: huh, a new board; thats interesting! I will watch with interest [risk of fragmenting attention] 19:12:07 fungi: big ticket item I believe is lifeless success, or seeming success, in getting a bazillion companies to donate racks of gear to his cloud 19:12:28 mordred: our cloud 19:12:49 * dprince suspicious about strings being attached to free cloud hardware 19:12:53 mordred: summit week seem to be big in pretending to donate stuff or people to various causes 19:12:55 lifeless: heh, I woke up to it :) but not a terrible idea at the moment 19:13:21 lifeless: I hear you mentioned some heat stuff at summit, so it would be nice to have a chat with you, dprince and derekh tomorrow or so to make sure we're still on track 19:13:25 * mordred has faith in lifeless and his ability to beat them in to submission 19:13:34 mordred: the natural pessimistic in me would suggest to wait until reality strikes 19:14:21 yes 19:14:24 pleia2: heat cluster to define the set of deployed emulated bm test environments. 19:14:29 pleia2: just detail really 19:14:54 lifeless: oh ok, this just relies on something heat can already do, yeah? 19:15:10 pleia2: totally, it's just a template saying we want 10 such machines 19:15:19 rather than spin 10 up by hand 19:15:21 great 19:15:57 lifeless: I'm confused. I thought the TE Builder just lived on an undercloud machine somewhere? 19:17:29 dprince: maybe move this bit over to the tripleo meeting in -alt? (I think we can move on from -infra topic) 19:17:48 dprince: yes, you're confused. lets sync when I'm not running a meeting opposite this :) - right after perhaps? 19:17:55 so anyway, we should probably stick to status updates here and hash out tripleo details elsewhere for sake of time 19:18:12 fungi: yep, let's move on 19:18:17 cool 19:18:30 #topic Wsme / pecan testing (sdague, dhellman) 19:18:57 I volunteered to help with this in a summit session 19:19:14 fun! 19:19:32 where is it stuck for the moment? 19:19:32 once we clean up folsom and add havana jobs I am going to take a good look at the existing tempest/devstack jobs and take a stab at retemplating them to removing a bunch of the common noise 19:19:54 that should make it easy to add tempest jobs for WSME/pecan that aren't the same as the existing jobs to prevent mutual gating 19:20:04 ahh, right, being able to get branch selection working for those 19:20:09 the big problem right now is we need new jobs to prevent nova being gated on WSME/pecan 19:20:26 that should happen as a side effect of refactoring the job templates 19:21:00 so that we test released wsme/pecan on nova changes, but branch tip wsme/pecan on their own changes 19:21:10 correct 19:21:36 any other tidbits of note? 19:22:04 I have some ideas of what the refactor may look like but I think I need to wait for the cleaned up jobs before taking these ideas seriously 19:22:09 so I won't bore you with them now 19:22:35 #topic New etherpad.o.o server and migration (clarkb) 19:22:41 best summit etherpad experience yet 19:22:48 kudos, clarkb! 19:22:50 it didn't completely fall over! 19:23:01 the RTT between HKG and DFW was painful 19:23:02 it was great :) 19:23:11 but other than that the server seemed to be fine 19:23:18 ++ 19:23:33 pleia2 19:23:36 the remaining work here is to get rid of the old server now that we have a backlog of backups on the new server 19:23:42 pleia2's graphs of tcp connects were awesome :) 19:23:46 I plan to do that this week 19:23:46 and we've already got the related action item carried forward for that 19:23:52 hooray for cacti 19:24:27 anything else there before we move along? 19:24:28 (I included a capture from cacti in blog post + twitter) 19:24:32 fungi: nothing else from me 19:24:45 pleia2: got a link? 19:24:55 * fungi likes reading infra-centric blog entries 19:25:13 fungi: end of the post http://princessleia.com/journal/?p=8644 19:25:28 #link http://princessleia.com/journal/?p=8644 19:26:03 wowie. nice! 19:26:04 (there are 4 posts, that's the one with etherpad) 19:26:21 #topic Retiring https://github.com/openstack-ci 19:26:38 is this a stale agenda item, or do we need to discuss further? 19:26:38 oh, I forgot to talk about this with jeblair 19:27:06 push to next meeting 19:27:18 i guess we can leave it on the agenda and bring him in on the discussion next week 19:27:23 yah 19:27:24 ya I think we need jeblair's opinion 19:27:35 #topic Savanna testing 19:28:00 sergey doesn't seem to be here 19:28:03 do we have savanna people in here who wanted to discuss testing? 19:28:09 yeah, not finding him 19:28:28 going once 19:28:33 twice 19:28:40 #topic Goodbye Folsom (ttx, clarkb, fungi) 19:28:50 WOO 19:28:57 \o/ 19:28:59 * mordred is excited 19:29:32 so i think the order should be: 1. abandon all open folsom changes, 2. tag current branch tip, 3. remove jobs, 4. delete branches 19:29:41 that sound sane? 19:29:46 fungi: yes sounds good 19:29:55 and a follow up to that is to add havana jobs 19:30:24 right, i'm fine doing those in the same change if we want, though maybe a pair of changes would be better for atomicity 19:30:34 pair of chnages would be good 19:30:49 pair of changes 19:32:35 ttx: any input on the folsom eol plan above? 19:33:23 fungi: I think there is a race 19:33:29 I think you want to remove the jobs first 19:33:35 fungi: nope sounds good, looks close enought to waht was done for previous EOLs 19:33:42 that prevents movement 19:33:52 then tag branch tip 19:34:23 okay, works for me 19:34:29 then delete branches, and I don't think you need to abandon the changes 19:34:57 so... 1. remove jobs, 2. abandon all open folsom changes, 3. tag current branch tip, 4. delete branches 19:35:06 oh 19:35:10 leave changes open? 19:35:16 why not? 19:35:23 I don't think they'll show once the branch goes away 19:35:35 they show up in the all open changes list, but that's the only reason i have 19:35:40 oh, maybe 19:35:46 oh. well, if they do, then we should abandon them 19:36:01 it gives closure to the changes in a concrete way, I am on board with deleting them 19:36:05 er abandoning them 19:36:11 I'm ok with it 19:36:32 there are 5 of them after al 19:36:39 and two of them are fungi's 19:36:57 yeah, i'm a problem, i know ;) 19:37:41 okay, well we'll try to knock that out this week, so... 19:37:53 #action ttx, clarkb, fungi EOL Folsom branches 19:38:40 other concerns/ideas? 19:38:53 we should send an announcement to the lsits 19:39:08 that ^ 19:39:17 or is it better to be quiet aobut these things? I don't remember if we anounced it in a wide manner last time 19:39:20 let's consider that step #5 19:39:26 ttx? 19:39:27 ttx: ^ is that something you want to do? 19:39:56 clarkb: only if I'm needed to make it happen 19:40:11 oh, misreading 19:40:18 ttx: fungi and I can do that actual work, curious if you want it to be announced 19:40:44 I think we should do whatever was done for essex/diablo... if we did nothing then, I suggest we do nothing now 19:40:49 right. main reasons i have ttx in there are in case he wants to sign tags and send an announcement, as release manager 19:41:38 though if apevec or adam_g are a better fit for that, covering stable release management, that's cool too 19:42:21 a quick grep through mail doesn't show any announcements for diablo and essex 19:42:26 i'll dredge the likely ml archives from the time period of the eol tags 19:42:33 oh, clarkb just did 19:42:37 fungi: how about a,nnouncig it on openstack-stable-maint to make sure apevec and adam_g know about it 19:42:42 well I did a 'EOL essex' search 19:42:44 announcing* 19:42:48 ttx: ++ 19:42:52 ttx: sounds good. i'll do that 19:44:30 #topic Open discussion 19:44:56 15 minutes left. anybody have anything exciting they want to talk about? 19:45:02 or complain about? ;) 19:45:17 I need a nap :) 19:45:23 me too 19:45:37 fungi: Is there anything I can help with to finish up the jenkins Salt stuff? 19:45:42 pleia2: yesterday actually wasn't too bad. today is worse. I am bad at this jetlag thing 19:46:01 So, if there is time, I wanted to talk about importing packaging into -infra. There was a topic on the mailing list about it 19:46:27 http://lists.openstack.org/pipermail/openstack-infra/2013-October/000380.html 19:46:28 UtahDave: yeah, you had said something about getting me some pointers to the right docs for setting up cascading task dependencies with reacrots 19:46:32 er, reactors 19:46:57 pabelanger: there is time 19:47:24 fungi: Yeah, I can get you some info on that. Is that what you want to start with? 19:47:39 pabelanger: it looked like consensus was to put the package repos in openstack-infra. I like them living there. I think we should have an openstack-infra-packagers group that get +2/+A on those repos 19:48:07 pabelanger: have you added new projects to our systems yet? the best documentation for it is the stackforge documentation but you essentially s/stackforge/openstack-infra/ and it should work 19:48:08 UtahDave: i think that's my next item (checking the etherpad for that) 19:48:21 pabelanger: http://ci.openstack.org/stackforge.html 19:48:37 (I think you are relatively familiar with the process though) 19:48:52 ok, fungi. I'll get that for you later today. 19:49:00 clarkb, Right, so I guess the issue was just naming the repos and stuff. Based on what people think is good, I can do the leg with to get it imported. 19:49:11 I would just propose a change that adds the things, make sure that the source repos are ready to be sucked into gerrit (remove unneeded branches and so on) then we can approve and we are off to the races 19:49:21 UtahDave: yep, that's the next item i had on the plan... 19:49:22 Then we can have some discussions about building out the repo infra for APT and RPM 19:49:22 pabelanger: ah naming stuff 19:49:32 #link https://etherpad.openstack.org/p/salt-slavery-and-puppetry 19:50:11 For example, I have zuul-deb in my personal repos on github, so not sure if we want something like zuul-packaging 19:50:12 pabelanger: I am not super familiar with this stuff. would we need different package repos for apt and rpm or is the resulting artifact independent of source? 19:51:07 clarkb: we can probably get by with one repo tracking multiple distros/releases, but now sure whether subdirectories or branches are a better fit 19:51:09 clarkb, well, I could see 1 repo, but different branches (deb and rpm). But honestly, I think it comes down to what people prefer 19:51:22 pabelanger: fungi: gotcha 19:51:28 I am happy with zuul-packaging in that case 19:52:00 pabelanger: i suspect a branch for "rpm" wouldn't work well to suit, say, sles and fedora both. likely it would need to be per distro+release 19:52:27 fungi, agreed 19:52:56 and, for that matter, you may want to even track something like ubuntu precise and trusty separately 19:53:15 or debian wheezy and jessie 19:53:18 et cetera 19:53:26 Indeed 19:53:50 so, in general I think people are onboard with the idea 19:53:57 so i think the big remaining question is whether branches or directories work better for this purpose 19:54:11 I am comfortable with git so branches :) 19:54:13 i'm leaning toward branches 19:54:32 I too like branches 19:55:15 and it may make use of things like debian's git-buildpackage a little smoother (or it might get in the way even worse--we should obviously choose our branch names carefully so as to avoid that possibility) 19:55:56 probably worth setting up a minimal set of branches that work before we import into gerrit 19:56:06 easier to sort this stuff out before we add gerrit to the mix 19:56:23 fungi, Ya, the zuul packaging for debian is already setup to use git-buildpackage 19:56:46 keen 19:57:51 we should also have a small master branch with global documentation about the repo and how/why it's organized that way 19:57:59 ++ 19:58:03 because people will be confused when there's no master branch 19:58:30 doing that makes the default branch non specific so no distro favoritism :) 19:58:33 might be able to include workflow suggestions/links in there as well 19:59:25 okay, I can get started with something and get some feedback from you guys in -infra 19:59:36 excellent 19:59:39 and that's just about it for time 19:59:55 so until next time... 20:00:00 #endmeeting