Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-07-18
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
17:04:31 cdent if the point of the yaml file is to allow people to experiment on thing that they then expect to some day become "normal"
17:04:51 efried cdent: yeah, that's where I was leaning
17:04:51 dansmith cdent: that may be one use of it, but not the primary use I expect
17:05:30 cdent I was going on what the spec says, because I _still_ have trouble comprehending who the user is here
17:05:49 sean-k-mooney there may be some things we never want nova to own on the comptue node like the cyborg aclleartos so something may move out of the provdier.yaml to other service or jsut stay there

Earlier   Later