17:00:17 <jroll> #startmeeting ironic
17:00:18 <openstack> Minutes (text): http://eavesdrop.openstack.org/meetings/ironci/2016/ironci.2016-11-21-17.00.txt
17:00:19 <openstack> Log:            http://eavesdrop.openstack.org/meetings/ironci/2016/ironci.2016-11-21-17.00.log.html
17:00:20 <dtantsur> o/
17:00:21 <openstack> Meeting started Mon Nov 21 17:00:17 2016 UTC and is due to finish in 60 minutes.  The chair is jroll. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:21 <JayF> o/
17:00:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:23 <NobodyCam> o/
17:00:24 <lucasagomes> o/
17:00:25 <openstack> The meeting name has been set to 'ironic'
17:00:25 <rpioso> o/
17:00:26 <mariojv> o/
17:00:26 <jroll> \o
17:00:29 <stendulker> o/
17:00:30 <_milan_> o/
17:00:31 <mgould> o/
17:00:33 <rloo> o/
17:00:36 <jroll> as always the agenda is here
17:00:40 <jroll> #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting
17:00:48 <sambetts> o/
17:01:23 <jroll> #topic announcements and reminders
17:01:25 <vdrok> o/
17:01:38 <jroll> reminder pike PTG signups are open, and limited to 500 people, so sign up early
17:01:40 <jroll> #link https://www.eventbrite.com/e/project-teams-gathering-tickets-27549298694
17:01:54 <vdrok> nova spec on portgroups merged
17:01:57 <jroll> also thanksgiving is this week in the US, so expect lots of people off toward end of week
17:02:04 <rama_y> o/
17:02:28 <jroll> anything else?
17:03:08 <jroll> #topic subteam status reports
17:03:13 <jroll> as always those are here
17:03:15 <jroll> #link https://etherpad.openstack.org/p/IronicWhiteBoard
17:03:19 <jroll> starting around line 84
17:03:24 <jroll> (priorities at line 74)
17:03:28 <joanna> o/
17:03:43 <dtantsur> I've requested Newton releases for all projects, they'll hopefully be processed soon
17:03:54 <rloo> thx dtantsur
17:04:02 <jroll> oh yes, awesome
17:04:02 <dtantsur> also Liberty reaches EOL as we speak
17:04:20 <rloo> sambetts, vdrok: is that the LAST ironic spec for portgroups support? /me is getting tired of...
17:04:46 <dtantsur> lol
17:04:48 <vdrok> rloo: you mean that update? I think so, yes
17:04:54 <vdrok> s/think/hope
17:04:59 <vdrok> :D
17:05:07 <lucasagomes> w00t
17:05:12 <rloo> vdrok: /me hopes too! :)
17:05:32 <rloo> lucasagomes:  is that a cheer for eol'ing liberty?
17:05:48 <lucasagomes> rloo, for vdrok, but yeah works for liberty as well :-)
17:05:56 <rloo> lucasagomes: :)
17:06:04 <dtantsur> lucasagomes, don't be too glad, I think we still support it downstream :D
17:06:16 <lucasagomes> dtantsur, we do yeah
17:06:16 <JayF> dtantsur: /o\
17:06:17 <rloo> sambetts: what's the status of the attach/detach patches?
17:06:36 <sambetts> New update for the Ironic side should be going out today :)
17:06:50 <rloo> sambetts: great! thx
17:08:21 <rloo> so i guess the deploy steps will be 'on hold' for a few weeks. mat128 is away for a bit but i forgot how long.
17:08:35 <jroll> yep
17:08:47 <jroll> the goal there is just to get the spec done, so I think that will be fine
17:09:45 <rloo> jroll: what are this week's priorities?
17:10:00 <jroll> rloo: still ingesting all the updates
17:10:06 <rloo> oh yeah, root device hints are done, thx lucasagomes!
17:10:22 <lucasagomes> yeah, the last bit was only docs :-)
17:11:00 <jroll> rloo: looks like we could just keep iterating on last week's stuff?
17:11:06 <jroll> looks like they all got some action
17:11:27 <rloo> we could. jroll do you think there will be anything for #5 this week? given your short week etc
17:11:48 <jroll> rloo: yeah I hope to have a code update today or tomorrow
17:12:14 <rloo> jroll: ok
17:12:38 <vdrok> #6 should be pretty quick to merge I think
17:12:54 * dtantsur hopes so
17:12:58 <jroll> +1
17:13:14 <rloo> so i see three? specs that need work: rolling upgrades, ipa REST API, fault support. are they at a state where we could meet to go over them, or should we wait another week or more?
17:14:02 <jroll> I'm honestly not sure
17:14:03 <mariojv> i think fault support should wait at least another week
17:14:14 <rloo> ok, let's wait then :)
17:14:20 <mariojv> JayF may correct me :)
17:14:39 <JayF> I plan on having a reviewable vesion of that up by EOW
17:14:55 <JayF> although I suspect it'll need more than a little review back-and-forth
17:15:32 <rloo> Ok, I'll bring it up again in 2 weeks (if i remember) :)
17:16:12 <jroll> cool
17:16:15 <jroll> anything else on this?
17:17:33 <jroll> #topic Drop QA/CI meeting and just handle any topics in this meeting?
17:17:36 <jroll> should be super quick
17:17:46 <jroll> in the QA meeting wednesday we agreed we don't need a separate meeting
17:17:54 <jroll> can just use subteam updates and such
17:17:56 <jroll> any objections here?
17:18:18 <rloo> jroll: did you discuss with john?
17:18:52 <jroll> rloo: I have not, good point
17:18:57 <jroll> was hoping he'd be here I guess :)
17:19:09 <rloo> jroll: he might be out this whole week
17:19:14 <jroll> right, I know
17:19:28 <rloo> i'm fine with dropping it as long as john is :)
17:19:31 <jroll> if there's no objections here I'll check it with him and then do the thing
17:19:36 <jroll> I propose we skip it this week thuogh :)
17:19:45 <rloo> +1 to skipping it!
17:19:46 <dtantsur> I'm all for it, as I usually cannot make it to the second evening meeting
17:20:07 <jroll> krtaylor: mind sending a skip notice to the ML ?
17:20:12 <vdrok> yeah, same for me
17:20:40 <lucasagomes> if the ppl that attend the meeting agrees on dropping it, i've no objections
17:20:47 <TheJulia> All for skipping this week and dropping it since it should bring more clarity to this meeting.
17:21:04 <jroll> cool, seems everyone agrees, I'll email john
17:21:07 <jroll> thanks!
17:21:11 <jroll> #topic open discussion
17:21:14 <jroll> who's got a thing?
17:21:27 <rloo> jroll: i have something under rfe review
17:21:33 <rloo> 4 things actually
17:21:52 <jroll> rloo: they were added within 20 minutes of the meeting, then :/
17:21:58 * jroll refreshes
17:22:01 <jroll> #topic RFE review
17:22:03 <rloo> jroll: yeah. my bad. supposed to be 2 days or so before
17:22:11 <jroll> fire away :)
17:22:33 <rloo> so i am slowing going through our rfes. checking to see which need specs or not. here are the oldest four i picked to discuss
17:22:43 <rloo> https://bugs.launchpad.net/ironic/+bug/1588177
17:22:43 <openstack> Launchpad bug 1588177 in Ironic "RFE: Allow ilo drivers to choose the ports to be inspected" [Wishlist,In progress] - Assigned to Shivanand Tendulker (stendulker)
17:23:00 <rloo> i don't think it needs a spec but ??
17:23:18 <dtantsur> I would like it to converted to "Allow to choose the ports to be inspected
17:23:27 <dtantsur> because I just got the same complains about pxe_drac inspection
17:23:46 <dtantsur> I'm fine with an RFE only as long as its generic and not iLO specific
17:24:07 <dtantsur> then, however, it's going to be funny to implement for ironic-inspector (requires API update), but we'll handle it :)
17:24:11 <rloo> dtantsur: makes sense to me.
17:24:16 <jroll> sounds more like "specify nics to not be managed by ironic", no?
17:24:17 <rloo> dtantsur: the generic part.
17:24:28 <rloo> the funny part, i dunno. i'm not laughing yet anyway :)
17:24:30 <dtantsur> jroll, to not present to Nova
17:24:43 <jroll> dtantsur: yeah, that too I suppose
17:24:47 <dtantsur> we don't "manage" ports IIRC, but nova picks the random one for provisioning
17:24:53 <jroll> ok, agree about generic
17:25:04 <sambetts> we have the pxe_enabled field now
17:25:12 <sambetts> we should use those ports
17:25:14 <lucasagomes> ++ for generic... And, should we use the pxe_enabled for it?
17:25:17 <lucasagomes> sambetts, =+
17:25:19 <lucasagomes> ++*
17:25:21 <jroll> sambetts: this is about inspection
17:25:23 <dtantsur> sambetts++ does nova always use it?
17:25:25 <jroll> so that data isn't there yet
17:25:27 <jroll> right?
17:25:36 <lucasagomes> dtantsur, not at the moment, I think
17:25:50 <jroll> this feature is easy without inspection, the user just doesn't add the ports
17:26:06 <dtantsur> yep. but inspection adds all ports
17:26:21 <pas-ha> dtantsur: this can be suppressed, right?
17:26:21 <dtantsur> (except for ironic-inspector which hacks around it, sigh)
17:26:22 <jroll> right, so pxe_enabled doesn't exist yet, so we can't use it for this
17:26:37 <dtantsur> pas-ha, for OOB inspection?
17:27:01 <pas-ha> I remember there was something like do not add ports if found new...
17:27:43 <pas-ha> or is it for discovery phase we are talking about?
17:28:02 * jroll comments his thoughts on the rfe
17:28:41 <dtantsur> pas-ha, I think you're talking about ironic-inspector
17:28:58 <dtantsur> pas-ha, and here we're discussing OOB inspection as implemented by (at least) pxe_ilo and pxe_drac
17:29:10 <pas-ha> ok, now I got this
17:30:02 <sambetts> IMO I think inspector should firewall off all ports that have pxe_enabled=False, we can't do anything about ports we don't know about yet
17:30:25 <jroll> that's... a different topic, though
17:30:25 <lucasagomes> sambetts, let's keep on topic
17:30:30 <lucasagomes> otherwise it will go crazy
17:30:32 <jroll> this isn't about inspector or existing ports
17:30:39 <jroll> still have 3 more RFEs
17:30:48 <rloo> so do we want a spec? or is it sufficient if they can clarify in the rfe?
17:30:49 <jroll> anyone disagree on approving a generic version of this one?
17:31:02 * jroll is fine without a spec, if it's generic
17:31:08 <lucasagomes> ++ for generic
17:31:13 <sambetts> ++
17:31:17 <rpioso> ++ for generic
17:31:23 <rloo> ++
17:31:23 <dtantsur> ++
17:31:36 <jroll> seems good enough to me
17:31:41 <jroll> rloo: next!
17:31:51 <rloo> https://bugs.launchpad.net/ironic/+bug/1596421
17:31:51 <openstack> Launchpad bug 1596421 in Ironic "RFE: Increase size of data base entry for instance_info to allow configdrives larger than 64KiB" [Wishlist,In progress] - Assigned to John L. Villalovos (happycamp)
17:31:51 <NobodyCam> ++
17:32:20 <rloo> there's discussions in that rfe, and patches. but i don't know that we have decided on anything?
17:32:28 <jroll> oh did we not?
17:32:45 <rloo> jroll: i don't know. i can't tell from looking at the rfe.
17:32:45 <JayF> So I thought the discussion w/r/t solving that problem about configdrive size
17:32:55 <JayF> was to stop storing a configdrive at all.
17:33:05 <lucasagomes> JayF, that's my understanding as well
17:33:10 <JayF> No other nova driver stores and re-uses a configdrive on rebuild.
17:33:21 <jroll> ah, yeah, that was a thing
17:33:27 <TheJulia> but our rebuild does not recreate nor offer it upon our rebuild
17:33:28 <lucasagomes> tho... we will need to change our API
17:33:29 <JayF> In fact, today, the fact you can't re-pass configdrive into ironic when doing a rebuilt is an API change from other nova drivers on rebuild
17:33:39 <lucasagomes> to allow rebuild to have a configdrive parameter
17:33:42 <TheJulia> err, our nova driver
17:33:48 <JayF> lucasagomes: ++
17:33:55 <TheJulia> lucasagomes: ++
17:34:54 <gabriel-bezerra> folks, I'd like some opinion on the discussion started here: https://review.openstack.org/360330/
17:35:31 <jroll> gabriel-bezerra: please wait for open discussion
17:35:35 <gabriel-bezerra> oh, sorry
17:35:50 <NobodyCam> I know folks who have modified ironic to automatically build and attach config drives
17:35:52 <jroll> TheJulia: JayF: lucasagomes: is there someone that can write down that decision and carry it forward to rfe/spec approval?
17:36:03 <JayF> jroll: I thought someone had done that, in a bug somewhere
17:36:06 * JayF looks
17:36:07 <gabriel-bezerra> i thought I had seen the "open discussion" topic
17:36:13 <jroll> JayF: not that I'm aware of
17:36:14 <sambetts> JayF: don't we need to store it at least for the period before we write it to the node??
17:36:20 <jroll> gabriel-bezerra: yeah, that was a misfire, no worries
17:36:28 <TheJulia> JayF: I thought the same had already been done, since there was >1 related bugs
17:36:29 <JayF> https://bugs.launchpad.net/ironic/+bug/1575935
17:36:29 <openstack> Launchpad bug 1575935 in Ironic "Rebuild should also accept a configdrive" [Medium,Confirmed] - Assigned to Stephane Miller (stephaneeee)
17:36:39 <TheJulia> We should unassigns that
17:36:45 <TheJulia> unassign
17:37:11 <lucasagomes> TheJulia, ++
17:37:11 <jroll> JayF: so we should reject the other rfe and point to that, then
17:37:13 <jroll> right?
17:37:15 <JayF> +1
17:37:19 <jroll> ok
17:37:59 * jroll has done it
17:38:02 <TheJulia> lucasagomes: removed assignment, since I've talked to cinerama in the past few weeks
17:38:05 <jroll> what's next rloo :)
17:38:09 <lucasagomes> ty
17:38:11 <rloo> https://bugs.launchpad.net/ironic/+bug/1599425
17:38:11 <openstack> Launchpad bug 1599425 in Ironic "[RFE]: Add few more capabilities to ironic inspection" [Wishlist,Confirmed]
17:38:29 * dtantsur wants a spec on that
17:39:00 <TheJulia> There already is one if memory serves
17:39:03 <dtantsur> we've been way too relaxed with adding capabilities. so now pxe_ilo detects something, ironic-inspector detects something different.
17:39:15 <dtantsur> and other drivers are probably not detecting any
17:39:36 <TheJulia> https://review.openstack.org/#/c/338138/
17:40:19 <rloo> TheJulia: oh, that's the spec for that rfe. ok. i'll just tag it as 'needs-spec' then :)
17:40:20 <dtantsur> right
17:40:24 <jroll> +1
17:40:53 <rloo> last but not least and easy i think: https://bugs.launchpad.net/ironic/+bug/1626106
17:40:53 <openstack> Launchpad bug 1626106 in Ironic "[RFE] Install optional dependencies when running unit tests" [Wishlist,Confirmed]
17:41:08 <TheJulia> uhhh
17:41:15 <TheJulia> Just the title makes me a little concerned
17:41:22 <dtantsur> lol
17:41:33 <dtantsur> ah, this one. yes
17:41:36 <rloo> TheJulia: ? bells ringing?
17:41:52 <sambetts> IMO third party CI should be covering this
17:41:55 <dtantsur> we got a problem when our tests for one of the drivers worked perfectly with mocks, but not with actual thing installed
17:42:02 * jroll doesn't see any reason not to do this
17:42:04 <dtantsur> sambetts, 3rdparty CI to run unit tests?
17:42:06 <mgould> so the upside is "catches problems with optional dependencies" and the downside is "will make g-r hate us"?
17:42:14 <lucasagomes> I think we should just do it
17:42:17 <dtantsur> mgould, yes
17:42:18 <sambetts> dtantsur: hmm good point :/
17:42:22 <TheJulia> dtantsur: that is exactly the reason why to do it
17:42:28 <jroll> why would this make g-r hate us?
17:42:42 <JayF> jroll: none of the driver-requirements are in g-r or u-c
17:42:44 <rloo> this doesn't affect g-r
17:42:45 <jroll> so?
17:42:49 <TheJulia> rloo: My only nit would be add "python" to the subject :)
17:42:51 <jroll> this has nothing to do with g-r, good or bad
17:42:56 <rloo> we wouldn't put the driver requirements in g-r
17:43:03 <mgould> oh, good, I must have misunderstood rloo's comment
17:43:07 <rloo> TheJulia: oh. ha ha.
17:43:15 <gabriel-bezerra> what is g-r?
17:43:17 <dtantsur> jroll, they may pull incompatible requirements to our unit tests
17:43:24 <lucasagomes> gabriel-bezerra, global requirements
17:43:25 <TheJulia> if it was system level packages, I would be very concerned
17:43:33 <jroll> dtantsur: not if we install them with u-c enabled
17:43:37 <jroll> :)
17:43:41 <mgould> gabriel-bezerra: https://github.com/openstack/requirements#global-requirements-for-openstack-projects
17:43:46 <gabriel-bezerra> thanks
17:43:51 <rloo> TheJulia: updated!
17:43:52 <dtantsur> jroll, if we don't add these requirements to g-r, they may contradict u-c
17:43:55 <TheJulia> \o/
17:44:01 <dtantsur> which will break our unit tests without ability to recover them
17:44:13 <pas-ha> TheJulia: for system level, there's http://docs.openstack.org/infra/bindep/index.html which I think we want to move to
17:44:14 <dtantsur> this is why everything is put into u-c
17:44:19 <jroll> dtantsur: if that's a real concern, we can keep it non-voting, and file bugs when that happens
17:44:23 <mgould> gabriel-bezerra: tl;dr all OpenStack projects must have compatible requirements.txt files
17:44:28 <dtantsur> jroll, this will work, I guess
17:44:34 <gabriel-bezerra> got it
17:45:04 <pas-ha> yeah, as non-voting extra unit test job - I'm fine with that
17:45:14 <JayF> it almost seems like a feature, not a bug
17:45:22 <JayF> that it could expose g-r + driver-requirements incompatibilities
17:45:26 <mariojv> ++ ^
17:45:26 <jroll> JayF: as long as it's non-voting yeah :)
17:45:37 <JayF> because then we can get he maintainers of the requirement to make it compat :)
17:45:44 <jroll> agree
17:45:53 <mariojv> maybe make it voting once all in-tree drivers are compatible
17:46:44 <dtantsur> mariojv, I doubt it. We don't even have ironic-inspector voting on ironic :D
17:46:49 <dtantsur> * ironic-inspector job
17:46:51 <jroll> ok, any objections to approve it?
17:46:59 <TheJulia> None here
17:47:01 <dtantsur> ++ for approving
17:47:04 <lucasagomes> nop
17:47:40 <rloo> thx all. that wasn't too painful. i'm going to add 10 next time (j/k)
17:48:14 <jroll> awesome
17:48:16 <TheJulia> rloo: just add one per week ;)
17:48:18 <jroll> open discussion?
17:48:22 <dtantsur> thanks rloo, this is useful
17:48:46 <rloo> ok, 4 or fewer :)
17:48:53 <TheJulia> open discussion would be good, I think gabriel-bezerra had a question
17:48:56 <gabriel-bezerra> As I would introduce earlier, I'd like some opinion on this: https://review.openstack.org/360330/
17:49:12 <gabriel-bezerra> the point is: oneview needs the machine to be turned off for it to set the boot device
17:49:13 <jroll> #topic open discussion
17:49:34 <gabriel-bezerra> agent driver tries to set the device while it is turned on
17:49:56 <gabriel-bezerra> 2 ways to fix it: change the agent driver or change oneview driver set-boot-device to shut the machine off
17:50:07 <gabriel-bezerra> that patch goes the second way
17:50:38 <jroll> what's the reasoning behind the first?
17:50:40 <TheJulia> So I think this is a oneview centric thing, so it seems like it would need to be addressed in the oneview driver
17:51:04 <rloo> can't we make it generic? add some flag to driver_info?
17:51:13 <mariojv> i agree with TheJulia, without having read the code. is there any disadvantage to the second option?
17:51:26 <gabriel-bezerra> the first: changing the agent to turn the amchine off before changing the boot device?
17:51:29 <sambetts> I would suggest if you need to change the order of operations in the agent deploy interface you inherit it and create a oneviewagentdeployinterface
17:51:30 <gabriel-bezerra> jroll:   ^
17:51:42 <rloo> anyway, what's the question? how to address it?
17:51:47 <jroll> gabriel-bezerra: yeah, what would be the advantage of that?
17:51:54 <TheJulia> the second option also allows the oneview driver to error if a user tries to explicitly change the boot device via the api, which right now, I guess would silently fail...
17:52:11 <gabriel-bezerra> we have a klugde today that we inherit the driver and copy-paste most of the code
17:52:25 <gabriel-bezerra> whenever it changes, our driver breaks together
17:52:49 <jroll> O_o
17:53:06 <TheJulia> gabriel-bezerra: so that seems like a second problem we need to solve as well
17:53:10 <sambetts> the problem I see with the existing patch is that if we change the agent driver to do a inband operation after setting the boot device then it'll break because you've powered off the node
17:53:13 <lucasagomes> gabriel-bezerra, if you set the boot device when the machine is on it fails ? Or it suceeds and it gets applied later after the machine reboots ?
17:53:20 <gabriel-bezerra> i mean.. part of the agent code is copy-pasted, so that we put the shut off code there
17:53:25 <gabriel-bezerra> yes
17:53:32 <gabriel-bezerra> lucasagomes: it fails
17:53:36 <lucasagomes> hmm
17:53:43 <jroll> sambetts: I don't see us doing that though :P
17:54:02 <gabriel-bezerra> another option i'd put is: add a hook to the agent driver and we could just put the shut off there.
17:54:08 <lucasagomes> gabriel-bezerra, what if you save the choosen boot device inside driver_internal_info and applies it when the machine is powered off ?
17:54:24 <lucasagomes> so ironic can lazily do it for oneview (instead of relying on the hardware for it)
17:54:44 <vdrok> yep, we do it for ipmitool
17:54:46 <lucasagomes> power_off() -> checks if there's a pending boot device -> applies/skip -> power off
17:55:00 <lucasagomes> I mean power off -> apply/skip
17:55:09 <gabriel-bezerra> sounds like an option
17:55:31 <lucasagomes> sounds better than doing a hard power off when you call "node-set-boot-device" for me
17:56:22 <TheJulia> I guess driver specific docs could highlight that difference if a user tries to explicitly set the boot device
17:57:14 <gabriel-bezerra> something the patch shows is: even shutting the machine off during a set-boot-device, all tempest tests pass..
17:57:39 <gabriel-bezerra> the patch doesn't bring it back to the previous state
17:58:14 <gabriel-bezerra> seems like all use cases so far for setting boot devices is followed by a reboot or power on
17:58:38 <jroll> except the api :)
17:58:40 <gabriel-bezerra> .. or that is obvious, and I'm just saing bs here
17:58:43 <gabriel-bezerra> yeah..
17:58:46 <gabriel-bezerra> :)
17:59:17 <jroll> yeah, idk if I have a good answer, need to think on this more
17:59:45 <jroll> and time is up
17:59:45 <vdrok> small review request - couple of small patches - https://review.openstack.org/396355, if you have some time
17:59:52 <jroll> to gabriel-bezerra's patch!
17:59:55 <jroll> thanks y'all
17:59:57 <jroll> #endmeeting