17:00:20 <lucasagomes> #startmeeting ironic
17:00:21 <openstack> Meeting started Mon Sep 19 17:00:20 2016 UTC and is due to finish in 60 minutes.  The chair is lucasagomes. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:25 <openstack> The meeting name has been set to 'ironic'
17:00:27 <mgould> o/
17:00:31 <lucasagomes> who's here for the meeting ?
17:00:32 <rpioso> o/
17:00:37 <jlvillal> \Oi!/
17:00:56 <mat128> o/
17:01:13 <rloo> o/
17:01:13 <vdrok> o/
17:01:16 <stendulker> o/
17:01:22 <lucasagomes> Welcome all
17:01:27 <lucasagomes> #topic Announcements / Reminders
17:02:02 <lucasagomes> the only annoucement that I have this week is that jroll is planning to release ironic, IPA, inspector and bifrost this week
17:02:06 <lucasagomes> anyone has anything else ?
17:02:28 <rloo> lucasagomes: we got the 4 Fishbowl and 4 other rooms i think. in the summit
17:02:40 <jlvillal> Vote for PTL?
17:02:49 <lucasagomes> rloo, a-ha cool I didn't know we already decided thanks
17:02:51 <lucasagomes> jlvillal, ++
17:03:13 <lucasagomes> so the PTL elections are opened, if you contributed with Ironic in the last cycle (and the one before I think) you will have a link in your email
17:03:17 <lucasagomes> please vote :-)
17:03:22 <vdrok> yup, and contributor meetup
17:03:41 <lucasagomes> vdrok, cool, that's on friday afternoon ?
17:03:42 <rloo> lucasagomes et al: http://lists.openstack.org/pipermail/openstack-dev/2016-September/103560.html
17:03:48 <vdrok> lucasagomes: yup
17:03:51 <lucasagomes> #link http://lists.openstack.org/pipermail/openstack-dev/2016-September/103560.html
17:03:55 <pas-ha> o/
17:04:06 <lucasagomes> rloo, great!
17:04:49 <lucasagomes> ok I think that's all for announcements, let's move on
17:04:51 <lucasagomes> #topic subteam status updates
17:04:56 <rloo> thx to all for bug smash!
17:05:07 <lucasagomes> oh yeah, that was a success :-)
17:05:09 <lucasagomes> #link https://etherpad.openstack.org/p/IronicWhiteBoard
17:05:19 <lucasagomes> everyone can take a moment to review those
17:05:30 <lucasagomes> ^
17:05:42 <lucasagomes> starts at L78
17:05:55 <rloo> I took a look at the HIGH bugs after the bug smash. I didn't see any (except for one that was fixed) that was urgent for newton. Anyone else think otherwise?
17:06:36 <lucasagomes> #link https://etherpad.openstack.org/p/ironic-bug-smash
17:06:45 <lucasagomes> this is the etherpad with the bugs we looked at the bug smash session btw
17:07:02 <rloo> lucasagomes: that reminds me; there are a few bugs that needed discussion?
17:07:22 <lucasagomes> rloo, yes we currently have 3 bugs listed
17:07:49 <lucasagomes> rloo, maybe we can discuss those in the open session for this meeting ?
17:07:56 <lucasagomes> tho we are missing some people today
17:08:10 <rloo> lucasagomes: we can look/discuss if we have time later :)
17:08:16 <lucasagomes> rloo, ++
17:08:29 <lucasagomes> rloo, the agent is very light so, I guess we will do
17:08:45 <lucasagomes> s/do//
17:08:58 <mat128> s/agent/agenda ?
17:09:01 <rloo> last week, devananda had mentioned something not being tested wrt the keystone policy support. does anyone know more about that? is there a patch to review?
17:09:17 <lucasagomes> mat128, https://wiki.openstack.org/wiki/Meetings/Ironic
17:09:22 <jroll> there's a test deva wanted but it isnt working yet
17:09:31 <jroll> on mobile, don't have a link
17:09:32 <mat128> "the agent is very light"
17:09:33 <mat128> nvm
17:09:45 <jroll> rloo ^
17:10:04 <lucasagomes> mat128, my bad...
17:10:06 <jroll> basically the test ensures all api calls have the policy enforcement
17:10:13 <vdrok> jroll: https://review.openstack.org/350177 ?
17:10:24 <rloo> jroll: ok. so we are good to release ironic w/o that test?
17:10:36 <lucasagomes> #link https://review.openstack.org/#/c/350177/
17:10:37 <jroll> probably fine rloo
17:10:43 <lucasagomes> that's the link for devananda's patch ^
17:11:04 <rloo> the only other thing i remember that we wanted (maybe) in newton is notifications. i don't know if the power state notifications will make it, needs more work still.
17:11:25 <rloo> other than those, is there *anything* we are waiting on, before a newton release?
17:11:45 <gabriel-bezerra> well..
17:11:50 <gabriel-bezerra> drivers considered here?
17:12:03 <rloo> gabriel-bezerra: no, not considering drivers. HI priority stuff.
17:12:07 <gabriel-bezerra> ok
17:12:18 <lucasagomes> gabriel-bezerra, well unless it's hi priority but I don't think we have any for specific drivers
17:12:18 <lucasagomes> yeah
17:12:34 <jroll> rloo, I'd like to get some of the install guide move done if we can, else we will need to backport it
17:12:44 <lucasagomes> that said, ocata will be open very soon
17:12:48 <gabriel-bezerra> we have inband inspection for oneview drivers. I believe we got a +2 from crhis
17:12:50 <rloo> jroll: OH. yeah, that makes sense. will look at it today/tomorrow.
17:12:50 <jroll> but easy to backport so not a big deal
17:12:51 <lucasagomes> jroll, do we have a date already for ocata ?
17:13:00 <vdrok> maybe this, I'll fix it tomorrow, but it depends on devstack-gate patch https://review.openstack.org/#/c/329625/9
17:13:03 <mat128> jroll, rloo: #link https://review.openstack.org/#/q/topic:bug/1612278
17:13:09 <jroll> lucasagomes: after we release, my goal is this week
17:13:15 <lucasagomes> ack
17:13:21 <gabriel-bezerra> lucasagomes, rloo: that's our main point for newton.
17:13:38 <stendulker> lucasagomes: there are few REF needs code review for iLO drivers
17:13:50 <rloo> stendulker: rfe's?
17:14:07 <stendulker> rloo: yes, no-spec ones
17:14:23 <jroll> pretty late for any features
17:14:29 <lucasagomes> stendulker, right, yeah those will be probably be reviewed after the release this week
17:14:56 * jroll would like to make a point to get some lagging driver things done in ocata
17:15:07 <rloo> jroll: ++
17:15:14 <stendulker> lucasagomes: also config drive pieces left...
17:15:27 <stendulker> have a +2 from John
17:15:38 <lucasagomes> stendulker, hmm that's configdrive for whole disk image + iscsi ?
17:15:45 <stendulker> lucasagomes: yes
17:15:48 <gabriel-bezerra> what is the policy regarding bugfixes after the release of this week?
17:15:49 <NobodyCam> ++
17:16:01 <rloo> gabriel-bezerra: please fix?
17:16:13 <jroll> gabriel-bezerra: typical backport policy
17:16:13 <lucasagomes> that's actually a good thing to fix, I will take a look after the meeting stendulker
17:16:15 <rloo> gabriel-bezerra: or do you mean, can they be backported to newton.
17:16:26 <stendulker> lucasagomes: thank you
17:16:32 <jroll> lucasagomes: ++
17:16:37 <gabriel-bezerra> yes, it is about porting to newton
17:17:01 <rloo> gabriel-bezerra: yeah, can be backported according to policy. anyone have that link?
17:17:02 <lucasagomes> gabriel-bezerra, http://docs.openstack.org/project-team-guide/stable-branches.html
17:17:15 <lucasagomes> that guide list what is acceptable to be backported and what is not
17:17:20 <gabriel-bezerra> thank you
17:17:26 <lucasagomes> #link http://docs.openstack.org/project-team-guide/stable-branches.html
17:18:14 <lucasagomes> cool, should we move on ?
17:18:24 <rloo> + move on
17:18:34 <lucasagomes> #topic Open Discussion
17:19:02 <lucasagomes> anything? rloo maybe we can take a look at those bugs ?
17:19:07 * jroll has nothing
17:19:32 <jroll> oh, don't forget to submit summit session things :)
17:19:42 <mat128> you guys had questions during the bug smash session re https://bugs.launchpad.net/ironic/+bug/1567629
17:19:44 <openstack> Launchpad bug 1567629 in Ironic "[RFE] Nova graphical console support" [Wishlist,In progress] - Assigned to Mathieu Mitchell (mat128)
17:19:45 <lucasagomes> ah also, today I've deployed a image on a VM +UEFI + iPXE on fedora 24. I will soon try to make it work on ubuntu 16.04
17:19:53 <lucasagomes> do we want forsee having a UEFI test in gate ?
17:20:00 <lucasagomes> I think it would be a good addition
17:20:00 <gabriel-bezerra> news on oneview ci: we have made good progress in getting it back up. some configuration issues are showing up.
17:20:12 <rloo> gabriel-bezerra: good news
17:20:14 <jroll> lucasagomes: I would love one :)
17:20:21 <jroll> gabriel-bezerra: awesome
17:20:24 <rloo> lucasagomes: seems like a good idea to me. unless it takes hours to test :)
17:20:34 <gabriel-bezerra> :)
17:20:58 <lucasagomes> rloo, should be the same, you just need to install some extra packages (uefi firmware) and add some tags in the libvirt XML thing
17:21:14 <lucasagomes> rloo, but yeah, should be the same as testing BIOS
17:21:21 <rloo> lucasagomes: that'd be great!
17:21:33 <mgould> lucasagomes++
17:21:36 <lucasagomes> if it works in ubuntu :-) I dunno yet
17:21:42 <mgould> and +1 to testing UEFI in CI
17:21:56 <jroll> lucasagomes: would be cool to just add it to a job if we can, rather than a new job
17:22:22 <lucasagomes> jroll, indeed, we can change one of the pxe_ipmitool jobs actually because would be good to test with a partition image
17:22:34 <jroll> yeah
17:22:38 <lucasagomes> to see if the ESP partition (the efi partition) was created successfully and all that
17:23:49 <lucasagomes> mat128, hmm not that I remember, it was an async session to be honest
17:24:04 <gabriel-bezerra> btw, should we be moving the ci jobs to xenial?
17:24:18 <lucasagomes> so people were looking at different bugs at the same time, i don't recall talking deeply about the nova console support
17:24:19 <mat128> lucasagomes: ok no problem :) I am author/assignee of the bug but couldnt attend the bug smash session
17:24:26 <jroll> gabriel-bezerra: infra is mostly doing that work with our help as needed
17:24:33 <vdrok> as for allowing ~ in the patch keys, if the rfc states it, why not allow it in ironic?
17:24:52 <lucasagomes> mat128, I see the tag needs-spec was added to that RFE, do you agree with it ?
17:25:07 <mat128> yup, it does need a spec
17:25:09 <rloo> mat128: I just looked at that. the notes say 'probably needs a summit session'
17:25:16 <jroll> vdrok: +1
17:25:25 * mat128 wont be at the summit, but yeah, needs a discussion at least
17:25:31 <gabriel-bezerra> jroll: thks. so no urgency for 3rd party ci moving to that before ocata starts, right?
17:25:35 <lucasagomes> mat128, oh :-(
17:25:49 <rloo> mat128: too bad. then we should move discussions etc to the spec proposal.
17:26:13 <mat128> yeah, that would work best for me
17:26:33 <jroll> gabriel-bezerra: yeah nbd right now, lets do it in ocata
17:26:44 <gabriel-bezerra> thanks
17:26:53 <vdrok> lucasagomes: what's the plan on releasing ironic-staging-drivers ?
17:27:00 <vdrok> this week too?
17:27:01 * jlvillal wonders if we can get mat128 access to that little robot thing that displays his face on a screen and he can show up for the meeting :)
17:27:10 <mat128> sure :)
17:27:14 <lucasagomes> vdrok, I've released it recently, I don't think we actually added anything else since
17:27:26 <lucasagomes> vdrok, I still have to look at the ansible driver, I'm sorry for that I didn't have the time
17:27:52 <mat128> My wife will be 38 weeks pregnant during the summit, no way I'm flying to another continent
17:27:53 <vdrok> lucasagomes: yeah, that's what pas-ha eagerly wants :)
17:27:53 <mat128> :)
17:27:58 <jroll> gotta drop, thanks for running this lucasagomes
17:28:02 <lucasagomes> vdrok, that said, ironic-staging-driver have an independent release, what about releasing it once we get that drver in ?
17:28:11 <pas-ha> lucasagomes: ++
17:28:12 <lucasagomes> jroll, see ya later in the channel
17:28:23 <vdrok> lucasagomes: yup, that works of course, thanks
17:28:52 <lucasagomes> mat128, congratulations in advance :-)
17:29:09 <mat128> lucasagomes: thank you :)
17:29:30 <mgould> mat128: congratulations!
17:29:41 <rloo> congrats in advance mat128!
17:29:53 <gabriel-bezerra> congrats, mat128!
17:29:56 <mat128> oh wow, thanks everyone :)
17:30:01 <lucasagomes> :D
17:30:08 <vdrok> mat128: yeah, that's a valid reason to skip :D
17:30:26 <rloo> vdrok: i don't have an opinion on ~ or / (wrt https://bugs.launchpad.net/ironic/+bug/1604148)
17:30:27 <openstack> Launchpad bug 1604148 in Ironic "Cannot patch keys that contain ~ or /" [Low,In progress] - Assigned to Brad Morgan (morgabra)
17:30:56 <vdrok> rloo: well, me too, but we state in api-ref that we comply to this rfc
17:31:08 <vdrok> so I think we'd better to fully comply :)
17:31:40 <vdrok> or that's another one, lemme look
17:31:49 <rloo> vdrok: i didn't know that we said we complied with that rfc.
17:31:55 <lucasagomes> vdrok, ++ yeah we still lack some operatorions (e.g move) to fully comply to that rfc
17:32:05 <lucasagomes> but would be good to don't diverge much from it
17:32:20 <mat128> can't find any mention of RFC on http://developer.openstack.org/api-ref/baremetal/index.html
17:32:26 <mat128> but that doesnt mean we never claimed supporting it
17:32:26 <rloo> well, i don't see this as a 'diverge' but as a restriction to.
17:32:37 * mgould also has to skip out: good night, everyone!
17:32:38 <lucasagomes> I don't see a strong reason also to support ~ and / to be honest, would be good to have a real example
17:32:38 <vdrok> aha The BODY of the PATCH request must be a JSON PATCH document, adhering to RFC 6902.
17:32:45 <vdrok> that's not 6901
17:33:21 <mat128> RFC 6902 mentions ~0 and ~1
17:33:49 <vdrok> mat128: yeah ++
17:34:00 <rloo> i guess the only reason for supporting that, is if some driver/capability needed it as a key?
17:34:06 <vdrok> section 4
17:34:19 <rloo> or extra/property?
17:34:35 <rloo> we would never add an attribute with ~ or /
17:35:04 <rloo> is the problem just with keys, or with values too?
17:35:07 <mat128> rloo: I guess you can have them in custom properties, or driver info
17:35:24 <lucasagomes> rloo, I haven't tried, seems to be key only (at least for "/")
17:35:29 <mat128> Makes me think, this probably triggers a bug with some of the properties stuff we do
17:35:39 <vdrok> rloo: just for the path
17:35:57 <vdrok> so yes, the key
17:36:45 <vdrok> well, looking at the patch, it's one character change https://review.openstack.org/#/c/343911/2/ironic/api/controllers/v1/types.py
17:37:07 <mat128> vdrok: that patch addresses ~ only, I think
17:37:12 <mat128> Oh
17:37:14 <rloo> i can't think of a reason to *not* allow it. unless we do something funky with the key strings.
17:37:24 <vdrok> mat128: I think ~0 == / and ~1  == ~
17:37:26 <mat128> yes
17:37:28 <rloo> i don't really care about how to fix it. the question was whether to actually support it.
17:37:32 <mat128> thats the 5 second delay :)
17:37:46 <rloo> so no one has said NO to supporting it. So we can leave it as a valid bug. right?
17:37:50 <mat128> I think we should support them because "The BODY of the PATCH request must be a JSON PATCH document, adhering to RFC 6902."
17:37:54 <mat128> rloo: +1
17:38:05 <jroll> lucasagomes: we have keys with / downstream
17:38:17 <jroll> old legacy junk, but it's there
17:38:19 <rloo> mat128: please add your comment to the bug.
17:38:24 <mat128> done already :)
17:38:26 <rloo> jroll: you too :)
17:38:28 <lucasagomes> rloo, one reason for "/" is the python-ironicclient maybe, node-update <node uuid> add properties/capabilities= for example
17:38:38 <jroll> rloo: it's my downstream teammate that filed it :P
17:38:40 <mat128> lucasagomes: thats a path
17:38:44 <rloo> jroll: ha ha
17:38:58 <lucasagomes> jroll, urgh hah ack
17:39:03 <rloo> jroll: would have helped if they had said they had a usecase for i!
17:39:18 <lucasagomes> ok so, apparently we do have a real use case here
17:39:22 <vdrok> yeah, client should be updated too I think, unless it supports ~ already
17:39:22 <mat128> rloo: that was hinted by the "what should one do if they already have that in the database?"
17:39:31 <jroll> idk, presumably people file bugs because their usage is broken :/
17:39:37 <rloo> mat128: that could be a hypothetical question :)
17:40:00 <mat128> rloo: I read it that way initially, but found it was from Brad
17:40:10 <jlvillal> Is the patch author still working on it?
17:40:17 <rloo> moving along, here's the next one: https://bugs.launchpad.net/ironic/+bug/1427923
17:40:19 <openstack> Launchpad bug 1427923 in Ironic "boot device API blocks while waiting on the BMC" [Medium,Confirmed] - Assigned to bin Yu (froyo-bin)
17:40:54 <lucasagomes> jlvillal, it's been 9 weeks since the patch was updated, but maybe he's waiting for it to be discussed/approved in the bug
17:41:05 <jroll> jlvillal: I'm in person with him this week, I can make him keep working on it :D
17:41:13 <jlvillal> Thanks :)
17:41:33 * jroll locks up the beer until that patch is done
17:41:50 <mat128> "New commit from Morgan"
17:42:38 <lucasagomes> rloo, one thing is, if we change that return code we need to bump the api version
17:42:49 <rloo> mat128: i did read brad's three points; his last one about getting these ~/ keys into the db is interesting.
17:42:51 <lucasagomes> rloo, but I tend to agree that we should never have a sync call that talks to the bmc
17:43:07 <rloo> lucasagomes: no problem bumping api version. is there?
17:43:16 <mat128> rloo: presumably he's running with that patch downstream
17:43:26 <jlvillal> Agree with that being a bug. Async is the way to go I would think. (Re: BMC issue).  If we did move on....
17:43:32 <jroll> mat128: nope :/
17:43:35 <mat128> ah
17:43:38 <lucasagomes> rloo, no, just pointing that as part of fixing that bumping it is a must
17:43:47 <rloo> jlvillal: i move on and i move back, all at the same time :)
17:43:56 <rloo> lucasagomes: right.
17:44:19 <lucasagomes> rloo, the problem I see with making that async is how the user will actually know that the boot device was set correctly
17:44:34 <lucasagomes> rloo, perhaps the same target_* fields that we use for power/provision
17:44:41 <mat128> ^ I was concerned too
17:44:43 <mat128> oh
17:44:45 <lucasagomes> (+ notifications when we get to that)
17:45:22 <mat128> lucasagomes: I would +1 a target_boot_device
17:45:25 <rloo> so dmitry suggests async in conductor, sync in api.
17:45:45 <mat128> rloo: you're still going to wait for the BMC when doing that call
17:45:48 <rloo> we tend to do async for most things, so i think we should follow a similar async pattern for this. that would be consistent.
17:46:07 <rloo> mat128: right, yes, the api sync would be waiting...
17:46:21 <rloo> mat128: i'm not sure we want to do that, api sync i mean. cuz we don't do that for other things.
17:46:32 <mat128> rloo: additionally, your driver would have to loop for the call to be done prior to restarting the machine
17:46:34 <rloo> mat128: but we do that at the client level. eg the --wait
17:47:06 <lucasagomes> I have to think about it, but yeah, I think the deva's main concern is actually the API being sync (and blocking the user waiting for the bmc)
17:47:17 <lucasagomes> that said, with a new api version we wouldn't break inspector
17:47:27 <lucasagomes> if it does pin on a specific version, I gotta check
17:47:44 <rloo> should this be an rfe then?
17:48:09 <rloo> i mean it is a bug i think, but i think we should agree on a solution before someone goes and codes something we don't like
17:48:15 <lucasagomes> sounds like a complex bug, but, not sure if it's a feature tho :-/
17:48:25 <lucasagomes> rloo, def
17:48:49 <vdrok> if it needs to get in in newton, maybe do the same as with power state, timeout?
17:49:06 <rloo> it doesn't need to get into newton. it was just on the list to discuss
17:49:06 <lucasagomes> vdrok, honestly I don't think it will get to newton
17:49:07 <gabriel-bezerra> any reason not to be async on both?
17:49:14 <lucasagomes> I target ocata for now
17:49:21 <lucasagomes> rloo, maybe an ML ?
17:49:24 <mat128> +1, both should be the same ^
17:49:30 <rloo> that's been a bug since early 2015.
17:49:35 <lucasagomes> to bring attention to that probelm and collect ideas ?
17:49:42 <rloo> lucasagomes: could try.
17:50:03 <rloo> i think we (the RoyalWe) need to be better at using the ML to discuss/resolve issues.
17:50:06 <lucasagomes> someone wants to volunteer to send it ? rloo ?
17:50:25 <rloo> one ... two... three... four...
17:50:37 <rloo> (how long should i wait before someone else volunteers?)
17:50:40 <rloo> sure :)
17:51:02 <jroll> I wonder how many people have actually had a problem with this api being async
17:51:11 <lucasagomes> gabriel-bezerra, currently we don't have a mechanism to tell the user whether the change succeed or not ?
17:51:17 <lucasagomes> s/?/
17:51:32 <rloo> jroll: doubt that there are many; otherwise i'd think we'd see more folks comment in that bug. or ask about it.
17:51:46 <lucasagomes> yeah, apparently it's just an incosistency with the rest of the API
17:51:47 <gabriel-bezerra> being async on any point would raise that.
17:51:49 <lucasagomes> like power
17:51:54 <gabriel-bezerra> oh, I get your point.
17:52:00 <jroll> rloo: right, so I wonder how much effort we put into fixing it :)
17:52:29 <gabriel-bezerra> so would you suggest adding a lock on the api until getting a "done" somehow from the conductor?
17:52:36 <rloo> jroll: so i don't know that "we" need to put much effort into it. but i do think that we ought to provide guidance so that if someone wants to fix it, they'll not waste their time doing it in a way that we don't want.
17:53:11 <lucasagomes> gabriel-bezerra, it's the other way around, it's set/get boot device is currently sync
17:53:17 <lucasagomes> gabriel-bezerra, the bug is about making it async
17:54:08 <gabriel-bezerra> my first attempt at this would be to make everything async
17:54:09 <rloo> so i think we're done discussing the bugs in that list. anything else?
17:54:25 <mat128> rloo: not for me
17:54:35 <gabriel-bezerra> I was looking for reasons not to be like that.
17:54:49 <gabriel-bezerra> rloo: not for me
17:55:00 <lucasagomes> gabriel-bezerra, right, yeah please jump in that bug
17:55:05 * jroll has nothing
17:55:10 * lucasagomes nothing from me either
17:55:19 <lucasagomes> so I think we can wrap it up
17:55:25 <lucasagomes> thank you all!
17:55:32 <lucasagomes> #endmeeting