| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-08 | |||
| 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 | |
| 14:41:04 | openstackgerrit | Dan Smith proposed openstack/nova master: Make nova-manage db purge take --all-cells https://review.openstack.org/550502 | |
| 14:41:18 | mdbooth | mriedem: NP, just thought I'd ask in case you had it cached. | |
| 14:41:20 | cdent | jaypipes: I can't remember; where did the aggregates-affinity plan end up? Is it a goer? https://review.openstack.org/#/c/529135/ | |
| 14:42:34 | mriedem | mdbooth: pre_live_migration on the dest host creates the bdms in the MigrateData object which is then passed back to the source | |
| 14:44:29 | mdbooth | mriedem: I suspect we're not restoring that stashed value to bdm.connection_info if we rollback. The volume would still be attached, but cinder v2 operations would fail I think. | |
| 14:44:48 | mdbooth | mriedem: This is code-inspection only. I'm going to try to verify and I'll raise a bug. | |
| 14:45:07 | openstackgerrit | Merged openstack/nova master: Handle IpAddressAlreadyAllocated exception https://review.openstack.org/535532 | |
| 14:45:16 | openstackgerrit | Merged openstack/nova master: install-guide: Wrap long console command https://review.openstack.org/544093 | |
| 14:45:18 | mriedem | i think i see where we update the bdm.connection_info to point at the dest host | |
| 14:45:25 | openstackgerrit | Merged openstack/nova master: [placement] use simple FaultWrapper https://review.openstack.org/533752 | |
| 14:45:46 | mriedem | mdbooth: this https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L5957 | |
| 14:45:48 | mdbooth | We update it for the dest in pre_live_migration | |
| 14:45:55 | mriedem | with refresh_conn_info=True | |
| 14:45:57 | mriedem | right | |
| 14:46:03 | mriedem | if you're using old style migrations | |
| 14:46:07 | mdbooth | mdbooth: Yep, that's the one. | |
| 14:47:03 | mdbooth | Incidentally, the downstream bug relates to a cinder driver which doesn't consistently return identical values for initialize_connection | |
| 14:47:27 | mdbooth | I believe because of multipath, although I'm not 100% sure why not | |
| 14:48:15 | mdbooth | The impact is that when we try to detach on the source post live migration, we call initialize_connection to get the source conn_info, then call detach, which fails because the conn_info isn't exactly what we had before | |
| 14:49:18 | mriedem | detach on the source during rollback because live migration failed? | |
| 14:49:29 | mdbooth | No, on success | |
| 14:49:37 | mriedem | ok you were saying rollback earlier | |
| 14:49:45 | mdbooth | Yeah, different bug :) | |
| 14:50:11 | mdbooth | I was looking at the success case, and noticed it looked like there was a related problem in the rollback case | |
| 14:50:25 | mdbooth | But I haven't verified that yet | |
| 14:51:04 | mdbooth | Anyway, as we call pre_live_migration synchronously, it occurred to me we don't need it to return to us the values before it modified them | |
| 14:51:18 | mdbooth | We can just stash them before calling pre_live_migration | |
| 14:51:49 | mriedem | i assume this is all a problem reported on like newton or something right? | |
| 14:51:56 | mriedem | i'm sure it's a latent bug for the old style volume attachments, | |
| 14:52:24 | mdbooth | Yeah, since Liberty I think | |
| 14:52:30 | mriedem | i think with the new style attachments, we don't have the same issue because live migration tracks the attachments for the source and dest host, and cinder stores the connection_info in the attachment records (in cinder), so we don't have the bdm.connection_info wonkaroo in nova | |
| 14:52:43 | mdbooth | Yep | |
| 14:53:23 | mriedem | simply refreshing the connection info for the old style attachments might do the trick | |
| 14:54:00 | mriedem | since that will initialize the connection (in cinder) for the host we're on (since we have to pass a host connector) and we'll get back a new connection_info from cinder which will get updated in the bdm.connection_info | |
| 14:56:11 | mdbooth | mriedem: True, except for the discovered inconsistent return value from initialize_connection | |
| 14:56:25 | mdbooth | Which I think the cinder folks are also treating as a bug, btw. | |
| 14:56:44 | mdbooth | But they hate the second call to initialize_connection regardless :) | |