| JayF | Basically the same problem I had with abspath calls in the security patch | 00:13 |
|---|---|---|
| opendevreview | minwoo seo proposed openstack/ironic master: Add `api-call` action for ironic inspection rule https://review.opendev.org/c/openstack/ironic/+/946741 | 00:50 |
| cardoe | TheJulia: but do we really need to yield? | 01:49 |
| TheJulia | For some things, like power sync absolutely | 01:49 |
| TheJulia | Or places on those periodics that can be any delay | 01:59 |
| iurygregory | I'm not sure how I used IPE with Dell machines in the past, but turns out they have a different event reporting the metrics <facepalm> | 02:03 |
| iurygregory | now I need to add something to https://github.com/openstack/ironic-prometheus-exporter/blob/master/ironic_prometheus_exporter/messaging.py#L65 to handle hardware.idrac.metrics :D | 02:05 |
| iurygregory | or maybe change a bit the logic on ironic to consider "redfish" when using driver idrac with idrac-redfish interfaces... <thinking> | 02:09 |
| rpittau | good morning ironic! o/ | 07:02 |
| opendevreview | Riccardo Pittau proposed openstack/bifrost master: Fix python interpreter when installing in venv https://review.opendev.org/c/openstack/bifrost/+/949518 | 08:03 |
| opendevreview | Riccardo Pittau proposed openstack/bifrost master: [WIP] use Pyhon 3.12 on centos9 https://review.opendev.org/c/openstack/bifrost/+/949449 | 08:06 |
| opendevreview | Riccardo Pittau proposed openstack/bifrost master: [WIP] use Pyhon 3.12 on centos9 https://review.opendev.org/c/openstack/bifrost/+/949449 | 08:10 |
| opendevreview | Riccardo Pittau proposed openstack/python-ironicclient stable/2025.1: Stop using deprecated format_* from osc_utils https://review.opendev.org/c/openstack/python-ironicclient/+/949704 | 08:13 |
| opendevreview | Riccardo Pittau proposed openstack/python-ironicclient stable/2024.2: Stop using deprecated format_* from osc_utils https://review.opendev.org/c/openstack/python-ironicclient/+/949705 | 08:14 |
| opendevreview | Riccardo Pittau proposed openstack/python-ironicclient stable/2024.1: Stop using deprecated format_* from osc_utils https://review.opendev.org/c/openstack/python-ironicclient/+/949706 | 08:15 |
| opendevreview | Merged openstack/python-ironicclient master: Stop using deprecated format_* from osc_utils https://review.opendev.org/c/openstack/python-ironicclient/+/949654 | 08:26 |
| abongale | Good Morning Ironic! | 08:38 |
| opendevreview | Doug Goldstein proposed openstack/python-ironicclient master: fix: portgroup create with uuid for idempotency https://review.opendev.org/c/openstack/python-ironicclient/+/949032 | 09:27 |
| Sandzwerg[m] | Morning ironic. | 10:47 |
| Sandzwerg[m] | So since our ironic upgrade from xena to antelope we have issues with UEFI images that used to work before. For the SLES images the deployment fails with "failed to install a bootloader when deploying node .." When reading https://docs.openstack.org/ironic/latest/user/creating-images.html it sounds a bit to me as if ironic now handles the whole disk image as a partition image. The questions I have are: Why now? How to stop it? The | 11:01 |
| Sandzwerg[m] | nodes do have a deploy kernel & ramdisk assigned in the properties but my understanding so far is that these are mandatory? | 11:01 |
| opendevreview | Riccardo Pittau proposed openstack/bifrost master: [WIP] use Pyhon 3.12 on centos9 https://review.opendev.org/c/openstack/bifrost/+/949449 | 11:15 |
| cardoe | Sandzwerg[m]: you wanna use whole disk | 12:43 |
| cardoe | rpittau: should we cut a new python-ironicclient release for the osc-utils breakage? | 12:51 |
| rpittau | cardoe: there's already one https://review.opendev.org/c/openstack/releases/+/949471 | 13:10 |
| rpittau | I'm going to update that now | 13:10 |
| Sandzwerg[m] | cardoe: I thought we were. How could I confirm/check? | 13:15 |
| TheJulia | Sandzwerg[m]: deploy kernel/ramdisk set in the driver_info properties is separate from the image itself | 13:19 |
| opendevreview | Riccardo Pittau proposed openstack/bifrost master: Fix python interpreter when installing in venv https://review.opendev.org/c/openstack/bifrost/+/949518 | 13:20 |
| TheJulia | Sandzwerg[m]: the image your tryin to deploy, does it have a kernel and ramdisk value in the properties of the image? | 13:20 |
| opendevreview | Riccardo Pittau proposed openstack/bifrost master: [WIP] use Pyhon 3.12 on centos9 https://review.opendev.org/c/openstack/bifrost/+/949449 | 13:20 |
| TheJulia | Sandzwerg[m]: furthermore, what is the actual error under the hood, if it is partition image, it shouldn't have been broken, ideally you should be using whole disk images, but there is a point we can only do so much on partition images as well. | 13:23 |
| cardoe | What Julia said. | 13:26 |
| TheJulia | I seem to remember there is an additional sanity check somewhere | 13:26 |
| TheJulia | https://github.com/openstack/ironic-python-agent/blob/master/ironic_python_agent/extensions/image.py#L188-L340 | 13:30 |
| TheJulia | The other huge aspect to consider is nobody should be really trying to use grub-install or grub2-install on UEFI systems at this point and | 13:31 |
| TheJulia | really, we shouldn't have that sort of hardware shipping anymore | 13:31 |
| TheJulia | The *best* path for a partition iamge is EFI artifacts are present and are preserved | 13:32 |
| freemanboss[m] | TheJulia: I came across ironic GitHub (Openstack) repo awhile ago. Is the GitHub repo also part of the repo one can contribute too? | 13:37 |
| TheJulia | freemanboss[m]: The github repository is a mirror of the repository in gerrit | 13:38 |
| TheJulia | if you attempt to issue a pull request on github, the request gets closed | 13:39 |
| TheJulia | https://github.com/openstack/ironic/pulls?q=is%3Apr+is%3Aclosed | 13:39 |
| freemanboss[m] | TheJulia: yeah it's written there but I don't quite understand what mirror means? | 13:39 |
| TheJulia | freemanboss[m]: Every change which gets committed into gerrit which is our code review platform, gets replicated to github to serve as a backup copy | 13:40 |
| freemanboss[m] | TheJulia: ohh I understand now. Thank you | 13:41 |
| Sandzwerg[m] | TheJulia: no the image I'll try to deploy has no kernel or ramdisk value set. The issue I saw in the IPA is that it's trying to install the bootloader in partition XYZ but the partiton does not exit. This is after the whole image was written to disk with qemu-img (and as part of that there were multiple partitions created. I'd need to check but in principle it should be root, efi and config-drive) | 13:57 |
| Sandzwerg[m] | > The other huge aspect to consider is nobody should be really trying to use grub-install or grub2-install on UEFI systems at this point and | 13:58 |
| Sandzwerg[m] | hmm I'll check with the colleague if that might be the case | 13:58 |
| Sandzwerg[m] | We now also see issues with our ubuntu images, which still get deployed by ironic but then fails to find it's root disk so I'm not sure if that is related or not | 14:00 |
| TheJulia | did you update IPA itself? | 14:00 |
| Sandzwerg[m] | We updated it to, I think zed, last year because of all the CVEs | 14:02 |
| TheJulia | are these machines in bios mode or UEFI mode? Is there a /boot/efi folder in the image ? | 14:02 |
| Sandzwerg[m] | The machines are all in UEFI mode. I need to check the image but I would suspect a /boot/efi. Let me confirm real quick. | 14:03 |
| TheJulia | I suspect, at some point, whole agent logs might be needed to really understand what is going on and why | 14:03 |
| Sandzwerg[m] | I should be able to get some | 14:05 |
| Sandzwerg[m] | <TheJulia> "are these machines in bios..." <- I just confirmed, yes there is. | 14:14 |
| TheJulia | eww | 14:14 |
| TheJulia | okay | 14:14 |
| TheJulia | so, that sort of explains why not EFI artifacts | 14:15 |
| TheJulia | hmm, yeah, an agent log is going to be required to really grok it | 14:15 |
| Sandzwerg[m] | Sure. I'll get one. | 14:16 |
| Sandzwerg[m] | An upstream ubuntu cloud image does work as well. So there is something going on with out images | 14:17 |
| TheJulia | Has anyone seen requests ever issue a ReadTimeout exception but actually have the response payload already ? | 14:51 |
| JayF | Have I seen it with *requests*? No. Have I seen similar behavior with other http clients when network was broken in weird/packet-lossy/overfirewalled ways? yes. | 14:57 |
| TheJulia | yeah, same | 14:58 |
| JayF | Basically the behavior I observed was the client got all the data, but connection was never closed | 14:58 |
| TheJulia | yeah | 14:58 |
| JayF | almost like if you were using pipelining and the client disappeared ... except this is the wrong direction for that | 14:58 |
| TheJulia | I have seen some firewalls hijack and ignore connection:close | 14:58 |
| JayF | everytime I've seen this it went back to packet loss, asymetric routing, or really, really bad firewall rules | 14:58 |
| rpittau | JayF, TheJulia, dtantsur, now metal3 is using ironic container with Python 3.12, can we get metal3 integration job back to voting? https://review.opendev.org/c/openstack/ironic/+/949458 | 15:11 |
| dtantsur | done | 15:27 |
| rpittau | thanks! | 15:37 |
| opendevreview | Julia Kreger proposed openstack/ironic master: trivial: add missing exception ot agent code path docstrings https://review.opendev.org/c/openstack/ironic/+/949776 | 16:02 |
| shermanm[m] | putting together skeleton of a spec for snapshots, is it an issue if the new spec has the same name as a retired one? "snapshot-support.rst" | 16:04 |
| JayF | When proposing your spec, I'd remove the old, unimplemented one as part of the same change | 16:08 |
| JayF | and make reference to a previous, unimplemented spec in the intro of the new one | 16:08 |
| JayF | that's what I'd do at least | 16:08 |
| shermanm[m] | JayF: +1 | 16:09 |
| Sandzwerg[m] | My co-worker just found the image property "img_type: whole-disk" is that something that ironic expects? | 16:25 |
| opendevreview | Verification of a change to openstack/ironic master failed: Make metal3 job voting again https://review.opendev.org/c/openstack/ironic/+/949458 | 16:39 |
| TheJulia | Sandzwerg[m]: we evaluate the other image property fields to determine image type | 16:44 |
| keekz | hi all, i just got this error and i'm wondering if it's expected? @cardoe thinks maybe the owner (me) should also be able to set it? ``` openstack baremetal node set --no-automated-clean 7ca98881-bca5-4c82-9369-66eb36292a95 "baremetal:node:disable_cleaning": "role:admin and system_scope:all" requires a scope of ['system'], request was made with project scope. (HTTP 500)``` | 16:48 |
| TheJulia | keekz: the default policy is you have to be a system scoped admin to modify that field on a node | 16:49 |
| TheJulia | your likely a project scoped admin right now | 16:49 |
| cardoe | Yes | 16:49 |
| JayF | TheJulia: for trait based dynamic networking, do people deploying with ironic directly have the ability to communicate all this now? probably not? | 16:49 |
| JayF | if you want a project scoped admin to be able to do that, you have to make them owner | 16:50 |
| TheJulia | I don't remember if there is an owner exception | 16:50 |
| cardoe | Hrm. It should be | 16:50 |
| TheJulia | JayF: uhh, standalone users are free to post traits | 16:50 |
| JayF | TheJulia: I'm more saying; can it be done BEFORE the spec is implemented? | 16:51 |
| TheJulia | or at least, users using ironic directly can post traits, its likely just not well documented with examples | 16:51 |
| JayF | TheJulia: no, right? | 16:51 |
| JayF | that's what I'm trying to determine | 16:51 |
| JayF | scoping the problem to what combo of (standalone, neutron+ironic, neutron+ironic+nova) | 16:51 |
| JayF | I think it's (irrelevant, problem, problem) | 16:51 |
| TheJulia | I'm trying to remember how you post traits to the api right now | 16:51 |
| JayF | well I'm mainly just trying to ask about what's possible with dynamic networking | 16:52 |
| TheJulia | let me wrap up the bugfix i'm working on | 16:52 |
| JayF | before we're to the proposed trait based stuff | 16:52 |
| * JayF skips ahead in his edits | 16:52 | |
| * TheJulia runs unit tests | 16:54 | |
| TheJulia | so yes, irrelevent, problem, problem is right. | 16:55 |
| TheJulia | hmm, so allocation has a desired trait match, doesn't appear to save the desired traits. Nova posts it as values to instance_info https://github.com/openstack/nova/blob/master/nova/virt/ironic/patcher.py#L117-L137 | 16:59 |
| TheJulia | somewhere there are some notes on doing it manually... from like a raid on deploy demo | 16:59 |
| cardoe | So there does not seem to be an exception for owner. That’s what @keekz was asking. Should there be? | 17:00 |
| keekz | i think i see what happened but it's hard to show on irc | 17:01 |
| JayF | TheJulia: yeah, that's what my mental model was, I just wanted to make sure there wasn't some magic in the deploy process for standalone users to do some mapping (beyond the pre-associated VIF stuff in the draft spec) | 17:01 |
| keekz | https://gist.github.rackspace.com/nicholas-kuechler/33f8579ecb1fc4313a17351e2d580ece | 17:02 |
| TheJulia | cardoe: keekz: so great question, I guess the short answer is I don't know. We always viewed the overall deployment operator being the one to make that decision, but we've softened that to permit owners having more control over their nodes so I think it would be okay for the owner to have such access, and maybe that we should permit it with a policy change | 17:02 |
| JayF | keekz: internal only | 17:03 |
| JayF | TheJulia: cardoe: keekz: Think about this feature in context of the recent CVE. I would be -1 to such a default change. | 17:03 |
| keekz | maybe this https://gist.github.rackspace.com/nicholas-kuechler/2128950cbfb44a9481c6e50da2ec3dc3 | 17:03 |
| JayF | literally that hostname is unreachable | 17:04 |
| keekz | sorry too many githubs | 17:04 |
| keekz | let's try this one :) https://gist.github.com/nicholaskuechler/0402b48ac0619c4f1151661223d79f32 | 17:04 |
| TheJulia | whoaw | 17:09 |
| TheJulia | hold up | 17:09 |
| keekz | i also found this https://github.com/openstack/ironic/commit/ffecec3c557280eef82b60f0906ae20f821e10f5 but does https://github.com/openstack/ironic/blob/master/ironic/common/policy.py#L995 need `check_str=SYSTEM_OR_OWNER_READER` instead of system? | 17:09 |
| TheJulia | you need to focus on policy for baremetal:node:disable_cleaning and not baremetal:node:update | 17:09 |
| TheJulia | yeah | 17:10 |
| TheJulia | so | 17:10 |
| TheJulia | that change was due to someone overriding the policy and doing exactly what your wanting to do | 17:10 |
| TheJulia | it should be something like SYSTEM_OR_OWNER_ADMIN | 17:11 |
| TheJulia | READER equates to, in that whole thing as the reader role and you don't want to grant write privs to the reader role ;) | 17:11 |
| keekz | SYSTEM_OR_OWNER_MEMBER_AND_LESSEE_ADMIN is the only other one | 17:12 |
| TheJulia | not lessee admin | 17:12 |
| JayF | TheJulia: I disagree with that assessment, why do we think OWNER_ADMIN should be able to disable cleaning (in default policy)? | 17:12 |
| JayF | Especially when we just had a CVE around owners potentially being able to extract creds from the conductor /if cleaning is disabled/ | 17:12 |
| TheJulia | JayF: this would be the ?3rd? time we've had operators come in and ask | 17:13 |
| TheJulia | so... if operators feel owner admins should, that is strong feedback | 17:13 |
| TheJulia | They *can* just carry override policy, thats fine | 17:13 |
| JayF | There's a bias in that sample; we wouldn't hear from people unhappy with the more secure default | 17:13 |
| TheJulia | fair | 17:13 |
| JayF | the other question I'd have is have we ever changed default policy based on conf | 17:13 |
| JayF | because this seems like it should be easier than having to carry full custom policy | 17:13 |
| JayF | but config to change config over there seems awful | 17:14 |
| TheJulia | Could you elaborate on your question a little bit more ? | 17:14 |
| JayF | CONF.conductor.allow_node_owner_to_disable_cleaning | 17:14 |
| JayF | if that, or something better named, existed, it would allow an operator to meet this need *without* taking on the massive downstream burden of custom policy | 17:14 |
| JayF | that's the question I'm asking, if that makes sense to do as a middle ground | 17:15 |
| opendevreview | Julia Kreger proposed openstack/ironic master: Fix agent get_XXX_steps retries from being treated as not fresh agents https://review.opendev.org/c/openstack/ironic/+/949785 | 17:17 |
| TheJulia | oh, yeah, I'd be totally cool with that | 17:17 |
| TheJulia | I totally see your point | 17:18 |
| TheJulia | I also lean towards enabling oeprators, but yeah, owner-admins are sort of either the infra owner, or a delegated owner | 17:18 |
| TheJulia | and... things can get weird in that space as well with the venn diagram of the access model | 17:18 |
| TheJulia | dtantsur: remember that thing about how I said I had a bug where the agent was retrying and things were going sideways like two weeks ago, https://review.opendev.org/c/openstack/ironic/+/949785 :) | 17:19 |
| JayF | Right now my mental model is something kinda like | 17:19 |
| JayF | Owner-admin: owns everything except the BMC and cleaning processes | 17:20 |
| JayF | Lessee-admin: can only perform minor maintenance items | 17:20 |
| JayF | cleaning is just weird in that sometimes it both protects the user and the ironic operator | 17:20 |
| JayF | depending on your threat models and use cases | 17:20 |
| TheJulia | yeah | 17:22 |
| TheJulia | there is a whole threat model decision to be made there | 17:22 |
| TheJulia | and I think making a config option makes a ton of sense | 17:22 |
| JayF | honestly lessee is like, almost as valuable for r/o as anything else | 17:22 |
| JayF | well, and Ironic can't make that threat model decision | 17:22 |
| TheJulia | and I'm fairly sure we have a couple other places where logic slightly differes policy wise on a knob, that may also be a new policy to merge though | 17:22 |
| TheJulia | exactly, we can't | 17:23 |
| JayF | so defaulting to more secure but making easy outs for folks with less secure requirements (or more trust in node.owner) is cool | 17:23 |
| TheJulia | but operators can | 17:23 |
| TheJulia | and custom policies are awful in general | 17:23 |
| JayF | yes | 17:23 |
| JayF | custom policies are awful | 17:23 |
| JayF | like, it's GREAT that we have them | 17:23 |
| JayF | but it's almost worse for upgrades than patches | 17:23 |
| TheJulia | yeah | 17:23 |
| cardoe | So you guys tell me if we are doing it wrong. | 17:29 |
| cardoe | But system scope is a pretty big knob. | 17:29 |
| cardoe | We have most nodes in a baremetal project. @keekz is an admin there. | 17:30 |
| cardoe | We have a few nodes in another project. No permissions there. | 17:31 |
| cardoe | @keekz has his DC admin for those nodes on. | 17:32 |
| cardoe | Those nodes are consumed by nova-ironic and leased. | 17:33 |
| Sandzwerg[m] | <TheJulia> "Sandzwerg: we evaluate the other..." <- OK. We just thought it might play a part. But the image with that fails as well. Still trying to get logs. Sadly the log collection is running in some kind of error. Need to continue tomorrow | 17:34 |
| cardoe | I was under the impression that node owner admin role was like system scope for owned nodes. | 17:35 |
| cardoe | The issue I’ve seen is that granting humans system scope like the policy suggests has a much bigger blast radius than Ironic. | 17:37 |
| cardoe | JayF: That’s my only issue with your model | 17:38 |
| JayF | cardoe: Remember the context: Ironic was originally an admin-only API (system scope) | 17:39 |
| JayF | like, I think you're right that system scope is a big knob | 17:40 |
| JayF | using node.owner to allow project scope admins to do things is smart too | 17:40 |
| JayF | and we're talking about how to enable it; but you are in a world where literally keekz could file a ticket and get someone to touch the servers he's managing; in some worlds the node.owner might be a client paying them for hosting | 17:40 |
| JayF | so we *should enable* your use case through things like configurable defaults (as I suggested above, and would +2 a patch to that effect) | 17:41 |
| JayF | but we shouldn't assume your model by default | 17:41 |
| cardoe | Sure. So probably first would be to describe the two use cases. And which is the default? | 17:42 |
| cardoe | So that the knob could reference it | 17:43 |
| cardoe | Who is leasee in the case of owner being the client? | 17:44 |
| JayF | Default assumes a situation where resources have been *assigned* to a project, but that project is not assumed to have any meaningful administrative power (this is generally true for project-scoped things in other openstack projects, aiui). Real world cases that match this: multitenant baremetal hosting w/o Ironic, internal platform with no internal trust between tenants. | 17:45 |
| JayF | (speaking on owner) | 17:45 |
| JayF | That's my POV, it may or may not be aligned with others | 17:45 |
| JayF | cardoe: you assume one-layer of server renting :D | 17:45 |
| TheJulia | wow, lots to read | 17:46 |
| * TheJulia reads | 17:46 | |
| JayF | Default for lessee assumes a situation where the lessee is the rough equivalent of any user at the far end of a `openstack server create` command | 17:46 |
| JayF | which means that they really can't do much by default :) | 17:46 |
| JayF | cardoe: fwiw I think your use case is actually more common; but defaulting to more secure wins out IMO | 17:47 |
| TheJulia | so, lessee is the end user, but some folks use lessee as a delienated furhter step of access to loan out hardware to other users of the same ironic cluster | 17:47 |
| TheJulia | The use model is the MOC Alliance where each university has owner admin privs | 17:48 |
| TheJulia | however, for example, boston university may loan brown a few racks, so they make brown's project ID the lessee on the node | 17:48 |
| TheJulia | (easier to talk to things when you can use actual names from the case) | 17:49 |
| TheJulia | ultimately, they may have promised a month, but the owner remains with the ability to rip the nodes back and reprovision them, for example if a disaster has occured | 17:49 |
| JayF | having owner and lessee also | 17:50 |
| JayF | er, ignore that, was going to delete and reword lol | 17:50 |
| JayF | that is basically cardoe's use case | 17:51 |
| JayF | just with no other users in the DC | 17:51 |
| TheJulia | Sandzwerg[m]: ugh, lmk tomorrow and I can spend a little time looking since we shouldn't have broken anything, I do want to understand exactly what is going on | 17:51 |
| JayF | so he's more willing to cross the owner/system line, which like I said, probably common but I prefer defaulting to more secure | 17:51 |
| TheJulia | yeah, absolutely | 17:52 |
| TheJulia | in that case the system operator is the owner | 17:52 |
| JayF | maybe that's the actual name of the flag | 17:52 |
| JayF | or the gist of it | 17:53 |
| TheJulia | in the developed use case, the system operator is the MOC alliance as a collaborative, where they have multiple universities and some private/public entities who are also members who have hardware they share out to lesses | 17:53 |
| JayF | if you flip this on, we let owners do anything you can do system scope, when talking about stuff under /v1/nodes | 17:53 |
| JayF | that might be better than playing whackamole | 17:53 |
| JayF | either way, not something I'm personally going to work on although I'm happy to review and be a sounding board | 17:54 |
| cardoe | Right. That’s why I’m saying let’s craft a little use case story. And say the knob does this use case or that. | 17:54 |
| cardoe | Yep. Heard that yak into my van. | 17:54 |
| TheJulia | .... | 17:58 |
| * TheJulia hopes no candy is involved | 17:58 | |
| TheJulia | ;) | 17:58 |
| JayF | You can start the spec if you wanna do a larger thing, or put in the smaller knob, or do custom policy to get past the current step | 17:58 |
| Sandzwerg[m] | <TheJulia> "Sandzwerg: ugh, lmk tomorrow and..." <- I'll try to get logs tomorrow for sure :) | 17:59 |
| TheJulia | This sort of relates to soemthing else I was thinking, but it was much more on the entry path, in devstack we create nodes as system-admin, not owner-admin | 17:59 |
| cardoe | If ya gave me another layer that’s not system scoped | 18:03 |
| TheJulia | .... I only add layers with a bottle of Redbreast at the ready. | 18:04 |
| TheJulia | ;) | 18:04 |
| TheJulia | I do, really, think we need to bifrucate the logic and have two policies | 18:05 |
| * TheJulia wonders if there is anywhere else where that might need to be changed/set though | 18:05 | |
| TheJulia | The other challenge is policy loading happens super early, and making it setting dependent is super hard because because it is compiled at load time | 18:10 |
| TheJulia | and you also can't mutate it without a separate policy to fallback on | 18:10 |
| TheJulia | (Julia has clearly gone down this rabbit hole in the past.) | 18:10 |
| JayF | re: loading nodes in devstack as owner-admin: yeah, I'd like for that to be better but just haven't had a good reason to do it yet, which I feel like I probably need to have? | 18:14 |
| JayF | like it's disruptive enough that "just because I like it" seemed like a weak reason lol | 18:15 |
| * JayF going to stop looking at IRC for a while. Is adding a lot of detail to dynamic networking spec | 18:15 | |
| TheJulia | heh | 18:24 |
| TheJulia | okay | 18:24 |
| opendevreview | Riccardo Pittau proposed openstack/bifrost master: [WIP] use Pyhon 3.12 on centos9 https://review.opendev.org/c/openstack/bifrost/+/949449 | 18:28 |
| opendevreview | Riccardo Pittau proposed openstack/bifrost master: [WIP] use Pyhon 3.12 on centos9 https://review.opendev.org/c/openstack/bifrost/+/949449 | 18:33 |
| opendevreview | Riccardo Pittau proposed openstack/bifrost master: [WIP] use Pyhon 3.12 on centos9 https://review.opendev.org/c/openstack/bifrost/+/949449 | 18:34 |
| opendevreview | Riccardo Pittau proposed openstack/bifrost master: [WIP] use Pyhon 3.12 on centos9 https://review.opendev.org/c/openstack/bifrost/+/949449 | 18:35 |
| TheJulia | so is our grenade job broken? | 18:38 |
| JayF | I've seen only one failure and didn't look deeply. I know it was passing yesterday. | 18:39 |
| TheJulia | https://zuul.opendev.org/t/openstack/build/eadf0a9a248646099f99612b5d1c8e11 | 18:39 |
| TheJulia | 3 failures now | 18:39 |
| opendevreview | Riccardo Pittau proposed openstack/bifrost master: [WIP] use Pyhon 3.12 on centos9 https://review.opendev.org/c/openstack/bifrost/+/949449 | 18:42 |
| opendevreview | Riccardo Pittau proposed openstack/bifrost master: [WIP] use Pyhon 3.12 on centos9 https://review.opendev.org/c/openstack/bifrost/+/949449 | 18:42 |
| JayF | TheJulia: What's the use case behind the idea of ``attach_single_port`` in that spec? I can't find a use case for having specific ones for port/portgroup instead of just "attach" | 18:45 |
| * JayF omits them and puts a TODO there | 18:46 | |
| opendevreview | Verification of a change to openstack/ironic master failed: Make metal3 job voting again https://review.opendev.org/c/openstack/ironic/+/949458 | 18:57 |
| TheJulia | JayF: basically the idea of just attach, but as a singular option | 19:06 |
| JayF | wait, so is the implication here | 19:06 |
| JayF | that attach_ports would attach "N" matching ports to that network? | 19:06 |
| TheJulia | I was thinking attach_ports would try to attach everything | 19:07 |
| TheJulia | or attach n ports | 19:07 |
| TheJulia | single port being, hey, I just need this singular attachment, no bonds or anything | 19:08 |
| JayF | I'm thinking count as a top level | 19:11 |
| JayF | alongside action/filter is a good idea | 19:11 |
| JayF | I know you did the {min_,max_,}count stuff as an idea at filter level | 19:12 |
| JayF | but doing it top level makes it a lot cleaner I think | 19:12 |
| * JayF is going to propose that | 19:15 | |
| TheJulia | I'd have to re-read it all to have an opinion at this point | 19:16 |
| TheJulia | I sort of, in a fuzzy way, remember I wrote stuff | 19:16 |
| JayF | I'm going to write it up this way | 19:17 |
| opendevreview | Michael Sherman proposed openstack/ironic-specs master: Revive snapshot spec https://review.opendev.org/c/openstack/ironic-specs/+/949797 | 19:25 |
| TheJulia | so grenade last passed at 00:50 local time, doesn't look like the one neutron thing which has merged should impact it and devstack hasn't merged anything. | 20:06 |
| TheJulia | but https://review.opendev.org/c/openstack/grenade/+/949166 did merge | 20:07 |
| TheJulia | and that... likely is what is going on | 20:07 |
| JayF | Can you please comment on that change? :( | 20:09 |
| JayF | we got forgot | 20:09 |
| opendevreview | Jay Faulkner proposed openstack/ironic-specs master: Trait based port selection and dynamic portgroups https://review.opendev.org/c/openstack/ironic-specs/+/945642 | 20:22 |
| * JayF has been staring at that for 3 hours | 20:22 | |
| JayF | I hope it's better but who knows lol | 20:22 |
| JayF | (you do, it's you, reading this, go review it :D) | 20:22 |
| TheJulia | yeah, looks like they completely ignored ironic-grenade | 20:30 |
| TheJulia | thanks folks | 20:31 |
| opendevreview | Jay Faulkner proposed openstack/ironic master: [CI] Explicitly set how to deploy neutron in grenade https://review.opendev.org/c/openstack/ironic/+/949803 | 20:53 |
| JayF | TheJulia: I think ^ that may be all we need, I hope | 20:54 |
| JayF | just highlighting you so you don't do it too :D | 20:54 |
| TheJulia | we already inherit it via config https://3a3797ba578fbbb3d46d-901b165ad0359779dd04ea18f59d8bd6.ssl.cf1.rackcdn.com/openstack/0d107fcecb4345829561cda005e2c7eb/zuul-info/inventory.yaml | 20:56 |
| TheJulia | interestingly enough, its like the service catalog doesn't match | 20:56 |
| JayF | hm | 20:56 |
| TheJulia | Interestingly, we have q-metering enabled | 21:00 |
| TheJulia | I'm trying to see if I can reproduce locally, but just normal devstack first | 21:03 |
| okamitok[m] | Is there anyway to prioritize hardware selection based on Nova flavors? | 21:11 |
| okamitok[m] | For example you've got hardware in 2 locations that satisfy the requirements for the flavor during selection and you always want site A to be chosen first unless there are none available? | 21:11 |
| TheJulia | not that I can think of off the top of my head, since the locations should ideally be mapped into nova as populations in separate AZs | 21:23 |
| TheJulia | or regions | 21:23 |
| TheJulia | I'm getting some really weird failures, I guess it might be time to rebuild my devstack machine | 21:31 |
| -opendevstatus- NOTICE: Setuptools 80.7.0 broke python package installs for many affecting CI jobs. That release has been yanked and it should be safe to recheck failed changes. | 22:00 | |
| opendevreview | Adam McArthur proposed openstack/ironic master: api: Add schema for node firmware API https://review.opendev.org/c/openstack/ironic/+/945943 | 22:18 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!