opendevreview | Jacob Anders proposed openstack/ironic master: Add support for verify steps https://review.opendev.org/c/openstack/ironic/+/800001 | 05:27 |
---|---|---|
arne_wiebalck | Good morning janders and Ironic! | 05:56 |
janders | good morning arne_wiebalck o/ | 06:02 |
janders | how was your weekend? | 06:02 |
arne_wiebalck | too short :) | 06:05 |
arne_wiebalck | what about yours? | 06:06 |
janders | I needed a holiday after my holiday | 06:08 |
janders | so - taking it easy, not doing much | 06:08 |
janders | I needed some of that :) | 06:08 |
arne_wiebalck | yeah, not sure why holidays usually "do not work" :) | 06:13 |
janders | :) | 06:13 |
arne_wiebalck | always seem to need some rest after the rest | 06:14 |
iurygregory | good morning janders arne_wiebalck and Ironic o/ | 06:26 |
janders | good morning iurygregory o/ | 06:26 |
arne_wiebalck | I am trying to understand some nightly activity in our deployment: from our monitoring it seems that when Ironic loses BMC access to check the power, it gives up checking, changes a node's power state in the DB to 'None', but then comes back after a while (24 hours?) to recheck? (I have a rack full of nodes which have no access to the management network since some days and these nodes seem to trigger sth like this.) | 06:27 |
arne_wiebalck | TheJulia: dtantsur ^^ | 06:27 |
arne_wiebalck | Good morning, iurygregory o/ | 06:27 |
rpittau | good morning ironic! o/ | 07:19 |
iurygregory | good morning rpittau o/ | 07:20 |
rpittau | hey iurygregory :) | 07:20 |
iurygregory | I'm trying to do some tests with sushy-tools locally, I've created the VM like mentioned in our docs https://docs.openstack.org/sushy-tools/latest/user/dynamic-emulator.html#systems-resource-driver-libvirt but when I'm trying to list Systems I get empty list of members .-., anyone tested this? | 07:33 |
dtantsur | good morning ironic, happy Monday | 08:48 |
janders | hey dtantsur o/ | 08:48 |
rpittau | hey dtantsur :) | 08:48 |
dtantsur | arne_wiebalck: yes, ironic will retry power faults periodically | 08:48 |
dtantsur | this was added a few releases ago and was one of the most commonly asked feature :) | 08:48 |
arne_wiebalck | dtantsur: makes sense | 08:49 |
dtantsur | iurygregory: mismatch between session types? | 08:49 |
dtantsur | there is a qemu:///system session and then there is your user session | 08:49 |
iurygregory | good morning dtantsur o/ | 08:49 |
arne_wiebalck | dtantsur: do you have a pointer to where this controlled? | 08:49 |
dtantsur | hold on | 08:49 |
iurygregory | dtantsur, oh ok let me try to check this... =) | 08:49 |
iurygregory | ty! | 08:50 |
arne_wiebalck | (this is super useful when nodes come back and Ironic self-heals :)) | 08:50 |
dtantsur | we should really document it in https://docs.openstack.org/ironic/latest/admin/power-sync.html.. | 08:50 |
arne_wiebalck | yes | 08:50 |
arne_wiebalck | I can add something once I read the code | 08:51 |
dtantsur | arne_wiebalck: I can do it, I still have it more or less in the context | 08:51 |
arne_wiebalck | perfect, thanks! | 08:51 |
arne_wiebalck | dtantsur: I realised now that what I see is a one-off large drain/shutoff to prepare for a scheduled intervention (I also see the regular power recheck, but at a much higher frequency, which makes sense) | 09:16 |
opendevreview | Dmitry Tantsur proposed openstack/ironic master: Document recovery from power faults https://review.opendev.org/c/openstack/ironic/+/811090 | 09:24 |
dtantsur | arne_wiebalck: ^^^ | 09:24 |
arne_wiebalck | dtantsur: thanks, LGTM! | 09:41 |
opendevreview | Merged openstack/ironic master: Document recovery from power faults https://review.opendev.org/c/openstack/ironic/+/811090 | 10:07 |
opendevreview | Tadeas Kot proposed openstack/ironic-inspector master: Add support for state selector in the list introspection https://review.opendev.org/c/openstack/ironic-inspector/+/807578 | 12:05 |
timeu | Hi all, anybody has seen the "boot option restoration" screen after deploying Lenovo machines with OSP 16.2 (https://pasteboard.co/m4LoiDGBCbKQ.png & https://pasteboard.co/RYt60CJ3HM6u.png) with Lenovo nodes ? One has to select ("Continue to boot" or "Always continue to boot") otherwise the node stays in a boot loop | 12:26 |
opendevreview | Merged openstack/ironic stable/ussuri: [Stable only] remove require_exclusive_lock from detect_vendor https://review.opendev.org/c/openstack/ironic/+/810656 | 12:30 |
* iurygregory never saw this before =( | 12:32 | |
janders | see you tomorrow Ironic o/ | 12:36 |
opendevreview | Verification of a change to openstack/ironic master failed: require_exclusive_lock: log traceback that lead to an error https://review.opendev.org/c/openstack/ironic/+/810615 | 12:48 |
dtantsur | timeu: I haven't seen this either. you probably need to ask lenovo people what it means. | 12:55 |
timeu | ok will try to get hold of somebody. I think it might need cleanup of the UEFI entries because right now the node has 3 ironic related UEFI entries (i.e. : Boot0000* red HD(1,GPT,69cc87f8-523a-42b6-9975-c0a176fda5c5,0x800,0x64000)/File(\EFI\red\grubx64.efi), Boot0005* Red Hat Enterprise Linux HD(1,MBR,0xcdc23ed2,0x800,0x64000)/File(\EFI\redhat\shimx64.efi), Boot0009* | 12:59 |
timeu | ironic1 HD(1,GPT,90744a9a-c9bc-41f4-bcad-b716d12254bd,0x800,0x64000)/File(\EFI\BOOT\BOOTX64.EFI)) | 12:59 |
dtantsur | The last one is from ironic, I the the first two are added by RHEL itself | 13:04 |
TheJulia | good morning | 13:14 |
iurygregory | good morning TheJulia | 13:14 |
TheJulia | timeu: redfish or ipmi? | 13:15 |
* TheJulia tries to wake up | 13:16 | |
dtantsur | morning TheJulia | 13:18 |
timeu | TheJulia: this is with the ipmi driver | 13:33 |
timeu | but I haven't seen this behavior in OSP 16.1 tough, but also we updated the UEFI/BMC firmware between OSP 16.1 and OSP 16.2 | 13:33 |
timeu | I know there was some UEFI related fixes between OSP16.1 and OSP16.2 | 13:33 |
TheJulia | timeu: mostly on bootloader config/setup, but using efibootmgr just to insert the next boot record | 13:37 |
TheJulia | timeu: lenovo hardware traditionally ignores persistant commands from what I understand, so the pattern we take should be ideal for it but at the same time now I'm wondering :\ | 13:38 |
timeu | hmm I can try to switch to redfish for the overcloud nodes and see if it shows a differnt behavior. | 13:39 |
TheJulia | timeu: might as well | 13:41 |
TheJulia | timeu: this is largely the major difference in train w/r/t ipmi https://github.com/openstack/ironic/commit/41355d5a28fec5053060632fa06c1f8a669693fd#diff-0663a2e07480141672d2b0af61648fd38f0f343412d9e92a439c7faffc6d4628 | 13:42 |
TheJulia | major difference is ironic uses raw instead of ipmitool hoping that the data gets passed/sent through | 13:42 |
TheJulia | At least, for non-supermicro hardware | 13:43 |
timeu | hmm I am wondering now: I ran into following issue https://bugzilla.redhat.com/show_bug.cgi?id=2007268 and dtantsur suggested to set vendor=ignoreme to workaround this issue until it is fixed. Could this be the reason for the other issue ? | 13:44 |
* TheJulia sighs | 13:45 | |
TheJulia | that is a new one | 13:45 |
dtantsur | I think we only explicitly check for "supermicro", "ignoreme" shouldn't trigger any logic | 13:46 |
dtantsur | TheJulia: fix for bugzilla btw: https://review.opendev.org/c/openstack/ironic/+/810656 | 13:46 |
opendevreview | Julia Kreger proposed openstack/ironic stable/train: [Stable only] remove require_exclusive_lock from detect_vendor https://review.opendev.org/c/openstack/ironic/+/811150 | 13:47 |
TheJulia | well if supermicro, changes behavior ever so slightly, but otherwise it is stock | 13:48 |
opendevreview | Merged openstack/ironic stable/xena: Set IPA download branch and MAX_MICROVERSION https://review.opendev.org/c/openstack/ironic/+/810835 | 13:54 |
opendevreview | Verification of a change to openstack/ironic master failed: require_exclusive_lock: log traceback that lead to an error https://review.opendev.org/c/openstack/ironic/+/810615 | 14:10 |
TheJulia | seems like ironic-tempest-ipa-partition-pxe_ipmitool is becoming less and less stable :( | 14:14 |
dtantsur | yeah, I've seen several failures today | 14:16 |
dtantsur | it could be broken, I haven't checked, I must admit | 14:16 |
TheJulia | I've seen it fail sporatically last week | 14:32 |
TheJulia | all timing it looked like | 14:32 |
opendevreview | Riccardo Pittau proposed openstack/ironic-python-agent-builder master: Update qemu version https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/776507 | 14:36 |
opendevreview | Riccardo Pittau proposed openstack/ironic-python-agent-builder master: Update qemu version https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/776507 | 14:38 |
opendevreview | Danni Shi proposed openstack/ironic-python-agent master: Add an attestation extension https://review.opendev.org/c/openstack/ironic-python-agent/+/803510 | 14:55 |
TheJulia | #startmeeting ironic | 15:00 |
opendevmeet | Meeting started Mon Sep 27 15:00:35 2021 UTC and is due to finish in 60 minutes. The chair is TheJulia. 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 |
TheJulia | o/ | 15:00 |
stendulker | o/ | 15:00 |
rpittau | o/ | 15:00 |
TheJulia | #chair iurygregory | 15:00 |
opendevmeet | Current chairs: TheJulia iurygregory | 15:00 |
rloo | o/ | 15:01 |
TheJulia | Welcome to this week's Ironic meeting. I'm this week's host, TheJulia! | 15:01 |
opendevreview | Dmitry Tantsur proposed openstack/bifrost master: Enable authentication in sushy-tools https://review.opendev.org/c/openstack/bifrost/+/810686 | 15:01 |
TheJulia | This week's agenda... seems slightly out of date. :) | 15:01 |
TheJulia | #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting | 15:01 |
ajya | o/ | 15:01 |
erbarr | o/ | 15:02 |
* TheJulia fixes it | 15:02 | |
TheJulia | okay! | 15:03 |
TheJulia | #topic Announcements / Reminders | 15:03 |
TheJulia | #info Ironic released 18.2.0 last week \o/ | 15:03 |
TheJulia | This was the xena cycle release, and as such the stable branch has been created. | 15:03 |
sam_z | heck yea! | 15:03 |
TheJulia | #info Yoga PTG is in 3 weeks! | 15:04 |
TheJulia | #link https://www.eventbrite.com/e/project-teams-gathering-october-2021-tickets-161235669227 | 15:04 |
arne_wiebalck | o/ | 15:04 |
TheJulia | #link https://etherpad.opendev.org/p/ironic-yoga-ptg | 15:04 |
TheJulia | Does anyone have anything to announce or remind us of this week? | 15:05 |
* TheJulia takes silence as a no | 15:06 | |
TheJulia | Moving on! | 15:06 |
TheJulia | #topic Review action items from the previous meeting | 15:06 |
TheJulia | Last week we had two action items. | 15:06 |
TheJulia | The first was for iurygregory to send an email regarding the upcoming PTG, which he did. | 15:07 |
TheJulia | #link http://lists.openstack.org/pipermail/openstack-discuss/2021-September/025033.html | 15:07 |
TheJulia | The second was to sync up with the release team regarding deliverables. | 15:07 |
TheJulia | iurygregory: are you available clarify a little further on this to us | 15:07 |
TheJulia | ? | 15:07 |
TheJulia | Hmm, idle for 2 days. Okay! | 15:08 |
TheJulia | tl;dr from iurygregory's notes is that items listed as cycle-with-rc will be moved to cycle-with-intermediary which seems to be a reverse, but okay! | 15:09 |
TheJulia | Moving on! | 15:09 |
TheJulia | #topic Subteam Status Report | 15:09 |
TheJulia | #link https://etherpad.opendev.org/p/IronicWhiteBoard | 15:09 |
*** redrobot is now known as Guest1129 | 15:09 | |
TheJulia | I'm feeling like we should have articulated storage cleaning enhacements a little more on the whiteboard | 15:11 |
TheJulia | Is everyone good to proceed onward? | 15:12 |
arne_wiebalck | yes | 15:12 |
rpittau | yep | 15:13 |
TheJulia | #topic Deciding on priorities for the coming week | 15:13 |
TheJulia | #link https://review.opendev.org/q/hashtag:ironic-week-prio+status:open | 15:13 |
TheJulia | Looks like we've got some bug fixes trickling in, but it looks like most of them are already on the list | 15:14 |
TheJulia | Does anyone have anything they would like to add to the list in gerrit? | 15:14 |
rpittau | I've added https://review.opendev.org/c/openstack/bifrost/+/806328 | 15:15 |
TheJulia | sounds good to me | 15:16 |
TheJulia | Anyone have anything else? | 15:16 |
* TheJulia guesses no | 15:17 | |
TheJulia | Since we have no Discussion topics listed, we will proceed directly to Baremetal SIG | 15:17 |
TheJulia | #topic Baremetal SIG | 15:17 |
arne_wiebalck | Next meeting scheduled for Tuesday October 12, 2021 at 4 PM UTC (note the unusual time!) | 15:17 |
TheJulia | arne_wiebalck: anything new? Plotting for before the PTG? | 15:17 |
arne_wiebalck | The idea is to get some input for the PTG. Let's see how it goes. | 15:18 |
TheJulia | Sounds good! | 15:18 |
rpittau | arne_wiebalck: oh that's a pity, going to miss that :/ | 15:18 |
arne_wiebalck | I pushed the time to 4pm for east coast attendees. | 15:18 |
arne_wiebalck | sorry west coast | 15:18 |
TheJulia | unfortunately, it is during the time for the finance committee meeting | 15:19 |
TheJulia | silly finances :( | 15:19 |
arne_wiebalck | As usual, make some publicity! | 15:19 |
arne_wiebalck | oh | 15:19 |
TheJulia | I think I'll email the group and see if we can push it back an hour | 15:19 |
TheJulia | The finance committee that is | 15:19 |
arne_wiebalck | we can also move the SIG meeting | 15:20 |
arne_wiebalck | no announcement has gone out yet | 15:20 |
TheJulia | Fewer people to loop in to see if I can move the finance committee meeting | 15:20 |
* TheJulia makes a note to email the members | 15:20 | |
arne_wiebalck | I think timeu still had some things to discuss to which we did not get last time | 15:20 |
arne_wiebalck | TheJulia: ok, let me know | 15:20 |
arne_wiebalck | rpittau: it is the day or the time which does not suit you? | 15:21 |
rpittau | arne_wiebalck: the time, have a conflict downstream | 15:21 |
arne_wiebalck | hm | 15:21 |
TheJulia | hmm | 15:21 |
arne_wiebalck | heh | 15:21 |
rpittau | :/ | 15:21 |
TheJulia | Maybe it might be worthwhile to adjust the time a little | 15:21 |
arne_wiebalck | in which direction? | 15:21 |
TheJulia | ?either? Going earlier will make it harder for US west coast operators, but honestly it would be past EOD in Europe if we were to push it to a convenient time for them. | 15:22 |
arne_wiebalck | yes | 15:22 |
TheJulia | rpittau: would earlier by 1 hour work? | 15:23 |
rpittau | yes, that would work for me | 15:23 |
arne_wiebalck | would that still work for west coast operators ? | 15:23 |
TheJulia | it would be 8 am local | 15:23 |
TheJulia | most wouldn't really get their day started until 9-am and then it is the first thing in the morning items. | 15:24 |
TheJulia | so 8 is *likely* better all around | 15:24 |
TheJulia | at least for those that wake up around 7, as opposed to those that wake up at 8 or 9 am :) | 15:24 |
arne_wiebalck | another option would be a "US" one later that day (if we find someone to host) | 15:25 |
TheJulia | I would be happy to host | 15:25 |
TheJulia | If we want to hold two I think that could actually work really well | 15:26 |
TheJulia | since it is feedback loop into the PTG | 15:26 |
TheJulia | Overall, that brings more creedence to commonalities between sessions | 15:26 |
arne_wiebalck | ok, then we keep the usual slot at 2pm UTC and I let you decide on a later one? Once we have this, we sent out a single announcement. | 15:27 |
TheJulia | sounds good to me | 15:27 |
TheJulia | I'll ping a couple operators to see what would be the best time on that same day for US friendly time | 15:27 |
arne_wiebalck | awesome, thanks TheJulia ! | 15:27 |
arne_wiebalck | I think that is it for the SIG | 15:28 |
TheJulia | Awesome | 15:30 |
TheJulia | Well, we have no discussion items... | 15:30 |
* dtantsur realizes the meeting is happening | 15:30 | |
TheJulia | So onward to Open Discussion | 15:30 |
TheJulia | #topic Open Discussion | 15:30 |
* TheJulia gives dtantsur coffee | 15:30 | |
dtantsur | Thank you :) Open discussion: how to stop getting lost in time? | 15:30 |
dtantsur | on the bright side, I typed some letters: https://owlet.today/posts/integrating-coreos-installer-with-ironic/ | 15:31 |
arne_wiebalck | TheJulia: going over the questions worked well last time :) | 15:31 |
TheJulia | arne_wiebalck: awesome! | 15:31 |
rloo | nice letters dtantsur! | 15:33 |
dtantsur | :) | 15:33 |
dtantsur | another open discussion: outreachy - yes/no? | 15:33 |
TheJulia | If annyone has any ideas: https://github.com/OpenStackweb/ironic-website/pull/43 | 15:33 |
TheJulia | dtantsur: sure!? but what? | 15:34 |
dtantsur | okay, lemme go through the storyboard today | 15:34 |
dtantsur | I'm quite sure we can find something small | 15:34 |
TheJulia | sounds good to me | 15:35 |
dtantsur | who is mentoring this time? | 15:36 |
dtantsur | I can continue, but I'll also happily hand it over to someone, especially someone new to mentoring | 15:36 |
TheJulia | I guess I can mentor | 15:36 |
TheJulia | I do need to do more mentoring this winter | 15:37 |
dtantsur | maybe the driver_info reform (username renaming and so on)? | 15:37 |
TheJulia | single parameter defaults and the like | 15:37 |
TheJulia | yeah | 15:37 |
TheJulia | I like that a lot | 15:38 |
TheJulia | and that simplifies some of the vendor driven delineations and confusion we've had over the years | 15:38 |
dtantsur | yep | 15:38 |
dtantsur | we can increase the scope a bit to collect, understand and document all driver_info fields we use | 15:38 |
dtantsur | wanna write an RFE? or do we have one? | 15:38 |
dtantsur | btw I can co-mentor if nobody else wants. just for HA reasons. | 15:39 |
TheJulia | I thought we had one | 15:39 |
TheJulia | dtantsur: I think that would be good | 15:39 |
rpittau | I could co-mentor too | 15:40 |
TheJulia | dtantsur: ++++ | 15:40 |
TheJulia | ++++ w/r/t documenta s well | 15:40 |
TheJulia | document | 15:40 |
* TheJulia can't type today | 15:40 | |
dtantsur | typing is overrates | 15:40 |
dtantsur | hmmm | 15:40 |
dtantsur | what about we have a review jam dedicated to old RFEs | 15:40 |
dtantsur | there are so many items, reaction to which is "mmm, cool idea, will not happen" | 15:41 |
TheJulia | That would be good for tomorrow | 15:41 |
TheJulia | what times tomorrow? | 15:41 |
dtantsur | did we have a normal slot? | 15:41 |
TheJulia | We do, I have a 7 am it looks like | 15:41 |
* TheJulia looks up the slots | 15:41 | |
TheJulia | ugh, I have another board related meeting at the first slot tomorrow | 15:42 |
TheJulia | I can do the later slot just fine | 15:42 |
dtantsur | what time UTC? | 15:42 |
TheJulia | This says 5PM UTC | 15:43 |
*** pmannidi is now known as pmannidi|AFK | 15:43 | |
dtantsur | a bit uncomfortable but doable | 15:43 |
dtantsur | I assume a bit too late for other europeans? | 15:44 |
TheJulia | We could also decide and say 4pm is the time tomorrow | 15:44 |
TheJulia | I'm good with 4PM fwiw | 15:44 |
dtantsur | same | 15:44 |
TheJulia | I propose we meet at 4pm? | 15:44 |
TheJulia | Any objections? | 15:44 |
dtantsur | anyone else? | 15:44 |
sam_z | would that be a good time to bring up the power spec proposal? | 15:44 |
TheJulia | sam_z: yes, but I'm also happy to discuss/review it after this meeting too :) | 15:45 |
sam_z | oh neat! | 15:45 |
TheJulia | I just need to find a storyboard item # and post a BZ | 15:45 |
dtantsur | well, I wanted to go through the list of reviews | 15:45 |
dtantsur | oh | 15:45 |
dtantsur | s/reviews/RFEs/ | 15:45 |
TheJulia | dtantsur: yeah, we'll do that tomorrow | 15:45 |
dtantsur | more like: yay/nay | 15:45 |
TheJulia | heh | 15:45 |
* dtantsur can neither type nor think | 15:45 | |
TheJulia | I think we're good and on the same page | 15:45 |
sam_z | mondays... | 15:45 |
TheJulia | even if neither of us can type | 15:45 |
dtantsur | which is to say, let's discuss sam_z's proposal after the meeting? | 15:45 |
TheJulia | Anything else before we move onward? | 15:46 |
TheJulia | dtantsur: ++ | 15:46 |
TheJulia | maybe after meeting + time to make coffee | 15:46 |
dtantsur | fair | 15:46 |
TheJulia | Moving onward! | 15:46 |
sam_z | nothin of substance from me here | 15:46 |
TheJulia | #topic Who is going to run the next meeting? | 15:46 |
TheJulia | I'm guessing, next week's Vict^H^H^Holunteer is iurygregory :) | 15:46 |
TheJulia | I don't know if I'll be around next week, I've got a Jury summons :( | 15:47 |
dtantsur | I think I can do it next week | 15:47 |
TheJulia | Okay! | 15:47 |
dtantsur | unless iurygregory wants MOAR POWER :D | 15:47 |
TheJulia | oh no, MOAR POWER jokes | 15:47 |
TheJulia | Time to call it a meeting! | 15:47 |
TheJulia | Thanks everyone! | 15:47 |
dtantsur | o/ | 15:48 |
TheJulia | #endmeeting | 15:48 |
opendevmeet | Meeting ended Mon Sep 27 15:48:08 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:48 |
opendevmeet | Minutes: https://meetings.opendev.org/meetings/ironic/2021/ironic.2021-09-27-15.00.html | 15:48 |
opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/ironic/2021/ironic.2021-09-27-15.00.txt | 15:48 |
opendevmeet | Log: https://meetings.opendev.org/meetings/ironic/2021/ironic.2021-09-27-15.00.log.html | 15:48 |
sam_z | https://review.opendev.org/c/openstack/ironic-specs/+/808804/ <- code review page and storyboard page -> https://storyboard.openstack.org/#!/story/2009184 | 15:55 |
sam_z | (no rush tho! i appreciate y'all's time regardless!) | 15:55 |
TheJulia | wow, 994 lines! | 15:59 |
arne_wiebalck | sam_z: can't you make it 1000 ? ;) | 15:59 |
TheJulia | arne_wiebalck: are you singing "When you're evil" ? | 16:00 |
arne_wiebalck | heh | 16:00 |
TheJulia | if so, it would be totally approvable and I would happilly join along :) | 16:00 |
arne_wiebalck | no, when I saw 994 lines I was proud we take the spec process very seriously | 16:01 |
arne_wiebalck | srsly, that was my first thought | 16:01 |
sam_z | i will add exactly 5 more, no more no less | 16:02 |
arne_wiebalck | :-D | 16:02 |
arne_wiebalck | the real challenge will be to keep it at 1000 when incorporating feedback | 16:02 |
sam_z | i uh. really wanted to be thorough i suppose. on the bright side i imagine it will also save me time writing documentation when the time comes | 16:02 |
* arne_wiebalck is not sure if he is helping the "we take specs serious" case here | 16:03 | |
dtantsur | I remember on my first pass I stumbled upon the authentication | 16:03 |
dtantsur | my first reaction was "wtf, why session service" | 16:03 |
dtantsur | then I started reading the details, and it kind of started making sense.. | 16:04 |
dtantsur | but I have headache from keystone :) | 16:04 |
dtantsur | sam_z: could you summarize, in simple words, what you're doing with SessionService? | 16:04 |
dtantsur | .. and whether the whole thing works with standalone (HTTP basic) auth? | 16:05 |
sam_z | essentially i plan on using it as a way for redfish clients to authenticate via keystone (making auth tokens and the like) through a redfish-compatible interface | 16:05 |
dtantsur | sam_z: okay, so Session ID is pretty much keystone token in disguise? | 16:06 |
sam_z | yes. | 16:07 |
sam_z | i wanted to add as little new things as possible | 16:07 |
dtantsur | and the auth endpoint is just a pass-thru to keystone? | 16:07 |
* sam_z is not sure if that is correct grammar but i digress | 16:07 | |
sam_z | essentially | 16:07 |
dtantsur | english doesn't have grammar, anyone does what they want | 16:08 |
* dtantsur ducks | 16:08 | |
dtantsur | sam_z: got it. makes sense, just don't forget that we also have the standalone use case (with HTTP basic auth). | 16:08 |
sam_z | i did bring up a consideration for http basic auth in around the middle of the spec | 16:08 |
sam_z | line 223 (thats a lot of lines lol) | 16:09 |
dtantsur | ah, cool. yeah, I haven't read it again, trying to clear up the most confusing parts first | 16:09 |
dtantsur | everything else should be straightforward | 16:09 |
dtantsur | okay, actually | 16:10 |
dtantsur | sam_z: how do you pass scope parameters to keystone? I think it's authentication requires user_domain_id, project_id/name and project_domain_id | 16:10 |
dtantsur | mmm, probably not for app credentials? I don't know much about app credentials. | 16:10 |
sam_z | ah so that's a problem i ran into and i plan to solve it by making the user generate an application credential to use for authentication | 16:10 |
dtantsur | they're not scoped? | 16:11 |
dtantsur | or rather: the user ID already has a scope? | 16:11 |
sam_z | they should be scoped when created i think | 16:11 |
dtantsur | which even makes sense. yes. | 16:11 |
dtantsur | okay, I should finally stop torturing you and start reading :) | 16:11 |
sam_z | app creds from what i've read are scoped to user and project which i think implicitly assumes a domain? | 16:12 |
dtantsur | yeah, in keystone v3 users and projects exist in a domain | 16:12 |
dtantsur | .. which doesn't 100% guarantee that keystone doesn't want domain to be specified | 16:12 |
dtantsur | have you tried playing with app credentials? I have 0 experience. | 16:12 |
sam_z | i have not actually | 16:13 |
sam_z | i will make a point to do that, today ideally | 16:13 |
sam_z | if not today then soon (tm) | 16:13 |
dtantsur | :) | 16:13 |
* dtantsur wonders if TheJulia knows everything about keystone now :) | 16:14 | |
sam_z | this makes me think if you use auth token id + secret for authentication you don't need to specify anything more: https://docs.openstack.org/keystone/latest/user/application_credentials.html#using-application-credentials | 16:14 |
dtantsur | yeah, just reading the same thing | 16:15 |
dtantsur | seems you're right | 16:15 |
TheJulia | everything, eek?! | 16:19 |
* TheJulia hides | 16:19 | |
TheJulia | sorry, haven't started reviewing, got interrupted and now dealing with the 2nd interrupt | 16:20 |
TheJulia | so reading, I also thought about app credentials on my frist reading | 16:29 |
TheJulia | But, it *feels* like we can and *should* drop keystone credentials and details | 16:29 |
TheJulia | then again, logging might be a little weird then | 16:30 |
TheJulia | because we wont' have a real context object | 16:30 |
TheJulia | well, it would be full of none's | 16:30 |
dtantsur | sam_z: I've left some comments. -1 is mostly because of some confusion around power states in one section and because of basic auth (we need it for standalone) | 16:30 |
TheJulia | dtantsur: concur w/r/t basic auth | 16:30 |
TheJulia | or at least, non-session based auth | 16:30 |
dtantsur | TheJulia: re keystone: when asking keystone for a token, we'll probably receive enough data to build a context. | 16:31 |
TheJulia | yes you do | 16:31 |
TheJulia | and if you re-validate a token you get the context populated via middleware | 16:31 |
TheJulia | *but* we also don't *need* context really under the hood | 16:31 |
TheJulia | we don't do any policy validation below the API layer | 16:32 |
sam_z | so basic auth is a necessity? | 16:32 |
dtantsur | sam_z: unfortunately yes. we have a very strong case for not using keystone in some deployments. | 16:32 |
TheJulia | yeah, one-off operations/interactions with tools tend to be basic auth based | 16:32 |
dtantsur | (disclosure: I work on metal3, we use ironic without openstack) | 16:32 |
sam_z | very fair. i honestly thought all clouds used keystone lol | 16:32 |
* TheJulia remembers bmc firmware versions which actually allowed basic auth to work better... rather unexpectedly | 16:32 | |
dtantsur | sam_z: ironic is a bit special, we have use cases outside of openstack | 16:33 |
dtantsur | metal3 is kubernetes | 16:33 |
dtantsur | "fun" fact: some BMCs have a pretty hard limit on the number of open sessions | 16:33 |
sam_z | interesting, i will keep that in mind. | 16:34 |
sam_z | so should basic auth *not* involve keystone at all? | 16:34 |
dtantsur | oh, well. we have 2 options: | 16:35 |
dtantsur | 1) require sessions when keystone is enabled, use HTTP basic when it's not | 16:35 |
dtantsur | 2) support HTTP basic in both cases | 16:35 |
dtantsur | 1) is more compatible, 2) is more... correct? | 16:35 |
dtantsur | wait, the other way around | 16:35 |
dtantsur | 2) is more compatible, 1) is more correct | 16:36 |
sam_z | i think 2) could work via a config option | 16:36 |
dtantsur | possibly | 16:36 |
dtantsur | I don't have a strong opinion here | 16:36 |
sam_z | like REDFISH_PROXY_ALLOW_BASIC_AUTH_KEYSTONE or something | 16:36 |
dtantsur | I know that some hardware only allows session auth, some - only basic auth | 16:36 |
dtantsur | if we start with supporting only session auth for keystone, it will be fine IMO | 16:37 |
sam_z | ok! i think when i update the spec, i will update it with 1) in mind but leave a note mentioning that if necessary we could also allow basic auth with keystone if the need arises | 16:38 |
sam_z | now i suppose the question for basic auth without keystone is-- how should credentials be handled | 16:38 |
dtantsur | sam_z: we have a middleware for that | 16:38 |
TheJulia | and if they see everything in that case, it is likely okay | 16:39 |
dtantsur | sam_z: https://opendev.org/openstack/ironic-lib/src/branch/master/ironic_lib/auth_basic.py | 16:39 |
dtantsur | yeah, without keystone there is no rbac, everyone sees everything | 16:39 |
dtantsur | sam_z: tl;dr when basic auth is used, we have an apache-compatible file with password hashes | 16:39 |
sam_z | ah so would the user simply need to supply like, a database connection or something? | 16:40 |
sam_z | or not the user | 16:40 |
sam_z | the operator | 16:40 |
dtantsur | I think you can happily ignore these details. the hashes are simply in a file, not even the database | 16:40 |
opendevreview | Merged openstack/ironic stable/train: [Stable only] remove require_exclusive_lock from detect_vendor https://review.opendev.org/c/openstack/ironic/+/811150 | 16:40 |
dtantsur | sam_z: if you're really curious, this is the commit adding basic auth support to bifrost: https://opendev.org/openstack/bifrost/commit/bcda97b6308eda47a80b6290d06bc43dbe5032a3 | 16:41 |
dtantsur | you can see from it what it entails on the operator's side | 16:41 |
dtantsur | but you personally can expect everything to be set up | 16:41 |
TheJulia | also, we don't do policy/lookup filtering in basic auth cases, so it makes some of the considerations kind of easier to work through | 16:41 |
dtantsur | because the native ironic API will use the same auth | 16:41 |
sam_z | so from my perspective, i should: 1) figure out if keystone is enabled, 2) if not, attempt basic auth, 3) take the creds and hand them off to the middleware for authentication, 4) if middleware gives me the thumbs up, allow the request, and if not, handle the request w an error? | 16:42 |
dtantsur | sam_z: sounds about right | 16:43 |
sam_z | nice. | 16:43 |
dtantsur | #1 corresponds to the auth_strategy option | 16:43 |
TheJulia | sam_z: and likely leverage if the keystone session has a project_id, then run queries with that project_id | 16:43 |
sam_z | what should be done about the case where a user has tools that only expect to work with sessionservice for authentication but there is no keystone? | 16:44 |
dtantsur | HTTP 400 Bad Request | 16:44 |
dtantsur | let's not solve too many corner cases at once :) | 16:45 |
sam_z | very true, very true. | 16:45 |
dtantsur | these tools will also not work with a lot of real-life hardware | 16:45 |
dtantsur | sam_z: what we should do is to hide the session endpoints when sessions are not supported | 16:46 |
dtantsur | the tools may decide based on the presence of SessionService | 16:46 |
sam_z | ah that's true. | 16:48 |
sam_z | that sounds like a good solution, and i will update the spec to reflect it! | 16:48 |
dtantsur | awesome, thank you! | 16:48 |
sam_z | ok! so i think that's all the points of confusion i wanted to clear up with y'all, so thanks a bunch dtantsur and TheJulia! | 16:52 |
sam_z | i'll be lurking in this channel regardless so if there's anything else to talk about regarding this, i should be around :) | 16:53 |
dtantsur | ++ | 16:54 |
dtantsur | have a nice evening folks o/ | 17:02 |
TheJulia | goodnight dtantsur | 17:02 |
* TheJulia frees memory becasue OMGTOOMANYTABS | 17:02 | |
iurygregory | TheJulia, sorry I took some medicine for headache and got some rest in the afternoon, about the deliverables, remember that 2 weeks ago we talked about the deliverables with cycle-rc (by default is a major bump), to avoid giving the the users the false impression that we have a lot of additions that would require a major bump I've talked with the release team and it makes sense to have the rc deliverables moved | 18:21 |
iurygregory | to cycle-with-intermediary so we can have a better control (ngs, networking-baremetal, ironic-ui, ironic-prometheus-exporter) | 18:21 |
iurygregory | so when yoga is open in the release repo we can update the deliverables and get feedback from the release team (Herve is ok with this change) | 18:22 |
TheJulia | iurygregory: heh, so wow, yeah, that is like the reverse action of the past. Okay! | 18:56 |
iurygregory | TheJulia, yeah, I should have added the irc logs in the agenda XD https://meetings.opendev.org/irclogs/%23openstack-release/%23openstack-release.2021-09-27.log.html | 19:34 |
-opendevstatus- NOTICE: Gerrit and Zuul services are being restarted briefly for configuration and code updates but should return to service momentarily | 20:09 | |
opendevreview | Riccardo Pittau proposed openstack/ironic-python-agent-builder master: Update qemu version https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/776507 | 21:10 |
TheJulia | stevebaker: https://storyboard.openstack.org/#!/story/2009255 | 21:44 |
janders | good morning Ironic o/ | 23:58 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!