17:00:06 <dtantsur> #startmeeting ironic
17:00:07 <openstack> Meeting started Mon Jun 12 17:00:06 2017 UTC and is due to finish in 60 minutes.  The chair is dtantsur. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:09 <TheJulia> o/
17:00:11 <openstack> The meeting name has been set to 'ironic'
17:00:12 <dtantsur> o/
17:00:12 <crushil> \o
17:00:14 <milan> o/
17:00:19 <stendulker> o/
17:00:23 <kaifeng> o/
17:00:24 <rloo> o/
17:00:45 <pas-ha> o/
17:00:45 <dtantsur> welcome everyone!
17:00:47 <jlvillal> o/
17:01:05 <rpioso> o/
17:01:07 <fellypefca> o/
17:01:21 <dtantsur> our agenda, as usual, can be found at:
17:01:24 <dtantsur> #link https://wiki.openstack.org/wiki/Meetings/Ironic
17:02:32 <dtantsur> #topic Announcements / Reminder
17:02:43 <rama_y> o/
17:02:43 <sauloaislan> o/
17:02:49 <Nisha_Agarwal> o/
17:02:51 <dtantsur> A bunch of stable releases was done for all our projects
17:03:11 <Nisha_Agarwal> woo
17:03:17 <dtantsur> the ironic-lib CI was repaired, and now builds IPA from source with the change being tested
17:03:33 <rloo> yay!
17:04:10 <dtantsur> anything else from anyone?
17:05:19 <dtantsur> #topic Review subteam status reports (capped at ten minutes)
17:05:26 <ricardoas> o/
17:05:39 <dtantsur> #link https://etherpad.openstack.org/p/IronicWhiteBoard line 96
17:05:48 * dtantsur remembers to update the bugs, sigh
17:06:25 <rajinir> o/
17:06:36 <sambetts> o/
17:06:37 <krtaylor> o/
17:09:26 <NobodyCam> o/
17:09:59 <Michael-ZTE> o/
17:11:40 <dtantsur> Nisha_Agarwal: could you please clean up the python 3 section of outdated information (merged patches, etc)?
17:12:19 <rloo> dtantsur: you didn't update the bugs, right?
17:12:25 <dtantsur> rloo: just updated the stats
17:12:37 <rloo> dtantsur: ok, i'll update the date for you :-)
17:12:41 <dtantsur> oh, I forgot to update the dates :) thanks rloo
17:13:03 <mgoddard> o/
17:13:06 <Nisha_Agarwal> dtantsur, done
17:13:08 <Nisha_Agarwal> :)
17:13:15 <dtantsur> thanks
17:14:00 <rloo> for CI refactoring, this has been reviewed, needs updating? https://review.openstack.org/#/c/429770/
17:14:27 <Nisha_Agarwal> rloo, yes
17:14:42 <rloo> I guess vsaienk0 isn't here
17:14:58 <rloo> dtantsur: how essential is the ci refactoring etc?
17:15:19 <dtantsur> rloo: it's always essential, but not in a sense of "do now or die"
17:15:30 <rloo> dtantsur: ok (phew)
17:15:48 <Nisha_Agarwal> rloo, this patch is more of a base for other manual cleaning patches in CI(third party)
17:15:49 <dtantsur> maybe we should move it to "High" section, dunno
17:15:59 <Nisha_Agarwal> dtantsur, ^^^
17:16:05 <rloo> dtantsur: yeah
17:16:07 <dtantsur> I see
17:16:34 <rloo> dtantsur: unless it is essential cuz we NEED test coverage of those missing things
17:17:00 <dtantsur> well, we have features not covered by CI, right?
17:17:07 <rloo> dtantsur: I mean, a feature isn't complete unless we have test coverage?
17:17:17 <dtantsur> right. hence we have it in essential.
17:17:40 <Nisha_Agarwal> rloo, but unless we have third party CI for the stuff vedors are proposing the code doesnt go in unless CI is there
17:17:52 * dtantsur looks at the clock
17:18:09 <dtantsur> I'd prefer we move the questions to the open discussion, as we have some topics proposed already
17:18:14 <rloo> Nisha_Agarwal: right. i think those features went in before we had a lot of CI coverage.
17:18:29 <Nisha_Agarwal> rloo, lets discuss it in open discussion
17:18:41 <rloo> Nisha_Agarwal: (I don't think there needs any more discussion...)
17:18:47 <dtantsur> is everyone done with statuses specifically?
17:18:56 * rloo done
17:19:11 <dtantsur> #topic Deciding on priorities for the coming week
17:19:12 <Nisha_Agarwal> rloo, i just meant that this patch is required for CI stuff (atleast for us)
17:19:41 <dtantsur> we've done some really good job this week :) we've landed 3 out of 4 week priorities
17:20:02 <jlvillal> Nice. You are very productive when I am on vacation ;)
17:20:14 <rloo> Nisha_Agarwal: i updated the whiteboard to mention that it is needed for 3rd party CI :-)
17:20:21 <dtantsur> I'd suggest we keep pushing on BFV and rolling upgrades. probably physical network awareness too
17:20:26 <rloo> jlvillal: no, just think of how much more we could have gotten done with you here!
17:20:35 <jlvillal> :)
17:20:46 <dtantsur> :)
17:20:47 <jlvillal> Those priorities make sense to me.
17:20:49 <Nisha_Agarwal> rloo, thanks :)
17:21:24 <dtantsur> should we keep OSC feature parity on list? there are a few easy wins there, I've +2ed all of them already
17:21:47 <sambetts> dtantsur: sounds like a good idea then
17:21:54 <sambetts> otherwise they just get lost
17:22:06 <rloo> dtantsur: sounds good with me. esp the OSC one, we will/should have at least one priority done this week ;)
17:23:23 <dtantsur> do I get it right that "move create_port to conductor" is the next patch related to physical network awareness?
17:23:25 <dtantsur> mgoddard: ^^^
17:23:38 <rloo> dtantsur: yup, that's right
17:23:53 <dtantsur> ok, so we have 4 topics now. is the list looking good?
17:23:59 <rloo> ++
17:24:03 <mgoddard> dtantsur: correct
17:24:26 <dtantsur> do we want to take anything else now that we have jlvillal to review everything? :)
17:24:34 <jlvillal> heh
17:24:45 <rloo> dtantsur: i say wait a week, he just got back :)
17:25:13 <dtantsur> ok, ok :) the 3 topics out of 4 are quite tough
17:25:33 <dtantsur> moving on?
17:26:09 <dtantsur> #topic the driver composition and breaking changes to the supported interfaces
17:26:18 <dtantsur> #link http://lists.openstack.org/pipermail/openstack-dev/2017-June/118226.html
17:26:40 <dtantsur> I've found that the way we change the drivers now somehow promotes doing breaking changes
17:26:52 <TheJulia> I am all for option 4, release note, and then provide a proposed mechanism to make their lives easier in the future
17:26:57 <dtantsur> e.g. when drivers move from a generic "pxe" boot to a specific "<vendor>-pxe"
17:27:15 <rloo> dtantsur: if i understand it, what you're saying is that the *default* interface was changed?
17:27:49 <dtantsur> rloo: not really. just one of the supported interfaces has changed its name
17:27:49 <milan> TheJulia ++ seems the easiest thing to do (almost nothing ;)
17:27:59 <dtantsur> "pxe" -> "<vendor>-pxe"
17:28:19 <rloo> dtantsur: so 'pxe' == 'irmc-pxe' ? same behavior?
17:28:42 <dtantsur> rloo: not exactly the same. they've extended it with more clean steps.
17:28:52 <dtantsur> and are dropping "pxe" for this reason
17:28:58 <rloo> dtantsur: so not the same interface. i see it as 'they changed the default interface'.
17:29:14 <dtantsur> s/the default/a supported/
17:29:19 <rloo> dtantsur: i didn't read/review the patch, just guessing...
17:29:32 <rloo> dtantsur: oh, if they only added a new supported one, then how does it break?
17:29:40 <dtantsur> rloo: and remove one too
17:29:49 <rloo> dtantsur: oh, the removal is what i missed.
17:29:56 <rloo> dtantsur: i don't see how you can remove, that is breaking change.
17:30:09 <dtantsur> this is my question: what should we do about such changes
17:30:17 <rloo> dtantsur: if we use our usual rules, need to deprecate first?
17:30:18 <pas-ha> will it not work at all with base pxe?
17:30:18 <stendulker> Or can they support both pxe and irmc-pxe as boot inetrfaces for Pike release and mark 'pxe' for obsolenscence within irmc hardware type?
17:30:26 <pas-ha> stendulker: +
17:30:33 <dtantsur> an essence of the change: https://review.openstack.org/#/c/416403/8/ironic/drivers/irmc.py@93
17:30:46 <dtantsur> rloo: ^^^
17:31:16 <rloo> dtantsur: i think we still need to support pxe.PXEBoot.
17:31:21 <rloo> dtantsur: needs a deprecation period.
17:31:32 <Nisha_Agarwal> rloo+
17:31:48 <rloo> dtantsur: or at least, we cannot break if someone had created a node with driver irmc and boot-interface=pxe.
17:32:07 <dtantsur> another option is to create a database migration
17:32:13 <dtantsur> no, it won
17:32:13 <rloo> dtantsur: we can issue a warning and 'redirect' pxe interface to boot.irmcpxeboot, but we can't break.
17:32:15 <dtantsur> won't work
17:32:16 <pas-ha> rloo: ++ plus a release note saying the 'pxe' interface will not have all the features
17:32:34 <dtantsur> this will need to implicitly enable the new interface, which is not enabled by default
17:33:43 <rloo> dtantsur: i think we should decide how we want things to work, and then see if we can get the code to do what we want
17:34:03 * dtantsur wonders if the change actually has to modify the boot interface in this case, not e.g. management
17:34:09 <rloo> masters that we are :-)
17:35:16 <rloo> i have to say, there is a lot more to this patch than what the commit msg sez. nothing about a new boot interface :-(
17:35:35 <rloo> i'd think based on the commit, that only the irmc mgt interface would get updated.
17:35:47 <dtantsur> yeah. even outside of this patch, we need a formal policy on similar changes.
17:36:01 <dtantsur> and it seems that the consensus is to keep support for pxe for some time, then switch?
17:36:04 <rloo> dtantsur: agreed that we need formal policy.
17:36:13 <stendulker> dtantsur: ++
17:36:22 * dtantsur has to write dev docs on the new drivers
17:36:31 <rloo> dtantsur: support for 'pxe' interface -- whether it means actual pxe code or if it 'redirects' to new 'irmc-pxe' is a diff story
17:36:51 <dtantsur> looking at the code, it's safe to support "pxe" in this particular case
17:37:09 <pas-ha> same feeling
17:37:14 <rloo> dtantsur: ok, that'd be the easiest thing to do.
17:37:39 <rloo> dtantsur: after deprecation, we can add DB migration script to change 'pxe' to irmc-pxe'.
17:37:43 <pas-ha> its just that bios restore won't work automatically
17:37:45 <dtantsur> ok, please post your thoughts to the ML thread. if we get a consensus, I'll try to capture it in the future drivers dev docs.
17:37:50 <stendulker> Or would be better for vendor to carve out vendor-* interfaces for hardware types so that they can be extended later without such issues
17:38:05 <dtantsur> stendulker: I actually was going to propose it, at least for boot..
17:38:17 <dtantsur> it seems that the boot interfase is very often extended by vendors
17:38:49 <stendulker> dtantsur: yes, and many a times we cannot plan it upfront, but a place holder should help in long run
17:39:33 <dtantsur> ok, please comment on the thread
17:39:41 <dtantsur> ready to move on?
17:40:18 <dtantsur> #topic RFE review
17:40:37 <dtantsur> #link https://bugs.launchpad.net/ironic/+bug/1691344
17:40:38 <openstack> Launchpad bug 1691344 in Ironic "[RFE] Make ip address of socat console configurable" [Wishlist,In progress] - Assigned to Wang KaiFeng (kaifeng)
17:41:17 <dtantsur> this seems a reasonable thing to do, and the patch looks quite straightforward
17:41:22 <pas-ha> this looks quite easy and imo does not need a spec, just make the default to be the current behavior
17:41:45 <TheJulia> I agree
17:41:52 <rloo> the rfe needs to identify the name of the new config
17:41:58 <rloo> but other than that, seems reasonable to me
17:42:00 <stendulker> ++
17:42:17 <dtantsur> I'd prefer it as well, but I can also argue about it on review
17:42:27 <rloo> and it should mention as pas-ha said, what the default value is.
17:42:41 <rloo> dtantsur: just a good habit for folks to have/do.
17:43:06 <dtantsur> "the ip address binded by socat is only configurable by $my_ip" implicitly mentions the default fwiw
17:43:29 <dtantsur> do we want more details or can we approve and figure out on the patch?
17:43:47 <rloo> we can approve, i will put a comment about what i just said.
17:43:52 <dtantsur> thanks!
17:43:52 <kaifeng> Thanks guys, I named it socat_address for current code, if there is any feedbacks from reviews about the option name, I would update back to the launchpad.
17:44:06 * jlvillal didn't know you could use "$my_ip" as a default value.  TIL
17:44:08 <rloo> i agree it implicitly mentions the default but i have seen in the past, where my assumption isn't the same as others.
17:44:10 <dtantsur> kaifeng: hi! I think we have a separate configuration section for [console]
17:44:25 <dtantsur> otherwise I'm good with it
17:44:48 <dtantsur> kaifeng: https://github.com/openstack/ironic/blob/master/ironic/conf/console.py  <-- I think it should go here
17:45:21 <dtantsur> actually, it's there already,so I'm good with it
17:45:32 <dtantsur> any other comments?
17:45:52 * dtantsur is ready to mark it rfe-approved
17:45:58 <kaifeng> Yes:)
17:46:25 <dtantsur> ok, let's move on
17:46:29 <dtantsur> #link https://bugs.launchpad.net/ironic/+bug/1696619
17:46:30 <openstack> Launchpad bug 1696619 in Ironic "[RFE] auto recovering from maintenance" [Wishlist,Confirmed] - Assigned to yuan liang (leetpy)
17:46:43 <dtantsur> this is something JayF tried to do with his specific faults work
17:46:59 <dtantsur> it's still very valuable to do, I wonder what specific implemention will be
17:47:05 <dtantsur> I'd prefer a spec on it, I guess..
17:47:23 <rloo> to be honest, i don't understand the description.
17:47:48 <dtantsur> rloo: IIUC this is about unsetting maintenance that was set due to a power fault
17:48:11 <pas-ha> this kind of looks lik 'faults' we have been talking about before
17:48:29 <pas-ha> courtesy of JayF
17:49:23 <rloo> so isn't this a dup of the faults spec then?
17:49:37 <dtantsur> rloo: the faults spec is dead, until somebody overtakes it
17:49:50 <dtantsur> we may point the person towards it. or we can ask for a spec and see how it looks.
17:50:08 <rloo> dtantsur: well, there's an RFE associated with the faults spec, if it already describes what this isn't/hasn't yet described...
17:50:08 <dtantsur> "specific faults" was a big thing, we can probably solve this particular problem easier
17:51:09 <dtantsur> rloo: right. do you propose to mark this as a duplicate?
17:51:10 <rloo> so regardless, i would want more information on this. i don't see/how they want to unset maintenance.
17:51:23 <dtantsur> or ask for a spec and see where it goes?
17:51:44 <rloo> i will admit i haven't read the faults spec so don't know which way to go but if the faults spec already describes what this person wants to do, then it seems to me that it is a dup.
17:52:02 <rloo> i am fine suggesting both and let the author decide.
17:52:03 <dtantsur> well, not directly
17:52:29 <dtantsur> the faults spec is more about reporting faults. it does not directly talk about unsetting maintenance IIRC
17:52:39 <dtantsur> "suggesting both and let the author decide" ++
17:52:57 <rloo> dtantsur: in that case it is different. i don't know w/o spending more time looking into this.
17:53:07 <rloo> but i want a better description!
17:53:22 <dtantsur> so, needs-spec?
17:53:28 <pas-ha> definitely
17:53:36 <rloo> yes please
17:53:47 <dtantsur> ok, I'll comment after the meeting
17:53:49 <rloo> unless they can describe it in the RFE.
17:54:12 <dtantsur> any more comments on this one?
17:54:30 <dtantsur> #link https://bugs.launchpad.net/ironic/+bug/1681320
17:54:31 <openstack> Launchpad bug 1681320 in Ironic "[RFE] Allow inspection to discover pci devices" [Wishlist,Triaged]
17:54:37 <dtantsur> Nisha_Agarwal: the microphone is yours :)
17:54:43 <Nisha_Agarwal> dtantsur, :)
17:55:12 <Nisha_Agarwal> So this is to propose the pci device inspection similar to what ironic-inspector does today
17:55:55 <Nisha_Agarwal> so that even OOB inspection can have the pci devices discovered and added to capabilities
17:57:00 <Nisha_Agarwal> Since inspector spec was approved and implemented long back , do we need a spec for this one. ispector spec link https://github.com/openstack/ironic-inspector-specs/blob/master/specs/generic-pci-resource.rst
17:57:17 <Nisha_Agarwal> s/ispector/inspector
17:57:40 <dtantsur> the only question I have is whether we want to make it a generic config or not
17:57:50 <wanyen> IMO, PCI device discovery and capability are important for users regardless in-band or oob discovery.
17:57:52 <Nisha_Agarwal> or just RFE would do for this one
17:58:05 <dtantsur> i.e. are more vendors going to implement it? should we make ironic-inspector respect ironic's configuration? etc
17:58:24 <Nisha_Agarwal> dtantsur, hmmm
17:58:46 <Nisha_Agarwal> dtantsur, may be when inspector is invoked from ironic it makes sense to respect ironic config file
17:58:56 <jlvillal> FYI: 2 minutes left
17:59:09 <Nisha_Agarwal> and when ran standalone, it can take input from its config file
17:59:16 <dtantsur> right, so we may want to extend ironic-inspector API to pass it.. or make the Inspector interface handle it
17:59:45 <Nisha_Agarwal> dtantsur, i didnt get?
17:59:45 * dtantsur needs to think more about it, to be honest
17:59:56 * milan too O:-)
18:00:00 <Nisha_Agarwal> dtantsur, ok.
18:00:07 <Nisha_Agarwal> milan, :)
18:00:09 <dtantsur> and we're out of time, sorry :( please anyone, let Nisha_Agarwal know what you think in the channel
18:00:21 <dtantsur> #endmeeting ironic