Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-09-05
16:20:14 jaypipes efried: distance would be stored in an aggregate_distances table, which would store the distance between the providers in one aggregate and providers in another.
16:20:31 jaypipes efried: distance would just be a number. higher the number, greater the relative distance.
16:21:18 edmondsw or bond_antiaffinity=card,switch if you want the PFs to come from different physical CNAs?
16:21:40 sean-k-mooney jaypipes: im not sure that distance would be a good match to antiafinity/affinity if i need to manually create agggreates for the vfs but ingeneral it is usefull
16:22:34 sean-k-mooney edmondsw: you could but you see the general pattern i would love to express this requirement on the neutorn port in a general way rather then statically defiened in a flavor
16:23:01 edmondsw sean-k-mooney yeah, and I think I agree with that if we can make it work
16:23:03 efried Now, let me make sure I understand something: placement is never going to be in the business of assigning individual VFs around. It's just gonna decrement the count and say "you got one from this RP".
16:23:04 sean-k-mooney bassically i would like to keep flavor extraspecs for compute requirement
16:23:59 efried Then it's up to the virt driver (or maybe the mech driver in this case?) to decide which specific VF to use -- or even to create the VF on the fly if that's something it can do.
16:24:03 sean-k-mooney efried: maybe... i think jay would agree i would not mind extending it to be able to do indvidual assignment
16:24:24 jaypipes sean-k-mooney: it's a possibility.
16:24:48 efried Point is, placement shouldn't be aware of an individual VF any more than it's aware of an individual memory megabyte.
16:25:13 jaypipes sean-k-mooney: in the same way that we agreed not to have aggregates have traits (instead, we "push down" all traits to the resource provider)
16:25:26 jaypipes efried: not necessarily.
16:25:50 dansmith jaypipes: eh?
16:25:55 efried jaypipes: eh?
16:26:00 jaypipes efried: if you need to differentiate between two VFs on a host because those two VFs expose different capabilities, then you will need to create each different VF as a resource provider.
16:26:01 sean-k-mooney efried: well i would like to have the mem_page resouce provider track indiviual pages too but i have more importing things to adress first
16:26:12 dansmith ah, sure
16:26:16 efried Okay, yeah.
16:26:21 dansmith not sure when/how that would happen
16:26:26 dansmith but if it did, then I guess
16:26:37 dansmith although then we're going to have a shitton of single-resource providers
16:26:40 jaypipes dansmith: ask sean-k-mooney. Intel excels at creating uses for complexity.
16:27:16 dansmith I'd hope that you could separate that into 32 VFs with tls-offload and 32 without, for a 64-vf nic
16:27:18 efried okay, as long as the general case is to have the inventory of VFs just be a number.
16:27:18 dansmith but..
16:27:29 dansmith efried: it's still that,
16:27:35 dansmith efried: you'd just have inventory=1 for these
16:27:39 efried yeah yeah.
16:27:42 efried I get it.
16:27:55 efried But the tls-offload thing...
16:28:00 sean-k-mooney well i can certenly do a lot with singel-resouce proverders
16:28:03 efried I would really hope there would be some other way to specify that.
16:28:15 dansmith efried: I wouldn't
16:28:23 jaypipes sean-k-mooney: would single resource providers provide spell checking? :)
16:28:43 sean-k-mooney haha perhaps...
16:28:44 dansmith efried: tls-offload being a trait for regular nics, and vfs, so if some have it and some don't...
16:28:48 jaypipes sean-k-mooney: :P
16:29:16 efried But if I create my VFs on the fly, and could assign that trait to any one of 'em on the fly (say, based on a prop in the binding profile)...
16:29:35 jaypipes dansmith, efried: technically you wouldn't necessarily need to have single resource providers for each VF. just one resource provider per set of VFs with similar capabilities.
16:29:37 dansmith efried: no, that's not the same
16:29:44 dansmith jaypipes: right exactly
16:30:00 dansmith efried: I meant if some VFs would be unable to provide tls offload, then they go in a separate provider without that trait
16:30:28 sean-k-mooney so our current generation of nics cant do this but in future nics we will be able to load firmware that gives different feature per vf
16:30:34 dansmith efried: if they all can and it's a by-request thing, then that means they're all in one provider with that trait and the virt driver decides to configure it as such based on the request
16:30:41 sean-k-mooney with fortvile XL710 its card wide
16:30:50 sean-k-mooney so all vf would have same features/tratis
16:30:53 dansmith sean-k-mooney: yeah and we're all REALLY glad for that
16:30:54 dansmith (not)
16:30:56 efried dansmith Ah, exactly what I was getting at earlier, but you said you didn't want.
16:31:04 dansmith efried: huh?
16:31:13 dansmith efried: a request has a list of required and preferred traits
16:31:44 jaypipes dansmith: don't tempt sean-k-mooney. he will call up the hw designers and ask them to rework it to be more complicated :P
16:32:01 dansmith efried: what I said was I didn't want virt-specific communication from the api user to the virt driver
16:32:20 sean-k-mooney haha well i did ask them to make atleas per pf instead of per card...
16:32:29 dansmith efried: this is not that, this is a generic and abstract requested trait.. placement has already filtered out virt hosts that can't do that generic thing
16:32:41 efried okay, "preferred trait" is new to me.
16:32:55 dansmith efried: doesn't matter, required trait is the same
16:32:58 dansmith for this example
16:33:27 sean-k-mooney efriad: the idea was the required traits would be enforced by filter and prefered trais would be consumed by weigher
16:33:52 dansmith sean-k-mooney: and both could feed into how the virt driver does something eventually
16:34:02 sean-k-mooney yes
16:34:18 abhi89 hey guys.. can someone please review https://review.openstack.org/#/c/485121/.. pending from a long time..
16:34:40 sean-k-mooney my go to examle is dpdk requires sse3 to work but would prefer avx for performance reasons
16:34:54 lbragstad mriedem: https://review.openstack.org/#/c/500918/
16:41:25 mriedem lbragstad: comment inline
16:41:37 efried What's the plan for associating physnets with RPs?
16:42:49 efried Does the RP have a trait like CUSTOM_PHYSNET_XXX where XXX is somehow associated with the port's physnet?
16:43:52 lbragstad mriedem: good call - done
16:46:31 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Add attachment_complete call to volume/cinder.py https://review.openstack.org/493323
16:46:32 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Tweak connection_info translation for the new Cinder attach/detach API https://review.openstack.org/493324
16:46:33 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Implement new attach Cinder flow https://review.openstack.org/330285
17:07:40 sean-k-mooney efried: i think physnet can be a standard trait prefix. so NW_PHYSNET_XXX
17:08:11 efried Okay; I thought you weren't allowed to create a trait with anything other than a CUSTOM_ prefix.
17:08:14 efried But that wasn't really my question.
17:08:22 sean-k-mooney efried: this was one of the usecases i wanted to have key value traits for originally but standard prefixes i think are ok too
17:08:41 efried My question is: who's responsible for recognizing that the XXX corresponds to the physnet in the neutron port?
17:09:46 sean-k-mooney efried: technically yes but lacking key value traits i was hoping we could have a set of stadard prefixes that you were also allowed to create. phynets is one the other option is to have physnet be a field of resouce class
17:10:41 efried Okay, but who's responsible for recognizing that the XXX corresponds to the physnet in the neutron port?
17:10:45 sean-k-mooney efried: well if nova reads the phynet form the port it can compute the trait name and placement can then just do a sting match
17:11:31 efried That would be one way... is that how it's going to work? Or is this still part of the open discussion?
17:12:36 sean-k-mooney still open. i was also thinking of ways to have neutron pass traits/resouce prodier request to nova so that nova does not have to compute the trait name
17:13:25 sean-k-mooney for example addint a traits field to the vif_binding details with the physnet name trait so that nova does not have to query neutron for the physnet
17:13:54 sean-k-mooney again this is up for discussion
17:15:26 efried sean-k-mooney Okay, thanks for the info.
17:16:56 mriedem dtantsur|afk: vdrok: do you know if there are any docs that talk about quota considerations for a tenant that is accessing both VMs and BMs? it's a topic i added here for the ptg: https://etherpad.openstack.org/p/queens-PTG-vmbm
17:17:32 vdrok hrm, not in ironic docs I think.
17:17:57 sean-k-mooney nova is currently the main thing interacting with traits and placement but i would like to add some knolowe of those apis to neutron so that nova does not have to know as much deails about the networking contriants going forwand and can jsut fowrad the reques for resouce providers and traints form neutorn.
17:18:42 mriedem sean-k-mooney: i think mlavalle already started something like a placement client in neutron a few releases ago
17:20:11 sean-k-mooney mriedem: cool we will need if for thinks like bandwith qos. e.g. if we model bandwith in placement and you increase the minium bandwith for a port i should go to placement and check that there is capasity left and increase the claim if so or fail the requst if not
17:21:30 sean-k-mooney e.g. if port is bound it should only allow bandwith to be increased if placement says there is capasity to do so and provide error to user if it cannot
17:30:39 jaypipes sean-k-mooney: there is no such thing as a standard trait prefix.
17:30:51 jaypipes sean-k-mooney: that XXX means it has to be a custom trait.
17:31:42 sean-k-mooney jaypipes: correct today. i was hopping we could add them if we were going to use them for standard thing like physnets to differenciate them for user created traits
17:32:25 sean-k-mooney basically any traint that does not start with custom_ i consider to be a trait that must be defiend in os-traits
17:32:33 jaypipes sean-k-mooney: I would oppose that. traits are boolean values.
17:33:02 jaypipes sean-k-mooney: the physical network that a NIC is associated with must be a custom trait.
17:33:08 sean-k-mooney but just as we have defiend the custom_ as a user defiend prefix i was hoping we could have other prefiex reseved for internal use such as the physnet
17:33:21 jaypipes sean-k-mooney: why though?

Earlier   Later