19:01:13 #startmeeting ironic 19:01:14 Meeting started Mon Sep 15 19:01:13 2014 UTC and is due to finish in 60 minutes. The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:15 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:01:17 \o 19:01:18 The meeting name has been set to 'ironic' 19:01:19 \o/ 19:01:24 o/ 19:01:24 As usual - our agenda can be found here: 19:01:26 #link https://wiki.openstack.org/wiki/Meetings/Ironic 19:01:45 o/ 19:01:54 #chair NobodyCam 19:01:54 Current chairs: NobodyCam devananda 19:02:05 #topic announcements 19:02:14 hi 19:02:18 a few quick reminders for folks, mostly about the release schedule 19:02:38 we are in feature freeze right now, which also means string and dependency freezes 19:02:55 also, the UEFI work landed on time -- that was our only feature freeze exception 19:02:58 good job on that :) 19:03:03 nice 19:03:04 \o 19:03:05 :) 19:03:09 devananda: just for clarity, can you define "string freeze" for me? 19:03:27 Shrews: changes in translated strings (exception and log messages) should be avoided 19:03:29 * NobodyCam would assume anything translated 19:03:40 #link https://wiki.openstack.org/wiki/StringFreeze 19:03:42 devananda: ok, that's what i assumed, but wanted to be sure 19:04:02 does it really matter for us, since they aren't translating anything for ironic anyway? 19:04:10 rloo: but they are 19:04:19 really? cool! 19:04:29 I've seen translation patches 19:04:31 devananda: by that wiki, we can change _existing_ strings, but not add _new_ ones? 19:04:37 rloo, https://www.transifex.com/projects/p/ironic/ :) 19:04:38 IIRC, there were two >50% translated languages in Icehouse 19:04:52 Shrews: correct. but we should try to minimize those changes too 19:04:57 gotcha 19:05:13 also 19:05:19 tomorrow is the second half of our graduation review 19:05:30 there were only two (minor) objections last week, both of which have been (IMO) addressed 19:05:31 * NobodyCam will be in tc meeting 19:05:43 fyi- the ironic dib chagnes to support ilo virtual media driver https://review.openstack.org/#/c/114124/ landed in tripleo 19:05:59 wanyen: thanks, but please save that for later in the meeting 19:06:10 is the wiki for migration finished? (/me will take a look) 19:06:13 that's it for my announcemetns. NobodyCam - anything from you? 19:06:16 devananda, i was going to polish off the migration docs today. should those be proposed to the ironic docs or is a pad/wiki good enough? 19:06:34 #link https://wiki.openstack.org/wiki/Ironic/NovaBaremetalIronicMigration 19:06:41 adam_g, lucasagomes: I'm currently assuming wiki is good enough until someone tells me otherwise 19:06:43 just maybe to get more eyes on https://wiki.openstack.org/wiki/Ironic/NovaBaremetalIronicMigration 19:07:02 oh! i didnt realize that was already there 19:07:05 cool 19:07:07 adam_g: there is a patch from jroll to fix the bug you hit in the migration of a live instance 19:07:10 also thank you to all who have helped on that doc 19:07:13 yeah it looks good, I haven't seem it in a while 19:07:16 devananda: what were the two minor objections by TC last week? 19:07:18 last time wasn't that complete 19:07:23 adam_g: https://review.openstack.org/#/c/121615/ 19:07:39 rloo: api proxy in nova (NobodyCam wrote it, it is merged) and migration docs (wiki above) 19:07:51 thx devananda 19:07:59 nice. the migration tool needs to be fixed as well, to properly populate the node instance_info 19:08:01 thank you to lucasagomes for the tests on the proxy patch 19:08:07 NobodyCam, yvw :) 19:08:40 #info Last week, the TC raised two minor objections to our graduation: an API proxy in Nova (now merged) and migration docs (now written at https://wiki.openstack.org/wiki/Ironic/NovaBaremetalIronicMigration ) 19:08:51 #info Final graduation review for Ironic in Juno is tomorrow 19:08:52 oh would this be a good place to bring up the fact that we broke tripleo last week? 19:09:22 NobodyCam: if there should be a discussion about that, perhaps save it for a bit later 19:09:23 adam_g: there's also this fix, jfyi: https://review.openstack.org/#/c/121651/ 19:09:27 ack 19:09:40 #topic Juno RC progress 19:09:46 #link https://launchpad.net/ironic/+milestone/juno-rc1 19:09:55 jroll, thanks 19:10:18 we've got the one BP done, but there are still >15 bugs we've targeted to RC1 19:10:32 18 IIRC :) 19:10:38 that should be the area of our focus in the next few weeks 19:10:50 I'd like to take a few minutes in each weekly meeting to open the door 19:10:58 for folks to call out bugs they think need extra attention 19:11:06 of course, we should be doing that during the week too :) 19:11:22 devananda: RC1 is Sept 25 (next THurs) 19:11:45 rloo: right. not next few weeks. next 10 days 19:11:53 #info RC1 is targeted to Sept 25 -- 10 days from now 19:12:00 (thanks ...) 19:12:27 deva, when is document due? due at RC1? 19:13:12 #info Juno release is targeted to Oct 16 19:13:26 wanyen: the sooner the better. Please don't leave it until Oct 16 19:13:45 deva, sure. 19:14:17 anyhow, I see a lot of bugs in progress 19:14:41 ahh so no need to bug folks about bugs 19:14:46 (yet) 19:14:48 would folks prefer to walk through them now, or have a less formal meeting for that, say, on wednesday? 19:14:49 lol :-p 19:15:13 on Wed 19:15:16 let's have a bug day later 19:15:20 I won't be here wed though :( 19:15:27 maybe do a bug-squash-day on wed and fri, until we are comfortable with the release quality? 19:15:27 I'm busy on Wed 19:15:28 Nor will I 19:15:34 ok - what's a better day :) 19:15:39 right, but can we make it a bit earlier than this meeting? 19:15:41 devananda: I would wed. so folks have to prep / finsh up 19:15:44 lucasagomes: ++ 19:15:56 My requirement is pretty much not Weds or Fri if you want me there :) 19:15:58 lucasagomes: i think we've usually done it around 8am PST 19:16:10 devananda, yeah, that's a good time 19:16:15 For me Thu-Fri and yes, actually earlier 19:16:16 so, I'm in :) 19:16:17 JayF: heh. ok. fwiw, friday is unofficial openstack bug day (in general, not just during RC) 19:16:26 cool 19:16:45 is that "create new bug day", or "squash existing bugs day" :) 19:17:05 #info we're going to have volunteer bug squash days thu & fri at 8am PST this week 19:17:21 Shrews: depends. probably both :) 19:17:48 any one else want to call out any bugs in particular? dtantsur - if you want to give your report on bug stats, I know it's out of order, but might as well give it now 19:18:00 right 19:18:07 Open: 111 (-22). 6 new (-3), 36 in progress (-8), 1 critical (+1), 11 high (-3) and 5 incomplete (+1); juno-rc1: 18 (+3) 19:18:20 we're better now, once some bugs moved to Nova 19:18:21 Open -22 --- awesome! 19:18:29 (also fixed a lot) 19:18:33 :) 19:18:35 great 19:18:47 and how/should we track ironic-bugs-in-nova? 19:18:51 but 18 for rc1 is a lot too (growed +3) 19:18:57 rloo, tag 'ironic' 19:18:59 devananda: i think we're going to need to start paying more attention to the hash ring bugs greghaynes is working on. we'll need to test that stuff pretty well, IMO 19:19:08 Shrews: ++ 19:19:11 Shrews: ++ 19:19:22 Shrews: at this point, it looks like a major functional change though 19:19:31 devananda: yeah, that was my next question 19:19:38 Shrews: so I think we need a discussion on whether it's too big for this late in the cycle 19:19:45 devananda: i think so 19:19:50 devananda: ++ 19:19:52 but, can discuss later 19:19:58 yeah it seems to be quite big/hard to test 19:20:13 Shrews, +1 to discuss later 19:20:22 later == when? 19:20:31 paris? 19:20:32 Shrews: if you have a grasp on the issue, can you raise it on the ML? I don't see greghanes here, or I'd ask him to weigh in 19:20:36 open topic :) 19:20:40 idk 19:20:50 paris sounds like a good time :D 19:21:04 so no fix in juno 19:21:05 aiui, the problem -might- be big enough to warrant fixing now 19:21:09 but I haven't dug in yet 19:21:10 devananda: i've been following one of his changes, but haven't looked at the second (or lifeless's change yet) 19:21:24 devananda: i'll catch up and start something though 19:21:25 JayF: jroll: have ya'll been following the hash ring bug thread? 19:21:35 rloo: I think time is to short and change is to big for J 19:21:37 devananda: honestly; no 19:21:39 devananda: a bit, yeah 19:21:51 are you affected by it // do you care about the fix? 19:22:04 is ironic 'usable' w/o the change? rackspace knows? 19:22:28 rloo: well. they are the only ones publicly discussing their in-production ironic service afaik 19:22:30 devananda: we're affected less by hash ring rebalances, as the agent driver doesn't have any local state on the conductor 19:22:40 jroll: ack. that's what I figured 19:23:15 devananda: we do care about the fix from a "we are nerds interested in distributed systems" standpoint, but that might be it 19:23:36 #info hash ring bug needs further discussion. May be a serious issue for PXE driver, but doesn't really affect IPA. 19:24:02 thanks, all. going to move on so we have time for everything 19:24:13 #topic Kilo summit planning 19:24:19 so, a few things here 19:24:41 first, assuming Ironic graduates, it'll get in the main track, and we can all enjoy the cross project track on the first day 19:24:46 (that's still an assumption at this point) 19:25:02 second, the neat website we've used in the past is -not- being used for planning purposes this time 19:25:23 all projects are using etherpads, google docs, or carrier pidgeons for session planning 19:25:33 I set this up last week -- should be open to everyone to edit 19:25:34 #link https://docs.google.com/spreadsheets/d/1XBKdeDeGfaRYaThjIIoYRwe_zPensECnxsKUuqdoVmQ/edit#gid=0 19:25:46 let's start throwing ideas up there now 19:25:52 and we'll discuss as Paris approaches 19:26:07 (by "now" i mean over the next month -- not this very minute) 19:26:17 * jroll watches everyone edit at once 19:26:27 lol 19:26:28 nice :) 19:26:38 I also want to ask, if anyone has a strong objection to this format and would prefer etherpad (or carrier pidgeon) 19:26:44 please speak up now 19:26:52 before we get a lot of info in the gdoc 19:26:55 * NobodyCam votes gdoc!!! 19:27:06 I like the spreadsheet 19:27:06 pidgeon sounds fine! 19:27:12 but pigeons are also fine with m 19:27:14 e 19:27:15 I don't mind the spreadsheet 19:27:37 * NobodyCam has tooo many ehter pads open 19:27:39 what is the Spec? column for? link to spec? 19:27:45 rloo: yes, if there is one 19:28:01 have we opened specs for kilo yet? 19:28:05 rloo: that was a feature on the old planning site -- you could link to specs or BPs in the proposal 19:28:12 have we opened the "K" directory in the spec repo yet? 19:28:17 rloo: no :) but that hasn't stopped folks from proposing them anyway 19:28:25 ha ha 19:28:29 btw specs for K needs to adhere to the new format write? 19:28:49 we maybe need to make it more clear/update our wiki about it 19:28:58 write/right* 19:28:58 I'd be very +1 to opening the kilo/ folder for ironic-specs, even if that means the specs proposed have to be rebased onto another template or can't be approved until officially opens 19:28:59 lucasagomes: ++ 19:29:45 heh 19:29:49 JayF: I would rather not open it until, at the earliest, Sept 25 (when RC1 is tagged) 19:30:54 devananda, JayF, I think things are fine as is, folks can rebase as needed if we reopen 19:31:09 who if anyone is going to port any J specs to K ? is that even a thing to be concerned about? 19:31:30 spec's that did not land 19:31:30 NobodyCam: none of us should do that 19:31:50 NobodyCam: the spec's author should rebase and repropose it -- this is also a way for us to see if they're still interested/committed to doing the work 19:32:07 so the spec review team should only look at k folder (once it opens) 19:32:17 we should, after RC, open the Kilo folder and publish some guidelines (link to new spec format, etc) 19:32:23 NobodyCam: yep 19:32:30 devananda: ack ... TY 19:33:03 more questions on Kilo design summit today? (I'm sure we'll come back to it in two weeks) 19:33:19 We have 4 design sessions, right? 19:33:33 also - if any ATC did not get their access code, please ping me privately 19:33:43 JayF: don't know yet. that depends on if ironic graduate 19:33:45 JayF: I think it's unknown at this time 19:34:04 tomorrow is the day! 19:34:10 if we do not graduate we get two? 19:34:14 oh - so, we will have a pod for Ironic all week 19:34:24 we may only get a few "full" sessions 19:34:38 but we can have our own unconference style thing 19:34:45 use the google doc to organize 19:34:46 or what ever 19:34:53 that's up to us -- it just won't be in the published schedule 19:35:00 does the Ironic pod need to be man'd as a "both" would be 19:35:00 also - that's how all the projects are being run this time 19:35:13 NobodyCam: no. it's in the developer area, not public hall 19:35:20 :) 19:35:31 it should probably have a sign and a schedule posted, or something 19:35:47 ok - moving on :) 19:35:59 #topic subteam status report - testing and CI 19:36:02 adam_g: hi! 19:36:06 hey! 19:36:12 you've done all the things! it's amazing! :) 19:36:26 not too much to report from last time. still waiting on getting all the grenade testing in place in our gate, a couple pending infra reviews still @ https://review.openstack.org/#/q/topic:ironic_infra,n,z 19:36:48 I dont see a grenade test in that list? 19:37:28 devananda, there is already a check-grenade-dsvm-ironic-sideways, but it requires some of those changes in that topic to get it passing 19:37:34 ahh ok 19:38:34 thats about it from me, not sure if others have more to report on the CI front 19:38:52 cool. nothing more from me 19:39:16 thank you adam_g :) great work! 19:39:17 i could say "thanks" several more times, though :) 19:39:27 np :) 19:39:43 #topic oslo 19:39:46 GheRivero: hi! around? 19:40:26 just arrived, just caching up with everything 19:40:35 so no news from my side 19:40:39 ok, np. I'll summarize what I know of oslo status real quick, then 19:40:55 I'm not expecting any big changse from oslo, aside from their publishing of Juno final versions of most of the libraries 19:41:09 which should be this thursday, IIRC 19:41:21 so we'll probably see one large patch to openstack-requirements from the bot 19:41:22 I expect all of those to be re-versioned releases of things we have already released by thursday, fwiw 19:42:10 should be trivial to land :) 19:42:24 #topic drivers 19:42:41 jroll, linggao, wanyen - anything to report on your various drivers? 19:42:47 hi! 19:42:49 * devananda notes that linggao isn't here 19:42:56 Would this be a good time to talk about IPA releasing/versioning for Juno? 19:42:58 I have a few quick things 19:43:14 JayF, +1 I think so 19:43:16 JayF: sure! 19:43:17 JayF: I think so, let me quickly status update 19:43:42 as usual, our semi-current status is always here: 19:43:44 #link https://etherpad.openstack.org/p/ipa-todos 19:43:57 currently working on getting CI running, the patches are listed in that etherpad 19:44:38 we're also working on a lot of documentation-type things, JayF and I started writing docstrings for everything, there's a few patches up, would love for some folks that don't typically work on IPA to review them :) 19:45:03 I heard that we have our first thrid party CI up? 19:45:21 we do! that's for ipminative 19:45:25 NobodyCam: yep! check-ironic-xcat-third-party 19:45:33 JayF: want to lead on the release/versioning stuff? 19:45:35 awesome!!! 19:45:37 nice, ibm is behind that right? 19:46:02 So with regards to IPA, we've had some informal discussions about how IPA should be released for Juno 19:46:06 yes - linggao is coordinating it, iirc 19:46:12 when we originally added the project; it was going to be SEMVER similar to clients 19:46:29 I wonder if that's the better approach vs blessing a release for Juno 19:46:38 I don't know the right answer, and I'm not even sure I have good ideas 19:46:50 So anyone willing to share their ideas, please do 19:47:23 JayF, I like cutting a version for it. But how we are doing it pip? 19:47:50 the mechanics of getting something into pip or into the release aren't that complex -- i can walk (someone) through that 19:48:04 but I think there are some important technical questions about which way it *should* be released 19:48:16 if IPA is treated like a client lib, 19:48:20 Yeah, I'm more concerned about how we should do it than the mechanics of doing whatever we decide 19:48:25 - it is free to release often, on its own cadence 19:48:31 I can figure out how to do anything that's been done before, and maybe even some new stuff soon :) 19:48:47 - it can get an entry in global-requrieemnts, and Ironic can depend on a specific version of it (from pip or from packages) 19:49:03 - downstream packagers (eg, deb & fedora) can pin it in their distros, too 19:49:07 and can release updates as needed 19:49:26 if on the other hand, IPA is treated like a project 19:49:36 - it only gets released once every six months 19:49:47 devananda: well, like I was saying earlier in IRC: IPA seems almost like something that a 'release' should be built images, not source 19:49:59 devananda: similar to how ipxe and syslinux package images in distros 19:50:11 but I don't think Openstack has something that models that way currently 19:50:12 fyi: ten minutes to go 19:50:14 - the dependency between it and Ironic is a bit harder to enforce and test, since there are no packaged versions of it between releases 19:50:39 JayF: the reason I disagree with releasing images, is then they are not customizable, which is almost a necessity 19:51:05 JayF: I don't hear you saying that rackspace wants to start releasing and maintaining images of CoresOS + IPA 19:51:12 if custom images are something someone wants/needs, I don't see the harm in having them pull it from git 19:51:31 JayF: also, OpenStack is not in that business either 19:51:44 devananda: We already tried; we were told to do it first-party in a post job that uploads to tarballs.openstack, which is what we're doing 19:52:05 I don't think standard releases are very useful except for testing, but that might just be me 19:52:17 JayF: yes. that is a tarball of the current build, useful by our CI systems 19:52:22 and that may be me thinking ahead to more advanced features that we're using, current upstream might be useful 19:52:24 JayF: to ensure that TIP of one project works with TIP of another 19:52:30 there's no releasing, no versioning, no packaging there 19:53:13 JayF: for example, two weeks after Kilo opens, how will you answer the request from a user who instaled Juno from deb packages 19:53:19 who wants to download a build of IPA compatible with that 19:53:20 ? 19:53:34 I'm inclined to think we should release as a client, after hearing this stuff 19:53:45 though I don't think distros should package it 19:53:47 IPA should be compatible with any ironic, if it isn't we didn't version well, similar to how we do with the clients 19:53:53 but I'm not sure we're good enough to do that ^ yet 19:53:58 jroll: ++ 19:53:59 jroll probably has the most reasonable solution 19:54:17 I think we are good enough to do that yet, but pinning a version can't hurt 19:54:36 jroll: as I see it, that would mean someone who is using their distro's Juno Ironic would also install IPA from their distro (who presumably used the versionthat we pinned in the release of Juno) to build their images 19:55:08 hrm, I don't think that's a good way to build images :| 19:55:12 5 minutes 19:55:24 I can help point ya'll at the process to make ^ happen -- basically means setting up a thing in pypi and a job in infra 19:55:38 are you saying they should e.g. cp /usr/local/bin/ironic-python-agent /my/fancy/image/filesystem 19:55:44 sounds... wrong 19:55:48 btu that might just be me, dunno 19:55:49 no 19:55:53 we can talk about specifics later 19:55:54 ok, we can continue this after the meeting 19:55:56 :) 19:56:09 #topic outstanding items for graduation 19:56:20 lucasagomes: I think you posted this? afaik, we've already covered it -- and we should be good 19:56:20 I think we'll want some wiki docs about how we expect people to use the pypi release to build their images 19:56:34 * NobodyCam updated the proxy line item color to blue 19:56:34 devananda, oh yeah we talked about it in the channel 19:56:40 JayF: indeed 19:56:41 and here 19:56:46 cool, skipping it 19:56:49 #topic Open Discussion 19:56:56 3 minutes! go :) 19:57:13 * jroll runs around waving his hands wildly 19:57:15 devananda, can we make the ironic tempest jobs voting in Nova? 19:57:23 since now the driver is merged there 19:57:25 lucasagomes: only when ironic graduates 19:57:34 ust a quick note we broke tripleo last week with a minor change to the virsh ssh commands. was fixed with https://review.openstack.org/#/c/120799 19:57:38 hmm 19:57:43 lucasagomes: also there's a much longer conversation happening on the ML and amongst the TC about that sort of thing 19:57:47 which I wont attempt to summarize now 19:58:13 devananda: when were you going to do another CLI release? 19:58:13 read the many threads on "future of the integrated release", "splitting out Nova", and so on ... and expect details in Paris 19:58:14 devananda, it's not the discussion about splitting the drivers out of the tree is it? 19:58:15 * NobodyCam crys after all that work done to land our driver 19:58:18 * lucasagomes needs to catch up with that thread 19:58:36 rloo: probably tomorrow. definitely before thursday 19:58:49 devananda: thx. I'd like a couple more changes in. 19:58:51 NobodyCam: no no -- it's really good taht our driver landed. 19:58:59 is there anything we need for tomorrow in the last two minutes 19:58:59 rloo: ok, please highlight them in channel post meeting 19:59:06 devananda: will do 19:59:10 NobodyCam: not that I know of. I think we're set for tomorrow 19:59:26 awesome work EVERYONE!!!!!! 20:00:04 +1 20:00:11 and thats time 20:00:13 thanks everybdy :) 20:00:15 ty 20:00:16 thanks! 20:00:18 great meeting all TY 20:00:18 thanks 20:00:25 cheers, thanks everyone! 20:00:31 thanks 20:00:33 #endmeeting