| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-08 | |||
| 13:00:22 | gibi | alex_xu_: this of course means that the boot will fail in the compute | |
| 13:01:26 | alex_xu_ | gibi: ah, i see, that works except it really fail late | |
| 13:02:17 | gibi | alex_xu_: yes, it is late and that is not optimal. But the whole create the port in the compute is not optimal | |
| 13:02:42 | gibi | alex_xu_: I would say it is temporary until we move the port create to conductor | |
| 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: Transactionally update allocations (v1.13) https://review.openstack.org/546674 | |
| 13:49:49 | openstackgerrit | Bence Romsics proposed openstack/osc-placement master: Add nested resource providers (v1.14) https://review.openstack.org/546675 | |
| 13:49:50 | openstackgerrit | Bence Romsics proposed openstack/osc-placement master: Limit allocation candidates (v1.15, v1.16) https://review.openstack.org/548043 | |
| 13:49:50 | openstackgerrit | Bence Romsics proposed openstack/osc-placement master: Allocation candidates parameter: required (v1.17) https://review.openstack.org/548326 | |
| 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 | sean-k-mooney: The Neutron agent can put traits, like | |
| 13:56:35 | gibi | `CUSTOM_GUARANTEED_BW_ONLY` and `CUSTOM_BEST_EFFORT_BW_ONLY` to the network | |
| 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 aggregates list to Destination object https://review.openstack.org/544729 | |
| 14:03:53 | openstackgerrit | Dan Smith proposed openstack/nova master: Add request filter functionality to scheduler https://review.openstack.org/544730 | |
| 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:54 | openstackgerrit | Dan Smith proposed openstack/nova master: Add require_tenant_aggregate request filter https://review.openstack.org/545002 | |
| 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. | |