15:00:32 <TheJulia> #startmeeting ironic
15:00:32 <openstack> Meeting started Mon Nov 25 15:00:32 2019 UTC and is due to finish in 60 minutes.  The chair is TheJulia. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:33 <TheJulia> o/
15:00:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:35 <etingof> o/
15:00:37 <openstack> The meeting name has been set to 'ironic'
15:00:38 <iurygregory> o/
15:00:39 <mkrai> o/
15:00:40 <TheJulia> I guess it is meeting time!
15:00:42 <rpioso> o/
15:00:48 <stendulker> o/
15:00:49 <rpittau> o/
15:00:51 <kaifeng> o/
15:00:51 <arne_wiebalck> o/
15:00:57 <cdearborn> o/
15:01:12 <mgoddard> \o
15:01:37 <TheJulia> We have a couple items on our agenda today. Please quickly review the agenda, I did do some clean-up and if I accidently removed an item that was not carried over from last week, please let me know
15:01:39 <TheJulia> #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting
15:01:59 <jerrywang> o/
15:02:07 <TheJulia> #topic Announcements / Reminders
15:02:27 <iurygregory> didn't we discussed about the Mid Cycle and the Ops Meetup in London ?
15:02:35 * dtantsur is lurking
15:02:59 <TheJulia> iurygregory: coming back to it, hopefully people have talked inside their orgs a little bit to get a feeling if what has been proposed works
15:03:13 <iurygregory> TheJulia, make sense ++
15:03:15 <iurygregory> =)
15:03:18 <TheJulia> I don't think I have any announcements this week.
15:03:29 <iurygregory> maybe say we started dropping Py2.7?
15:03:47 <mkrai> iurygregory, ++
15:03:58 <TheJulia> #info Support for Python 2.7 testing started being dropped last week. If you see any patches, please review them.
15:04:25 <TheJulia> Additionally, There are a few specs in ironic-specs that could use some eyes from the community
15:04:32 <dtantsur> yep, and the actual compatibility will be gone as well
15:04:40 <dtantsur> now right away, but soon probably
15:04:51 <TheJulia> dtantsur: will break regardless very quickly
15:05:09 <iurygregory> dtantsur, i think after we drop on all projects
15:05:14 * etingof just updated his L3 spec and seeks for feedback
15:05:14 <TheJulia> Does anyone have anything they would like to remind us of or announcements to raise?
15:05:17 <iurygregory> (maybe on Phase2)
15:06:17 <TheJulia> I'd like to cut a release very soon fwiw, so it could make sense to get all of the python2.7 related stuff taken care of before then. Anyway that doesn't really matter at the moment.
15:06:36 <TheJulia> Okay, well I guess we're good to move along
15:07:00 <TheJulia> Next would be action item review, I don't think we had any last week. Checking
15:07:04 <dtantsur> iurygregory: sooner, I'm afraid
15:07:21 <TheJulia> No action items
15:07:29 <iurygregory> dtantsur, I'm ok i was just wondering the effect on the clients =)
15:07:48 <TheJulia> #topic Review subteam status reports
15:08:32 <TheJulia> The subteam list needs to be updated based on priorities, which needs to be merged, just giving some additional time for any last minute feedback.
15:08:38 <TheJulia> #link https://etherpad.openstack.org/p/IronicWhiteBoard
15:08:49 <TheJulia> Line 260
15:09:09 <TheJulia> #link https://review.opendev.org/#/c/694704/
15:09:09 <patchbot> patch 694704 - ironic-specs - Ussuri project priorities - 5 patch sets
15:09:54 <TheJulia> dtantsur: could you add your IPA patch to the replacing WSME list?
15:10:34 * TheJulia adds software raid5/6 to the raid topic
15:10:50 <dtantsur> done
15:11:01 * dtantsur is in a zombie mode, sorry
15:11:11 <TheJulia> zombie status is acceptable :)
15:11:46 <iurygregory> "monday mode"
15:12:18 <TheJulia> dtantsur: I saw someplace you mentioned somewhere that zeroconf had been updated with ipv6 support completed. Does that necessitate any ironic changes or should it just be ensure that it gets into the available window with constraints?
15:12:42 <dtantsur> yep, there is an ironic-lib patch
15:12:50 <TheJulia> awesome
15:13:00 <dtantsur> it's on the list
15:13:05 <TheJulia> awesome, thanks
15:13:23 <TheJulia> I guess we'll need to get that merged and released very soon?
15:13:57 <TheJulia> dtantsur: thanks for putting that on the proposed chagnes for review list
15:14:59 <arne_wiebalck> the retirement spec has been updated with the discussion from the PTG ... if anyone has time / is interested
15:15:05 <TheJulia> arne_wiebalck: thanks!
15:15:13 <rpittau> dtantsur TheJulia the problem with that patch as I see it is that it breaks compatibility with python 2, should we wait for all the other py2.7 dropping patches to merge first ? at least related to whatever uses ironic-lib
15:15:16 <TheJulia> I think we're good, shall we proceed to priorities for the coming week
15:15:49 <TheJulia> rpittau: Likely, we're going to have to have major version revs all around I think...
15:16:54 <rpittau> yeah
15:16:54 <TheJulia> So we can release newest ironic-lib and I guess block it from constraints for a few days while the rest of the py2.7 stuff merges
15:17:12 <rpittau> ack
15:17:40 <TheJulia> #topic Deciding on priorities for the coming week
15:17:57 <TheJulia> #link https://etherpad.openstack.org/p/IronicWhiteBoard
15:18:09 <TheJulia> Line 163
15:18:21 * TheJulia wonders if zane needs some IRC attachment glue :(
15:18:59 <TheJulia> the two proposed look reasonable to me. I kind of want to propose the raid 5/6 patch I put up, but it failed standalone tests and I don't know why yet
15:19:42 <dtantsur> TheJulia, rpittau, we can just wait with ironic-lib release until the consumers are ready
15:20:06 <TheJulia> it feels like a chicken/egg sort of thing to me
15:20:10 <TheJulia> but that is also true
15:20:53 <iurygregory> I've added a link for the patches that are open for Drop Py27
15:21:01 <TheJulia> dtantsur: would it make sense to put a reno into ironic and block it on ironic-lib release for zeroconf ipv6 changes?
15:21:06 <TheJulia> iurygregory: I saw, thanks!
15:21:17 <iurygregory> sorry for the long link =)
15:21:20 <TheJulia> No worries!
15:21:38 <TheJulia> Does anyone have anything else to add?
15:22:38 <TheJulia> I guess the list looks good for me so if we're good we can proceed
15:23:55 <rpittau> let's
15:24:09 <TheJulia> Good, I was starting to look at how I could get crickets delivered  :)
15:24:17 <iurygregory> ++ to move
15:24:20 <TheJulia> Onward!
15:24:25 <TheJulia> #topic Discussion
15:24:52 <TheJulia> First item, a returning item from last week is having a mid-cycle. I believe arne_wiebalck wants to firm the dates up so he can book space
15:24:53 <rpittau> crickets over IP ? (sorry)
15:25:16 <TheJulia> rpittau: hmm. Cricket over IP over Avian Carrier?
15:25:32 <arne_wiebalck> it'd be good to decide if we want to have a mid-cycle here at CERN.
15:25:47 <rpittau> yes!
15:25:55 * iurygregory can't confirm I couldn't talk to my manager but the dates are good I would say =)
15:26:14 <iurygregory> arne_wiebalck, we want ofc XD
15:26:23 * etingof is in the same boat with iurygregory
15:26:28 <TheJulia> I think it is a good idea, I've gotten some "seems like it should be reasonable" feedback from my management, but only discussion in passing really
15:26:34 <TheJulia> I'm sure that can firm up.
15:27:25 <arne_wiebalck> do we need a minimum attendance before we say it's on?
15:28:08 <arne_wiebalck> how about we give it another week?
15:28:16 <TheJulia> Hmm, devopsdays Geneva is Febuary 24th-25th
15:28:31 <arne_wiebalck> uh, didn't know  ...
15:28:35 <rpittau> oh interesting
15:29:36 * iurygregory would say change to 26 27 the mid-cycle
15:30:06 <TheJulia> arne_wiebalck: could be additional reasoning. Anyway I think if you reserve the space, and if you have a sign-up or attendance tracking thing that we could use instead of an etherpad?
15:30:23 <rpioso> Will remote participation be possible?
15:30:34 <arne_wiebalck> https://indico.cern.ch/event/863986/
15:30:40 <arne_wiebalck> rpioso: yes
15:30:52 <TheJulia> iurygregory: that may be logical or not. I suspect we should look at hotel capacity/access
15:30:58 * TheJulia adds mental note to check that in the next day or so
15:31:06 <iurygregory> TheJulia, agree =)
15:31:15 <TheJulia> Anyway, seems like we should proceed onward to the next discussion topic
15:31:15 * arne_wiebalck will check the room for 26/27
15:31:27 <TheJulia> iurygregory the topic is yours
15:31:47 <iurygregory> ok o/
15:32:25 <iurygregory> IPA using UEFI + Secure Boot https://storyboard.openstack.org/#!/story/2006847
15:33:23 <iurygregory> I've talked with many people, and we have different ideas on how we should solve this, and I was thinking that the topic also has many different use cases and it would be worth a discussion about it
15:33:48 <iurygregory> TheJulia, if I'm correct we can't use mokutil because we run under chroot?
15:34:23 <iurygregory> that would be the reason we can't ensure after we reboot?
15:34:48 <TheJulia> iurygregory: no, because IPA's state may not be the state desired for the running instance
15:35:41 <TheJulia> so we may be network booting legacy bios mode or uefi mode (depending on hardware and configuration) and then trying to use that transient state to infer the desired final operating mode of the instance
15:37:01 <iurygregory> if the operator wants to use secure boot this is something he would set on configuration that would be available for the ipa?
15:37:51 <TheJulia> In theory, but it would take some work for the operator. They wouldn't really be able to use iPXE without getting signed binaries
15:37:59 <TheJulia> which is doable, but takes some work
15:38:47 <TheJulia> I guess there is just no guarentee between the two states so use of current state to determine post reboot state is not really an option. Which is why I've been thinking we can only look at data on disk
15:39:07 <TheJulia> Does anyone have any thoughts on this?
15:39:12 <iurygregory> also while talking with some people I got the feedback that call gru2-install on non-SB case it's not ok since this could prevent SB to be enable later..
15:39:22 <TheJulia> indeed
15:41:09 <TheJulia> iurygregory: it feels like a chart with options and constraints needs to be created to visually map this out
15:41:42 <TheJulia> Maybe something in https://ethercalc.openstack.org/ and use that to discuss options?
15:41:55 <TheJulia> so it is slightly more visual?
15:42:23 <iurygregory> make sense to me
15:42:42 <TheJulia> Okay, then seems like maybe we can return to this item next week or hopefully settle it this week :)
15:42:47 <iurygregory> yeah =)
15:42:48 <TheJulia> Are we good to move on?
15:42:51 <iurygregory> ++
15:42:53 <TheJulia> Okay!
15:43:00 <TheJulia> #topic Baremetal SIG
15:43:24 <TheJulia> arne_wiebalck: Any updates? I've not heard anything since my last discussion with the foundation about trying to encourage use case contribution to the whitepaper
15:43:40 <arne_wiebalck> I haven't heard from the foundation or any potential authors ... have you?
15:43:46 <TheJulia> But I know some people were likely at kubecon last week, and we're unlikely to see any action in the states since many have two days off this week.
15:43:48 <arne_wiebalck> Ah :)
15:44:09 <arne_wiebalck> Too early to chase ?
15:44:12 <TheJulia> perhaps
15:44:16 <arne_wiebalck> ok
15:44:21 <TheJulia> I'm happy to send a follow-up email this week though
15:44:27 <rpioso> Any word on the possibility of remote participation?
15:44:28 <arne_wiebalck> sounds good
15:44:41 <TheJulia> rpioso: what do you mean?
15:45:00 <rpioso> TheJulia: In the ops meetup.
15:45:15 * iurygregory I was thinking it was for the mid-cycle
15:45:16 <TheJulia> rpioso: I have no idea, it may be worthwhile to ask those folks
15:45:18 * rpioso is his manager's messenger :-)
15:45:32 <TheJulia> rpioso: do you have the link for their planning/discussion etherpad?
15:45:53 <arne_wiebalck> https://etherpad.openstack.org/p/LON-2020-OPS-TOPICS
15:45:59 <TheJulia> arne_wiebalck: thanks!
15:46:01 <rpioso> TheJulia: I do now :-)
15:46:10 <rpioso> arne_wiebalck: Thank you!
15:46:12 <TheJulia> Awesome, I guess we're good to proceed then
15:46:32 <TheJulia> #action TheJulia to follow-up with foundation folks regarding use case follow-up
15:46:39 <TheJulia> Just so I hopefully don't forget
15:47:43 <TheJulia> #topic RFE Review
15:47:48 <TheJulia> We have two proposed RFEs to review
15:48:01 <TheJulia> The first is to support compressed images
15:48:03 <TheJulia> #link https://storyboard.openstack.org/#!/story/2006936
15:48:29 * kaifeng thought we already have
15:48:38 <TheJulia> We have some if done in the qcow2 file...
15:48:58 <kaifeng> I think the same is true for compressed
15:49:35 <TheJulia> I'm not sure, but there is a possibility that some of it could be orphaned code or not in the path that is being used
15:49:45 <kaifeng> there is no difference to convert a compressed/uncompressed image to raw if memory serves.
15:50:14 <TheJulia> I think qemu-convert can read stdin... I think
15:50:34 <etingof> why can't we keep the images as-is, but compress them just for transmission (HTTP)?
15:51:04 <TheJulia> Well... people sometimes don't support that and the issue is it is files on a webserver that have already been compressed
15:51:14 <rpittau> it would add the compress time to the transmission time in that case
15:51:16 <TheJulia> That may or may not support passing the stream arguments.
15:51:34 <kaifeng> if i understand the story correct, it means compressed user-image
15:51:45 <TheJulia> yes
15:51:54 <etingof> ramdisk can't be that large ;)
15:52:06 <kaifeng> i believe we just need to turn off stream raw
15:52:11 <TheJulia> I've heard of 2+ GB IPA ramdisks
15:52:13 <kaifeng> and it will work
15:52:39 <TheJulia> hmm, good point
15:52:42 <TheJulia> We need more information
15:52:58 <TheJulia> I've asked shardy to update the RFE with some more contextual information
15:54:28 <TheJulia> Next RFE!
15:54:31 <TheJulia> #link https://storyboard.openstack.org/#!/story/2006910
15:54:37 <TheJulia> A one-shot deployment API
15:56:25 <TheJulia> It seems reasonable to me, and while it is not a spec and it is an IPA change, it would be a virtual endpoint, so I guess I'm good with it and seeing where it ends up
15:57:05 * dtantsur is back, sorry
15:57:15 <TheJulia> dtantsur: welcome back
15:57:30 <iurygregory> the RFE description is almost a spec =)
15:57:41 <dtantsur> I like detailed RFEs ;)
15:57:50 <TheJulia> Indeed :)
15:57:54 <dtantsur> the deployment API has been discussed.. many times. this work is loosely based on sambetts' ideas.
15:58:51 <TheJulia> I'm good with it, any objections or support for it?
15:59:05 <iurygregory> +1
15:59:27 * etingof is confused by "These resources will be purely virtual: they won't be backed by database objects." followed by "Deployment objects" description
15:59:48 <mgoddard> will we switch the nova virt driver to use it?
15:59:52 <dtantsur> etingof: these are objects in the API, but there is no database objects behind them
15:59:56 * kaifeng needs more reading, but definitely no objection for new ideas
15:59:59 <dtantsur> mgoddard: there are a few words about it there :)
16:00:09 <dtantsur> essentially, nova may benefit from a multi-step approach
16:00:18 <mgoddard> dtantsur: skimmed for them :)
16:00:20 <TheJulia> dtantsur: single step you mean?
16:00:37 <dtantsur> TheJulia: well, I think nova is a special consumers who may actually use a multi-step approach
16:00:47 <dtantsur> e.g. I think VIF attachment is separate
16:01:00 <etingof> will it play well with HA? what happens if conductor dies along the way?
16:01:10 <TheJulia> dtantsur: it is... I guess yeah it may be best to stay multi all along
16:01:16 <TheJulia> etingof: deployment dies
16:01:16 <dtantsur> etingof: there is no state in the conductor, it's all taken from the nodes
16:01:30 <dtantsur> it's essentially what metalsmith implements on the client side, but moved to ironic-api
16:01:37 <TheJulia> etingof: or to be more precise, the deployment is moved to deploy failed
16:01:45 <TheJulia> if it is not completed.
16:02:12 <dtantsur> right, the same way it's done now
16:02:34 <TheJulia> yup
16:03:08 * dtantsur grabs whiskey while waiting for objections
16:03:13 <etingof> could one deploy twice?
16:03:26 <TheJulia> Anyway, we're past our ending time. If there are no objections, I think that is the end of our meeting
16:03:28 <etingof> if it's all virtual, I suspect no state
16:03:30 <mgoddard> dtantsur: objection! pass the whiskey along
16:03:34 <dtantsur> :D
16:03:41 <dtantsur> etingof: how do you imagine it?
16:03:43 <TheJulia> mgoddard: Very wise :)
16:03:59 <TheJulia> I guess you guys can discuss
16:03:59 <etingof> double curl
16:04:08 <TheJulia> Well if there is nothing else, thanks everyone!
16:04:11 <dtantsur> etingof: same is right now: the 2nd request gets CONFLICT
16:04:17 <dtantsur> thanks TheJulia
16:04:24 <etingof> no racing?
16:04:27 <TheJulia> task.node.save() occurs when the lock is raised
16:04:38 <TheJulia> the second connection would read the db and see the lock
16:04:43 <dtantsur> etingof: it's build around nodes internally
16:04:54 <dtantsur> so usual node locks (and our beloved Node locked error) apply
16:04:56 <TheJulia> #endmeeting