| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-18 | |||
| 16:41:12 | sean-k-mooney | not ensure that trait is appended to the virt dirver set | |
| 16:41:21 | dansmith | yeah | |
| 16:42:03 | efried | okay, so: | |
| 16:42:03 | efried | - s/ensure/additional/g | |
| 16:42:03 | efried | - forward compat for $minor version (additionalProperties:true) | |
| 16:42:03 | efried | - $COMPUTE_NODE with explanation that includes "all ironic nodes" | |
| 16:42:06 | efried | what else? | |
| 16:42:23 | dansmith | not all ironic nodes, but all nodes | |
| 16:42:33 | dansmith | or "all nodes managed by this compute" or something like that | |
| 16:42:43 | sean-k-mooney | maybe call it $compute_service | |
| 16:43:19 | dansmith | GOD | |
| 16:43:21 | dansmith | no | |
| 16:43:28 | dansmith | have you read the comments from the last 24 hours? | |
| 16:43:36 | dansmith | it's *not* the service, it's the node that provides inventory | |
| 16:43:37 | sean-k-mooney | ok | |
| 16:43:39 | dansmith | that's the point :) | |
| 16:43:46 | sean-k-mooney | oh right | |
| 16:44:53 | sean-k-mooney | yes i was trying to say that i map node to a singel RP for a since server in my head. and that each ironci compute sevicce manage mulitpl phyical server each of which is a seper compute node but i think we mean the same thing and im jsut saying it badly | |
| 16:45:06 | openstackgerrit | Lee Yarwood proposed openstack/nova master: WIP nova-next: Deploy noVNC from source https://review.opendev.org/671490 | |
| 16:45:26 | dansmith | sean-k-mooney: right, it's the terminology that is important I think, but obviously we're on the same page for mechanics | |
| 16:45:53 | dansmith | it would be wrong to apply something that is declared to be "for the compute service" to the "compute nodes" | |
| 16:46:10 | sean-k-mooney | yes | |
| 16:46:14 | dansmith | but making the terminology match makes it clear that it's for the node, 1, 2, or 20 of them as managed by this service | |
| 16:46:20 | efried | except we're conflating that a bit with things like the DISABLED trait... | |
| 16:46:55 | efried | perhaps that's not the best example, but we've got traits on the RP that are really capabilities of the compute service... | |
| 16:47:00 | dansmith | we're headed in the right direction with that though | |
| 16:47:06 | dansmith | disabled predates nodes as a concept | |
| 16:47:18 | dansmith | this moves it closer to the right thing, which is move it to the schedulable entity | |
| 16:48:11 | sean-k-mooney | well if a compute service was disabled. all the compute nodes it managed would be unavailable until ironci moved them to be managed by another compute service | |
| 16:48:31 | dansmith | that's my point | |
| 16:48:44 | dansmith | it used to be right, now it's wrong, disabled traits on compute nodes is making it right-er | |
| 16:49:05 | efried | also, do you feel as though the virt driver should or should *not* be involved in the processing here? | |
| 16:49:40 | efried | cdent: this plays into whether auto traits can be added or not | |
| 16:50:26 | efried | If we cut the virt driver out entirely, we can do the providers.yaml processing after update_provider_tree+update_traits without reorganizing the rt flow. | |
| 16:50:35 | sean-k-mooney | efried: we breifly discussed if the generic code should live in teh Resouce tracker or in the driver base class | |
| 16:50:59 | efried | Yeah, I'm less concerned about which module the generic code lives in and more about where it's invoked from in the flow. | |
| 16:51:32 | sean-k-mooney | right i have a prefence but im wondering what dansmith thinks | |
| 16:52:04 | efried | I've been proposing (https://review.opendev.org/#/c/612497/10/specs/train/approved/provider-config-file.rst@205) that it be invoked from within update_provider_tree itself, giving the driver a certain amount of control | |
| 16:52:14 | sean-k-mooney | also my perference change depening on what we allow in the current version and in the future | |
| 16:52:32 | dansmith | efried: remember, I was mostly concerned about the optics of how it's viewed from reading the spec, | |
| 16:52:42 | dansmith | but I do think that making it as absolutely uniform as possible is important, | |
| 16:53:08 | dansmith | and having it fully within the RT so that the RT refuses to update/replace anything the virt driver has done across the board would be the most consistent I think | |
| 16:53:26 | efried | including automatic traits? | |
| 16:53:54 | dansmith | well, I really think allowing them to remove traits by this mechanism is dangerous, as I said | |
| 16:53:56 | sean-k-mooney | efried: my perfernce would be that the behavior would be the same regardless of the virt driver if at all possible | |
| 16:54:02 | dansmith | yes ^ | |
| 16:54:17 | cdent | is there any mechanism to remove traits? | |
| 16:54:21 | efried | In this iteration only adding traits is allowed, so the difference is whether, when I try to add a trait that's otherwise dealt with by the compute manager, it sticks or not. | |
| 16:54:38 | efried | cdent: not yet, but we've been trying to leave it open for that possibility (in some form) in the future. | |
| 16:54:39 | dansmith | definitely should not | |
| 16:54:48 | efried | okay. | |
| 16:54:49 | efried | so | |
| 16:54:50 | sean-k-mooney | if we allw modifcation of inventores/traits creted by the virt driver i also conceed we might want to delgate processign to the virt driver at that point | |
| 16:55:05 | dansmith | efried: don't we have a declaration of which traits are owned by the compute and virt, so that we can wholly box off those anyway? | |
| 16:55:17 | efried | today: update_provider_tree => update_auto_traits | |
| 16:55:17 | efried | tomorrow: update_provider_tree => process_providers_yaml => update_auto_traits | |
| 16:55:24 | efried | dansmith: no, unfortunately not | |
| 16:55:38 | efried | and in fact, the above mixes poorly | |
| 16:55:38 | sean-k-mooney | dansmith: not really. unless we say provdier.yaml can only use CUSTOM_ | |
| 16:55:40 | dansmith | efried: well, maybe we should do that as part of this.. I know we discussed it before | |
| 16:55:44 | sean-k-mooney | which i think is too restrictive | |
| 16:55:51 | dansmith | sean-k-mooney: well, that would probably not be too bad, IMHO | |
| 16:55:54 | efried | because update_provider_tree may have some traits it enforces | |
| 16:56:13 | dansmith | it would clearly draw a box around the things you're doing as being purely localized customization and not mucking with internal features | |
| 16:56:20 | efried | but then update_auto_traits (which is not under control of the virt driver -- except as declared by the compute capabilities dict) has others | |
| 16:56:21 | sean-k-mooney | it would be nice to be able to use a standard hyper treading treat or secure boot trait | |
| 16:56:33 | sean-k-mooney | and use the file to add them if its supported | |
| 16:56:42 | efried | dansmith: unfortunately it's not easy to do. See venn diagram here https://docs.openstack.org/nova/latest/reference/update-provider-tree.html#taxonomy-of-traits-and-capabilities | |
| 16:56:57 | dansmith | sean-k-mooney: but why would that not be exposed by the driver if it's available and enabled? making operators track that is dumb | |
| 16:57:03 | sean-k-mooney | im not sure if those are actully good examples | |
| 16:57:06 | efried | that is, we've identified the problem before, but punted on trying to solve it because it's too hard. | |
| 16:57:20 | dansmith | efried: CUSTOM_ would make it pretty easy | |
| 16:57:25 | sean-k-mooney | dansmith: well the hypertreading tread is explcitly not owned by the virt driver | |
| 16:57:42 | efried | hum | |
| 16:57:43 | dansmith | sean-k-mooney: why? | |
| 16:57:52 | sean-k-mooney | its stated that way to allow the cpu tread polices to work | |
| 16:58:12 | dansmith | sean-k-mooney: give me a reason that makes sense, not one that is tied to how things work today :) | |
| 16:58:44 | sean-k-mooney | this is why i said that might not be a good example but its in che CPU standaisation in placement spec | |
| 16:59:14 | dansmith | ack | |
| 16:59:29 | sean-k-mooney | last paragrh in https://github.com/openstack/nova-specs/blob/master/specs/train/approved/cpu-resources.rst#add-hw_cpu_hyperthreading-trait | |
| 16:59:42 | sean-k-mooney | well that section in general. | |
| 16:59:55 | sean-k-mooney | im not sure if there are standard traits you would want to manage this way | |
| 17:00:04 | sean-k-mooney | i just didnt want to assuem there wasnt | |
| 17:00:40 | dansmith | I think saying that these things are all restricted to the CUSTOM_ realm is a good line, IMHO | |
| 17:00:43 | efried | I think I can buy CUSTOM_ only. | |
| 17:00:51 | sean-k-mooney | again for v1 we could say just CUSTOM_ untill we have a usecase that requires standard traits | |
| 17:01:00 | dansmith | efried: you willing to say that for traits and inventory or just the former? | |
| 17:01:33 | sean-k-mooney | e.g. you can only have CUSTOM_ resouce classes too? | |
| 17:01:41 | dansmith | I'm less sure about it for inventory, but it does eliminate a lot of my concern over overriding virt inventory | |
| 17:01:47 | efried | well, in both cases it would be nice to be able to propose standard so that, if/when those features become native, you don't have to reshape. | |
| 17:01:54 | sean-k-mooney | i think invntories are less of an issue | |
| 17:01:56 | efried | but | |
| 17:02:09 | efried | I can see where it simplifies things to say CUSTOM_ only for now. | |
| 17:02:12 | dansmith | efried: seems like a clearer line though | |
| 17:02:15 | efried | yes | |
| 17:02:39 | dansmith | efried: do you actually expect people to define their own non-custom classes in placement? if they do they run up against id conflict right? | |
| 17:02:48 | sean-k-mooney | we have previosly agreed that that virt divers should not use CUSTOM_ stuff in general right | |
| 17:02:57 | efried | dansmith: no, they would have to propose them in the actual repos | |
| 17:03:01 | dansmith | sean-k-mooney: except for ironic which *relies* on it | |
| 17:03:08 | dansmith | efried: right, so then they have to reshape anyway | |