| *** zzzeek has quit IRC | 00:00 | |
| *** zzzeek has joined #openstack-ironic | 00:04 | |
| *** paras333 has joined #openstack-ironic | 00:04 | |
| *** zzzeek has quit IRC | 00:08 | |
| *** zzzeek has joined #openstack-ironic | 00:11 | |
| *** tosky has quit IRC | 00:39 | |
| *** Goneri has quit IRC | 01:12 | |
| *** Goneri has joined #openstack-ironic | 01:38 | |
| *** Goneri has quit IRC | 02:05 | |
| *** xinliang has joined #openstack-ironic | 02:14 | |
| *** mkrai has joined #openstack-ironic | 03:26 | |
| *** xinliang has quit IRC | 04:00 | |
| *** trandles has quit IRC | 04:24 | |
| *** paras333 has quit IRC | 04:31 | |
| *** mkrai has quit IRC | 04:40 | |
| *** mkrai_ has joined #openstack-ironic | 04:40 | |
| *** paras333 has joined #openstack-ironic | 04:46 | |
| *** paras333 has quit IRC | 04:51 | |
| *** ianychoi__ has joined #openstack-ironic | 04:57 | |
| *** ianychoi_ has quit IRC | 04:59 | |
| *** zzzeek has quit IRC | 05:02 | |
| *** zzzeek has joined #openstack-ironic | 05:04 | |
| *** zzzeek has quit IRC | 05:39 | |
| *** zzzeek has joined #openstack-ironic | 05:42 | |
| *** uzumaki has joined #openstack-ironic | 06:07 | |
| *** zzzeek has quit IRC | 06:45 | |
| *** zzzeek has joined #openstack-ironic | 06:47 | |
| *** belmoreira has joined #openstack-ironic | 07:00 | |
| *** zzzeek has quit IRC | 07:06 | |
| *** Qianbiao has joined #openstack-ironic | 07:06 | |
| *** zzzeek has joined #openstack-ironic | 07:06 | |
| *** mkrai_ has quit IRC | 07:14 | |
| *** zzzeek has quit IRC | 07:27 | |
| *** zzzeek has joined #openstack-ironic | 07:28 | |
| *** zzzeek has quit IRC | 07:37 | |
| *** zzzeek has joined #openstack-ironic | 07:40 | |
| openstackgerrit | vinay50muddu proposed openstack/ironic master: Add support to manage certificates in iLO https://review.opendev.org/c/openstack/ironic/+/760573 | 07:50 |
|---|---|---|
| *** ociuhandu has joined #openstack-ironic | 07:59 | |
| *** ociuhandu has quit IRC | 08:00 | |
| openstackgerrit | vinay50muddu proposed openstack/ironic master: Add support to manage certificates in iLO https://review.opendev.org/c/openstack/ironic/+/760573 | 08:02 |
| arne_wiebalck | Good morning, ironic! | 08:10 |
| *** zzzeek has quit IRC | 08:13 | |
| *** zzzeek has joined #openstack-ironic | 08:15 | |
| *** mkrai has joined #openstack-ironic | 08:21 | |
| janders | good morning arne_wiebalck | 08:34 |
| janders | how was your weekend? | 08:34 |
| arne_wiebalck | very nice: we had an Italian day yesterday (since we cannot go anywhere atm): tiramisu, cafe, pasta, vino, ... :) | 08:36 |
| arne_wiebalck | janders: how about you? | 08:36 |
| janders | sounds awesome! :) | 08:37 |
| janders | went on a two-day 4WD trip with my club - it was good fun :) | 08:37 |
| *** tosky has joined #openstack-ironic | 08:37 | |
| janders | food didn't match yours though, just decent country pub fare and local beers | 08:37 |
| janders | and getting acceptable coffee is always a bit of a challenge in remote areas :) | 08:39 |
| *** dougsz has joined #openstack-ironic | 08:40 | |
| *** ricolin has quit IRC | 08:47 | |
| *** fmuyassarov has joined #openstack-ironic | 08:49 | |
| openstackgerrit | vinay50muddu proposed openstack/ironic master: Add support to manage certificates in iLO https://review.opendev.org/c/openstack/ironic/+/760573 | 08:53 |
| arne_wiebalck | janders: as a coffee specialist I guess your standards are pretty high | 08:54 |
| *** mgoddard has joined #openstack-ironic | 08:54 | |
| *** lucasagomes has joined #openstack-ironic | 08:56 | |
| *** derekh has joined #openstack-ironic | 09:12 | |
| janders | :D | 09:25 |
| *** k_mouza has joined #openstack-ironic | 09:25 | |
| *** mkrai has quit IRC | 09:27 | |
| *** rpittau|afk is now known as rpittau | 09:27 | |
| rpittau | good morning ironic! o/ | 09:27 |
| *** k_mouza has quit IRC | 09:30 | |
| arne_wiebalck | hey rpittau o/ | 09:31 |
| rpittau | hey arne_wiebalck :) | 09:31 |
| *** mkrai has joined #openstack-ironic | 09:31 | |
| janders | good morning rpittau | 09:31 |
| rpittau | hey janders :) | 09:31 |
| *** mkrai has quit IRC | 09:32 | |
| janders | speaking of coffee... how is your new machine going rpittau? :) | 09:32 |
| *** mkrai has joined #openstack-ironic | 09:32 | |
| *** dougsz has quit IRC | 09:34 | |
| *** k_mouza has joined #openstack-ironic | 09:34 | |
| rpittau | janders: it's working very well :) | 09:35 |
| rpittau | we tried a couple of different types of coffees and with the grinder we found already a couple of good combinations | 09:35 |
| rpittau | in the end the brita filter just works :) | 09:36 |
| *** zzzeek has quit IRC | 09:37 | |
| janders | excellent! :) | 09:38 |
| janders | we mostly run on doubleshot flat whites and espressos | 09:39 |
| janders | I like ristrettos every now and then and I use ristrettos for milk based coffee | 09:39 |
| janders | what's your favourites? | 09:39 |
| *** zzzeek has joined #openstack-ironic | 09:40 | |
| *** dougsz has joined #openstack-ironic | 09:47 | |
| rpittau | I usually go for ristretto or normal, sometimes double, depends on the moment of the day :) | 09:49 |
| janders | but no milk? | 09:51 |
| janders | have you had any hassles getting everything (machine and grinder) to switch smoothly between single and doubleshots? | 09:52 |
| rpittau | no milk, no sugar, just plain coffee | 09:54 |
| janders | nice! :) | 09:55 |
| rpittau | to have a longer coffee I just use the single shot with the double-espresso button :D | 09:56 |
| rpittau | no issue in switching between single and double though, just getting a little adjusted on water quantity | 09:56 |
| janders | my single and double filters seem to prefer significantly different grinds | 10:02 |
| janders | my mods made the grinder work 10/10 for the double filter, but singles come out close to overextracted even on the most coarse setting | 10:05 |
| janders | cant have it both ways apparently :) | 10:05 |
| *** ociuhandu has joined #openstack-ironic | 10:05 | |
| *** ociuhandu has quit IRC | 10:20 | |
| *** ociuhandu has joined #openstack-ironic | 10:32 | |
| *** ociuhandu has quit IRC | 10:38 | |
| *** mgoddard has quit IRC | 10:47 | |
| *** ociuhandu has joined #openstack-ironic | 10:51 | |
| *** ociuhandu has quit IRC | 11:05 | |
| *** k_mouza has quit IRC | 11:10 | |
| *** k_mouza has joined #openstack-ironic | 11:22 | |
| *** dtantsur|afk is now known as dtantsur | 11:31 | |
| *** ociuhandu has joined #openstack-ironic | 11:33 | |
| dtantsur | morning/afternoon ironic | 11:34 |
| openstackgerrit | Merged openstack/bifrost master: Allow inserting SSH public key for dynamic-login https://review.opendev.org/c/openstack/bifrost/+/763806 | 11:40 |
| *** mgoddard has joined #openstack-ironic | 11:55 | |
| *** mgoddard has quit IRC | 12:07 | |
| *** mkrai has quit IRC | 12:15 | |
| *** mkrai_ has joined #openstack-ironic | 12:15 | |
| *** tosky has quit IRC | 12:24 | |
| *** tosky has joined #openstack-ironic | 12:25 | |
| *** mkrai_ has quit IRC | 12:35 | |
| *** sshnaidm|off is now known as sshnaidm | 12:38 | |
| *** zzzeek has quit IRC | 12:44 | |
| *** zzzeek has joined #openstack-ironic | 12:44 | |
| *** zzzeek has quit IRC | 12:49 | |
| *** zzzeek has joined #openstack-ironic | 12:50 | |
| *** ociuhandu has quit IRC | 12:57 | |
| *** zzzeek has quit IRC | 12:59 | |
| *** zzzeek has joined #openstack-ironic | 13:02 | |
| *** zzzeek has quit IRC | 13:06 | |
| *** zzzeek has joined #openstack-ironic | 13:08 | |
| *** zzzeek has quit IRC | 13:12 | |
| *** zzzeek has joined #openstack-ironic | 13:14 | |
| *** ociuhandu has joined #openstack-ironic | 13:15 | |
| *** ociuhandu has quit IRC | 13:25 | |
| *** paras333 has joined #openstack-ironic | 13:38 | |
| *** ociuhandu has joined #openstack-ironic | 13:38 | |
| *** lbragstad has quit IRC | 13:39 | |
| *** paras333 has quit IRC | 13:44 | |
| *** paras333 has joined #openstack-ironic | 13:44 | |
| *** lbragstad has joined #openstack-ironic | 13:47 | |
| *** zzzeek has quit IRC | 13:56 | |
| *** zzzeek has joined #openstack-ironic | 13:58 | |
| TheJulia | good morning | 14:01 |
| TheJulia | it seems a little quiet today | 14:03 |
| dtantsur | morning TheJulia | 14:03 |
| dtantsur | yeah | 14:03 |
| *** uzumaki has quit IRC | 14:04 | |
| TheJulia | I'm updating the meeting agenda, do we need to revisit the RFE's from last week? | 14:04 |
| TheJulia | I don't remember | 14:04 |
| dtantsur | I don't really think so | 14:04 |
| * TheJulia removes them for today | 14:06 | |
| TheJulia | How was last week? | 14:06 |
| * dtantsur barely remembers | 14:07 | |
| rpittau | very calm | 14:07 |
| TheJulia | I hope how quiet it is now is not indicitive of the rest of th emonth | 14:12 |
| *** ayoung has joined #openstack-ironic | 14:33 | |
| *** fmuyassarov has quit IRC | 14:34 | |
| arne_wiebalck | "Took 6.74 seconds to build instance." | 14:39 |
| * arne_wiebalck has adopted the first production nodes into Ironic *and* Nova | 14:39 | |
| dtantsur | mmm, adoption into nova? how? | 14:39 |
| arne_wiebalck | with the fake drivers | 14:40 |
| arne_wiebalck | roughly: enroll, set fake, provide, some placement fiddling, instance creation, set real drivers | 14:41 |
| arne_wiebalck | for nova, it feels real :) | 14:42 |
| *** tzumainn has joined #openstack-ironic | 14:42 | |
| TheJulia | Interesting... | 14:45 |
| *** trandles has joined #openstack-ironic | 14:45 | |
| *** rloo has joined #openstack-ironic | 14:48 | |
| arne_wiebalck | now, these nodes can be handled via openstack commands, although they were installed before Ironic was introduced | 14:48 |
| arne_wiebalck | *"openstack server" commands | 14:49 |
| *** kaifeng has joined #openstack-ironic | 14:52 | |
| *** johnsag has joined #openstack-ironic | 14:55 | |
| *** ociuhandu has quit IRC | 14:56 | |
| *** ociuhandu has joined #openstack-ironic | 14:57 | |
| TheJulia | Is it just me or do the new gerrit URLs make anyone else think of launchpad? | 15:00 |
| TheJulia | #startmeeting ironic | 15:00 |
| openstack | Meeting started Mon Nov 30 15:00:10 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 |
| TheJulia | o/ | 15:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:00 |
| *** openstack changes topic to " (Meeting topic: ironic)" | 15:00 | |
| openstack | The meeting name has been set to 'ironic' | 15:00 |
| rpioso | \o | 15:00 |
| dtantsur | o/ | 15:00 |
| kaifeng | o/ | 15:00 |
| TheJulia | Welcome to our weekly meeting of Irony for Ironic. I'll be your host! | 15:00 |
| rloo | o/ | 15:00 |
| ajya | o/ | 15:00 |
| bfournie | o/ | 15:00 |
| TheJulia | Our agenda an be found on the wiki. | 15:01 |
| TheJulia | #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting | 15:01 |
| TheJulia | Our agenda also looks very bare, so maybe this will be a super quick meeting | 15:01 |
| TheJulia | #topic Announcements / Reminders | 15:01 |
| *** openstack changes topic to "Announcements / Reminders (Meeting topic: ironic)" | 15:01 | |
| *** tosin has joined #openstack-ironic | 15:01 | |
| TheJulia | I only have one item to announce/remind us of this week which is for contributors to be mindful of reviews. With holidays coming up and a number of people taking time off, it is going to become increasingly difficult to move things forward so earlier feedback will always help. | 15:02 |
| *** ociuhandu has quit IRC | 15:02 | |
| TheJulia | Does anyone else have anything to remind us of or announce this week? | 15:02 |
| *** stendulker has joined #openstack-ironic | 15:03 | |
| stendulker | o/ | 15:04 |
| * TheJulia gets out the crickets and lets them make announcements indicating we should likely move on | 15:04 | |
| TheJulia | \o stendulker | 15:04 |
| rpittau | o/ | 15:04 |
| TheJulia | We had no action items from our last meeting, so we can proceed to reviewing subteam status reports | 15:05 |
| TheJulia | #topic Review subteam status reports | 15:05 |
| *** openstack changes topic to "Review subteam status reports (Meeting topic: ironic)" | 15:05 | |
| TheJulia | #link https://etherpad.openstack.org/p/IronicWhiteBoard | 15:05 |
| TheJulia | Starting at line 257 | 15:05 |
| * TheJulia also makes coffee in hopes that it wakes people up | 15:05 | |
| TheJulia | hmm, I must not have uploaded the community goal update to the specs repo :\ | 15:07 |
| TheJulia | doh! | 15:07 |
| TheJulia | bdodd: ajya: Regarding redfish raid, what is the next step for that patch? | 15:09 |
| arne_wiebalck | o/ | 15:09 |
| ajya | TheJulia: I have left some comments around async operations and Tasks - need to decide if taking that approach | 15:10 |
| *** ociuhandu has joined #openstack-ironic | 15:10 | |
| TheJulia | ajya: okay, would it help for others to review that patch this week? | 15:10 |
| ajya | TheJulia: yeah, can do that for additional input | 15:11 |
| TheJulia | ajya: please add that patch to the list of changes to review this week | 15:11 |
| *** uzumaki has joined #openstack-ironic | 15:11 | |
| ajya | TheJulia: ok | 15:11 |
| ajya | TheJulia: there is related sushy patch also to be reviewed, will add that too | 15:12 |
| TheJulia | ok | 15:12 |
| TheJulia | Well, I guess Iury can't comment on oslo.privsep stuff :( | 15:13 |
| TheJulia | ajya: Is there any updates with regards to configuration molds? Even no-update works on the etherpad :) | 15:14 |
| TheJulia | zer0c00l: Looks like your anaconda spec is getting closer. :) | 15:15 |
| ajya | TheJulia: will add update in the pad, checking Swift&tokens, might have questions later | 15:15 |
| TheJulia | ajya: okay | 15:15 |
| TheJulia | Looks like the interop profile is still under review | 15:15 |
| arne_wiebalck | Would be great to have someone else try them. | 15:15 |
| *** ociuhandu has quit IRC | 15:16 | |
| arne_wiebalck | The profiles look ok, but we may need a discussion on how to use them. | 15:16 |
| arne_wiebalck | Maybe during the SIG meeting next week. | 15:16 |
| TheJulia | Is everyone good to proceed to priorities for the week? | 15:16 |
| TheJulia | arne_wiebalck: ++ | 15:16 |
| arne_wiebalck | When rpioso is presenting them. | 15:16 |
| *** Goneri has joined #openstack-ironic | 15:17 | |
| TheJulia | I guess we're good to proceed onward | 15:18 |
| TheJulia | #topic Deciding on priorities for the coming week | 15:19 |
| *** openstack changes topic to "Deciding on priorities for the coming week (Meeting topic: ironic)" | 15:19 | |
| TheJulia | #link https://etherpad.opendev.org/p/IronicWhiteBoard | 15:19 |
| TheJulia | Starting at line 120 | 15:19 |
| * TheJulia removes merged/not applicable items | 15:20 | |
| TheJulia | Looks like all of the proposed for addition items seem logical to add to me | 15:21 |
| TheJulia | Anything else to add this week? | 15:22 |
| *** ayoung has quit IRC | 15:23 | |
| rpittau | mmm nothing super pressing, but if there's time I'd like to add the tenacity conversion patch https://review.opendev.org/c/openstack/ironic/+/376574 | 15:24 |
| *** ayoung has joined #openstack-ironic | 15:25 | |
| TheJulia | Seems reasonable | 15:25 |
| rpittau | thanks! | 15:25 |
| TheJulia | Added | 15:25 |
| kaifeng | i'd like to add this https://review.opendev.org/c/openstack/ironic/+/764563 but I think we need to discuss in the rfe review | 15:25 |
| TheJulia | Is there anything else? or does htis list look good? | 15:25 |
| TheJulia | kaifeng: yes, lets discuss that in rfe review | 15:26 |
| TheJulia | Well, since we have no discussion items | 15:26 |
| TheJulia | arne_wiebalck: Anything beyond the redfish profiles for the next SIG meeting | 15:26 |
| TheJulia | ? | 15:26 |
| TheJulia | w/r/t the baremetal sig? | 15:26 |
| arne_wiebalck | TheJulia: no | 15:27 |
| TheJulia | #topic Baremetal SIG | 15:27 |
| *** openstack changes topic to "Baremetal SIG (Meeting topic: ironic)" | 15:27 | |
| arne_wiebalck | Meeting #3 Tue Dec 8, 2020 at 2pm UTC | 15:27 |
| *** ociuhandu has joined #openstack-ironic | 15:27 | |
| arne_wiebalck | https://etherpad.opendev.org/p/bare-metal-sig | 15:27 |
| TheJulia | #info Next scheduled session is Tue Dec 8, 2020 at 2pm | 15:27 |
| TheJulia | #link https://etherpad.opendev.org/p/bare-metal-sig | 15:27 |
| TheJulia | #topic RFE Review | 15:27 |
| *** openstack changes topic to "RFE Review (Meeting topic: ironic)" | 15:27 | |
| TheJulia | kaifeng: since you wanted to discuss that item, you as they say, have the floor :) | 15:28 |
| *** uzumaki has quit IRC | 15:28 | |
| kaifeng | thanks | 15:28 |
| kaifeng | it was an old proposal https://storyboard.openstack.org/#!/story/2003091 | 15:28 |
| kaifeng | that to have a name field for ports | 15:29 |
| TheJulia | wow, yeah, 2019 | 15:29 |
| TheJulia | err, 2018 | 15:29 |
| kaifeng | yeah, i was thinking differently at that time | 15:29 |
| TheJulia | so just an idea of a human relatable name storage? | 15:30 |
| kaifeng | things turned out that a name field helps us managing ports like other resources, nodes, portgroups | 15:30 |
| TheJulia | It does | 15:31 |
| TheJulia | or, would | 15:31 |
| TheJulia | and it keeps the same style of unique constraint | 15:31 |
| kaifeng | the new proposal is to have a unique name fields, so that some operations can be automated | 15:31 |
| TheJulia | Seems reasonable to me, anyone else? | 15:31 |
| dtantsur | do we need names for everything then? | 15:32 |
| dtantsur | at least all physical entities? | 15:32 |
| kaifeng | probaly not, but ports are quite important one :) | 15:32 |
| dtantsur | oh, we have port group names? then we should probably have port names | 15:33 |
| dtantsur | I remember having some objection, but I don't remember its essence now, soo.. | 15:33 |
| kaifeng | portgroup comes later and have a name field | 15:33 |
| * kaifeng there was a patch to address this proposal but it's quite long ago | 15:34 | |
| TheJulia | I think the objections/concerns were that someone would always try to store the inspection ramdisk identified interface name | 15:34 |
| TheJulia | and as we've all learned over time, that not be consistent across OSes or upgrades | 15:35 |
| *** ociuhandu has quit IRC | 15:35 | |
| kaifeng | yes, that's different | 15:35 |
| TheJulia | I sense this is RFE-approved if there are no objections. | 15:35 |
| TheJulia | I don't think it needs a spec at this point, it is a fairly simple change | 15:36 |
| rloo | i'd suggest that the story itself have the highlevel info | 15:38 |
| rloo | eg, API changes. will need data migration thing. | 15:38 |
| TheJulia | kaifeng: yeah, it would kind of help for a slight revamp for historical context | 15:38 |
| kaifeng | ok, will update the story in a moment | 15:39 |
| TheJulia | Anyway, with that I think we're good to move to Open Discussion | 15:39 |
| TheJulia | #topic Open Discussion | 15:39 |
| *** openstack changes topic to "Open Discussion (Meeting topic: ironic)" | 15:39 | |
| TheJulia | Everyone have a good weekend? | 15:39 |
| dtantsur | a cold one :) | 15:40 |
| rpittau | cold indeed... | 15:40 |
| TheJulia | good cold? or just very cold weather moved in? | 15:40 |
| rloo | TheJulia: i can't remember where we discussed this, maybe at the ptg. wrt backports and 'skipping' some older releases. were we going to discuss with the community? (Not sure this is open discussion, i was just reminded of it.) | 15:40 |
| *** mkrai has joined #openstack-ironic | 15:41 | |
| TheJulia | rloo: I thought we had settled given one of the additional jump points stein went EM ?last? week. | 15:41 |
| rloo | i honestly don't recall the details of that discussion but saw that stein went em and was going to update the whiteboard with that info :) | 15:42 |
| rloo | it was something like backport but to eg only queens but not rocky | 15:43 |
| Qianbiao | I have a question: is port group created manually by admin? or has an automatic method to generate it? | 15:43 |
| TheJulia | Qianbiao: manual, you have to know the configuration available to you and what may be represented in the switch config already | 15:43 |
| Qianbiao | yeah, i guess so. | 15:44 |
| Qianbiao | I am courious that: port name is not volatile | 15:44 |
| TheJulia | rloo: yeah, unless there is a real reason to, we were going to skip and focus on the branches taht are cared about | 15:44 |
| *** uzumaki has joined #openstack-ironic | 15:44 | |
| *** johnsag has quit IRC | 15:44 | |
| Qianbiao | so, if we use a fixed port name, we need to use stable interface name | 15:45 |
| stendulker | During inspection we do create ports for the MACs discovered https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/redfish/inspect.py#L162-L182 | 15:45 |
| TheJulia | Qianbiao: OS precieved port name can be depending on settings and mismatches that can occur between ramdisk, persistant port naming schemes, etc | 15:45 |
| rloo | TheJulia: ah, right. there was something about testing/ci too i think. guess i can look back at the notes. what i recall? is that it seemed like a good idea to get community thoughts about it. to be somewhat consistent or whatever? or maybe needed to discuss with the release team? | 15:45 |
| TheJulia | Names are really for humans, not the software | 15:45 |
| Qianbiao | yes, TheJulia kaifang, this is what I was worry about | 15:45 |
| TheJulia | rloo: there are already other projects skipping em branches unless people really want a thing on them | 15:46 |
| TheJulia | Anything else for us to discuss today? | 15:46 |
| rloo | TheJulia: right. I haven't seen anything though, where this 'awareness' is mentioned in the community as a whole, vs individual projects. | 15:46 |
| TheJulia | rloo: yeah, I don't think there was anything actionable from that. I really don't remember though | 15:48 |
| rloo | TheJulia: for ironic, perhaps you might update our whiteboard (around line 207) about what we decided if it is still appropriate. | 15:48 |
| rloo | ah, https://etherpad.opendev.org/p/ironic-wallaby-ptg. around L326 | 15:49 |
| *** johnsag has joined #openstack-ironic | 15:51 | |
| TheJulia | ahh, yeah | 15:52 |
| TheJulia | Okay, I'll try to do that this week | 15:52 |
| TheJulia | #action Julia to sync with stable team w/r/t backport strategy | 15:52 |
| rloo | thx TheJulia! | 15:52 |
| TheJulia | Well everyone, have a wonderful day! And a wonderful week! | 15:52 |
| rloo | and then we ought to doc so I don't forget :D | 15:52 |
| rloo | same to you too TheJulia! | 15:53 |
| TheJulia | o/ | 15:53 |
| TheJulia | Thanks everyone! | 15:53 |
| TheJulia | #endmeeting | 15:53 |
| *** openstack changes topic to "Bare Metal Provisioning | Status: http://bit.ly/ironic-whiteboard | Docs: http://docs.openstack.org/ironic/ | Bugs: https://storyboard.openstack.org/#!/project_group/75 | Contributors are generally present between 6 AM and 12 AM UTC, If we do not answer, please feel free to pose questions to openstack-discuss mailing list." | 15:53 | |
| openstack | Meeting ended Mon Nov 30 15:53:41 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:53 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/ironic/2020/ironic.2020-11-30-15.00.html | 15:53 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/ironic/2020/ironic.2020-11-30-15.00.txt | 15:53 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/ironic/2020/ironic.2020-11-30-15.00.log.html | 15:53 |
| rpittau | thank you! | 15:53 |
| *** ociuhandu has joined #openstack-ironic | 15:57 | |
| *** tosin has quit IRC | 15:59 | |
| *** ebagakis has joined #openstack-ironic | 16:00 | |
| *** Qianbiao has quit IRC | 16:00 | |
| kaifeng | the story is updated :) | 16:00 |
| *** ociuhandu has quit IRC | 16:01 | |
| *** ociuhandu has joined #openstack-ironic | 16:01 | |
| kaifeng | btw, is anyone still using vif id from the extra? I am surprised it's till there | 16:01 |
| *** stendulker has quit IRC | 16:02 | |
| rloo | thx kaifeng. Could you do me a favour and add to that story, the pieces that need to be done? ironic, python-ironicclient, openstacksdk? want to make sure we don't forget. | 16:06 |
| kaifeng | tbh I haven't investiaged openstacksdk if it needs to be updated, should be trivial if there is any. | 16:08 |
| kaifeng | however I can put a checklist there :) | 16:09 |
| *** zzzeek has quit IRC | 16:11 | |
| dtantsur | it's probably a two-liner in openstacksdk | 16:11 |
| *** zzzeek has joined #openstack-ironic | 16:14 | |
| rloo | yup :) thx kaifeng | 16:19 |
| kaifeng | yw rloo | 16:19 |
| kaifeng | dtantsur: i left a comment on the https://review.opendev.org/c/openstack/bifrost/+/763806 wrt the kernel parameters | 16:20 |
| ajya | TheJulia, dtantsur, re storage of the molds in Swift. Taking a look at options, is idea that Ironic conductor service user has access to all end-users' projects or that Ironic conductor, while running clean/deploy, authenticates on behalf of end-user who initiated clean/deploy (that way can only access that user's project)? | 16:20 |
| -openstackstatus- NOTICE: The Gerrit service on review.opendev.org is being restarted quickly to troubleshoot high load and poor query caching performance, downtime should be less than 5 minutes | 16:21 | |
| TheJulia | ajya: That seems correct | 16:23 |
| ajya | TheJulia: first or second option? | 16:23 |
| TheJulia | Well, technically both statements are correct as they focus on different parts of the mechanism. The first action should convey the requestor's authentication, subsequent actions should be performed by ironic itself. | 16:25 |
| TheJulia | because the task has been released and the context of the original request is gone. | 16:25 |
| ajya | yes, the context at that time is gone, that's why I'm asking - if Ironic has access to all projects, does it defeat the purpose that knowing other user's project id, user2 can access user1 project via Ironic? Or that's where saving project_id the node comes in - Ironic does not allow going to different project id? | 16:29 |
| ajya | *saving project_id to the node | 16:29 |
| TheJulia | well, that is ultimately going to depend upon the access configuration of ironic's servic account rights | 16:29 |
| TheJulia | up front the project would need to be extracted and if later action performed would need to be leveraged. I guess I'm lost in the mechanics of what youre trying to achieve as a multi-step process. In other words, what step in what process is this at? | 16:31 |
| TheJulia | Applying should be fairly straight forward, download from swift, load into temporary storage somehow, and use from that. Uploading to swift, the user should ideally have granted rights for ironic to post to that location if the original task needs to be released | 16:32 |
| *** mkrai has quit IRC | 16:33 | |
| ajya | I'm asking that because if user has granted right for ironic to post to that location, then any other user can trick Ironic to post to that location as long as it knows that location | 16:35 |
| TheJulia | the target location thus must remain secret at the api surface | 16:36 |
| TheJulia | and transitory | 16:37 |
| kaifeng | bye o/ | 16:37 |
| TheJulia | goodnight kaifeng | 16:37 |
| ajya | TheJulia: are project_id-s considered to be secrets? As for swift location includes project id. | 16:39 |
| *** ebagakis has quit IRC | 16:53 | |
| TheJulia | ajya: in this case, with what your proposing, if it has to persist then it should be in driver_internal_info and masked from view | 16:57 |
| TheJulia | that is, if I'm understanding the concerns combined with the workflow as your percieving them | 16:58 |
| *** lucasagomes has quit IRC | 17:04 | |
| NobodyCam | Good Morning Folks | 17:12 |
| NobodyCam | Happy Monday | 17:12 |
| rpittau | hey NobodyCam :) | 17:13 |
| ajya | TheJulia: to make sure we are talking about the same, having user1 that has project1/container1/ and user2 that has project2/container2 and if using full URLs to specify location. What mechanism will prevent user1 to give project2/container2 as location if in the end Ironic will upload stuff to it having all the access it needs? That is, if using user's credentials user1 wouldn't be able | 17:14 |
| ajya | to access project2, but Ironic can access everything. | 17:14 |
| TheJulia | ajya: realistically permissions which they should be able to influence as users for their projects or containers. This all depends on workflow and if such credentials are even accessible though. Perhaps a question would be, does the agent *need* to start to facilitate the extraction of configuration, if not, then the original user's credentials could be used. Otherwise, the only option is preconfigured target | 17:18 |
| TheJulia | to save these items that is set in ironic.conf | 17:18 |
| openstackgerrit | Tzu-Mainn Chen proposed openstack/ironic-specs master: Allow Ironic to act as a power control intermediary https://review.opendev.org/c/openstack/ironic-specs/+/764801 | 17:18 |
| TheJulia | the latter is how deploy ops using swift | 17:18 |
| *** dsneddon has joined #openstack-ironic | 17:28 | |
| *** mgoddard has joined #openstack-ironic | 17:30 | |
| *** ociuhandu has quit IRC | 17:31 | |
| *** ociuhandu has joined #openstack-ironic | 17:32 | |
| *** dsneddon has quit IRC | 17:33 | |
| *** mgoddard has quit IRC | 17:35 | |
| *** ociuhandu has quit IRC | 17:37 | |
| TheJulia | tzumainn: do you remember, was it intentional or intentional to prevent to disallow or allow an owner to update the owner field if they are the owner of the node? | 17:38 |
| tzumainn | TheJulia, I don't think it was intentional! | 17:39 |
| dking | Is there a way that I can easily remove a field from the introspection data once a server is running? | 17:39 |
| TheJulia | I'm thinking it may have been "hi, I give you this server now" | 17:39 |
| TheJulia | dking: introspection data where? | 17:39 |
| TheJulia | dking: like what is posted to swift? | 17:39 |
| TheJulia | tzumainn: trying to look at this through the lens of the secure rbac effort which you may have heard of | 17:40 |
| TheJulia | I'm typing up a spec | 17:40 |
| tzumainn | TheJulia, I've heard of it in passing! is there anything I can help with? | 17:40 |
| rpittau | good night! o/ | 17:42 |
| *** rpittau is now known as rpittau|afk | 17:42 | |
| dking | TheJulia: Like what is output with something like: "openstack baremetal introspection data save <UUID>" | 17:42 |
| dtantsur | dking: you cannot change introspection data without some hackery. why? | 17:42 |
| TheJulia | tzumainn: code review would be much appreciated, I have a WIP of a spec up and I'm trying to generally articulate the API impact and resulting permission matrix. tl;dr WHEEEEEE | 17:43 |
| tzumainn | TheJulia, haha, definitely! just let me know when the spec is submitted | 17:43 |
| dking | dtantsur: Because I was hoping to be able to send a password in it. I'm trying to figure out a way to get set random BMC creds upon introspection and then allow Ironic to use those going forward. | 17:44 |
| openstackgerrit | Tzu-Mainn Chen proposed openstack/ironic-specs master: Allow Ironic to act as a power control intermediary https://review.opendev.org/c/openstack/ironic-specs/+/764801 | 17:45 |
| dtantsur | Assuming you *have* thought twice about the associated risks, you can probably write an ironic-inspector plugin (introspection hook) that intersects the credentials, sets them in ironic and discards them from the data | 17:46 |
| TheJulia | dking: I was thinking exactly that^^ | 17:46 |
| dking | Since the node doesn't exist prior to introspection, this is challenging. I suppose that we could set data returned to be a key to access a temporarily stored password, and then the key would be useless once expired. However, I was hoping to avoid the extra software if I coul. | 17:46 |
| TheJulia | at least, when you originally raised it | 17:46 |
| dking | dtantsur: You mentioned and introspection hook. The only thing I was aware of to this point was inspector collectors. I'm looking up introspection hooks now. | 17:47 |
| dtantsur | dking: collectors are agent-side, hooks are server-side | 17:48 |
| dtantsur | dking: take this as an example: https://opendev.org/openstack/ironic-inspector/src/branch/master/ironic_inspector/plugins/extra_hardware.py | 17:48 |
| dtantsur | or better something that does update the node: https://opendev.org/openstack/ironic-inspector/src/branch/master/ironic_inspector/plugins/raid_device.py | 17:49 |
| *** ociuhandu has joined #openstack-ironic | 17:50 | |
| TheJulia | tzumainn: does it make sense for a node owner to be able to change the driver_info field values? | 17:51 |
| tzumainn | TheJulia, probably not; that seems like something only an admin should be able to do | 17:53 |
| TheJulia | tzumainn: what about a project scoped admin ? | 17:53 |
| dking | dtantsur: Nice. So, it has access to both the introspection data as well as the node information. So, that's good. But it seems to me that it still ends up being about the same as an introspection rule in that it still has to have the data sent back in the data[] object from a collector? I suppose that it has no way to send information back to the node while it is still running? | 17:53 |
| tzumainn | TheJulia, I can't quite see the use case for that, but it's possible I'm missing something | 17:54 |
| dtantsur | TheJulia: I would expect the answer to be highly deployment-specific | 17:54 |
| TheJulia | dtantsur: I'm having that same feeling... | 17:54 |
| tzumainn | TheJulia, generically speaking, we ran into the issues of needing some fine-grained policy-based control over which fields a non-admin could modify and which they couldn't | 17:54 |
| dtantsur | dking: well, you can ssh into it :) | 17:54 |
| tzumainn | we kinda papered over the issue temporarily by adding two new policy rules that enabled provisioning with metalsmith, but I'm wondering if there's a way to get to a more generic solution | 17:55 |
| dtantsur | but yes, the pattern is the same.. and I've just realized we allow access to unprocessed data, i.e. before hooks are running | 17:55 |
| dtantsur | tzumainn: aka https://storyboard.openstack.org/#!/story/2006910 ? | 17:55 |
| dking | dtantsur: from the inspection hook? At this point, I'd even consider sshing in. | 17:55 |
| dtantsur | dking: I also considered it at some point. you need an SSH key in the ramdisk, and you know IP addresses from introspection data. | 17:56 |
| tzumainn | dtantsur, that works specifically for deployments, but what if people are using external provisioning tools? | 17:56 |
| dking | dtantsur: Oh, maybe I just got what you mean. I could perhaps run that hook and use the password and then remove it from the inspection_data object so that it would never have to end up in the database? | 17:57 |
| dtantsur | tzumainn: I haven't thought about such an exotic case | 17:57 |
| TheJulia | tzumainn: secure rbac may be the solution, or the deployment api. I'm trying to think through the matrix and fields and write out words now so an update should be posted in the next hour or two | 17:57 |
| tzumainn | dtantsur, oh, the MOC put that case front-and-center in front of me :) | 17:57 |
| dtantsur | dking: I did mean that, but then I realized that we also store introspection data *before* running any processing | 17:57 |
| dtantsur | dking: what we could do is sanitize introspection data before storing it | 17:58 |
| dtantsur | I see no point in storing anything that looks like *password | 17:58 |
| dking | dtantsur: Well, somebody could have a field like "want_to_reset_password", but maybe if that were stated clearly. | 17:59 |
| dtantsur | well, ironic already sanitizes things like that from its JSON fields (driver_info, properties) | 18:00 |
| dking | dtantsur: Or even if there were something to check for fields that have some pre-chosen suffix, like *_sanitize | 18:00 |
| dtantsur | works for me | 18:01 |
| dtantsur | or starting with secret_ | 18:01 |
| dking | Ah. I wondered how it did that. I thought it just hard coded that one specific field. | 18:01 |
| dking | Yep. So, whatever it is, I'm fine with that. | 18:01 |
| TheJulia | dking: fwiw, the santizie will find fields with "password" or "secret" in the name and replace the value with '******' | 18:01 |
| dking | Would that data then be available for introspection rules also, or would it only be available for introspection hooks as it would be cleared before the rules are processed? | 18:02 |
| TheJulia | that is on gets of course | 18:02 |
| dtantsur | we can do it only on returning the data via API | 18:02 |
| dtantsur | (to be clear: it's not implemented yet) | 18:02 |
| dking | As long as whatever we use has about the same level of security as .driver_info.ipmi_password, I suppose it would be fine as that's the ultimate destination. | 18:03 |
| *** ayoung has quit IRC | 18:03 | |
| *** ayoung has joined #openstack-ironic | 18:05 | |
| dking | So, if implemented, the data would be available to both introspection hooks as well as introspection rules. It will also be stored in the database, so anybody with database access would have access to the data. Also, if debug is on, it would be recorded in logs. However, other than that, and any GET request of the data, through the API, would replace the data with '******' for the return value, and in this way, it would behave | 18:06 |
| dking | somewhat like .driver_info.ipmi_password? | 18:06 |
| dtantsur | yep | 18:07 |
| *** k_mouza has quit IRC | 18:07 | |
| dking | That sounds great for me. | 18:07 |
| NobodyCam | good Morning rpittau|afk | 18:08 |
| dking | However, it raises another question in my mind, for another part of the process. For Hardware Manager clean steps, does the node object contain the actual .driver_info.ipmi_password or is that obfuscated there, too? | 18:08 |
| dtantsur | I *think* it's obfuscated | 18:09 |
| dtantsur | cannot remember clearly - brain dead after writing some Go code :) | 18:09 |
| *** derekh has quit IRC | 18:09 | |
| dking | Go can do that to you. :) | 18:09 |
| dking | Well, bummer. I hadn't thought about that. So, I'm going to need to find a way to be able to set the BMC creds during a clean step, because during clean, I need to reflash the BMC, and it looses any creds there. | 18:11 |
| dtantsur | maybe we should lift this restriction now that we have a better TLS story (if it exists at all) | 18:12 |
| dtantsur | anyway, time to go, chat with you tomorrow | 18:12 |
| *** dtantsur is now known as dtantsur|afk | 18:13 | |
| *** dougsz has quit IRC | 18:13 | |
| *** ociuhandu has quit IRC | 18:18 | |
| *** ociuhandu has joined #openstack-ironic | 18:19 | |
| *** belmoreira has quit IRC | 18:22 | |
| *** ociuhandu has quit IRC | 18:23 | |
| *** trandles has quit IRC | 18:25 | |
| *** k_mouza has joined #openstack-ironic | 18:26 | |
| *** k_mouza has quit IRC | 18:27 | |
| *** gyee has joined #openstack-ironic | 18:28 | |
| *** ayoung has quit IRC | 18:31 | |
| *** ociuhandu has joined #openstack-ironic | 18:33 | |
| *** ociuhandu has quit IRC | 18:37 | |
| *** k_mouza has joined #openstack-ironic | 18:41 | |
| *** kaifeng has quit IRC | 18:41 | |
| *** ayoung has joined #openstack-ironic | 18:43 | |
| *** k_mouza has quit IRC | 18:45 | |
| *** trandles has joined #openstack-ironic | 18:54 | |
| TheJulia | ugh, ninjs's rst editor is down.... the main page yeilds a nginx message | 19:03 |
| TheJulia | the actual app returns a proxy error :( | 19:03 |
| *** k_mouza has joined #openstack-ironic | 19:08 | |
| *** johnsag has quit IRC | 19:11 | |
| *** ociuhandu has joined #openstack-ironic | 19:16 | |
| openstackgerrit | Julia Kreger proposed openstack/ironic-specs master: Ironic Secure RBAC https://review.opendev.org/c/openstack/ironic-specs/+/764070 | 19:18 |
| TheJulia | tzumainn: ^^^ | 19:18 |
| *** mgoddard has joined #openstack-ironic | 19:19 | |
| TheJulia | dking: interesting that it looses the bmc password... seems like "it is time" to go ahead and setup the ability for the password to be set directly. | 19:19 |
| TheJulia | via inband means | 19:20 |
| dking | TheJulia: I haven't actually tested that yet. I'm still testing my code before building a new image to test it. But if so, then yeah, I would like it if it could be passed somehow inband. | 19:23 |
| tzumainn | TheJulia, thanks! I'll take a look | 19:23 |
| TheJulia | tzumainn: I tried to represent the existing model as cleanly as memory permitted me into the world of scoped roles. Hopefully it makes sense and kind of explains what is going on | 19:24 |
| dking | I should probably try to find a better workflow for testing, but I'm not really sure of a great way to do that inside of the image. So, if anybody has a good workflow down for testing hardware managers inside of IPA and has some time, I'd love to hear how it's being done. | 19:24 |
| *** hoonetorg has quit IRC | 19:25 | |
| dking | Right now, I just test things and make some assumptions from code, then build those into my unit tests, try to build an image, and then re-think my code if I got an assumption wrong. | 19:25 |
| TheJulia | That would be interesting to hear. arne_wiebalck should give a talk on what they do! | 19:25 |
| *** hoonetorg has joined #openstack-ironic | 19:26 | |
| TheJulia | dking: that kind of represents almost all agent code development :( | 19:26 |
| dking | ...and I don't even really know how to unit test with dispatch_to_managers, either. | 19:26 |
| TheJulia | yeah, I don't think you can because it would try and dispatch to each hardware manager | 19:26 |
| arne_wiebalck | The main speed up we implemented for testing is to make our h/w manager just a stub which git clones the real code. This way we do not need to build a new image when we do a change, but only a git push :) | 19:28 |
| arne_wiebalck | This should maybe go into IPAB as a DIB element. | 19:29 |
| TheJulia | sounds like something that could help folks like dking | 19:29 |
| dking | TheJulia: I took a bit of a look at how current tests use it, but they have the advantage of only running code inside of the same class, and not a separate hardware manager. I added what seemed to be the relevant mocks, and I did get it to work somewhat. It at least could call the desired function, but got errors from there. At least I gave it a shot. | 19:29 |
| dking | arne_wiebalck: That's interesting. I'm still a bit fuzzy on how to get the IPA to re-read the hardware manager entry points to grab new code. And even then, I don't know how to start up the inspection or clean steps again while leaving the node in maintenance mode. | 19:31 |
| *** mgoddard has quit IRC | 19:33 | |
| arne_wiebalck | dking: maybe what we should do is collect some use cases (like the ones you describe) and then see what people do to address them | 19:35 |
| arne_wiebalck | dking: sounds like sth we could do in one of the SIG sessions | 19:36 |
| *** k_mouza has quit IRC | 19:37 | |
| arne_wiebalck | dking: or, if noone has a solution, discuss how to address them | 19:37 |
| dking | That would be helpful. It seems like not a lot of people build custom hardware managers, or if they do, they learn how and then you never really hear from them again. | 19:39 |
| TheJulia | lbragstad: hey,, if you have a few minutes, could you take a look-see at https://review.opendev.org/c/openstack/ironic-specs/+/764070 and see if that kind of jives with your perceptions ? | 19:40 |
| arne_wiebalck | dking: that is probably true, our h/w manager changes very little | 19:40 |
| arne_wiebalck | dking: it is mostly to define which cleaning steps we want to do | 19:40 |
| arne_wiebalck | dking: and gathers some additional h/w info | 19:41 |
| arne_wiebalck | dking: which we post-process with inspector hooks | 19:41 |
| arne_wiebalck | dking: but this, for instance, stems from times when we did not schedule with resource classes | 19:41 |
| arne_wiebalck | dking: so, some of this is not needed anymore | 19:42 |
| arne_wiebalck | I think JayF may also run custom h/w managers | 19:43 |
| dking | Yes, he has been most helpful in learning to use them. | 19:43 |
| *** tosky has quit IRC | 19:45 | |
| dking | arne_wiebalck: So, perhaps I should ask whether my use cases for the custom h/w managers is still not better handled elsewhere. Currently, we are using them to 1) clean disks (some of that is being reviewed to perhaps go upstream), 2) to reflash the BMC and BIOS firmware to keep it up to date as well as setting any custom BIOS/BMC configurations, and 3) to set or reset the BMC credentials (which is what I'm working on now, and | 19:46 |
| dking | is necessary during cleaning because the BMC update clears the IPMI creds). Would the firmware updates be better done elsewhere? | 19:46 |
| arne_wiebalck | dking: 1) is sth we do as well | 19:48 |
| arne_wiebalck | dking: 3) is sth we have implemented, but do not use | 19:48 |
| arne_wiebalck | 2) is sth we do completely OOB atm | 19:48 |
| dking | Tell me about 3). How is that implemented? | 19:49 |
| *** ociuhandu has quit IRC | 19:51 | |
| arne_wiebalck | dking: this is a disabled cleaning step, it uses ipmitool to check whether the BM users have been tempered with | 19:51 |
| arne_wiebalck | BMC | 19:52 |
| *** ociuhandu has joined #openstack-ironic | 19:52 | |
| arne_wiebalck | dking: I was wrong, we do not reset, we only check the BMC accounts (and can remove accounts which were added by the user of the node) | 19:53 |
| dking | I would love to see any information on that. It's something that I'm building at the moment for our use. It mostly works, up to the password part, which is what I'm currently trying to figure out. | 19:53 |
| arne_wiebalck | the IPMI password management is handled outside of Ironic for us | 19:54 |
| dking | Ah. Because of our use case, we'll be needing to update the firmware regularly, at least until our vendor provides a way to consistently check for tamper, which might be a while. | 19:54 |
| arne_wiebalck | dking: regularly means how often? | 19:55 |
| *** ociuhandu has quit IRC | 19:55 | |
| *** ociuhandu has joined #openstack-ironic | 19:55 | |
| dking | arne_wiebalck: Unfortunately, we do no know that yet as we're still running beta workloads. But it will be however often cleaning is run, which runs automatically when moving to available. | 19:56 |
| arne_wiebalck | dking: right, I was about to assume this | 19:57 |
| arne_wiebalck | dking: I think the cleaning framework is a good place to do this | 19:57 |
| dking | Okay. It's good to know we're on the right track for that one. | 19:57 |
| arne_wiebalck | dking: we have a cleaning step for benchmarking, for instance, which uploads the results to ES | 19:58 |
| arne_wiebalck | dking: I think so, maybe TheJulia has a better idea? | 19:58 |
| dking | arne_wiebalck: But since the BMC update wipes out the IPMI creds, we'll need some way to get or reset those. | 19:58 |
| * TheJulia appears slightly frazzled from rbac | 19:59 | |
| arne_wiebalck | dking: just thinking: there is no way to get the creds on the node from the BMC itself, is there? | 20:00 |
| dking | arne_wiebalck: As for timing, with disk cleaning, BIOS firmware reflashing, and the other steps outside of the BMC update, it takes only 15 minutes or so for our largest servers. However, the BMC update takes 2 hours, which hurts, but should be fine until we start getting close to running out of available hardware. | 20:00 |
| dking | arne_wiebalck: I'm not entirely sure. I do believe that the option to dump the current config obfuscates the password. | 20:01 |
| TheJulia | BMC update takes 2 hours?!? | 20:01 |
| arne_wiebalck | dking: in any case, you want to create new credentials, right? | 20:01 |
| dking | TheJulia: Yes, for Supermicro BMC firmware updates run from their command line untility. It's faster than that through their web utility for some reason. But we're hoping very much that our vendor can get them to provide a tamper check. | 20:02 |
| TheJulia | a conductor side rotate_ipmi_credentials or assert_ipmi_credentials. | 20:02 |
| TheJulia | dking: yeah, I was going to say the last update I did via their webui didn't take very long | 20:02 |
| arne_wiebalck | TheJulia: atm, there is no way to securely transport data from the conductor to the IPA, is there? | 20:03 |
| TheJulia | I bet they are having to indirectly signal 64 megabytes to the appropriate chip from with-in the OS.... which can be super slow | 20:03 |
| dking | TheJulia: yeah, no sure why it does that. | 20:03 |
| TheJulia | Think programming an arduino | 20:03 |
| TheJulia | arne_wiebalck: with auto-tls there is, just post it | 20:04 |
| dking | Ah. That's possible. I'm sure that it could be done better, but we're willing to eat the time cost for the moment. | 20:04 |
| dking | Where would be a good place for the conductor to send that data to the IPA? | 20:05 |
| arne_wiebalck | TheJulia: so, the conductor could generate a new pw, update the DB and send it to the IPA? | 20:05 |
| arne_wiebalck | TheJulia: prob is if sth goes wrong :-S | 20:05 |
| TheJulia | arne_wiebalck: that could be done, yes. Just needs code | 20:05 |
| dking | But I suppose that before I get too far into looking for a workaround, i should check to confirm that it's not sent in the node object in the hardware manager. | 20:05 |
| TheJulia | dking: the node object would be scrubbed | 20:06 |
| TheJulia | i.e. secrets hidden | 20:06 |
| dking | bust | 20:06 |
| lbragstad | TheJulia reading - thanks! | 20:06 |
| arne_wiebalck | dking: it is removed I think | 20:06 |
| TheJulia | The only exception to that is we explicitly extract the agent_token and send it in a separate field upon lookup | 20:06 |
| TheJulia | because... we didn't want a knob to go "show me all the secrets" outside of what the policy can be set to enable | 20:07 |
| arne_wiebalck | dking: is Ironic the source of truth for the IPMI creds? | 20:07 |
| dking | I was thinking that sending it to the IPA would be a good place to get secret things sent inband. | 20:07 |
| TheJulia | dking: it is likely the only/best way | 20:07 |
| dking | arne_wiebalck: Ideally, it will be. Because it has to have the creds, and I would prefer to have them in as few places as possible. Technically, there will be admin creds which are separate, but Ironic will not know about those. They would be physically tagged on the server. | 20:08 |
| arne_wiebalck | it'd be great to have a "rotate BMC creds" cleaning step, which assumes Ironic is in control of the user/pw | 20:09 |
| arne_wiebalck | in our case the creds are managed somewhere else | 20:09 |
| arne_wiebalck | so, Ironic is just told what the creds are | 20:10 |
| dking | arne_wiebalck: I agree. After all, as I said, Ironic already has to know the BMC creds, and as it has BMC access as well as root access (during IPA), it is almost guaranteed to have every access it needs to maintain them. | 20:10 |
| arne_wiebalck | but if we had such a step, Ironic could call out to the service | 20:10 |
| arne_wiebalck | it may be easier for Ironic to authenticate to such a service than for the IPA | 20:11 |
| *** k_mouza has joined #openstack-ironic | 20:11 | |
| dking | arne_wiebalck: Regardless, if a password rotation happens, Ironic has to know about it, and has to know the same password that the IPA would know, and it looks like info only flows one way. | 20:12 |
| arne_wiebalck | dking: yes | 20:13 |
| arne_wiebalck | dking: the creds do not need to be set by the IPA | 20:14 |
| arne_wiebalck | dking: could also be set by the conductor directly, no? | 20:14 |
| arne_wiebalck | dking: so, rather than a cleaning step, there would be a node command | 20:14 |
| dking | arne_wiebalck: I'm not sure that I understand. Are you suggesting having Ironic update the BMC creds using the BMC driver directly? | 20:17 |
| *** hjensas has quit IRC | 20:18 | |
| arne_wiebalck | dking: yes (I'm just thinking) | 20:18 |
| dking | arne_wiebalck: The reason why it would need to be available during the clean step, at least for my use case, is that when the cleaning happens, it updates the BMC firmware and purges the BMC configs, which means that it also removes the BMC user and sets everything back to default. At that point, IPA is still running and has access, but until creds are set again, Ironic would lose BMC access. | 20:19 |
| arne_wiebalck | dking: I would need to talk to the colleagues who manage the IPMI creds since I think they do this remotely when I ask them for a reset | 20:19 |
| arne_wiebalck | dking: ah, ok | 20:19 |
| arne_wiebalck | dking: true | 20:20 |
| dking | arne_wiebalck: I imagine that's what most people do. We did that before as well. Before, any reset would reset to the same admin creds, but now we get our hardware sent to us from the manufacturer with random default credentials. | 20:21 |
| *** dsneddon has joined #openstack-ironic | 20:23 | |
| *** hjensas has joined #openstack-ironic | 20:24 | |
| arne_wiebalck | dking: our env is not so hostile, so we do not do this :) | 20:30 |
| arne_wiebalck | dking: isn't there a way to verify the f/w is unchanged? | 20:31 |
| arne_wiebalck | dking: in our env, BMC f/w updates do not happen very often ... I guess we are lucky :) | 20:32 |
| dking | arne_wiebalck: Unfortunately, there isn't at the moment. However, even when it does, we would still need to update it sometimes, when updates come. And that has to be automated. | 20:33 |
| arne_wiebalck | dking: yes, that's true | 20:33 |
| dking | arne_wiebalck: Well, we're giving root access to our servers, and maybe even malware. | 20:33 |
| arne_wiebalck | dking: and you plan to have a h/w manager per platform to do this? | 20:34 |
| arne_wiebalck | dking: our users have root and BMC access | 20:34 |
| dking | arne_wiebalck: If users have root access, they could potentially upload compromised firmware. | 20:36 |
| arne_wiebalck | dking: absolutely | 20:36 |
| arne_wiebalck | dking: they could also simply add new BMC accounts | 20:37 |
| dking | arne_wiebalck: Exactly. So, when they return the servers, we need to be able to wipe everything out to be able to be sure they haven't. | 20:38 |
| arne_wiebalck | dking: how will you handle different platforms? | 20:38 |
| arne_wiebalck | dking: a h/w manager for each? | 20:38 |
| *** k_mouza has quit IRC | 20:39 | |
| arne_wiebalck | dking: a h/w manager per BMC which supports only a specific f/w version? | 20:39 |
| dking | arne_wiebalck: Yes, a h/w manager for each. But really, I was thinking about having a generic command to use ipmitool, and to maybe even abstract that to something and load through through dispatch_to_managers. So, as long as they use IPMI, it should work. | 20:39 |
| dking | arne_wiebalck: Oh, for the BMC updates? yes, we would do that. Currently the h/w manager I have has a method to try to get the right BMC/BIOS binaries by model number. | 20:40 |
| dking | It's not trivial, but the aim is to add security. | 20:40 |
| arne_wiebalck | dking: yes ... we also maintain per type recipes and binaries | 20:41 |
| *** ociuhandu has quit IRC | 20:43 | |
| arne_wiebalck | dking: it's a very interesting problem ... if you find a solution how it could be solved with Ironic, that would be really great! | 20:43 |
| arne_wiebalck | dking: we could still do the SIG thing I mentioned earlier and see if we can crowd-develop a solution (and discuss other less hard issues) | 20:44 |
| * arne_wiebalck has to go | 20:45 | |
| arne_wiebalck | bye, everyone o/ | 20:45 |
| dking | arne_wiebalck: Thank you very much! Have a good night! | 20:46 |
| *** k_mouza has joined #openstack-ironic | 20:46 | |
| *** k_mouza has quit IRC | 20:48 | |
| *** tosky has joined #openstack-ironic | 20:48 | |
| *** k_mouza has joined #openstack-ironic | 20:48 | |
| *** k_mouza has quit IRC | 20:59 | |
| *** k_mouza has joined #openstack-ironic | 21:00 | |
| *** vesper11 has quit IRC | 21:01 | |
| *** ociuhandu has joined #openstack-ironic | 21:07 | |
| *** zzzeek has quit IRC | 21:08 | |
| *** zzzeek has joined #openstack-ironic | 21:12 | |
| arne_wiebalck | dking: Thanks for driving this! Last thought for the day: do you have a story on storyboard for this problem already? If no, this may serve as a good place to collect ideas. | 21:13 |
| * arne_wiebalck really goes now :) | 21:14 | |
| *** k_mouza has quit IRC | 21:20 | |
| lbragstad | TheJulia reviewed your spec - nice write up! | 21:22 |
| TheJulia | lbragstad: thanks! | 21:24 |
| TheJulia | stevebaker: I would also appreciate a spec review, fwiw. :) | 21:27 |
| stevebaker | TheJulia: sure thing! | 21:29 |
| *** ociuhandu has quit IRC | 21:29 | |
| *** ociuhandu has joined #openstack-ironic | 21:30 | |
| TheJulia | Thanks! | 21:30 |
| *** ociuhandu has quit IRC | 21:30 | |
| *** ociuhandu has joined #openstack-ironic | 21:30 | |
| *** ociuhandu has quit IRC | 21:30 | |
| *** ociuhandu has joined #openstack-ironic | 21:32 | |
| *** ociuhandu has quit IRC | 21:36 | |
| *** ociuhandu has joined #openstack-ironic | 22:00 | |
| *** ociuhandu has quit IRC | 22:21 | |
| TheJulia | grrr, I really need to reorganize my desk with new gerrit's ui | 22:29 |
| TheJulia | :( | 22:29 |
| -openstackstatus- NOTICE: The Gerrit service on review.opendev.org is being restarted quickly to make further query caching and Git garbage collection adjustments, downtime should be less than 5 minutes | 22:36 | |
| *** k_mouza has joined #openstack-ironic | 22:48 | |
| *** ociuhandu has joined #openstack-ironic | 22:48 | |
| *** ociuhandu has quit IRC | 22:53 | |
| openstackgerrit | Julia Kreger proposed openstack/ironic master: Policy json to yaml migration https://review.opendev.org/c/openstack/ironic/+/763262 | 23:02 |
| *** rcernin has joined #openstack-ironic | 23:03 | |
| *** ociuhandu has joined #openstack-ironic | 23:05 | |
| *** ociuhandu has quit IRC | 23:10 | |
| *** alexmcleod__ has joined #openstack-ironic | 23:10 | |
| *** alexmcleod_ has quit IRC | 23:10 | |
| *** tkajinam has quit IRC | 23:10 | |
| *** tkajinam has joined #openstack-ironic | 23:11 | |
| *** k_mouza has quit IRC | 23:17 | |
| *** ociuhandu has joined #openstack-ironic | 23:21 | |
| openstackgerrit | Julia Kreger proposed openstack/ironic-inspector master: Add upgrade check, and json2yaml policy handling https://review.opendev.org/c/openstack/ironic-inspector/+/763286 | 23:26 |
| janders | good morning Ironic o/ | 23:30 |
| *** ociuhandu has quit IRC | 23:46 | |
| stevebaker | janders: hi! | 23:47 |
| TheJulia | good mroning | 23:58 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!