15:00:32 #startmeeting ironic 15:00:32 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 o/ 15:00:34 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:35 o/ 15:00:37 The meeting name has been set to 'ironic' 15:00:38 o/ 15:00:39 o/ 15:00:40 I guess it is meeting time! 15:00:42 o/ 15:00:48 o/ 15:00:49 o/ 15:00:51 o/ 15:00:51 o/ 15:00:57 o/ 15:01:12 \o 15:01:37 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 #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting 15:01:59 o/ 15:02:07 #topic Announcements / Reminders 15:02:27 didn't we discussed about the Mid Cycle and the Ops Meetup in London ? 15:02:35 * dtantsur is lurking 15:02:59 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 TheJulia, make sense ++ 15:03:15 =) 15:03:18 I don't think I have any announcements this week. 15:03:29 maybe say we started dropping Py2.7? 15:03:47 iurygregory, ++ 15:03:58 #info Support for Python 2.7 testing started being dropped last week. If you see any patches, please review them. 15:04:25 Additionally, There are a few specs in ironic-specs that could use some eyes from the community 15:04:32 yep, and the actual compatibility will be gone as well 15:04:40 now right away, but soon probably 15:04:51 dtantsur: will break regardless very quickly 15:05:09 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 Does anyone have anything they would like to remind us of or announcements to raise? 15:05:17 (maybe on Phase2) 15:06:17 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 Okay, well I guess we're good to move along 15:07:00 Next would be action item review, I don't think we had any last week. Checking 15:07:04 iurygregory: sooner, I'm afraid 15:07:21 No action items 15:07:29 dtantsur, I'm ok i was just wondering the effect on the clients =) 15:07:48 #topic Review subteam status reports 15:08:32 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 #link https://etherpad.openstack.org/p/IronicWhiteBoard 15:08:49 Line 260 15:09:09 #link https://review.opendev.org/#/c/694704/ 15:09:09 patch 694704 - ironic-specs - Ussuri project priorities - 5 patch sets 15:09:54 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 done 15:11:01 * dtantsur is in a zombie mode, sorry 15:11:11 zombie status is acceptable :) 15:11:46 "monday mode" 15:12:18 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 yep, there is an ironic-lib patch 15:12:50 awesome 15:13:00 it's on the list 15:13:05 awesome, thanks 15:13:23 I guess we'll need to get that merged and released very soon? 15:13:57 dtantsur: thanks for putting that on the proposed chagnes for review list 15:14:59 the retirement spec has been updated with the discussion from the PTG ... if anyone has time / is interested 15:15:05 arne_wiebalck: thanks! 15:15:13 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 I think we're good, shall we proceed to priorities for the coming week 15:15:49 rpittau: Likely, we're going to have to have major version revs all around I think... 15:16:54 yeah 15:16:54 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 ack 15:17:40 #topic Deciding on priorities for the coming week 15:17:57 #link https://etherpad.openstack.org/p/IronicWhiteBoard 15:18:09 Line 163 15:18:21 * TheJulia wonders if zane needs some IRC attachment glue :( 15:18:59 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 TheJulia, rpittau, we can just wait with ironic-lib release until the consumers are ready 15:20:06 it feels like a chicken/egg sort of thing to me 15:20:10 but that is also true 15:20:53 I've added a link for the patches that are open for Drop Py27 15:21:01 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 iurygregory: I saw, thanks! 15:21:17 sorry for the long link =) 15:21:20 No worries! 15:21:38 Does anyone have anything else to add? 15:22:38 I guess the list looks good for me so if we're good we can proceed 15:23:55 let's 15:24:09 Good, I was starting to look at how I could get crickets delivered :) 15:24:17 ++ to move 15:24:20 Onward! 15:24:25 #topic Discussion 15:24:52 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 crickets over IP ? (sorry) 15:25:16 rpittau: hmm. Cricket over IP over Avian Carrier? 15:25:32 it'd be good to decide if we want to have a mid-cycle here at CERN. 15:25:47 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 arne_wiebalck, we want ofc XD 15:26:23 * etingof is in the same boat with iurygregory 15:26:28 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 I'm sure that can firm up. 15:27:25 do we need a minimum attendance before we say it's on? 15:28:08 how about we give it another week? 15:28:16 Hmm, devopsdays Geneva is Febuary 24th-25th 15:28:31 uh, didn't know ... 15:28:35 oh interesting 15:29:36 * iurygregory would say change to 26 27 the mid-cycle 15:30:06 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 Will remote participation be possible? 15:30:34 https://indico.cern.ch/event/863986/ 15:30:40 rpioso: yes 15:30:52 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 TheJulia, agree =) 15:31:15 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 iurygregory the topic is yours 15:31:47 ok o/ 15:32:25 IPA using UEFI + Secure Boot https://storyboard.openstack.org/#!/story/2006847 15:33:23 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 TheJulia, if I'm correct we can't use mokutil because we run under chroot? 15:34:23 that would be the reason we can't ensure after we reboot? 15:34:48 iurygregory: no, because IPA's state may not be the state desired for the running instance 15:35:41 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 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 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 which is doable, but takes some work 15:38:47 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 Does anyone have any thoughts on this? 15:39:12 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 indeed 15:41:09 iurygregory: it feels like a chart with options and constraints needs to be created to visually map this out 15:41:42 Maybe something in https://ethercalc.openstack.org/ and use that to discuss options? 15:41:55 so it is slightly more visual? 15:42:23 make sense to me 15:42:42 Okay, then seems like maybe we can return to this item next week or hopefully settle it this week :) 15:42:47 yeah =) 15:42:48 Are we good to move on? 15:42:51 ++ 15:42:53 Okay! 15:43:00 #topic Baremetal SIG 15:43:24 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 I haven't heard from the foundation or any potential authors ... have you? 15:43:46 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 Ah :) 15:44:09 Too early to chase ? 15:44:12 perhaps 15:44:16 ok 15:44:21 I'm happy to send a follow-up email this week though 15:44:27 Any word on the possibility of remote participation? 15:44:28 sounds good 15:44:41 rpioso: what do you mean? 15:45:00 TheJulia: In the ops meetup. 15:45:15 * iurygregory I was thinking it was for the mid-cycle 15:45:16 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 rpioso: do you have the link for their planning/discussion etherpad? 15:45:53 https://etherpad.openstack.org/p/LON-2020-OPS-TOPICS 15:45:59 arne_wiebalck: thanks! 15:46:01 TheJulia: I do now :-) 15:46:10 arne_wiebalck: Thank you! 15:46:12 Awesome, I guess we're good to proceed then 15:46:32 #action TheJulia to follow-up with foundation folks regarding use case follow-up 15:46:39 Just so I hopefully don't forget 15:47:43 #topic RFE Review 15:47:48 We have two proposed RFEs to review 15:48:01 The first is to support compressed images 15:48:03 #link https://storyboard.openstack.org/#!/story/2006936 15:48:29 * kaifeng thought we already have 15:48:38 We have some if done in the qcow2 file... 15:48:58 I think the same is true for compressed 15:49:35 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 there is no difference to convert a compressed/uncompressed image to raw if memory serves. 15:50:14 I think qemu-convert can read stdin... I think 15:50:34 why can't we keep the images as-is, but compress them just for transmission (HTTP)? 15:51:04 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 it would add the compress time to the transmission time in that case 15:51:16 That may or may not support passing the stream arguments. 15:51:34 if i understand the story correct, it means compressed user-image 15:51:45 yes 15:51:54 ramdisk can't be that large ;) 15:52:06 i believe we just need to turn off stream raw 15:52:11 I've heard of 2+ GB IPA ramdisks 15:52:13 and it will work 15:52:39 hmm, good point 15:52:42 We need more information 15:52:58 I've asked shardy to update the RFE with some more contextual information 15:54:28 Next RFE! 15:54:31 #link https://storyboard.openstack.org/#!/story/2006910 15:54:37 A one-shot deployment API 15:56:25 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 dtantsur: welcome back 15:57:30 the RFE description is almost a spec =) 15:57:41 I like detailed RFEs ;) 15:57:50 Indeed :) 15:57:54 the deployment API has been discussed.. many times. this work is loosely based on sambetts' ideas. 15:58:51 I'm good with it, any objections or support for it? 15:59:05 +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 will we switch the nova virt driver to use it? 15:59:52 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 mgoddard: there are a few words about it there :) 16:00:09 essentially, nova may benefit from a multi-step approach 16:00:18 dtantsur: skimmed for them :) 16:00:20 dtantsur: single step you mean? 16:00:37 TheJulia: well, I think nova is a special consumers who may actually use a multi-step approach 16:00:47 e.g. I think VIF attachment is separate 16:01:00 will it play well with HA? what happens if conductor dies along the way? 16:01:10 dtantsur: it is... I guess yeah it may be best to stay multi all along 16:01:16 etingof: deployment dies 16:01:16 etingof: there is no state in the conductor, it's all taken from the nodes 16:01:30 it's essentially what metalsmith implements on the client side, but moved to ironic-api 16:01:37 etingof: or to be more precise, the deployment is moved to deploy failed 16:01:45 if it is not completed. 16:02:12 right, the same way it's done now 16:02:34 yup 16:03:08 * dtantsur grabs whiskey while waiting for objections 16:03:13 could one deploy twice? 16:03:26 Anyway, we're past our ending time. If there are no objections, I think that is the end of our meeting 16:03:28 if it's all virtual, I suspect no state 16:03:30 dtantsur: objection! pass the whiskey along 16:03:34 :D 16:03:41 etingof: how do you imagine it? 16:03:43 mgoddard: Very wise :) 16:03:59 I guess you guys can discuss 16:03:59 double curl 16:04:08 Well if there is nothing else, thanks everyone! 16:04:11 etingof: same is right now: the 2nd request gets CONFLICT 16:04:17 thanks TheJulia 16:04:24 no racing? 16:04:27 task.node.save() occurs when the lock is raised 16:04:38 the second connection would read the db and see the lock 16:04:43 etingof: it's build around nodes internally 16:04:54 so usual node locks (and our beloved Node locked error) apply 16:04:56 #endmeeting