| opendevreview | Taketani Ryo proposed openstack/ironic master: Add the setting of memcached servers to keystone_authtoken https://review.opendev.org/c/openstack/ironic/+/898183 | 00:27 |
|---|---|---|
| rpittau | good morning ironic! o/ | 07:11 |
| masghar | Good morning! | 08:10 |
| dtantsur | morning folks, happy Monday | 08:29 |
| opendevreview | Pierre Riteau proposed openstack/bifrost stable/victoria: CI: Update cached cirros image to 0.5.3 https://review.opendev.org/c/openstack/bifrost/+/885880 | 09:45 |
| iurygregory | good morning Ironic | 11:10 |
| iurygregory | yay habemus Firmware Interface in gophercloud :D | 12:05 |
| rpittau | Great :) | 12:18 |
| iurygregory | yeah, now I think i just need 2 things to have in metal3 :D | 12:34 |
| dtantsur | iurygregory: FYI https://github.com/gophercloud/gophercloud/pull/2791 | 12:39 |
| iurygregory | interesting | 12:40 |
| *** drannou_ is now known as drannou | 13:18 | |
| TheJulia | good morning | 13:25 |
| iurygregory | good morning TheJulia =) | 13:25 |
| opendevreview | Damien RANNOU proposed openstack/ironic-python-agent-builder master: When creating the rescue user, check if we are on Debian or RH based in order to use the right sudo group https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/898322 | 14:27 |
| opendevreview | Damien RANNOU proposed openstack/ironic-python-agent-builder master: When creating the rescue user, check if we are on Debian or RH based in order to use the right sudo group https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/898322 | 14:48 |
| JayF | o/ | 15:00 |
| JayF | #startmeeting ironic | 15:00 |
| opendevmeet | Meeting started Mon Oct 16 15:00:13 2023 UTC and is due to finish in 60 minutes. The chair is JayF. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:00 |
| opendevmeet | The meeting name has been set to 'ironic' | 15:00 |
| iurygregory | o/ | 15:00 |
| dtantsur | o/ | 15:00 |
| TheJulia | o/ | 15:00 |
| JayF | Welcome to the Ironic meeting! A reminder that this meeting is held under the OpenInfra Code of Conduct available at https://openinfra.dev/legal/code-of-conduct. | 15:00 |
| JayF | #topic Announcements / Reminder | 15:00 |
| JayF | #info Standing reminder to review patches tagged ironic-week-prio and to hashtag any patches ready for review with ironic-week-prio: https://tinyurl.com/ironic-weekly-prio-dash | 15:00 |
| JayF | #topic Action items from previous meeting | 15:01 |
| JayF | I need to carry this over | 15:01 |
| JayF | #action JayF to backport ngs_save fix for networking_generic_swtich, cut a bugfix-version (not branch) release of it | 15:02 |
| JayF | sorry about that, it fell off my radar | 15:02 |
| JayF | #topic Caracal Release schedule | 15:02 |
| JayF | #link https://releases.openstack.org/caracal/schedule.html | 15:02 |
| JayF | Take note, we have a release schedule. | 15:02 |
| JayF | Any related commentary or discussion? | 15:02 |
| TheJulia | nothing from me | 15:03 |
| rpittau | o/ | 15:03 |
| JayF | #topic October PTG | 15:03 |
| JayF | #info Topics/schedule have been aligned for PTG, please review | 15:03 |
| JayF | #link https://etherpad.opendev.org/p/ironic-ptg-october-2023 | 15:03 |
| JayF | As always, there is some flexibility, please review and make noise if any proposed thing is ahardship. | 15:04 |
| JayF | Any related commentary or discussion on PTG? | 15:04 |
| TheJulia | nothing on my end | 15:05 |
| JayF | moving on. | 15:05 |
| JayF | #topic Ironic CI Status | 15:05 |
| JayF | Anything of note about Ironic CI? | 15:05 |
| TheJulia | Last week the cirros mirror went offline, it was down for ~4-6 hours, I think on Thursday. Rechecks may be needed but I may have already done them on the open changes from that time window | 15:06 |
| * TheJulia doesn't remember anymore | 15:06 | |
| JayF | Aight. In general it's the quiet time so I'm not surprised the only report is a hard-break. | 15:06 |
| JayF | #topic RFE Review | 15:06 |
| JayF | One topic here | 15:06 |
| JayF | #link https://review.opendev.org/c/openstack/ironic-specs/+/896474 | 15:06 |
| JayF | httpboot support | 15:06 |
| JayF | Please take note of the spec and review it | 15:07 |
| JayF | I will add it to my queue but probably will not be a +2 on it unless absolutely neccessary due to the lack of personal experience with redfish gear | 15:07 |
| TheJulia | If anyone has questions, please feel free to ping me | 15:07 |
| TheJulia | Also, FWIW, we have an ilo version which basically does the exact same thing as prior art, it is not mentioned, but it uses the httpboot bmc interface | 15:08 |
| JayF | oh, neat | 15:08 |
| JayF | I don't have access to ilo hardware for my work, fwiw, either, even though my downstream uses it | 15:08 |
| JayF | Thanks for proposing that spec. | 15:08 |
| JayF | #topic Open Discussion. | 15:08 |
| JayF | I'm going to note, this is a bit of a plug but we've got 50 minutes, I feel OK doing it :P | 15:09 |
| JayF | I'll be presenting at SeaGL on Nov 4, on Trust in an Open Source Community https://osem.seagl.org/conferences/seagl2023/program/proposals/984 | 15:09 |
| JayF | I believe it'll be simulcast or rebroadcast digitally for those not in the area, if you're interested. | 15:09 |
| iurygregory | tks for sharing JayF =) | 15:10 |
| rpittau | nice | 15:10 |
| JayF | Anything else for open discussion? | 15:11 |
| TheJulia | Do we have anything we need to discuss in advance of the ptg next week? | 15:11 |
| TheJulia | Just thinking, it is next week | 15:11 |
| JayF | I was hoping folks would look at the etherpad after the meeting and maybe that would induce conversation as needed | 15:11 |
| JayF | you and I went over it sync last week to get it scheduled | 15:12 |
| JayF | so I think mostly action lies on others now to do prework :) | 15:12 |
| JayF | I have more TC-PTG prework to do, too | 15:12 |
| TheJulia | It is also the week before the PTG, most of us need a little mental downtime plus time for administrative tasks | 15:13 |
| TheJulia | so, mileage will vary this week. | 15:13 |
| JayF | ++ | 15:13 |
| drannou | I have one if you want: Don't know if you remumber but I ask few weeks ago if you already work on Disk encryption. Seems that it was not the case, so we move on checking how we could integrate SED disks encryption with ironic, barbican etc. We will try to make a POC | 15:13 |
| JayF | I personally have had a lot of pulls on that cord as well the last two or three weeks | 15:13 |
| TheJulia | dtantsur: so I'm thinking of completely ripping glean out. Any objections? | 15:13 |
| dtantsur | It's not enough information for me to object or not :) | 15:13 |
| TheJulia | dtantsur: still supporting the case though, just not using external tools/logic to do parsing | 15:13 |
| JayF | drannou: so, is there hardware-assistance in the encrpytion or what? | 15:14 |
| dtantsur | If you suggest to rewrite it ourselves.. I'll ask WHY | 15:14 |
| JayF | drannou: would be interesting to see a writeup -- mailing list or RFE bug is OK if you're not spec-ready yet, about what you have in mind for on disk/orchestration | 15:14 |
| TheJulia | dtantsur: eh, we don't need to do *everything* it does, just a small portion of stuff | 15:14 |
| TheJulia | for a very short transient time, turns out to be very little code, really | 15:15 |
| dtantsur | TheJulia: I think pretty much everything it does is networking. | 15:15 |
| JayF | rip out glean in what context? | 15:15 |
| TheJulia | networking for long term consumption, we're in a ramdisk :) | 15:15 |
| TheJulia | virtual media boot handling/parsing of config-2 | 15:15 |
| dtantsur | The very goal of supporting several different networking backends is quite hard. Let alone testing that in the CI. | 15:15 |
| JayF | ack | 15:15 |
| TheJulia | dtantsur: not if we're using the standard interface to make runtime changes | 15:16 |
| dtantsur | TheJulia: there are *at least* two of them | 15:16 |
| JayF | there's a standard, cross-distro network interface? | 15:16 |
| dtantsur | NM and systemd-network | 15:16 |
| TheJulia | iproute2 should be available | 15:16 |
| JayF | mmm | 15:16 |
| JayF | that won't do everything network-data can specify | 15:16 |
| JayF | e.g. bonding with vlans | 15:16 |
| TheJulia | we don't configure bonding | 15:17 |
| drannou | JayF: Yes, Drives like NVME support offloaded encryption: the device itself will manage it, on elec power on the disk is encrypted, waiting for the key. The idea would be to boot on IPA and let the IPA unlock the disk, and soft reboot on the disk | 15:17 |
| dtantsur | we can do it | 15:17 |
| TheJulia | and vlans was simple | 15:17 |
| dtantsur | And using low-level tools behind the NM back is a risky approach | 15:17 |
| TheJulia | okay, if someone were to do it manually, yes, they could articulate bonding | 15:17 |
| dtantsur | wdym manually? it's a part of network data. | 15:17 |
| TheJulia | I'm thinking in the fully integrated case, we bind ports individually afaik | 15:18 |
| TheJulia | so manually would be someone populating network_data and have no neutron | 15:18 |
| dtantsur | Which is what Steve Hardy is doing with Metal3 nowadays :) | 15:18 |
| TheJulia | The alternative is add additional backends to glean so we can test it in CI | 15:18 |
| TheJulia | (tinycore) | 15:18 |
| dtantsur | Or test with a real IPA image | 15:19 |
| TheJulia | can't due to rax | 15:19 |
| dtantsur | Can we ask the Infra to not schedule us there? I feel like we're going too far to solve RAX issues already... | 15:19 |
| TheJulia | or we rip out the fallback logic and just risk performance being a bigger issue | 15:19 |
| JayF | that's what I was about to ask, dtantsur | 15:20 |
| clarkb | we have nested virt flavors. They can and do fail we ask people willing to use them to work with the cloud when that happens to figure it out as we are unable to debug for you | 15:20 |
| clarkb | they are also in limited clouds so may go away | 15:20 |
| clarkb | but haven't yet | 15:20 |
| TheJulia | I can always go deal with trying to write a glean backend for tinycore, but.. I dunno since there is fear over nested virt availability. We opt into nested virt where available | 15:22 |
| JayF | drannou: as long as there's an open standard for it, I don't see why we'd be in opposition to it. That being said; barbican is not a super active openstack project to be blunt, so that's the only piece that makes me nervous is taking a dep there. | 15:22 |
| dtantsur | A glean backend for tinycore is better than rewriting the whole Glean ourselves IMO | 15:22 |
| TheJulia | It is not the whole of glean, but if we're super fearful of just making runtime changes, then I can abandon the path I'm on | 15:23 |
| drannou | JayF: Yes I completely agree, but we would just use barbican for what it is : a secured key store | 15:23 |
| dtantsur | TheJulia: 80% of Glean is already too much Glean :) | 15:23 |
| JayF | drannou: if I was implementing it in Ironic; given the standalone-use-cases of Ironic, and especially that it's deployed in e.g. metal3, I'd probably suggest that key store be made into an interface in Ironic so it can be pluggable | 15:23 |
| TheJulia | There was work a few years ago to do on-boot encryption and plug that into a remote keystore | 15:24 |
| JayF | drannou: but I think it's obvious this is a feature that 'fits' Ironic; just write it up in an RFE and add it to "RFE Review" on meeting agenda (likely meeting next week is cencelled for PTG) | 15:24 |
| TheJulia | .... CoreOS had it turned on for a short while. | 15:25 |
| JayF | drannou: if we need more details, at that RFE review we might ask you to write a spec | 15:25 |
| JayF | hmm | 15:25 |
| TheJulia | I'm trying to remember what it was called | 15:25 |
| JayF | I'm going to close the meeting; we've sorta devolved into general chat at this point | 15:25 |
| JayF | #endmeeting | 15:26 |
| opendevmeet | Meeting ended Mon Oct 16 15:26:26 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:26 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/ironic/2023/ironic.2023-10-16-15.00.html | 15:26 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/ironic/2023/ironic.2023-10-16-15.00.txt | 15:26 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/ironic/2023/ironic.2023-10-16-15.00.log.html | 15:26 |
| clarkb | also I would get away from "solve the rax issues" its not a rax problem | 15:26 |
| clarkb | its a "nested virt is hard" problem and clouds don't want to bother with the pain | 15:26 |
| JayF | drannou: to be clear; an RFE is just a bug ticket in bugs.launchpad.net/ironic | 15:26 |
| clarkb | amazon doesn't do nested virt either | 15:26 |
| TheJulia | clarkb: True, but highly variable performance on rax doesn't help *at all* | 15:27 |
| clarkb | TheJulia: I've said it before and I'll say it again :) we are very likely our own worst enemy (noisy neighbor) in most of these clouds | 15:27 |
| drannou | Never done an RFE before, Yes I can do it but I don't know if ti will fit the rules :p | 15:27 |
| clarkb | in particular I believe that swapping jobs lead to iops being consumed to the detriment of test nodes across the hypervisors | 15:27 |
| TheJulia | clarkb: I know, and I agree, which is also why we've made efforts to minimize our footprint on rax in particular | 15:28 |
| drannou | clarkb: the biggest problem with nested offload is the security, there was several CVE related to that on intel side | 15:28 |
| clarkb | drannou: well it also just doesn't work. It crashes regularly when you get a kernel update in one of the three kernels involved | 15:28 |
| clarkb | if you tightly control the kernel in all three layers then you can probably get it working pretty reliably but that isn't the case for public clouds | 15:29 |
| TheJulia | drannou: so is the idea your hoping for the encrypted glance image functionality ? | 15:29 |
| drannou | it depends of the workload, most of the time "it works", but of course on specific load, it might not be stable enough | 15:29 |
| JayF | for cloud providers, "most of the time it works" is hell | 15:30 |
| JayF | drannou: https://bugs.launchpad.net/ironic/+bug/2034953 is an example of an RFE bug; generally speaking more detail is better. Sometimes I can find it helps me, even if it's "heavier" process, to jump to writing a spec which are these: https://review.opendev.org/c/openstack/ironic-specs/+/896474 -- the specs are good to look at for a checklist of stuff to think about even if | 15:30 |
| drannou | JayF: so true... | 15:30 |
| JayF | just writing an RFE bug | 15:30 |
| JayF | drannou: I think it's obvious we are all friendly and stuff, so just take a swing and we'll help if it's not in line :D | 15:30 |
| drannou | TheJulia: well I did not yet check the Glance part, even may be it's not needed: I was more thinking about an ironic driver | 15:31 |
| drannou | like BMC, reboot etc | 15:31 |
| JayF | yeah the piece I'm a little interested in is that since it sounds like this unencrypt happens in-band | 15:32 |
| TheJulia | The conundrum on the glance encrypted image stuffs is largely it is all writen from a "everything is a VM" and the infrastructure is LUKS under the hood | 15:32 |
| JayF | and Ironic gets outta the loop once we get a workload provision | 15:32 |
| JayF | is who does the decrypt once the workload is released | 15:32 |
| drannou | when the disk is unlock, it has no impact on the final OS (to be confirmed), so having it activable or not depending on IPA introspection would be better | 15:32 |
| TheJulia | which doesn't work on the hardware side of things short of decrypting the entire thing | 15:32 |
| JayF | TheJulia: this sounds more like formalization around the security locking and key management stuff in NVMe protocols | 15:33 |
| TheJulia | JayF: yeah | 15:33 |
| JayF | TheJulia: I am ... suspicious that the model will mesh with ours but it's hard to talk/think about without having the full picture written down to reason about | 15:33 |
| TheJulia | JayF: the glance->VM encrypted image stuff? | 15:34 |
| TheJulia | or NVMe security? | 15:34 |
| JayF | no, the stuff drannou is talking about re: managing NVMe encrpytion keys and locking/unlocking drive | 15:34 |
| TheJulia | Yeah, that, I dunno | 15:34 |
| drannou | JayF: I made a sim^ple test on hardware I have : in rescue, locking the NVME with a pass, so it wipe out the disk | 15:35 |
| TheJulia | One of the paths I've seen is an unencrypted intermediate ramdisk which can obtain the key and do the unlock, but somewhere that key has to be housed | 15:35 |
| drannou | I manually unlock, and install a debian on it | 15:35 |
| JayF | TheJulia: that "somewhere" in drannou's proposal is barbican, but yeah | 15:35 |
| JayF | I'm interested to see it end-to-end | 15:35 |
| TheJulia | yeah, much more a customized diskimage-builder thing imho, but we would need to be aware to do the initial needful | 15:36 |
| drannou | after a hard reboot, the disk is locked, nothing can boot, but after putting back the rescue, manually unlocking the disk, and soft rebooting, the host boot normally | 15:36 |
| JayF | mainly curious how the two cases look compared: on-disk deployment (we don't have netbooting anymore so it'll have to manage it's own boot once deployed) | 15:36 |
| JayF | and deployment itself | 15:36 |
| JayF | best case is it works with Ironic and the implementation is a deploy template with a step | 15:36 |
| TheJulia | yeah | 15:36 |
| JayF | drannou: that is ... unlikely to be a good fit with the Ironic model then IMO | 15:37 |
| JayF | if a user was on a flat network, and using this NVMe style security, a locked disk could put that machine at more security risk because it would potentially fallback to pxe | 15:37 |
| JayF | it would almost require using like ... idk ramdisk deploy driver? with no cleaning? | 15:38 |
| JayF | so you just deploy onto it to unlock the data on the disk | 15:38 |
| TheJulia | you could | 15:38 |
| TheJulia | sort of yeah | 15:38 |
| TheJulia | you'd need to have an initial deploy but that too could in theory be a step | 15:38 |
| JayF | I think it's the sort of thing that could be hacked into Ironic to make it work, like I mention as a step | 15:38 |
| drannou | IMO theer is two possible approch: use IPA to unlock the device, or create a small IPA like image that we could flash on the boot sector of the NVME (less interesting for me) | 15:39 |
| TheJulia | but ramdisk doesn't execute agent side steps at all on boot | 15:39 |
| JayF | but I don't think that kind of failure mode is something that'd make sense as a first class Ironic thing | 15:39 |
| JayF | UNLESS/UNTIL we support that "devices that can never power off" stuff TheJulia has queued for PTG | 15:39 |
| JayF | bceause this is a case of a "device that we can never intentionally power off" essentially | 15:39 |
| TheJulia | eh, one panacia might not, but multiple may! | 15:39 |
| drannou | JayF: Yeah exactly, something like: instead of "clean" arguement, ironic say to IPA: unlock @ reboot | 15:39 |
| JayF | the thing is, IPA only runs during provisioning actions | 15:40 |
| JayF | well, if we call node servicing a provisioning action | 15:40 |
| TheJulia | well, we could always drop in a kexec step too | 15:40 |
| JayF | IPA is outta the picture once the node has an OS on it and is puttering along | 15:40 |
| JayF | so you'd have to do something like rescue mode or like I said, wire up a ramdisk deploy as an "unlocker" | 15:40 |
| TheJulia | and then there could be some sort of path to always send down deployment as setup | 15:40 |
| TheJulia | dunno, that gets a little complex in clustered setups as there are some caveats | 15:41 |
| JayF | possible with Ironic ✓ | 15:41 |
| drannou | The problem is that IPA only works on Provisionning vlan, so we would need to do something like rescue: when the customer ask for a hard boot, we need to boot the host on provisionning network, boot IPA, unlock the disk, and go back on user network | 15:41 |
| JayF | good idea to implement upstream as a happy path ⃠ | 15:41 |
| JayF | yep, exactly | 15:42 |
| JayF | but rescue is a little... delicate | 15:42 |
| TheJulia | Well, you can do per-node provisioning, but then you also have security risks... less so with something like httpboot, but yeah | 15:42 |
| JayF | because it's timing based as it is | 15:42 |
| JayF | it's successful as a feature to help recover otherwise screwed-up nodes, but it's not something I'd want as part of my usual workflow | 15:43 |
| drannou | So yes it's a complicated subject, that would need to change a lot of things | 15:44 |
| TheJulia | steps allow for workflows to be defined though | 15:44 |
| JayF | hmmm | 15:45 |
| TheJulia | kind of going back to deploy time raid | 15:45 |
| JayF | the reason this doesn't mesh with Ironic model | 15:46 |
| JayF | is that we can't model it in our states | 15:46 |
| JayF | if we were to support something like this as a grade-A thing, we'd need to model "locked" as a state, potentially | 15:46 |
| TheJulia | We'd almost need a "ASSISTEDACTIVE" | 15:46 |
| drannou | JayF: the 'lock/unlock' disk state in the API ? | 15:46 |
| JayF | well, what TheJulia is saying is closer | 15:46 |
| TheJulia | meaning we always need to do something to turn the machine on | 15:47 |
| JayF | we'd need a state either saying "provisioned with OS but inaccessible" | 15:47 |
| JayF | or "provisioned with OS but only accessible because MAGIC" | 15:47 |
| TheJulia | drannou: for the redfish api? | 15:47 |
| drannou | TheJulia: I was just asking what JayF has in mind, but he already answer :) | 15:48 |
| TheJulia | ahh, okay | 15:48 |
| TheJulia | some sort of "we need to do a thing" state in the state machine wouldn't be awful, really. Just the caveats I was thinking of in terms of cluster management. You'd basically want tinyipa sized artifacts for inband operations | 15:48 |
| drannou | yeah that's also something I had in ming: how to "know". In fack I was thinking to simply say: if the power state is off, there is no other way to make a nova start or reboot | 15:49 |
| TheJulia | that is if you can use such and don't need 600MB NIC card firmware | 15:49 |
| JayF | So to be clear: | 15:49 |
| JayF | 1) The quickest path is the quick and dirty step based approach, either with rescue or with swapping deploy driver to ramdisk deploy to unlock drives | 15:49 |
| JayF | 2) this is the longer term "prettier" approach which probably would have to be ordered *after* support for hardware which can never be powered off (which is being discussed at PTG next week) | 15:50 |
| drannou | I fill that, for security topic, there is no "quick and dirty" possibility :D | 15:50 |
| JayF | well, (1) would be all operator config, not upstream code | 15:50 |
| JayF | you can do all you want in your config that I never have to see or be responsible for | 15:50 |
| JayF | and believe me, people do LOL | 15:50 |
| drannou | so I will try to make an RFE, may be it will be too simple as a first step, but we might be able to iterate on it | 15:52 |
| * TheJulia punts the IPA changes to teach to read/just run ip commands to setup networking | 15:52 | |
| JayF | getting the issue filed and on the meeting agenda is the best first start | 15:53 |
| JayF | although I'm about to cancel next week's meeting :D | 15:53 |
| TheJulia | It makes sense to do so, tbh (the meeting | 15:57 |
| JayF | well, I think it might actually overlap with scheduled PTG sessions | 16:00 |
| JayF | so it's not really optional | 16:00 |
| JayF | just didn't mention it in the meeting | 16:00 |
| rpittau | good night! o/ | 16:05 |
| opendevreview | Julia Kreger proposed openstack/ironic-python-agent master: WIP/DNM: Get rid of simple-init (but keep glean) https://review.opendev.org/c/openstack/ironic-python-agent/+/895519 | 21:10 |
| JayF | TheJulia: thought: we need a way, other than separate drivers, for hardware-specific cleaning steps in-band, perhaps. Lighter weight. akin to hardware managers? IDK ... | 21:24 |
| JayF | TheJulia: just thinking of stuff like, ilo had a built in config reset which is useful for cleaning; but that's a bad reason for it to have a whole driver vs just redfish + a single ilo specific bit | 21:24 |
| JayF | just trying to think of new mental models for thi | 21:24 |
| JayF | *this | 21:24 |
| TheJulia | So the challenge is in the ilo case it is exposed as a step on their driver | 21:26 |
| JayF | think about this in a greenfield world | 21:26 |
| JayF | not as it is today | 21:26 |
| JayF | then like, we can try to mush it into the existing mdoel | 21:26 |
| TheJulia | Oh, yeah, sure if user selected and enabled on a single Interface | 21:26 |
| TheJulia | Need a conditional model for automatic operation | 21:27 |
| JayF | Well think about in a world where automatic cleaning could be driven by a to-be-designed step template | 21:27 |
| JayF | then you move away from a world where everything has to be integrated and automatic and magic | 21:27 |
| JayF | and into one where I can opt into pulling things from more varied places | 21:28 |
| TheJulia | Still conditional at some level | 21:28 |
| JayF | yeah, I guess so | 21:28 |
| JayF | this just turns rapidly into | 21:28 |
| JayF | main driver+sidecar | 21:28 |
| TheJulia | Today, we have a deploy template, and we’re explicitly told what to use | 21:28 |
| JayF | or just redfish-{blah} type drivers | 21:28 |
| TheJulia | In that world, we sort of have to guess or be told explicitly | 21:28 |
| JayF | yeah | 21:28 |
| JayF | because of the undiscoverability, by nature, of some of these hardware features | 21:29 |
| TheJulia | Yeah, which sort of lands us on hardware driver based sort of defaults too since it is the lowest common denominator to a class of gear | 21:29 |
| TheJulia | Or some sort of “can I execute, and try to execute” model for some steps | 21:30 |
| JayF | now, from a flip side perspective | 21:30 |
| TheJulia | Or both | 21:30 |
| JayF | these sort of "advanced features" | 21:30 |
| JayF | are unlikely to be something people want to magically want enabled in general | 21:30 |
| TheJulia | Yup | 21:30 |
| JayF | so potentially having the ability to expose them but only work when flipped on explicitly isn't too horrible | 21:30 |
| TheJulia | Yeah, if they are supported. That is another conundrum | 21:31 |
| JayF | I like the idea of node.automated_clean = name_of_step_template somehow enabling this | 21:31 |
| JayF | but we'd almost need some new kind of nerfed interface implementation | 21:31 |
| JayF | that only provides steps and has limitations on what it can do | 21:31 |
| JayF | like hand it a redfish client or something | 21:31 |
| JayF | like it could never be the whole driver; but it could be a step mix in | 21:32 |
| JayF | (I'm still not to the point of saying this is an idea, or a good idea, I'm just sorta trying to explore the space) | 21:32 |
| ashinclouds[m] | Nothing stops us from mixing today, just nobody has asked and most drivers have kept the value add stuff behind their libraries on nonstandard interfaces. If appropriate delineation existed, it’s not a big deal | 21:33 |
| JayF | ah, in the actual hardware the fancy features are gated in the proprietary side of the bmc? | 21:34 |
| JayF | that craters any potential at all for extracting value here then | 21:34 |
| TheJulia | JayF: often, yeah by proprietary apis or by license keys | 22:05 |
| JayF | I mean, if that's the case, may those features languish in unsupported hell forever. I don't wanna expend energy making $vendor money at the expense of openness. | 22:19 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!