Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-07-18
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
17:03:14 sean-k-mooney and i gues the vPMEM stuff
17:03:28 sean-k-mooney ok ignore the virt driver wont use it thing
17:03:32 efried I'm saying if they propose the standard ones before they start customizing, they don't need to reshape.
17:03:46 dansmith efried: that's a big if, but okay :)
17:03:51 efried anyway, I think trying to anticipate how reshapes play in here is a fool's errand
17:04:07 cdent It's an important question though
17:04:10 dansmith I'm massively happier about all this if it's restricted to CUSTOM_
17:04:17 efried so yeah, CUSTOM only for both traits and resource classes is okay for this rev

Earlier   Later