Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-04-06
10:18:52 stephenfin if we were to say new extra spec == new microversion, we'd have to take that away from operators
10:18:57 johnthetubaguy it was, "does it impact security" I think
10:19:17 johnthetubaguy stephenfin: we would have to give them a namespace like CUSTOM:
10:19:34 johnthetubaguy so to use the new API microversion, they need to update their flavors
10:19:45 stephenfin if we were doing this from scratch, yes
10:19:57 stephenfin but there are custom extra specs in the wild now, so that ship has sailed
10:20:05 johnthetubaguy well, not quite
10:20:17 johnthetubaguy they would still work with older microversions right?
10:20:27 johnthetubaguy to move forward, they need a migration path
10:20:27 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:21:02 johnthetubaguy well... I guess we should be comparing this to image properties
10:21:06 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:47 stephenfin yeah, they could use the older microversions
10:22:50 stephenfin compared to image metadata properties, I think we're mostly in the same place now
10:23:22 stephenfin you can add a new image metadata property or modify an existing one (add a new value to an enum)
10:23:51 johnthetubaguy so I am stuggling to understand everyone's position in text form
10:25:08 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:20 stephenfin (since it was only added this cycle)
10:26:55 johnthetubaguy but to be rejected, they would need to be calling the new microversion right?
10:26:58 bauzas johnthetubaguy: stephenfin: the consensus I think is that https://review.opendev.org/#/c/704643/ is a nobrainer
10:27:01 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:36 bauzas but https://review.opendev.org/#/c/708436/ is debatable until we reach an agreement
10:27:57 johnthetubaguy I think we agree with the patch, but are unsure on future changes?
10:28:16 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:27 bauzas johnthetubaguy: I'm okay with https://review.opendev.org/#/c/704643/ because it's just a non-enabled framework
10:29:09 bauzas but we need to draw a line
10:29:32 bauzas we said in the spec that a microvesion would signal the fact that we enforce now
10:29:38 bauzas and I'm still OK with this
10:29:56 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:30:10 johnthetubaguy bauzas: because that is what the current patches do right?
10:30:49 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:31:04 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:22 johnthetubaguy plus the wild west of custom scheduler stuff, which we need to keep
10:31:23 bauzas and that wasn't addressed in the spec AFAIK
10:31:39 johnthetubaguy bauzas: yeah, agreed with that worry
10:32:42 bauzas there are actually 2 different things in my mind
10:32:52 bauzas A/ a forgotten key
10:33:00 bauzas B/ a new key in a future release
10:33:36 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:56 bauzas B/ is still undesigned in my mind
10:34:34 bauzas because 'Cloud OVH' could unsupport 'myfancynewkey' while 'Cloud Vexxhost' would
10:34:46 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:35:05 stephenfin kick that decision to Victoria? :)
10:35:07 bauzas compared to now where both support it (well, actually, just accepting it silently)
10:35:18 gibi bauzas: those OVH and Vexxhost keys won't be in tree keys
10:35:36 gibi so they need to implement custom validators
10:35:45 gibi I guess
10:36:02 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:33 stephenfin only the cloud operators themselves will see it though
10:36:37 gibi bauzas: do you mean a situation, when I have a script that creates flavors both in OVH and Veexhost?
10:36:46 stephenfin and they'd see the same thing for image metadata
10:36:48 bauzas that's exactly why 3 years ago, we left the custom filters to be wildcards
10:37:28 bauzas gibi: for a flavor, this requires an admin by default policy
10:37:35 bauzas so i wouldn't worry too much
10:37:51 gibi bauzas: then in what situation you worry?
10:38:06 bauzas image properties that can be user-defined
10:38:28 bauzas do we expose the flavor extra specs to the users ? I think so too
10:38:58 gibi stephenfin: does the same validator code runs for the image properties?
10:39:26 sean-k-mooney bauzas: image propertiese cant be userdeined
10:39:34 stephenfin gibi: no, image properties are already validated because they're mapped to o.vos
10:39:36 sean-k-mooney bauzas: we made them ovo years ago
10:39:57 bauzas hem you're right
10:40:00 sean-k-mooney bauzas: yes its configurable by policy but extra specs are shown
10:40:02 gibi bauzas: so the image properties are a different story
10:40:30 bauzas okay, I just to reconsider whether we have a problem or not
10:40:33 stephenfin different but also the same, in as far as they're not tied to microversions
10:40: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:42 gibi adding an extra spec is also admin only by default, like creating flavor
10:40:56 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:41:24 gibi sean-k-mooney, stephenfin: ack, thanks
10:42:18 sean-k-mooney in the current spec we have the query arg to disable validation right
10:42:58 johnthetubaguy sorry in a meeting
10:43:14 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:56 sean-k-mooney so kind of like the microverions if you want the ussuri behavior then you just set teh right validation version
10:44:31 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:46:15 sean-k-mooney also morning all o/
10:46:41 bauzas fwiw, I just left a comment on https://review.opendev.org/#/c/708436/ to summarize our thoughts
10:46:55 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:47:31 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:51 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:58 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:48:04 bauzas stephenfin: do this and I +2
10:48:13 bauzas (+2/+W) actually
10:49:19 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:27 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:35 stephenfin bauzas: cool. gimme 5. Finishing up doc rework
10:49:40 alex_xu stephenfin: the huaqiang's one, about adding pcpuset field
10:50:18 bauzas johnthetubaguy: stephenfin: actually, that's a good call
10:50:18 alex_xu stephenfin: oops, misunderstand your word. right, I saw your patch
10:50:25 stephenfin alex_xu: cool :)
10:50:32 alex_xu cool
10:50:52 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:55 bauzas \o/
10:50:59 stephenfin johnthetubaguy: Yeah, sticking in TODOs is as close as I've gotten to reworking the extra specs yet
10:50:59 bauzas problem solved.
10:51:41 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:52:10 bauzas and since people can provide their own out-of-tree filters and do what they want, they wouldn't be hit
10:52:25 bauzas I like that plan actually
10:54:39 gibi bauzas: replied in https://review.opendev.org/#/c/708436/
10:55:33 bauzas gibi: cool, we're on the same page

Earlier   Later