| *** ociuhandu has joined #openstack-nova | 01:15 | |
| *** ociuhandu has quit IRC | 01:19 | |
| *** tetsuro has joined #openstack-nova | 01:26 | |
| *** tetsuro has quit IRC | 02:14 | |
| openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Introduce scope_types in os-flavor-manage https://review.opendev.org/714818 | 02:37 |
|---|---|---|
| openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add new default roles in os-flavor_manage policies https://review.opendev.org/714819 | 02:37 |
| openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Pass the actual target in os-flavor-manage policy https://review.opendev.org/714822 | 02:38 |
| *** mkrai has joined #openstack-nova | 02:56 | |
| *** ralonsoh has joined #openstack-nova | 03:04 | |
| *** ociuhandu has joined #openstack-nova | 03:13 | |
| openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add new default roles in server topology policies https://review.opendev.org/717585 | 03:14 |
| *** mvkr has quit IRC | 03:15 | |
| *** psachin has joined #openstack-nova | 03:19 | |
| *** ociuhandu has quit IRC | 03:22 | |
| *** ociuhandu has joined #openstack-nova | 03:24 | |
| *** mvkr has joined #openstack-nova | 03:28 | |
| *** tetsuro has joined #openstack-nova | 03:29 | |
| *** ociuhandu has quit IRC | 03:29 | |
| *** tetsuro has quit IRC | 03:58 | |
| *** tetsuro has joined #openstack-nova | 04:02 | |
| *** prometheanfire has left #openstack-nova | 04:09 | |
| *** evrardjp has quit IRC | 04:36 | |
| *** evrardjp has joined #openstack-nova | 04:37 | |
| *** udesale has joined #openstack-nova | 04:51 | |
| *** udesale has quit IRC | 04:52 | |
| *** udesale has joined #openstack-nova | 04:52 | |
| *** udesale has quit IRC | 05:03 | |
| *** udesale has joined #openstack-nova | 05:03 | |
| *** ratailor has joined #openstack-nova | 05:04 | |
| openstackgerrit | melanie witt proposed openstack/nova master: Reset the cell cache for database access in Service https://review.opendev.org/717662 | 05:39 |
| *** tetsuro has quit IRC | 06:05 | |
| *** tetsuro has joined #openstack-nova | 06:21 | |
| *** ociuhandu has joined #openstack-nova | 06:28 | |
| *** dpawlik has joined #openstack-nova | 06:28 | |
| *** ociuhandu has quit IRC | 06:33 | |
| *** ccamacho has joined #openstack-nova | 06:34 | |
| *** rpittau|afk is now known as rpittau | 06:35 | |
| *** ccamacho has quit IRC | 06:46 | |
| *** ccamacho has joined #openstack-nova | 06:46 | |
| *** ttsiouts has joined #openstack-nova | 06:47 | |
| *** nightmare_unreal has joined #openstack-nova | 06:53 | |
| *** slaweq has joined #openstack-nova | 07:01 | |
| *** zhanglong has joined #openstack-nova | 07:03 | |
| *** dklyle has quit IRC | 07:04 | |
| *** maciejjozefczyk has joined #openstack-nova | 07:08 | |
| *** ociuhandu has joined #openstack-nova | 07:13 | |
| *** ociuhandu has quit IRC | 07:18 | |
| *** tesseract has joined #openstack-nova | 07:29 | |
| *** dtantsur|afk is now known as dtantsur | 07:41 | |
| *** xek__ has joined #openstack-nova | 07:46 | |
| *** happyhemant has joined #openstack-nova | 07:46 | |
| bauzas | gibi: stephenfin: good morning, I worked on finishing the implementation for the vGPU multiple types https://review.opendev.org/#/c/715490/ | 07:47 |
| bauzas | I will provide a new change for having a functional test | 07:47 |
| *** mkrai has quit IRC | 07:51 | |
| gibi | bauzas: ack, I will try to look at it today | 07:54 |
| gibi | and good morning | 07:54 |
| gibi | :) | 07:54 |
| *** tosky has joined #openstack-nova | 07:58 | |
| *** ralonsoh has quit IRC | 07:58 | |
| *** spsurya_ has joined #openstack-nova | 07:59 | |
| *** links has joined #openstack-nova | 08:02 | |
| *** alex_xu has joined #openstack-nova | 08:08 | |
| * alex_xu go to super-market today, and found there is machine for tracking people face and body temperature | 08:09 | |
| *** mkrai has joined #openstack-nova | 08:09 | |
| bauzas | alex_xu: gtk | 08:11 |
| *** ralonsoh has joined #openstack-nova | 08:11 | |
| bauzas | the only problem is that some of us are not having temperature issues if they have COVID-19 | 08:11 |
| alex_xu | bauzas: yea | 08:11 |
| alex_xu | bauzas: another fun is the phone tracked here, if you are out of the city, you will be notice to ioslate for 14days | 08:12 |
| bauzas | alex_xu: you're living in Peking, right? | 08:13 |
| alex_xu | bauzas: the joke is if you use vpn, then you are being notice for isolation :) | 08:13 |
| alex_xu | bauzas: yes | 08:13 |
| bauzas | ack okay | 08:13 |
| alex_xu | so Matthew is right in shanghai summit, we are totally tracked :) | 08:15 |
| *** mkrai has quit IRC | 08:29 | |
| *** dpawlik has quit IRC | 08:29 | |
| bauzas | alex_xu: well, we have some kind of discussion in France about being tracked or not | 08:31 |
| bauzas | the problem is that a lot of folks around me are just walking outside while they shouldn't | 08:31 |
| bauzas | and we're now locked down since 3 weeks, and for maybe 3 or 4 weeks again | 08:31 |
| *** priteau has joined #openstack-nova | 08:32 | |
| alex_xu | bauzas: yea, i'm pretty sure you will feel safe on the stree. but yes...the big brother is watching you. but anyway, we discuss the same issue privately :) | 08:32 |
| alex_xu | bauzas: pretty sure you need another 3 weeks...from the experience we have... | 08:33 |
| alex_xu | bauzas: ^ the work above the above one, I'm talking about the another side of tracking :) | 08:34 |
| alex_xu | s/work/word/ | 08:35 |
| bauzas | yeah In understand you | 08:35 |
| alex_xu | bauzas: we have people on the street now, since people already lock in the room since Feb... just shopping mall is pretty empty, but the park is full of people... | 08:36 |
| *** kashyap has joined #openstack-nova | 08:37 | |
| *** dpawlik has joined #openstack-nova | 08:38 | |
| *** martinkennelly has joined #openstack-nova | 08:40 | |
| *** ociuhandu has joined #openstack-nova | 08:41 | |
| *** ociuhandu has quit IRC | 08:45 | |
| *** zhanglong has quit IRC | 08:46 | |
| *** avolkov has joined #openstack-nova | 08:48 | |
| *** luyao has joined #openstack-nova | 08:49 | |
| *** mkrai has joined #openstack-nova | 08:50 | |
| *** martinkennelly has quit IRC | 08:51 | |
| *** tetsuro has quit IRC | 08:54 | |
| *** rcernin has quit IRC | 09:03 | |
| *** ociuhandu has joined #openstack-nova | 09:13 | |
| openstackgerrit | Marcin Juszkiewicz proposed openstack/nova master: libvirt: check for AMD SEV only on x86-64 https://review.opendev.org/714425 | 09:19 |
| *** vishalmanchanda has joined #openstack-nova | 09:24 | |
| bauzas | stephenfin: FWIW, /me starts to review https://review.opendev.org/#/c/704643/ | 09:30 |
| stephenfin | Ta. vGPU is on my list for today :) | 09:30 |
| johnthetubaguy | ah, I was just looking at that too, maybe bad timing | 09:43 |
| bauzas | stephenfin: johnthetubaguy: I'll provide comments and a -1 | 09:46 |
| bauzas | just downloading the patch for verifying somethin | 09:46 |
| johnthetubaguy | stephenfin: is it worth being more specific on what happens when you don't set an extra spec? or describing dependencies, like things that imply numa aware placed VMs, etc | 09:51 |
| gibi | cores, here is a quick functional test stabilization patch needing a second core https://review.opendev.org/#/c/717070 | 09:52 |
| stephenfin | You mean in the descriptions for the extra specs themselves? | 09:52 |
| bauzas | gibi: on it, I'm mostly done | 09:52 |
| johnthetubaguy | stephenfin: somewhere like that | 09:52 |
| gibi | bauzas: thanks | 09:52 |
| johnthetubaguy | stephenfin: comparing it to configuration, basically | 09:53 |
| stephenfin | Yeah, sure. I probably need to better flesh out the descriptions for much of them, including things like what virt driver supports what extra spec | 09:53 |
| stephenfin | In a follow-up though, preferably? I'd like to focus more on making sure every possible extra spec is listed there first | 09:53 |
| johnthetubaguy | stephenfin: I thought you did fairly well on the virt support, I guess there are a bunch of libvirt only in there that are not spelled out | 09:53 |
| johnthetubaguy | stephenfin: yeah, I am OK with that, just wondering about your plans really | 09:54 |
| johnthetubaguy | stephenfin: there are things like PCI alias, when you check the format and not the content, which is typical of json schema checks, just wondering about your thoughts there | 09:54 |
| stephenfin | Yeah, I plan to massively improve the documentation and do things like add cross-referencing | 09:54 |
| *** mkrai has quit IRC | 09:55 | |
| johnthetubaguy | to be clear, I would be fine just checking the keys and not the value, as a step forward, so this is a step ahead of that | 09:55 |
| stephenfin | Ah, so for more detailed things like that, I was planning to leave it to the virt driver for now | 09:55 |
| stephenfin | ditto for things like "you need to specify 'hw:cpu_policy' to use 'hw:cpu_thread_policy'" | 09:56 |
| stephenfin | I wanted to do that via the validator initially but it was way too much /o\ | 09:56 |
| johnthetubaguy | I guess I see this as our global API abstraction, that has been implemented by limited drivers... but yeah, its totally a next step | 09:57 |
| *** mkrai has joined #openstack-nova | 09:59 | |
| bauzas | stephenfin: I don't see anything in the spec about API interop consistency with updates on, say, https://review.opendev.org/#/c/704643/21/nova/api/validation/extra_specs/capabilities.py | 10:05 |
| bauzas | like, I want 'baz' to be accepted in Victoria | 10:05 |
| bauzas | but calling a Ussuri API will tell you 'sorry but no' | 10:05 |
| bauzas | stephenfin: do you plan to address this later on ? | 10:05 |
| johnthetubaguy | its not turned on yet right, haven't set the microversion where it starts | 10:06 |
| *** mkrai has quit IRC | 10:06 | |
| *** mkrai_ has joined #openstack-nova | 10:06 | |
| *** mkrai_ has quit IRC | 10:07 | |
| *** mkrai has joined #openstack-nova | 10:08 | |
| bauzas | johnthetubaguy: indeed, see my comments https://review.opendev.org/#/c/704643/21 | 10:08 |
| stephenfin | bauzas: There's no easy answer for that. I think that's the main reason we had to make the policy configurable. We didn't want to require a microversion to add a new extra spec so people needed a escape lever | 10:08 |
| bauzas | stephenfin: okay, I just feel my biggest concern is that if we avoid to whitelist some key for some filter, then people will see a behavioural change | 10:09 |
| bauzas | right? | 10:09 |
| stephenfin | bauzas: tbh though, it's the exact same issue we see with image metadata today and configuring flavor extra specs, unlike configuring image metadata, is admin-only | 10:09 |
| bauzas | alas. people can use 2.85 microversion if they want to disable it | 10:10 |
| stephenfin | bauzas: Correct, but we have signalled that change with a microversion and we've provided a way to "escape" validation | 10:10 |
| bauzas | stephenfin: yeah I understood it | 10:10 |
| stephenfin | or pass '?validation=permissive', iirc | 10:10 |
| bauzas | stephenfin: I'm just afraid that we could merge something that would opt-in | 10:10 |
| bauzas | close to RC1 | 10:10 |
| bauzas | stephenfin: but we can go like it is now | 10:11 |
| bauzas | at least if we have ways to address issues easilty | 10:11 |
| bauzas | because reviewing all the key and value regexes for every filter isn't an easy thing | 10:11 |
| bauzas | but I don't want to hold this one | 10:11 |
| bauzas | so, my take is : if we mess things up, we all assume that we're about to provide bugfixes that will touch the API behaviour and should be backportable | 10:12 |
| bauzas | if we all agree on this, I'm thumbs up | 10:12 |
| bauzas | gibi: stephenfin: johnthetubaguy: ^ | 10:12 |
| bauzas | or we go permissive *by default* | 10:12 |
| johnthetubaguy | hang on... I am missing something | 10:13 |
| bauzas | (which is not the default case IIUC) | 10:13 |
| johnthetubaguy | don't we currently do zero validation by default right now? | 10:13 |
| gibi | bauzas: fixing bugs in the extra_spec validation will not need a new microversion in my view. | 10:13 |
| johnthetubaguy | including after the proposed validation | 10:13 |
| bauzas | gibi: me too, but I'm just saying that we will change the API behaviour silently | 10:13 |
| johnthetubaguy | hang about | 10:14 |
| bauzas | so we all need to accept it | 10:14 |
| stephenfin | johnthetubaguy: no, after https://review.opendev.org/#/c/704643/ it's enabled by default | 10:14 |
| johnthetubaguy | this totally requires a microversion | 10:14 |
| gibi | bauzas: we fix bugs in the API behavior. Which was allowed before as well | 10:14 |
| bauzas | johnthetubaguy: this is enabled later in another change | 10:14 |
| stephenfin | whoops | 10:14 |
| stephenfin | https://review.opendev.org/#/c/708436/ | 10:14 |
| stephenfin | johnthetubaguy: got that ^ | 10:14 |
| bauzas | 2.86 | 10:14 |
| stephenfin | johnthetubaguy: It's a noop with the first patch. The microversion change to turn it on is a separate change | 10:14 |
| bauzas | tbc, I'm okay with approving https://review.opendev.org/#/c/704643/ provided stephenfin (or me) just changes the commit msg | 10:15 |
| johnthetubaguy | stephenfin: yeah, i.e. its added in a microversion | 10:15 |
| bauzas | but I'm not okay with https://review.opendev.org/#/c/708436/ until we basically agree on the stuff I said | 10:15 |
| bauzas | but as gibi said, bugfixes are accepted, so maybe I'm overthinking | 10:15 |
| johnthetubaguy | so... if you do an old microversion, there is no change | 10:15 |
| bauzas | correct | 10:16 |
| gibi | correct | 10:16 |
| johnthetubaguy | nope, bug fixes than change the API would be really bad right? | 10:16 |
| johnthetubaguy | I am really confused here | 10:16 |
| johnthetubaguy | code looks OK to me, but not agreed with the discussion here | 10:16 |
| gibi | johnthetubaguy: if we broke the API we have to fix them with a bugfix. I don't see how that is a bad thing. | 10:16 |
| johnthetubaguy | gibi: nope, we just keep a broken microversion, we did exactly that in the past, see the limits APIs | 10:17 |
| johnthetubaguy | well, it depends on the bug... | 10:17 |
| stephenfin | we're saying that additions to and bug fixes for the _registry_ of extra specs are okay and wouldn't need a microversion | 10:17 |
| gibi | I'm sure that in other cases we said "client should not have to opt in to get a fix" | 10:17 |
| stephenfin | not the API itself | 10:17 |
| bauzas | okay, see, that's why I wanted some discussion about this | 10:17 |
| johnthetubaguy | hmm... | 10:17 |
| bauzas | ... or we set it to permissive by default | 10:17 |
| johnthetubaguy | permissive by default seems pointless to me, needs to get on by default in a new microversion | 10:18 |
| bauzas | and then we have a later change for turning it by default that would require approvals separately | 10:18 |
| stephenfin | that has to be okay, because operators are currently allowed to specify their own extra specs for use in e.g. custom scheduler filters | 10:18 |
| gibi | I think the differentiator was always like "Was the bug in the API was clearly a bad behavior?" | 10:18 |
| bauzas | johnthetubaguy: I agree, the microversion bump would have to be on the 'turn on by default' | 10:18 |
| stephenfin | if we were to say new extra spec == new microversion, we'd have to take that away from operators | 10:18 |
| johnthetubaguy | it was, "does it impact security" I think | 10:18 |
| johnthetubaguy | stephenfin: we would have to give them a namespace like CUSTOM: | 10:19 |
| johnthetubaguy | so to use the new API microversion, they need to update their flavors | 10:19 |
| stephenfin | if we were doing this from scratch, yes | 10:19 |
| stephenfin | but there are custom extra specs in the wild now, so that ship has sailed | 10:19 |
| johnthetubaguy | well, not quite | 10:20 |
| johnthetubaguy | they would still work with older microversions right? | 10:20 |
| johnthetubaguy | to move forward, they need a migration path | 10:20 |
| bauzas | I don't want to rediscuss the spec https://specs.openstack.org/openstack/nova-specs/specs/ussuri/approved/flavor-extra-spec-validators.html | 10:20 |
| johnthetubaguy | well... I guess we should be comparing this to image properties | 10:21 |
| bauzas | I'm just okay with the plan, but from an implementation point of view, I feel that has necessarly to be discussed | 10:21 |
| stephenfin | yeah, they could use the older microversions | 10:21 |
| stephenfin | compared to image metadata properties, I think we're mostly in the same place now | 10:22 |
| stephenfin | you can add a new image metadata property or modify an existing one (add a new value to an enum) | 10:23 |
| johnthetubaguy | so I am stuggling to understand everyone's position in text form | 10:23 |
| stephenfin | for example, setting the 'hw_pci_numa_affinity_policy' property would be rejected by a Train cloud but not an Ussuri cloud, regardless of microversion | 10:25 |
| stephenfin | (since it was only added this cycle) | 10:25 |
| johnthetubaguy | but to be rejected, they would need to be calling the new microversion right? | 10:26 |
| bauzas | johnthetubaguy: stephenfin: the consensus I think is that https://review.opendev.org/#/c/704643/ is a nobrainer | 10:26 |
| gibi | my position: I assume that the defined key-values are good (reviewed a good chunk of it), if we break something then we will fix it in a bugfix, I don't see other ways to prevent a break. custom extra_specs can be used with old microversion, and custom validator can be added to use the new microversion | 10:27 |
| bauzas | but https://review.opendev.org/#/c/708436/ is debatable until we reach an agreement | 10:27 |
| johnthetubaguy | I think we agree with the patch, but are unsure on future changes? | 10:27 |
| stephenfin | johnthetubaguy: my position is that tying extra spec registry modifications to microversions is a lot of work and gives us almost nothing in return w.r.t. API interop | 10:28 |
| bauzas | johnthetubaguy: I'm okay with https://review.opendev.org/#/c/704643/ because it's just a non-enabled framework | 10:28 |
| bauzas | but we need to draw a line | 10:29 |
| bauzas | we said in the spec that a microvesion would signal the fact that we enforce now | 10:29 |
| bauzas | and I'm still OK with this | 10:29 |
| stephenfin | because A) many extra specs are virt driver specific and therefore do different things on different clouds, B) flavor extra specs are admin-only by default, C) we've provided an escape lever for people that don't want this, and D) this is how image metadata props also work | 10:29 |
| johnthetubaguy | bauzas: because that is what the current patches do right? | 10:30 |
| johnthetubaguy | stephenfin: no, they mean the same thing on every cloud, just not all clouds have them available, at least that is the design | 10:30 |
| bauzas | johnthetubaguy: correct, my only concern is the potential issues we could raise or any potential new keys we would want to provide | 10:31 |
| johnthetubaguy | plus the wild west of custom scheduler stuff, which we need to keep | 10:31 |
| bauzas | and that wasn't addressed in the spec AFAIK | 10:31 |
| johnthetubaguy | bauzas: yeah, agreed with that worry | 10:31 |
| bauzas | there are actually 2 different things in my mind | 10:32 |
| bauzas | A/ a forgotten key | 10:32 |
| bauzas | B/ a new key in a future release | 10:33 |
| bauzas | A/ sounds a bug, and I personnally agree with gibi on the fact we should just accept to backport a bugfix aiming to fix such things | 10:33 |
| bauzas | B/ is still undesigned in my mind | 10:33 |
| *** sean-k-mooney has joined #openstack-nova | 10:34 | |
| bauzas | because 'Cloud OVH' could unsupport 'myfancynewkey' while 'Cloud Vexxhost' would | 10:34 |
| gibi | bauzas: we might now better what to do with B as when we have the situation to add an new in tree key | 10:34 |
| stephenfin | kick that decision to Victoria? :) | 10:35 |
| bauzas | compared to now where both support it (well, actually, just accepting it silently) | 10:35 |
| gibi | bauzas: those OVH and Vexxhost keys won't be in tree keys | 10:35 |
| gibi | so they need to implement custom validators | 10:35 |
| gibi | I guess | 10:35 |
| bauzas | gibi: if this key is written to be used in a Victoria change, and if OVH lags with a Ussuri cloud compared to Vexxhost, then you'll see a change | 10:36 |
| stephenfin | only the cloud operators themselves will see it though | 10:36 |
| gibi | bauzas: do you mean a situation, when I have a script that creates flavors both in OVH and Veexhost? | 10:36 |
| stephenfin | and they'd see the same thing for image metadata | 10:36 |
| bauzas | that's exactly why 3 years ago, we left the custom filters to be wildcards | 10:36 |
| bauzas | gibi: for a flavor, this requires an admin by default policy | 10:37 |
| bauzas | so i wouldn't worry too much | 10:37 |
| gibi | bauzas: then in what situation you worry? | 10:37 |
| *** rcernin has joined #openstack-nova | 10:38 | |
| bauzas | image properties that can be user-defined | 10:38 |
| bauzas | do we expose the flavor extra specs to the users ? I think so too | 10:38 |
| gibi | stephenfin: does the same validator code runs for the image properties? | 10:38 |
| *** mensis has joined #openstack-nova | 10:39 | |
| sean-k-mooney | bauzas: image propertiese cant be userdeined | 10:39 |
| stephenfin | gibi: no, image properties are already validated because they're mapped to o.vos | 10:39 |
| sean-k-mooney | bauzas: we made them ovo years ago | 10:39 |
| bauzas | hem you're right | 10:39 |
| sean-k-mooney | bauzas: yes its configurable by policy but extra specs are shown | 10:40 |
| gibi | bauzas: so the image properties are a different story | 10:40 |
| bauzas | okay, I just to reconsider whether we have a problem or not | 10:40 |
| stephenfin | different but also the same, in as far as they're not tied to microversions | 10:40 |
| sean-k-mooney | gibi: they use to be a blank sting until like extra specs but peopel were exploiting them to pass virt driver specific stuff | 10:40 |
| gibi | adding an extra spec is also admin only by default, like creating flavor | 10:40 |
| bauzas | I said (and gibi too) that A/ (a bugfix for adding a forgotten key) isn't a problem. johnthetubaguy, you okay with this ? | 10:40 |
| gibi | sean-k-mooney, stephenfin: ack, thanks | 10:41 |
| sean-k-mooney | in the current spec we have the query arg to disable validation right | 10:42 |
| * gibi asked these questions to tease out the problematic scenario | 10:42 | |
| johnthetubaguy | sorry in a meeting | 10:42 |
| sean-k-mooney | if we really really want too we can have that vailadte=false flag be valdiate=2020-01 or some other validation version | 10:43 |
| sean-k-mooney | so kind of like the microverions if you want the ussuri behavior then you just set teh right validation version | 10:43 |
| sean-k-mooney | i think thats proably overkill untill people ask for it or clould have issue with it but its a simple enough solution to implement | 10:44 |
| *** derekh has joined #openstack-nova | 10:45 | |
| sean-k-mooney | also morning all o/ | 10:46 |
| bauzas | fwiw, I just left a comment on https://review.opendev.org/#/c/708436/ to summarize our thoughts | 10:46 |
| alex_xu | stephenfin: I just go through them all https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/use-pcpu-and-vcpu-in-one-instance | 10:46 |
| alex_xu | stephenfin: a question for https://review.opendev.org/714658, I think we need to add data migration script, right? it isn't hard I think | 10:47 |
| mensis | Hello, we are currently using OpenStack Pike version. i wanted to ask a question about VM Resize operation. After i resize a virtual machine, when i log in to it via SSH, i get 'kernel:NMI watchdog: BUG: soft lockup - CPU#12 stuck for 29s! [python:9846]' message. And VM is really slow right now. When i check CPU utilization, sometimes i see %1000. Any suggestions, please? | 10:47 |
| bauzas | stephenfin: could you just respin a revision of https://review.opendev.org/#/c/704643/ by just amending the commit msg and explaining why you add into the ignore list H328 ? | 10:47 |
| bauzas | stephenfin: do this and I +2 | 10:48 |
| bauzas | (+2/+W) actually | 10:48 |
| stephenfin | alex_xu: yeah, we could (and probably should) add an online migration for that, yes. It shouldn't be difficult. You saw my patch to update the ComputeNode.numa_topology and Instance.numa_topology fields | 10:49 |
| johnthetubaguy | stephenfin: I think I am ok with the trade off, because its an admin API, I think if we changed the meaning of an existing extra spec (in a big way, like a rename) we would want a microversion (basically we shouldn't do that) | 10:49 |
| stephenfin | bauzas: cool. gimme 5. Finishing up doc rework | 10:49 |
| alex_xu | stephenfin: the huaqiang's one, about adding pcpuset field | 10:49 |
| bauzas | johnthetubaguy: stephenfin: actually, that's a good call | 10:50 |
| alex_xu | stephenfin: oops, misunderstand your word. right, I saw your patch | 10:50 |
| stephenfin | alex_xu: cool :) | 10:50 |
| alex_xu | cool | 10:50 |
| bauzas | johnthetubaguy: stephenfin: we could just say that we won't support new filters with fancy new keys upstream until we somehow come up with a plan | 10:50 |
| bauzas | \o/ | 10:50 |
| stephenfin | johnthetubaguy: Yeah, sticking in TODOs is as close as I've gotten to reworking the extra specs yet | 10:50 |
| bauzas | problem solved. | 10:50 |
| bauzas | johnthetubaguy: stephenfin: that would solidly refrain the need for pushing new filters in-tree and would at least require a spec, which I think is always good | 10:51 |
| bauzas | and since people can provide their own out-of-tree filters and do what they want, they wouldn't be hit | 10:52 |
| bauzas | I like that plan actually | 10:52 |
| gibi | bauzas: replied in https://review.opendev.org/#/c/708436/ | 10:54 |
| bauzas | gibi: cool, we're on the same page | 10:55 |
| *** ierdem has joined #openstack-nova | 10:55 | |
| bauzas | I'd appreciate johnthetubaguy to agree on https://review.opendev.org/#/c/708436/16//COMMIT_MSG@12 | 10:56 |
| bauzas | but if he's ok, I'll change my vote to +2 (at least once I'm fully done with reviewing) | 10:56 |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: api: Add framework for extra spec validation https://review.opendev.org/704643 | 10:57 |
| stephenfin | bauzas: ^ | 10:58 |
| *** tkajinam has quit IRC | 10:59 | |
| bauzas | stephenfin: +W | 11:01 |
| bauzas | stephenfin: but you need to rebase the whole tree now | 11:01 |
| bauzas | (sorry, if it was other thing but a commit msg, I would have proposed a FUP) | 11:01 |
| stephenfin | I'm not sure if I do or if Gerrit will do it for me, but I'm reworking the doc patch so can do so shortly if needed | 11:02 |
| stephenfin | I'll wait to see if there are review comments first | 11:02 |
| *** ociuhandu has quit IRC | 11:05 | |
| *** ociuhandu has joined #openstack-nova | 11:05 | |
| *** ociuhandu has quit IRC | 11:10 | |
| ierdem | Hello guys, i have a question about resizing a running VM. I tried to increase vCPU counts of a running VM and after that i connected succesfully but it is too slow to run anything. When i see process list via "top" command, i saw CPU usage is approximately 1000 percent and it decrease sometimes but increase again. Any suggestions please? | 11:11 |
| * bauzas goes out for lunch | 11:12 | |
| stephenfin | bauzas: out out? :O | 11:12 |
| stephenfin | :P | 11:12 |
| bauzas | out from my room :p | 11:12 |
| bauzas | Who Let the Dogs out out ? | 11:13 |
| bauzas | https://www.youtube.com/watch?v=Qkuu0Lwb5EM | 11:13 |
| sean-k-mooney | well regardign fancy new keys. i would rather just define a custom: name spaces that should be used for user defined extra_specs and declare all other namespaced keys as owned by nova | 11:15 |
| sean-k-mooney | and if a new intree filter wants to add keys it gets its own namespace | 11:16 |
| *** ociuhandu has joined #openstack-nova | 11:16 | |
| sean-k-mooney | if our of tree filter need to define keys the do it via custom: | 11:16 |
| sean-k-mooney | ideally with a prefix e.g. custom:myfilter_mykey | 11:17 |
| *** ociuhandu has quit IRC | 11:23 | |
| *** zhanglong has joined #openstack-nova | 11:25 | |
| *** ttsiouts has quit IRC | 11:26 | |
| *** ttsiouts has joined #openstack-nova | 11:27 | |
| sean-k-mooney | ierdem: i assume you have oversubsrtion enabled on your cloud? | 11:30 |
| sean-k-mooney | ierdem: is the host over subsibed | 11:30 |
| sean-k-mooney | ierdem: it should like you either have someing in the vm that is broken/maliusly consumeing cpu, the vm workload need more vcpus or the host is over subsribed | 11:31 |
| sean-k-mooney | ierdem: simply seeing high cpu usage in the guest is not an indication that something is wrong form a nova point of view | 11:32 |
| ierdem | hmm, how can i check if the host is oversubscribed? | 11:33 |
| ierdem | by the way, before resizing vCPU count, it was working fine | 11:34 |
| kplant | a resize can move the instance to another hypervisor | 11:35 |
| *** JamesBenson has joined #openstack-nova | 11:36 | |
| kplant | if you just do a 'nova hypervisor-show <uuid>' | 11:36 |
| kplant | you can check vcpus vs vcpus_used | 11:36 |
| kplant | if vcpus_used > vcpus; you're over subscribed | 11:36 |
| ierdem | ok, thanks i will try and return to you | 11:37 |
| kplant | also vcpus_used == vcpus is a bad idea, unless nova knows about vcpus you're reserving | 11:38 |
| sean-k-mooney | yes by default resize to same host is disabled so it normally does a move and will only stay on the same host if the weigher consider it to be the best host | 11:38 |
| sean-k-mooney | if you enable same host resize in the config | 11:39 |
| sean-k-mooney | kplant: if you use vcpu_pin_set or (cpu_shared_set and cpu_dedicated_set) then yes vcpu_used == vcpu shared is fine | 11:40 |
| kplant | yeah, if not ideal :-) | 11:40 |
| sean-k-mooney | ideally you should sue the *_sets for doing host reservation instead fo the reserved_host_cpus | 11:41 |
| sean-k-mooney | *use | 11:41 |
| sean-k-mooney | if you use the set you can choose which cpus to reserve and then you can use systemd to run the host process only on thos cores | 11:42 |
| kplant | you can go further and use the bootloader | 11:42 |
| sean-k-mooney | using isolcpus? is so you should really avoid that | 11:42 |
| kplant | my only complaint with *_sets is you can't have open ended ranges | 11:43 |
| kplant | like "3-" | 11:43 |
| kplant | makes it easier to deal with hosts with, not vastly, different configs | 11:43 |
| sean-k-mooney | you can do negations | 11:43 |
| sean-k-mooney | "^0-2" | 11:43 |
| kplant | ooo | 11:43 |
| sean-k-mooney | i think negated ranges works | 11:44 |
| sean-k-mooney | you can negate indivcual cores | 11:44 |
| sean-k-mooney | we prably could add open ended ranges too you could always file a bug/blueprint | 11:45 |
| kplant | i think negated ranges provide the same result | 11:45 |
| kplant | nice | 11:45 |
| sean-k-mooney | ill triple check the code to make sure that works | 11:46 |
| sean-k-mooney | we support it for cpu_realtime_mask | 11:46 |
| sean-k-mooney | but i think its supported in teh *_sets too | 11:46 |
| sean-k-mooney | kplant: this is the code and it inclde the negation example for 1 core | 11:47 |
| openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: template: consider openstack client besides novaclient https://review.opendev.org/717722 | 11:48 |
| *** tbachman has joined #openstack-nova | 11:48 | |
| sean-k-mooney | kplant: yep negated ranges should work https://github.com/openstack/nova/blob/31aa4a6d7f0b8c301b093ad176ee2b44b5d3cec8/nova/virt/hardware.py#L134-L140 | 11:48 |
| sean-k-mooney | sorry miss read that | 11:50 |
| sean-k-mooney | the negation only works with 1 cpu | 11:50 |
| *** tkajinam has joined #openstack-nova | 11:51 | |
| kplant | looking at 113 -> 116 | 11:51 |
| kplant | i think you might have been right originally | 11:51 |
| kplant | it tests for ^str == '^' | 11:51 |
| kplant | then proceeds as normal | 11:51 |
| kplant | the next try/catch is for a range | 11:51 |
| kplant | oof, that's ignoring what you highlighted though | 11:52 |
| sean-k-mooney | https://github.com/openstack/nova/blob/824bc358c25564ed6603d8f94587abd8902fe5af/nova/tests/unit/virt/test_hardware.py#L132-L133 | 11:53 |
| openstackgerrit | Balazs Gibizer proposed openstack/nova master: doc: require openstack client change for every new API microversion https://review.opendev.org/717727 | 11:53 |
| sean-k-mooney | unit tests are awsome :) | 11:53 |
| kplant | that's still not a show stopper | 11:53 |
| sean-k-mooney | although docs would also help | 11:53 |
| *** nweinber has joined #openstack-nova | 11:54 | |
| kplant | as long as the _set string is _only_ negations, every other vcpu should implicitly be available for scheduling, no? | 11:54 |
| sean-k-mooney | that is the behavior i would want as an enduser | 11:54 |
| sean-k-mooney | but no unfortunetly that is not what the behvior is today | 11:56 |
| kplant | i probably just over thought it and gave myself a reason to be lazy and use reserved_host_cpus instead of cpu_dedicated_set | 11:56 |
| kplant | oh, really? | 11:56 |
| openstackgerrit | Merged openstack/nova master: Add info about affinity requests to the troubleshooting doc https://review.opendev.org/715092 | 11:57 |
| sean-k-mooney | it starts with an empty set cpuset_ids = set() | 11:57 |
| openstackgerrit | Merged openstack/nova master: Stabilize functional tests https://review.opendev.org/717070 | 11:57 |
| kplant | eek | 11:57 |
| openstackgerrit | Merged openstack/nova master: Introduce scope_types in security groups policy https://review.opendev.org/716786 | 11:57 |
| sean-k-mooney | and after we loop over every thing cpuset_ids -= cpuset_reject_ids | 11:57 |
| sean-k-mooney | it would not be hard to add that behavior. | 11:57 |
| kplant | i would expect assuming all cpus to actually be faster code | 11:58 |
| kplant | that's more likely in line with what the result will be | 11:58 |
| sean-k-mooney | kplant: that code does not know how many cpus you have | 11:58 |
| kplant | fair, it would come from sql | 11:59 |
| sean-k-mooney | not quite where this is used is on the comptue node before we store the info in the db but anyway if you do have a propoasl for improving this feel free to write it up | 12:00 |
| kplant | is this the better behavior? the current behavior forces the user to be explicit | 12:02 |
| kplant | i guess i can always submit it and get input that way | 12:02 |
| *** rcernin has quit IRC | 12:04 | |
| *** rcernin has joined #openstack-nova | 12:05 | |
| sean-k-mooney | kplant: if you dont set the config options all cores are assumed to be usable | 12:06 |
| sean-k-mooney | kplant: so the idea was of you opt in you should say what you want | 12:06 |
| kplant | i think that mindset still applies, just change the behavior from cpu_*_set to a merge behavior instead of replace | 12:08 |
| kplant | i think that's reasonable | 12:08 |
| sean-k-mooney | kplant: that said i have wanted to remove the reserved_host_cpus options since we first added vcpu_pin_set so makeing it nicer to use the reserved_host_cpus will help with that goal | 12:08 |
| kplant | just want to make sure before i waste time with a bp | 12:08 |
| kplant | waste other people's time* | 12:10 |
| sean-k-mooney | kplant: well we would need to keep backwards compatbliy so we could not make it merge by defaul but we could change the behavior so that if you only specify negation then we woud assume all cpus were valid and apply the negation | 12:10 |
| *** ratailor has quit IRC | 12:11 | |
| kplant | very fair point | 12:11 |
| kplant | that would make cpu_dedicated_set = "4" == all cpus | 12:11 |
| sean-k-mooney | kplant: ill file a bug | 12:12 |
| kplant | appreciate that | 12:12 |
| *** nweinber has quit IRC | 12:13 | |
| *** nweinber has joined #openstack-nova | 12:13 | |
| sean-k-mooney | kplant: the only issue really is that now that we have two ranges cpu_share_set and cpu_dedicated_set | 12:16 |
| sean-k-mooney | it become less uesful but its still useful | 12:16 |
| kplant | i guess the winner between the two would be the more explicit option? | 12:17 |
| kplant | share_set: "1-5" | 12:17 |
| kplant | dedicate_set: "3" | 12:17 |
| sean-k-mooney | no you get an error if you do that | 12:17 |
| sean-k-mooney | and i dont think we want that much magic in the config option parsing | 12:17 |
| *** tkajinam has quit IRC | 12:18 | |
| kplant | that works | 12:18 |
| kplant | so i guess here's a difficult question | 12:19 |
| kplant | if you do mix shared and dedicated on the same host, and leave N cpus unspecified | 12:19 |
| kplant | are they shared? are they dedicated? | 12:19 |
| kplant | with the current implementation they're neither | 12:19 |
| sean-k-mooney | https://bugs.launchpad.net/nova/+bug/1871096 | 12:21 |
| openstack | Launchpad bug 1871096 in OpenStack Compute (nova) "when only a negation is specified for cpu_*_sets we should assume all cpus are vaild and subtract the negated cpus" [Wishlist,Triaged] | 12:21 |
| sean-k-mooney | kplant: if you dont set the config options all cpus will be reported as VCPU resouce class which is used for shared cpus | 12:22 |
| sean-k-mooney | and then we have fallback logic in the scheulder currently to allow pinned guest to land there | 12:23 |
| sean-k-mooney | if you use cpu pinning however we woudl stonly prefer if you used cpu_dedicated_set | 12:23 |
| sean-k-mooney | eventually we might remove the fallback and required it | 12:24 |
| johnthetubaguy | stephenfin: did you update the api-ref for those extra params? | 12:25 |
| *** udesale_ has joined #openstack-nova | 12:28 | |
| *** udesale has quit IRC | 12:31 | |
| kplant | sean-k-mooney: thanks! | 12:31 |
| *** Liang__ has joined #openstack-nova | 12:32 | |
| *** priteau has quit IRC | 12:35 | |
| *** ociuhandu has joined #openstack-nova | 12:42 | |
| stephenfin | johnthetubaguy: Oh, probably not. Will respin now | 12:43 |
| johnthetubaguy | stephenfin: I am struggling with this validation mode stuff... should have been a discussion on the spec I know, but didn't see this one go by | 12:43 |
| johnthetubaguy | not going to block it or anything, just can't see how it works for users | 12:44 |
| stephenfin | The discussion for that was mostly done on IRC, unfortunately :( Earlier versions of the spec didn't have the concept. It was all or nothing | 12:47 |
| johnthetubaguy | stephenfin: that "disabled" mode I think is what worries me, I think the "permissive" isn't so bad, although I would prefer some namespacing of keys, as its easier to understand | 12:47 |
| stephenfin | wdym namespacing of keys? | 12:48 |
| johnthetubaguy | well placement traits is the example | 12:48 |
| johnthetubaguy | if as a user you list the traits | 12:48 |
| johnthetubaguy | you can see which ones are standard, and which ones your deployer has probably made up | 12:49 |
| johnthetubaguy | i.e. can you go read the openstack docs to find out what it is, or otherwise | 12:49 |
| johnthetubaguy | ... I had a lot of pushback in Rackspace on not allowing vendor extensions, which is what extra specs is right. Namespacing the crazy seems the least we could do for our users | 12:50 |
| stephenfin | So insist on a namespace for any custom extra specs? | 12:51 |
| johnthetubaguy | think of the user listing extra specs on the flavors | 12:51 |
| johnthetubaguy | they want to workout what they mean, where do they look | 12:51 |
| johnthetubaguy | you could just see its missing in openstack docs, but that doesn't mean too much | 12:52 |
| johnthetubaguy | then you grep the source code... nothing | 12:52 |
| *** rcernin has quit IRC | 12:52 | |
| johnthetubaguy | then you ask the group running your cloud, and they forgot, the person who added the flavor left last week | 12:52 |
| johnthetubaguy | ... I got carried away there, but really its that problem I am thinking of fixing | 12:53 |
| johnthetubaguy | say we used a namesapce, anything invalid keys could get translated to CUSTOM_<old_name> in the new API microversion | 12:53 |
| johnthetubaguy | there could well be a better fix | 12:54 |
| stephenfin | ah, see I'd been more focused on catching typos or extra specs that don't do anything (like 'hw:mem_policy', which a lot of TripleO roles were setting for years, despite it never being implemented) | 12:55 |
| *** nweinber_ has joined #openstack-nova | 12:56 | |
| johnthetubaguy | ... an API that lists all supported extra_spec keys in a given release, isn't a bad way forward, I would allow adding new keys without a microversion | 12:56 |
| stephenfin | so for this, I was under the impression that things were pretty freeform and outside of the extra specs we control (in-tree ones), they had to stay that way | 12:57 |
| johnthetubaguy | yeah, agreed the typos are important to fix, and you have done that (with or without the disabled and permissive flags) | 12:57 |
| johnthetubaguy | I don't think we want that, its just we never got around to fixing it | 12:57 |
| *** nweinber_ has quit IRC | 12:58 | |
| johnthetubaguy | similar conversions around scheduler hints | 12:58 |
| *** nweinber has quit IRC | 12:58 | |
| *** nweinber_ has joined #openstack-nova | 12:58 | |
| johnthetubaguy | although, that might be just what is in my head | 12:58 |
| *** Luzi has joined #openstack-nova | 13:01 | |
| sean-k-mooney | johnthetubaguy: the reason disabled exists is so we can in the future have a new micoroverions that modify flavor creattion without forceing validation | 13:01 |
| *** nweinber_ has quit IRC | 13:01 | |
| *** nweinber has joined #openstack-nova | 13:01 | |
| sean-k-mooney | johnthetubaguy: flavor specs can be seen by users and we allow third party filters so i dont think traslating them to custom: is valid | 13:02 |
| johnthetubaguy | sean-k-mooney: my worry is it means someone has decided to change how some existing key works, which sounds dangerous to me | 13:02 |
| sean-k-mooney | johnthetubaguy: that is not what htis is for | 13:02 |
| johnthetubaguy | sean-k-mooney: it would only be in a new microversion, for all unsupported keys | 13:02 |
| johnthetubaguy | in a new microversion, the API can basically do what we want (ish), i.e. requires client changes to uses it | 13:03 |
| sean-k-mooney | johnthetubaguy: its so that if you are using non standard flavor extra specs for filters or out of try drivers you can trun off the validation | 13:03 |
| sean-k-mooney | johnthetubaguy: the flavor creation api can but the rest of openstack has to work the same | 13:03 |
| sean-k-mooney | so the filters wont be mircoverion dependant | 13:03 |
| sean-k-mooney | johnthetubaguy: i would not expect the translation to happen by default | 13:05 |
| sean-k-mooney | which is what would happen with nova client | 13:05 |
| sean-k-mooney | which is guess is another reason to prefer osc | 13:05 |
| sean-k-mooney | johnthetubaguy: as i said before i think a good way forward would be to deprecated non namespaces extra specs | 13:07 |
| sean-k-mooney | create a custom: namespcae for those that need it | 13:07 |
| sean-k-mooney | and reserve all other namespaces for nova to use | 13:07 |
| *** eharney has joined #openstack-nova | 13:07 | |
| sean-k-mooney | we have already broken the behvairo or extra specs but we have so far never removed them but i would ok tighening the contract around extra specs and how they can be modifed | 13:09 |
| *** artom has joined #openstack-nova | 13:09 | |
| sean-k-mooney | i aggree however with the current approch in the flavor validation work. | 13:10 |
| *** ociuhandu has quit IRC | 13:11 | |
| *** ociuhandu has joined #openstack-nova | 13:12 | |
| sean-k-mooney | also extra_specs are not for vender extentions. they are missues for that but they are for feature requests | 13:12 |
| openstackgerrit | Merged openstack/nova master: Add test coverage of existing server external events policies https://review.opendev.org/717155 | 13:13 |
| openstackgerrit | Merged openstack/nova master: Introduce scope_types in server external events https://review.opendev.org/717167 | 13:13 |
| *** mkrai has quit IRC | 13:13 | |
| *** lbragstad_ is now known as lbragstad | 13:16 | |
| *** ociuhandu has quit IRC | 13:17 | |
| *** dtantsur is now known as dtantsur|brb | 13:21 | |
| *** ccamacho has quit IRC | 13:25 | |
| *** mriedem has joined #openstack-nova | 13:26 | |
| *** amodi has joined #openstack-nova | 13:32 | |
| *** ccamacho has joined #openstack-nova | 13:35 | |
| *** mdbooth has joined #openstack-nova | 13:39 | |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: api: Add support for new cyborg extra specs https://review.opendev.org/716222 | 13:41 |
| *** spatel has joined #openstack-nova | 13:44 | |
| *** mkrai has joined #openstack-nova | 13:44 | |
| spatel | sean-k-mooney: morning! hope you guys are safe. | 13:44 |
| spatel | I want to talk about - https://bugs.launchpad.net/os-vif/+bug/1837252 | 13:45 |
| openstack | Launchpad bug 1837252 in os-vif stein "[OSSA-2019-004] Ageing time of 0 disables linuxbridge MAC learning (CVE-2019-15753)" [High,Fix committed] - Assigned to sean mooney (sean-k-mooney) | 13:45 |
| spatel | I have two cloud running queens and stein and queens has ageing 300 but stein has 0 | 13:46 |
| spatel | its kind of security issue at this point | 13:46 |
| sean-k-mooney | spatel: that has already been fixed in stien | 13:46 |
| spatel | hmm! why i am still seeing flooding on stein ? i check aging and its 0 ( disabled) | 13:47 |
| sean-k-mooney | spatel: you are using linux bridge or ovs? | 13:47 |
| spatel | Linuxbridge | 13:47 |
| sean-k-mooney | then you dont have the correct version of os-vif | 13:48 |
| sean-k-mooney | let me check if we have don a release | 13:49 |
| spatel | hmm! how do i verify and lets say i don't have then any hand fix ? | 13:49 |
| sean-k-mooney | https://github.com/openstack/os-vif/commit/ec9d5430300c908ea9a1c64151eee7af522a44e7 | 13:49 |
| sean-k-mooney | we merged it onto the stable branch in july | 13:49 |
| sean-k-mooney | spatel: it was fixed in 1.15.2 | 13:50 |
| sean-k-mooney | https://github.com/openstack/releases/commit/f23ff65cbf52ea1c5f7b2985cab56ce23a5264b7 | 13:50 |
| spatel | sean-k-mooney: how do i verify os-vif version? | 13:51 |
| sean-k-mooney | how did you install openstack | 13:51 |
| spatel | openstack-ansible | 13:51 |
| sean-k-mooney | package install or source install | 13:51 |
| spatel | sources | 13:51 |
| spatel | /openstack/venvs/neutron-19.0.0.0rc3.dev6 | 13:52 |
| sean-k-mooney | the source install uses pip in a viruatl env so you would enter the venv for nova and do "pip freeze" | 13:52 |
| *** mkrai_ has joined #openstack-nova | 13:52 | |
| sean-k-mooney | so "source /openstack/nova.../bin activate" followed by "pip freeze | grep vif" then "deactivate" | 13:53 |
| spatel | nova or neutron? | 13:54 |
| sean-k-mooney | so "source /openstack/nova.../bin/activate" followed by "pip freeze | grep vif" then "deactivate" | 13:54 |
| spatel | let me try | 13:54 |
| sean-k-mooney | nova | 13:54 |
| sean-k-mooney | well both should have the same version but neutorn only started using os-vif in stine or train | 13:54 |
| *** zhanglong has quit IRC | 13:54 | |
| sean-k-mooney | nova has used it for much longer | 13:54 |
| *** mkrai has quit IRC | 13:55 | |
| spatel | sean-k-mooney: i am running os-vif==1.15.1 | 13:55 |
| stephenfin | bauzas, gibi: Are you okay with me dropping the 'disabled' policy from https://review.opendev.org/#/c/708436/16/nova/api/openstack/compute/schemas/flavors_extraspecs.py@39 ? | 13:55 |
| spatel | look like buggy version | 13:56 |
| sean-k-mooney | spatel: yep so you need to follow osa insturction to upgrade | 13:56 |
| stephenfin | The idea being that no one can override our definitions of extra specs | 13:56 |
| spatel | is the a way to fix by hand ? | 13:56 |
| sean-k-mooney | you can fix it by hand but no i would not expect that to be the correct way | 13:56 |
| *** damien_r has joined #openstack-nova | 13:56 | |
| stephenfin | as a reminder, "strict" = key and value validation, "permissive" = value validation only, "disabled" = no validation | 13:57 |
| sean-k-mooney | spatel: you should proably just do a minor update to the latest version fo stable stine | 13:57 |
| spatel | sean-k-mooney: i want to try by hand first and then will do upgrade to make sure it works | 13:57 |
| spatel | is this compute side fix or neutron server? | 13:57 |
| spatel | sorry controller i meant | 13:57 |
| stephenfin | so with this, one could configure e.g. 'myfancyextraspec=foo', but never 'hw:cpu_policy=garbage' | 13:57 |
| sean-k-mooney | stephenfin: i dont think we should drop disabled | 13:57 |
| stephenfin | how come? | 13:58 |
| sean-k-mooney | for the resaons i suggested it was required in the first place | 13:58 |
| sean-k-mooney | i want to ensure if we modify the flavor create command in the futre we can still disable validation andu use whatever was intoduced in the new microverion | 13:58 |
| johnthetubaguy | sean-k-mooney: I am not understanding those yet, could you give a concrete example please? | 13:59 |
| *** mkrai_ has quit IRC | 13:59 | |
| bauzas | stephenfin: on a call | 14:00 |
| sean-k-mooney | if we modfiy flavor create to allow setting the flavor accesss as part of a singel atoimc command in 2.xy | 14:00 |
| sean-k-mooney | but still want to disable validation we cant do both without disabled | 14:00 |
| johnthetubaguy | sean-k-mooney: sorry, I don't understand why | 14:00 |
| sean-k-mooney | im assuming 2.xy is after the micoverion that intoduces validation | 14:01 |
| sean-k-mooney | and since its on by default that woudl be an issue right | 14:01 |
| johnthetubaguy | in some future microversion, we can change what is allowed, to whatever we need it to be | 14:01 |
| *** damien_r has quit IRC | 14:01 | |
| sean-k-mooney | permissive still spams the logs with the warning | 14:02 |
| sean-k-mooney | and not everyone wants that | 14:02 |
| *** mkrai has joined #openstack-nova | 14:02 | |
| johnthetubaguy | so like we shouldn't spam the logs, but I don't understand the API request you are trying to describe and why its a problem? | 14:03 |
| sean-k-mooney | its only a problm if i have a vendor exteion | 14:03 |
| openstackgerrit | jayaditya gupta proposed openstack/nova master: Support for --overwrite flag for nova-manage placement heal_allocations command Closes-Bug:#1868997 https://review.opendev.org/715395 | 14:03 |
| sean-k-mooney | or out of tree driver | 14:04 |
| johnthetubaguy | sean-k-mooney: but that is what permissive is there for | 14:04 |
| stephenfin | those are permitted by permissive | 14:04 |
| *** lennyb has quit IRC | 14:04 | |
| sean-k-mooney | permissve still does value valdiation | 14:04 |
| sean-k-mooney | and there is nothing stopping out of tree driver or vendor extions form extenting the allowed values | 14:04 |
| johnthetubaguy | correct, your out of tree thing is BAD if it changes an existing extra_spec, and needs fixing | 14:04 |
| sean-k-mooney | proably but it proably been bad for years | 14:05 |
| johnthetubaguy | agreed | 14:05 |
| sean-k-mooney | i dont really understand why having a way to turn off validation is an issue | 14:05 |
| sean-k-mooney | we have to have that code path for older microverions anyway | 14:06 |
| sean-k-mooney | so its just if disable do old code path | 14:06 |
| sean-k-mooney | e.g. do nothing | 14:06 |
| johnthetubaguy | because it encourages really bad, basically unsupported, behaviour | 14:06 |
| johnthetubaguy | https://docs.openstack.org/nova/latest/contributor/policies.html#out-of-tree-support | 14:06 |
| sean-k-mooney | not really | 14:06 |
| sean-k-mooney | it would encurage it if it was the default | 14:07 |
| sean-k-mooney | but its not | 14:07 |
| sean-k-mooney | anyway i dont want to hold up the validation work as i want to see that land | 14:07 |
| johnthetubaguy | To be clear, our dev policy says we should not support any of these out of tree things | 14:07 |
| sean-k-mooney | so if it must be removed so be it but i dont think that is the correct chose | 14:08 |
| *** mgariepy has joined #openstack-nova | 14:08 | |
| sean-k-mooney | sure but this is not jsut for out of tree things | 14:08 |
| bauzas | johnthetubaguy: stephenfin: I'm back | 14:08 |
| *** efried has quit IRC | 14:08 | |
| sean-k-mooney | some people will just not want to pay the cost of validation | 14:08 |
| *** efried has joined #openstack-nova | 14:09 | |
| johnthetubaguy | sean-k-mooney: they can use the older microversion, till sometime after the the sun becomes a red giant and we up the minimum supported microversion | 14:10 |
| sean-k-mooney | johnthetubaguy: they cant if they want to use a feature in a later microverion at the same time | 14:10 |
| sean-k-mooney | johnthetubaguy: this is modifying flaovr update and create | 14:10 |
| sean-k-mooney | if we modify either after we add valdiation we either always get validation or you have to do two api calls | 14:11 |
| sean-k-mooney | that was my orginal argment for disabled | 14:11 |
| johnthetubaguy | to be clear, this is our policy on these matters: https://docs.openstack.org/nova/latest/contributor/policies.html#out-of-tree-support | 14:11 |
| sean-k-mooney | johnthetubaguy: to be clear my orginal argument was nothing to do with "out of tree support" :) | 14:12 |
| johnthetubaguy | now I think allowing out of tree keys in extra specs has been allowed for so long, we have to support it somehow, which technically violates the policy | 14:12 |
| johnthetubaguy | the question I have is how best to do that | 14:12 |
| sean-k-mooney | johnthetubaguy: we dont require microverion bumps for extra specs | 14:13 |
| johnthetubaguy | the disabled flag basically allows interop problems in the API | 14:13 |
| sean-k-mooney | so there is also no way to determin if an extra spec is supproted form the api | 14:13 |
| johnthetubaguy | sean-k-mooney: we will after this change | 14:13 |
| sean-k-mooney | johnthetubaguy: that was not part of the proposal | 14:13 |
| * bauzas tried to look at the convo but can someone tl;dr: me ? | 14:13 | |
| bauzas | stephenfin: ^ | 14:13 |
| bauzas | ? | 14:13 |
| johnthetubaguy | I was just trying to do that really | 14:13 |
| johnthetubaguy | not very well mind :/ | 14:14 |
| johnthetubaguy | I think we shouldn't have the disabled flag | 14:14 |
| johnthetubaguy | ... actually I don't like the permissive flag, but I agree we need to support the use case it allows | 14:14 |
| sean-k-mooney | johnthetubaguy: where did you think we were agreeign to do a microverion bump on extra spec changes? | 14:14 |
| sean-k-mooney | becasue that was not discussed as part of the spec or planned | 14:15 |
| johnthetubaguy | sean-k-mooney: because any time we change API validation, its a microversion bump | 14:15 |
| sean-k-mooney | not with what was propsoed | 14:15 |
| bauzas | sean-k-mooney: I think we all agree on this | 14:15 |
| *** Luzi has quit IRC | 14:15 | |
| johnthetubaguy | I am more stating the current API rules, which we haven't proposed a change to | 14:15 |
| bauzas | (about providing a microversion for a new extraspec key) | 14:15 |
| sean-k-mooney | bauzas: if we do then we can never do feature backports downstream | 14:16 |
| bauzas | but we can discuss on a spec modification if you want | 14:16 |
| sean-k-mooney | no api microverion bumps in backports remember | 14:16 |
| bauzas | sean-k-mooney: indeed, but it's the same with the existing | 14:16 |
| sean-k-mooney | we allow flavor extra specs to change in backports | 14:16 |
| sean-k-mooney | as they are not consierd a api change downstream | 14:16 |
| sean-k-mooney | flavor extra specs are considerd unversioned | 14:17 |
| johnthetubaguy | well, the spec was approved to make them part of the API | 14:17 |
| bauzas | I mean, if we were discussing about backporting a feature adding a new API modification (even for a filter key), I would have said "sorry but no" | 14:17 |
| sean-k-mooney | johnthetubaguy: i dont recall tat being in the spec | 14:17 |
| johnthetubaguy | these implications where not gone through, that is true | 14:18 |
| sean-k-mooney | johnthetubaguy: its not stated in the spec and i would have objected to that change without makeing flavor extraspecs ovo | 14:19 |
| sean-k-mooney | https://github.com/openstack/nova-specs/blob/master/specs/ussuri/approved/flavor-extra-spec-validators.rst | 14:19 |
| johnthetubaguy | sean-k-mooney: ovo would have been a good approach, that is why I suggested custom namespacing instead of the flag | 14:20 |
| sean-k-mooney | specicilly if we want to make extraspecs versioned then i wouls have propsed seperating this into two fileds | 14:20 |
| bauzas | or rather https://specs.openstack.org/openstack/nova-specs/specs/ussuri/approved/flavor-extra-spec-validators.html ;) | 14:20 |
| sean-k-mooney | one that is an ovo and the other that is a bag for random stings | 14:20 |
| johnthetubaguy | not sure why we need two apis, but it would work | 14:21 |
| sean-k-mooney | johnthetubaguy: backwards compat | 14:21 |
| johnthetubaguy | I mean instead of key namespace like traits | 14:21 |
| johnthetubaguy | anyways, it seems a bit late to reopen all that | 14:21 |
| sean-k-mooney | well we could but it might be hard to detangel | 14:21 |
| sean-k-mooney | perhaps a bit :) | 14:22 |
| sean-k-mooney | so the current approch is predicated on extra_sepcs not beign microverion bumps | 14:22 |
| sean-k-mooney | that is the assumtion that spec is making | 14:22 |
| sean-k-mooney | if we want to be stricter we could but i kind of feel like we shoudl do that as a followup in ussuri | 14:23 |
| sean-k-mooney | *victoria | 14:23 |
| johnthetubaguy | sean-k-mooney: is that stated in the spec though, I think it is just the assumption some people made, and others made the opposite | 14:23 |
| johnthetubaguy | ... but if we add anything in the API we have to support it *for ever* | 14:24 |
| sean-k-mooney | https://specs.openstack.org/openstack/nova-specs/specs/ussuri/approved/flavor-extra-spec-validators.html#rest-api-impact | 14:24 |
| sean-k-mooney | that is all that is stated | 14:24 |
| johnthetubaguy | so I would rather we land the most restrictive thing, and make it more open in the future | 14:24 |
| sean-k-mooney | if we do that it will never happen | 14:25 |
| johnthetubaguy | not if people don't need the extra things, which is great, we get a better smaller API | 14:25 |
| sean-k-mooney | i would like dansmith to weigh in on this before we make any discision | 14:26 |
| johnthetubaguy | me too | 14:26 |
| sean-k-mooney | i understand where you are comming form and i was supportive of this because i wanted the api to be stricter | 14:27 |
| dansmith | should I just read the scrollback? | 14:27 |
| sean-k-mooney | dansmith: we were talking about the flavor extra specs validatiors, specifcally the query arg to contol validation | 14:28 |
| sean-k-mooney | it would appear that some assumed after this spec all extra_spec changes would involve a micro version bump | 14:28 |
| sean-k-mooney | which raise the question why have the policy. i made the opisite assumtion that we would continue to not bump the microver when altering extra_specs | 14:29 |
| dansmith | is the question not the microversion for the validation param, but whether or not we bump the microversion for future validators? | 14:29 |
| *** gary_perkins has quit IRC | 14:30 | |
| sean-k-mooney | there are two questions. do we bump the mircoverion for evey extra_spec change going forward | 14:30 |
| sean-k-mooney | and what are the implciation of the validation parm in either case | 14:31 |
| *** ociuhandu has joined #openstack-nova | 14:31 | |
| dansmith | so, I thought the plan was to make validation optional through the flag, isn't that right? | 14:31 |
| bauzas | dansmith: see the open discussion in https://review.opendev.org/#/c/708436/16//COMMIT_MSG@12 | 14:31 |
| *** gary_perkins has joined #openstack-nova | 14:32 | |
| sean-k-mooney | dansmith: yes that was the plan in the spec | 14:32 |
| dansmith | because if so, I would expect that we don't treat the extra_specs *themselves* as versioned and schema-controlled, which means no microversion for each new one, | 14:32 |
| bauzas | dansmith: the main concern we were discussing is whether there was an interop issue | 14:32 |
| dansmith | and rather the only thing we're versioning is the *behavior* of optionally validating them | 14:32 |
| openstackgerrit | Lee Yarwood proposed openstack/nova master: virt: Provide block_device_info during rescue https://review.opendev.org/700811 | 14:34 |
| openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Add support for stable device rescue https://review.opendev.org/700812 | 14:34 |
| openstackgerrit | Lee Yarwood proposed openstack/nova master: compute: Report COMPUTE_RESCUE_BFV and check during rescue https://review.opendev.org/701429 | 14:34 |
| openstackgerrit | Lee Yarwood proposed openstack/nova master: api: Introduce microverion 2.86 allowing boot from volume rescue https://review.opendev.org/701430 | 14:34 |
| openstackgerrit | Lee Yarwood proposed openstack/nova master: compute: Extract _get_bdm_image_metadata into nova.utils https://review.opendev.org/705212 | 14:34 |
| openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Support boot from volume stable device instance rescue https://review.opendev.org/701431 | 14:34 |
| johnthetubaguy | hmm, I guess I worry *what* validation is actually being done, i.e. what is the supported list of that given Nova endpoint | 14:34 |
| dansmith | johnthetubaguy: meaning you say validation=true and you don't know if the endpoint is new enough to validate numa_nodes or something? | 14:34 |
| bauzas | johnthetubaguy: dansmith: stephenfin: sean-k-mooney: gibi: honestly, can we just enable the feature by being permissive now (and not having a microversion now) and discuss about those concerns in a later change ? | 14:35 |
| dansmith | because if so, the easy way is to make validation=(yes|no|strict), and if you ask for strict validation while passing a key it doesn't support, then it fails and tells you | 14:35 |
| dansmith | bauzas: not sure how we would do that | 14:36 |
| stephenfin | bauzas: It's not permissive at the moment though, it's a no-op | 14:36 |
| johnthetubaguy | its strict by default in the new microversion right? | 14:36 |
| stephenfin | yes | 14:36 |
| bauzas | dansmith: I personnally feel we only need a microversion once we default to be strict | 14:36 |
| dansmith | bauzas: we need a microversion as soon as we add a parameter, AFAIK | 14:36 |
| bauzas | my counter-proposal is to enable this feature but be opt-in | 14:36 |
| johnthetubaguy | dansmith: hmm, I guess, although I thought we were against that approach before. I am more worried about the user listing the extra specs and trying to understand them | 14:37 |
| bauzas | dansmith: yeah, if you mean a extraspec key, I don't disagree | 14:37 |
| dansmith | johnthetubaguy: to be honest, the importance of this feature is pretty low to me | 14:37 |
| johnthetubaguy | the strict/permissive/disabled thing sure needs a microversion to be added | 14:37 |
| dansmith | we have no param right now, so we need a microversion regardless right? | 14:38 |
| johnthetubaguy | dansmith: +1 | 14:38 |
| dansmith | and why as the yes/no/strict thing rejected before? | 14:38 |
| dansmith | *was | 14:38 |
| bauzas | okay, nevermind my counter-proposal, you're right | 14:38 |
| bauzas | a microversion has to be added anyways | 14:38 |
| stephenfin | it's not been rejected: that's what we have at the moment | 14:38 |
| johnthetubaguy | it might have been silently ignored actually... | 14:38 |
| bauzas | but I just feel we need to be permissive as default until we come up with a solid consensus on what we agree | 14:39 |
| sean-k-mooney | johnthetubaguy: that would be an implemation detail of the route lib we are using if it was ignored | 14:39 |
| stephenfin | johnthetubaguy: yeah, no query arg validation on that end point at the moment | 14:39 |
| sean-k-mooney | its still an invalid query | 14:39 |
| johnthetubaguy | (just because that API didn't have any query params before) | 14:39 |
| bauzas | I tried to capture the problems and the proposals in https://review.opendev.org/#/c/708436/16//COMMIT_MSG | 14:39 |
| dansmith | bauzas: I would prefer we default to non-strict validation if that's what you mean | 14:39 |
| bauzas | correct | 14:39 |
| bauzas | 2.86 would enable the feature | 14:40 |
| bauzas | by being permissive | 14:40 |
| johnthetubaguy | dansmith: OK, yeah, that would consistent with not needing a microversion for new extra specs, but lets admins opt into avoid a typo | 14:40 |
| johnthetubaguy | honestly, my preference is to make these a real part of the API, and controlled in microversions, as I find the whole thing a mess to use right now | 14:41 |
| sean-k-mooney | johnthetubaguy: extra specs are generaly backend speicic too so are not portabl in genreal | 14:41 |
| dansmith | johnthetubaguy: but extra_specs are open-ended anyway, so it seems odd to me to have some set of them, not even namespaced, be hard-version-controlled | 14:41 |
| bauzas | sean-k-mooney: and I hate this | 14:41 |
| sean-k-mooney | e.g. they need knoladge of the way the cloud was configured (filters, virtdriver, versions) | 14:41 |
| bauzas | sean-k-mooney: in particular the libvirt knobs we introduced | 14:42 |
| dansmith | sean-k-mooney: that's why I don't really want this validation in the first place | 14:42 |
| bauzas | those are utterly specifics | 14:42 |
| sean-k-mooney | bauzas: sure but without normallising extra_spcs wich is a differnet topic we cant fix that | 14:42 |
| bauzas | hence being permissive | 14:42 |
| sean-k-mooney | bauzas: no the libvirt ones are no worse the the powervm or vmware ones | 14:42 |
| openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add new default roles in tenant tenant usage policies https://review.opendev.org/717587 | 14:42 |
| sean-k-mooney | bauzas: many of the other virt diriver stated using the libvirt ones after we standarised them | 14:43 |
| *** psachin has quit IRC | 14:43 | |
| johnthetubaguy | dansmith: I guess I like what we did with traits, and wanted that for scheduler hints and extra specs, granted its hard to do retrospectively | 14:43 |
| bauzas | (12:17:50) bauzas: ... or we set it to permissive by default | 14:43 |
| bauzas | tbc, there are two alternatives | 14:43 |
| bauzas | option A : let the operators opt-in | 14:44 |
| sean-k-mooney | johnthetubaguy: schduler hints are seperate | 14:44 |
| bauzas | option B : microversion everything | 14:44 |
| johnthetubaguy | sean-k-mooney: that was because we asked them to, so our API is an abstraction that is useful, rather than a bag of virt driver flags | 14:44 |
| dansmith | johnthetubaguy: yeah, doesn't seem like we can do that now without a large migration of everyone's custom specs, or our system ones | 14:44 |
| sean-k-mooney | johnthetubaguy: yep and i would like if we could add back abstrations | 14:44 |
| sean-k-mooney | johnthetubaguy: i noted as much in early verion of the validation patch | 14:44 |
| sean-k-mooney | johnthetubaguy: its why we have we should move x and other comment in the code | 14:45 |
| johnthetubaguy | dansmith: yeah, I would sadly agree that doing that is likely a waste of our valuable time at this point, FWIW, I find the documentation and structure useful on its own, it helped with image props. | 14:45 |
| sean-k-mooney | ya the migration of the instance embeded flavor would be a pain although we could do it if neded | 14:45 |
| dansmith | johnthetubaguy: agree, it's not worth it at this point | 14:46 |
| sean-k-mooney | johnthetubaguy: well part of stephens work is to imporve the docs | 14:46 |
| johnthetubaguy | so my proposal earlier was to alias in the new microversion, so you add a prefix for all non-system ones, but its a pain | 14:46 |
| dansmith | so, crazy idea | 14:46 |
| dansmith | what if we add a new namespace prefix that itself implies that the spec is validated.. something like system:numa_nodes, which would require validation, but otherwise be the same as numa_nodes, at least for the foreseeable future? | 14:47 |
| sean-k-mooney | dansmith: i would prefer to define custom: | 14:48 |
| dansmith | that would give us something we could eventually warn people about, deprecate the non-system numa_nodes in the future and then eventually land on anything not in system: becomes the "wild west of custom stuff" | 14:48 |
| sean-k-mooney | to opt out | 14:48 |
| sean-k-mooney | rather then opt in | 14:48 |
| sean-k-mooney | and just validate all other namespaced extra specs | 14:48 |
| bauzas | sorry, need to drop, urgent kitchen issue | 14:48 |
| dansmith | sean-k-mooney: well, the problem is right now the entire non-namespaced space is custom | 14:48 |
| bauzas | (kids at home, lovely) | 14:48 |
| sean-k-mooney | dansmith: actully not quite | 14:49 |
| sean-k-mooney | we messed up one key | 14:49 |
| sean-k-mooney | but more or less | 14:49 |
| frickler | I'm seeing nova-api lockup when running under apache2 mod-wsgi-py3 on stein with >1 thread enabled, is this a known issue? traceback looks like this and the server stops responding after answering some few requests correctly http://paste.openstack.org/show/PhzU6ZXQnkfrDjyAAAoe/ | 14:49 |
| dansmith | sean-k-mooney: like bauzas says, I think that throwing the switch to opt-out right now is not great | 14:49 |
| sean-k-mooney | ya whcih is why the valdiation parma was added | 14:49 |
| sean-k-mooney | or old micorverions | 14:50 |
| dansmith | right, | 14:50 |
| dansmith | but as johnthetubaguy has said, it's hard for people to know what is being checked or not | 14:50 |
| sean-k-mooney | yes that is true | 14:50 |
| johnthetubaguy | a list of validated namespaces is a nice way forward | 14:51 |
| sean-k-mooney | we also will have different behavior between osc and nova client | 14:51 |
| *** Liang__ has quit IRC | 14:51 | |
| johnthetubaguy | ideally the ones we already use would all fit into that list | 14:51 |
| sean-k-mooney | johnthetubaguy: currently that would be everyting nova knows about in tree | 14:51 |
| stephenfin | I can do permissive for now, then add an API to list all recognized extra specs in a future version with a new microversion. At that point, we could also switch to strict | 14:51 |
| stephenfin | Would that do the trick? | 14:51 |
| johnthetubaguy | the others are just not validated... we land at permissive for everything | 14:51 |
| dansmith | sean-k-mooney: actually, it'd be everything we know how to validate | 14:51 |
| johnthetubaguy | stephenfin: what dansmith is suggesting is a bit nicer, and the reverse of my CUSTOM namespace proposal | 14:52 |
| sean-k-mooney | dansmith: stephenfin added validation for everyting i think | 14:52 |
| sean-k-mooney | dansmith: but yes you are technically correct | 14:52 |
| *** dklyle has joined #openstack-nova | 14:52 | |
| johnthetubaguy | basically be strict for all the in tree namesapces we use today, permissive for everything else | 14:52 |
| stephenfin | johnthetubaguy: right, but who's going to do that work? | 14:52 |
| sean-k-mooney | i had envisioned that after this if you adde an extra specs you would add a validator or extend the existing ones | 14:53 |
| dansmith | sean-k-mooney: it would be easier to enforce that in code with a namespace | 14:53 |
| sean-k-mooney | yes i just dont want operator to have to updated there exiting instance | 14:54 |
| dansmith | well, they won't for the time being | 14:54 |
| dansmith | we still honor the non-namespaced version, unvalidated for the foreseeable future | 14:55 |
| stephenfin | johnthetubaguy: ah, wait, you mean be strict for e.g. 'hw:' namespaced extra specs, but not 'foo:' ? | 14:55 |
| johnthetubaguy | so possible way forward, maybe... we drop the strict and disabled mode, we merge with permissive as the default, but we redefine the API as what dansmith said (i.e. only a microversion to add a new supported namesapce) | 14:55 |
| sean-k-mooney | the other downside to a new name spaces if if we only have one the we have to put everyhtin into it | 14:55 |
| johnthetubaguy | stephenfin: yeah | 14:55 |
| *** cmorpheus is now known as cmurphy | 14:55 | |
| johnthetubaguy | while its not what your code currently does... its actually an API definition / docs change. | 14:55 |
| dansmith | johnthetubaguy: what does permissive mean? just log errors? | 14:55 |
| sean-k-mooney | dansmith: yep | 14:55 |
| stephenfin | nope | 14:56 |
| johnthetubaguy | dansmith: it means only validate known keys, | 14:56 |
| dansmith | sean-k-mooney: I was expecting we'd namespace everything, so things would become system:hw:thing | 14:56 |
| stephenfin | permissive means 'hw:numa_nodes=asdassdf' is rejected, but 'sdfsdfsd:sdfsdf' isn't | 14:56 |
| sean-k-mooney | stephenfin: it logs unknone keys | 14:56 |
| sean-k-mooney | or did you not do that in the end | 14:56 |
| stephenfin | and rejects them with a 4xx error | 14:56 |
| stephenfin | oh,sorry | 14:56 |
| johnthetubaguy | I didn't see a log in the code, thankfully | 14:56 |
| dansmith | that's not permissive | 14:56 |
| stephenfin | logs the unknown keys, yes | 14:56 |
| stephenfin | or does it | 14:56 |
| stephenfin | I'm not sure if I bothered included a log | 14:57 |
| stephenfin | *including | 14:57 |
| bauzas | you didn't | 14:57 |
| stephenfin | ETOOMUCHNOISE | 14:57 |
| sean-k-mooney | dansmith: strict rejects unkown keys with an error | 14:57 |
| sean-k-mooney | permisive allows them and validates the values of keys it know about | 14:57 |
| bauzas | honestly, that's why I want to move on | 14:57 |
| sean-k-mooney | and disabled is a noop | 14:57 |
| dansmith | sean-k-mooney: unknown keys in namespaces like hw: I assume? | 14:57 |
| bauzas | we need to enable something and then discuss on a separate change | 14:57 |
| stephenfin | any unknown keys | 14:57 |
| stephenfin | e.g. hw:cpu_policyyy | 14:58 |
| stephenfin | which is why I wanted strict | 14:58 |
| *** dtantsur|brb is now known as dtantsur | 14:58 | |
| dansmith | but people can use their own custom keys for scheduler behavior yeah? so we can't reject *everything* | 14:58 |
| bauzas | stephenfin: it can still be a recommended choice | 14:58 |
| johnthetubaguy | yeah, I think if we are strict for all known namespaces, it would be much better | 14:58 |
| bauzas | stephenfin: but this would only be a doc thing | 14:58 |
| bauzas | johnthetubaguy: we had this discussion 3 years ago | 14:59 |
| johnthetubaguy | bauzas: we probably did, I might have been wrong then too | 14:59 |
| stephenfin | dansmith: yes, and I've documented how they can add their own validators for whatever extra specs they want | 14:59 |
| bauzas | johnthetubaguy: and we said we had to be accepting *any* key because we can't assume whether it's a typo or a custom key | 14:59 |
| dansmith | wait, | 14:59 |
| stephenfin | assuming they don't want to simply opt of validation | 14:59 |
| sean-k-mooney | dansmith: right hence the idea of having "custom:" namespace where you can add stuff we woudl never validate | 14:59 |
| dansmith | so in strict mode they have to write code in order to be able to use things like the json filter? | 14:59 |
| bauzas | the 'custom:' namespace is good but this requires some proper signaling (and at least one cycle of deprecation) | 15:00 |
| sean-k-mooney | dansmith: json filter uses shcduler hint | 15:00 |
| bauzas | ie. we say "okay, look, custom filters will continue to work without any change in U and V" | 15:00 |
| dansmith | there's some filter we can hit custom fields on the flavor isn't there? | 15:00 |
| bauzas | "but starting from W, you will need to change your flavors to use a custom: prefix" | 15:00 |
| sean-k-mooney | dansmith: yes compute capablity filter and the aggartioninstnaceType filter | 15:01 |
| stephenfin | yes, 'CapabilitiesFilter' and 'AggregateInstanceExtraSpecsFilter' filters | 15:01 |
| sean-k-mooney | dansmith: both are supproted | 15:01 |
| stephenfin | and I've enumerated the known values for both | 15:01 |
| sean-k-mooney | it jsut allows any key | 15:01 |
| sean-k-mooney | if you use there namespaces | 15:01 |
| stephenfin | *known keys | 15:01 |
| stephenfin | the values are basically wildcards because of how flexible thoseare | 15:01 |
| openstackgerrit | Lee Yarwood proposed openstack/nova master: workarounds: Add option to disable native LUKSv1 decryption by QEMU https://review.opendev.org/708030 | 15:01 |
| openstackgerrit | Lee Yarwood proposed openstack/nova master: workarounds: Add option to locally attach RBD volumes https://review.opendev.org/708029 | 15:01 |
| stephenfin | *those are | 15:01 |
| melwitt | frickler: yes https://docs.openstack.org/releasenotes/nova/stein.html#known-issues | 15:01 |
| sean-k-mooney | stephenfin: you allow any key in there namespace right | 15:02 |
| *** beekneemech is now known as bnemec | 15:02 | |
| sean-k-mooney | because those filters allow arbitray key names as long as they are in the same namespaces | 15:02 |
| bauzas | sean-k-mooney: dansmith: stephenfin: honestly, I think I'm +2 on a deprecation policy for those filters | 15:02 |
| bauzas | like, no longer supporting those wildcards at W | 15:03 |
| bauzas | and the same goes for custom filters | 15:03 |
| sean-k-mooney | bauzas: that a sperate topic | 15:03 |
| bauzas | sean-k-mooney: no, that's tied | 15:03 |
| stephenfin | sean-k-mooney: not the Capabilities filter anyway - those have to map to a field on the HostState object or ComputeNode o.v.o | 15:03 |
| frickler | melwitt: ha, thx for pointing me to the obvious docs | 15:03 |
| bauzas | we can't be strict on enforcing keys until we fixed those messed keys | 15:03 |
| sean-k-mooney | stephenfin: ya i was thinking of the other one | 15:03 |
| bauzas | (internal team meeting FTW) | 15:03 |
| sean-k-mooney | bauzas: we can they have there own namespace | 15:04 |
| dansmith | okay I see the a.i.e.s filter already has a namespace, I didn't realize | 15:04 |
| stephenfin | sean-k-mooney: yes, that's wildcarded | 15:04 |
| sean-k-mooney | but ya i guess i should join intrenal call | 15:04 |
| stephenfin | yup, since Grizzly (thanks, Intel) | 15:04 |
| bauzas | that bears me (joke) | 15:04 |
| sean-k-mooney | dansmith: yep i made sure those fileter would still work in the spec review | 15:05 |
| sean-k-mooney | sicne they used to be used for dpdk/numa stuff alot | 15:05 |
| openstackgerrit | Lee Yarwood proposed openstack/nova master: DNM - Test stable device rescue tests with BFV instances https://review.opendev.org/710050 | 15:05 |
| bauzas | honestly, that's now 4 hours we're discussing over this and I'm out of steam now | 15:06 |
| dansmith | bauzas: wait until people start asking about how to do this in osc in a year :) | 15:07 |
| bauzas | so, again, either we make this permissive now or we just punt this for now | 15:07 |
| bauzas | ... | 15:08 |
| stephenfin | johnthetubaguy: so in this permissive for unknown namepaces only model, would we reject e.g. every unrecognized 'hw:' extra spec? | 15:08 |
| bauzas | dansmith: I just feel we made too many gifts in the past with custom and in-tree filters | 15:08 |
| johnthetubaguy | stephenfin: I think that is a yes, to prevent the most obvious typos | 15:08 |
| bauzas | we should ask for some return | 15:08 |
| johnthetubaguy | stephenfin: or rather, for the user to know things are validated if its in a known namespace | 15:08 |
| stephenfin | johnthetubaguy: okay, in that case do we need to continue to provide a way to disable validation in case there are people there with e.g. 'hw:something_custom' right now? | 15:09 |
| johnthetubaguy | stephenfin: bonus, we would only need a microversion to add a new namespace | 15:09 |
| openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Remove MIN_LIBVIRT_MULTIATTACH https://review.opendev.org/710238 | 15:10 |
| johnthetubaguy | stephenfin: I think we would just drop that flag for now, and see how people take it | 15:10 |
| johnthetubaguy | I like the simpler API of there being a list of validated namespaces | 15:10 |
| johnthetubaguy | stops all the mess of migrating people towards "custom" something | 15:10 |
| stephenfin | okay, so unless our hand was forced we'd be essentially saying "you need to change this if you ever want to use this microversion" | 15:11 |
| johnthetubaguy | I think so, yes | 15:12 |
| johnthetubaguy | well, you can use the new API version to add your new key, and delete the old bad key | 15:12 |
| stephenfin | Cool. Last one. Do we still need strict in this model (or that parameter in general), seeing as we are effectively strict for all recognized namespaces | 15:12 |
| johnthetubaguy | I don't think so | 15:12 |
| johnthetubaguy | at least not to start with | 15:13 |
| stephenfin | Okay, so I can drop that parameter | 15:13 |
| johnthetubaguy | you could typo the namespace... but, hey, at least we are helping you more now | 15:13 |
| stephenfin | That all works for me. gibi, bauzas, sean-k-mooney, dansmith: any significant concerns with that before I do the needful ^ ? | 15:13 |
| stephenfin | (last 15 lines or so of scrollback) | 15:14 |
| openstackgerrit | Lee Yarwood proposed openstack/python-novaclient master: Microversion 2.86 - Stable device boot from volume rescue https://review.opendev.org/714956 | 15:14 |
| johnthetubaguy | stephenfin: for completeness, the old microversions are still unchanged, no validation at all there | 15:15 |
| stephenfin | Yeah, agreed | 15:15 |
| johnthetubaguy | sorry that all took so long, but I think what we have at the end is better | 15:16 |
| johnthetubaguy | and easier to document and use :) | 15:16 |
| sean-k-mooney | ill read back in a few minutes. | 15:16 |
| lyarwood | stephenfin: ah, both of us are going for 2.86 again, want me to move to 2.87? | 15:17 |
| stephenfin | lyarwood: Yup :) Your call but it might make sense | 15:17 |
| lyarwood | stephenfin: yup no issues, I wasn't paying attention | 15:18 |
| bauzas | stephenfin: pardon my French but I may have misunderstood the agreement in between you and johnthetubaguy | 15:20 |
| bauzas | what's the outcome when it's said "drop this flag" ? drop the microversion ? | 15:21 |
| stephenfin | keep the microversion, but drop the '?validate' argument | 15:21 |
| bauzas | and the default being ? | 15:21 |
| bauzas | permissive as I can understand crom 'I don't think so' from johnthetubaguy ? | 15:22 |
| bauzas | from* | 15:22 |
| stephenfin | strict for all known namespaces (hw:, os:, vmware:, ...) | 15:22 |
| stephenfin | don't care for anything outside that set | 15:22 |
| bauzas | I'm cool with this | 15:24 |
| bauzas | stephenfin: ^ | 15:24 |
| bauzas | no upgrade impact, pretty clear | 15:24 |
| bauzas | stull leaves nothing unchanged except for already-defined namespaces | 15:24 |
| bauzas | that works for me | 15:24 |
| *** vishalmanchanda has quit IRC | 15:33 | |
| *** mkrai has quit IRC | 15:36 | |
| *** ociuhandu has quit IRC | 15:36 | |
| *** ierdem has quit IRC | 15:37 | |
| *** ociuhandu has joined #openstack-nova | 15:37 | |
| *** gyee has joined #openstack-nova | 15:38 | |
| *** ociuhandu has quit IRC | 15:42 | |
| *** alex_xu has quit IRC | 15:57 | |
| gibi | stephenfin: and if you have out of tree hw:xxx key then add a custom validator? | 15:59 |
| gibi | or use the old microversion | 15:59 |
| stephenfin | yes | 15:59 |
| gibi | so custom validators can add to in-tree name spaces? | 16:00 |
| stephenfin | they shouldn't but they could, yes | 16:00 |
| gibi | OK | 16:00 |
| stephenfin | we just prevent overriding specific extra specs e.g. 'hw:cpu_policy' | 16:01 |
| gibi | OK, cannot override in-tree defined validators | 16:01 |
| melwitt | gmann: we have a minor emergency regarding the policy warning logging (see the -infra channel). it's melting the logstrash indexing | 16:01 |
| gibi | what if I have namespaced out of tree keys today? like ericsson:awesome_feature_flag ? | 16:02 |
| stephenfin | nothing happens until you add a validator | 16:02 |
| stephenfin | we ignore all unknown namespaces | 16:02 |
| gibi | OK, make sense | 16:02 |
| openstackgerrit | John Garbutt proposed openstack/nova master: Update quota_class APIs for db and api limits https://review.opendev.org/712143 | 16:02 |
| stephenfin | (and those without namespaces, fwiw) | 16:02 |
| openstackgerrit | John Garbutt proposed openstack/nova master: Add stub unified limits driver https://review.opendev.org/712137 | 16:03 |
| openstackgerrit | John Garbutt proposed openstack/nova master: Assert quota related API behavior when noop https://review.opendev.org/712140 | 16:03 |
| gibi | stephenfin, johnthetubaguy: seems like a good idea. | 16:03 |
| openstackgerrit | John Garbutt proposed openstack/nova master: Make unified limits APIs return reserved of 0 https://review.opendev.org/712141 | 16:03 |
| openstackgerrit | John Garbutt proposed openstack/nova master: Add logic to enforce local api and db limits https://review.opendev.org/712139 | 16:03 |
| openstackgerrit | John Garbutt proposed openstack/nova master: Enforce api and db limits https://review.opendev.org/712142 | 16:03 |
| openstackgerrit | John Garbutt proposed openstack/nova master: Update quota_class APIs for db and api limits https://review.opendev.org/712143 | 16:04 |
| johnthetubaguy | melwitt: oops :/ | 16:05 |
| johnthetubaguy | probably means the same for our users | 16:05 |
| melwitt | yeah :( we were just talking about this the other day but I didn't realize how intense it is | 16:05 |
| johnthetubaguy | does it mean almost every API call? | 16:06 |
| johnthetubaguy | or just a massive storm on restart? | 16:06 |
| melwitt | we need to get it removed asap. we were already talking to gmann about it and he was cool with removing it and doing a reno-only announcement re: policy changes | 16:06 |
| johnthetubaguy | melwitt: is there a patch up? | 16:06 |
| melwitt | looks like every API call | 16:06 |
| johnthetubaguy | yeah, that isn't right :/ | 16:07 |
| melwitt | no not that I know of, no patch yet | 16:07 |
| *** rpittau is now known as rpittau|afk | 16:08 | |
| *** xek__ is now known as xek | 16:09 | |
| *** dtantsur is now known as dtantsur|afk | 16:11 | |
| openstackgerrit | Alexandre arents proposed openstack/nova master: Calculate disk_over_committed for raw instances https://review.opendev.org/717037 | 16:14 |
| johnthetubaguy | its probably all system only API calls... as our tests probably don't have a system admin user yet | 16:14 |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: api: Add microversion for extra spec validation https://review.opendev.org/708436 | 16:16 |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Add documentation for flavor extra specs https://review.opendev.org/710037 | 16:16 |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: Drop concept of '?validation' parameter https://review.opendev.org/717789 | 16:16 |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Move description of groups to document itself https://review.opendev.org/717790 | 16:16 |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Add 'nova' domain and include extra specs in it https://review.opendev.org/717791 | 16:16 |
| stephenfin | johnthetubaguy: I think that matches up with what you were expecting ^ | 16:16 |
| stephenfin | gibi: Also, I retooled the docs. It's _much_ nicer now (we can cross-reference!) | 16:17 |
| gibi | stephenfin: will look but sounds awesome! | 16:17 |
| openstackgerrit | John Garbutt proposed openstack/nova master: Update limit APIs https://review.opendev.org/712707 | 16:19 |
| *** tesseract has quit IRC | 16:21 | |
| *** mensis has quit IRC | 16:21 | |
| * bauzas calls it a day, see you folks | 16:22 | |
| gibi | bauzas: o/ sorry I could not get to the vgpu series of yours | 16:23 |
| gibi | maybe tomorrow | 16:24 |
| bauzas | gibi: thanks and no worries | 16:24 |
| bauzas | gibi: in the meantime, I'll write to provide a func change for seeing the behaviour | 16:24 |
| openstackgerrit | John Garbutt proposed openstack/nova master: Update quota sets APIs https://review.opendev.org/712749 | 16:24 |
| gibi | bauzas: thanks | 16:24 |
| openstackgerrit | John Garbutt proposed openstack/nova master: Tell oslo.limit how to count nova resources https://review.opendev.org/713301 | 16:29 |
| *** udesale_ has quit IRC | 16:30 | |
| openstackgerrit | John Garbutt proposed openstack/nova master: Enforce resource limits using oslo.limit https://review.opendev.org/615180 | 16:33 |
| *** evrardjp has quit IRC | 16:36 | |
| *** ircuser-1 has joined #openstack-nova | 16:37 | |
| *** evrardjp has joined #openstack-nova | 16:37 | |
| melwitt | johnthetubaguy: I wonder if we should revert https://review.opendev.org/701624 for now? or is there some other way to approach this cc gmann | 16:40 |
| gibi | do somebody know the irc nick of the owner of https://review.opendev.org/#/c/713089/ ? we would need to release the novaclient this week and patches are blocked on this | 16:41 |
| melwitt | gibi: looks like it might be alisterle https://launchpad.net/~alistarle | 16:43 |
| gibi | melwitt: thenk I will try to ping him when he is up | 16:43 |
| johnthetubaguy | melwitt: are we sure we know what is causing the logs, I think it might be the scope chagnes | 16:43 |
| openstackgerrit | John Garbutt proposed openstack/nova master: Add legacy limits and usage to unified limits https://review.opendev.org/713498 | 16:44 |
| openstackgerrit | John Garbutt proposed openstack/nova master: Update quota apis with keystone limits and usage https://review.opendev.org/713499 | 16:44 |
| openstackgerrit | John Garbutt proposed openstack/nova master: Add reno for unified limits https://review.opendev.org/715271 | 16:44 |
| melwitt | johnthetubaguy: I don't have deep enough knowledge to know that but I was thinking if we unmarked the things as deprecated it would stop the deprecated messages? | 16:45 |
| melwitt | I guess I would propose the revert as -W to see for sure | 16:45 |
| johnthetubaguy | we have about 20 or more patches like that though | 16:45 |
| johnthetubaguy | do you have the log message causing the issue to hand? | 16:45 |
| melwitt | oh really? it's not just the one that marks deprecated | 16:45 |
| johnthetubaguy | logs I am looking at at failing to load now... which could be related | 16:45 |
| johnthetubaguy | we have deprecated loads though | 16:46 |
| melwitt | ok I see | 16:46 |
| johnthetubaguy | we might have to change the logging config for oslo.policy | 16:46 |
| johnthetubaguy | assuming that is possible somehow | 16:46 |
| gmann | johnthetubaguy: melwitt let me propose it to disable it temp and then find a good way | 16:47 |
| johnthetubaguy | gmann: thanks, sounds like a plan | 16:47 |
| johnthetubaguy | gmann: which log message is it? | 16:47 |
| melwitt | this is an example, https://6d82362f2cdc504b27f1-9f757b11a1d2b00e739d31e1ecad199a.ssl.cf5.rackcdn.com/717662/1/check/tempest-integrated-compute/b3260ce/controller/logs/screen-n-api.txt | 16:48 |
| gmann | johnthetubaguy: it is from base rule | 16:48 |
| melwitt | gmann: yay you're here, thank you. once we disable it I need to tell clarkb so he can dump the current logs from indexing. he said it will never catch up and we need to start fresh | 16:49 |
| openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Disable the policy warning temporary https://review.opendev.org/717802 | 16:55 |
| gmann | melwitt: johnthetubaguy ^^ | 16:56 |
| *** ociuhandu has joined #openstack-nova | 16:57 | |
| johnthetubaguy | gmann: assuming that works, lets do it. | 16:58 |
| gmann | johnthetubaguy: yeah, let's wait for gate result also | 16:59 |
| melwitt | gibi: fyi ^ patch to temporarily disable policy deprecation warnings currently making nova-api logs huge with log spam (example is linked few messages back in backscroll) | 17:01 |
| *** ttsiouts has quit IRC | 17:03 | |
| johnthetubaguy | oh my, its very chatty :/ | 17:04 |
| melwitt | yeah it's ... a lot more logging than I had realized | 17:05 |
| *** ociuhandu has quit IRC | 17:08 | |
| dansmith | only 15k in that one log | 17:09 |
| melwitt | "only" | 17:09 |
| johnthetubaguy | ah, right, that isn't so bad then (ducks) | 17:09 |
| dansmith | melwitt: yes, extreme sarcasm around the only | 17:10 |
| melwitt | I know, I thought it was funny | 17:10 |
| gmann | johnthetubaguy: melwitt dansmith : to sync up on some approach on policy warning and adopting new behaviour ( lbragstad and I discussed last week i think) | 17:11 |
| lbragstad | o/ | 17:12 |
| gmann | Warning: 1. do not log warning for policy changing defaults (but still not enabled as we support old defaults also) 2. do log warning where policy names are changed (granular cases in our case) | 17:12 |
| *** nightmare_unreal has quit IRC | 17:12 | |
| gmann | New behaviour: 1. one way was to make enforce_policy as all-new-together a flag to disable the deprecation rules also. means if this flag is true then support only new defaults_scope | 17:13 |
| lbragstad | i was thinking about this a little more, did we want to provide a way for people to opt into the new defaults without writing to the policy file (again)? | 17:14 |
| gmann | yeah, that one. with enforce_scope flag right ? | 17:15 |
| melwitt | I thought there was a way, by setting enforce_scope = True? or is that not something a user can do | 17:15 |
| gmann | yeah there is but that only control scope_type checks not the deprecated old rules | 17:16 |
| lbragstad | kind of - but we didn't expect to use that option to adjust deprecation behavior | 17:16 |
| melwitt | oh I see | 17:16 |
| gmann | or we can do with new flag which we can keep it for future usual policy changes also | 17:17 |
| lbragstad | but i can understand the usecase where deployers want to opt into the new policy system without having to write "new" defaults back into the policy file to get around noisy logs and the logical OR in oslo.policy | 17:17 |
| gmann | so when enforce_scope if true by default or we remvoe that in future we can keep new flag for deprecation things always | 17:18 |
| lbragstad | i guess that's the part i'd like to walk through, does it make sense to reuse that option or do we need something new? | 17:18 |
| bnemec | I think they're separate things. enforce_scope is a temporary thing while everyone gets their policies scope-ready, this new deprecation flag is something that we would keep indefinitely because it will have use any time a policy is deprecated for any reason. | 17:20 |
| gmann | IMO, something new make sense for considering the future cases | 17:20 |
| *** kaisers has quit IRC | 17:21 | |
| bnemec | Also, I should note that we are past all of the freeze dates that apply to oslo.policy, so whatever we do it needs to be ASAP so we can request an FFE. | 17:21 |
| gmann | bnemec: yeah that is what i was thinking yesterday and about to ask if oslo.policy is already released ? | 17:22 |
| sean-k-mooney | stephenfin: ill review the new version you pushed. i think i can live with that compromise but im not entirely sure its an improvemnt | 17:24 |
| bnemec | Yeah, that ship has sailed. Our last planned feature release (which was an FFE itself) happened Friday. | 17:25 |
| gmann | ok | 17:25 |
| bnemec | I think this is worth an FFE, but it's no longer up to me alone. | 17:25 |
| gmann | I (or if lbragstad want to do) can propose that if all agree on that ? | 17:26 |
| *** kaisers has joined #openstack-nova | 17:27 | |
| lbragstad | gmann i'm happy to review if you push something up | 17:28 |
| gmann | lbragstad: ok. I will try to push that today. | 17:30 |
| *** kaisers has quit IRC | 17:34 | |
| *** kaisers has joined #openstack-nova | 17:38 | |
| *** ttsiouts has joined #openstack-nova | 17:40 | |
| *** ttsiouts has quit IRC | 17:45 | |
| openstackgerrit | Merged openstack/nova stable/rocky: Unplug VIFs as part of cleanup of networks https://review.opendev.org/715404 | 17:50 |
| *** dpawlik has quit IRC | 17:51 | |
| *** ttsiouts has joined #openstack-nova | 17:52 | |
| *** ralonsoh has quit IRC | 18:03 | |
| *** tonyb[m]_ has joined #openstack-nova | 18:06 | |
| *** lseki_ has joined #openstack-nova | 18:07 | |
| *** tonyb[m] has quit IRC | 18:08 | |
| *** lseki has quit IRC | 18:08 | |
| *** tonyb[m]_ is now known as tonyb[m] | 18:08 | |
| *** lseki_ is now known as lseki | 18:08 | |
| *** links has quit IRC | 18:08 | |
| openstackgerrit | Sasha Andonov proposed openstack/nova master: rbd_utils: increase _destroy_volume timeout https://review.opendev.org/705764 | 18:11 |
| *** d34dh0r53 has quit IRC | 18:13 | |
| *** d34dh0r53 has joined #openstack-nova | 18:14 | |
| *** ttsiouts has quit IRC | 18:14 | |
| *** mlavalle has joined #openstack-nova | 18:18 | |
| openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Fix new context comparison workaround in base tests class https://review.opendev.org/717825 | 18:22 |
| *** derekh has quit IRC | 18:24 | |
| openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Fix new context comparison workaround in base tests class https://review.opendev.org/717825 | 18:26 |
| *** ociuhandu has joined #openstack-nova | 18:32 | |
| *** ociuhandu has quit IRC | 18:52 | |
| *** ociuhandu has joined #openstack-nova | 18:53 | |
| *** kukacz has quit IRC | 18:55 | |
| *** kukacz has joined #openstack-nova | 18:57 | |
| *** ociuhandu has quit IRC | 18:59 | |
| openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Fix misc comments on policy work https://review.opendev.org/717835 | 18:59 |
| *** dking_desktop has quit IRC | 19:20 | |
| *** ccamacho has quit IRC | 20:15 | |
| *** nweinber has quit IRC | 20:17 | |
| *** haleyb has joined #openstack-nova | 20:18 | |
| *** xek has quit IRC | 20:37 | |
| openstackgerrit | Lee Yarwood proposed openstack/nova master: workarounds: Add option to disable native LUKSv1 decryption by QEMU https://review.opendev.org/708030 | 21:01 |
| openstackgerrit | Lee Yarwood proposed openstack/nova master: workarounds: Add option to locally attach RBD volumes on compute hosts https://review.opendev.org/708029 | 21:01 |
| *** ociuhandu has joined #openstack-nova | 21:02 | |
| *** ociuhandu has quit IRC | 21:06 | |
| openstackgerrit | Merged openstack/nova master: Disable the policy warning temporary https://review.opendev.org/717802 | 21:13 |
| *** efried has quit IRC | 21:34 | |
| *** efried has joined #openstack-nova | 21:36 | |
| sean-k-mooney | melwitt: regarding the oslo.policy cahnge. if we cant deliver that via a FFE is the plan to leave the deprecation warning disabled or do something slighly hacky like monky patch oslo.policy to do what we want for ussuri | 21:40 |
| sean-k-mooney | melwitt: i know we have monkeypatched other libs in the past but i would feel weired doing it to oslo so i assume it would be left disabled | 21:41 |
| melwitt | sean-k-mooney: yeah, I'm thinking about the same thing and I am not sure. I would think leave it disabled in the worst case scenario of not being able to solve it in oslo.policy via FFE. but I know that leaves us in a bind too wrt to any policy name changes that are also occurring | 21:44 |
| melwitt | gmann: did you have any thoughts on this yet, what do we do if we can't get the oslo.policy stuff figured out? ^ | 21:44 |
| *** slaweq has quit IRC | 21:47 | |
| gmann | melwitt: I will push both things on oslo side today if those cannot be merged due to any reason, then i think we left with no option than keep it disabled. | 21:49 |
| *** spatel has quit IRC | 21:49 | |
| gmann | we are saying to support the old defaults by 2 cycles at least so existing deployement are not going to break immediately which mean no-warning things also not so bad | 21:50 |
| melwitt | gmann: ack thanks | 21:58 |
| melwitt | that's true we have some time to sort it out from that perspective | 21:59 |
| *** JamesBenson has quit IRC | 22:00 | |
| *** m1p has joined #openstack-nova | 22:24 | |
| *** m1p has left #openstack-nova | 22:26 | |
| *** rcernin has joined #openstack-nova | 22:30 | |
| *** maciejjozefczyk has quit IRC | 22:33 | |
| *** maciejjozefczyk has joined #openstack-nova | 22:36 | |
| *** tkajinam has joined #openstack-nova | 22:42 | |
| *** mriedem has left #openstack-nova | 22:43 | |
| *** Liang__ has joined #openstack-nova | 23:07 | |
| sean-k-mooney | gmann: the oslo team are currently asking for an FFE for some libs so if we want to get this in we should ask them to include it in that FFE | 23:14 |
| gmann | sean-k-mooney: yeah, I am working on changes and will ask FFE | 23:16 |
| *** tosky has quit IRC | 23:28 | |
| *** Liang__ has quit IRC | 23:39 | |
| openstackgerrit | Luigi Toscano proposed openstack/nova master: zuul: Switch to the Zuulv3 grenade job https://review.opendev.org/704364 | 23:41 |
| *** brinzhang has joined #openstack-nova | 23:57 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!