15:00:08 <TheJulia> #startmeeting ironic
15:00:09 <openstack> Meeting started Mon Jul 30 15:00:08 2018 UTC and is due to finish in 60 minutes.  The chair is TheJulia. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:12 <TheJulia> o/
15:00:13 <openstack> The meeting name has been set to 'ironic'
15:00:22 <mjturek> o/
15:00:26 <kaifeng> o/
15:00:29 <bdodd> o/
15:00:31 <rpioso> \o
15:00:33 <etingof> o/
15:00:40 <hshiina> o/
15:00:44 <rloo> o/
15:00:45 <stendulker> o/
15:00:59 <jroll> \o
15:01:24 <TheJulia> Our agenda this week is on the wiki. We have a few discussion topics this week, but hopefully it should go quickly.
15:01:40 <TheJulia> #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting
15:01:52 <TheJulia> #topic Announcements/Reminders
15:02:24 <TheJulia> This week is R-4, which means we're closing in on release quite quickly.
15:02:43 <rajinir> o/
15:02:50 <TheJulia> #info python-ironicclient and python-ironic-inspector-client were released last week.
15:03:25 <TheJulia> #info Reminder: Please add topics and update if you will be present on the Stein PTG planning etherpad.
15:03:28 <TheJulia> #link https://etherpad.openstack.org/p/ironic-stein-ptg
15:04:23 <TheJulia> #info Next week is R-3, or Rocky RC1 release. We should expect to release ironic 11.1 next week as a result.
15:05:29 <TheJulia> Also worth noting, PTL nominations are underway and close tomorrow evening near midnight UTC.
15:05:55 <TheJulia> Does anyone have anything to announce or remind us of?
15:06:54 <TheJulia> I guess not, we can move on then.
15:07:52 <TheJulia> Looks like we had no action items last week, so we can skip that
15:08:20 <TheJulia> #topic Review subteam status reports
15:08:33 <TheJulia> #link https://etherpad.openstack.org/p/IronicWhiteBoard
15:08:53 <TheJulia> Starting at line 163
15:09:30 <rloo> wrt the Bugs, can we delete the stuff about moving to storyboard, and whether anythign needs to be addressed?
15:09:38 <rloo> L169 & 171
15:10:01 <TheJulia> I don't see why not
15:10:35 <rloo> done :)
15:11:14 <TheJulia> Looks like there is some discussion in the neutron event spec
15:11:25 <etingof> may be line 37 needs to be deleted as well
15:11:50 <TheJulia> But, that really doesn't need to be focused on at the moment since we're not going to be able to move it forward until Stein
15:12:21 <rloo> I updated the BIOS status (L186)
15:12:51 <TheJulia> rloo: awesome
15:13:22 <rpioso> The idrac vendor priority is up-to-date.
15:13:56 <TheJulia> I saw the notes, looks like a new CI job was added for that, \o/
15:14:14 <TheJulia> etingof: Okay, consider it done
15:14:36 <rloo> wrt classic driver removal: is the only thing left, api-ref examples?
15:14:42 <rloo> L243ish
15:14:43 <rpioso> TheJulia: That's correct, thanks to rajinir
15:15:05 <TheJulia> rloo: I believe so... we'll have to confirm with dtantsur|brb
15:15:17 <rloo> thx derekh for doing the zuul v3 playbook refactoring!
15:15:28 <TheJulia> ++
15:15:59 <TheJulia> I think we're good to move on to review priorities for the week. Which I did some cleanup of earlier but didn't remove all of the merged items.
15:16:33 <derekh> rloo: no problem, still more to do, will start the next batch ASAP
15:16:49 <jroll> whoa, ramdisk deploy driver landed, nice work
15:16:49 <TheJulia> Everyone good to move on?
15:16:56 <rloo> derekh: :)
15:17:13 <TheJulia> jroll: yeah, forgot to dance over the weekend :)
15:17:26 <rloo> awesomeness!
15:17:39 <TheJulia> Anyway, lets move on to priorites if there are no objections
15:17:56 <rloo> oh, nice, the nova bug fixes landed too
15:18:09 <TheJulia> #topic Deciding on priorities for the coming week
15:18:15 <rloo> nothing to do I think :)
15:18:31 <TheJulia> #link https://etherpad.openstack.org/p/IronicWhiteBoard
15:18:34 <TheJulia> Line 184
15:18:51 <TheJulia> er,r line 103
15:18:51 <rloo> ? line 100?
15:20:19 <TheJulia> Yeah, 100 is the header
15:20:37 <TheJulia> Anyway, I just deleted things that merged from the list
15:20:43 <TheJulia> Lots of stuff merged last week \o/
15:21:16 <TheJulia> This week looks to largely be documentation and bug fix related since we're essentially feature frozen. I have a few FFE discussion topics up next though :)
15:21:33 <TheJulia> Everyone good with the list or is anyone aware of anything else that we should add for this next week?
15:21:36 <jroll> yeah, list looks good to me
15:21:42 <jroll> I'll add conductor group docs when they're up
15:21:46 <TheJulia> jroll: thanks
15:22:03 <rloo> ++ good
15:22:12 <TheJulia> Okay, discussion time!
15:22:28 <w-miller> hi all, i posted a story this morning for a feature i was looking at working on, regarding adding introspection rules for ironic ports (https://storyboard.openstack.org/#!/story/2003149). i’m not really au fait with the RFE workflow so apologies if this is the wrong time to bring it up, but if anyone had any feedback on the story it would be much appreciated :)
15:23:01 <TheJulia> w-miller: great timing!
15:23:07 <TheJulia> #topic Discussion
15:23:41 <TheJulia> I have three items that we might wish to grant a FFE to on the agenda, The item w-miller brought up happens to be one of them
15:24:17 <TheJulia> The change looks very minor, which is why I included it as a possibility
15:24:33 <TheJulia> errr
15:24:37 <TheJulia> wait a second
15:24:43 <w-miller> ah yeah, i think that’s the change i made last week - but the story is a new one for a different feature
15:24:46 <TheJulia> I was speaking regarding https://storyboard.openstack.org/#!/story/1670768
15:24:46 <rloo> that only affects ironic-inspector?
15:24:49 <jroll> yeah I don't see it on the list :)
15:25:02 * TheJulia got confused
15:25:08 <jroll> I think w-miller is only asking for an RFE review
15:25:09 <TheJulia> sorry :(
15:25:28 <TheJulia> Yeah, he is sekeing an RFE review for 2003149
15:25:32 <TheJulia> Seeking
15:25:50 <w-miller> Yeah :)
15:26:04 <jroll> ok, let's loop back to that
15:26:10 <TheJulia> I'm wondering if we should allow https://storyboard.openstack.org/#!/story/1670768 to be granted a FFE https://review.openstack.org/#/c/585779
15:26:11 <patchbot> patch 585779 - ironic-inspector - Allow nested action value formatting
15:26:11 <openstackgerrit> Merged openstack/networking-generic-switch master: add alias for hpe_comware  https://review.openstack.org/586681
15:26:18 <TheJulia> wow
15:26:21 <TheJulia> okay, wrong link
15:26:26 * TheJulia needs more coffee... or something
15:26:54 <TheJulia> https://review.openstack.org/#/c/585779/
15:26:55 <patchbot> patch 585779 - ironic-inspector - Allow nested action value formatting
15:27:24 <TheJulia> I have no objections, dtantsur|brb indicated he was +1 to it based on his prior statement
15:27:56 <TheJulia> Any objections to granting a FFE?
15:28:26 <jroll> I'm not sure about how I feel about FFEs where the patch was initially proposed... a day before (?) feature freeze?
15:28:54 <rloo> there are two things: rfe needs to be approved, and code needs to be approved
15:29:15 <rloo> the code change itself doesn't look difficult
15:29:22 <rloo> how useful is this?
15:29:44 <rloo> Having asked those questions, I'm good with FFE if we have two cores that are willing to shepherd it along
15:29:55 <jroll> this one seems minimal, so I'm not totally against it, but proposed a day before is the epitome of rushing things :) so I'm -0 I guess
15:30:18 <jroll> basically what rloo said
15:30:35 <TheJulia> It seems like it could be very useful for more complex rules. I'm good with shepherding it
15:30:38 <rloo> yes, it is rushing things. note that the rfe was started in march.
15:30:40 <TheJulia> anyone else?
15:30:57 <openstackgerrit> Merged openstack/networking-generic-switch stable/queens: Set neutron branch name in tox_install.sh  https://review.openstack.org/586611
15:31:05 <w-miller> without the change, a couple of extra ‘boilerplate’ rules are required for the same behaviour - that’s the main point i think
15:31:13 <TheJulia> march 2017
15:31:34 <rloo> even better (or worse)
15:31:51 <TheJulia> Anyway, dtantsur|brb indicated he was +1, so I say we just kind of let things progress there and see what happens.
15:32:05 <rloo> i think for ffe, we need two cores to step up
15:32:31 <TheJulia> Well, dtantsur|brb is also away, so by that we're basically blocked on that
15:32:46 <rloo> you mean, dtantsur|brb coudl be one of the cores?
15:32:53 <TheJulia> rloo: yes
15:32:57 <rloo> who is the other core?
15:33:05 <TheJulia> rloo: I volunteered earlier
15:33:10 <rloo> oh, i missed that.
15:33:14 <TheJulia> Oh, okay
15:33:28 <rloo> OK, so how about FFE oked if we get a second (hopefully dtantsur|brb) core.
15:33:45 <rloo> are we at least good with approving rfe? i guess the two cores can approve that too.
15:33:57 <TheJulia> rloo: works for me.
15:34:07 <rloo> Good. next... ? :)
15:34:34 <TheJulia> Next: The automated_clean feature setting on nodes that yolanda has been working on.
15:35:16 <TheJulia> This involves changes all the way to the API. dtantsur|brb is -0 based upon the fact that it does involve an API change, we can merge it and just not merge client code since that has already been released
15:35:22 <jroll> yeah, I have the same issues with rushing on this one, it was also first proposed july 25
15:35:28 <rloo> is there a link?
15:35:30 <TheJulia> I'm kind of -0 as well, I feel that we are rushing
15:35:34 <jroll> and also has api changes which are irreversible
15:35:37 <jroll> rloo: https://review.openstack.org/#/c/585795/
15:35:38 <patchbot> patch 585795 - ironic - Add automated_clean field
15:35:53 <TheJulia> rloo: Three patches linked on the agenda.
15:36:15 <TheJulia> https://review.openstack.org/586508
15:36:16 <patchbot> patch 586508 - python-ironicclient - Add management of automated_clean field
15:36:19 <rloo> thx. but also good to put it in the minutes, since the agenda will change.
15:36:19 <jroll> I'm -2 tbh, I don't want to rush an API change
15:36:23 <TheJulia> that one can't land
15:36:31 <jroll> #link https://review.openstack.org/#/c/585795/
15:36:31 <patchbot> patch 585795 - ironic - Add automated_clean field
15:36:32 <jroll> there
15:36:34 <jroll> :)
15:37:03 <TheJulia> and https://review.openstack.org/#/c/585991/
15:37:03 <patchbot> patch 585991 - ironic - Add automated_clean field to the node object and API
15:37:15 <TheJulia> I really feel that we need to wait until Stein
15:37:33 <jroll> the RFE also has no info whatsoever
15:37:54 * dtantsur is back
15:38:07 <rloo> It has a client change, it might be useful w/o it, but I don't think it is worth rushing to get this in. is there a serious need for this now?
15:38:39 <TheJulia> jroll: yeah, tripleo context is needed there since there is the resistance to have cleaning by default, but ceph requires it.
15:38:45 <dtantsur> I'll look into the introspection rules RFE if needed
15:39:01 * TheJulia adds that context real quick
15:39:14 <jroll> TheJulia: well, I mean implementation things
15:39:23 <rloo> dtantsur: and review the code for that?
15:39:23 <jroll> what's the API? etc
15:39:26 <dtantsur> rloo: yes
15:39:29 <jroll> how is it used?
15:39:36 <rloo> dtantsur: thx, so FFE granted for that one!
15:39:52 <dtantsur> as to the API addition, I think it's very useful, but I'm quiet against API changes after FF
15:39:55 <jroll> this RFE has zero info that is useful to decide whether it's a good feature to accept
15:39:57 <dtantsur> * quite
15:41:18 <rloo> if you're running tripleO for real, it seems dangerous to NOT clean.
15:41:21 <TheJulia> I think it is necessary, if the context of deployments with automated_clean being disbaled is taken into account.
15:41:29 <rloo> is this just for testing purpoess?
15:41:44 <dtantsur> rloo: no, tripleo undercloud has cleaning off by default :(
15:41:47 <TheJulia> But I think we can just wait until Stein since it involves a client change as well.
15:42:16 <dtantsur> and fwiw it will be mostly useless for tripleo without client changes, either ironicclient or tripleoclient
15:42:24 <rloo> let's wait then. but it would be good to update to provide more info as to why it is useful
15:42:44 <jroll> yeah, we need more than a single sentence for an api change :)
15:42:46 <rloo> (I mean, the rfe has to be approved first, and jroll has asked...)
15:42:47 <dtantsur> I think a real use case is something like diskless nodes
15:42:57 <dtantsur> and the new ramdisk deploy
15:43:07 <jroll> I would especially like to discuss somewhere how safe the None/true/false thing is
15:43:11 <dtantsur> where you simply don't need cleaning for this particular node (but may need for regular ones)
15:43:26 <TheJulia> dtantsur: that is a good point, might not want it if your just spinning ramdisks around... or you may explicitly need it on some nodes
15:43:32 <rloo> we used to say that a spec was needed if there was an API change.
15:43:41 <rloo> I'm fine relaxing that, as long as the story has more info
15:43:48 <TheJulia> rloo: I think it evolved last week, but yeah
15:43:59 <rloo> ok, i think we've discussed this enough now :)
15:44:08 <TheJulia> Agreed!
15:44:09 <TheJulia> Next!
15:45:31 <TheJulia> kaifeng proposed a patch to add the ability to save introspection results to the database, https://review.openstack.org/#/c/583930/ which seems very useful as presently the only option is swift.
15:45:32 <patchbot> patch 583930 - ironic-inspector - Supports database as an introspection data storage
15:46:06 <TheJulia> We've kind of talked about this some in the past, and I'm +1 to the idea
15:46:46 <rloo> ugh. rfe hasn't been approved yet.
15:46:55 <rloo> all of a sudden, the inspector has the spotlight...
15:46:57 <sambetts> I believe we did that at some point in the past, and we remove that because it blew out the DB
15:46:58 <dtantsur> it looks straightforward and benefits the standalone case *a lot*
15:47:12 <dtantsur> sambetts: no, it was storing huge JSONs in node.extra :)
15:47:17 <dtantsur> IIRC
15:47:39 <sambetts> I thought we had stored the inspection results in inspectors DB too, pre-dmidecode
15:47:47 <sambetts> then we added that and it made it HHUUUGE
15:47:57 <dtantsur> I don't think so? but maybe my memory lets me down
15:48:10 <dtantsur> anyway, as long as it's a separate table, it should not be a big hit
15:48:13 <TheJulia> If we did, we should check and hold off
15:48:19 <rloo> where's the spec? details on how to decide whether to store in inspector db or in swift?
15:48:28 <jroll> that's a pretty large change, it seems to me
15:48:44 <jroll> and basic pieces like this make me skeptical that it's anywhere near ready https://review.openstack.org/#/c/514552/21/ironic_inspector/conf/processing.py
15:48:45 <patchbot> patch 514552 - ironic-inspector - Supports database as introspection data storage: p...
15:49:02 <TheJulia> rloo: essentially the storage feature is completely useless without swift, and there are deployments that just don't want swift...
15:49:15 <jroll> oh lord it's making all the storage stuff fully pluggable
15:49:27 * TheJulia takes that as a -1 from jroll
15:49:28 <sambetts> I thought we had saving to disk in there somewhere (we might have removed that too)
15:49:29 <rloo> TheJulia: right, but saying 'store it in inspector's database', doesn't give much detail. is it a new table? what field? what is the size of the field?
15:49:33 <dtantsur> to be fair, I think it was me asking about pluggability
15:49:51 <jroll> and again this RFE is one sentence.
15:49:55 <rloo> i don't think the rfe is ready to be approved.
15:50:17 <rloo> so no FFE for this. unless two cores feel strongly for it.
15:50:19 <jroll> I don't usually review inspector things (sorry), but if I did I would be -1 on an FFE here
15:50:31 <sambetts> we should definatly ask the question about the size of the data too, the json returned by IPA is massive with the dmi data hence we use swift, its fine in a small deployment, but any good sized ironic deployment with inspector :/
15:50:33 <TheJulia> I think that is fair
15:50:59 <TheJulia> Okay, moving on!
15:51:03 <TheJulia> and 10 minutes reamining
15:51:05 <TheJulia> err, 9
15:51:26 <rloo> w-miller had that question earlier on
15:51:44 <TheJulia> #topic RFE Review
15:51:54 <TheJulia> w-miller has brought forth https://storyboard.openstack.org/#!/story/2003149
15:51:54 <w-miller> apologies for the mistiming
15:52:05 <TheJulia> to allow conditionals in inspection rules on ports
15:52:13 <TheJulia> w-miller: no worries :)
15:52:59 <sambetts> now that is a nice RFE
15:53:06 <dtantsur> honestly, we should rewrite introspection rules in some less awkward DSL
15:53:57 <TheJulia> I like it
15:54:12 <TheJulia> the RFE that is
15:54:16 <sambetts> it would be cool if it just worked with the jq like json accessing logic, so we could write conditions for any data in the returned inspection data
15:54:23 <w-miller> the RFE would also be to allow for port actions as well as conditionals - setting/extending an attribute, for example, is also applicable to a port
15:54:24 <dtantsur> I'm -0 on any big additions to what we have now. I'll be +2 and helping with any effort to make it more universal.
15:54:40 <TheJulia> +1 re rewriting, but that is out of scope discussion wise at the moment
15:54:55 <dtantsur> well, for me it's in scope
15:55:17 <TheJulia> I don't think we can take it on, and we would have to support the old syntax and migrate
15:55:24 <TheJulia> s/and/and or/
15:55:25 <dtantsur> as someone who is responsible for this horror :)
15:55:27 <w-miller> mgoddard had rewriting of conditional logic to use Jinja2 as a possible feature for me to look at in future but i think that’s a bridge to be crossed if/when it comes to it
15:55:43 <dtantsur> well, the old syntax is quite rigid, it's not hard to convert from it (yet)
15:56:07 <TheJulia> dtantsur: you know inspecctor the best, which do you feel brings more value to a user?
15:57:14 <dtantsur> I'm afraid the approach we take only fixed some cases. i.e. what to do when you want to update port AND node?
15:58:13 <TheJulia> Two minute warning
15:58:51 <TheJulia> dtantsur: So do you think changing to a less awkward syntax would be better than the RFE for users in the short term?
15:59:05 <w-miller> dtantsur: you mean for the same conditional/within the same rule?
15:59:14 <dtantsur> w-miller: yes; TheJulia: yes.
15:59:31 <dtantsur> w-miller: I'm ready to discuss after the meeting
15:59:51 <w-miller> okay great, thanks
15:59:57 <TheJulia> Sounds good
16:00:14 <TheJulia> Well, if there is nothing else for anyone to bring up, we can call the meeting done.
16:00:20 <rpioso> I would very much appreciate reviews of https://review.openstack.org/#/c/579673
16:00:21 <patchbot> patch 579673 - python-dracclient - Filter out non-ASCII characters on invalid UTF8
16:00:41 <rpioso> Oops, wrong change.
16:00:55 <rpioso> https://review.openstack.org/#/c/545184/
16:00:55 <patchbot> patch 545184 - ironic - Fix iDRAC hardware type does not work with UEFI
16:01:04 <dtantsur> rpioso: will look
16:01:11 <rpioso> dtantsur: ty
16:01:31 <TheJulia> Thanks everyone!
16:01:35 <TheJulia> #endmeeting