15:00:17 <TheJulia> #startmeeting ironic
15:00:18 <openstack> Meeting started Mon Aug 24 15:00:17 2020 UTC and is due to finish in 60 minutes.  The chair is TheJulia. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:18 <TheJulia> o/
15:00:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:21 <rpittau> o/
15:00:22 <openstack> The meeting name has been set to 'ironic'
15:00:23 <JayF> o/
15:00:27 <rajinir> o/
15:00:29 <rpioso> \o
15:00:30 <kaifeng> o/
15:00:31 <ajya> o/
15:00:33 <TheJulia> Good morning ironic!
15:00:35 <erbarr> o/
15:00:37 <bfournie> o/
15:00:39 <bdodd> o/
15:00:41 <arne_wiebalck> o/
15:00:51 <brtknr> o/
15:01:11 <iurygregory> o/
15:01:19 <TheJulia> Our agenda can be found on the wiki, as always.
15:01:22 <TheJulia> #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting
15:01:25 <cdearborn> o/
15:01:29 <TheJulia> #topic Annoucements/Reminders
15:01:55 <TheJulia> A midcycle topic etherpad has been setup
15:01:57 <TheJulia> #link https://etherpad.opendev.org/p/Ironic-Victoria-midcycle
15:02:18 <TheJulia> I believe September 2nd and 3rd are the best looking dates when I last glanced at the doodle
15:02:21 <dtantsur> o/
15:02:26 <TheJulia> rpittau: when are we closing that out?
15:02:34 <rpittau> TheJulia: on wednesday
15:02:50 <rpittau> wanted to give some more time as I know some people were on vacation until today
15:03:06 <TheJulia> Additionally: If there is any update required for non-client libraries, we need to have it in before next week to meet the OpenStack release schedule
15:03:14 <TheJulia> #link https://releases.openstack.org/victoria/schedule.html
15:03:15 <stendulker> o/
15:03:16 <rloo> meeting?
15:03:41 <TheJulia> #link https://doodle.com/poll/pi4x3kuxamf4nnpu
15:03:45 <TheJulia> Is the link for the doodle
15:04:01 <TheJulia> Does anyone have anything else to announce or remind us of?
15:04:35 * TheJulia expects one day for someone to announce a gif of pixie boots on the moon or something
15:04:51 <dtantsur> the PTG registration has opened, I think
15:05:29 <TheJulia> Looks like we had no action items last week, so we should be able skip that part of the meeting.
15:05:42 <TheJulia> Oh!
15:06:19 <TheJulia> It is Forum brainstorming time! If there are items to be dsicussed or items that shoudl be held as forum topics, please add them to the victoria midcycle etherpad and we can further refine and bring those forward.
15:07:46 <TheJulia> I guess we'll be there as a team, the PTG that is?
15:08:55 * TheJulia assumes yes
15:08:59 <TheJulia> Anyway! Onward!
15:09:02 <dtantsur> yep
15:09:04 <iurygregory> ++
15:09:05 <rpittau> yeah
15:09:34 <TheJulia> Moving to subteam status reports
15:09:42 <TheJulia> #topic Review subteam status reports
15:09:48 <TheJulia> #link https://etherpad.openstack.org/p/IronicWhiteBoard
15:10:07 <TheJulia> Starting at line 327
15:10:42 <TheJulia> dtantsur: you mentioned bug fix branch changes, can you write down something under breaking the cycle so we know to do it?
15:11:01 <TheJulia> I'm also not entirely sure what you were saying, so more $words is likely better
15:11:14 <TheJulia> iurygregory: any luck with grenade?
15:11:39 <dtantsur> TheJulia: I'll probably propose a documentation patch instead
15:11:39 <iurygregory> TheJulia, nope =( -P didn't help
15:11:48 <TheJulia> dtantsur: awesome
15:12:04 <iurygregory> maybe worth to discuss during the next midcycle
15:12:21 <TheJulia> iurygregory: sounds like a great topic for the etherpad!
15:12:40 <iurygregory> TheJulia, yeah I will add
15:13:07 <iurygregory> and we would probably need to merge broken so we would switch to zuulv3
15:13:13 <iurygregory> and help the goal
15:14:59 <TheJulia> *sigh*
15:15:11 <TheJulia> well, on the plus side it would help more people see what is going on
15:15:25 <iurygregory> yeah
15:15:34 <iurygregory> compared to before, we can see some problems..
15:15:36 <TheJulia> iurygregory: any news on privsep?
15:15:48 <TheJulia> being able to see the problems is a much better situation!
15:16:04 <iurygregory> I was able to chat with ralonsoh today (he was on PTO)
15:16:38 <iurygregory> the failure we see only in one job is a bit weird, since ironic should have access to all folders we are running the os.link
15:16:42 <rpittau> iurygregory: for privsep I think adding some more logging on the permissions of the dirs/files might help, at least for debugging
15:16:50 <iurygregory> rpittau, yeah
15:17:08 <TheJulia> To me, it seems likely that privsep will slip to next cycle? Any thoughts/concerns around this?
15:17:30 <rpittau> no concerns
15:17:36 <TheJulia> rpioso: thanks for the update on the redfish compatability profile stuffs
15:17:50 <TheJulia> arne_wiebalck: I guess we should talk about next steps for the sig. That could also be a midcycle topic I guess?
15:17:57 <iurygregory> no concerns also, but I will keep updating =)
15:18:25 <arne_wiebalck> TheJulia: yes
15:18:30 <arne_wiebalck> TheJulia: I need to pick this up
15:18:35 <rpioso> TheJulia: You're welcome. And done :)
15:18:45 <arne_wiebalck> TheJulia:  I think we wanted to send out a mail re SIG meetings
15:19:08 <TheJulia> Yeah, I think that was the consensus before you went on PTO
15:19:14 <arne_wiebalck> TheJulia: And a first topic would be what to focus on after the white paper
15:19:33 <arne_wiebalck> TheJulia: There was some input from the opendev event
15:19:45 <arne_wiebalck> TheJulia: I will send out the mail to find a regular slot
15:19:49 <TheJulia> Indeed!
15:19:51 <TheJulia> Awesome!
15:20:18 <TheJulia> Well, is everyone good to proceed to reviewing priorities for the coming week?
15:20:23 <rpittau> let's
15:20:38 <TheJulia> #topic Deciding priorities for the coming week
15:20:41 <TheJulia> #link https://etherpad.openstack.org/p/IronicWhiteBoard
15:20:59 <TheJulia> Starting at line 156
15:21:22 <TheJulia> Any thoughts on droppign the WSME removal changes/refactoring patches for now, they are blocked and we don't have clarity
15:21:53 <TheJulia> dropping them from the list for the next week or two, that is
15:21:55 <rpittau> sounds good, they need revision/rebase anyway
15:22:31 <TheJulia> Okay, removing merged items
15:23:02 <TheJulia> just what we need during our weekly meeting, a netsplit
15:23:21 <dtantsur> \o/
15:23:28 <rpittau> yay
15:23:38 <TheJulia> Looks like it was a small one anyway
15:24:32 <TheJulia> Okay, new items staring at line 230, any objection to adding these?
15:25:17 <iurygregory> I've updated the dhcp-less section
15:25:26 <TheJulia> Oh, that is awesome
15:25:40 <iurygregory> good thing is that we won't need changes on ipa etc
15:25:47 <iurygregory> glean just works
15:25:49 <TheJulia> impressive
15:26:04 * TheJulia hears the lack of objections as agreement to add all the items after line 230
15:26:15 <iurygregory> the only fix we needed is merged https://review.opendev.org/#/c/747144/ (Vinay did some tests and reported this issue)
15:26:16 <patchbot> patch 747144 - ironic - Fix network_data path for dhcpless deployments (MERGED) - 1 patch set
15:29:42 <TheJulia> Okay list updated, Does that work for everyone?
15:30:09 <rpittau> yep
15:30:26 <stendulker> https://review.opendev.org/#/c/742936/
15:30:26 <patchbot> patch 742936 - ironic - Allow HttpImageService to accept custom certificate - 6 patch sets
15:30:31 <TheJulia> Well, then I think it is time to move forward to discussion
15:30:33 <stendulker> Can this be added?
15:30:52 <TheJulia> stendulker: already in the list
15:30:54 <TheJulia> line 189
15:31:01 <stendulker> TheJulia: oh, ok, Thanks
15:31:06 <TheJulia> No worries!
15:32:01 <TheJulia> #topic Discussion
15:32:08 <TheJulia> We have one discussion topic this morning.
15:32:15 <TheJulia> dtantsur: would you like the microphone?
15:32:24 <dtantsur> yep
15:32:37 <dtantsur> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016681.html
15:32:48 <dtantsur> this is a proposal to deprecate and eventually remove the iscsi deploy interface
15:33:07 <dtantsur> with the introduction of the image_download_source option we no longer seem to have use cases that are covered by iscsi but not by direct
15:33:29 <dtantsur> when working on deploy steps, the presence of a similar but not quite same interface implementation was a huge impediment
15:34:02 <TheJulia> I can second the pain of the similar but fundamentally different interfaces causing headaches.
15:34:02 <dtantsur> with a goal of reducing the code base and substantially reducing the testing matrix, I'd like to remove it
15:35:00 <TheJulia> I'm pretty much for this proposal, I'm wondering if anyone is really objecting?
15:35:22 * arne_wiebalck thinks that image_download_source=http for direct should be called indirect
15:35:22 <kaifeng> how about moving it to x-stagging-drivers after removal from ironic?
15:35:25 <JayF> No objection from me. Maybe even a minor squeal of gleeful victory for the agent :D
15:35:47 <TheJulia> arne_wiebalck: propose a patch? :)
15:35:58 <iurygregory> arne_wiebalck, ++
15:36:18 <TheJulia> I actually like that idea and deprecating/removing iscsi does open the door to that
15:36:34 <TheJulia> And it wouldn't need to be a separate interface, just an option
15:36:44 <dtantsur> arne_wiebalck: indirect is how we call it in the CI :)
15:36:44 <TheJulia> well, a separate interface of code
15:37:14 <TheJulia> So I'm not hearing objections, maybe we bring up one more time at the midcycle and if nobody screams by then go ahead and approve the deprecation?
15:37:32 <arne_wiebalck> I think this provides a very smooth transition for iscsi deployments
15:37:53 <arne_wiebalck> We should just be clear it does not address scalability issues
15:37:55 <TheJulia> it might be even easier for it to be an optional upgrade step or logic in the ugprade checker
15:38:35 <TheJulia> time for RFE Review?!?
15:38:52 <TheJulia> arne_wiebalck: ++
15:39:04 <openstackgerrit> Ankit Kumar proposed openstack/ironic master: Enhance certificate verification for ilo harware type  https://review.opendev.org/743490
15:40:01 <TheJulia> #topic RFE Review
15:40:09 <TheJulia> dtantsur: are these all yours? :)
15:40:15 <dtantsur> at least added by me :)
15:40:27 <TheJulia> I need to step away for a moment, if you wouldn't mind :)
15:40:29 <dtantsur> #link https://storyboard.openstack.org/#!/story/2007214 Pass TLS certificate file from ironic to IPA via virtual media
15:40:35 <dtantsur> oops, I scared TheJulia :)
15:40:41 <iurygregory> hahaha
15:40:55 <dtantsur> anyway, the first one addresses the well known problem of TLS between ironic and the agent
15:41:11 <dtantsur> JayF helped me shape it so that it covers both static and automatic TLS
15:41:17 <dtantsur> (thanks!)
15:41:35 <JayF> One thing that on further consideration I wonder if you wanna add to that RFE
15:41:35 <dtantsur> my personal goal is to have the TLS pretty much automatically set up and enabled
15:41:42 <JayF> is the Ironic conductor presenting a client certificate to IPA
15:42:06 <JayF> and using the same mechanism for passing cert/key to IPA to also pass a ca file through to IPA
15:42:43 <dtantsur> yep, I haven't thought about this bit yet
15:42:59 <openstackgerrit> Dmitry Tantsur proposed openstack/ironic-python-agent master: Document in-band deploy steps and add more docs for custom steps  https://review.opendev.org/747753
15:43:18 * TheJulia returns
15:43:41 <dtantsur> JayF: should be easy to add, even later on
15:43:45 <JayF> ++
15:44:05 <dtantsur> any thoughts on the overall RFE? especially if anybody understands TLS better than me?
15:44:53 <JayF> My only concern is that by design, sending a private key over to the agent over and over makes it unlikely to remain secure
15:45:27 <JayF> I think in a perfect world, we'd have Ironic generate a fresh, rapidly-expiring cert/key that's signed by a longer-lived cert
15:45:27 <dtantsur> JayF: I don't think we send the private key, do we?
15:45:36 <JayF> but there's nothing that would prevent that from being done as a later step
15:45:46 <TheJulia> as long as it seems like nothing blocks us in from doign that later, I'm good with it.
15:45:51 <dtantsur> the current proposal offers to generate the key on the agent side and send ironic its public part
15:45:58 <JayF> 2.1 bullet #2: If these are provided, embed them into the virtual media ISO and populate the oslo.service [ssl]cert_file and [ssl]key_file option in /etc/ironic-python-agent/ironic-python-agent.conf.
15:46:34 <dtantsur> ah, the client certificate part
15:46:46 <dtantsur> JayF: what if we split away the client certificates into a new RFE?
15:46:56 <dtantsur> the number of combinations here already gives me a headache
15:46:58 <JayF> but again, it can be a later enhancement so I don't view it as a  blocker. It just makes it difficult to see deployers with strong preexisting certificate infrastructure being wiling to ship around private keys like that.
15:47:01 <JayF> dtantsur: +++
15:47:06 <TheJulia> I like that idea
15:47:13 <TheJulia> (split them into two rfes
15:47:13 <TheJulia> )
15:47:14 <dtantsur> okay, I'll split 2.1 and further improvements into a new RFE
15:47:18 <TheJulia> awesome
15:47:20 <TheJulia> next!
15:47:20 <dtantsur> how is everything else looking?
15:47:33 * dtantsur gives people 1 more minute to add their comments
15:47:56 <TheJulia> I already approved 2008043
15:48:08 <TheJulia> Given it was always the intent for us to support that case
15:48:21 <dtantsur> okay, good :)
15:48:24 <TheJulia> it is just a logical progression at this point
15:48:31 <dtantsur> I'd not mind to have a volunteer for that
15:48:55 <dtantsur> #link https://storyboard.openstack.org/#!/story/2008043 (deploy steps via API) is looking for a volunteer since dtantsur is pretty busy
15:49:06 <TheJulia> ++
15:49:12 <dtantsur> okay, moving to the last one (which is not mind, but I've put it here)
15:49:15 <dtantsur> s/mind/mine/
15:49:25 <dtantsur> #link https://storyboard.openstack.org/#!/story/2008047 Add a feature discovery API to Ironic
15:49:37 <dtantsur> idea by dhellmann based on metal3 experience with ironic
15:49:51 * dtantsur gives people time to read the text
15:50:59 <openstackgerrit> Merged openstack/python-ironicclient master: Allow to pass global request id for remaining objects  https://review.opendev.org/725941
15:51:02 <TheJulia> I generally like the idea, but that seems like it could sprawl into a lot of ocde
15:51:04 <openstackgerrit> Merged openstack/python-ironicclient master: Add release note regarding global_request_id  https://review.opendev.org/732590
15:51:04 <TheJulia> code
15:51:14 <dtantsur> yep. I suspect this is something that would require a spec
15:51:16 <JayF> That API seems like it would be great. It also seems like it would be incredibly complex and a large amount of maintenance.
15:51:47 <TheJulia> because it comes down to providing a concrete answer to the capability matrix of a driver, which means some of that has to be coded in with a union of what can be identified about the node
15:52:12 <JayF> I also suspect there are some capabilities which might be driver-capable but not environment-capable in a way Ironic can't identify
15:52:21 <TheJulia> dtantsur: I concur, JayF: I'm thinking the same
15:52:27 <dtantsur> well, to the best of our knowledge :)
15:52:39 <dhellmann> you could definitely build it incrementally
15:52:46 <dtantsur> dhellmann: o/
15:53:00 <dhellmann> it doesn't have to be able to answer every possible question before it would be useful
15:53:02 <TheJulia> dhellmann: We love incrementalism here in ironic :)
15:53:47 <TheJulia> I'd love a spec that details basic mechanics, maybe an idea of how we would wire the basic internals together, and what the api response should be
15:53:58 <dhellmann> it also doesn't have to give perfect answers, if there are things ironic can't figure out
15:54:26 <dhellmann> I could work with someone on that, but couldn't commit to doing the whole thing
15:54:42 <JayF> Having an oracle that's only sometimes-correct can be worse than having no answer at all. I'm not sure I agree this is a useful item to do incrementally.
15:54:54 <dtantsur> dhellmann: if it ends up being what we want downstream, somebody from our team will pair with you
15:54:59 <dhellmann> JayF: what features could we not answer definitively?
15:55:07 <dhellmann> dtantsur : ++
15:55:27 <dtantsur> (it may be even me, given my experience with adding large stuff to ironic)
15:55:36 <JayF> dhellmann: that'd be something I'd need to think more on, but I think the matrix gets quite a few dimensions around some features
15:55:46 <dtantsur> JayF: agreed about sometimes, but there are things that we can figure out but currently don't
15:56:00 <dtantsur> like, we can look at a node and see if it has any chances of supporting virtual media at all
15:56:05 <dhellmann> I would wait to add features like that to the response set, then.
15:56:08 <TheJulia> Yeah, it could easily become a 3d matrix :\
15:56:12 <dtantsur> by going to its redfish endpoint and seeing if the VirtualMedia resource is there
15:56:19 <dtantsur> and supports a Cd type
15:56:30 <dtantsur> and Manager-to-System mapping is 1-to-1
15:56:33 <TheJulia> well, then there likely also needs otbe license checking
15:56:58 <TheJulia> "it is present" "And it is licensed" and "we can map it properly"
15:56:58 <dtantsur> if it can be checked - awesome!
15:57:08 <TheJulia> yeah
15:57:20 <dtantsur> then we go from "it may or may not support it" to "it's very likely to support it"
15:57:22 <TheJulia> lets focus on a single slice
15:57:40 <TheJulia> at least in terms of a spec and then see how that can be iterated upon in other areas
15:57:50 <dhellmann> sure. a first version may respond based on what ironic supports. a later version might add the license check
15:57:51 * dtantsur adds needs-spec tag
15:58:50 <TheJulia> Well, we seem to only have two minutes left and didn't get to Open Dsicussion
15:58:55 <TheJulia> #topic Open Discussion
15:59:04 <TheJulia> Are there any other items to be discussed/raised?
15:59:15 <JayF> I wanted to toss out if we'd ever considered having an interface specifically for in-band cleaning.
15:59:51 <dtantsur> not sure I get it
15:59:54 <JayF> We have a few drivers which mix-in AgentBase to get agent cleaning support, even if agent isn't used for deployment. Just wondering if that's a good pattern to continue or if there'd be interest in making that a more clean split.
16:00:25 <dtantsur> that makes some sense at first glance; it also gives me a huge headache
16:00:27 <JayF> Right now, DeployInterface handles both deployment and cleaning. There are drivers, such as ramdisk driver, which mix-in agent for cleaning, along with another method for deployment
16:00:28 <TheJulia> JayF: is the thought to be able to have drivers that don't support cleaning?
16:00:36 <TheJulia> or nodes in configurations?
16:00:52 <JayF> TheJulia: I'm thinking stuff like ramdisk driver, a potential future anaconda/kickstart driver, not having to worry about cleaning at all, but just handle the deployment half
16:01:00 <rloo> (also, soon-to-present rfe for an anaconda deploy driver -- not for cleaning...)
16:01:17 <TheJulia> hmm
16:01:22 <rloo> (yeah, what JayF said :))
16:01:23 <JayF> TheJulia: since they mainly are about alternative ways to deploy, and are mostly ambivalent about cleaning -- although today that's implemented as mixing in AgentBase to get agent cleaning
16:01:26 <TheJulia> There is a knob over cleaning on the node
16:01:59 <JayF> I could see someone even wanting to, for instance, use a ramdisk driver with ansible cleaning, perhqps.
16:02:00 <TheJulia> And a long time ago there was discussion of splitting it, but in multitanant environments I suspect it would always be needed, so I'm not sure where the happy medium is at this moment
16:02:21 <dtantsur> we don't need to have no-clean implementation
16:02:23 <JayF> I just can't figure out why in our model deployment and cleaning should be unified.
16:02:26 <JayF> dtantsur: ++
16:02:30 <TheJulia> JayF: I could see that case
16:02:36 <dtantsur> we can have a data migration that'll populate the new field based on the current deploy_interface
16:02:51 <JayF> I'm not even proposing it for sure right now, I'm just curious if it passes the smell test.
16:02:53 <dtantsur> I fully agree, I wonder who can dedicate so much time to make it work
16:02:56 <JayF> Seems like it might be time for it, though.
16:03:10 <JayF> dtantsur: /me would try to volunteer zer0c00l to do it as part of the anaconda work
16:03:12 <JayF> lol
16:03:16 <TheJulia> seems like one of those 50/50 items. It might pass the smell test
16:03:18 <dtantsur> poor zer0c00l
16:03:37 <dtantsur> as somebody who's recently dived into the guts of our agent code...
16:03:38 <TheJulia> heh
16:03:48 <dtantsur> ... I don't want to do it again for such a big refactoring
16:03:50 <dtantsur> :)
16:03:51 * TheJulia lives in that code...
16:03:52 <rloo> it is ok to volunteeer zer0c00l with JayF as backup :D
16:03:59 <JayF> Oh no! A reversal!
16:04:08 <dtantsur> a well detailed RFE would be a good first step
16:04:12 <TheJulia> ++
16:04:23 <TheJulia> Anyway, I guess we're done for today. Thanks everyone!
16:04:28 <JayF> ack; just wanted to make sure the answer wasn't "absolutely not" before taking more effort than a conversation
16:04:30 <JayF> o/
16:04:39 <dtantsur> thanks!
16:05:10 <TheJulia> #endmeeting