19:02:48 #startmeeting Ironic 19:02:48 Meeting started Mon Jun 16 19:02:48 2014 UTC and is due to finish in 60 minutes. The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:02:48 \o 19:02:49 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:02:52 The meeting name has been set to 'ironic' 19:02:54 o/ 19:02:57 o/ 19:02:57 hi all! 19:02:58 \o 19:03:01 o/ 19:03:08 o/ 19:03:08 hi devananda 19:03:15 Good morning/evening everyone! 19:03:17 #chair NobodyCam 19:03:18 Current chairs: NobodyCam devananda 19:03:35 as usual, our agenda can be found here 19:03:38 #link https://wiki.openstack.org/wiki/Meetings/Ironic 19:03:53 #topic announcements 19:04:13 I think there's a few announcements to make today 19:04:24 which I didn't add to the agenda -- sorry 19:04:37 devananda: I have one as well when you're done 19:04:39 most notably, we landed a lot of bug fixes last week -- thanks to everyone who helped with reviews ! 19:04:54 and the J1 milestone was tagged on thursday 19:05:25 also, sdague did a lot of work fixing the gate issues, one of which was removign ironic from the integrated gate 19:05:28 \o/ 19:05:40 /o\ \o/ 19:05:46 so we currently have our own gate queue, meaning we can land patches much faster than we could in the last few weeks 19:05:55 :) 19:05:56 so that should help us get some *features* landed in J2 :-D 19:06:04 :) 19:06:13 ok, two more announcements, which are on the wiki 19:06:25 bug tags -- dtantsur had started work on that, and I added several more 19:06:29 and updated the main wiki 19:06:34 Thank you sdague ! 19:06:40 #link https://wiki.openstack.org/wiki/Bug_Tags#Ironic 19:06:54 so when filing or triaging bugs, please try to tag them when there's something appropriate 19:07:17 oh I too have a minor thing 19:07:29 that'll help folks find bugs in areas they are familiar with / want to work on 19:07:32 lastly 19:07:32 o/ (late) 19:07:33 the midcycle 19:07:44 we're confirmed and all that to be colocated with nova 19:08:05 details are here 19:08:06 #link https://wiki.openstack.org/wiki/Sprints/BeavertonJunoSprint 19:08:24 if you are going to attend, please RSVP here: https://www.eventbrite.com/e/openstack-ironic-juno-mid-cycle-developer-meetup-tickets-11886066545 19:08:41 * NobodyCam notes to do that toda 19:08:43 so I can tell the venue how many are coming 19:08:45 today 19:08:59 also, I'd love us to have an agenda 19:09:03 devananda: What about invitations for those who do not live in the US? 19:09:05 anyone want to coordinate that? 19:09:34 #info anyone needing a VISA invitation, please email me directly 19:09:46 #link https://etherpad.openstack.org/p/juno-ironic-sprint 19:09:52 romcheg: ^ I'll see waht I can do, but can't promise anything ... also such things often take a long time 19:10:02 please put the topics to be discussed in the juno mid-cycle sprint on that etherpad ^ 19:10:03 longer than the ~6 weeks until the sprint 19:10:04 devananda: Thanks for the info! 19:10:15 over the weekend I put up https://review.openstack.org/#/c/100063 which Moves check-tripleo-ironic-undercloud-precise from the experimental queue 19:10:18 to the check queue for TripleO and Ironic. 19:10:37 is the mid cycle paid by openstack fundation ? :-) 19:10:37 NobodyCam: please hold off on review discussions until later in the meeting 19:10:41 linggao: no 19:11:10 (-: 19:11:29 we can talk more about the midcycle a bit later too 19:11:39 that's it for my announcements. jroll, you had something quick? 19:11:47 for anybody that happens to be in SF for gigaom structure conference (or otherwise) the SF rackspace office is having a structure after party on thursday night. you're all invited - our team (mostly in this office) has really enjoyed working with y'all :) 19:12:10 that's all :) 19:12:12 jroll: awesome! thanks for sharing 19:12:33 jroll: have a link to more info (like dates)? 19:12:53 this thursday at 5pm 19:13:01 oh, this thursday. heh :) 19:13:03 ok, moving on 19:13:04 I should have one by end of day today, but yes, thursday at 5 19:13:15 #topic release cycle progress reports 19:13:37 as i mentioned, j1 was tagged 19:13:58 #link https://launchpad.net/ironic/juno/juno-1 19:14:05 when will be j2? 19:14:06 62 bug fixes, 0 blueprints 19:14:24 j2 is targeted for july 24 19:14:47 just before the sprint 19:15:05 we are tracking things that we target to J2 here 19:15:07 #link https://launchpad.net/ironic/+milestone/juno-2 19:15:20 at the moment, we have only had one spec approved 19:15:27 lucas' instance-info spec 19:15:35 yes 19:15:46 i think we need to spend some time this week hammering on specs 19:15:52 which we think we can implement by j2 19:15:59 so that they're approved ASAP 19:16:24 so how to make sure one blueprint/feature get into j2? 19:16:26 ^ we definitely need more cores looking at specs, I have two and have seen very little action in the reviews 19:17:02 devananda: there is a separate list of folks that can +2 specs, vs reviews, right? 19:17:11 rloo_: correct 19:17:30 oh? who is on that list? 19:17:47 i thought russell was on it but i could be wrong. 19:17:50 me 19:17:54 me 19:18:15 rloo_: russell_h ? 19:18:16 the lists are separate to allow for different types of contribution 19:18:21 jroll: be nice to those guys ;) 19:18:33 rloo_: https://review.openstack.org/#/admin/groups/352,members 19:18:39 IMHO, not everyone reviewing specs needs to be reviewing code, but they do need to understand the project's issues 19:18:46 anyway 19:18:49 so if a spec is landed does that mean it approved for Juno? 19:18:55 linggao: no 19:19:05 Do specs require 1x+2 or 2x+2? 19:19:08 I have some specs there, but not sure when do I supposed to start write code. 19:19:17 JayF, 2x+2 19:19:18 let me find the link ... 19:19:30 there is a good description of the process we're following in the wiki 19:19:33 also 19:19:40 I saw some patches checked in before the specs got landed. 19:19:48 i am not infinitely scalable :( 19:19:54 devananda: here's that link https://wiki.openstack.org/wiki/Blueprints#Nova 19:20:03 devananda: not true! :P 19:20:21 linggao, yeah, some patches came from old blueprints that were transformed into a spec later (like the management interface one) 19:20:30 jroll: yep, thanks 19:20:47 lucasagomes, also iLO. 19:20:58 yeah 19:21:03 linggao: approving a spec means that the proposal is accepted, but the code/feature may still not be targeted 19:21:04 devananda: could we add 'ironic' to that Blueprints wiki? 19:21:10 lucasagomes, also the whole disk support. 19:21:10 linggao: that is tracked on launchpad 19:21:22 linggao, they weren't landed, were they? 19:21:25 we still have *A LOT* of features proposed without specs 19:21:36 #link https://blueprints.launchpad.net/ironic 19:22:00 that's not a call to write specs for all of them 19:22:05 dtantsur, no. I just want to know when is a code time to *start* write code. 19:22:23 oh, and I'll have a question what to do with bugs like https://bugs.launchpad.net/ironic/+bug/1327187 19:22:24 Launchpad bug 1327187 in ironic "node extra attribute as capability in host states  " [Undecided,Invalid] 19:22:32 linggao: that depends. what's really a question for reviewers is when do we /approve/ the code 19:22:46 linggao: which should be after teh spec is approved and the feature is targeted to a milestone 19:23:04 linggao: I think you're free to write code whenever, but you'd need to be aware that if the spec isn't approved or the direction/design is changed, your code will also have to correspond to those changes. 19:23:07 I understand people start writing some code before BP is targeted, we just should not approve it 19:23:13 rloo_, +1 19:23:36 to be honest, given the number of reviews, I won't even look at a review associated with a blueprint unless the blueprint is approved. 19:23:39 rloo, that's my worry 19:23:43 core reviewers should be getting better at landing code that has a spec approved, and blueprint targetred to current milestone 19:23:46 aside from bug fixes 19:23:59 rloo_: thank you :) 19:24:02 dtantsur: so leave big code changes as WIP until spec approved? Or flag in the review that the spec is awaiting review? 19:24:04 rloo_: you're doing it right :) 19:24:25 rloo_: feel free to -2 code changes that link to blueprints which are not yet approved 19:24:33 devananda: i guess the question is (and was when this new blueprint process came up), is if the specs process will delay things for the developers. 19:24:40 rloo_: yes, it will 19:24:52 mrda, I suggest cores just never +2 it (maybe just +1) 19:24:54 just do not like to write throw-away code. 19:24:55 rloo_: but it should be a huge help to the core review team 19:25:12 is there a need for a 'blueprint spec' review day? 19:25:34 rloo_: we do need to review the specs 19:25:36 rloo_: It's hard to do 19:25:37 problem with a spec review day is that we can't really land following patches 19:25:39 I would be very curious as to the review stats for specs vs. code. I just don't see much movement in review for specs. 19:25:47 I think we need to dedicate a bit more time per day to review it 19:25:51 rloo_: Specs require careful reading 19:25:53 (will do it) 19:26:00 so 19:26:07 all of this is really a call to action for folks to review specs 19:26:16 got it :) 19:26:20 I think we need to land some big features this cycle 19:26:20 +! 19:26:22 +1 19:26:39 and get ironic graduated? 19:26:48 rloo_: right 19:26:58 rloo_: but a few of the feature proposals ARE towards taht end 19:27:01 like the async api 19:27:13 anyway... i'm goign to side track myself soon. 19:27:43 goign to move on lest we spend the whole meeting talkign about specs 19:28:10 #info need more people to review specs, particularly for features that we want to land in j2 or j3 19:28:18 #topic sub team status reports 19:28:30 Shrews, adam_g: hi! any updaets on the tempest work? 19:28:52 the new tempest patches are still in review 19:29:09 biggest news here has been the ironic gate jobs becoming non-voting 19:29:28 question.. is this what we want? or should we be actively trying to get that change reverted? 19:29:58 adam_g: what are adv vs disadvs? 19:30:06 #link http://lists.openstack.org/pipermail/openstack-dev/2014-June/037424.html 19:30:08 adam_g: aiui, you're referring to gate-tempest-dsvm-virtual-ironic being non-voting on ironic itself 19:30:23 devananda, yes, and on DIB 19:30:33 adam_g: i feel quite strongly that our tempest tests should be voting in our gate 19:30:52 devananda: turns out adding new ironic tests to tempest is complicated by the fact that only a single bm node is available for the tests. This means parallel testing will not work (that's not done anyway), and we must add code to make sure the bm node is available for the next ironic test. I've added code for the second part (going through testing now). 19:30:59 yeah, I rely on that test, because that's the only test that actually deploys a vm end to end 19:31:14 rloo_, AFAIU, it allows ironic to land patches quicker and if our job ends up with a rate of failure, it does not affect the main gate queue for other projects (which was the case during the gate fire of the last two weeks) 19:31:25 okay 19:31:32 AIUI, sdague made that change because a) that test was failing often due to network issues, and b) ironic was in the integrated gate 19:31:43 both of which have been addressed, afaik 19:31:46 yeah 19:31:53 adam_g: so those are pros. cons? 19:32:02 rloo_, pros, i suppose. cons are we dont get that test coverage as part of the gate :) 19:32:14 I think we should try to revert that change 19:32:28 the job was actually made non-voting because some fixes had not synced to all devstack slaves. but we appear to be stable again http://no-carrier.net/~adam/openstack/ironic_gate_status.html 19:32:31 Since it won't affect the main gate anymore 19:32:34 Shrews: ah, a cleanup between tempest tests? yep, i think we need that 19:32:52 +1 for making it voting again 19:33:10 adam_g: are there any cons for reverting that change? 19:33:14 okay. i have a patch that should address some of the other structual issues identified with the ironic job. hoping we can get it voting again once that merges, tho it may take some time to prove stability once again 19:33:19 the test is being run, just not voting? 19:33:25 rloo_: correct 19:33:28 is it passing > 90% of the time now? 19:33:33 rloo_: it votes in our check queue and runs in gate, but doesn't vote in gate 19:33:38 devananda: more like a wait for the cleanup to complete 19:33:44 devananda, not that i can tell, its just a matter of convincing others that we are stable. 19:34:12 adam_g: that link seems to only show stats for check queues 19:34:37 devananda, oh, dag. ill fix that after the meeting 19:34:57 NobodyCam: any updates on the tripleo tests? 19:35:06 over the weekend I put up https://review.openstack.org/#/c/100063 which Moves check-tripleo-ironic-undercloud-precise from the experimental queue to the check queue for TripleO and Ironic. 19:35:10 :-p 19:35:36 it will be non voting until it proves it self as working 19:35:39 but it should 19:36:03 sounds good 19:36:09 thanks! 19:36:34 :) 19:36:37 NobodyCam: i think that should remove check-tripleo-ironic-seed now, no? 19:37:01 its still a valid check no? 19:37:13 NobodyCam: it's a subset of the undercloud test 19:37:31 booting the undercloud already include creating the seed vm and all? 19:37:45 if so yeah, sounds good to remove it 19:37:51 NobodyCam: I'm not totally sure. please check with lifeless after the meeting on that, but I think that's what he wants 19:37:54 if undercloud proves it self as working then I will remove seed when switching it to voting 19:38:21 #topic bugs 19:38:25 and check with lifeless too 19:38:25 dtantsur: hi! 19:38:28 hi! 19:38:41 first some numbers about the situation: 2 New bugs; 118 Open bugs; 41 In-progress bugs; 1 Critical bug; 19 High importance bugs 19:38:42 dtantsur: welcome back :) 19:38:48 yeah, thanks :) 19:39:04 I'm going to count differences every week, so that we feel, where we're going 19:39:24 note that we have 41 in-progress bugs, isn't it too much? <-- open question 19:39:48 dtantsur: thanks! that should be very helpful 19:40:03 how many of those 41 are actually in progress? 19:40:28 that's the question :) I've cleaned bugs that are _obviously_ not in progress 19:40:47 the remaining are up to their owners, I guess 19:41:01 in-progress == there's a review associated with it? 19:41:10 rloo_, we're aiming for this 19:41:22 hmm 19:41:25 but actually people need some time before review. and this time can grow and grow... 19:41:40 we're committed to no more than 7 days before patch arrives 19:41:47 (that was 2 weeks ago) 19:41:59 I'll be keeping eye on this 19:42:06 sounds like we need some more reviewing done :) 19:42:20 one thing I'd like to call out is setting proper importance on bugs 19:42:22 #link https://wiki.openstack.org/wiki/Bugs#Importance 19:42:24 dtantsur: sorry, i think you mean that in progress == assigned? 19:42:40 rloo_, to me it's the same 19:42:51 I think folks (myself sometimes as well) are using priority more as an "how soon do we want this fixed" 19:42:54 dtantsur: I don't view it as the same, that's why I wanted clarification ;) 19:43:03 rather than what it means to the rest of openstack -- importance or impact of this bug 19:43:28 there are some low-impact bugs that we may want fixed soon 19:43:38 the way to communicate that via LP is to set the priority "low" but target it to the next milestone 19:43:39 for me "in progress" means we have a responsible one who is moving it. assigned means someone is doing something on it, not just sitting :) 19:43:41 devananda: NobodyCam: the seed job 19:44:00 yes, for now we can replace it with the undercloud one, which means that ironic in the *seed* is being exercised. 19:44:27 we actually want two other things - a) a seed-uc-overcloud job and b) to run tempest against each of the stages 19:44:27 lifeless: awesome ty... 19:44:39 dtantsur: let's see if we can get the # of inprogress bugs to actually reflect # of code reviews fixing bugs 19:45:02 devananda, ok :) 19:45:11 I have 2 more things on agenda... 19:45:12 fwiw, i think it's quite possible we have that many open reviews proposign bug fixes 19:45:37 maybe, I didn't research this numbers quite well 19:46:13 next, launchpad can show some guidelines to one reporting bug. I'm trying to write such guidelines and I need your help: https://etherpad.openstack.org/p/ironic-launchpad-bug-guidelines 19:46:24 at least I suggest asking people for logs 19:46:28 they're often missing 19:46:37 anyone can help me? 19:46:47 dtantsur: I will take a look 19:46:54 thnx! 19:47:13 And one more open question re bugs and specs: what to do with bugs like https://bugs.launchpad.net/ironic/+bug/1327187 19:47:17 Launchpad bug 1327187 in ironic "node extra attribute as capability in host states  " [Undecided,Invalid] 19:47:23 that's actually a non-written spec 19:47:29 dtantsur: IMO you did the right thing there 19:47:50 dtantsur: reject the bug, have them file a spec, exactly as you did 19:47:51 (I've put it into letter to devananda last week, but afaik the letter didn't get to you, right? :( ) 19:47:52 +1 agreed, cause that bug fix might touch many parts of the code 19:48:06 fwiw, I saw a patch recently that had both closes-bug and implements-bp in the commit message 19:48:07 driver code, api for better filtering the capabilities 19:48:20 so I'd say it should go to the spec process 19:48:25 dtantsur: hm, i dont think i saw it :( 19:48:48 devananda, well, nothing interesting except for this question :) 19:49:11 I also suggest triagers to clearly evaluate, whether some bug requires writing a spec 19:49:39 A bit complex case is bugs that are actually requests for specs :) 19:49:55 like https://bugs.launchpad.net/ironic/+bug/1328939 19:49:56 Launchpad bug 1328939 in ironic "Setting instance default_ephemeral_device should be more intelligent" [Low,Triaged] 19:50:00 (10 minute bell) 19:50:13 ty jroll :) 19:50:20 oh, I take too much time :( Well, this is generally all for me 19:50:24 dtantsur: thanks. a good point to bug triagers 19:50:30 moving on 19:50:39 #topic IPA subteam 19:50:46 hi! 19:50:47 jroll, russell_h: hi! 19:50:52 I'll be quick 19:51:00 I've updated our todo list: https://etherpad.openstack.org/p/ipa-todos 19:51:09 there's some new specs linked in there 19:51:21 I've outlined the current patch chain 19:51:28 and what needs to be split from 84795 19:51:53 jroll: fantastic 19:51:56 please please please review our specs and the patches we're depending on :) 19:52:00 jroll, how are chances to get everything done in Juno? 19:52:12 dtantsur: that's my primary goal in life right now :) 19:52:25 (that might be exaggerating a bit :P ) 19:52:25 jroll, great! Anything I can help in addition to reviews? 19:52:36 nope! reviews are where we're most limited 19:52:37 my rough thoughts as of right now ... 19:52:39 we're very interested in auto-discovery here 19:52:48 for the instance_info stuff we are still blocked by a tempest test 19:52:54 dtantsur: as are we :) 19:52:56 I see the patch as part of the IPA chain there 19:53:01 getting more eyes on your specs will be really helpful over the next month 19:53:08 and landing the common dependencies 19:53:10 like instance info 19:53:11 #link https://review.openstack.org/#/c/95789/ 19:53:18 dtantsur: we should talk more about what that actually means, but our main goal right now is for feature parity with the pxe driver 19:53:59 dtantsur: after that lands, we'll be working on better features :) (like the things listed to be split from 84795) 19:53:59 I think we should be able to easily achieve that refactoring and landing common code before the midcycle 19:54:08 ^ 19:54:10 I fully agree 19:54:12 jroll, yeah, that's obvious :) I wonder if we can get a bit further during Juno and get nodes discovery 19:54:27 human time would be the only reason we dont land the spec by then. from what i've sen it's coming along really well (need to review this week again) 19:54:54 jroll: do you think you guys will have enough done by the midcycle that others can insatll and test locally? 19:55:04 eg, some docs, devstack integration, etc 19:55:06 dtantsur: I hope that everything in that etherpad will be done for juno, plus decom 19:55:20 devananda: I hope so 19:55:37 jroll: ok. i think that will have an impact on what we can do for IPA at the midcycle 19:55:37 devananda: dwalleck_ has been working on devstack/tempest integration lately, that's a large part of that work 19:55:45 devananda: and then docs 19:55:53 I expect it to be doable 19:56:03 if others can play with it easily (myself included) by then, I think we'll have a good shot at landing in j3 19:56:11 jroll, btw are you planning getting rid of docker? 19:56:17 devananda: indeed 19:56:22 (was discussed some time ago, but I forgot) 19:56:25 dtantsur: we no longer run in docker, it's only a build step 19:56:34 as soon as it lands, are we moving to have IPA as the default deploy mechanism? 19:56:37 jroll: ^^ glad to hear that :) 19:56:40 dtantsur: patches for alternate build systems (DIB) welcome :) 19:56:55 dtantsur: I think that at Rackspace, our prefered way of running it will continue to be inside a container under CoreOS. I am willing to help and review patches to add DIB elements 19:56:55 lucasagomes: let's talka bout that post-meeting 19:57:00 devananda, ack 19:57:07 lucasagomes: my hope is juno or K1 :) 19:57:09 3 minute bell, moving on 19:57:11 jroll, JayF, I see :) 19:57:11 3 minutes 19:57:15 #topic Oslo 19:57:17 jroll, sure 19:57:18 GheRivero: any news here? 19:57:20 oslo.db finally has a alpha release! The oslo.db review has been updated but is not functional yet (openstack pypi mirror not updated yet) 19:57:23 But what it's really important to us are the alembic/opportunistic migrations tests. 19:57:26 There are a couple of reviews (99965 and 93424) to address that. 19:57:29 Once they land, there will be another oslo.db release (I hope), so we can fully start testing ironic within oslo.db (but there is no rush in that now) 19:57:32 That's all 19:57:34 :) 19:57:35 thanks!! 19:57:46 #topic nova db migration 19:57:52 romcheg: hi! 19:57:54 Hi! 19:58:29 romcheg: any news? 19:58:30 So I have installed nova and Ironic on my lab and tested what changed in both DBs 19:58:54 I managed to update the migration scripts and will post that tomorrow 19:59:06 So I have two questions and will try to be quick 19:59:20 Does this feature require a spec? 19:59:43 it's covered by my spec in nova 19:59:44 https://review.openstack.org/#/c/95025/ 19:59:49 Ah, great 20:00:06 Is there anyone who wants to volunteer on making the research of how to test these migrations? 20:00:20 That is another big topic 20:00:29 yea, will require grenade tests 20:00:35 beep (time bell) 20:00:49 sdague had volunteered at the summit to give some guidance, burt we'll need someone to work on that 20:01:06 #info need a volunteer to help with grenade testing of nova-bm -> ironic db migration code 20:01:13 thanks all! we're out of time 20:01:15 perhaps we should find a nova-baremetal user for that :P 20:01:19 thank you all 20:01:20 #endmeeting