17:01:26 #startmeeting ironic 17:01:27 Meeting started Mon Mar 7 17:01:26 2016 UTC and is due to finish in 60 minutes. The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:28 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:29 o/ 17:01:30 o/ 17:01:30 The meeting name has been set to 'ironic' 17:01:33 o/ 17:01:36 <[1]rpioso> o/ 17:01:38 o/ 17:01:41 hi 17:01:57 hi folks, sorry for starting a minute late 17:02:01 o/ 17:02:08 #chair NobodyCam 17:02:08 Current chairs: NobodyCam devananda 17:02:12 o/ 17:02:27 o/ 17:02:29 as usual, the agenda can be found here: https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting 17:02:54 also, I'm standing in for jroll today while he is gone for a few days 17:03:04 o/ 17:03:10 #topic Announcements 17:03:19 :) o/ 17:03:27 o/ 17:03:39 only thing he left on my radar, announcement wise, is the reminder about the upcoming release 17:04:30 library and client releases for Mitaka are behind us now, and I believe jroll plans to do a server release once he's back (end of this week) 17:05:00 ditto for inspector, end of this week or beginning of the next.. 17:05:12 depending on how we finish the leftovers 17:05:19 dtantsur: cool, thanks 17:05:25 devananda: apart from RAID, is there anything else that we wanted in this upcoming release? 17:05:35 there are still a pile of patches for the neutron integration work that we had hoped would land 17:05:45 there are the network stuff that is not merged yet 17:05:55 (what deva said) 17:05:57 the API patches for that got delayed as jroll refactored driver loading to make it into a network driver 17:06:03 yeah, network stuff would be awesome to finish 17:06:17 devananda, and agent drivers support for partition images 17:06:20 this is the main new patch there: https://review.openstack.org/#/c/285852/ 17:06:44 hmm, someone problems has to overtake it 17:06:50 devananda: but 285852 is a WIP? 17:06:51 s/problems/probably/ 17:07:01 jroll left that for me to pick up this week 17:07:22 oh, great, thanks devananda :) 17:07:26 so unless someone else has a strong desire, I'll pick that up and work on it today 17:08:03 anyone else have announcements, or shall we move on? 17:08:08 I have a quick one 17:08:24 the devstack-gate patch enabling drivers other than {pxe, agent}_ssh to run on gate is now merged. Now the ipmitool jobs are running in the gate 17:08:25 o/ 17:08:33 woot! 17:08:36 pxe_ipmitool is passing, agent_ipmitool is failing because we need a small change in devstack ( https://review.openstack.org/#/c/287698/ ) to set the default image to agent_ipmitool to a full disk one. Right now agent_ssh is hardcoded there, so it only do it for that driver 17:08:50 that's it :-) 17:08:56 awesome !! 17:09:12 thx lucasagomes. Great news! 17:09:12 #info library and client releases done last week 17:09:24 #info ironic and ironic inspector server releases expected by EOW (or early next week) 17:09:40 #info devstack-gate now supports allowing ironic testing with ipmitool driver 17:09:51 devananda, does IPA also has some release cycle? 17:09:57 devananda, do I get it right that then on the RC week we do one more release of services, and make stable/mitaka out of it? 17:10:06 #info networking integration work still in progress, pending driver-loading refactoring 17:10:07 Nisha_away, good catch. we need to release it soonish 17:10:27 dtantsur, agent drivers partition image support requires a patch in IPA too 17:10:50 dtantsur: I believe that is the plan, ye 17:10:50 so was just wondering when is that planned 17:11:07 Nisha_away: if jroll has plans for an IPA release, I'm not currently tracking that 17:11:25 Nisha_away, we're approaching the feature freeze, so I don't think this large feature has a big chance of getting in.. 17:11:47 dtantsur, these are small patches 17:11:51 already in review 17:12:00 well, we'll see 17:12:04 ironic-lib already released with fix for it 17:12:04 let's move on and discuss that more in the open discussion section 17:12:11 devananda, sure 17:12:12 which I think we'll get to quickly today 17:12:12 +1 17:12:21 #topic subteam status report 17:12:46 note that I've removed the "futurist" section. and that's because the change has landed in both ironic and inspector \o/ 17:12:56 dtantsur: nic! 17:12:57 nice! 17:13:03 are we done with the manual cleaning? should we remove it too? 17:13:07 \o/ 17:13:56 dtantsur: i think we can remove manual cleaning. there is just one thing left, the API to get the avail clean steps. that won't happen in Mitaka. 17:14:11 devananda, I still remember your idea about splitting periodic tasks to separate processes.. might be an interesting thing to start thinking of 17:14:20 dtantsur, yeah AFAIK it's done 17:14:26 ok, removing 17:14:36 dtantsur: ++ for that in Newton 17:16:04 dtantsur: TheJulia: I was playing with bifrost + inspector a lot last week, and it seems like that is poorly supported right now, and not working 17:16:13 :( 17:16:14 ugh 17:16:19 dtantsur: for inspector, didn't you just mention that there will be an upcoming release? 17:16:30 rloo, yep. or even 2 of them 17:16:52 dtantsur: 2 this week? was going to update the subteam status report 17:17:13 dtantsur: thx for updating :) 17:17:42 rloo, we need a release around this week, then another one on the RC week; ditto for ironic 17:17:52 (if I get the release process right ofc) 17:18:07 dtantsur: yeah, that sounds about right 17:18:48 dtantsur: yep 17:19:29 devananda: specific bugs would be useful, but firing that up right now to take a look 17:21:32 TheJulia: I'm unclear as to what should work as there wasnt a lot of documentation on that, but yea, let's chat more this week 17:21:40 and i'll file bugs as I figure out what ya'll expect :) 17:21:57 absolutely :) 17:22:10 giving folks another minute with updates, then we'll move on 17:23:13 I don't have any specs to discuss in the next section today -- been focused on other things, and will resume spec reviews after M3 17:23:26 #topic stuck specs 17:23:51 #info I've been focused on other things, and will resume spec reviews after M3 17:24:26 there's one topic on the agenda, but jroll asked it to wait until he's back 17:24:54 #topic open discussion 17:25:02 kind-of-an-update: we didn't convince tripleo to create a stable branch for DIB.. 17:25:10 dtantsur, :-( 17:25:17 so we might want to wait until kilo eol, then just drop the old ramdisk.. 17:25:28 (at least that's what we discussed with jroll) 17:25:53 dtantsur: IIRC, they agreed to test DIB/master against ironic stable/XX 17:25:58 yeah, it's already marked as deprecated so I think we are fine 17:26:00 wanted to remind folks that Daylight saving time it next sunday here in the US 17:26:01 is there anyone working with jroll in the "add network drivers" patch? 17:26:02 just will take longer 17:26:13 devananda, that's barely possible due to requirements.. 17:26:20 but is worth investigating 17:26:29 thiagop: I am. do you want to get involved there? 17:27:07 devananda: I was looking into the code, but a little confused about what is lacking. If you show me the path I can help 17:27:22 #info DST ends in the US this week 17:27:33 :) 17:28:12 UK DST time isn't until March 27, thats going to be confusing... 17:28:39 sambetts: yea. the meeting time may apear to change by an hour for some folks while DST settles in different countries 17:29:45 I thought the meeting time was on UTC? 17:30:02 it i 17:30:03 it is 17:30:44 mgould, it is... but since we are on UTC+0 it just matches with out current time 17:30:50 our* 17:31:00 yep 17:31:06 until the clocks change and then we're an hour off 17:31:06 which is very handy btw 17:31:11 yeah 17:31:12 mgould: for example, on the US West Coast, the meeting time this week is 9am. next week it is 10am 17:31:39 sure, it was the "may appear to change... while DST settles in" that confused me 17:31:49 the local meeting time will change until DST ends 17:31:56 which is months away 17:32:24 mgould: sorry for the confusion. I meant that as a caution against merely assuming that the time changes in your local time, because different countries implement DST at different times. 17:32:32 OK, gotcha 17:33:52 are we good with the microversion header change being proposed? 17:34:00 http://lists.openstack.org/pipermail/openstack-dev/2016-March/087928.html 17:34:05 * devananda reads 17:34:36 would it be OpenStack-API-Version: baremetal xyz 17:34:47 rloo, yup 17:34:56 we will keep both for backward compat 17:35:10 they're also removing Min- and Max- headers 17:35:13 dunno if we like it 17:35:32 dtantsur, this is just for the client to request the version 17:35:38 min/max are in the server right? 17:35:55 we will keep it because we already use it 17:35:55 dtantsur: OH, didn't know that. how do we handle backward compat for that if it is removed? 17:36:01 lucasagomes: are we the only service which sends min/max in replies today? 17:36:10 rloo, we don't remove :) but it's not on the guideline 17:36:14 devananda, I believe nova does too, lemme check 17:36:23 we copied everything from nova 17:36:37 rloo, we will keep what we have so we don't break existing users 17:36:41 and tools 17:36:41 actually inspector also sends them, but inspector works differently with versions in other regards 17:36:43 dtantsur: I copied the idea of how they implemented it, but we implemented it quite differently 17:36:51 oh, I didn't know it 17:37:02 I thought we're doing a pretty close thing 17:38:02 * rloo wonders if we should have a subteam cross-project report 17:38:26 we should have had it before we jumped into implementing microversions ;) 17:38:28 * dtantsur ducks 17:38:47 I meant, agreeing on the things like that 17:38:47 dtantsur: agreed. We should have got you to spearhead it :) 17:39:06 * dtantsur is tired and skips parts of sentences 17:39:28 yeah, it was a bit rushed indeed 17:39:50 but maybe at the time we didn't know it would become an OS thingy. Nova was the only one implementing it AFAIR 17:40:45 lucasagomes: we needed something at the time, to handle the change in states. it made sense at the time to leverage what nova did. 17:40:46 devananda, so, looking here. I was mistaken, I think nova do not return min/max headers 17:40:54 rloo, yeah 17:41:05 in any case, now that more projects are starting to support it, and there is cross-project needs to standardize on the approach 17:41:17 I think we will need to add that to our API 17:41:20 the cross-project stuff (almost all? all?) emerge when similar 'patterns' are done across 2 or more projects and someone notices/brings it up. 17:41:25 and maintain compat with what we already released 17:41:26 devananda, ++ 17:41:35 yep 17:41:49 it's a very common pattern, as rloo just pointed out 17:42:02 rloo, agreed 17:42:09 that we did it early isn't bad -- it's helped us, and helped openstack figure out what works 17:42:20 so I don't think we should be hard on ourselves cuz it was 'rushed'. 17:42:38 like devananda said :) 17:42:56 trying to force a concensus across projects before anyone has implemented it is a recipe for stress and stalled progress (we've seen this many times before) 17:43:32 but if we need something not covered in that proposal (like min/max values in the return headers) we need to speak up now 17:44:39 worst case we can query the api for min / max supported versions 17:44:53 ? 17:45:46 NobodyCam: yes. querying the root resource "/" should return the versions in the HTTP BODY 17:46:11 that would require a change in our clients' error handling, but I don't think that would take much work 17:46:48 I seem to remember we discussed it before 17:47:22 devananda, but I don't think we are going to change it in Ironic right? We can keep the headers 17:47:29 rloo: thanks for bringing this up. I don't see any problem with the proposal 17:47:42 thx devananda 17:48:05 lucasagomes: we'll have to keep X-OpenStack-Ironic-API* headers around for compat with current/older clients 17:48:14 yeah 17:49:37 any other topics for open discussion? 17:49:59 I'm happy to give folks back 10 minutes, since it seems like we've wound down early 17:50:08 :) 17:50:42 ... ok! thanks everyone! 17:50:44 thank you all ... 17:50:47 #endmeeting