| *** bauzas_ is now known as bauzas | 05:41 | |
| opendevreview | Alexander Hild proposed openstack/nova master: feat: "vm uuid" in baseBoard asset tag https://review.opendev.org/c/openstack/nova/+/924907 | 07:34 |
|---|---|---|
| *** blady is now known as Guest1228 | 09:07 | |
| *** bauzas_ is now known as bauzas | 09:18 | |
| opendevreview | Alexander Hild proposed openstack/nova master: feat: Include "vm uuid" in baseBoard asset tag in libvirt domain xml https://review.opendev.org/c/openstack/nova/+/924916 | 10:30 |
| sean-k-mooney | gibi: bauzas: can one of ye hit https://review.opendev.org/c/openstack/nova/+/924733 | 11:35 |
| gibi | looking | 11:36 |
| gibi | +A | 11:38 |
| sean-k-mooney | gibi: thanks | 11:39 |
| sean-k-mooney | gibi: i left some other comments on https://review.opendev.org/c/openstack/nova/+/924866 by the way in case you want to weigh in there | 11:40 |
| sean-k-mooney | im +2 on it but want to get dans opion before proceeding | 11:40 |
| andreykurilin | Hi folks! I have a custom Neutron plugin that restricts adding&removing specific security groups from ports. It works excellently with Nova's `addSecurityGroup` server action, i.e., Nova propagates an original error from Neutron to the end-user. But 'removeSecurityGroup' behaves differently - it raises 500 if something goes wrong on the Neutron side. Is the behavior difference between similar server actions intentional or not? | 11:41 |
| andreykurilin | If not, can this case be considered as a bug? And the last question - if it is a bug, does it require a microversion bump or not, as the 'removeSecurityGroup' API already defines a 400 error code? | 11:41 |
| gibi | sean-k-mooney: ack. My limited understanding of the related code tells me that our defaults probably OK and if we start reconfiure things we will hit edge cases. So lets wait for Dan but I think we can land this as is and chalk up one more thing to care about when we rewrite the image code in nova. | 11:44 |
| sean-k-mooney | yep thats where im at too | 11:44 |
| sean-k-mooney | im going for an "eyes fully open appoch" just to be transparent and say hay this edge case exist but it existed before so not a regression | 11:46 |
| sean-k-mooney | it does double down on the fact we need better tempest coverage of the formats we intend to supprot in the nova ci however | 11:47 |
| sean-k-mooney | even if those are just in a perodic job | 11:47 |
| sean-k-mooney | or one that only runs on cahgnes to the image code | 11:47 |
| gibi | I agree. We only caught our regression becuase we were lucky to have a job with ami images | 11:55 |
| sean-k-mooney | andreykurilin: we do not provide any supprot in nova for third party enturon exteions | 12:02 |
| sean-k-mooney | andreykurilin: so unless this is in tree in neutron its by defientioan not a nova bug | 12:03 |
| sean-k-mooney | if there is an aooved neutron api exteion for this beaviro then nova can be enhanced to supprot that when its enabeld | 12:04 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: DNM: test downstream cross repo testing https://review.opendev.org/c/openstack/nova/+/924823 | 12:04 |
| sean-k-mooney | the behaivor being differnet is likely not intentional but im not sure if we shoudl fix it | 12:06 |
| sean-k-mooney | if we were to fix this a micorversoin would not be approiate | 12:07 |
| *** ykarel_ is now known as ykarel | 12:07 | |
| sean-k-mooney | andreykurilin: your custom neutron plugin is effectivly impelmeting "custom api policy" internaly which we also do not supprot | 12:07 |
| opendevreview | Stephen Finucane proposed openstack/osc-placement master: Remove use of distutils https://review.opendev.org/c/openstack/osc-placement/+/924926 | 12:12 |
| stephenfin | sean-k-mooney: gibi: Can you folks review that when you get a chance? osc-placement is currently broken on Python 3.12, which is the default Python on Fedora 40 (and has been out since October 2023) | 12:12 |
| sean-k-mooney | stephenfin: 3.12 is alos only optional in this release and that was a hard battel to get to even that point | 12:18 |
| sean-k-mooney | but im very much in favor of fixing any 3.12 issues | 12:18 |
| sean-k-mooney | so yes ill review it now | 12:19 |
| sean-k-mooney | https://github.com/openstack/governance/blob/master/reference/runtimes/2024.2.rst | 12:19 |
| sean-k-mooney | for refernce | 12:19 |
| sean-k-mooney | ah its this | 12:19 |
| sean-k-mooney | so the other option is to use microversion_parse form oslo? | 12:19 |
| gibi | stephenfin: Is it intetional that we ignore the patch version from semver? | 12:20 |
| sean-k-mooney | but im ok with your in tree version too | 12:20 |
| sean-k-mooney | gibi: depends on the schem | 12:20 |
| sean-k-mooney | patch only exsits in the 4 . version i.e. major.minor.bugfix.patch | 12:21 |
| stephenfin | gibi: It's not semver, it's a microversion. to the best of my knowledge, microversions never have a patch version | 12:21 |
| sean-k-mooney | and ya microvesion dont use it | 12:21 |
| stephenfin | and won't ever use it | 12:21 |
| sean-k-mooney | https://pypi.org/project/microversion-parse/ | 12:21 |
| sean-k-mooney | that is the shared dep we maintain fo doitng htis by the way | 12:22 |
| stephenfin | yeah, see my commit message. This is small enough that I don't see the point in dragging in a new (and borderline unmaintained library) | 12:22 |
| sean-k-mooney | right but in genreally i want use to not cargo cult this to every project | 12:22 |
| sean-k-mooney | so im fine with this for now but either we shoudl pull that in or add this to oslo.utils | 12:23 |
| stephenfin | If it belongs anywhere, it's probably osc-lib | 12:23 |
| sean-k-mooney | well we need it for the sdk and in opentack tooo | 12:23 |
| sean-k-mooney | by openstack i mean nova et al | 12:23 |
| stephenfin | but this is going away once we switch osc-placement to sdk | 12:23 |
| sean-k-mooney | oh i just mean i have seen this exact issue in pbr and other projects | 12:24 |
| stephenfin | microversion-parse handles things like parsing headers. I think using it in nova makes sense | 12:24 |
| gibi | ahh OK I did not realized that we are parsing microversion | 12:24 |
| sean-k-mooney | so i think we are both ok with the osc_placement patch for now? | 12:25 |
| gibi | and I cannot blame it to lack of coffee as I just had one | 12:25 |
| gibi | I put my +2 ther | 12:25 |
| gibi | e | 12:25 |
| sean-k-mooney | ok ill +w it so | 12:25 |
| gibi | cool | 12:25 |
| gibi | thanks stephenfin for fixing it | 12:25 |
| stephenfin | np | 12:26 |
| *** blady is now known as Guest1235 | 12:43 | |
| *** Guest1235 is now known as gryf | 12:43 | |
| opendevreview | Merged openstack/osc-placement master: Remove use of distutils https://review.opendev.org/c/openstack/osc-placement/+/924926 | 12:50 |
| andreykurilin | sean-k-mooney: thanks for reply. “custom api policy” - yes and no. I can simplify the case - restricting to manipulate security groups for ‘less-privileged’ roles. It does not require a custom policy and reuses everything ‘builtin’. addSecurityGroup action reraises neutron’s policy error which gives end-user enough information what is going on, versus 500 by removeSecurityGroup | 13:01 |
| andreykurilin | Neutron plugin I mentioned previously is entirely on neutron’s project side. It is not nova specific, i.e., it does not modify/extend nova-api. I just tried to give more context about what I’m trying to achieve. it looks like I gave more misleading info rather than useful one :) | 13:10 |
| sean-k-mooney | andreykurilin: right btu nova does not supprot neutron srbac funcitonaltiy or any non default policy/roles | 13:12 |
| sean-k-mooney | andreykurilin: so https://docs.openstack.org/neutron/latest/admin/config-rbac.html is not supproted by nova because the netruon folks never created a spec or worked with use to add support | 13:13 |
| sean-k-mooney | we ocationaly get one of request ot enable subset of it | 13:13 |
| sean-k-mooney | but there has never been an effort to actully supprot it or update it when neturon adds new fucntionaltiy | 13:14 |
| sean-k-mooney | andreykurilin: if you want to use any fucntionaly restricte by that then you cannot use nova proxy apis anymore | 13:14 |
| sean-k-mooney | you have to do the secrity group config via neutron api only | 13:15 |
| andreykurilin | sean-k-mooney: yes, I understand that nova should not care about neutron rbac. The only problem for me here is that the end user who sees a 500 internal error (with fill out a bug report message) is less happy than someone who sees a propagated error from neutron. As I mentioned, one method already does this. | 13:16 |
| sean-k-mooney | what error code does neutron return in this case | 13:16 |
| andreykurilin | 400 | 13:16 |
| sean-k-mooney | 400 bad request is technially not correct for a permission denial | 13:17 |
| sean-k-mooney | do you have an example of the neutorn error respocne you can post | 13:17 |
| andreykurilin | I could be incorrect, let me recheck quickly | 13:18 |
| andreykurilin | ps: I was referencing https://github.com/openstack/nova/blob/master/nova/network/security_group_api.py#L635-L638 versus https://github.com/openstack/nova/blob/master/nova/network/security_group_api.py#L695-L699 | 13:19 |
| sean-k-mooney | so its partly because removing a secrity group is never ment to be somethign that can fail | 13:19 |
| sean-k-mooney | we may be able to handel the 400 case there safely | 13:21 |
| sean-k-mooney | we woudl need to knwo if there is any other case that neutron returns a 400 | 13:21 |
| sean-k-mooney | but we are only updatign the securit_group part of the port in that requst | 13:21 |
| sean-k-mooney | so its proably ok | 13:21 |
| sean-k-mooney | i dont like that we are returing a 400 form nova in this case by the way | 13:23 |
| sean-k-mooney | it really should be a 403 | 13:24 |
| andreykurilin | sean-k-mooney: rechecked, I was incorrect, sorry. Neutron actually raises 403. I thought that my simplified case for custom neutron logic is similar to policy errors | 13:24 |
| sean-k-mooney | ok so a 403 is what i would expect becuase this is being deigned based on the permission of the roles the request was made with | 13:25 |
| sean-k-mooney | so nova should be handleling that gracefuly and returning a 403 as well so i think we can catch that and provide a better error message | 13:26 |
| andreykurilin | But what about 400 ? :) Are you still ok with handling it the same way as in addSecurityGroup ? | 13:27 |
| sean-k-mooney | but i would also consider this to be skirting what is and is not in scope to fix in nova | 13:27 |
| sean-k-mooney | andreykurilin: i would prefer that to also be a 403 but that woudl require a microverison update | 13:28 |
| sean-k-mooney | and im not sure we want that | 13:28 |
| sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/exception.py#L1054 | 13:29 |
| sean-k-mooney | that unfortunetly inhrits form invlaide and default to a 400 as a result | 13:29 |
| sean-k-mooney | that was a bug form when we first added the proxy api https://github.com/openstack/nova/commit/c3ed3dfcf99e9162616960bad5c7b7a36d3b2453 | 13:30 |
| sean-k-mooney | we have got better at using sematicly correct http respoce codes since then | 13:30 |
| andreykurilin | Yes, it is 400. It is set separately here https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/security_groups.py#L430 | 13:30 |
| sean-k-mooney | so if we want to avoid a micor version bump we might be forced to use 400 https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/security_groups.py#L432 | 13:32 |
| sean-k-mooney | although i belive we are alwasy allowed to return a 401 and 403 | 13:32 |
| sean-k-mooney | btu we shoudl disucss that with gmann ^ | 13:32 |
| sean-k-mooney | andreykurilin: if you want to create a patch for this do | 13:32 |
| sean-k-mooney | we can discuss the exacat details of the respoce code and message content as part of the review | 13:33 |
| andreykurilin | sean-k-mooney: great, thanks! I already have a patch for handling 400 as a part of removeSecurityGroup action https://review.opendev.org/c/openstack/nova/+/924399 . I’ll add 403 handling there as well | 13:34 |
| sean-k-mooney | can you actully file a bug for this too | 13:35 |
| sean-k-mooney | and add a release note please. | 13:35 |
| sean-k-mooney | we would ideally have both if we are going to backport this | 13:35 |
| andreykurilin | sure | 13:35 |
| dansmith | JayF: TheJulia: Someone told me that ironic is using glance's ARI format in some way, presumably to store your ramdisk image, is that right? | 14:09 |
| opendevreview | Merged openstack/nova stable/2023.2: Change force_format strategy to catch mismatches https://review.opendev.org/c/openstack/nova/+/924733 | 14:11 |
| TheJulia | dansmith: yeah, aki and ari for the raw image artifacts set by an admin to facilitate ops, they never ever get handed off to a conversion operation | 14:15 |
| dansmith | TheJulia: okay, I feel like that's the wrong image type to be using.. what gets stored in the aki? | 14:16 |
| sean-k-mooney | those are not required as far as i am aware by the way | 14:17 |
| dansmith | oh, the kernel for a pxeboot operation? | 14:17 |
| TheJulia | dansmith: yes | 14:17 |
| sean-k-mooney | what i ment by that is using ari and aki | 14:17 |
| sean-k-mooney | to store the ramdisk and kernel images | 14:17 |
| dansmith | the reason is that AKI, ARI are not just kernel and ramdisk, they are *amazon* kernel and ramdisk, which at least when it was defined meant "a paravirt kernel" and "a ramdisk with paravirt drivers in it" | 14:17 |
| dansmith | that said, TheJulia, those things never flow through nova at all, is that right? | 14:17 |
| sean-k-mooney | i dont think there is any ckecking that the ramdisk image and kernel iamge uuid are in those formats | 14:18 |
| TheJulia | dansmith: well, it is possible to do, given how they can be constructed | 14:18 |
| dansmith | asking because I want to (thermo) nuke AMI,ARI,AKI from nova | 14:18 |
| TheJulia | dansmith: never flow through nova | 14:18 |
| dansmith | okay | 14:18 |
| frickler | dansmith: sean-k-mooney: I lost track a bit, are there fixes already that should make https://review.opendev.org/c/openstack/nova/+/924734 pass or does that still need further investigation? or just enough rechecks? ;) | 14:19 |
| sean-k-mooney | dansmith: TheJulia nova support suing sepreate ram/kernel disk indepenent of the format of the root disk as far as im aware | 14:19 |
| sean-k-mooney | so if you took an ami and uploaed all 3 parts as raw | 14:19 |
| sean-k-mooney | it would work | 14:19 |
| TheJulia | sean-k-mooney: yeah, it *should* and I would expect it to actually | 14:20 |
| sean-k-mooney | as would uploading a qcow as qcow and refeince seperate kerenl/ram disk | 14:20 |
| TheJulia | I think this goes back to age old convention | 14:20 |
| dansmith | sean-k-mooney: yeah, I'm sure we're not doing any specific checking on the aki,ari bits | 14:20 |
| TheJulia | set like 10 years ago because people didn't think of raw | 14:20 |
| sean-k-mooney | to me the only purposue today is lableing them as not bootable | 14:20 |
| TheJulia | perfect | 14:20 |
| sean-k-mooney | for filtering the images | 14:20 |
| dansmith | TheJulia: no, raw has been around forever, it's because the disk image of an ARI,AKI booted thing is not a disk | 14:21 |
| TheJulia | dansmith: indeed and correct | 14:21 |
| TheJulia | ari/aki has also been in the docs for ages for some human delination purpose I never understood | 14:21 |
| sean-k-mooney | frickler: checkign | 14:21 |
| TheJulia | other than it is an explicit kernel and explicit ramdisk | 14:22 |
| dansmith | TheJulia: it's not for humans specifically, it's for amazon compatibility which has long since gone away in direct form | 14:22 |
| sean-k-mooney | frickler: i think there is a requirement repo change to bump packaging to the 2023.2 version to fix the setuptools issues | 14:22 |
| TheJulia | dansmith: wasn't explicitly aware of that, but likely humans just didn't know to update ironic's docs. | 14:22 |
| dansmith | TheJulia: virtual machines booted this way don't use a bootloader on the disk and are sort of warm booted from a pre-crafted memory state | 14:23 |
| frickler | sean-k-mooney: ah, that was merged two days ago, so I'll try to recheck then https://review.opendev.org/c/openstack/requirements/+/924764 | 14:23 |
| sean-k-mooney | yep that the patch i was looking for | 14:23 |
| sean-k-mooney | perfect | 14:23 |
| dansmith | TheJulia: right, I think the human problem is that people saw "ramdisk" and "kernel" and thought "oh these are what I should use" without considering what the "amazon-" prefix meant in context | 14:23 |
| dansmith | TheJulia: anyway, the thing I wanted to confirm is that if we were to drop all that special behavior from nova it's not going to impact ironic and it sounds like that's true | 14:24 |
| TheJulia | dansmith: yeah, its just a doc issue really | 14:24 |
| TheJulia | dansmith: correct | 14:24 |
| dansmith | TheJulia: you mean a doc issue because you could easily store all those in 'raw' images and it would all work fine right? | 14:24 |
| TheJulia | yeah | 14:26 |
| dansmith | ack | 14:26 |
| TheJulia | at least *should* afaik | 14:26 |
| TheJulia | I would expect it to in other words | 14:27 |
| sean-k-mooney | unless ye have also specical cased it for some archane reason im not sure why it woudl not | 14:28 |
| sean-k-mooney | the format you mark somethign in in glance really does not change the content of the data | 14:28 |
| dansmith | right, glance is going to start using inspector to enforce the content of the stream at some point, | 14:29 |
| dansmith | and if we were to get particular about it, we'd need to decide what we're going to accept for those formats | 14:29 |
| TheJulia | Can the format be changed post upload? | 14:32 |
| * TheJulia has never tried, hence the question | 14:32 | |
| dansmith | no | 14:32 |
| TheJulia | oh joy | 14:34 |
| TheJulia | okay | 14:34 |
| TheJulia | folks would just have to explicitly correct any incorrect usage | 14:34 |
| sean-k-mooney | TheJulia: glance does not allow the format to be updated after the fact | 14:34 |
| dansmith | I'm not saying you need to do that, to be clear, | 14:34 |
| * TheJulia creates a bug to fix the docs so we take care of it sooner rather than later | 14:34 | |
| dansmith | I'm saying it's wrong, historically wrong, and I want to remove that specialized support from nova | 14:35 |
| sean-k-mooney | TheJulia: so yes but by uploading and using new iamges with the corect format | 14:35 |
| TheJulia | yeah, I grok that | 14:35 |
| dansmith | but you guys can continue being wrong, I just don't want to break ironic if doing so in nova would be a problem | 14:35 |
| TheJulia | sean-k-mooney: yeah, figured that | 14:35 |
| TheJulia | dansmith: no worries, we should fix it anyway just to remove confusion | 14:35 |
| JayF | We have plenty of other ways to keep being wrong instead ;) | 14:35 |
| dansmith | JayF: I was being overly dramatic in my use of wrong of course :) | 14:36 |
| JayF | oh, I took it as jovial :D | 14:36 |
| dansmith | okay good :) | 14:38 |
| TheJulia | JayF: looks like our devstack plugin uses the wrong convention too, but that also should be an easy/quick fix as far as I can see | 14:42 |
| JayF | yeah we've been telling people aki/ari since forever | 14:45 |
| JayF | I'm probably at least somewhat responsible for that, at least as the last person left from the team that made the agent lol | 14:45 |
| TheJulia | JayF: https://bugs.launchpad.net/ironic/+bug/2074090 | 14:46 |
| dansmith | glance probably needs an image format type of "non-bootable-artifact" or something like that | 14:46 |
| dansmith | raw is technically okay for those things, but people think raw means "a MBR/GPT disk that I should be able to boot in nova" too | 14:47 |
| dansmith | perhaps raw but setting hw_arch to be "linux/x86" or something to make it clear it's not a machine-bootable thing or something like that | 14:47 |
| TheJulia | Simple is likely best here, since raw is just bytes, not a disk image under a certian format | 14:48 |
| JayF | Yeah, I think that's likely why we'd have gone with the aki/ari back in the day, like you said above, pattern matching on "kernel" and "ramdisk" and there's no other choice that fits | 14:48 |
| JayF | it's almost like we're trying to combine "purpose" and "image format" in the same field, and it's resisting for good reason :D | 14:48 |
| dansmith | yeah, and the fact that all three are also options for container_format makes it even less sensical | 14:49 |
| TheJulia | yup | 14:49 |
| dansmith | you know what we should do | 14:53 |
| dansmith | we should add a disk_format of 'gpt' to glance, | 14:54 |
| dansmith | and start rejecting raw in nova over time | 14:54 |
| dansmith | then we can assert that a gpt image actually has a gpt header and we could stop with this "anything that doesn't match another format must be raw" silliness, | 14:54 |
| dansmith | which would really help a lot I think | 14:55 |
| dansmith | then raw can be more like what TheJulia says above (which is correct, just with caveats today) | 14:55 |
| TheJulia | yeah | 14:57 |
| TheJulia | gpt would be nice actually, since there are distinctions but really it should get treated exactly like raw | 14:58 |
| JayF | a partition image, so to speak, would always have to be raw, yeah? | 14:58 |
| TheJulia | the VM firmware... otoh | 14:58 |
| TheJulia | JayF: it could be qcow2 as a container | 14:58 |
| TheJulia | and when unpacked it is just bytes | 14:58 |
| dansmith | TheJulia: right it would be treated like raw inside of nova and for qemu, but we could assert that it's not just random bytes but at least looks like a gpt on the surface, | 14:59 |
| dansmith | refuse to boot something that is claimed as raw in glance (which could be a kernel or ramdisk or text file) | 14:59 |
| dansmith | and not have the "else: must be raw" behavior everywhere in nova, which is the source of lots of problems | 14:59 |
| dansmith | because to qemu, an iso is raw because it doesn't support it | 15:00 |
| TheJulia | yeah | 15:00 |
| TheJulia | makes sense actually | 15:00 |
| dansmith | and ami/ari/aki images also have to be treated as raw because qemu-img doesn't support them when we're comparing notes | 15:00 |
| TheJulia | yeah | 15:01 |
| dansmith | basically this sort of hack: https://github.com/openstack/nova/blob/master/nova/virt/images.py#L186 | 15:01 |
| andreykurilin | sean-k-mooney: er… I cannot find the actual nova’s code that does it, but 403 is automatically propagated from neutron’s call. So my simplified case was totally irrelevant. Sorry for misleading you. It is only about 400 as a part of removeSecurityGroup now. | 15:04 |
| *** bauzas_ is now known as bauzas | 15:04 | |
| dansmith | ralonsoh: does your comment on the ami snapshot patch mean it solves the problem for your neutron stuff? | 15:38 |
| dansmith | ah looks like it from the neutron DNM patch, cool | 15:39 |
| dansmith | sean-k-mooney: ^ | 15:39 |
| *** iurygregory__ is now known as iurygregory | 16:35 | |
| priteau | Looks like https://review.opendev.org/c/openstack/nova/+/924734 is ready to merge | 17:07 |
| frickler | dansmith: ^^ do you want to have another look? | 17:23 |
| gmann | sean-k-mooney: andreykurilin: on SG error. I agree to handle both 403 as well 400 in both Add/Remove SG cases which is always better than 500. NOTE: neither 400 or 403 need microversion bump as those are always existing error code from all the APIs so we can just fix this with bug fix with no microversion bump | 17:23 |
| dansmith | frickler: +Wd | 17:23 |
| gmann | sean-k-mooney: andreykurilin: 500 -> '400, 403, 404 or 415' is all ok. https://docs.openstack.org/nova/latest/contributor/microversions.html#id3 "The exception to not needing a microversion when returning a previously unspecified error code is the 400, 403, 404 and 415 cases. " | 17:24 |
| opendevreview | Merged openstack/nova master: Remove AMI snapshot format special case https://review.opendev.org/c/openstack/nova/+/924866 | 17:29 |
| gmann | sean-k-mooney: andreykurilin but for 403 we should define new exception which can clearly have msg about neutron access error otherwise user can confuse on nova access issue. Something inherited from PolicyNotAuthorized or Forbidden but a different error msg - https://github.com/openstack/nova/blob/master/nova/exception.py#L191 | 17:29 |
| gmann | andreykurilin: just read your last msg about 403 is already propagated. can you check what error msg it say? | 17:31 |
| gmann | andreykurilin: bcz I am not sure where we handle the neutron 403, but it is propagated in both cases addSecurityGroup and removeSecurityGroup ? https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/security_groups.py#L421-L430 https://github.com/openstack/nova/blob/eb5e3374bcb5de3b5986b66438a59c73be7fb596/nova/api/openstack/wsgi.py#L667 | 17:49 |
| *** iurygregory__ is now known as iurygregory | 17:57 | |
| andreykurilin | gmann: `RESP BODY: {"forbidden": {"code": 403, "message": "rule:update_port is disallowed by policy\nNeutron server returns request_ids: ['req-97c54f6e-6876-4cf4-9657-b8b3be322f57’]”}}`. vs `RESP BODY: {"forbidden": {"code": 403, "message": "Policy doesn't allow os_compute_api:os-security-groups:add to be performed.”}}` in case of Nova’s native policy error. | 18:15 |
| andreykurilin | Despite the fact neutron errors have an extra 'suffix' line with request-id, mo, adding some prefix to error's from neutron should give more visibility of "guilty" side. | 18:16 |
| andreykurilin | gmann: https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L213-L214 neutronclient’s 403 is handled on ‘globally’ | 18:22 |
| gmann | andreykurilin: right. did not check that. ++ | 18:23 |
| andreykurilin | Yeah, It took me a while to find it | 18:23 |
| gmann | andreykurilin: then you can just add 400 case in Remove SG case | 18:24 |
| gmann | all these handling are so deep in code and hard to find :) | 18:24 |
| andreykurilin | gmann: thank you! I’ll update my patch yesterday with a proper release note. | 18:26 |
| gmann | andreykurilin: ++ thanks | 18:26 |
| andreykurilin | *tomorrow (need to relax ) | 18:34 |
| opendevreview | Merged openstack/nova stable/2023.1: Change force_format strategy to catch mismatches https://review.opendev.org/c/openstack/nova/+/924734 | 19:18 |
| opendevreview | Jay Faulkner proposed openstack/nova master: [ironic] Factor out metadata and send to ironic https://review.opendev.org/c/openstack/nova/+/923910 | 20:08 |
| JayF | sean-k-mooney: https://review.opendev.org/c/openstack/nova/+/923910 + https://review.opendev.org/c/openstack/ironic/+/924887 are tested working in devstack. Still have to write a small migration script and some tempest tests, but wanted to get general agreement on the shape of the change before going further. If you could have a look I'd appreciate it. (/me goes and asks the same of Ironic cores) | 21:13 |
| *** bauzas_ is now known as bauzas | 21:16 | |
| opendevreview | sean mooney proposed openstack/nova stable/2024.1: Remove AMI snapshot format special case https://review.opendev.org/c/openstack/nova/+/924982 | 21:46 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!