15:00:51 #startmeeting ironic 15:00:52 Meeting started Mon Aug 10 15:00:51 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:53 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:56 The meeting name has been set to 'ironic' 15:00:56 o/ 15:00:57 o/ 15:00:57 o/ 15:00:59 o/ 15:00:59 \o 15:01:02 o/ 15:01:04 Sorry, I was lost in my thoughts in a document 15:01:08 Good morning ironic! 15:01:09 o/ 15:01:12 o/ 15:01:15 o/ 15:01:17 o/ 15:01:29 I hope everyone had a wonderful weekend! 15:01:55 There is not better weekend then fixing your car 15:02:00 * iurygregory had - BBQ <3 15:02:03 Our agenda, as always, can be found on the wiki. 15:02:05 #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting 15:02:19 o/ 15:02:26 #topic Announcements / Reminder 15:02:54 Only one item, we need to cut some releases this week 15:03:00 On a positive side, CI is happy! 15:03:01 \o/ 15:03:06 \o/ 15:03:11 *dances* 15:03:29 Oh one other thing worth mentioning 15:03:50 All the redhatters are off on Friday of this week, and I may also take some time next week. I have not decided yet 15:04:14 question: dtanstur is around or on vacation. I dont see him in user list 15:04:37 If anyone wants to run the meeting next week.... I would be more inclined to take the time off. *subtle hint* 15:04:44 gudrutis0: yes, he is on PTO this week 15:04:51 stendulker: o/ 15:04:54 PTO? 15:04:55 TheJulia: I can run the meeting next week if needed 15:04:57 I can run the meeting 15:04:58 o/ 15:05:01 paid time off 15:05:02 vacation 15:05:06 oh =) 15:05:58 so yeah next week either rpittau or me can run the meeting =) 15:06:05 Well, since nobody else seems to have any annoucements or reminders, we should move on! 15:06:47 iurygregory: I'd love for a non-redhatter to run it, but I'm also driving a lot on Friday/Sunday so I may just be dead to the world on Monday 15:06:58 * TheJulia checks if we had action items 15:07:17 No action items, so I guess we can go to subteam status 15:07:33 #topic Review subteam status reports 15:07:56 #link https://etherpad.opendev.org/p/IronicWhiteBoard 15:07:59 Starting at line 302 15:08:47 I may need to offer chocolate or something for reviews on the out of memory patch 15:08:55 photos of delicious chocolates or something 15:09:14 very motivating 15:09:38 yay! the ramdisk tempest scenario test merged 15:09:48 queue dancing! 15:09:57 \o/ 15:10:42 Looks like stevebaker has been making good progress on API cleanups/refactoring stuffs 15:11:20 And Dmitry posted some work for ramdisk tls 15:11:21 \o/ 15:11:37 iurygregory: still fighting with ci jobs? 15:11:42 yes 15:11:45 :( 15:11:52 on grenade and on tempest .-. 15:11:55 ugh 15:12:02 at least it's not a POST_FAILURE 15:12:08 trying to figure out why the new flavor is not helping .-. 15:12:14 now the tests are just failing 15:12:22 Or a POST_FAILURE that is a real failure :( 15:12:34 tosky: oh? 15:12:35 tosky, the failures were the same =) 15:12:38 for grenade 15:12:50 I saw privsep patches, awesome. 15:13:11 yeah, I'm trying to understand the problem with the sudo to fix them hehe 15:13:17 iurygregory: oh, ok 15:13:20 and test aganist ironic to see how it goes 15:13:28 I need to double check the openstack schedule but I think we are approaching the point where we need to amke progress on ironic-lib or we're going to slip the item to next cycle 15:13:47 ack 15:13:58 ohhh deploy time software raid in standalone job testing merged 15:14:14 So seems like docs are what is left there 15:14:47 rpioso: is there anything more up to date on the Redfish Interop profiles? 15:15:27 TheJulia: Nothing new. 15:15:33 ok 15:15:49 Seems like the baremetal sig is idle at the moment given Arne is on PTO as well 15:16:06 so I guess we're good with updates, is everyone ready to proceed to priorities for the week? 15:16:14 let's 15:16:18 ++ 15:16:43 #topic Deciding on priorities for the coming week 15:16:50 #link https://etherpad.opendev.org/p/IronicWhiteBoard 15:17:01 Starting at line 159 15:17:10 Well, let me clean that up since a LOT of stuff merged last week 15:20:56 Does anyone have items to propose to the list this week? 15:20:56 I'm almost done cleaning the list up 15:21:53 this backport for ipa https://review.opendev.org/745493 15:21:54 patch 745493 - ironic-python-agent (bugfix/6.2) - Ignore devices with size 0 when collecting inventory - 1 patch set 15:22:49 added 15:22:52 not a priority but needs discussion: https://review.opendev.org/#/c/745289/ 15:22:53 thanks 15:22:53 patch 745289 - ironic-inspector - Identify accelerator devices during introspection - 2 patch sets 15:23:05 kaifeng: sure 15:23:25 Well, I think that is it 15:23:56 Everyone good with the list? I'm sure there is some stuff we can add as the week goes on, but I've been very heads down on CI issues and bugs the last couple of weeks 15:24:32 ++ 15:24:36 looks good, maybe some more backprots, but can check them during the week 15:24:56 Yeah, I have one or two that need to be attended to 15:25:08 but yeah, largely it has been CI. Thanks everyone! 15:25:28 Well, I guess time to move on to Discussion 15:25:31 #topic Discussion 15:25:39 I guess we now have two items, or at least one 15:26:03 The first one was the 2021 User Survey question. The OpenStack Foundation has inquired if we would like to change the question we pose on the user survey. 15:26:21 Presently the question is "Ironic: What would you find most useful if it was part of ironic?" 15:26:49 do we have some results so we can evaluate? 15:26:53 I was thinking for 2021, perhaps something more like "Ironic: Would you submit anonymous usage statistics if a tool existed? Yes/No/Not Applicable", but since this is a community, I'd like to hear if anyone has any thoughts or ideas 15:27:55 statistics about the deployment? 15:28:03 So results have to be scrubbed for anonymity, and often because it is free form text entry we get a variety of responses. Sometimes it is features we've already implemented and people haven't updated, etc 15:28:13 I'm trying to understand the `new` question... 15:28:31 Yeah, I was thinking if we could somehow get an idea of the drivers/numbers of nodes per conductors, number of conductors... it would help understand our users better 15:28:48 oh gotcha =) 15:28:55 but I am unsure if people would eveb be receptive to submitting such data 15:28:58 I think self networking service would be very helpful to make ironic more dependant 15:29:27 kaifeng: could you elaborate on that a little more? 15:29:29 kaifeng: network configuration embedded ? 15:29:35 I'm trying to understand your idea :) 15:29:46 integration with neutron makes the network structure quite complex 15:29:52 This is what I am feeling 15:30:24 This is true, and in many cases it is complexity that is not always needed 15:30:46 I really want a "call this ansible playbook" driver for networking, to be honest 15:30:52 rpittau: I am thinking a mini network service provided by ironic :) 15:31:24 wow 15:31:30 kaifeng: that sounds cool, especially for standalone 15:32:39 I think it may be good to avoid trying to have a whole service as another thing that needs to be setup, but if we could do like local file dhcp configuration or even just call a playbook to change switchport config, that would be a huge bonus for operators 15:33:03 Anyway, that has been my thought for a while 15:33:17 I agree, a service is probably overkill, while a configuration "tool" could be ideal 15:33:37 or just another integration point 15:33:38 Indeed, an alternative integration I would reword. 15:33:46 ++ 15:33:47 yep 15:34:06 So back to the 2021 question real quick, anyone have any thoughts on that. I have to send our answer into the foundation this week 15:35:10 maybe an email to openstack-discuss would be good? 15:35:24 I'm ok with the old and the new one =) 15:35:28 I can do that 15:35:31 i feel like the question is too open ended. (ie, not totally clear what is being asked). 15:35:34 Yeah, leave it open for a day or two 15:35:35 It would be useful to get some data on drivers being used. We do not know adoption of newer drivers e.g. redfish or vmedia 15:35:58 stendulker: ++ 15:35:59 essentially are ppl migrating from pxe/ipmi 15:36:08 we should give some guidance in terms of granularity and what we want to collect 15:36:13 I guess there is some stat on the hardware automation event? 15:36:28 rloo: if we provided an example of the data we would like users to submit, it would help them answer the question 15:36:49 yes, that would help. 15:36:52 kaifeng: like attendees? 15:37:02 Okay, I'll send an email to the list after the meeting 15:37:05 Oh, I mean oob technologies 15:37:17 kaifeng: ahh. 15:37:32 Next topic, kaifeng it seemed you had something for discussion? Would you like to discuss it now? 15:37:39 Also I think it would be useful to know what ppl hate about Ironic... 15:37:55 sure 15:38:00 stendulker: state machine 15:38:11 TheJulia: :) 15:38:13 and that it is complex to setup 15:38:22 * TheJulia shouldn't be surprised that she knows this 15:38:30 FWIW, we do get some of that with the existing question 15:39:07 okay, it's about the patch https://review.opendev.org/#/c/745289/ 15:39:08 patch 745289 - ironic-inspector - Identify accelerator devices during introspection - 2 patch sets 15:39:12 But yeah. I think the questionnaire closes in a few weeks and typically the foundation gets something out to PTLs end of september to mid-october 15:39:43 (odd, i love the state machine...) 15:41:06 kaifeng: I'm kind of with your statement on why to keep the possible devices in the code 15:41:12 it seems dtantsur prefers to have a new node field for saving accelerator devices so it can be guarded by API and consumed by CLI 15:41:27 ugh 15:42:18 I guess the question is, will Nova or some other service be eventually leveraging the data? 15:42:19 for known devices I am ok to have a in tree yaml or something 15:42:32 kaifeng: Ohh, I like that idea! 15:42:38 rloo: <3 15:43:14 nova maybe for possible pci passthrough ? 15:43:16 In our case Nova will be the data consumer 15:43:16 rloo: the state machine is often misunderstood. 15:43:58 ah, in that case, we might be able to clarify. 15:44:20 and the value of a dedicated field really comes down to if it is opportunistic or not, and given the nature of the data 15:44:51 Adding a new field for possible/occassional data seems like something that might make it harder for the API to be leveraged 15:45:00 but it is really just informational for scheduling I guess 15:45:33 yes, I am thinking this way, from the ironic side, we just provide such information 15:46:13 And also incrementing the microversion in nova makes it a harder change to consume 15:46:28 and still not every machine/node/etc will have accelerators 15:47:01 I'm thinking a new field is only going to be useful if we don't expect it to be used or leveraged for a while. If it is in properties, it can be leveraged much sooner 15:47:30 Anyone else have any thoughts? 15:47:53 And is there ever a case where an operator would need to change the data? 15:48:25 i think we ought to move away from our dict-like fields, if possible. 15:48:43 They are much harder for an operator or api client to update 15:49:16 if possible, if makes sense... 15:49:29 yeah 15:49:30 we would have much more fields if we don't have dict-fields tbh 15:49:53 i don't think it is a problem to have a lot more fields. 15:49:54 kaifeng: agreed, and we have to find a "balancing point" between the two 15:50:19 rloo: oh, there is. We get bug reports where people only paste the last 25 lines from "openstack baremetal node show" 15:50:44 oh... 15:50:53 People don't comprehend how many items are returned until they look 15:51:00 unless they know taht is 15:51:04 that 15:51:09 well, parsing properties isn't fun. and we don't have an API to filter/search on properties. 15:51:27 I think the benefit of new fields is if we have efficient update/query support from the db 15:51:33 All comes down to the operator, at least in my mind. Will they be interacting with the field 15:51:50 kaifeng: yes, we can't query/match dict fields easily 15:51:51 but for dict-fields, we can't, so why a new dict-field then 15:52:07 (we have a downstream hack to allow filtering on property values :-( ) 15:52:15 rloo: yeouch 15:52:29 it is really useful but yup, i agree 15:52:39 * TheJulia passes rloo delicious tea 15:52:51 yum... 15:53:31 kaifeng: Anyway, It comes down the operator interactions in my mind. I feel like we have some general consensus on that here today 15:53:46 We can't really answer that question without knowing what the operator will be doing 15:53:56 or instead of the operator, the user of the API 15:54:05 since... one can grant non-admin users rights now 15:54:34 Anyway, are we good to proceed? 15:55:01 probably 15:55:12 Skipping Baremetal SIG since arne is not here as well as RFE review since there are no items 15:55:14 Well, if anyone has new thoughts, please comment on the patch 15:55:17 #topic Open Discussion 15:55:33 kaifeng: do you want it on the review priorities for the week? 15:55:43 does anyone have anything else to discuss today? 15:55:57 TheJulia: thanks, that would be good :) 15:57:34 Is it possible to get your input on my MR since dtantsur is away? 15:57:45 kaifeng: done 15:57:48 gudrutis0: link? 15:58:35 https://review.opendev.org/#/c/731794/7/doc/source/user/usage.rst@120 15:58:36 patch 731794 - ironic-inspector - More flexible definitions of conditions in rules - 7 patch sets 15:59:27 gudrutis0: I've added it to my review queue 15:59:34 This exact comment, we were discussing if it is worth introducing 2 new variables instead of 1 15:59:46 TheJulia: thanks 16:00:02 no problem! 16:00:15 Well, if there is nothing else folks, thank you and have a wonderful week! 16:00:36 thanks! 16:00:43 danke 16:00:57 thank you 16:01:07 ty 16:01:29 #endmeeting