| opendevreview | Merged openstack/ironic master: Add Redfish LLDP data collection support to the Redfish inspection interface. https://review.opendev.org/c/openstack/ironic/+/967841 | 00:20 |
|---|---|---|
| cardoe | Alright ignore that inspection rules owner thing. I wish system scopes could be “ironic” or “neutron”. | 00:34 |
| cardoe | cid: as far as inspection rules do we have any larger examples? Like it seems that I can have a conditional for a grouping of rules | 00:35 |
| TheJulia | system owner is not an awful idea, tbh | 00:36 |
| cardoe | Well the rules aren’t tied to a node. So it’s not working how I want. | 00:43 |
| TheJulia | oh, yeah, that makes sense | 00:45 |
| cardoe | I wish I could have owners associate some rules though. | 00:47 |
| TheJulia | that wouldn't seem that difficult, really | 00:47 |
| TheJulia | and that was part of the original idea | 00:47 |
| cardoe | I have two different groups that have hardware. Their network stuff cannot conflict and overlap so I have them in one neutron since ironic will only talk to one. | 00:49 |
| TheJulia | ugh, yeah, we never modeled on multiple neutrons | 00:50 |
| cardoe | Which is okay. | 00:50 |
| cardoe | If I could get multiple VNI pools that would be perfect cause each fabric would be its own conductor group | 00:51 |
| JayF | all you need is copy, paste, sed, and network_interface=other_neutron ;) | 00:52 |
| * TheJulia twitches | 00:52 | |
| * TheJulia drifts to the living room to get away from those computer boxes | 00:55 | |
| opendevreview | Iury Gregory Melo Ferreira proposed openstack/ironic master: Add retry logic for boot device changes during POST https://review.opendev.org/c/openstack/ironic/+/971150 | 02:23 |
| opendevreview | Iury Gregory Melo Ferreira proposed openstack/ironic master: Fix heartbeat for steps with requires_ramdisk=False https://review.opendev.org/c/openstack/ironic/+/971152 | 03:42 |
| rpittau | good morning ironic! o/ | 07:44 |
| opendevreview | Riccardo Pittau proposed openstack/bifrost master: Removed unused tinyipa CI jobs https://review.opendev.org/c/openstack/bifrost/+/969083 | 08:26 |
| opendevreview | Riccardo Pittau proposed openstack/bifrost master: Remove unused tinyipa CI jobs https://review.opendev.org/c/openstack/bifrost/+/969083 | 08:27 |
| opendevreview | nidhi proposed openstack/ironic master: Add LLDP collect for DRAC Redfish inspection https://review.opendev.org/c/openstack/ironic/+/970630 | 09:18 |
| opendevreview | nidhi proposed openstack/ironic master: Add LLDP collect for DRAC Redfish inspection https://review.opendev.org/c/openstack/ironic/+/970630 | 09:20 |
| opendevreview | Merged openstack/ironic master: Use per-node external_http_url for configdrive ISO https://review.opendev.org/c/openstack/ironic/+/901777 | 09:33 |
| cid | cardoe, I'm not sure what you mean by "grouping of rules". | 11:39 |
| cid | You may be thinking of `loops`? With loops you can perform the same action or condition on as many arguments as you want. | 11:39 |
| cid | I can come up with examples of how simple as well as how much complex an inspection can get, and probably also add it to the docs. But I will have to revisit the code one more time to :). | 11:39 |
| cid | I mean, you can create multiple set of rules as well | 11:41 |
| opendevreview | Milan Fencik proposed openstack/ironic master: fix: iPXE boot interface neutron logic detection https://review.opendev.org/c/openstack/ironic/+/971173 | 11:53 |
| opendevreview | Allain Legacy proposed openstack/ironic master: Add generic switch driver support https://review.opendev.org/c/openstack/ironic/+/966469 | 13:22 |
| opendevreview | Allain Legacy proposed openstack/ironic master: Add ironic-networking network interface https://review.opendev.org/c/openstack/ironic/+/966470 | 13:22 |
| opendevreview | Allain Legacy proposed openstack/ironic master: Add standalone networking service installation guide https://review.opendev.org/c/openstack/ironic/+/966471 | 13:22 |
| opendevreview | Allain Legacy proposed openstack/ironic master: Improve exception handling in switch driver factory https://review.opendev.org/c/openstack/ironic/+/969852 | 13:22 |
| opendevreview | Allain Legacy proposed openstack/ironic master: Add two phase driver factor initialization https://review.opendev.org/c/openstack/ironic/+/971182 | 13:22 |
| opendevreview | Allain Legacy proposed openstack/ironic master: Introduce switch driver base class https://review.opendev.org/c/openstack/ironic/+/971183 | 13:22 |
| opendevreview | Allain Legacy proposed openstack/ironic master: Address remaining review comments for rpc methods https://review.opendev.org/c/openstack/ironic/+/971184 | 13:22 |
| alegacy | dtantsur: I've addressed your comments. A couple of them caused me to re-think a couple of things and that resulted in a bit of restructuring. That resulted in me breaking out some things into 2 more commits which I've tacked onto the front of the chain. | 13:25 |
| cardoe | iurygregory: since you've got some dell hardware... can you peek at ComputerSystem.SerialNumber vs ComputerSystem.SKU? It's the System object in Sushy. | 13:58 |
| cardoe | janders: I think you do as well. | 13:58 |
| cardoe | Lemme know if you're seeing the Dell Service Tag (aka Serial Number) in the SKU field and a longer string in the SerialNumber field (which happens to be the motherboard's serial number) | 13:59 |
| iurygregory | cardoe, sure let me check, does it matter the model of the hardware? I only have a R640 atm | 14:00 |
| cardoe | cid: yeah I'm trying to go through the docs and some of the loop stuff. I might update the docs from what I learn. Almost thinking about making a simulator CLI for it as well. | 14:00 |
| iurygregory | or you want an idrac10 machine? | 14:00 |
| cardoe | iurygregory: I was hoping you had different hardware than me so whatever you got is perfect. | 14:00 |
| iurygregory | the idrac10 I had is not available anymore =(, but let me see with the machines I have, I might be able to poke some people to check also | 14:00 |
| cardoe | I don't have either of those right now. my idrac10 stuff is sitting boxed up on a loading dock heading back out the door right now | 14:01 |
| alegacy | cardoe: I have a R740 ... sku: "H98S753", and serial_number: "CNIVC000000000" (zeroed the digits) | 14:02 |
| iurygregory | serial number a mix of letters and numbers 14 characters / sku mix of letters and number 7 characters | 14:03 |
| TheJulia | good morning | 14:06 |
| alegacy | TheJulia: your revert must have propagated down to me... the issue I saw yesterday is no longer happening. Thank you. | 14:09 |
| TheJulia | That is both good, and saddening to hear :) | 14:13 |
| dtantsur | morning TheJulia. you mentioned you had an idea why it happened? | 14:16 |
| TheJulia | Yeah, if the log is correct from that action, there is no publisher id and that gets saved as "" and then "" == "" | 14:17 |
| cardoe | alegacy: Thank you. | 14:36 |
| cardoe | iurygregory: perfect. | 14:36 |
| cardoe | So I'm gonna make a bug that says we should on Dell's stuff the SKU into SerialNumber and ignore the SerialNumber. | 14:36 |
| cardoe | Cause the IPA puts the Dell Service Tag into SerialNumber in inspection data. With Redfish we don't do that. | 14:37 |
| cardoe | The 7 character Service Tag is effectively the Serial Number as defined by Dell. | 14:37 |
| cardoe | I've confirmed that its the motherboard's serial number we're seeing there by having the DC swap a motherboard for me on a chassis and re-reading the value. | 14:37 |
| opendevreview | Julia Kreger proposed openstack/bifrost master: add an OCI artifact registry https://review.opendev.org/c/openstack/bifrost/+/961388 | 15:07 |
| opendevreview | Julia Kreger proposed openstack/bifrost master: bifrost-registry-install: install the ORAS client https://review.opendev.org/c/openstack/bifrost/+/968355 | 15:07 |
| opendevreview | Julia Kreger proposed openstack/bifrost master: Upload a disk image to OCI https://review.opendev.org/c/openstack/bifrost/+/968416 | 15:07 |
| opendevreview | Julia Kreger proposed openstack/bifrost master: Upload to and use artifact from OCI registry https://review.opendev.org/c/openstack/bifrost/+/968417 | 15:07 |
| TheJulia | Just rebases ^ | 15:08 |
| TheJulia | cardoe: I'm sort of feeling weird regarding https://review.opendev.org/c/openstack/ironic/+/971173 without a unit test. Thoughts? | 15:13 |
| JayF | I did intake on https://bugs.launchpad.net/virtualbmc/+bug/2133163 and opened it | 15:13 |
| JayF | tl;dr there's a bad security vuln in vbmc | 15:14 |
| TheJulia | joy | 15:16 |
| JayF | with my vmt hat on, it's not security managed, we don't generally care | 15:16 |
| JayF | with my ironic hat on, I am waffling between "we should care enough to fix it" and "meeehhhhhhhh" | 15:17 |
| dtantsur | Somebody with access to Claude could just point it at the report | 15:18 |
| TheJulia | well, even then, its a test service for local usage | 15:19 |
| dtantsur | To be clear, I fully agree with disclosing the bug and not treating it as a security issue in Ironic | 15:20 |
| JayF | Yeah, I think there are some ideas in there that we can pluck out to improve. There's no reason we aren't filtering the domain for file paths, for instance | 15:20 |
| JayF | But I have no desire to build a full ownership model and authentication into vbmc | 15:20 |
| TheJulia | anything we do there is sort of just pushing the problem around while also being breaking. Granted, we shouldn't really care about that, but if you suddenly can't invoke sudo or get elevated command execution to do stuff with VMs, your sort of in a werid state then | 15:20 |
| TheJulia | and then try to track/enforce that against VM state | 15:20 |
| dtantsur | tl;dr nobody should use vbmc any more unless they test something with IPMI | 15:21 |
| TheJulia | yup | 15:21 |
| dtantsur | Even people doing testing should opt for sushy-tools in most cases | 15:22 |
| * dtantsur is wondering how we can discourage everyone from using virtualbmc | 15:23 | |
| dtantsur | Maybe move it in-tree under devstack/lib? :) | 15:23 |
| JayF | how about rejecting their security bug reports and asking them openly why they are even packaging it :D | 15:23 |
| JayF | lol | 15:23 |
| dtantsur | That works but is reactive. I'd prefer a proactive approach. | 15:24 |
| dtantsur | I wonder how many messages of mine disappeared into irccloud hole.. | 15:29 |
| dtantsur | 4 messages, lovely. Here they go again: | 15:31 |
| dtantsur | One thing we did poorly was providing an attractive name for the project | 15:31 |
| dtantsur | sushy-tools does more to discourage usage | 15:31 |
| dtantsur | Rename to insecure-fake-ipmi? | 15:31 |
| dtantsur | I'm only half-joking btw. And stop doing any releases, especially putting anything on PyPI. In fact, maybe pull virtualbmc from PyPI. | 15:31 |
| JayF | Are you using a bnc or the webapp? | 15:31 |
| JayF | pulling vbmc from pypi is a good idea | 15:31 |
| dtantsur | JayF: bnc of course | 15:31 |
| JayF | ah, I use a PWA :) | 15:32 |
| JayF | was going to point you at the firefoxpwa bug around "all websockets go kaput when opening an external link" | 15:32 |
| dtantsur | If I wanted a so-so client, I'd just connect through Matrix like Steve | 15:32 |
| dtantsur | and not pay money for something the Synology NAS in my living room did much better | 15:32 |
| JayF | i find bnc style connections to be crap regardless of the host :) | 15:33 |
| JayF | I sometimes miss weechat in a screen, but not when I'm on mobile :) | 15:33 |
| dtantsur | ZNC has been rock sold for me for a decade but I decided not to rely on a server inside Red Hat (and thus VPN) | 15:33 |
| TheJulia | regarding pulling from pypi, I'm sure some folks out there have just been pip installing it for long standing CI jobs. It would break them, but if we wanted to have a small initial step on the path... then its not an unreasonable breaking sep | 15:45 |
| dtantsur | Changing the CI to install from git is annoying but IMO acceptable to make the folks stop and think | 15:46 |
| dtantsur | (I suspect we in Metal3 also install it from pypi) | 15:46 |
| cardoe | TheJulia: I agree. I'm speaking with Milan about it. | 15:48 |
| TheJulia | I guess a new breaking centos change has dropped | 15:55 |
| TheJulia | "msg": "Unable to enable service firewalld: Failed to enable unit: Unit /etc/systemd/system/firewalld.service is masked\n" | 15:55 |
| dtantsur | eeek | 15:55 |
| TheJulia | looks like it is failing in bifrost-ironic-install :\ | 15:55 |
| TheJulia | https://zuul.opendev.org/t/openstack/build/1e9ea279d6fa412d966648e09cde6631 <-- logs from rebase of dtantsur's install an iamge registry chagne | 15:56 |
| * TheJulia goes and looks up the ansible module syntax | 15:56 | |
| TheJulia | masked: false seems to be a possible path | 15:57 |
| opendevreview | Julia Kreger proposed openstack/bifrost master: Centos: set masked: false for firewalld https://review.opendev.org/c/openstack/bifrost/+/971212 | 15:59 |
| JayF | unmasking firewalld means it needs to be configured to let traffic thru, yeah? | 16:02 |
| TheJulia | well, the install sets it up and the prior state was that it was not masked, but now suddenly, it appears masked | 16:03 |
| TheJulia | so thinking centos likely changed things since the bifrost changes I posted a week and a few days ago passed just fine then | 16:03 |
| TheJulia | Looks like that change is good | 16:13 |
| TheJulia | Once it passes, I'll re-base and restack and whatnot | 16:14 |
| cardoe | hrm.. this test is gonna be funky. | 16:24 |
| cardoe | The tests only set "not_pxe" in the capabilities. | 16:24 |
| cardoe | The reality is that we probably should have def is_capable(self, cap) -> bool: on BootInterface | 16:25 |
| cardoe | Cause "ipxe_boot" implies "pxe_boot" | 16:25 |
| cardoe | We've also got a disconnect in "pxe_enabled". Cause our Dell's have HTTP based PXE enabled but don't have TFTP based PXE enabled. But IPA and Ironic report it as pxe_enabled=False. | 16:26 |
| dtantsur | For IPA, we rely on the BOOTIF kernel parameter, which is probably not set in this case | 16:30 |
| TheJulia | originally, the interfaces should have been dual flagged capability wise | 16:55 |
| TheJulia | so I sort of figured out why we didn't spot the ipa issue | 17:00 |
| TheJulia | partly, because the test was marked non-voting | 17:00 |
| TheJulia | and somehow it started failing in October/early november before hte ipa change merged | 17:00 |
| opendevreview | Doug Goldstein proposed openstack/ironic master: feat: add is_capable helper on BootInterface https://review.opendev.org/c/openstack/ironic/+/971226 | 17:02 |
| cardoe | So that's a WIP that's 0% complete that we could tighten that up. | 17:02 |
| cardoe | I can ask Milan to instead add "pxe_boot" to the iPXE interfaces. The only reason that "ipxe_boot" exists is for the ISCSI case it seems so that we can load something via ISCSI directly in the PXE env. | 17:03 |
| Milan | I can do it that way too, looking through the references in the code, it shouldn't break anything, but I'll defer to experts here :) TheJulia thoughts? | 17:21 |
| TheJulia | I think just *something* would make me more comfortable | 17:22 |
| cardoe | The other option is we just add "pxe_boot" to the iPXE drivers capabilities. | 17:29 |
| cardoe | The code just sets a flag "not_pxe" internally and if "pxe_boot" is not in capabilities then it set not_pxe. | 17:32 |
| cardoe | So its just not an easy one to test around | 17:32 |
| Milan | I'm open to any suggestions as long as we agree how we want to do it, I can write additional tests if needed, no problems. I'll wait for more feedback | 17:37 |
| TheJulia | cardoe: I think adding pxe_boot to ipxe driver caps makes sense, I just don't remember why it was not already there. | 17:41 |
| opendevreview | Julia Kreger proposed openstack/ironic-python-agent-builder master: ci: Start running the advaned ironic job https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/971232 | 17:46 |
| opendevreview | Julia Kreger proposed openstack/bifrost master: add an OCI artifact registry https://review.opendev.org/c/openstack/bifrost/+/961388 | 17:47 |
| clif | Question: I want to share data loaded by a conductor with a driver, specifically the neutron network driver and the trait-based-networking configuration data. Do I add TBN config as an attribute on the task? Or do I share it another way? | 17:49 |
| cardoe | TheJulia: So I'm gonna guess oversight? When you added it in 2018 you had both ipxe_boot and pxe_boot in there. The tests you wrote (which are since gone) even put a comment in the fake that you wrote which said "ipxe_boot imples pxe_boot so add both" | 17:50 |
| cardoe | So https://review.opendev.org/c/openstack/ironic/+/942135 is where it's broken | 17:54 |
| cardoe | That's the commit which stopped doing the "ipxe_boot" imples "pxe_boot. | 17:55 |
| cardoe | Every other commit either says that in the commit message or has a comment in the code. | 17:56 |
| cardoe | ah okay I see the flow. | 17:58 |
| opendevreview | Julia Kreger proposed openstack/ironic-tempest-plugin master: ci: fix and log errors on advanced tests disqual https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/971233 | 17:58 |
| TheJulia | oh joy! | 17:59 |
| TheJulia | I broke it! | 17:59 |
| * TheJulia breaks everything! | 17:59 | |
| cardoe | So in 2018 when you added it you put in the comments sayin that ipxe_boot implies pxe_boot so just add it. And you put it on the capabilities. | 17:59 |
| opendevreview | Verification of a change to openstack/bifrost master failed: Replace CLA instructions with DCO https://review.opendev.org/c/openstack/bifrost/+/956392 | 18:00 |
| TheJulia | so yeah, I added that change, 942135 because we were logging about pxe stuffs when doing vmedia | 18:00 |
| cardoe | Fast forward to Kaifeng splitting up ipxe and pxe classes. He only put ipxe_boot on the iPXE classes. But it didn't matter cause all the code that cared about that was deleted. He also removed your comments about the implying link and he deleted the tests. | 18:00 |
| TheJulia | *sigh* | 18:01 |
| cardoe | Then you added that check earlier this year and just checked pxe_boot | 18:01 |
| cardoe | You did have a TODO which said to make this safer in the future but that was deleted as well. | 18:01 |
| * TheJulia cries a little | 18:02 | |
| TheJulia | okay, that explains why making that change also didn't raise any other test failures and also why it seems like a bigger burden | 18:03 |
| cardoe | so I think Milan the better change is going to be to add pxe_boot to the iPXE classes. | 18:06 |
| cardoe | I think we rename ipxe_boot in the future as well. | 18:06 |
| TheJulia | ++, and just have something in there which tests it is set | 18:06 |
| cardoe | I found another one that's ripe for breaking | 18:07 |
| cardoe | ramdisk_boot and ramdisk_boot_configdrive | 18:07 |
| cardoe | ramdisk_boot_configdrive imples ramdisk_boot. But for now we've set both on the only interface that sets it. | 18:08 |
| TheJulia | ugh, bifrost upgrade job timed out :( | 18:08 |
| cardoe | The question isn't really if we're booting ipxe vs pxe. | 18:08 |
| cardoe | It's "can we use ipxe extended features or not" | 18:08 |
| TheJulia | well, the options we need to use and set are different | 18:08 |
| TheJulia | yeah | 18:08 |
| TheJulia | keep in mind, some of that randsik related stuff is also around the concept of ramdisk booting via the boot interface | 18:09 |
| TheJulia | and then also the prior pattern of ramdisk booting to pivot to the physical disk | 18:09 |
| TheJulia | (which, I think we've entirely removed the driver support for that path | 18:09 |
| cardoe | clif: so how would you load it? Can you share it via a param? | 18:09 |
| cardoe | Well I'm saying the code path checks ramdisk_boot a bunch and then suddenly checks ramdisk_boot_configdrive. So if someone was to add another BootInterface with just ramdisk_boot_configdrive then it would do the wrong thing. | 18:10 |
| clif | cardoe: Right now I'm loading the configuration data in the conductor class at startup | 18:11 |
| cardoe | TheJulia: actually exact same bug. We'll try to clean up the config drive if ramdisk_boot is set and there was a config drive. Not if ramdisk_boot_configdrive is set. But if ramdisk_boot_configdrive is set we'll generate one. | 18:12 |
| Milan | ok so it seems that adding pxe_boot to the iPXE classes capabilities is the course of action, I'll adjust the tests too. | 18:12 |
| TheJulia | joy | 18:14 |
| cardoe | You actually pointed out the possibilities for this abuse when you added HTTP boot. Cause you added it as a separate flag from the capabilities. | 18:16 |
| cardoe | Anyway, yes I agree with your former self that we need a safer interface / better test for this. :-D | 18:17 |
| TheJulia | does anyone remember if we wired BOOTIF into vmedia boots as well? | 18:17 |
| cardoe | I don't see it | 18:19 |
| TheJulia | le sigh | 18:19 |
| cardoe | We should though | 18:19 |
| TheJulia | ok | 18:19 |
| TheJulia | yeah | 18:20 |
| TheJulia | alegacy: so, you weren't vmedia booting, but you were network booting, so we needed an extra guard to prevent the possible case. | 18:33 |
| opendevreview | Julia Kreger proposed openstack/ironic-python-agent-builder master: WIP: lockout configdrive reads on network boots https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/971236 | 18:34 |
| opendevreview | Allain Legacy proposed openstack/ironic master: Add two phase driver factor initialization https://review.opendev.org/c/openstack/ironic/+/971182 | 18:47 |
| opendevreview | Allain Legacy proposed openstack/ironic master: Introduce switch driver base class https://review.opendev.org/c/openstack/ironic/+/971183 | 18:47 |
| opendevreview | Allain Legacy proposed openstack/ironic master: Add generic switch driver support https://review.opendev.org/c/openstack/ironic/+/966469 | 18:48 |
| opendevreview | Allain Legacy proposed openstack/ironic master: Add ironic-networking network interface https://review.opendev.org/c/openstack/ironic/+/966470 | 18:48 |
| opendevreview | Allain Legacy proposed openstack/ironic master: Add standalone networking service installation guide https://review.opendev.org/c/openstack/ironic/+/966471 | 18:48 |
| opendevreview | Allain Legacy proposed openstack/ironic master: Improve exception handling in switch driver factory https://review.opendev.org/c/openstack/ironic/+/969852 | 18:48 |
| opendevreview | Allain Legacy proposed openstack/ironic master: Address remaining review comments for rpc methods https://review.opendev.org/c/openstack/ironic/+/971184 | 18:48 |
| alegacy | TheJulia: thanks. | 18:50 |
| opendevreview | Merged openstack/bifrost master: Replace CLA instructions with DCO https://review.opendev.org/c/openstack/bifrost/+/956392 | 19:44 |
| cardoe | So anyone knowledgeable about the RBAC policy stuff... is it crazy to want to scope the system scope into different applications? like I see we use system_scope = all but what about system_scope = ironic while all can imply that? | 20:36 |
| opendevreview | Merged openstack/ironic master: Trait Based Networking Simulator https://review.opendev.org/c/openstack/ironic/+/966202 | 20:37 |
| JayF | ...what you're saying doesn't make sense | 20:37 |
| cardoe | So if I give you system scope. Then you've got system scope against neutron APIs as well. | 20:37 |
| JayF | Yeah. This is why you should limit use of system and service scope. | 20:38 |
| JayF | Ironic enables you to do this by allowing you to permit project owners to add nodes, which are automatically put into that project | 20:39 |
| JayF | use of Ironic in system scope is, more often than not, a choice to opt out of our node ownership RBAC stuff | 20:39 |
| cardoe | Well not for inspection rules | 20:40 |
| cardoe | It's system scope or bust. | 20:40 |
| JayF | same with public=true runbooks | 20:40 |
| TheJulia | so, I think the idea your getting into cardoe was more geared towards individual projects for services themselves | 20:40 |
| cardoe | Yeah that would make sense to me rather than sharing the "service" project. | 20:42 |
| cardoe | JayF: I'm just verbally brainstorming some kind of separation. I think the folks in here have appreciated some of that separation of concerns in the past in convos so I was just floating it out here. | 20:43 |
| JayF | cardoe: Ironic implemented service account this way, fwiw | 20:43 |
| JayF | cardoe: you can specify in Ironic which project to use as your service account | 20:43 |
| JayF | cardoe: yeah, I was just trying to tease out the root question, which I usually do through picking through the ask like we did here | 20:44 |
| JayF | > rbac_service_project_name¶ | 20:44 |
| JayF | and > rbac_service_role_elevated_access¶ | 20:45 |
| JayF | should be able to do something in the direction of what you're thinking, for Ironic clients at least | 20:45 |
| cardoe | So to give an example. I've got domain=infra, project=baremetal. I've got domain=service, user=ironic-api and domain=service,user=ironic-conductor-foo. Where foo is 1 of my fabrics and the name of the conductor group / shard. | 20:45 |
| cardoe | My nodes are owned by domain=infra,project=baremetal. But then I've also got some other nodes that are in domain=infra,project=othermetal | 20:47 |
| cardoe | Maybe I'm doing too much. | 20:48 |
| cardoe | othermetal are nodes that'll be my neutron network nodes. | 20:48 |
| cardoe | There's a different conductor for them. | 20:49 |
| JayF | I have worked places that model your type of problem | 20:49 |
| JayF | using config | 20:49 |
| cardoe | Ultimately I ask because if I come up with a setup that makes sense then I'm more than happy to write up a use case doc. | 20:49 |
| JayF | with diverging conductor group configs to acheieve some level of access restriction | 20:49 |
| JayF | at one place, we restricted an environment that way for PCI purposes | 20:50 |
| JayF | I think it's a problem, but I'm not convinced it's a software problem so much as a "there are 100 way to arrange openstack and about 95 of them are /wrong/ in some way" | 20:50 |
| cardoe | Makes sense. | 20:50 |
| cardoe | Yep. Agreed. Folks I work with are probably tired of hearing me say "OpenStack is like of the the 1500 random pieces Lego sets where its a build your own adventure" | 20:51 |
| TheJulia | and another 5 are prime examples of schrodinger's cat | 20:51 |
| cardoe | https://www.lego.com/en-us/product/bricks-bricks-bricks-10717 | 20:52 |
| cardoe | That's OpenStack. Build your heart out kids. | 20:52 |
| cardoe | I'm aiming to come to an arrangement that makes sense to others and then write up a document about it and how to configure it. | 20:52 |
| cardoe | Much like how Metal3 is an implementation of another arrangement. | 20:53 |
| cardoe | And Bifrost is another. | 20:53 |
| cardoe | But if that doesn't make sense I'll go back to my messy corner of Legos. | 20:54 |
| cardoe | I did rebuild my Saturn V rocket recently. | 20:54 |
| JayF | I offer a useless suggestion: just have one neutron, instead, of course! | 20:55 |
| cardoe | To be clear I don't wanna say my arraignment is better than another. Just more of a use case that others can follow if they want the same kind. So that they don't have to feel their way around in the dark like me. | 20:59 |
| opendevreview | Julia Kreger proposed openstack/ironic-tempest-plugin master: ci: fix and log errors on advanced tests disqualification https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/971233 | 20:59 |
| TheJulia | I think that is one of the challenges we have as a community made worse, by keeping everything open we tried not to lock anyone into a box but didn't really get good at leaving the popcorn for a trail | 21:00 |
| TheJulia | rpittau: dtantsur: looks like we need to make some major changes to bifrost jobs. Above and beyond centos changes, bookworm jobs now run out of ram at grub loading ramdisk: https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_4f7/openstack/4f7856502a68454f83cfec1caca71ec7/logs/testvm1_console.log and the upgrade job needs to be disabled to land the centos10 fix. :\ | 21:14 |
| TheJulia | Looks like there are also some general unhappiness, like EFI and General Protection errors | 21:18 |
| opendevreview | Julia Kreger proposed openstack/bifrost master: Centos: set masked: false for firewalld https://review.opendev.org/c/openstack/bifrost/+/971212 | 21:27 |
| opendevreview | Julia Kreger proposed openstack/bifrost master: ci: undo non-voting for centos10 upgrade https://review.opendev.org/c/openstack/bifrost/+/971258 | 21:27 |
| TheJulia | I'm sort of wondering if centos10 jobs should be non-voting, since it doesn't seem stable. | 21:28 |
| gmaan | cardoe: system scope is only supported by the ironic. all other openstack services does not implement it and raise 403 if request is made with system scope. | 22:53 |
| cardoe | ah | 22:53 |
| cardoe | Good to know. | 22:53 |
| gmaan | yeah, so system scope token used for ironic are safe from other services access point of view | 22:54 |
| opendevreview | Doug Goldstein proposed openstack/ironic master: fix redfish inspect system product name https://review.opendev.org/c/openstack/ironic/+/971142 | 22:55 |
| *** mfencik is now known as Milan_ | 22:57 | |
| *** Milan_ is now known as Milan | 22:58 | |
| Milan | IDENTIFY | 22:59 |
| opendevreview | Julia Kreger proposed openstack/bifrost master: add an OCI artifact registry https://review.opendev.org/c/openstack/bifrost/+/961388 | 22:59 |
| cardoe | sweet I was hoping that conductor would crash out when I gave it an incorrect inspection rules yaml file... | 23:27 |
| cardoe | Guess these yaks aren't gonna shave themselves. | 23:28 |
| *** Milan is now known as mfencik | 23:32 | |
| opendevreview | Doug Goldstein proposed openstack/ironic master: update inspection rules docs and code to the same order https://review.opendev.org/c/openstack/ironic/+/971264 | 23:50 |
| opendevreview | Doug Goldstein proposed openstack/ironic master: document additional inspection rules actions https://review.opendev.org/c/openstack/ironic/+/971265 | 23:50 |
| opendevreview | Doug Goldstein proposed openstack/ironic master: fix loading of built-in inspection rules https://review.opendev.org/c/openstack/ironic/+/971266 | 23:50 |
| cardoe | Very rough cause I gotta run | 23:50 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!