| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-11-08 | |||
| 14:50:22 | sean-k-mooney | bauzas: i generally agree with dan the reason traits exist is to request hardware capabliteis like sse3 | |
| 14:50:48 | sean-k-mooney | but we realised that not all capabliteis are hardware capabliets | |
| 14:51:11 | dansmith | right, this new capability is "virtual hardware capability" not unlike a cpu flag, IMHO | |
| 14:51:16 | sean-k-mooney | which is why the compute namespace exists to model the capablity of a hyperviors to emulate/provide a functionaltiy | |
| 14:51:41 | sean-k-mooney | right so https://github.com/openstack/os-traits/tree/master/os_traits/compute | |
| 14:51:49 | sean-k-mooney | is for software cpablies | |
| 14:52:05 | sean-k-mooney | and https://github.com/openstack/os-traits/tree/master/os_traits/hw is for host capablities | |
| 14:52:24 | dansmith | exactly | |
| 14:53:03 | bauzas | yeah, so my point is that some of the traits can directly be used, for sure, like the hardware ones | |
| 14:53:12 | sean-k-mooney | where i kind of sit in this debate is if we have an extra spec to enable a functionlatiy that should automatically result in requeest the capablity | |
| 14:53:25 | bauzas | but for some traits we only use internally for scheduling, those shouldn't be directly used | |
| 14:53:53 | sean-k-mooney | i.e. you should not need to request hw:viommu=true and traits:viommu=required | |
| 14:54:21 | sean-k-mooney | the former shoudl result in the latter being added automatically | |
| 14:54:27 | bauzas | if one day, we think that COMPUTE_NET_VIRTIO_PACKED is not the right trait to provide for supporting the virtio_packed thing, we could be able to no longer provide it | |
| 14:54:54 | 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 | |
| 14:55:14 | sean-k-mooney | yep and since we dont expect anywone to directly request it (just use the flavor extra spec) that shoudl be fine | |
| 14:55:30 | bauzas | anyway, I don't want us to discuss that much now | |
| 14:55:31 | sean-k-mooney | we can just document "hay dont set this nova will do it for you" | |
| 14:55:51 | bauzas | agreed | |
| 14:56:33 | dansmith | well, it's that reason why I think it's not *worth* a trait really, and a service version is enough to get through this current hoop we have | |
| 14:56:54 | bauzas | dansmith: that's exactly why I meh'd to the spec | |
| 14:57:05 | dansmith | but I'm not wed to either alternative as they both have pros and cons | |
| 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 | |