Earlier  
Posted Nick Remark
#openstack-nova - 2018-03-08
13:03:06 alex_xu_ gibi: yea, with port create to conductor that can be resolved
13:05:15 alex_xu_ gibi: another thing is about the upgrade case, if the check at nova-compute, the new node will failed to create, the old node will success
13:05:41 alex_xu_ but i think it is ok
13:09:09 gibi alex_xu_: yeah, that will be a bit strange too
13:09:30 gibi alex_xu_: but it is all due to not having information at scheduling time
13:09:41 gibi alex_xu_: which is again due to the port create beeing too late
13:17:13 alex_xu_ gibi: yea, agree
13:17:56 gibi alex_xu_: I'm planning to update the spec tomorrow to reflect the review comments so far
13:23:44 stephenfin jaypipes: Fancy getting this one through? https://review.openstack.org/#/c/407173/
13:29:17 jaypipes stephenfin: did you see tetsuro and sean-k-mooney's suggestions on the exception message? I think those are good suggestions.
13:29:47 stephenfin jaypipes: I...did not :) I'll rework sharpish
13:30:26 sean-k-mooney jaypipes: stephenfin it was more of a nit form my perspective but tetsuro was correct regading where the limit comes form
13:30:37 jaypipes stephenfin: I am going to make another suggestion on the exception message... gimme a sec?
13:30:46 stephenfin jaypipes: Go for it
13:31:16 sean-k-mooney als its thrusday so dont need that away message anymore
13:36:41 cdent seems a sane summary jaypipes, thanks
13:38:53 sean-k-mooney jaypipes: gibi i taught of one edge case for bandwidth based schduling via placement that i dont think was discussed at the ptg or in the spec.
13:41:03 sean-k-mooney jaypipes: gibi today we dont have a way to require specific resouce classes to be claimed as a pair. e.g. we can enforce that an allocation from the vf inventory also allocates form the bandwith inventory. as such we might need to build on dansmith's prefilter work to enforce that somehow
13:42:16 sean-k-mooney maybe we can use a trait such as "requires_bandwidth" on the RP but we also dont have a required traits concept to allocate form a RP
13:42:25 jaypipes stephenfin: k, done
13:43:05 jaypipes sean-k-mooney: that's what efried's granular request groups stuff is all about.
13:43:37 sean-k-mooney jaypipes: yes but it wont prevent a request for just the vf from being allocated form the same rp without a request for bandwidth
13:43:50 jaypipes sean-k-mooney: sure it would.
13:44:11 sean-k-mooney how?
13:44:22 jaypipes sean-k-mooney: the request would just be for SRIOV_NET_VF and NET_INGRESS_BYTES_PER_SECOND in the same request group.
13:44:59 sean-k-mooney yes and how do i prevent a differnet instance form getting a vf by only requesting SRIOV_NET_VF
13:45:06 sean-k-mooney without NET_INGRESS_BYTES_PER_SECOND
13:45:17 jaypipes sean-k-mooney: forbidden traits maybe?
13:45:39 sean-k-mooney jaypipes: what would you forbid?
13:45:58 jaypipes sean-k-mooney: probably the CUSTOM_PHYSNET_BLAH traits.
13:46:00 edleafe sean-k-mooney: wouldn't that be an operator decision? I.e., don't create flavors without both together?
13:46:01 alex_xu_ gibi: cool, thanks for the update
13:46:27 sean-k-mooney edleafe: the request is comeing from the neutron port not the flavor
13:46:44 sean-k-mooney jaypipes: that would prevent the SRIOV_NET_VF and NET_INGRESS_BYTES_PER_SECOND requst from working
13:48:50 jaypipes sean-k-mooney: not sure I follow you...
13:49:14 sean-k-mooney jaypipes: one way to support this would be to introduce a new concept the placement api which allow you per RP to discibe a set of resouces from its invenotries that would be allocated to gether.
13:49:35 sean-k-mooney let me start over
13:49:48 openstackgerrit Bence Romsics proposed openstack/osc-placement master: New dict format of allocations (v1.11, v1.12) https://review.openstack.org/542819
13:49:49 openstackgerrit Bence Romsics proposed openstack/osc-placement master: Add nested resource providers (v1.14) https://review.openstack.org/546675
13:49:49 openstackgerrit Bence Romsics proposed openstack/osc-placement master: Transactionally update allocations (v1.13) https://review.openstack.org/546674
13:49:50 openstackgerrit Bence Romsics proposed openstack/osc-placement master: Allocation candidates parameter: required (v1.17) https://review.openstack.org/548326
13:49:50 openstackgerrit Bence Romsics proposed openstack/osc-placement master: Limit allocation candidates (v1.15, v1.16) https://review.openstack.org/548043
13:50:03 sean-k-mooney we have 1 RP with 2 inventories SRIOV_NET_VF and NET_INGRESS_BYTES_PER_SECOND
13:50:58 sean-k-mooney to allow minium bandwith gurantees i need to ensure that vf for the SRIOV_NET_VF are only allocated if NET_INGRESS_BYTES_PER_SECOND allocation are also made
13:51:33 sean-k-mooney if i dont i can over subsribe on bandwith as the bandwith for the extra vf are not tracked by placement
13:53:07 jaypipes sean-k-mooney: this is kind of why I said that I preferred allocations to be done atomically...
13:54:29 sean-k-mooney jaypipes: but the issue is that the 2 allocation on for SRIOV_NET_VF and NET_INGRESS_BYTES_PER_SECOND and the second for SRIOV_NET_VF are two different boot requests
13:55:03 gibi sean-k-mooney: did this section answers your question? https://review.openstack.org/#/c/502306/15/specs/rocky/approved/bandwidth-resource-provider.rst@260
13:55:41 gibi nova meeting starts in 5 minutes
13:55:55 sean-k-mooney gibi: not quite as there is noting in placement to prevent a request with no traits but SRIOV_NET_VF comming from that RP
13:56:30 sean-k-mooney gibi: basically we would need to tag RP with reqiured traits. not have a per request required traits paramater
13:56:35 gibi `CUSTOM_GUARANTEED_BW_ONLY` and `CUSTOM_BEST_EFFORT_BW_ONLY` to the network
13:56:35 gibi sean-k-mooney: The Neutron agent can put traits, like
13:56:38 gibi RPs to indicate which physical port belongs to which group. Neutron can offer
13:56:41 gibi this configurability via neutron.conf. Then Neutron can add
13:56:44 gibi `CUSTOM_GUARANTEED_BW_ONLY` trait in resource request of the port that is QoS
13:56:47 gibi aware and add `CUSTOM_BEST_EFFORT_BW_ONLY` trait otherwise.
13:56:48 Spazmotic meeting-4?
13:57:02 gibi Spazmotic: #openstack-meeting
13:57:06 Spazmotic Thanks sir
13:57:38 gibi sean-k-mooney: this means that the non QoS aware ports will only be allocated to places that has CUSTOM_BEST_EFFORT_BW_ONLY trait
13:57:41 sean-k-mooney gibi: if neutron can guarentee that every neutron port will have one of those traits going forwared then it will work
13:57:53 gibi sean-k-mooney: yeah, that is the idea
13:57:55 Spazmotic Must head to bed, will read it when iw ake up. Have a good day, novers.
13:58:05 gibi sean-k-mooney: and as neutron will create the RPs neutron can put the trait as well
13:58:37 sean-k-mooney gibi: ok i was thinking we shoudl support this explcitly in placement rather then requiring all consumers of placement to provide a similar guarntee.
13:59:00 openstackgerrit Stephen Finucane proposed openstack/nova master: hardware: Rework '_get_cpu_topology_constraints' https://review.openstack.org/407173
13:59:01 openstackgerrit Stephen Finucane proposed openstack/nova master: hardware: Rework get_number_of_serial_ports https://review.openstack.org/407174
13:59:03 stephenfin sean-k-mooney, jaypipes: That should be better ^
13:59:34 gibi sean-k-mooney: yeah, a generic solution would be even better but I haven't thought about how to do that
14:00:06 dansmith cdent: do you know if edleafe is out this week?
14:00:19 cdent he's back in biz today I believe
14:00:21 sean-k-mooney gibi: one extra table of required_traits_to_rp then in the sql just vailidate that all traits in reqiured traits are in the request
14:00:25 cdent was halfway yesterday
14:00:45 edleafe dansmith: I'm here, but distracted with lots of non-OpenStack stuff
14:01:08 dansmith edleafe: ah, cool
14:01:19 dansmith edleafe: cdent reviewed some of my prefilter patches which reminded me you promised to do the placement api for that and I meant to say something last week about it
14:01:40 sean-k-mooney gibi: it shoudl be fairly simple but its a new api and needs a spec + placement team need to agree this is an api we want to supprot going forwoard
14:02:17 dansmith edleafe: jaypipes already got a spec for that merged, so the gates are open
14:02:22 edleafe dansmith: I remember. If you could point me to your patches it will help refresh the tired brain cells
14:02:43 dansmith edleafe: yep, here's the template of the client bit: https://review.openstack.org/#/c/547990/2
14:02:49 dansmith edleafe: and the spec: https://review.openstack.org/#/c/544694/
14:03:15 edleafe dansmith: ok. Probably won't have bandwidth until Monday, though
14:03:39 dansmith edleafe: ack
14:03:52 openstackgerrit Dan Smith proposed openstack/nova master: Add AggregateList.get_by_metadata() query method https://review.openstack.org/544728
14:03:53 openstackgerrit Dan Smith proposed openstack/nova master: Add request filter functionality to scheduler https://review.openstack.org/544730
14:03:53 openstackgerrit Dan Smith proposed openstack/nova master: Add aggregates list to Destination object https://review.openstack.org/544729
14:03:54 openstackgerrit Dan Smith proposed openstack/nova master: Add require_tenant_aggregate request filter https://review.openstack.org/545002
14:03:54 openstackgerrit Dan Smith proposed openstack/nova master: WIP: Make get_allocation_candidates() honor aggregate restrictions https://review.openstack.org/547990
14:03:55 openstackgerrit Dan Smith proposed openstack/nova master: WIP: Honor availability_zone hint via placement https://review.openstack.org/546282
14:04:46 jaypipes sean-k-mooney: I'm amenable to reviewing a spec on it, but it won't be a priority for Rocky. just so you know.
14:10:21 jaypipes stephenfin: +2
14:12:51 stephenfin jaypipes: ta
14:27:24 mdbooth mriedem: Just looking at a live migration bug which came up downstream, and I can't see anywhere we restore bdm.connection_info if we're forced to rollback. Any chance I missed it? That's not the downstream bug, btw, but it's in the same area.
14:29:15 openstackgerrit Merged openstack/nova master: Deprecate sparse LVs https://review.openstack.org/549771
14:31:54 hrw bauzas, jaypipes, kashyap, mriedem, stephenfin: thanks for help with PCIe hotplug patch.
14:32:20 kashyap` Np
14:34:43 gibi sean-k-mooney: yeah. I think I will try to not make a dependency between the bandwidth spec and a new placement api spec if this is not really necessary
14:34:57 gibi sean-k-mooney: that spec is already a monster :)
14:40:45 mriedem mdbooth: not off the top of my head

Earlier   Later