Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-09
15:31:14 leakypipes it's not changing anything.
15:32:03 superdan oh this is that neutron thing
15:32:07 leakypipes mriedem: this is to solve the chicken-and-egg problem where external agents cannot manage child provider resources because there's no way to tell the agent what the UUID of the compute node resource provider is.
15:32:11 leakypipes mriedem: right.
15:32:12 giblet mriedem, superdan: for me it is just a usage example to better understand the intention of https://review.openstack.org/#/c/550244/
15:33:14 openstackgerrit Takashi NATSUME proposed openstack/nova stable/queens: [placement] Add sending global request ID in get https://review.openstack.org/543116
15:35:16 mriedem so operator defines a yaml file of the compute node and all of it's nested providers and their inventory and traits, etc, and all services that care about it read from that file when creating new things, rather than rely on their own information
15:37:27 mriedem can we make it xml and conform to CIM standards? :)
15:39:17 mriedem so this is just the uuids or everything?
15:39:28 mriedem like a heat template for placement?
15:40:03 mriedem what happens when nova-compute says that the inventory the operator put into the yaml file is different from what it calculates?
15:41:25 openstackgerrit Stephen Finucane proposed openstack/nova master: Fix indentation in doc/source/cli/* https://review.openstack.org/549166
15:41:40 finucannot mriedem: ^ the things I do for docs
15:42:22 finucannot That God awful formatting of block comments in openstackdocstheme really needs to be fixed too
15:43:54 rabel finucannot: thank you! while you're at it, could you have a look at https://review.openstack.org/#/c/549180/ too? it's glance's cli docs and probably has the same problem
15:44:11 finucannot rabel: Sure :)
15:46:43 finucannot rabel: That ones not as bad because they're using definition lists correctly - they just happen to have them indented wrongly
15:46:54 finucannot Some comments left all the same, if you fancy tackling them
15:49:39 rabel finucannot: did you post the comments? i can't see them
15:49:49 finucannot whoops
15:50:01 finucannot rabel: actually published now
15:50:37 leakypipes mriedem: no. I specifically did *not* make the provider config YAML format include nested providers. One file per provider.
15:51:23 rabel finucannot: thanks
15:51:40 mriedem leakypipes: ok, so it's a yaml file per provider, and can include the full provider description, including inventory, allocations, traits, aggregates, etc?
15:51:40 finucannot rabel: FYI this is the defacto reference guide for all things reStructuredText http://docutils.sourceforge.net/docs/user/rst/quickstart.html
15:51:49 finucannot The actually Sphinx docs are awful (I'm working on it)
15:51:49 leakypipes mriedem: if a virt driver or external agent wishes to set overrides on a bunch of resource providers (possibly in a tree of providers), they can use multiple YAML files. I have left the implementation details of that stuff to the agent implementors.
15:51:58 leakypipes mriedem: no allocations.
15:52:02 leakypipes mriedem: no aggregates.
15:52:09 leakypipes mriedem: only inventory and traits.
15:52:10 mriedem so just what the RT would report today
15:52:15 leakypipes correct.
15:52:26 mriedem and then the RT will overwrite those, b/c that's what it does today
15:52:58 leakypipes mriedem: I have only submitted a spec describing the behaviour of a single override -- the resource provider's UUID -- in the resource tracker.
15:53:13 mriedem leakypipes: the spec says it can also be inventory and traits
15:53:31 leakypipes mriedem: I haven't discussed overriding inventory or traits in the resource tracker yet. I've only commented on a possible format for describing those inventory/traits overrides.
15:53:38 mriedem https://review.openstack.org/#/c/551315/1/specs/rocky/approved/override-compute-node-uuid.rst@84
15:54:01 mriedem then ^ should probably come out
15:54:07 leakypipes mriedem: why?
15:54:29 mriedem we need to be clear about what happens if an operator is going to put inventory and trait information in this yaml file,
15:54:32 superdan leakypipes: if we just let them explicitly set the name on the provider, then can't we avoid providing a generic override mechanism so that other services can use the name to sync up?
15:54:36 mriedem because today the RT is going to override that
15:54:54 mriedem if you plan to support out of band inventory/traits definitions, then the spec needs to discuss fixing the override so that nova merges those in
15:55:05 leakypipes mriedem: I'm happy to remove that from the use cases list.
15:55:28 leakypipes mriedem: I planned on another spec to discuss the implementation of inventory and trait overrides in the resource tracker.
15:55:37 leakypipes mriedem: that spec is just for the compute node UUID override.
15:56:39 leakypipes superdan: UUID or name, I don't really care. But there has to be a way of signaling to the resource tracker not to use the CONF.host value.
15:57:11 superdan leakypipes: or we just define a new conf option for the name of the RP, default=None means use CONF.host
15:57:19 mriedem ^ was just thinking that
15:57:25 superdan and then roll from there, without having to provide generic override mechanisms, hard coding uuids, etc
15:58:03 leakypipes superdan: and how does that signal to other agents running in other containers what the value should be that they look up?
15:58:36 superdan the same way as if this override yaml file is present and has a uuid set I guess?
15:59:26 superdan for the container file namespace issue, you can put that one option in its own conf file in a common location
15:59:39 superdan *filesystem namespace I mean
15:59:43 leakypipes superdan: how so? the agent may a) be managing multiple compute nodes and need information on multiple providers and b) needs some way of indicating what those compute node identifiers are.
16:00:10 leakypipes superdan: "one option in its own conf file" vs a standardized descriptor file format for resource providers?
16:00:25 superdan I'm confused.
16:00:31 leakypipes superdan: I would have thought you'd be supportive of not adding yet more configuration options.
16:00:51 mriedem leakypipes: this spec doesn't talk about non-nova agents managing multiple compute nodes
16:01:08 openstackgerrit Balazs Gibizer proposed openstack/nova-specs master: Network bandwidth resource provider https://review.openstack.org/502306
16:01:23 mriedem i'm reading this all as 1:1 with a single compute node
16:02:21 leakypipes mriedem: I can add text about 1:M because that's what neutron agents do... many of them run on controller nodes and manage resources for hundreds of compute nodes.
16:03:46 mriedem sorry for my lack of neutron agent know-how, but that's not the case for OVS and LB is it?
16:03:55 mriedem otherwise how would os-vif plugins work for those?
16:04:03 mriedem since we don't use rpc or rest apis in os-vif
16:04:44 mriedem i'm not trying to be snarky, i just don't know the details on how neutron agents can all be deployed, and for which types of neutron backends
16:06:38 leakypipes in a container on a controller...
16:06:38 leakypipes mriedem: imagine a neutron agent that is managing network bandwidth resources for a rack of compute nodes. it needs to know the UUIDs (or compute node names) of those compute node resource providers so that it can add child providers to each compute node that represent the PFs that have a limited supply of ingress/egress bandwidth for physical networks. That agent could run on a single compute node or it could run on the TOR, or it could run
16:08:20 mriedem is that a thing today with the traditional OVS agent? or is this a neutron agent of the future?
16:08:32 giblet Kevin_Zheng, alex_xu_: I've updated the bandwidth spec based on the comments so far https://review.openstack.org/#/c/502306
16:08:33 mriedem like, a new agent service for managing placement type resource information
16:10:55 leakypipes mriedem: I'm not entirely sure where you're going with these questions... I can remove the multi-provider stuff from the spec, but frankly, I don't see why we'd want to limit ourselves to agents that only work with a single resource provider.
16:11:49 mriedem leakypipes: i'm just trying to understand. i don't know if i'm just retarded and don't know how neutron agents work *today*, or if you're talking about something that could be built off of this spec for a new neutron agent in the future. but if it's a problem then i'll just stop asking questions.
16:11:58 leakypipes superdan: to answer your question above about "if we just let them explicitly set the name on the provider, then can't we avoid providing a generic override mechanism so that other services can use the name to sync up?", we will need to provide trait override information in the (near) future -- think about the whole forbidden traits and cpu_model stuff. Do you propose adding more CONF options for trait overrides as well?
16:12:34 leakypipes mriedem: I'm feeling ganged up on.
16:12:37 mriedem operators, or external services, can set traits
16:12:50 mriedem nova just needs to not overwrite them
16:13:07 mriedem i don't think we need config options for that
16:13:12 leakypipes mriedem: and how do we signal to nova not to override *some* traits but not others?
16:13:13 mriedem it's why we have the rest api
16:13:21 mriedem CUSTOM_?
16:13:48 mriedem i thought there was some discussion about that at the ptg about overriding standard vs custom traits
16:13:50 mriedem would have to look
16:13:58 leakypipes mriedem: that's problematic because the specific traits we need to prevent overriding are things like CPU features when CONF.cpu_model is set.
16:15:04 mriedem L494 https://etherpad.openstack.org/p/nova-ptg-rocky
16:15:44 superdan leakypipes: I'm not ganging up on you, I promise
16:16:13 superdan leakypipes: I think we can avoid overwriting traits easily without any config by having things like the virt driver assert which ones it is authoritative over and leaving others alone
16:16:36 mriedem wrt merging traits i'd be fine with just not touching any traits that aren't in the set that we (nova-compute) says should be on the provider
16:16:39 mriedem the compute node provider
16:16:46 mriedem standard or custom
16:17:15 mriedem but if n-cpu says trait X should be on the provider, and someone removed it, then we're going to end up putting it back on
16:17:27 leakypipes superdan: how are you proposing that the virt driver indicate which traits it is authoritative over?
16:17:38 superdan leakypipes: like I said in the room,
16:18:05 superdan some sort of contract between compute and virt, where virt returns all the traits and a "assert", "de-assert", "dont-care" sort of thing
16:18:19 openstackgerrit Balazs Gibizer proposed openstack/nova-specs master: Network bandwidth resource provider https://review.openstack.org/502306
16:18:25 superdan compute looks at the traits currently on a provider, and doesn't touch any that are not mentioned or listed as dont-care
16:18:31 superdan same for any compute-manager-owned traits
16:18:34 leakypipes superdan: and for non-virt things?
16:18:38 superdan same
16:19:00 mriedem i'm not yet sure why we need that level of granularity

Earlier   Later