| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-11-08 | |||
| 14:57:07 | bauzas | if we only do this in a prefilter, we can modify it later | |
| 14:58:18 | bauzas | like, say, by one time, we create some other trait that says "heh, look, I'm a libvirt host" (I know, I know, this is something some people disagree but that's just an example), then we could remove that trait, provided we support both traits during a SLURP time | |
| 14:58:53 | bauzas | again, don't nitpick that example, we could be smarter | |
| 14:59:18 | dvo-plv | sean-k-mooney, bauzas Under words "user should not use trait, only nova". Should I add this here https://review.opendev.org/c/openstack/nova/+/876075/25/releasenotes/notes/packed-virtqueue-filter-43a376674cb5b345.yaml ? | |
| 14:59:50 | bauzas | dvo-plv: I don't think we need | |
| 15:00:01 | sean-k-mooney | dvo-plv: not in the release notes | |
| 15:00:09 | sean-k-mooney | but it could be a note in the feature doc | |
| 15:00:10 | dansmith | I don't think you should say it at all | |
| 15:00:22 | sean-k-mooney | that also ok | |
| 15:00:25 | dansmith | if it's a trait there's no point in us trying to get people to not use it | |
| 15:00:29 | sean-k-mooney | provided we dont refence it in our doc | |
| 15:00:29 | dansmith | that's just confusing | |
| 15:00:34 | dansmith | (and won't work) | |
| 15:00:41 | sean-k-mooney | i.e. just mention the extra spec not the trait in the doc | |
| 15:00:45 | dansmith | I'm confused | |
| 15:00:50 | dansmith | why are we not mentioning it? | |
| 15:01:22 | sean-k-mooney | to use this feature you do not need to set the trait manually in the flavor ro the image | |
| 15:01:36 | sean-k-mooney | you just need to set the flavor extra spec | |
| 15:01:42 | dansmith | but why? | |
| 15:01:46 | sean-k-mooney | the trait is an internal detail and does not need to be in the doc | |
| 15:01:57 | dansmith | then we should _not_ be using a trait, IMHO | |
| 15:02:19 | sean-k-mooney | becuase the prefilte adds it based on teh extra spec | |
| 15:02:47 | dansmith | the only way I think a trait makes sense is if you want to be able to say "I asked for packed queue in hw_ and I want you to FAIL if you can't find me a host that supports that" | |
| 15:03:03 | sean-k-mooney | that what it will do | |
| 15:03:28 | sean-k-mooney | the prefilter will check if the flavor has the packed virt queue extra spec and add a required trait | |
| 15:03:39 | sean-k-mooney | so it will fail if we dont find a host | |
| 15:03:40 | dansmith | but you're talking about a prefilter to always do that | |
| 15:03:46 | sean-k-mooney | yes | |
| 15:04:00 | dansmith | what other hw_ things do we enforce at prefilter time that way? | |
| 15:04:04 | sean-k-mooney | unless we just dont do the trait at all | |
| 15:04:09 | sean-k-mooney | sev | |
| 15:04:12 | sean-k-mooney | vtpm | |
| 15:04:42 | sean-k-mooney | we technialy do thoese in teh ResouceRequest.from_request_spec function | |
| 15:04:45 | sean-k-mooney | rahter then a prefilter | |
| 15:04:45 | dansmith | "sev" and "tpm" are not in request_filter | |
| 15:05:16 | sean-k-mooney | if you want a prefilter example cyborg | |
| 15:05:30 | sean-k-mooney | they both run at more or less the same time | |
| 15:05:33 | dvo-plv | dansmith, it will set trait if user required packed here https://review.opendev.org/c/openstack/nova/+/876075/25/nova/scheduler/request_filter.py#275 | |
| 15:06:16 | dansmith | this seems like mixing scopes to me | |
| 15:06:19 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/scheduler/utils.py#L187-L195 | |
| 15:06:30 | sean-k-mooney | dansmith: that the other place we do this ^ | |
| 15:08:57 | dansmith | ack, well, I don't really see why this needs to be this way, but whatever | |
| 15:09:17 | bauzas | anyway, I don't have time this cycle to do anything with traits | |
| 15:09:37 | bauzas | I just wanted to make sure we don't agree to use that trait I dislike in flavors | |
| 15:10:20 | opendevreview | Danylo Vodopianov proposed openstack/nova-specs master: Re-propose using VirtIO PackedRing Configuration support for 2024.1 https://review.opendev.org/c/openstack/nova-specs/+/895924 | |
| 15:10:24 | bauzas | and I can write some contrib doc saying "please avoid passing hw traits directly in flavors" or some paragraph we could bikeshed | |
| 15:10:35 | dansmith | bauzas: I'm really opposed to that | |
| 15:11:05 | bauzas | what exactly ? hw traits ? | |
| 15:11:09 | sean-k-mooney | bauzas: i would also be opposed to saying dont pas hw traits | |
| 15:11:15 | dansmith | I think acting like there are some 3rd rail traits that you shouldn't use is ridiculous and makes no sense.. if you're going to have an un-disable-able request filter then there's no _point_ in putting one in a flavor, | |
| 15:11:37 | dansmith | but sayin that you shouldn't for some unexplainable reason makes no sense to me | |
| 15:12:05 | bauzas | okay, then the yellow line I would draw would be "don't use standard traits that are automatically queried by either a scheduler prefilter or a requestspec utils method" | |
| 15:12:14 | dansmith | no. | |
| 15:12:29 | sean-k-mooney | i mean you proably shouldnt but i dont think we need to docuemnt that | |
| 15:12:38 | sean-k-mooney | there may be valid reasons to do it | |
| 15:12:40 | dansmith | "there is no need to specify traits like hw_packed_virt_queue because nova does it for you" | |
| 15:12:48 | dansmith | is the strongest I'd say, but I wouldn't even say that | |
| 15:13:22 | sean-k-mooney | i think all we have to do is document the minimal extra spec requried to enabel the feature | |
| 15:13:32 | dansmith | yes | |
| 15:13:33 | sean-k-mooney | and jsut not mention the triats outside the spec | |
| 15:13:53 | bauzas | okay, I won't argue | |
| 15:14:12 | sean-k-mooney | wether there are triats, compute service bump ectra are detail we need to agree on but in general should not impact end users or operators | |
| 15:14:57 | bauzas | I personnally think there are 'consumable traits' and 'non-consumable ones' but OK to not explain to operators the names of the 'non-consumable' ones :) | |
| 15:15:11 | bauzas | that said, they'll get them with placement | |
| 15:15:13 | dansmith | bauzas: I reject your reality and substitute my own | |
| 15:15:27 | sean-k-mooney | :) | |
| 15:16:09 | bauzas | okay, nevermind, I'm done with this | |
| 15:16:15 | sean-k-mooney | bauzas: all traits shoudl be "consumabel traits" they may not exist in yoru cloud but thats a seperate probelm | |
| 15:16:19 | bauzas | like I said, there are other cores but me for the spec | |
| 15:16:29 | dansmith | all traits *are* consumable, so that's just the end of it :) | |
| 15:17:14 | bauzas | this just implies that we won't never remove a trait from a compute once we provide it | |
| 15:17:22 | bauzas | but OK | |
| 15:17:32 | sean-k-mooney | bauzas: we have never done it before | |
| 15:17:38 | sean-k-mooney | and i assuemd that was going to be the case yes | |
| 15:17:55 | sean-k-mooney | i mean unless | |
| 15:17:58 | sean-k-mooney | we remove a feature | |
| 15:18:19 | sean-k-mooney | if we remove the ablit to do somethign removing the trait is reflecting reality | |
| 15:18:47 | bauzas | sure, I wasn't talking about removing a feature | |
| 15:19:04 | dansmith | I too don't think there's any way to remove a trait other than not supporting a thing it represents | |
| 15:19:05 | bauzas | but rather rebuilding the feature by doing other scheduler way | |
| 15:19:22 | dansmith | which is also why traits are massively more expensive than bumping an internal integer | |
| 15:19:35 | bauzas | ^ that is my concern | |
| 15:19:59 | dansmith | well, that was my argument in the beginning | |
| 15:20:00 | sean-k-mooney | if we decied because we have done the min libvirt version we dont need the triat thats fine | |
| 15:20:01 | bauzas | so, again, if we are not able to draw a line (which I can understand), then I won't accept the spec | |
| 15:20:19 | sean-k-mooney | but i dont really like bumping a min compute version for a driver only change | |
| 15:20:21 | bauzas | and I'll just wait for another core to accept it | |
| 15:20:25 | sean-k-mooney | but if that is preferabel fine | |
| 15:20:42 | sean-k-mooney | we are just scoping out supproting this until the cloud is fully upgraded | |
| 15:20:44 | bauzas | we already have a min compute version that works | |
| 15:21:04 | dansmith | sean-k-mooney: https://github.com/openstack/nova/blob/master/nova/objects/service.py#L136 | |
| 15:21:11 | sean-k-mooney | right but normally i would not expect a compute service bump for a change that only affect a virt driver | |
| 15:21:19 | bauzas | https://github.com/openstack/nova/blob/master/nova/objects/service.py#L264 | |
| 15:21:48 | sean-k-mooney | dansmith file backed memroy required toher chagnes | |
| 15:22:06 | dansmith | this feels kinda similar: https://github.com/openstack/nova/blob/master/nova/objects/service.py#L220 | |
| 15:24:20 | sean-k-mooney | dansmith: im more ok with documenting "do a compute service bump for dirver only changes" then docuementing anything about not suing traits | |
| 15:25:24 | dansmith | I definitely understand the "this is purely a driver thing so not service version eligible" but I think that this is (a) the primary virt driver, (b) in tree, (c) has hard version requirements built into the driver | |
| 15:25:43 | bauzas | guys, I originally wanted to discuss about https://bugs.launchpad.net/nova/+bug/2041519 status and we sidetracked on the trait thing where I'm done and not much interested. Fancy moving to that ? | |
| 15:25:44 | dansmith | and also maybe (d) most of the other live migration and neutron things we bump the service version for are really just for libvirt features/changes | |
| 15:25:46 | dansmith | so I dunno | |