Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-12
16:49:19 dansmith why is that unreasonable?
16:49:32 dansmith it doesn't have to be the full set of traits that any virt driver might expose,
16:49:39 dansmith just the ones _it_ might expose
16:50:19 dansmith we could make a turbo simple data structure that they all use, which requires them to declare any traits they may want to use, then assert the ones it finds, and the rest will be de-asserted
16:50:34 dansmith to avoid leaking some asserted ones that are never de-asserted
16:50:42 dansmith I must be missing why this is a hard problem
16:50:44 bauzas dansmith: so the virt driver would provide all the possible CPU traits, either with a "+" or a "-" prefix, depending on what it knows to support ?
16:50:58 dansmith bauzas: all the cpu traits it knows about yeah
16:51:10 bauzas that would work then
16:51:18 bauzas okay, I see your idea
16:51:21 dansmith bauzas: it doesn't need to worry about traits for PPC processors, for example
16:51:32 dansmith if the operator added one of those then, sucks for that operator
16:51:45 bauzas yeah, but it would still report "negative" traits
16:51:51 dansmith yeah
16:51:55 bauzas cool with me then
16:52:02 dansmith so if you changed the cpu_model later, it would sync up with all the flags that are now legit
16:52:15 bauzas based on the specific compute version it runs
16:52:29 ygl bauzas: can you help me with my issue please if you can
16:52:31 dansmith sure, but as time goes forward, the cpu flag set only grows
16:52:41 bauzas that's a reasonable assumption
16:52:53 dansmith and for non-cpu flag things,
16:53:00 ygl bauzas: i want to launch a vm with a dummy nic interface without an IP assigned to it
16:53:01 dansmith it becomes a compatibility thing kinda like our db schema,
16:53:04 bauzas and honestly, who cares if the operator sets a trait that the virt driver doesn't know ?
16:53:19 dansmith where you need to not just add/remove traits willy-nilly over releases without doing some cleanup
16:53:26 dansmith ygl: this channel is for development, see topic please
16:53:31 bauzas the operator would suck less if they would use a custom trait for that
16:53:41 bauzas yeah, I like that idea actually
16:53:48 ygl dansmith: i tried other channels but they r not responding
16:53:53 bauzas because we explicitly then provide what the virt driver knows
16:53:58 dansmith bauzas: yup, we could have an audit mode where the compute node logs any traits it didn't calculate, which should ideally be just the ones the operator set
16:54:28 dansmith so any that got leaked over time would be easy to identify
16:56:50 ygl bauzas: sorry to disturb you. can you help me with my issue, if you can
16:57:13 efried Note that the ironic virt driver is gleaning traits from inspector. So that interface will need to change: either to support +/-; or to add a separate "get all the traits I might care about" call.
16:57:49 dansmith efried: the interface from the ironic driver to ironic?
16:57:54 efried yeah
16:57:59 sean-k-mooney dansmith: the cpu traits would be reported on the CPU resouce providers not the compute node correct nulless the cpu inventory is under the compute node. just thinking of the numa case where the inventory would be per numa node
16:58:24 dansmith efried: depends on the traits I guess, and what is going on right now.. if the ironic driver is exposing traits that don't need to be deleted later, then it won't really matter
16:58:46 dansmith sean-k-mooney: yeah, that doesn't change this though
16:59:39 sean-k-mooney dansmith: yep just checking. i would expect most operator traits to be applied to the compute node RP but they may want to tag sub resouce providres also.
17:00:01 dansmith sean-k-mooney: yeah, network-related traits will need to be below compute node
17:00:11 dansmith efried: ah, looks like we're just proxying any trait they want?
17:00:17 efried yup.
17:00:49 dansmith efried: yeah, well, that kinda sucks, but it's resolvable I think
17:00:54 efried Assuming we go forward with this, all the merge logic needs to be handled by the individual virt drivers. Unless we're going to invent some interface outside of u_p_t.
17:00:55 efried except for get_traits, which I freakin knew was going to bite us in the ass.
17:01:20 dansmith I guess we could also provide the current set of traits to the virt driver so it gets to decide if it thinks any of the ones set are important to ack or nak
17:01:29 efried dansmith: That's what we do.
17:01:34 efried in u_p_t
17:02:11 dansmith efried: I don't think the virt drivers should be doing merging in the general case
17:02:27 dansmith efried: just being write-only for the majority of things, this ironic thing notwithstanding
17:02:28 efried dansmith: Then we need nontrivial redesign of u_p_t.
17:02:49 dansmith well I dunno what to say dude.. this is clearly a thing we missed in the design :)
17:03:20 efried The way it's currently designed: The resource tracker builds the ProviderTree, which includes all the providers' traits as known by placement, and passes that to u_p_t. The virt driver mungs the ProviderTree as it sees fit and then returns. Then resource tracker flushes those changes back to placement.
17:03:54 dansmith yeah, well, we can provide merging routines to the virt drivers to use on the tree,
17:04:00 dansmith and expect that most just use those
17:04:12 efried Sure we can. But the merging still has to be the responsibility of the virt driver.
17:05:12 sean-k-mooney efried: perhaps but it would be nicer if it was the respociblity of the compute manager or some other componet just above the virt driver so it could be shared acrosss all virtdirvers
17:05:44 dansmith sean-k-mooney: yeah, that's what I'd like, to expose some augmented topology from the virt driver so the compute can update the tree,
17:05:46 efried sean-k-mooney: And I'm saying that would require some semantic that's not compatible with u_p_t as designed.
17:05:51 efried The ProviderTree business was so we didn't have to have separate virt driver methods for get_inventory, get_traits, get_aggregates, and (this is the main one) somehow_structure_the_provider_tree_hierarchy
17:05:52 dansmith but it sounds like we've already exposed this all the way down
17:06:22 bauzas efried: dansmith's proposal patch is simple
17:06:24 dansmith so, whatever, we can argue about cleaning that up later if we want, unrelated to fixing this merging thing
17:06:26 efried dansmith: The code isn't merged. We could still rip it all out and change our minds. But I believe we'd be getting a lot more complicated.
17:06:32 admin__ mridem: http://logs.openstack.org/24/550324/2/gate/legacy-tempest-dsvm-neutron-full/211271c/job-output.txt.gz#_2018-03-12_16_02_09_694703 failed
17:06:33 bauzas it doesn't require to modify what we currently have
17:06:42 bauzas it's just a convention
17:06:43 dansmith efried: oh, I thought you meant they're already getting the tree
17:07:26 dansmith I dunno, exposing that all the way down isn't my preference, but if that's what we've agreed on so far, I wouldn't hold it up because I don't like it
17:07:27 bauzas like, in a nested RP world, I'd just see the tree with the root RP having a set of traits, each of those be ether prefixed by plus or minus
17:07:38 bauzas or, say a NUMA node
17:07:39 dansmith we just need to integrate this wrinkle at least
17:07:51 efried dansmith: The code was written in Q, but the series didn't merge in time. So we wrote and approved the spec for R (it didn't have a bp/spec in Q - was just kinda folded into the NRP work). The series starts here: https://review.openstack.org/#/c/537648/
17:07:51 dansmith bauzas: it's more complicated than that
17:08:06 dansmith we need a full topology back from the virt driver with traits at every level It hink
17:08:12 dansmith ack
17:08:22 bauzas mmm
17:08:45 bauzas IIRC, the proposal is the virt driver that passes a tree that has RPS with traits attached, right?
17:08:49 efried dansmith: Yes, the full topology. Does that topology include +/- prefixes? In which case it's not a ProviderTree but something different (ProviderTreeDelta?)
17:09:23 bauzas a trait is attached to a RP, right?
17:09:30 dansmith efried: in the model you have proposed,
17:09:32 sean-k-mooney dansmith: you may not have traits at all levels but there is noting preventing that either. it just depends on the resouces but in all likely hood most RPs will have traits
17:09:38 efried dansmith: Otherwise, like I say, we have to have granular methods that return deltas for traits, inventories, aggregates, and (somehow) the tree structure itself.
17:09:40 bauzas the fact that the RP is a child or a root RP, is just a detail
17:09:50 dansmith efried: we just need a provider.merge_traits(my_assertions) method that takes the +/- things right?
17:09:56 bauzas yeah
17:10:06 bauzas that's a compute method
17:10:09 jaypipes efried: we would want to change the ProviderTree.set_traits() stuff to use the merge traits +/- approach
17:10:13 bauzas no need to change the virt driver interface
17:10:14 efried dansmith: Yes. And virt drivers have to use it. Which is okay with me.
17:10:19 dansmith efried: where provider would be any element in the tree
17:10:20 jaypipes doh, jinx
17:10:24 dansmith efried: yeah, I think that's fine
17:10:42 bauzas the merge_traits() thing is a compute manager method, right?
17:10:45 efried dansmith: But to clarify, it still means the virt driver is responsible for merging traits.
17:10:48 dansmith bauzas: no
17:10:50 jaypipes bauzas: no. ProviderTree
17:10:54 efried ^
17:11:00 bauzas meh to that

Earlier   Later