Tuesday, 2026-04-28

opendevreviewMerged openstack/python-ironicclient stable/2024.2: Fix parallel initial version negotiation  https://review.opendev.org/c/openstack/python-ironicclient/+/97740802:08
opendevreviewMerged openstack/python-ironicclient stable/2025.1: Fix parallel initial version negotiation  https://review.opendev.org/c/openstack/python-ironicclient/+/97740702:09
*** hroy_ is now known as hroy03:06
clifgm ironic o/12:25
TheJuliagood morning folks12:51
Sandzwerg[m]Morning ironic13:14
Sandzwerg[m]What would be the easiest way for me to get a "standalone" ironic to add a node to test if redfish etc works? Devstack? Something else? We got access to new hardware but only via jumphost so adding it to our current cluster is not possible.13:16
dtantsurSandzwerg[m]: standalone - bifrost?13:16
dtantsurEven as a Metal3 person, I often use bifrost as a very easy way to get Ironic without literally anything else.13:17
Sandzwerg[m]Never used that but I'll take a look and ask dumb questions if I fail, thanks :D13:18
dtantsurlet's put it this way: it's as easy as openstack software even gets :D (which is not what normal humans generally call easy, but you're in this business, you know)13:19
dtantsurSandzwerg[m]: we also have this thing here for the specific case of testing nodes, but somewhat opinionated: https://github.com/openshift-metal3/bmctest13:20
dtantsurmaybe it's useful for you13:20
Sandzwerg[m]Sounds both useful. I'll dig some documentation 13:25
* TheJulia crosses her fingers hoping her long stopped devstack VM stack a new stack without any issues15:19
opendevreviewJay Faulkner proposed openstack/ironic-specs master: Add 2026.2 Work Items document  https://review.opendev.org/c/openstack/ironic-specs/+/98601816:10
dtantsurTheJulia: hey, rbac question. Is it intended that even project admins cannot read last_error by default?16:37
dtantsurThis looks like a usability nightmare16:37
JayFdtantsur: they are similarly blocked from node history then, I presume?16:38
TheJuliadepends on the modeling, because if it is an owner project admin, yes, if a lessee project admin, maybe not?!16:38
JayFlast_error can contain infrastructural things -- like hostnames -- that you wouldn't want exposed to external users16:38
TheJuliaThat ^^16:38
dtantsurYeah, but how do you use Ironic without it?16:39
JayFIn a standalone Ironic + multitenant model, you don't trust project owner w/infra information16:39
JayFdtantsur: support ticket -> system admin "plz2fix"16:39
dtantsurUgh. I'd never use a system like that.16:39
TheJuliaif your using ironic as a lessee, your node is deployed by that point16:39
JayFdtantsur: I don't disagree we should make it perhaps easy/obvious/well documented how to loosen that control16:39
dtantsurTheJulia: no lessees involved16:39
dtantsurJust a normal project admin, the way bifrost+keystone is installed16:39
TheJuliaI don't have the rbac context loaded from backup tapes right now, but I think we may have put a separate policy knob around that which could be tuned16:40
dtantsurYeah, but who would *not* want it tuned? "As an operator, I want to make sure failures are impossible to debug"? :)16:40
JayFdtantsur: node.owner is not, in all use cases, the infra operator16:41
JayFthat's the reason the knob has to exist16:41
TheJuliaI mean, it all depends on the security posture and honestly the ironic user was always modeled as more the system scoped users with graduated access down to the project scoped admin16:41
TheJuliathis goes to the root and response of the original openstack rbac bug16:41
TheJuliaand truthfully, all we can do make a reasonable attempt and pivot with feedback when we get it16:42
JayFI'll note I am not a user of this use case currently; but if my downstream ever stopped use of Nova we'd almost certainly move to this model with these expectations :/16:42
TheJuliathen we adjust, its not a big deal16:42
dtantsurI understand the reasoning, but ironic is not usable without access to last_error or service logs16:42
TheJuliadmitry, I hear you but your maybe not understanding my response16:43
TheJuliaWe can change, that is okay16:43
TheJuliabeating up the issue over a shift in use expectations doesn't help16:43
JayFHaving an easy knob to turn doesn't even mean it has to default in the way I want it to16:43
TheJuliathat is also another possibility, based on the discussion and the embracing of project scoped admins, I'd likely revisit that and make it more towards what dmitry is saying16:44
JayFbut I also think it's sad to have the expectation that without the ability to troubleshoot directly, Ironic node ownership is not a useful item. I think that reliability expectation is different per environment16:44
* TheJulia entirely shifts gears now16:44
dtantsurJayF: well, it's useful until something goes wrong, even if something is as trivial as a bad checksum16:45
TheJuliahttps://github.com/openstack/ironic/blob/master/ironic/common/policy.py#L538-L54516:45
TheJuliaso, either there is a bug someplace, or there is a larger issue16:45
TheJuliawhat roles does the user have ?16:45
JayFdtantsur: this honestly is kinda interesting in context of the maintenance discussion in the PTG: we *should* have some way to define what errors are infra (5xx style errors) vs usage/image/permissions (4xx/3xx)16:46
dtantsurtrue16:46
JayFin the same way we have ideas of maintenance which might operate at different levels16:46
* dtantsur figures out the roles16:46
TheJuliahold on16:46
TheJuliaPlease go back to my question, what roles does the user have16:46
dtantsurTrying, trying16:46
TheJuliabecause it should be visible to an owner16:46
dtantsurBloody openstack CLI, I cannot remember so many UUIDs.....16:47
JayFowner/lessee being where that split is by default does make sense16:47
JayFfor the higher security case bifurcating into user v system errors is almost required to have sensible error reporting in bad image cases as pointed out by dmitry16:47
TheJuliaI'm sort of wondering if dmitry is using an admin roled user which is somehow missing reader16:47
TheJuliabut... things would look super weird there because its expected in the model16:47
* TheJulia has no idea how that would *look* API surface wise16:48
dtantsurTheJulia: bingo. Bifrost only creates "admin" roles.16:48
dtantsurI guess the roles are not hierarchical, are they?16:48
TheJuliaAFAIK they are supposed to be16:48
TheJuliathat sounds like a keystone bug?!16:48
TheJuliaBut maybe... devstack masks over it16:49
TheJuliaor... maybe... uhhhhh16:49
* dtantsur dies inside16:49
* TheJulia joins dtantsur16:49
TheJuliaIs it beer'o'clock yet?16:49
TheJuliaAnyhow, seriously speaking, in any proper environment, admin is expected to have "member", and "reader" as well16:50
TheJuliait should be heiarchical, but if you have custom handling like maybe what we ended up with bifrost's "keystone" logic, maybe that gets bypassed. Honestly, I don't know, I know in devstack the last time I looked it was doing a pattern from the pre-bake heiarchical changes so maybe that got kept which is horrific16:51
dtantsurSo, a bifrost bug? But when can I list my nodes then? :)16:51
dtantsurs/when/why/16:51
dtantsur(I'm also surprised I can create/delete users without having the system scope.. I don't understand keystone)16:52
TheJuliaso, can you verify your roles from keystone itself?16:52
dtantsurIf you tell me how..16:52
TheJuliayeah, its all in that project's scope16:52
TheJuliagreat question16:53
TheJuliauhhhhhh openstack role list? maybe16:53
opendevreviewVictor proposed openstack/ironic master: Truncate node history event to avoid DB column overflow  https://review.opendev.org/c/openstack/ironic/+/98139916:53
dtantsurTheJulia: it's all roles, not just mine16:53
TheJuliaopenstack role assignment list --user <user-name-or-id> --effective --names16:54
TheJuliathat is what google is suggesting and I do believe that is heading in the right direction because you have to ask keystone for the role assignment data16:54
dtantsurWell, I have all roles on my project: admin, manager, member, reader16:54
TheJuliayou mean to your user in the project? 16:55
dtantsuryep16:55
TheJuliaOkay, so your a system scoped admin, manager, member, reader16:56
TheJuliathat explains why list gets nodes16:56
TheJuliaIf you look at the node itself, is the owner set to the project's uuid ?16:56
dtantsurHmmhmmm, I have a bit too many projects here16:57
dtantsurwhy do I have both "baremetal" and "admin"?16:57
dtantsurIt may be a bifrost stuff-up in the end16:58
TheJuliayeah16:58
TheJuliaand pre-baked defaults16:58
dtantsurIt still confusing why I, being a super admin that can read anything, cannot read last_error :)17:00
dtantsurTheJulia: wasn't https://opendev.org/openstack/bifrost/src/branch/master/playbooks/roles/bifrost-ironic-install/tasks/keystone_setup.yml#L159-L167 supposed to create me a role on the baremetal project?17:01
TheJuliasuper admin is system scope17:01
dtantsurah, wait, it's a normal user17:01
TheJuliaoh yeah, so, thats why17:01
TheJuliaits a mismatched state17:01
TheJuliaat least, that is my gut feeling17:02
TheJuliaso, bifrost bug17:02
dtantsurMmm, wait. No.17:02
TheJuliaI bet if we change that to grant member, reader, it will behave exactly as desired17:02
dtantsurDo you know if I can understand which user and project I'm using now? Through CLI?17:02
TheJuliaI just don't have that context on my mind at the moment17:04
TheJuliathere is a way17:04
TheJuliajust I don't know it. If you look at the response headers, I think X-Project-ID gets included in the response17:04
TheJuliaI.. Think17:04
dtantsurI think we're back to square one, unfortunately. I was looking at a wrong user. I must be bifrost_user, and I have all roles on project baremetal.17:04
TheJuliathis is all so blurry to me at this point that I just don't remember how the middleware is doing that 17:04
dtantsurMy nodes are owned by project baremetal. But I cannot read their last_error.17:05
TheJuliadebug log and spit out the oslo_policy logging  by editing it and comparing on the backend because its about what the server gets as effective on the backend17:06
dtantsurI seriously wonder how some of our policy.check invokations even work. We don't pass a node there, how is node.owner read?17:19
dtantsurI have a gut feeling that we need to replace many cases of direct policy.check accesses with our check_owner_policy helper17:20
dtantsurI'll file a bug, I cannot spend more time on this, unfortunately17:20
JayFcardoe: https://review.opendev.org/c/openstack/ironic/+/984663/2#message-dd27186859190048de5d6e7b6c76090889384339 this is a trivial thing to fix if you get a sec17:23
dtantsurOhhhhhhhh, uhhhhh, lol17:24
dtantsurThe policy works when "owner" is included in --fields but not without it17:24
opendevreviewMichal Nasiadka proposed openstack/bifrost master: [WIP] Experimental support for ARM64 hosts on Debian  https://review.opendev.org/c/openstack/bifrost/+/92005717:24
cardoeJayF: well we didn't backport the original addition of the API so I don't think we're gonna backport that.17:24
dtantsurhttps://bugs.launchpad.net/ironic/+bug/215057317:26
JayFcardoe: ...huh? Oooooh. this bug only impacts runbooks "v2" style runbooks?17:48
JayFdtantsur: lolsob17:49
JayFthat's a hilariously sad bug17:49
cardoeJayF: yes. This was to address your or dtantsur's feedback on the "v2" runbooks but it had already gotten a couple of +2 and we wanted to land another DB change on top of it so I said I'd make changes in a follow on.17:50
JayFcid: https://review.opendev.org/c/openstack/ironic/+/984663/2#message-dd27186859190048de5d6e7b6c76090889384339 you might wanna re-evaluate your vote based on what cardoe says17:50
JayFcardoe: we might not approve it r/n just so it doesn't go from 0 review -> landed in like 5 minutes, but if nobody else does, self-approve tomorrow or poke me about it?17:51
cid:D17:51
cidSo true and we missed missed it.17:51
JayFme and you are anchored to when runbooks v1 was implemented17:52
opendevreviewMerged openstack/ironic-tempest-plugin master: Allow removing volume connectors on some states  https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/98185918:29
cardoeJayF: you got access to openstack-exporter right?18:47
cardoeWhat about the helm-charts?18:47
JayFopenstack-exporter's only active maintainer is Adam MacArthur for my team. For some definition of "Active" (Adam is a PhD student with a plate that is almost always full -- but if you get someone in the community reviewing patches they have a path to maintainership)18:58
cardoeWell I'm interested in the helm-charts which are an adjacent repo.20:40
cardoekeekz from my team is gonna fork it to start fixing issues.20:41
JayFwe don't use that and have no work in it20:46
JayFI'm not sure if Adam got repo or org keys but I'd generally feel uncomfy asking him to use them on a repo we don't operate on anyway20:46
cardoeWell I'd be happy to propose merging the helm-chart into the main repo and publishing it with code releases.20:51
cardoeOr we can just fork it and go from there.20:51
cardoeThe separate repo used to be a thing when you couldn't use OCI for charts since they used a repo for the chart metadata.20:51
*** mdfr8 is now known as mdfr21:10
JayFyeah again the ideal path for that to take is to get active in that repo so we can get >1 maintainer21:18
JayFI doubt Adam has helm experience, but imbq21:18
JayF**imbw21:18
keekzboth repos are in the same org (openstack-exporter)21:20
keekzis this an 'openstack' project? if so, i feel like it should be in the openstack org, so we have clear ownership etc :)21:21
JayFIt's not an openstack project. It's a github org (openstack-exporter) with one repo that Adam on my team (openstack-exporter/openstack-exporter) has been trying to improve.21:21
JayFI wouldn't be -1 to a move into openstack; but there is a community there that we are trying to reignite through actually reviewing and landing the code21:22
JayFand from my PoV that's just moving deckchairs around until we actually get the project in a decent state21:22
keekzyeah i'd make prs to the helm charts if they'd actually get reviewed. i was under the impression that entire org/project was dead since other folks have already forked it and improved it21:23
JayFWe advocated and got Adam admin access at some level (unsure if repo or org)21:23
JayFbut as I indicated earlier; I will not be one to push Adam to use that access in a repo he's not even touching21:23
JayFthe best route is to get reviewing in that repo, talk to Adam (sharpz7) there, and get yourself as a maintainer too21:24
JayFwe are desparate for more hands right now, Adam is highly part time and I am not gonna smear his work there any thinner21:24
JayFkeekz: cardoe: noting this conversation is likely better held in that github org -- please post something there and ping me+adam if needed (I'm jayofdoom over there)21:29
cardoeI was tabbed out.21:30
cardoekeekz: throw a PR out there21:30
keekzi will have kiro raise a pr and we'll what happens :) my change is going to be fairly small, the helm chart assumes it creates/owns the secret, but we need to supply our own secret and have it use that instead, so it should be optional.21:33
JayFTo be clear: I do not think Adam is reviewing helm charts nor has the knowledge base to do so.21:34
keekzyeah that's fine, i understand.21:34
JayFwe are ... walking a line here21:34
JayFtrying not to just trample the project, build some momentum with multiple contributors21:34
JayFwithout pissing off the old maintainer who retains admin21:35
keekzit's fine, i think we mostly thought it was abandoned21:35
JayFit was, honestly21:36
keekzat least we know at least one repo in that org has activity 👍 21:36
JayFit took us 6 months and a threatened fork to get keys to the repo21:36
TheJuliabrraaaains?21:38
cardoenone here21:39
cardoefix node_periodic() to not completely die on exception21:39
cardoeTheJulia: how's the wife?21:39
TheJuliaDoing pretty good, although some swelling and hating the world is naturally occuring21:39
TheJuliaI need to go get her more ice cream at some point before dinner time21:40

Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!