| rpittau | good morning ironic! o/ | 08:16 |
|---|---|---|
| opendevreview | Merged openstack/ironic-prometheus-exporter master: [codespell] Adding Tox Target for Codespell https://review.opendev.org/c/openstack/ironic-prometheus-exporter/+/906778 | 08:49 |
| opendevreview | Mohammed Boukhalfa proposed openstack/sushy-tools master: Add fake_ipa inspection, lookup and heartbeater to fake system https://review.opendev.org/c/openstack/sushy-tools/+/875366 | 09:34 |
| iurygregory | good morning | 10:52 |
| opendevreview | Dmitry Tantsur proposed openstack/ironic master: [WIP] Add inspection PXE filter https://review.opendev.org/c/openstack/ironic/+/907991 | 11:17 |
| opendevreview | Mohammed Boukhalfa proposed openstack/sushy-tools master: Add fake_ipa inspection, lookup and heartbeater to fake system https://review.opendev.org/c/openstack/sushy-tools/+/875366 | 12:41 |
| frickler | JayF: rpittau: iurygregory: I updated https://review.opendev.org/c/openstack/releases/+/906560 pls have another look (yoga-eom) | 12:53 |
| iurygregory | frickler, ack | 12:53 |
| iurygregory | +1 | 13:00 |
| adam-metal3 | Hey Ironic, quick question is virtual media boot expected to work with sushy-tools + OpenStack in this config https://docs.openstack.org/sushy-tools/latest/user/dynamic-emulator.html#systems-resource-driver-openstack ? | 13:11 |
| dtantsur | adam-metal3: https://review.opendev.org/c/openstack/sushy-tools/+/906768/ | 14:13 |
| TheJulia | good morning | 14:13 |
| dtantsur | morning TheJulia | 14:13 |
| adam-metal3 | thanks dtantsur | 14:14 |
| SvenKieske | o/ | 14:21 |
| SvenKieske | JayF or maybe someone else (don't know Julia Kregers nick): where these comments never resolved? https://review.opendev.org/c/openstack/ironic/+/907148?tab=comments we try to make sense of them over in #openstack-kolla on how to best implement this for actual prod deployments :) thanks for any pointers. | 14:23 |
| dtantsur | the nick is TheJulia | 14:23 |
| TheJulia | o/ | 14:23 |
| SvenKieske | I'm still following the maze of links in the comments there, so maybe I can figure this out myself, but any pointers possibly would greatly speed up the process I guess.. :) | 14:23 |
| SvenKieske | ty :) now I remember having seen that nick already in the past! | 14:24 |
| TheJulia | so, they were, I just failed to click done on them | 14:24 |
| TheJulia | those were all on patchset 3 | 14:24 |
| SvenKieske | ah nice, for reference, our current WIP effort can be found here: https://review.opendev.org/c/openstack/kolla-ansible/+/908007 does that make sense to do this way? (a very broad question I recognize) | 14:25 |
| TheJulia | SvenKieske: yes, that should work. | 14:25 |
| SvenKieske | But I just don't want to open the permissions more than we need to, we just recently introduced a slip up in handling service role in another project, so I want to double check we are doing the secure thing(TM) | 14:26 |
| TheJulia | SvenKieske: the net result is an account in the service project with the service role has elevatda ccess then | 14:26 |
| TheJulia | That service project doesn't *have* to be service, you can change that, but the default for most tools/deployments just seems to be "service" | 14:27 |
| SvenKieske | yes, but that would be system-scoped, right? I was wondering if I can't somehow configure an allowlist of only necessary projects? I don't know if this is possible. because afaik not each openstack service needs access to ironic. | 14:27 |
| TheJulia | no | 14:27 |
| TheJulia | so... | 14:28 |
| TheJulia | if you have a service project, it is inherently project scoped | 14:28 |
| TheJulia | it is just a special project name | 14:28 |
| TheJulia | unfortunately, with the stock policy code, it is not possible to configure a project allow list | 14:28 |
| SvenKieske | ah, I did know the latter but didn't know the former (that it's inherently project scoped) | 14:28 |
| TheJulia | I mean, you could create a system scoped "service" role'ed user | 14:29 |
| SvenKieske | I guess I need to read up more on the keystone docs, because we still have some changes in the works to implement service roles for all services.. | 14:29 |
| TheJulia | and that could also work, but... yeah | 14:29 |
| TheJulia | :) | 14:29 |
| TheJulia | SvenKieske: I think kolla has it already, tbh | 14:29 |
| SvenKieske | thank you so far | 14:29 |
| TheJulia | well, the service project | 14:30 |
| TheJulia | you can just grant "service" to accounts in the "service" project | 14:30 |
| SvenKieske | well yeah, but not all users have the service role, if you're interested this is still also WIP: https://review.opendev.org/c/openstack/kolla-ansible/+/815577 | 14:30 |
| SvenKieske | yeah, that's the missing piece currently | 14:30 |
| SvenKieske | maybe we should also add some tests for this of our own | 14:31 |
| TheJulia | likely a good idea | 14:31 |
| TheJulia | so, not all projects support the service role, fwiw | 14:31 |
| TheJulia | It is sort of something still being implemented in a number of places | 14:32 |
| TheJulia | *but* we support it at this point | 14:32 |
| TheJulia | and realistically you can also assembled everything a couple different ways, just use of a service project is sort of the "most common path" | 14:32 |
| TheJulia | given that is the way devstack does it, creates the accounts with admin, service role | 14:33 |
| * TheJulia is still trying to wake up | 14:35 | |
| opendevreview | OpenStack Release Bot proposed openstack/bifrost master: reno: Update master for unmaintained/yoga https://review.opendev.org/c/openstack/bifrost/+/908116 | 15:02 |
| opendevreview | OpenStack Release Bot proposed openstack/ironic-inspector master: reno: Update master for unmaintained/yoga https://review.opendev.org/c/openstack/ironic-inspector/+/908118 | 15:02 |
| opendevreview | OpenStack Release Bot proposed openstack/ironic-prometheus-exporter master: reno: Update master for unmaintained/yoga https://review.opendev.org/c/openstack/ironic-prometheus-exporter/+/908121 | 15:03 |
| opendevreview | OpenStack Release Bot proposed openstack/ironic-python-agent-builder master: reno: Update master for unmaintained/yoga https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/908123 | 15:03 |
| opendevreview | OpenStack Release Bot proposed openstack/ironic-python-agent master: reno: Update master for unmaintained/yoga https://review.opendev.org/c/openstack/ironic-python-agent/+/908125 | 15:03 |
| opendevreview | OpenStack Release Bot proposed openstack/ironic-ui master: reno: Update master for unmaintained/yoga https://review.opendev.org/c/openstack/ironic-ui/+/908127 | 15:04 |
| opendevreview | OpenStack Release Bot proposed openstack/ironic master: reno: Update master for unmaintained/yoga https://review.opendev.org/c/openstack/ironic/+/908129 | 15:04 |
| opendevreview | OpenStack Release Bot proposed openstack/metalsmith master: reno: Update master for unmaintained/yoga https://review.opendev.org/c/openstack/metalsmith/+/908131 | 15:04 |
| TheJulia | Well, that is new | 15:04 |
| opendevreview | OpenStack Release Bot proposed openstack/networking-baremetal master: reno: Update master for unmaintained/yoga https://review.opendev.org/c/openstack/networking-baremetal/+/908133 | 15:04 |
| opendevreview | OpenStack Release Bot proposed openstack/networking-generic-switch master: reno: Update master for unmaintained/yoga https://review.opendev.org/c/openstack/networking-generic-switch/+/908135 | 15:05 |
| opendevreview | OpenStack Release Bot proposed openstack/python-ironic-inspector-client master: reno: Update master for unmaintained/yoga https://review.opendev.org/c/openstack/python-ironic-inspector-client/+/908137 | 15:05 |
| opendevreview | OpenStack Release Bot proposed openstack/python-ironicclient master: reno: Update master for unmaintained/yoga https://review.opendev.org/c/openstack/python-ironicclient/+/908139 | 15:05 |
| opendevreview | OpenStack Release Bot proposed openstack/sushy master: reno: Update master for unmaintained/yoga https://review.opendev.org/c/openstack/sushy/+/908141 | 15:05 |
| bbezak | Hi Ironic!. I've been playing a bit with recent rbac changes in kolla-ansible context. I'm wondering if that is correct - that is project scoped admin role can't list drivers for example | 15:15 |
| bbezak | "baremetal:driver:get": "(role:reader and system_scope:all) or (role:service and system_scope:all) or rule:service_role" requires a scope of ['system'], request was made with project scope. (HTTP 500) | 15:15 |
| JayF | Yes. | 15:16 |
| TheJulia | SvenKieske: o/ Hi, looks like your not the only one | 15:16 |
| JayF | Yeah, the idea that it requires a scope of system is the problem. Only thing that project admins can see, generally, are things that belong to their project (e.g. nodes with lessee or owner set to project) | 15:16 |
| TheJulia | bbezak: yes, that was the consensus the project reached long ago | 15:16 |
| * TheJulia shortened her answer based upon JayF's reply | 15:17 | |
| TheJulia | allocations, volume data, ports which also related. As long as we can identify an associated node | 15:17 |
| JayF | I find RBAC easier to understand when I put it in a public cloud context. | 15:17 |
| TheJulia | ++ | 15:18 |
| JayF | You wouldn't want a customer admin (project admin) to see/configure things that could impact other customers (projects) | 15:18 |
| JayF | You want those capabilities at a level above the project (system scope) | 15:18 |
| bbezak | makes sense. however it looks that only ironic left in the field with system scope approach (except keystone) | 15:19 |
| JayF | Well, if you think a little historically: Ironic used to be an admin-only API | 15:19 |
| TheJulia | Another item to consider as context, is Ironic implemented system scope very on since ironic was basically an admin-only service, and the very early feedback we got was exceptionally positive from multiple operators who basically told us "omg, thank you! this makes it so much easier for us to delineate and better appropriately restrict access" | 15:19 |
| JayF | ++++ yes exactly | 15:19 |
| JayF | Julia and I basically completing each others sentences | 15:19 |
| bbezak | :) | 15:19 |
| TheJulia | after we got that feedback, the projects which had a heavier lift for system scoped lobbied and convinced the TC to abandon system scope | 15:20 |
| bbezak | thx for context | 15:20 |
| JayF | I'll note | 15:20 |
| JayF | you and SvenKieske make two people who have been confused by this | 15:21 |
| JayF | please help us understand how to better document this | 15:21 |
| TheJulia | ... I don't *really* like the idea, but if folks would be so interested, I might be willing to take on adding "admin" version of the service patch as a easy to use knob of some sort | 15:21 |
| TheJulia | ++ | 15:21 |
| JayF | we have been neck-deep in this for so long, sometimes it's hard to know how to turn it | 15:21 |
| JayF | I would be like. -0.5 to that | 15:21 |
| JayF | there needs to be a compelling use case | 15:21 |
| TheJulia | agree completely | 15:21 |
| JayF | and I don't see it | 15:21 |
| TheJulia | I do need to go back and highlight "how to make things visible" | 15:22 |
| TheJulia | going back to the discussion with adamcarthur5 last week | 15:22 |
| JayF | honestly just an RBAC doc page, including a FAQ: "I am a project scoped admin can I can't see X!?" | 15:22 |
| TheJulia | Yeah, I was thinking most likely on troubleshooting | 15:23 |
| TheJulia | wanted to see what adam posted first, though | 15:23 |
| JayF | he is having a battle with devstack | 15:23 |
| JayF | basically overnight it's just ... disappearing | 15:23 |
| JayF | I think some automation on the server image might be screwing things up at logrotate time | 15:23 |
| TheJulia | ugh | 15:24 |
| JayF | Pretty much my reaction. | 15:24 |
| SvenKieske | I'm currently also struggling with nova and cinder, tbf nova seems to have the most docs on rbac and service tokens after keystone maybe. but cinder basically says "you must configure access with service tokens"..yeah cool, but _how_ ? and then it just refers to OSSA-2023-003 launchpad which has hundreds of comments.. | 15:25 |
| TheJulia | idea for a very rainy day, an endpoint to walk the entire history table and return everything | 15:25 |
| SvenKieske | sorry for the rant :( | 15:25 |
| opendevreview | Merged openstack/ironic-python-agent-builder master: reno: Update master for unmaintained/yoga https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/908123 | 15:26 |
| TheJulia | yeah, service token refers to using a service scoped user *plus* enabling the client to embed the user data along with it | 15:26 |
| SvenKieske | actually there seem to be decent docs here: https://docs.openstack.org/cinder/latest/configuration/block-storage/service-token.html#send-service-token | 15:26 |
| TheJulia | so basically you get a special request which has both the original user token and the service token to take an action | 15:26 |
| opendevreview | Merged openstack/ironic-prometheus-exporter master: reno: Update master for unmaintained/yoga https://review.opendev.org/c/openstack/ironic-prometheus-exporter/+/908121 | 15:27 |
| TheJulia | the only thing which *requires* that, afaik, is interactions with Cinder on volumes | 15:27 |
| TheJulia | and you can see the client option in the example | 15:27 |
| opendevreview | Merged openstack/bifrost master: reno: Update master for unmaintained/yoga https://review.opendev.org/c/openstack/bifrost/+/908116 | 15:28 |
| * JayF takes off TC and PTL hats | 15:30 | |
| JayF | if I were deploying this, I'd ignore that service scope exists and use system scoped users | 15:30 |
| JayF | the difference is not meaningful in most cases | 15:30 |
| JayF | and if it is meaningful, you'd need a decoder ring to figure out what the difference is | 15:30 |
| * JayF puts hats back on | 15:30 | |
| * dtantsur still hardly understands this difference | 15:31 | |
| opendevreview | Merged openstack/metalsmith master: reno: Update master for unmaintained/yoga https://review.opendev.org/c/openstack/metalsmith/+/908131 | 15:31 |
| SvenKieske | yeah I mean, to do the thing, like "oh wait, this user token is invalid by know, we can't therefore rollback this action based on the users token alone, but there is a service token sent with it, which is valid so it's fine" is not really a good design.. | 15:32 |
| SvenKieske | now* | 15:33 |
| opendevreview | Merged openstack/python-ironicclient master: reno: Update master for unmaintained/yoga https://review.opendev.org/c/openstack/python-ironicclient/+/908139 | 15:33 |
| JayF | I don't want to make value judgements about he design or implementation. I suspect the real answer to gaps are too much work and too few hands. | 15:33 |
| SvenKieske | I surely understand where it comes from, being backwards compatible and you have users in the field who need to be taken care of and all..still | 15:34 |
| JayF | just trying to figure out how to navigate the word we have :D | 15:34 |
| opendevreview | Merged openstack/ironic-inspector master: reno: Update master for unmaintained/yoga https://review.opendev.org/c/openstack/ironic-inspector/+/908118 | 15:34 |
| TheJulia | fun likely super low hanging fruit bug: https://bugs.launchpad.net/python-ironicclient/+bug/2052527 | 15:34 |
| opendevreview | Merged openstack/python-ironic-inspector-client master: reno: Update master for unmaintained/yoga https://review.opendev.org/c/openstack/python-ironic-inspector-client/+/908137 | 15:35 |
| SvenKieske | more/clear docs and good defaults go a long way. I mean if we implement this wrong in a upstream deployment project which is rather familiar with all the projects, I don't want to know what users are doing on their own when their not that familiar with everything. | 15:35 |
| opendevreview | Merged openstack/networking-generic-switch master: reno: Update master for unmaintained/yoga https://review.opendev.org/c/openstack/networking-generic-switch/+/908135 | 15:35 |
| opendevreview | Merged openstack/ironic-python-agent master: reno: Update master for unmaintained/yoga https://review.opendev.org/c/openstack/ironic-python-agent/+/908125 | 15:36 |
| TheJulia | SvenKieske: when you say wrong, what makes you think you went on the wrong path to begin with? | 15:36 |
| opendevreview | Merged openstack/sushy master: reno: Update master for unmaintained/yoga https://review.opendev.org/c/openstack/sushy/+/908141 | 15:36 |
| TheJulia | sorry for the merge notices folks, I approved all of the unmaintained patches in one sweep | 15:36 |
| dtantsur | ++ it's good when things merge :) | 15:37 |
| JayF | TheJulia: yeah we both did, at some point I started seeing your approvals as I was approving, so some # of those patches have approvals within seconds of each other | 15:38 |
| opendevreview | Merged openstack/networking-baremetal master: reno: Update master for unmaintained/yoga https://review.opendev.org/c/openstack/networking-baremetal/+/908133 | 15:38 |
| JayF | it's pretty excellent | 15:38 |
| bbezak | so rbac_service_role_elevated_access=true looks sane for kolla-ansible's nova-compute-ironic service for example - not to create system scoped service user only for ironic needs that is. currently ironic user is a admin role - I'm adding it to be service role too | 15:39 |
| bbezak | However uber admin user of kolla-ansible/kayobe - which needs to do some operations on baremetals will need to be at least (probably) system scoped member. | 15:39 |
| bbezak | but I'll play around more | 15:39 |
| JayF | So what I'd suggest | 15:40 |
| JayF | if you're diving into RBAC | 15:40 |
| JayF | have a project defined where you add the nodes into | 15:40 |
| SvenKieske | TheJulia: Well I currently try to fix https://bugs.launchpad.net/kolla-ansible/+bug/2049762 which is the aftermath of https://security.openstack.org/ossa/OSSA-2023-003.html | https://bugs.launchpad.net/nova/+bug/2004555 | 15:40 |
| JayF | so whatever project creates those nodes, they'll have owner on those nodes | 15:40 |
| * JayF assumes K-A registers notes which may not be falic | 15:40 | |
| JayF | s/falic/valid/ | 15:40 |
| TheJulia | and admins will then have admin rights on the nodes :) | 15:40 |
| TheJulia | and members will have member rights | 15:41 |
| TheJulia | and the world will be happy! Or Julia will be sad. | 15:41 |
| SvenKieske | our core maintainer got this wrong, and I and nobody else noticed during review..so clearly there is room for improvement in our understanding :) | 15:41 |
| JayF | Bluntly, I had a conversation with TheJulia in the last two weeks and learned RBAC stuff | 15:41 |
| TheJulia | ahh, and it all still sort of worked because of the deprecated policies. | 15:41 |
| TheJulia | sorry JayF, hopefully I didn't break your brain... too much | 15:41 |
| JayF | there's a lot to understand and if you don't work closely with it it's hard to keep the context | 15:41 |
| bbezak | I'm not sure if we could force all possible muiti-tenant users to add all nodes to one project | 15:41 |
| JayF | TheJulia: remember my "SERVICE ROLE IS JUST A STICKY NOTE!?" breakage. | 15:42 |
| JayF | lol | 15:42 |
| JayF | you cracked my brain like an egg! | 15:42 |
| TheJulia | And the whole thing with the OSSA-2023-003 response is just... much more a "how", but words are hard and I think the framing on that didn't help | 15:42 |
| TheJulia | bbezak: I'm not planning on it, I'm planning on documenting it. Keep in mind, for a long time, the other tenant users were entirely unable to ever see anything in ironic unless they had been granted explicit admin rights, then we enter into the realm of the original bug which created system scope | 15:43 |
| TheJulia | bbezak: the whole thing with this enabled us to extend access to project scoped members and readers | 15:46 |
| bbezak | TheJulia: sorry which "this"? :) | 15:46 |
| SvenKieske | I'm fairly certain I voiced some concerns back in the day at least to funghi. because the openstack security process seems to assume the project is "finished" once core openstack services are fixed. deployment projects seem to be left out in the cold, at least we had not much time understanding and implementing all the needed bells and whistles which I suspect lead to a hurry and maybe imperfect | 15:46 |
| SvenKieske | implementation on our side. | 15:46 |
| JayF | SvenKieske: Is K-A vulnerabity-managed or eligible to be? | 15:47 |
| opendevreview | Merged openstack/ironic master: reno: Update master for unmaintained/yoga https://review.opendev.org/c/openstack/ironic/+/908129 | 15:47 |
| TheJulia | as long as networking-baremetal loaded into neutron can still see ironic, and nova can still see ironic nodes using elevated access, compute resources will be able to be leveraged as before. | 15:47 |
| JayF | These all sound like "there is too much work for all these people" type of problems :/ | 15:47 |
| opendevreview | Merged openstack/ironic-ui master: reno: Update master for unmaintained/yoga https://review.opendev.org/c/openstack/ironic-ui/+/908127 | 15:47 |
| bbezak | yeah, baremetal managent looks ok from project scoped side now | 15:48 |
| TheJulia | bbezak: This refers to all of the rbac work we've put into Ironic since... Wallaby | 15:48 |
| SvenKieske | JayF: afaik yes, and afaik our cores should get some advanced notices about vulns, but I don't really know if this is read on time or acted upon or if this works at all. At least my impression was that it wasn't somehow handled fast enough. | 15:48 |
| bbezak | with elevated | 15:48 |
| TheJulia | well, really, pre-wallaby | 15:48 |
| TheJulia | SvenKieske: As an FYI, Ironic got to find out about that OSSA after the fact and had to develop a fix. | 15:49 |
| TheJulia | so, it wasn't *just* deployment projects. | 15:49 |
| JayF | SvenKieske: https://security.openstack.org/repos-overseen.html#repositories-overseen you are /not/ vulnerability managed | 15:49 |
| SvenKieske | nice :D more information I would have preferred to not know about ;) | 15:49 |
| JayF | I said something to the effect of this to my boss about the work to try and fix up eventlet: this is 1 of 100 different things that are this deep, and this broken, we could spend time on and fix. | 15:50 |
| JayF | The only option is to pick one and work through it, and try to not do too much at once | 15:50 |
| SvenKieske | JayF: maybe I can get us on that list and take care of that stuff once I know our project better, or whatever it takes to become core (my question regarding this is unanswered so far). | 15:51 |
| JayF | As Ironic PTL, I'd look for review frequency and quality as well as project knowledge and trust | 15:51 |
| SvenKieske | I'm following the eventlet work as well :) | 15:51 |
| JayF | IME anytime someone got core access, it was more giving them the access after they showed they /were already/ a core in the project | 15:51 |
| JayF | I'd have a frank conversation with the PTL | 15:52 |
| SvenKieske | I guess I maybe still lack in quality and surely knowledge of our 47k lines of yaml (I just counted) :D It's getting better though.. | 15:52 |
| JayF | and if you can't get in touch with the PTL, run yourself next time and be more responsive ;) | 15:52 |
| TheJulia | I'll note, discussions like this are also something I look for when nominating. Sometimes it also takes people just asking, and I would encourage (as well to what JayF just said), to have a frank discussion with the PTL | 15:52 |
| SvenKieske | JayF: ah can't really complain about the PTL, it's a lot of work I'm not sure I would want to be responsible for alone. | 15:53 |
| TheJulia | SvenKieske: sometimes it is also the mindset and recognition we are not experts, we only know our distinct areas and need to be mindful :) | 15:53 |
| TheJulia | SvenKieske: not complain, just talk :) | 15:53 |
| JayF | I think he was responding to my comment about "if they don't wanna talk, run" | 15:53 |
| JayF | and someone already clued SvenKieske to the dirty truth about being a PTL: it's all responsibility and very little glory :P | 15:54 |
| SvenKieske | TheJulia: well I'm at the stage that I know so much that I know I don't know really very much, sometimes knowledge seems to decrease as well as increasing (new questions popping up) :) | 15:54 |
| TheJulia | bbezak: awesome, Sorry about that, I should have anticipated folks were not going to use system scoped accounts after the rollback in community wide approach and should have just done it, but my capacity is finite. | 15:54 |
| JayF | In one of my other IRC channels -- a lot of senior oss folks from various communities -- we were talking about how much context gets lost | 15:54 |
| JayF | so SvenKieske, it's OK to not know much, we gotta get the context transferred over | 15:55 |
| JayF | it's something we're not always the best at in openstack, but we need to focus on it more | 15:55 |
| TheJulia | +++++++++++++++ | 15:55 |
| JayF | I want to retire some day and so do many other devs, I suspect | 15:55 |
| TheJulia | "what is retire?" | 15:55 |
| SvenKieske | sure, that's why I'm always trying to ask our upstream how stuff is supposed to work :) works fairly well, thanks for all the insights | 15:55 |
| TheJulia | oooh ahh, brand new KMFDM just played on pandora for me | 15:56 |
| * TheJulia gives pandora a cookie | 15:56 | |
| JayF | I know those letters separately | 15:56 |
| TheJulia | JayF: https://en.wikipedia.org/wiki/KMFDM | 15:57 |
| SvenKieske | nice band, is pandora still a thing? I guess it got shut down back in the day in europe only? | 15:57 |
| TheJulia | Still a thing in the states. | 15:57 |
| bbezak | TheJulia: regular baremetal managent is ok with elevated. but still I need to tackle regular admin (project scoped) can't do basic operations - like initial issue (driver get) | 15:57 |
| SvenKieske | TheJulia: lol when I visit pandora I get "Pandora isn't available in this country right now" :( sometimes europe can't have nice things. | 15:58 |
| TheJulia | bbezak: driver list is an elevated request because it reveals the internals of the infrastructure along with conductor list. | 15:58 |
| opendevreview | Takashi Kajinami proposed openstack/networking-baremetal master: Bump hacking to 6.1.0 https://review.opendev.org/c/openstack/networking-baremetal/+/907552 | 15:58 |
| TheJulia | SvenKieske: The mobile app worked until my next to last day in the EU, last time I was there | 15:59 |
| TheJulia | Walking around Wien and suddenly "Pandora is not available in your region." | 15:59 |
| TheJulia | bbezak: driver list also can't be tied back to nodes, so... I guess the bigger question is why is driver list *really* needed in your case | 16:00 |
| JayF | TheJulia: conductor_group.owner when | 16:03 |
| * JayF ducks | 16:03 | |
| * TheJulia searches etsy for "laser beam eye upgrades" | 16:03 | |
| TheJulia | oooh ahh a 4.2 watt laser | 16:05 |
| TheJulia | If I wasn't fearing the need to flee the US in the year, I'd seriously consider getting a 200+ watt laser | 16:07 |
| * TheJulia never really did much with her home made laser cutter | 16:07 | |
| JayF | I can summarize my desire to never get a 200W laser with "ow my eyes" | 16:08 |
| TheJulia | laser protection gear, dude :) | 16:08 |
| JayF | That's a lot easier to say as someone who'd live outside of range of the laser :P | 16:09 |
| JayF | although the idea of outfitting my dog and cats with laser protective googles is great | 16:10 |
| TheJulia | "laserpunk" ?! | 16:10 |
| TheJulia | instead of "steampunk" | 16:11 |
| JayF | https://www-cio-de.translate.goog/a/lockheed-martin-nutzt-openstack-fuer-mondmission,3727581?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp | 16:17 |
| JayF | tl;dr: OpenStack helping go to the moon. | 16:18 |
| bbezak | TheJulia: driver list is part of ironic CI smoke tests. I'll play with keystone admin in system scope | 16:18 |
| JayF | bbezak: ah yeah, you'll need a system reader for that at a minimum | 16:18 |
| rpittau | good night! o/ | 17:05 |
| JayF | \o | 17:28 |
| TheJulia | Question, do we want to add a migration to auto-set null owners? | 19:36 |
| TheJulia | *if* configured, that is | 19:36 |
| JayF | I would need to hear a good use case | 19:44 |
| JayF | my knee-jerk is why would we allow a migration for a api thing | 19:44 |
| JayF | you can api call to do that | 19:44 |
| JayF | but if you have very-large-N nodes, that's painful -- but you're also more likely to need >1 owner set across the nodes | 19:44 |
| JayF | so I sorta feel like the usefulness is limited | 19:44 |
| TheJulia | Good points, I'm thinking more as folks might be used to the prior model and might feel like they got bitten because they don't want to chagne the config temporarily or use a system role, but at some point at a certain scale they likely need or already have owner already used maybe | 19:47 |
| JayF | or you just continue interacting with Ironic in system scope or flip off "scoped access" and use it like you have before | 19:59 |
| JayF | those are also options: we have a knob they can turn off to opt outta this stuff for some period of time | 19:59 |
| NobodyCam | Good afternoon Ironic folks, anyone happen to be aware of any strangeness with boot from volume with cinder on RH9? | 20:16 |
| TheJulia | le sigh | 20:18 |
| TheJulia | NobodyCam: I can cycle to that question *after* my next meeting | 20:19 |
| TheJulia | JayF: yeah, sort of writing that up right now | 20:19 |
| TheJulia | anyone have access to a running openstack and can tell me if something like "openstack project show -c id admin" returns just the project id value as expected | 20:20 |
| AustinCormier[m] | kamino@INFRA-PROD-DEPLOYER-01:/opt/kolla_testbeds/production/config$ openstack project show -c id admin... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/vkhtczRUCKvAnbjZIXENBEHR>) | 20:21 |
| AustinCormier[m] | You have to use -f value if you ONLY want the id without the formatting. | 20:21 |
| TheJulia | awesome, just wanted to make sure | 20:22 |
| TheJulia | now to just write up a "get yourself a system admin account" | 20:22 |
| TheJulia | eek! | 20:22 |
| NobodyCam | +++ Thank you | 20:33 |
| opendevreview | Julia Kreger proposed openstack/ironic master: docs: augment admin troubleshooting docs for system scope context https://review.opendev.org/c/openstack/ironic/+/908203 | 22:10 |
| TheJulia | NobodyCam: define strangeness, I'm not immediately aware of any on rhel 9.x, but iscsi is a less and less popular mechanism. What are you seeing which is weird? | 22:11 |
| NobodyCam | Good Afternoon TheJulia :) :wave | 22:11 |
| NobodyCam | we are getting a general "failed to open SAN device error: 0x03232019 | 22:13 |
| NobodyCam | talent gotten to do a tcpdump just yet | 22:14 |
| TheJulia | UEFI boot? | 22:15 |
| TheJulia | so, I think this is the change in how ipxe handled multipath | 22:16 |
| TheJulia | see: https://ipxe.org/err/032320 | 22:16 |
| TheJulia | https://review.opendev.org/c/openstack/ironic/+/570145 is a patch you might want to check for | 22:19 |
| NobodyCam | oh | 22:43 |
| NobodyCam | ;) | 22:43 |
| * NobodyCam checks | 22:43 | |
| adamcarthur5 | TheJulia https://hastebin.com/share/uyisuxepum.typescript I figured out the right OS_CLOUD var eventually, here are my results. All the commands ran successfully | 23:27 |
| adamcarthur5 | Not sure if this is what you mean but I will share regardless in case it is | 23:28 |
| JayF | yeah, that makes sense | 23:29 |
| JayF | you provision as the project, you look at nodes as an admin | 23:29 |
| TheJulia | yup, and nova just schedules :) | 23:38 |
| TheJulia | well, placement | 23:38 |
| TheJulia | There was talk of one day trying to make scheduler owner aware. I wonder where that got left off at | 23:59 |
| TheJulia | well, *placement* | 23:59 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!