15:00:04 <iurygregory> #startmeeting ironic
15:00:04 <opendevmeet> Meeting started Mon Jun 28 15:00:04 2021 UTC and is due to finish in 60 minutes.  The chair is iurygregory. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:04 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:04 <opendevmeet> The meeting name has been set to 'ironic'
15:00:11 <dtantsur> o/
15:00:11 <TheJulia> o/
15:00:12 <rpioso> o/
15:00:13 <iurygregory> Hello ironicers, welcome to our weekly meeting!
15:00:16 <iurygregory> o/
15:00:20 <vmud213> o/
15:00:23 <rloo> o/
15:00:32 <iurygregory> Our agenda can be found in the wiki =)
15:00:34 <iurygregory> #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting
15:01:24 <TheJulia> hmm, do we have enough quorum?
15:01:26 <stendulker> o/
15:01:32 <TheJulia> hmm, maybe
15:01:35 <iurygregory> I was about to ask that TheJulia =)
15:02:03 <TheJulia> maybe just roll forward and if we have any consensuses or decisions to make we might need to be mindful
15:02:28 * rpioso wonders what comprises a quorum.
15:02:31 <iurygregory> yeah, privsep discussion would probably need some consensus =)
15:02:48 <TheJulia> rpioso: generally >8 contributors to me
15:02:54 <iurygregory> we can try to summon arne_wiebalck and JayF :D
15:03:09 <TheJulia> using the magical ironic dust of summoning
15:03:15 <arne_wiebalck> o/
15:03:15 <TheJulia> lol
15:03:20 <iurygregory> it works :D
15:03:23 <rpioso> TheJulia: When did that become a thing :-)
15:03:31 <rloo> JayF is OOO today (AC issues)
15:03:35 * arne_wiebalck does not know how he ended up in this meeting all of a sudden
15:03:43 <TheJulia> rloo: not good :(
15:03:56 <rpioso> arne_wiebalck: lol
15:03:57 <iurygregory> rloo, oh I saw on twitter about the AC =(
15:03:57 <rloo> yeah, i think it is sweltering there...
15:03:59 <ajya> o/
15:04:10 <iurygregory> seems like we have enough people :D
15:04:12 <TheJulia> rpioso: quorum or magical dust?
15:04:21 <iurygregory> #topic Announcements / Reminders
15:04:32 <rpioso> TheJulia: lol quorum?
15:04:40 <TheJulia> rpioso: been a thing for a long time
15:04:47 <iurygregory> Anyone has anything to announce today?
15:05:14 <TheJulia> iurygregory: are we cancelling next week's meeting?
15:05:53 <iurygregory> good question, +1 from me since is holiday in CZ
15:06:31 * iurygregory is not sure about other EU countries
15:06:58 <arne_wiebalck> I don't think it is a holiday in FR or CH.
15:07:16 <iurygregory> is also holiday in the US according to TheJulia
15:07:17 <arne_wiebalck> Or DE.
15:07:37 <iurygregory> so I don't think we will have enough quorum
15:07:50 <arne_wiebalck> I am totally fine with cancelling the meeting ofc :)
15:08:28 <TheJulia> I think we should just cancel next week's meeting
15:08:46 <TheJulia> unless someone wants to run it next week
15:08:50 <iurygregory> yeah
15:09:22 <rpioso> Independence from Meeting Day?
15:09:28 <TheJulia> rpioso: +1
15:09:38 <iurygregory> lol :D
15:09:53 <iurygregory> I don't see any objections so ...
15:10:17 <iurygregory> #agreed no upstream meeting on July 5th
15:10:33 <iurygregory> #info no upstream meeting on July 5th
15:10:49 <iurygregory> I will send an email to the openstack-discuss
15:11:03 <iurygregory> #topic Review action items from previous meeting
15:11:15 <iurygregory> We don't have any action items from last meeting, skipping
15:11:27 <iurygregory> #topic Review subteam status reports
15:11:33 <iurygregory> #link https://etherpad.opendev.org/p/IronicWhiteBoard
15:11:41 <iurygregory> starting on L65 =)
15:13:31 <iurygregory> zer0c00l, you around? =)
15:14:03 <iurygregory> just wondering if there are any plans to test anaconda deployment in CI upstream
15:15:52 <TheJulia> iurygregory: he typically is not up for another hour I think
15:16:06 <TheJulia> I know, he wants to though
15:16:14 <iurygregory> ack =)
15:16:27 <rloo> if there are no plans, then we need to add plans. if i remember, i'll ask him
15:16:37 <iurygregory> rloo, tks!
15:16:39 <arne_wiebalck> TheJulia: for the nova ironic driver item, I will check with our nova experts if they would like to follow up upstream
15:17:42 <iurygregory> we have updates on every item, should we move to the next topic?
15:18:43 <iurygregory> moving on
15:18:45 <iurygregory> #topic Deciding on priorities for the coming week
15:18:49 <TheJulia> arne_wiebalck: ack, there really is no reason for it to hit ironic for that query at all given the cache should have it and be able to properly fulfill it
15:19:01 <iurygregory> #link https://tinyurl.com/ironic-weekly-prio-dash
15:19:30 <arne_wiebalck> TheJulia: yes ... Belmiro plans to follow up
15:19:35 <TheJulia> arne_wiebalck: ack
15:19:41 <arne_wiebalck> TheJulia: with nova upstream
15:19:50 <arne_wiebalck> TheJulia: no timelines yet
15:20:07 <TheJulia> I'd like to add https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/797521 to the list for the week
15:20:34 <TheJulia> There is a dependency on a tempest fix, but the tempest fix already has a +2
15:20:34 <dtantsur> I'd appreciate adding https://review.opendev.org/c/openstack/ironic/+/797508 and https://review.opendev.org/c/openstack/ironic/+/797875
15:20:55 <TheJulia> dtantsur: seems reasonable
15:21:17 <iurygregory> ++ a quick look to all patches they are ok to have the hashtag
15:22:30 <TheJulia> done
15:23:09 <iurygregory> more patches? :D
15:23:25 <iurygregory> last call XD
15:24:24 <iurygregory> sounds like we can move to Discussion
15:25:31 <iurygregory> #topic Discussion
15:25:55 <iurygregory> we have one topic today from dtantsur and I about oslo-privsep
15:26:02 <iurygregory> #link https://review.opendev.org/c/openstack/ironic-lib/+/745536
15:26:39 <iurygregory> dtantsur, if you want to give context about your concerns re privsep it would be good =)
15:26:57 <dtantsur> IPA has half-monkey-patched stdlib
15:27:27 <dtantsur> I don't feel easy about launching a new process with a clone of IPA and using it for execing other processes as root, although IPA is always as root
15:27:47 <dtantsur> so I wonder if we could have a global switch to turn privsep into regular calls without forking
15:28:12 <TheJulia> hmmmm
15:28:21 <rloo> so replace rootwrap with privsep and add an option to turn off privsep
15:28:22 <TheJulia> This *does* make a lot of sense
15:28:42 <dtantsur> rloo: pretty much
15:29:18 <iurygregory> I know nova has a few commands that they run as non-privilege
15:29:31 <iurygregory> I don't think they have a config option
15:29:40 <dtantsur> as a bonus, make dependency on privsep conditional for the sake of smaller IPA images
15:30:04 <dtantsur> note that I don't mean a config option in a sense of oslo.config, but rather something like a global variable that can be set early
15:30:24 <dtantsur> (it could go through oslo.config as well in case someone wants to run IPA as non-root (LOL)?)
15:30:26 <TheJulia> dtantsur: ++
15:31:04 <iurygregory> I'm trying to understand the part of global variable that can be set early...
15:32:08 <TheJulia> likely just something in the ipa code very early on which declares the global
15:32:19 <rloo> i'm good with that. as long as we default to privsep on.
15:32:47 <dtantsur> import ironic_lib; ironic_lib.USE_PRIVSEP = False
15:32:56 <TheJulia> ++
15:33:41 <rloo> Any security issues with turning it off? security is not my forte...
15:34:09 <iurygregory> if it's off it will use rootwrap by default no?
15:34:28 <dtantsur> let's drop rootwrap maybe?
15:34:34 <dtantsur> I don't see why we would keep both
15:34:45 <iurygregory> only after we have all the support in privsep I would say =)
15:34:52 <dtantsur> if privsep is off, a command is executed as it is. if the service is not root - touch luck
15:35:04 <arne_wiebalck> off is only for IPA which is running as root anyway, no?
15:35:17 <dtantsur> right
15:35:27 <TheJulia> arne_wiebalck: I think that is what we're all thinking
15:35:47 <TheJulia> at least, that is my momentary perception of consensus
15:36:42 <rloo> based on this, i think the idea is to remove rootwrap support: https://review.opendev.org/c/openstack/governance/+/718177
15:37:22 <iurygregory> yeah correct, we can drop rootwrap after we swtich all things to privsep
15:37:49 <arne_wiebalck> my point was to answer rloo's question: since off is only for IPA, and IPA is root anyway, there *should* be no security concerns ... but then security is not my forte either :)
15:38:27 <rloo> we can either 1. replace rootwarp with privsep, then add some global thingy to turn off privsep; or 2. do both at the same time.
15:38:38 <TheJulia> So we need to consider use/purpose, the driving purpose was to secure and delineate access for services which live for a long time serving/supporting user workloads. IPA... kind of not that at all.
15:38:55 <rloo> (wondering if someone has some weird usecase with ipa)
15:39:04 <TheJulia> rloo: yes... kind of
15:40:30 <TheJulia> But that would be a *highly* restrictedmode which doesn't yet exist
15:40:40 <rloo> I think we've agreed then? replace rootwrap with privsep, add a way to turn off privsep
15:40:45 <TheJulia> so I think we're safe to proceed and move forward
15:40:52 <rloo> ++
15:41:06 <dtantsur> yep
15:41:10 <iurygregory> sounds like a plan
15:41:31 <iurygregory> I will update the status with the info of the discussion =)
15:42:27 <iurygregory> moving to our meeting topic
15:42:33 <iurygregory> #topic Baremetal SIG
15:42:37 <iurygregory> #link https://etherpad.opendev.org/p/bare-metal-sig
15:42:45 <iurygregory> arne_wiebalck, do you have anything for the SIG?
15:43:02 <arne_wiebalck> Next meeting is Tuesday July 13, 2021 at 2 PM UTC
15:43:12 <arne_wiebalck> with TheJulia on Bifrost
15:43:24 <TheJulia> \o/
15:43:29 <arne_wiebalck> (announcing now as we do not have a meeting next week)
15:43:37 * TheJulia puts calendar items on her calendar to remind herself
15:43:40 <iurygregory> #info Next Baremetal SIG meeting is Tuesday July 13, 2021 at 2 PM UTC - TheJulia talking about Bifrost
15:43:52 <iurygregory> tks arne_wiebalck and TheJulia !
15:44:02 <iurygregory> #topic RFE review
15:44:12 <iurygregory> We have one RFE from vmud213 - Add a clean/deploy step to add 3rd party CA certificates to iLO
15:44:19 <iurygregory> #link https://storyboard.openstack.org/#!/story/2008784
15:44:54 <vmud213> Hi
15:45:25 <TheJulia> hi vmud213
15:45:55 <dtantsur> vmud213: the idea is great (modulo s/ilo_ca_certs_dir/ca_certs_dir), ideally the RFE should spell out the clean/deploy steps names
15:45:56 <vmud213> does anyone has any questions or any clarification needed on this. Please let me know
15:46:17 <vmud213> dtantsur: Ok.Sure. i will update.
15:46:19 <vmud213> one question.
15:46:37 <TheJulia> vmud213: quick question, by add is it just replacing or appending ca certificates?
15:46:40 <vmud213> there are 2 steps for adding and removing. Should i pursure both as part of the same patch?
15:46:53 <TheJulia> vmud213: That answers my question then
15:47:02 <TheJulia> or my next question. Yes, ideally both at the same time
15:47:04 <vmud213> ThJulia: It's appending the certificate
15:47:17 <iurygregory> ++ to both at same time
15:47:18 <vmud213> perhaps there is lot of confusion on the naming
15:47:20 <TheJulia> Also, it looks like you've got a wired-in do on deploy anyway step, which I'm not sure we want by default
15:47:37 <vmud213> actually we need these CA certificates to be added to iLO.
15:48:23 <TheJulia> So, you may, but maybe just run the steps anyway as part of the step framework instead of always invoke?
15:48:57 <stendulker> @TheJulia: without matching certificates ilo-https boot inetrface will not work.
15:48:59 <TheJulia> maybe that means a third, hybrid step
15:49:20 <dtantsur> you seem to have a chicked-and-egg problem then?
15:49:22 <TheJulia> "check-set-certificates" or something which could be enabled by default with a deploy_step value
15:49:34 <stendulker> dtantsur: kind of, yes.
15:49:47 <dtantsur> you need IPA to use cleaning but the UEFI boot cannot work without the right certificates
15:49:49 <TheJulia> I guess the thing we want to avoid as much as possible, is things requiring custom boot interface code
15:50:15 <stendulker> but these certificate addition is kind one-time thing
15:50:35 <stendulker> unless one wants to remove/replace them after teardown
15:50:57 <dtantsur> you probably need to rework it to become a step that doesn't need the ramdisk
15:51:03 <dtantsur> otherwise its usability is questionable
15:51:36 <stendulker> I think, it does not need ramdisk, bit needs a reboot to become effective.
15:51:55 <TheJulia> hmm, it was being done before too,  I guess if we can use the step code it becomes more clear for operators, and it can be ensured to be in a working state
15:52:08 <dtantsur> set_async_step_flags relies on IPA
15:52:31 <dtantsur> additionally, the only way to avoid IPA right now is to explicitly mark your step as not requiring ramdisk AND explicitly request cleaning without IPA
15:52:45 <TheJulia> ugh, yeah
15:52:51 <vmud213> dtantsur: the steps can be executed as part of different boot interface
15:53:09 <dtantsur> so, start with iPXE, then switch to UEFI?
15:53:17 <iurygregory> O.o
15:53:17 <TheJulia> vmud213: we *really* don't want different boot interfaces, it complicates support matrixes and hurts adoption of driver specific interfaces
15:53:21 <dtantsur> going to be confusing. and if you have iPXE working, why bother with UEFI?
15:53:58 <vmud213> dtantsur: that is the capability of the hardware that we are leveraging
15:54:01 <TheJulia> lets take a step back
15:54:48 <TheJulia> I think *we* generally agree the idea is good, it needs a little more verbosity to explain the problem and what is going to be done to solve it. The patch itself, is going to take a little more back and forth and context to understand, because ultimately multiple things are attempting to be done here
15:55:06 <iurygregory> agree ^
15:55:12 <dtantsur> ++
15:55:23 <TheJulia> and if one of those things is distinctly or drastically different or the problem cascades, then we need to cover that in the RFE, or maybe a separate discussion
15:55:36 * TheJulia hopes I'm making sense
15:55:58 <dtantsur> yeah, and we need to keep in mind the dependency between cleaning and IPA
15:56:07 <vmud213> TheJulia: I think i understood what you are saying
15:56:29 <vmud213> But the point is
15:56:40 <vmud213> in any case this is all about adding the certificates
15:56:48 <vmud213> which is needed in any case
15:57:15 <TheJulia> Apparently it is needed, but there are different ways to approach that, and ideally if it is required, it shouldn't be a deploy or cleaning step set to 0
15:57:21 <TheJulia> well, priority set to 0
15:57:31 <vmud213> the iLO or any other BMC can not accept the certifciates unless it is properly configured with root CA who issued them
15:57:43 <vmud213> so i wonder in the case of iPXE how this solves the problem
15:57:46 <TheJulia> The step framework should be used wherever possible to facilitate these sorts of things
15:57:51 <dtantsur> iPXE doesn't use HTTPS
15:58:00 <TheJulia> I'm really confused where ipxe came into this discussion
15:58:11 <TheJulia> this is basically like virtual media booting right?
15:58:12 <dtantsur> actually, a lot of virtual media implementations don't verify certificates, but that's another story
15:58:21 <TheJulia> BMC needs to validate the certificate of the webserver? yes?
15:58:45 <dtantsur> the UEFI boot interface already calls add_certificates. I wonder why it's not enough.
15:59:02 <TheJulia> dtantsur: well, apparently a reboot is required based on what stendulker said
15:59:04 * dtantsur is interested in this topic because we probably need to do the same for Redfish eventually
15:59:12 <TheJulia> I guess, all the confusion is just more evidence we need a more verbose RFE
15:59:17 <dtantsur> TheJulia: booting IPA is a rebootr
15:59:30 <iurygregory> we have less than 1min, I think we can just end the meeting and keep the discussion right? =)
15:59:36 <dtantsur> yep
15:59:40 <TheJulia> dtantsur: true
15:59:57 <TheJulia> dtantsur: which makes me wonder...why the clean steps?!
15:59:58 <vmud213> dtantsur: the boot interface calls the certificate only to booot the deploy_iso configured ehind the https
15:59:58 <iurygregory> tks everyone!
16:00:00 <iurygregory> #endmeeting