19:06:14 #startmeeting infra 19:06:15 Meeting started Tue Apr 23 19:06:14 2013 UTC. The chair is jeblair. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:06:16 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:06:18 The meeting name has been set to 'infra' 19:06:35 o/ 19:06:53 #link https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting 19:06:59 #link http://eavesdrop.openstack.org/meetings/infra/2013/infra.2013-04-09-19.02.html 19:07:13 no actions from last meeting! 19:07:25 #topic jenkins slave operating systems 19:07:31 o/ 19:07:36 mordred: ping 19:08:16 mordred wanted to discuss some aspects of this -- a process to fall back on lts after testing latest ubuntu 19:08:40 and at the moment we're still using dprince's rackspace account for rhel6 slaves... 19:08:56 as for that, i think we should switch to centos 19:08:59 yikes 19:09:23 jeblair: ++ I think that was the general agreement. Also moving from centos to rhel later if details get sorted shouldn't be terribly difficult 19:09:24 earlier we decided to set the summit as a cut-off for when we'd give up on waiting for rhel licenses 19:09:51 and i think he's still working on backporting rhel6 fixes to stable releases before we can refactor the jobs and start enforcing anything in the gate there 19:10:21 * ttx waves 19:10:53 oneiric is eol on may 9... 19:11:00 i'd like to defer centos discussions until we can bring the issue back up with dprince 19:11:01 and that's our current 2.6 test platform 19:11:32 but i suspect it would be easy enough to tackle now that rhel6 slaves are easily launched 19:11:46 fungi: from talking at the summit, afaik he's on board with centos. perhaps he'll chime in. 19:13:00 i think we should decide now what to do about rhel/centos, and i also think we need a backup plan if one of those is not ready for testing 2.6 globally 19:13:43 o/ 19:14:14 if rhel/centos aren't ready by may 9, what should we do? 19:14:23 i can go ahead and start launching centos slaves. rhel6 seems to be working on master for everything where we use oneiric, just not for some stable release branches 19:14:34 might depend on how close we are? could keep oneiric running a little bit past EOL 19:14:46 jeblair: debian? in theory debian would be very close to our ubuntu stuff 19:15:10 and I doubt debian has forked python 19:15:22 but yes, there may be a patch or two pending for grizzly on a couple projects, and sounded like still a few for folsom as well 19:15:47 squeeze comes with 2.6, but that'll be oldstable probably next week or so 19:16:03 ah, wheezy has the python2.6 packages 19:16:12 oldstable still gets us at least 6 months of security support though 19:16:15 yeah 19:16:21 choosing debian would work well for the upcoming use of eNovance servers for testing 19:16:39 anteaya: yeah, and we did tell you guys at ODS that testing debian could be on our horizon anyway 19:16:47 and yes, i'm running packaged 2.6, 2.7, 3.2 and 3.3 on wheezy currently as well. ought to work 19:16:55 wheezy should hit stable the first week in may (fingers crossed) 19:17:01 pleia2: pending TC approval was what I had in my notes 19:17:13 but if we are discussing a soft release, thumbs up from me 19:17:14 anteaya: yeah 19:17:14 to be clear, we take direction from what to test on from the supported platforms identified by the tc 19:17:37 #link http://eavesdrop.openstack.org/meetings/tc/2013/tc.2013-01-08-20.02.log.html 19:18:27 we're in the unusual situation of _possibly_ being unable to fulfill those requirements after may 9 19:18:35 unless rhel/centos starts working 19:18:55 so in that case, i think we can look to alternatives such as debian to approximate what we're doing now 19:19:10 but i don't think that necessarily means that we'd continue doing that 19:19:19 again, i'm mainly worried about folsom working on centos... maybe also grizzly. i expect master to "just work" 19:19:22 once rhel/centos are working 19:20:19 i can try to get some centos and debian slaves spun up this evening. i'll give me an opportunity to test UtahDave's salt minion registration additions while i'm at it 19:20:33 er, it'll give me an opportunity 19:20:52 fungi: okay. it would be good to know if debian is an option 19:21:04 but that way we'll know if we have work ahead of us from a launching slaves perspective 19:21:08 two birds with one stone, nice 19:22:12 also, i'm pretty sure lucid won't work, but perhaps that's worth double checking 19:22:46 #action fungi spin up centos and debian slaves 19:22:50 also would be nice to add them into d-g if that part works... or are we less concerned about oneiric devstack slaves since they're short-lived 19:22:59 I think lucid is a long shot 19:23:13 fungi: oneiric dg slaves can go away now that we're killing the diablo branch 19:23:32 istr devstack still being broken on rhel/centos (supposed to be more or less fixed in 6.4?) 19:23:44 we only need it for the unit tests, at the moment 19:23:51 perfect 19:24:02 that makes this a much easier proposition 19:25:05 #action dprince status of 2.6 unit tests on stable branches on rhel? 19:25:18 anything else related to this? 19:25:52 #topic bug triage / havana tasks 19:26:00 #link https://etherpad.openstack.org/cibugreview-april2013 19:26:07 pleia2 helpfully put that together 19:26:26 i brain dumped my notes from the summit into the bottom of that 19:26:39 that's something like ~40 new tasks 19:26:49 these are all the ones from https://bugs.launchpad.net/openstack-ci/+milestone/grizzly 19:26:56 do we want to set aside an hour at some point in the near future to go through the list together in an organized fashion? 19:27:10 so we also probably want to retarget and also look at bugs that don't have a target at all (I haven't done that yet) 19:27:19 clarkb: yes, i'd like to do that 19:27:44 pleia2: is today too busy for that? if so I can drive it 19:27:50 today is good 19:27:55 i'm free after this meeting. :) 19:28:00 ++ 19:28:01 perfect 19:28:07 awesome 19:28:41 okay, so let's work on that today, including going over the tasks i dumped at the bottom and making new bugs for those 19:29:42 #topic aaaa records 19:30:13 should i send out an announcement today and say we'll add aaaa records on friday? 19:30:24 o/ 19:30:26 +++++++++++++ 19:30:33 sorry I am very excited about this 19:30:36 me too 19:30:40 * fungi ^2 19:30:47 newbie dumb question, but would love a readers digest on "aaaa records" 19:30:55 ipv6 19:31:02 ah! thank you 19:31:03 rainya: ipv6 address resource records in dns 19:31:29 an ipv6 address is 4x as big as an ipv4 address, thus aaaa instead of just a 19:31:34 rainya: after the grizzly summit we migrated our jenkins and gerrit servers to ipv6 capable VMs. we are only just now getting around to adding records to DNS so that people will hit them on their ipv6 addresses 19:31:53 * rainya loves how readers digest means so many different things ;) 19:31:54 there were various problems we ran into before that needed to be fixed before we could flip the switch 19:31:55 thanks guys 19:32:01 also, when people try to learn ipv6, they make that noise. "AAAA!" 19:32:25 hah 19:32:58 at the moment i still know of three machines in rackspace exhibiting that ipv6 ssh issue, so they need to continue not to get aaaa records until that's solved 19:33:16 the most recent ticket is 939341 19:33:37 so maybe 1800utc/11am pdt friday? 19:33:58 works for me 19:34:08 ++ 19:34:23 (going for early enough for people to notice problems before the weekend and late enough that it doesn't screw up their week) 19:34:48 so we have the weekend to revert if there's lots of yelling 19:35:12 #action jeblair announce aaaa records for 1800utc fri apr 25 2013 19:35:31 #topic Discoverability for openstackwatch rss generator 19:35:58 the openstackwatch rss generator works now 19:36:03 where should it live? 19:36:25 did anybody come up with good ideas as to where we can visibly hyperlink project-specific resources? 19:36:26 somewhere in gerrit's interface is where I would expect it 19:36:46 should there be a new page? 19:36:55 or integration into current pages? 19:37:20 pleia2: like, from the projects list in gerrit or what? (ignoring for the moment how much java might be involved to make that happen) 19:38:00 fungi: I think if we add something to the footer of the page via js that should work 19:38:08 we need some additional js for the status alerts anyways 19:38:12 fungi: when landing on "review.openstack.org" it would be nic eto be able to search for "RSS" and find it 19:38:30 (indeed, I'm sure I did when I first started all of this :)) 19:38:30 searchable is nice 19:38:39 clarkb: pleia2: yeah, but there's a separate url per-project 19:39:00 single-feed is an option, but makes little sense in our setup i think 19:39:01 so would that link off to somewhere else with a list of all the different rss feeds then? 19:39:17 fungi: oh, openstackwatch is separate urls? 19:39:34 pleia2: yes 19:39:39 fungi: +1 19:39:43 one per project, yeah. as jeblair said we could make just one feed but i think it would be pretty useless for our users that way 19:39:45 one url per feed, one feed per project 19:40:14 * pleia2 nods 19:40:29 nova devs probably just want to watch the nova feed for example, or maybe just nova and cinder. et cetera 19:40:41 could we do both? one page with links to all the feeds plus a feed link per project main page 19:40:56 too much? 19:40:58 anteaya: gerrit doesn't really have a project page 19:41:19 the projects list is under "admin" and not many users click there 19:41:24 (we could add it to the launchpad project pages) 19:41:34 there's an idea 19:41:42 jeblair: hmmm 19:42:05 that might work, links on the launchpad project page 19:42:31 i'm liking that suggestion, personally 19:42:37 so a page with all the links in gerrit, launchpad, or somewhere else? (as well as the wiki) 19:42:58 i don't think we need more than one of those :) 19:43:06 okay 19:43:24 it is easy enough to do, but how often do people actually go to the launchpad page? I wonder how discoverable it is 19:43:30 so just a link on the project page in launchpad and a wikipage with all of them 19:43:47 pleia2: and then link from gerrit to the wiki page for discoverability? 19:43:54 jeblair: that's what I'm thinking 19:43:56 it wouldn't be my intuition to goto launch for it. 19:44:13 lauchpad does't even support git. 19:44:28 zaro: but the bugs and blueprints are all still there 19:44:31 people go to lp for bugs, but that won't get them to hte main page 19:44:32 personally I try to avoid EVER going to launchpad 19:44:32 okay so were in gerrit for the link? 19:44:44 s/were/where 19:45:15 our gerrit theming is in the config repo, right? if so, just a patch to that presumably 19:45:17 where ever it's easiest to add it :) 19:45:25 hmmm 19:45:36 okay, I will plant a flag with a patch 19:45:46 review away if you have better suggestions 19:46:05 so gerrit (somewhere) launchpad project page, wiki page 19:46:06 yes? 19:46:07 probably not in the header menus since having it buried would be hard to find, in the header or footer? 19:46:19 pleia2: I'll look around 19:46:27 i think the footer 19:47:05 it's not needed in the normal operation of gerrit, it's there for reference 19:47:13 yeah 19:47:14 I try for something and we can hash it out when we have a patch in front of us? 19:47:21 thanks anteaya 19:47:24 thank you 19:48:09 also, we should be very certain about the actual urls -- i think we should consider them permanent once we put this into production and document it. 19:48:19 good point 19:48:26 (ie, do we want to use the cdn or host on review.o.o, etc) 19:48:51 yeah, the swift cdn url format i used was just a first stab. other suggestions welcome there 19:49:18 let's move on to baremetal? 19:49:29 * fungi nods. 10 minutes remaining 19:49:29 #topic baremetal project 19:49:37 devananda: ^ 19:49:47 hi! 19:50:36 jeblair: so i believe we have approval from mark collier for the code name "truss" 19:50:47 what's the process to get things going? 19:50:58 the name sounds painful ;) 19:51:20 devananda: bring it up with the tc, since it's a scope change for an existing project 19:51:27 for those whose minds might wander, https://en.wikipedia.org/wiki/Truss 19:51:36 devananda: ha ha ha, I can't stop laughing 19:51:49 devananda: (i don't anticipate a problem, people in general are in favor of modularizing nova) 19:52:16 devananda: ttx may know the exact procedure -- does there need to be a formal motion, and if so, how should it be written? 19:53:07 devananda: when the tc signs off on it, we can run a git filter branch to make a new repo 19:53:09 jeblair: gotcha. /me waits to see if ttx is around and has an answer :) 19:53:24 devananda: and otherwise set it up like a new project 19:53:25 assuming the tc hands it back to us stamped with approval we would need to filter branch, import into gerrit, setup jenkins tests. The other bits I think you can do for yourself on launchpad etc 19:53:35 from a technical perspective, this is more or less like a new gerrit project just with the need to split the repos via filter-branch. do we do that before or clean it up after import? 19:53:42 er, what clarkb said 19:53:50 fungi: before please 19:54:29 so basically there will need to be a quiescence period where people merge what they're going to merge, freeze, split, then resume work on the new project i guess 19:54:50 does that quiescence apply to all of nova, or just the baremetal-specific code bits? 19:55:28 I think just baremetal specific bits 19:55:39 you also patch in important changes after the split 19:55:40 great. that should be fairly simple 19:55:40 for nova proper there'll just be a follow-up commit to delete all the bm-related files presumably 19:55:51 devananda: i just squatted truss on launchpad and pypi 19:56:01 well, no. we won't delete the current code from nova trunk 19:56:13 because it has to be there for at least one release as deprecated 19:56:17 like with cinder and quantum, there'll be parallel things for a bit 19:56:18 o/ does this mean the bm jokes are nearing eol? 19:56:18 ahh, okay. even easier then 19:56:19 exactly 19:56:34 rainya: hopefully, though now you can make truss jokes instead :p 19:56:55 devananda: i shall try to content myself with straight poles joining up with nodes! 19:57:05 devananda: is truss going to get its own user-facing api, and client? 19:57:06 rainya: :) 19:57:08 "squatted truss" -- the jokes make themselves 19:57:08 jeblair: thanks 19:57:19 jlk: better than squatting bm 19:57:42 jeblair: yes 19:57:49 jeblair: yes, it iwll have a user-facing api 19:58:03 oh, exciting. i am curious as to why, but i don't need to know right now. 19:58:12 i also squatted python-trussclient then. :) 19:58:22 enrollment of machines in the internal inventory 19:58:30 yep ^ 19:58:39 also for interfacing with CMDBs and so forth 19:58:45 ok 19:59:01 one-minute warning 19:59:11 so. i'll ping ttx and the tc, and let ya know. thanks! 19:59:40 that's time. thanks everyone! 19:59:41 #endmeeting