| *** pmannidi is now known as pmannidi|brb | 02:03 | |
| *** pmannidi|brb is now known as pmannidi | 04:12 | |
| dtantsur | good.. *looks outside* night? | 06:03 |
|---|---|---|
| dtantsur | rpioso: the firmware update RFE makes sense to me (modulo some implementation details, which should be polished on the patch anyway) | 06:06 |
| arne_wiebalck | Good morning, Ironic! | 06:31 |
| iurygregory | good morning dtantsur arne_wiebalck and Ironic o/ | 06:55 |
| arne_wiebalck | hey iurygregory dtantsur, good morning o/ | 07:07 |
| dtantsur | o/ | 07:19 |
| *** MikeCTZA_ is now known as MikeCTZA | 07:23 | |
| MikeCTZA | I'm starting to think I will never get ironic working, what seems so simple is just not happening for me ... | 07:27 |
| dtantsur | is it DNS still? | 07:27 |
| MikeCTZA | yup I still cant find any reference to how / where to set that | 07:28 |
| rpittau | good morning ironic! o/ | 07:28 |
| dtantsur | MikeCTZA: that's with neutron, right? I suspect you need to set nameservers on the subnet | 07:29 |
| MikeCTZA | yeah I've done that but let me double check I've even had some other network changes made today that I though could be related but guess not | 07:30 |
| iurygregory | morning rpittau o/ | 07:30 |
| rpittau | hey iurygregory :) | 07:30 |
| iurygregory | it's always DNS =) | 07:30 |
| MikeCTZA | so I PXE off VLANID505 (in our case)... that works, then when it is in IPA - thats when it talks to neutron right? which is the network that i've added in openstack? | 07:31 |
| dtantsur | MikeCTZA: I assume the OS of the ramdisk will get DNS servers from your DHCP | 07:31 |
| dtantsur | which duing deployment comes from neutron | 07:31 |
| dtantsur | you can always hack your ramdisk to populate resolve.conf and see if you can progress further | 07:32 |
| MikeCTZA | and the DNS it gets from that would be an internal DNS which you set with --dns-nameserver on the openstack subnet create line correct? | 07:32 |
| dtantsur | I *think* so | 07:32 |
| dtantsur | as an aside, I'm surprised eventlet requires working DNS.. it's not needed for IPA itself | 07:33 |
| dtantsur | https://github.com/eventlet/eventlet/issues/462 | 07:37 |
| iurygregory | <facepalm> | 07:37 |
| dtantsur | MikeCTZA: so it seems that another workaround for you (assuming you don't need DNS on IPA), is it add "EVENTLET_NO_GREENDNS=yes" to environment variables in the ironic-python-agent systemd service | 07:38 |
| dtantsur | and yes, facepalm | 07:38 |
| MikeCTZA | which means I'd need to build a fresh IPA right? | 07:39 |
| dtantsur | no necessarily | 07:39 |
| dtantsur | MikeCTZA: https://docs.openstack.org/ironic/latest/admin/troubleshooting.html#patching-the-deploy-ramdisk | 07:39 |
| dtantsur | whatever is easier for you | 07:39 |
| MikeCTZA | thanks, let me give that a read | 07:40 |
| rpittau | gosh that was reported 3 years ago | 07:40 |
| dtantsur | it would still be useful to understand why you don't get nameservers | 07:40 |
| MikeCTZA | I feel I'm so close but just not quite there in getting this working | 07:40 |
| dtantsur | because it will affect your instances most likely | 07:40 |
| MikeCTZA | it could be our setup, which is not the simplest I must admit | 07:41 |
| dtantsur | production setups are really simple, aren't they? :) | 07:41 |
| rpittau | the nightmares | 07:42 |
| MikeCTZA | right ... done the ramdisk patch without DNS / env variable so let me see if I got that right and what happens now | 07:52 |
| MikeCTZA | could be that i did that wrong or is something else as its the same, I added Environment=EVENTLET_NO_GREENDNS=yes to the [Service] section in the ironic-python-agent.service file once I unpacked then repacked it | 07:57 |
| rpittau | MikeCTZA: that should be correct | 08:00 |
| janders_ | good morning Ironic o/ | 08:30 |
| *** janders_ is now known as janders | 08:30 | |
| rpittau | hey janders :) | 08:30 |
| iurygregory | janders, o/ | 09:05 |
| opendevreview | Bernd Mueller proposed openstack/ironic master: changed code for memory burin vm-bytes, 75 to 75% https://review.opendev.org/c/openstack/ironic/+/815264 | 09:47 |
| opendevreview | Merged openstack/bifrost master: Bump up Ansible to 4.x https://review.opendev.org/c/openstack/bifrost/+/814858 | 09:57 |
| opendevreview | Merged openstack/ironic master: changed code for memory burin vm-bytes, 75 to 75% https://review.opendev.org/c/openstack/ironic/+/815264 | 10:27 |
| *** dviroel|rover|afk is now known as dviroel|rover | 11:10 | |
| TheJulia | Good morning eeryone | 12:31 |
| rpittau | good morning TheJulia :) | 12:33 |
| opendevreview | Riccardo Pittau proposed openstack/bifrost master: Bump ansible lint to latest version https://review.opendev.org/c/openstack/bifrost/+/815293 | 12:35 |
| dtantsur | morning TheJulia | 12:36 |
| iurygregory | good morning TheJulia =) | 12:39 |
| * TheJulia is going to run and get some breakfast... no fresh milk or cream in the firdge | 12:40 | |
| TheJulia | fridge | 12:40 |
| iurygregory | things that normally happens you travel =) | 12:41 |
| iurygregory | when* | 12:41 |
| rpittau | iurygregory: about arm, I was already doing a research on tinycore on arm64 (connected to my involvement with arm64 downstream) and we do have nodesets with arm64, like ubuntu-focal-arm64 and centos-8-stream-arm64 | 12:51 |
| iurygregory | rpittau, I was planning in talk with you :D, oh that's nice! | 12:52 |
| dtantsur | rpittau: do you know how many of them we have? | 12:53 |
| dtantsur | like, can we start building tinyIPA on them? | 12:53 |
| rpittau | I don't have the numbers, but just for the builds we could probably give that a try | 12:54 |
| rpittau | honestly I tried only once building tinyipa on rpi but it didn't go well :) | 12:54 |
| rpittau | there are not many jobs on arm64 AFAICS | 12:56 |
| opendevreview | Dmitry Tantsur proposed openstack/sushy master: [WIP] Migrate common constants to enums https://review.opendev.org/c/openstack/sushy/+/815107 | 12:56 |
| dtantsur | this becomes a pretty nightmarish patch ^^ | 12:56 |
| rpittau | wow | 12:57 |
| dtantsur | on the other hand, I now have a script to generate enums from XMLs | 12:57 |
| dtantsur | https://review.opendev.org/c/openstack/sushy/+/815107/3/tools/generate-enum.py | 12:58 |
| dtantsur | eventually, I hope, we can autogenerate large parts of sushy | 12:58 |
| rpittau | I don't see issues in the change, lets' see what the CI says | 13:02 |
| TheJulia | om nom | 13:23 |
| opendevreview | Nisha Agarwal proposed openstack/ironic master: Add nvme as interface_type for RAID input https://review.opendev.org/c/openstack/ironic/+/815110 | 13:41 |
| opendevreview | Iury Gregory Melo Ferreira proposed openstack/ironic-specs master: [WIP] Yoga Themes https://review.opendev.org/c/openstack/ironic-specs/+/815308 | 13:48 |
| opendevreview | Dmitry Tantsur proposed openstack/sushy master: Prepare the ground to use enums instead of strings https://review.opendev.org/c/openstack/sushy/+/815103 | 14:18 |
| opendevreview | Dmitry Tantsur proposed openstack/sushy master: Prepare the ground to use enums instead of strings https://review.opendev.org/c/openstack/sushy/+/815103 | 14:27 |
| tzumainn | hi! just a note - I think there may be an issue with the default allocation policies right now, as it seems like unrestricted allocation creation is open to everyone, and some of the subsequent logic may be incorrect | 14:37 |
| tzumainn | there are notes and an explanation in https://review.opendev.org/c/openstack/ironic/+/812007 if anyone wants to take a look! | 14:37 |
| iurygregory | tzumainn, hey! thanks for patch I will add to the priorities for the week for review | 14:41 |
| tzumainn | iurygregory, thanks! | 14:42 |
| TheJulia | tzumainn: I seem to think that what your describing, at least without looking at the patch, is the intended behavior | 14:58 |
| tzumainn | TheJulia, it's a bit confusing to me though, because it seems as if there are less permissions around baremetal:allocation:create than baremetal:allocation:create_restricted | 14:59 |
| TheJulia | That still feels like the intent, but I'll need to wrap my brain around it compeltely | 15:00 |
| rpittau | #startmeeting ironic | 15:00 |
| opendevmeet | Meeting started Mon Oct 25 15:00:22 2021 UTC and is due to finish in 60 minutes. The chair is rpittau. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:00 |
| opendevmeet | The meeting name has been set to 'ironic' | 15:00 |
| iurygregory | o/ | 15:00 |
| TheJulia | o/ | 15:00 |
| erbarr | o/ | 15:00 |
| stendulker | o/ | 15:00 |
| bfournie | o/ | 15:00 |
| ajya | o/ | 15:00 |
| arne_wiebalck | o/ | 15:00 |
| rpittau | Hello everyone! Welcome our weekly meeting! | 15:00 |
| rloo | o/ | 15:00 |
| rpittau | Our agenda can be found on the wiki. | 15:00 |
| rpittau | #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting | 15:00 |
| ameya49 | o/ | 15:00 |
| Marina | o/ | 15:00 |
| dtantsur | o/ | 15:01 |
| rpittau | #topic Announcements / Reminders | 15:01 |
| rpittau | the Yoga PTG was last week | 15:01 |
| rpittau | #link https://etherpad.opendev.org/p/ironic-yoga-ptg | 15:02 |
| rpittau | it looks like it was quite successfull :) | 15:02 |
| * iurygregory is writing a summary to post on ironicbaremetal.org and send to the ML | 15:03 | |
| rpittau | great! | 15:03 |
| rpioso | o/ | 15:03 |
| TheJulia | iurygregory: thanks! | 15:03 |
| iurygregory | np =) | 15:04 |
| opendevreview | Dmitry Tantsur proposed openstack/sushy master: Prepare the ground to use enums instead of strings https://review.opendev.org/c/openstack/sushy/+/815103 | 15:04 |
| rpittau | this is the only announcement for today, does anyone have anything else to announce/remind us of ? | 15:04 |
| TheJulia | Nothing on my end | 15:05 |
| rpittau | alright, moving on! | 15:05 |
| rpittau | #topic Review action items from previous meeting | 15:05 |
| rpittau | we didn't have any action items from last time | 15:06 |
| rpittau | #topic Review subteam status reports | 15:06 |
| rpittau | #link https://etherpad.opendev.org/p/IronicWhiteBoard | 15:06 |
| iurygregory | I think we can skip ? ^ /me wondering since we need to update for the ones from Yoga | 15:07 |
| rpittau | around L62 | 15:07 |
| TheJulia | I suspect much doesn't make sense on the subteam status report until we've reached forward consensus | 15:07 |
| iurygregory | yeah =) | 15:07 |
| TheJulia | for cycle priorities | 15:07 |
| rpittau | yep | 15:07 |
| rpittau | alright, let's move forward then | 15:07 |
| rpittau | #topic Deciding on priorities for the coming week | 15:07 |
| rpittau | #link https://review.opendev.org/q/status:open+hashtag:ironic-week-prio | 15:08 |
| rpittau | I see the yoga themes is there already :) | 15:08 |
| iurygregory | yeah I added already :D | 15:08 |
| iurygregory | we will talk a bit more about it in open discussion =) | 15:09 |
| rpittau | that's probably the highest priority for the week, but I guess we have some space for something more | 15:09 |
| dtantsur | https://review.opendev.org/c/openstack/sushy/+/815103 could use some eyes | 15:09 |
| dtantsur | unfortunately, I'm still not finished with common constants, but should be soon | 15:09 |
| rpittau | added | 15:10 |
| rpittau | any other patches to add to the priorities for this week ? | 15:11 |
| dtantsur | https://review.opendev.org/c/openstack/ironic-python-agent/+/814771 if possible | 15:11 |
| rpittau | sure, added | 15:11 |
| rpittau | anything else ? | 15:13 |
| rpittau | ok, let's move on | 15:13 |
| rpittau | #topic Discussion | 15:13 |
| rpittau | iurygregory: do we want to talk now about the Yoga Themes or you want to keep that for the end? | 15:14 |
| iurygregory | rpittau, both are ok I would say? | 15:14 |
| iurygregory | I added to open discussion because people will need to review the patch =) | 15:14 |
| *** dviroel|rover is now known as dviroel|rover|lunch | 15:15 | |
| rpittau | ok, I guess we'll need time to have a look there | 15:15 |
| rloo | do you want us to review that patch now? | 15:15 |
| iurygregory | rloo, nope it will be more a request for review so people can provide feeedback during the next days | 15:16 |
| rloo | ok, thx for clarification. (Does it need WIP or does that mean it isn't ready for review?) | 15:16 |
| iurygregory | WIP is because we only have a few topics, I will remove after getting some feedback and add more information | 15:17 |
| iurygregory | like after we figure out who is interested in which topic etc | 15:17 |
| TheJulia | I guess my only concern is storage cleaning enhancement. I don't really remember discussing it during hte ptg and it basically made no progress on consensus building over the past six months | 15:17 |
| rloo | 'topics' == 'themes' in the PR? | 15:17 |
| rloo | seems like a lot of themes to me :D | 15:17 |
| TheJulia | yeah, it is a lot of themes and some of it could be a little more generalized | 15:18 |
| iurygregory | TheJulia, it was during the time you were in the TC call =) | 15:18 |
| rloo | i think we forgot to get votes on these during the ptg. | 15:18 |
| iurygregory | ok, seems like we are talking now :D let's continue | 15:18 |
| TheJulia | We kind of realized a long time ago general work themes were better than specific items since sometimes areas shift/change | 15:18 |
| iurygregory | I got the list from the https://etherpad.opendev.org/p/ironic-yoga-ptg L655 basically | 15:19 |
| iurygregory | the idea is that contributors should vote on topics, provide feedback (we can merge this two topics etc,) (I want to help in this effort) | 15:20 |
| TheJulia | Yeah, and often in the past, I've worked to generalize it a little more as defining the areas | 15:20 |
| iurygregory | so I can update accordingly to what people said =) | 15:20 |
| iurygregory | TheJulia, got it =) | 15:20 |
| rloo | fwiw, i'm good with generalized or non-generalized themes, as long as 'we' know what is going on ;) | 15:22 |
| rloo | the description of the theme will provide more info. and we can change things during the cycle (as we've done) | 15:22 |
| iurygregory | yeah we can have the section with details like we had in xena | 15:23 |
| TheJulia | rloo: ++ | 15:23 |
| * rloo wonders if what might be more important is the primary contacts/who will do the work... | 15:23 | |
| iurygregory | well, they will provide the updates about the status and will be working on the theme | 15:25 |
| iurygregory | if is something simple it doesn't have to be a theme or can just be merged with something more generic I would say | 15:25 |
| iurygregory | so, as action item for people that are interested please review the Yoga Themes https://review.opendev.org/c/openstack/ironic-specs/+/815308 and provide your feedback :D | 15:27 |
| rpittau | we will probably discuss more during the week, after the first reviews :) | 15:28 |
| TheJulia | rpittau: ++ | 15:28 |
| iurygregory | agree =) | 15:28 |
| rpittau | we can move forward for now | 15:29 |
| rpittau | #topic Baremetal SIG | 15:29 |
| rpittau | #link https://etherpad.opendev.org/p/bare-metal-sig | 15:29 |
| rpittau | not sure if we have any news, arne_wiebalck ? | 15:29 |
| arne_wiebalck | We have meetings since about a year now. I guess it is time to check if we continue, stop, change ...? | 15:29 |
| TheJulia | Yeah, and I *think* the consensus was to start a mailing list thread as a retrospective | 15:30 |
| iurygregory | I know we had a topic to talk about the SIG in the PTG on Friday but after TheJulia left everybody left the meeting also :D | 15:30 |
| arne_wiebalck | heh | 15:30 |
| arne_wiebalck | I can send a mail ofc, but since it costs nothing for anyone except for the speakers, I expect noone may care. | 15:31 |
| rpioso | arne_wiebalck: I feel we're starting to hit our stride. The turn outs for the past 2 meetings were encouraging. | 15:31 |
| arne_wiebalck | rpioso: true | 15:31 |
| rpittau | we have the opportunity now | 15:32 |
| rpittau | personally I think we should continue, participation was encouraging | 15:32 |
| TheJulia | rpioso: good point! | 15:32 |
| arne_wiebalck | well, we can continue as long as we have volunteers to present (which was not a problem so far, thanks to all of you!) | 15:32 |
| rpioso | arne_wiebalck: Would be a shame to lose that as we hopefully come out of the pandemic. | 15:32 |
| TheJulia | I think the difference is we did some active advertising for the last two | 15:32 |
| arne_wiebalck | TheJulia: yeah, we were a little more "aggressive" :) | 15:32 |
| rloo | 'marketing' arne, 'marketing' :D | 15:33 |
| * TheJulia imagines an advertising agency for bare metal bears and owls and whatnot :) | 15:33 | |
| arne_wiebalck | again, the main work is for the speakers and for steve who does the editing | 15:33 |
| iurygregory | we didn't have as much operators as we expected, but this is something we can work on I would say =) | 15:33 |
| arne_wiebalck | rloo: :-D | 15:33 |
| rpittau | owl-bears ? https://en.wikipedia.org/wiki/Owlbear | 15:33 |
| dtantsur | :D | 15:34 |
| TheJulia | We only tended to get maybe 30% of those who responded or expressed interest… which is statistically pretty good for a community meeting during the work day | 15:34 |
| arne_wiebalck | getting more operators to come along to anything is a long standing hard issue, it seems | 15:34 |
| arne_wiebalck | the videos have between 100 and 500 views | 15:34 |
| rpioso | Any Metal3 operator prospects? | 15:34 |
| arne_wiebalck | most popular videos say "Introduction" in it | 15:34 |
| iurygregory | yeah, wondering if the large scale sig has meeting with operators also =) | 15:35 |
| rpittau | I was going to say if we should maybe extend the invitation to metal3 operators or devs, maybe during the metal3 meeting ? | 15:35 |
| rpittau | not sure it was ever mentioned there | 15:35 |
| arne_wiebalck | I don't think so. | 15:35 |
| arne_wiebalck | a metal3 intro/overview would also be nice :-D | 15:36 |
| arne_wiebalck | we still have quite some topics on the list | 15:36 |
| arne_wiebalck | but I don't want to bother speakers if they think it is not the best use of their time | 15:36 |
| rpioso | The Scientific SIG may be a source of operators, too. Is there a Telecom SIG? | 15:36 |
| TheJulia | there is definitely overlap there, but I don't think much beyond verticals exists outside of the scientific folks | 15:37 |
| TheJulia | and they largely self-organized in order to address a whole set of issues they had | 15:37 |
| arne_wiebalck | I guess the main aspect is commitment from all of you to continue to contribute/prepare presentations. | 15:39 |
| iurygregory | arne_wiebalck++ | 15:39 |
| arne_wiebalck | So, what is the feeling, we try to continue? | 15:41 |
| rpittau | in theory next session should be november 9th | 15:41 |
| iurygregory | I think so =) | 15:41 |
| rpioso | ++...+ | 15:41 |
| arne_wiebalck | rpittau: yes | 15:41 |
| iurygregory | I think we can move to the next topic rpittau =) | 15:43 |
| rpittau | we should definitely continue, let's see if we can find a topic/presenter for the next session (not necessarily now) | 15:43 |
| rpittau | yep | 15:43 |
| arne_wiebalck | ok | 15:43 |
| rpittau | #topic RFE review | 15:43 |
| rpittau | rpioso: you have a request for an RFE ? | 15:44 |
| rpioso | rpittau: Yes, we're proposing [RFE] Enhance Redfish firmware update user experience, https://storyboard.openstack.org/#!/story/2008723. | 15:44 |
| TheJulia | I'm a bit concerned by a duality re-use of [redfish]use_swift. If memeory serves we added a new config option in the deploy interfaces for download of assets to the conductor | 15:45 |
| rpioso | We added more details, so folks can better understand what's going to change and how. | 15:45 |
| TheJulia | We've also had operators explicitly say they need conductors, or they need to be able to define/use their own external endpoint outside of openstack entirely. | 15:46 |
| TheJulia | or that the bmc's can't reach anything but the locally attached network, so implication of behavior seems... problematic and possibly complicating for those operators | 15:47 |
| dtantsur | I guess the idea is similar though? | 15:47 |
| dtantsur | I either can use Swift to send things to the BMC or I can not | 15:47 |
| TheJulia | or supply the url to the bmc to download | 15:48 |
| rpioso | TheJulia: If I understand the operators need described above, the solution we've proposed should address that, no? | 15:48 |
| dtantsur | yeah, so we get to *_download_source again :) | 15:49 |
| TheJulia | dtantsur: exactly | 15:49 |
| TheJulia | rpioso: no, it actually potentially breaks a case by forcing a download and different location of access | 15:49 |
| TheJulia | At least, that is how I'm parsing it | 15:50 |
| dtantsur | what does ilo do? | 15:50 |
| dtantsur | and irmc? | 15:50 |
| TheJulia | I *think* ilo posts the file | 15:50 |
| dtantsur | my biggest worry would be creating more inconsistencies | 15:50 |
| TheJulia | like contents to the bmc | 15:50 |
| dtantsur | ahhh | 15:50 |
| TheJulia | but I'd have to check | 15:50 |
| dtantsur | well | 15:50 |
| TheJulia | brain is at EIUNSUFFCOFFEEEEEEE | 15:51 |
| iurygregory | can we update X FW at the same time? Does the BMC have support to do this? | 15:51 |
| TheJulia | iurygregory: depends on the bmc | 15:51 |
| iurygregory | so iDRAC has support to update multiple FW at once? (I think this would be the case right?) | 15:51 |
| rpioso | iurygregory: Yes, it can update multiple FW during 1 reboot (at once, sort of). | 15:52 |
| iurygregory | rpioso, got it =) | 15:52 |
| dtantsur | it seems like iLO downloads the file locally, yeah | 15:52 |
| dtantsur | I guess it may be an argument for re-serving the firmware from the conductor | 15:53 |
| sonali_borkar | yes ilo download it locally | 15:53 |
| rpioso | https://opendev.org/openstack/ironic/src/commit/5be9edecd3a7e6de905a1eff6621f0227f26b855/ironic/drivers/modules/ilo/management.py#L569 | 15:56 |
| TheJulia | the feedback generally seems to be that operators don't want the bmc's to be able to talk to anything if they can avoid it | 15:57 |
| rpioso | TheJulia: Where do operators prefer the firmware packages be served from? | 15:58 |
| TheJulia | I don't remember https://opendev.org/openstack/ironic/src/commit/5be9edecd3a7e6de905a1eff6621f0227f26b855/ironic/drivers/modules/ilo/firmware_processor.py#L162 being this complex | 15:58 |
| rpittau | we're almost at the top of the hour, let's wrap up the meeting and we can keep discussing it afterwards? | 15:58 |
| TheJulia | rpioso: locally attached https servers on the same network if outbound connections are required | 15:58 |
| iurygregory | rpittau,++ | 15:59 |
| rpittau | we discussed the Yoga Topics already, so we can skip that | 15:59 |
| TheJulia | rpioso: naturally, not every operator. Some are willing to allow some specific endpoint access such as the conductor's webserver or swift, but it really varries | 15:59 |
| rpittau | last but not least | 15:59 |
| rpittau | #topic Who is going to run the next meeting? | 15:59 |
| iurygregory | I can run | 15:59 |
| rpittau | thanks iurygregory :) | 15:59 |
| rpittau | that's all folks! | 16:00 |
| dtantsur | TheJulia: if they use virtual media, they already need to allow the conductor | 16:00 |
| rpittau | #endmeeting | 16:00 |
| opendevmeet | Meeting ended Mon Oct 25 16:00:05 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:00 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/ironic/2021/ironic.2021-10-25-15.00.html | 16:00 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/ironic/2021/ironic.2021-10-25-15.00.txt | 16:00 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/ironic/2021/ironic.2021-10-25-15.00.log.html | 16:00 |
| TheJulia | rpioso: uniform point of agreement seems to be an absolute no for just go to the internet. | 16:00 |
| rpioso | TheJulia: The locally attached web server seems like yet another way. Could that be a follow-on to Redfish firmware update, Redfish vmedia, and ilo firmware update? Seems like that ask applies to at least those 3. | 16:04 |
| tzumainn | TheJulia, I didn't want to interrupt the meeting, but just letting you know that one of my comments on the restricted allocation patch explains why I think it's a bug - I could definitely be wrong though | 16:07 |
| arne_wiebalck | bye everyone, see you tomorrow o/ | 16:08 |
| rpittau | good night everyone! o/ | 16:08 |
| rpioso | iurygregory: Is the RFC approved. Does the community support the enhancement request to improve the Redfish firmware update UX? | 16:08 |
| dtantsur | rpioso: I personally like the RFE, just two things: 1) I'd prefer to exclude handling of archives (no zip bombs on the conductor :), 2) I'd include an optional parameter download_source similar to image_download_source | 16:11 |
| TheJulia | tzumainn: I'm walking through it noww ith verbose comments | 16:11 |
| iurygregory | rpioso, I don't think we reached full consensus to say is approved, based on what I saw from the discussion, I do like the idea of the RFE =) | 16:11 |
| *** dviroel|rover|lunch is now known as dviroel|rover | 16:11 | |
| rpioso | dtantsur: Which section should contain download_source? | 16:12 |
| dtantsur | rpioso: I think it may actually become a clean step parameter next to each URL | 16:13 |
| rpioso | dtantsur: And, if true, then utilize [redfish] use_swift, etc. settings? | 16:14 |
| dtantsur | yeah, I'm okay with everything else | 16:14 |
| iurygregory | I think if you change the points dtantsur mentioned we can consider rfe-approved =) | 16:14 |
| rpioso | dtantsur: We'll add that optional parameter. I propose its default value be true, since that's what the other features have been doing forever-ish. | 16:15 |
| dtantsur | rpioso: it's not boolean, it's a string with several options (check image_download_source in ironic.conf) | 16:15 |
| dtantsur | (which is probably an implementation detail at this point) | 16:16 |
| rpioso | dtantsur: Got it! (I hadn't pulled it up :-( | 16:17 |
| rpioso | dtantsur: Are you willing to accept archive handling? I feel it's very, very handy for operators. One archive per server model, ... | 16:18 |
| rpioso | iurygregory: We'll make the change dtantsur and TheJulia suggested. Thank you! | 16:18 |
| dtantsur | rpioso: I feel like it's a weird precedent, especially in the view of potential archive-based issues (like zim or tar bombs).. | 16:18 |
| dtantsur | I need to think about it for some while.. what if we land the first version without it? | 16:19 |
| rpioso | dtantsur: Hasn't the ilo been doing this? | 16:19 |
| dtantsur | a good question, needs checking | 16:19 |
| dtantsur | rpioso: on a very-very brief look, they seem to have one file per update | 16:21 |
| dtantsur | they do seem to handle RPM files (per docs), but probably it happens somewhere in proliantutils | 16:22 |
| dtantsur | I guess we can come to this question from another direction: | 16:22 |
| dtantsur | rpioso: what's the standard form updates are distributed? | 16:23 |
| dtantsur | do vendors (Dell, for example), actually distribute archives that consumers are supposed to extract? | 16:23 |
| rpioso | dtantsur: Yeah, the ilo RPM file contains a .scexe. I don't know if that's compressed. | 16:31 |
| rpioso | dtantsur: For PowerEdge servers, I see .EXE files on dell.com. Supporting an archive is meant to make it easier for operators, because a server model/configuration may need to have up to ~10 packages updated. | 16:34 |
| TheJulia | tzumainn: https://review.opendev.org/c/openstack/ironic/+/812007/2/ironic/api/controllers/v1/allocation.py <-- line 309, which one is actually failing? | 16:34 |
| dtantsur | rpioso: if an archive is not something the operators receive, I doubt it will be something they'll want to upload | 16:35 |
| dtantsur | keep in mind, this all will likely be scripted in some way | 16:35 |
| dtantsur | I'd start with a smaller version and grow it if we can requests | 16:35 |
| dtantsur | s/can/get/ | 16:35 |
| dtantsur | (which is to say, my position is not "NO, NEVER", rather "let's wait with fancy features") | 16:36 |
| dtantsur | see you tomorrow folks | 16:51 |
| dtantsur | o/ | 16:51 |
| TheJulia | tzumainn: okay, comments posted | 16:52 |
| tzumainn | TheJulia, so I think I started hitting this issue when I was using metalsmith as a non-admin, and was getting errors because the allocations were being created with no owner | 16:52 |
| tzumainn | TheJulia, I'll reply on the patch, thanks! | 16:52 |
| TheJulia | tzumainn: so, they *should* be getting an owner added along the way | 16:52 |
| TheJulia | tzumainn: worst comes to worst | 16:52 |
| tzumainn | TheJulia, yep, and the reason they're not is because they're passing the baremetal:allocation:create check | 16:53 |
| TheJulia | tzumainn: system admin scoped ? | 16:53 |
| tzumainn | TheJulia, nope, just normal members of a project that has lessee access to a node | 16:53 |
| TheJulia | ahh | 16:53 |
| TheJulia | I see | 16:53 |
| TheJulia | tzumainn: is enforce_new_defaults enabled? | 16:54 |
| TheJulia | tzumainn: ahh, I see | 16:55 |
| TheJulia | so you changed create, took away role:member, changed to system member which would send it down the path of auto-reconciling it | 16:55 |
| TheJulia | but that is not actually right | 16:55 |
| TheJulia | so we need to | 16:55 |
| TheJulia | line 335 of allocation.py | 16:56 |
| TheJulia | not make it conditional on enforce_new_defaults | 16:56 |
| TheJulia | err | 16:56 |
| TheJulia | no | 16:56 |
| TheJulia | yeah, we need to explicitly handle the other case there *as well* | 16:56 |
| TheJulia | in addition to outside of it | 16:57 |
| TheJulia | there being the overall method | 16:57 |
| TheJulia | line 339 needs to move over 4 spaces to the left out of the except handling | 16:59 |
| tzumainn | TheJulia, ahhh, I see what you're saying - yeah, I think there's a problem in the code, but I also misunderstood what the new policy was doing | 16:59 |
| TheJulia | and if not allocation.get('owner') around it | 16:59 |
| TheJulia | yeah, agree there definitely is | 16:59 |
| TheJulia | err, that should be "if project and allocation.get('owner') is None" then set an owner override | 17:01 |
| tzumainn | TheJulia, I misunderstood the system scope, but looking at the defaults - isn't it true that if a user passes allocation:create_restricted, they're guaranteed to pass allocation:create as well? | 17:01 |
| TheJulia | tzumainn: it is not | 17:01 |
| TheJulia | create_restrcited is restricted to system scoped accounts only | 17:01 |
| tzumainn | because create_restricted is set to SYSTEM_MEMBER, while allocation:create is ALLOCATION_CREATOR, which is SYSTEM_MEMBER or SYSTEM_ADMIN? | 17:01 |
| TheJulia | becasue it basically allows creation of records outside of the rbac model | 17:02 |
| tzumainn | or am I misunderstanding how those default policies work? | 17:03 |
| TheJulia | https://github.com/openstack/ironic/blob/2ff7f553c08ab74c4b09763110e43168b44d638c/ironic/api/controllers/v1/allocation.py#L360-L361 | 17:04 |
| TheJulia | so, it *only* records it if set to true | 17:05 |
| TheJulia | that seems like the bug | 17:05 |
| TheJulia | tzumainn: possibly, it certinly is not ocmplex, and allocations was the painful edge case | 17:05 |
| tzumainn | TheJulia, okay, so just to confirm my understanding | 17:06 |
| tzumainn | the default for create_restricted is here: https://github.com/openstack/ironic/blob/master/ironic/common/policy.py#L1607 | 17:07 |
| tzumainn | and the default for create should be more restricted, and is here: https://github.com/openstack/ironic/blob/master/ironic/common/policy.py#L1599 | 17:07 |
| tzumainn | but that resolves to https://github.com/openstack/ironic/blob/master/ironic/common/policy.py#L136 | 17:08 |
| tzumainn | and that actually seems *less* restrictive to me? | 17:08 |
| TheJulia | tzumainn: no, create is literally any authorized user | 17:17 |
| TheJulia | because they *can* ask for baremetal, there is no guarentee they *will* get it though | 17:18 |
| TheJulia | create_restricted is restricted intentionally to system scoped users, i.e. system admins | 17:18 |
| tzumainn | TheJulia, I think that's reversed from the original intent, isn't it? | 17:19 |
| TheJulia | no, restricted was always intended to be more restricted | 17:19 |
| tzumainn | okay, yeah, that's my understanding | 17:19 |
| tzumainn | so: https://github.com/openstack/ironic/blob/2ff7f553c08ab74c4b09763110e43168b44d638c/ironic/api/controllers/v1/allocation.py#L304 | 17:20 |
| tzumainn | at a high level: check if allowed to create, if not check if allowed to create restricted | 17:20 |
| tzumainn | but if I'm reading the default policies correctly, if a user is allowed to create restricted then they will always be allowed to create, right? | 17:21 |
| TheJulia | tzumainn: is enforce_new_defaults set to true or false? | 17:21 |
| tzumainn | I tested with both, but currently it's set to false | 17:22 |
| TheJulia | tzumainn: that is why this is happeneing then | 17:22 |
| TheJulia | https://github.com/openstack/ironic/blob/master/ironic/api/controllers/v1/allocation.py#L360-L384 | 17:22 |
| tzumainn | TheJulia, the issue I saw happens before we even get there | 17:23 |
| tzumainn | on https://github.com/openstack/ironic/blob/master/ironic/api/controllers/v1/allocation.py#L346 | 17:23 |
| opendevreview | Nisha Agarwal proposed openstack/ironic master: Add nvme as interface_type for RAID input https://review.opendev.org/c/openstack/ironic/+/815110 | 17:23 |
| TheJulia | okay | 17:23 |
| TheJulia | so... hmm | 17:23 |
| TheJulia | https://github.com/openstack/ironic/blob/2ff7f553c08ab74c4b09763110e43168b44d638c/ironic/api/controllers/v1/allocation.py#L316 is getting called right? | 17:24 |
| TheJulia | tzumainn: do these users pass this policy check https://github.com/openstack/ironic/blob/master/ironic/common/policy.py#L1642 ? | 17:26 |
| tzumainn | TheJulia, ahh, so that's what should be caught if we're not using secure rbac - okay, that's something I could check | 17:28 |
| tzumainn | TheJulia, but - if someone is using secure rbac, and has default policies | 17:28 |
| TheJulia | okay, so yeah, if they are traditional pre SRBAC effort admins, yes, they get away with not submitting a owner, for compatability reasons | 17:29 |
| TheJulia | then later on it should be caught and added in a mandatory fashion | 17:29 |
| tzumainn | sorry for trailing off, I have a better understanding of what's going on now but still processing | 17:31 |
| TheJulia | no worries | 17:31 |
| TheJulia | This is super convoluted because of the compatability | 17:31 |
| tzumainn | TheJulia, okay, so in the secure rbac world, is it expected that someone with permission to create a restricted allocation never gets to https://github.com/openstack/ironic/blob/2ff7f553c08ab74c4b09763110e43168b44d638c/ironic/api/controllers/v1/allocation.py#L324-L331 ? | 17:34 |
| TheJulia | so https://github.com/openstack/ironic/blob/2ff7f553c08ab74c4b09763110e43168b44d638c/ironic/api/controllers/v1/allocation.py#L330-L332 would be remedying the situation, if https://github.com/openstack/ironic/blob/2ff7f553c08ab74c4b09763110e43168b44d638c/ironic/api/controllers/v1/allocation.py#L316 is raising an exception | 17:35 |
| TheJulia | tzumainn: that is correct | 17:35 |
| tzumainn | TheJulia, oh, weird | 17:36 |
| tzumainn | okay, I think I get it now - https://github.com/openstack/ironic/blob/2ff7f553c08ab74c4b09763110e43168b44d638c/ironic/api/controllers/v1/allocation.py#L346 is handling the logic if not using secure rbac | 17:37 |
| TheJulia | tzumainn: any chance I can get the policy dictionary data logged by the api for one of these requests | 17:37 |
| tzumainn | and https://github.com/openstack/ironic/blob/2ff7f553c08ab74c4b09763110e43168b44d638c/ironic/api/controllers/v1/allocation.py#L360-L381 is handling the logic if using secure rbac? | 17:38 |
| tzumainn | TheJulia, yeah, let me undo some of my changes though so it's fresh | 17:38 |
| TheJulia | tzumainn: okay | 17:38 |
| TheJulia | and yes, and yes | 17:39 |
| tzumainn | TheJulia, okay, so I think most of my changes in the patch are unnecessary, except for the one involving this line: | 17:45 |
| tzumainn | https://github.com/openstack/ironic/blob/2ff7f553c08ab74c4b09763110e43168b44d638c/ironic/api/controllers/v1/allocation.py#L326 | 17:45 |
| tzumainn | this is the non-secure rbac case where we are creating a restricted allocation | 17:45 |
| tzumainn | and we want this code to set the allocation owner for us, or at least guarantee that the allocation has the owner equal to the user's project | 17:45 |
| tzumainn | so instead of "if project and..." it should be "if allocation.get('owner') and...", right? | 17:46 |
| tzumainn | because if no allocation owner is set, then we're happy and just set it ourselves on line 332? | 17:46 |
| TheJulia | tzumainn: are we 100% sure we're hitting an exception there, I ask becasue what youre describing seems like we don't | 17:47 |
| tzumainn | fair enough, let me revert the change and verify! | 17:47 |
| TheJulia | But, if we just magically add the allocation owner there, if not populated, it may likely just be okay | 17:48 |
| TheJulia | just the issue is the create_pre_rbac rule can allow pre-rbac users to still do the exact same thing if they are in the barmetal_admin group or a member in the admin project | 17:49 |
| TheJulia | yay for confusion! | 17:49 |
| tzumainn | TheJulia, okay! just tested non secure RBAC, unpatched code; creating an allocation fails | 18:04 |
| tzumainn | it passes if I change: | 18:04 |
| tzumainn | https://github.com/openstack/ironic/blob/2ff7f553c08ab74c4b09763110e43168b44d638c/ironic/api/controllers/v1/allocation.py#L326 | 18:04 |
| tzumainn | and | 18:04 |
| tzumainn | https://github.com/openstack/ironic/blob/2ff7f553c08ab74c4b09763110e43168b44d638c/ironic/api/controllers/v1/allocation.py#L328 | 18:04 |
| tzumainn | so that instead of "if project..." it's "if allocation.get('owner')..." | 18:04 |
| tzumainn | which makes sense to me, as project is simply the project passed in as part of the request, and what we really want is to check if the user is trying to set a not-themselves-project for the allocation | 18:05 |
| TheJulia | tzumainn: so the purpose behind if project, is to ignore system scoped cases | 18:05 |
| tzumainn | TheJulia, yep, but you said that this logic was only being used for non-secure RBAC, right? | 18:06 |
| TheJulia | mostly yes, and I guess it is me being defensive | 18:06 |
| TheJulia | code wise | 18:07 |
| tzumainn | it is an extremely complicated logic chain that you had to work through to support both secure RBAC and the former use case! | 18:08 |
| TheJulia | indeed | 18:08 |
| TheJulia | very :( | 18:08 |
| TheJulia | so, I'm actually better with removing the if project portion, but I feel like the project should still be populated | 18:08 |
| TheJulia | it just seems *weird* | 18:08 |
| tzumainn | doesn't https://github.com/openstack/ironic/blob/2ff7f553c08ab74c4b09763110e43168b44d638c/ironic/api/controllers/v1/allocation.py#L332 populate the project? | 18:09 |
| tzumainn | I might not understand what you mean by populate the project | 18:09 |
| tzumainn | my understanding of that code segment is that it's literally just making sure that a restricted user isn't setting someone else as the owner | 18:09 |
| TheJulia | yes, and in system scope it would end up being none | 18:10 |
| tzumainn | oh, I see what you're saying - whereas in non-secure RBAC it's always going to be populated with the user's project | 18:11 |
| tzumainn | in that case would it make sense for it to be: | 18:11 |
| tzumainn | if project and allocation.get('owner') and project != allocation.get('owner'): | 18:12 |
| tzumainn | ? | 18:12 |
| tzumainn | and for https://github.com/openstack/ironic/blob/2ff7f553c08ab74c4b09763110e43168b44d638c/ironic/api/controllers/v1/allocation.py#L328 it'd just be | 18:12 |
| tzumainn | "if allocation.get('owner') and not CONF.oslo_policy.enforce_new_defaults:" since that's explicitly the non-secure RBAC case? | 18:13 |
| TheJulia | I *think*, maybe | 18:13 |
| TheJulia | prime concern, do the tests all pass ;) | 18:14 |
| tzumainn | hahaha, yep | 18:14 |
| tzumainn | I'll try it, and make sure there's a test to cover this use case as well | 18:14 |
| tzumainn | and I'll remove all the secure RBAC thrashing I did | 18:14 |
| TheJulia | okay | 18:14 |
| TheJulia | sorry for the pain | 18:14 |
| TheJulia | where oh where did I put my brain | 18:15 |
| tzumainn | oh, not at all, this is all extremely hard and everything else works amazingly | 18:16 |
| TheJulia | \o/ | 18:16 |
| TheJulia | I need to write more tests... I think.... on this whole thing this cycle | 18:16 |
| TheJulia | somehow I'll make/find/invent time | 18:16 |
| TheJulia | But I suspect it will largely be the "this should never work" cases | 18:16 |
| opendevreview | Merged openstack/ironic stable/wallaby: Do not use any parts of image URL in temporary file names https://review.opendev.org/c/openstack/ironic/+/814378 | 18:53 |
| opendevreview | Tzu-Mainn Chen proposed openstack/ironic master: Fix restricted allocation creation for old policy defaults https://review.opendev.org/c/openstack/ironic/+/812007 | 19:13 |
| TheJulia | tzumainn: release note :) | 20:30 |
| TheJulia | tzumainn: I *think* that does it, if I properly understand the exact case your hitting | 20:30 |
| tzumainn | TheJulia, ah, okay! yep, I'll add a release note | 20:30 |
| *** dviroel|rover is now known as dviroel|rover|out | 20:56 | |
| opendevreview | Tzu-Mainn Chen proposed openstack/ironic master: Fix restricted allocation creation for old policy defaults https://review.opendev.org/c/openstack/ironic/+/812007 | 21:19 |
| opendevreview | Steve Baker proposed openstack/ironic master: Add platform:rpm shim, grub packages to bindep https://review.opendev.org/c/openstack/ironic/+/815386 | 21:53 |
| opendevreview | Steve Baker proposed openstack/ironic master: WIP Capture [pxe]loader_file_paths for distros https://review.opendev.org/c/openstack/ironic/+/815392 | 23:54 |
| stevebaker[m] | zigo: hey, I'd be interested to know what you think of https://review.opendev.org/c/openstack/ironic/+/815392 | 23:55 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!