| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-27 | |||
| 19:16:39 | mriedem | since ODL won't send a vif plugged event until the port binding changes, right? | |
| 19:16:43 | mriedem | which currently happens in post live migration | |
| 19:17:19 | sean-k-mooney[m] | mriedem: yes didnt you already remove that in your code. we were talking about this last week i think? | |
| 19:17:22 | mriedem | i'm almost inclined to add a [workarounds] config option to disable that wait for vif plugged, but enable the wait by default | |
| 19:17:28 | mriedem | it's a todo in the code right now | |
| 19:17:40 | mriedem | so for ovs and LB we'd default to wait, | |
| 19:17:46 | mriedem | but if you're using ODL, you disable the wait | |
| 19:18:57 | sean-k-mooney[m] | ya odl wont send the event until there is a neutron port update which will only happen when we activate the new building as a result of the change to the host-id in the vif binding_details dicts | |
| 19:19:06 | sean-k-mooney[m] | mriedem: we cant tell if its odl or ovs from nova so we cant wait | |
| 19:19:21 | sean-k-mooney[m] | we can wait for the compute to tell use it has plugged the interface we just cant wait for neutron to say its wired it up | |
| 19:19:23 | mriedem | sean-k-mooney[m]: i know we can't | |
| 19:19:28 | mriedem | but the operator can | |
| 19:20:00 | mriedem | so for live migration, we can default to wait, assuming you're using a networking backend that doesn't suck | |
| 19:20:12 | mriedem | and if you are, then you need to configure nova-compute to not wait for vif plugged events during live migration | |
| 19:20:44 | mriedem | to other specs cores, i think https://review.openstack.org/#/c/521392/ is a no-brainer | |
| 19:20:58 | sean-k-mooney[m] | oh yes we could have a per compute config option or i guess a could wide one for the conductor | |
| 19:21:11 | mriedem | conductor doesn't wait | |
| 19:21:12 | mriedem | compute does | |
| 19:21:44 | sean-k-mooney[m] | mriedem: so in the prelive migrate would we have the dest read the config value and stick it in the migration data | |
| 19:22:01 | mriedem | umm | |
| 19:22:09 | mriedem | i figured the source would read the config since the source host is what's waiting | |
| 19:22:21 | mriedem | if the wait has to depend on the dest, then yeah maybe that has to go into the migrate data object | |
| 19:22:31 | mriedem | if the dest host is using ODL but the source is using OVS | |
| 19:23:26 | sean-k-mooney[m] | well since the dest might have a different network backend to the souce we should get the dest value no? | |
| 19:23:37 | mriedem | probably | |
| 19:24:54 | sean-k-mooney[m] | we proabbly also want to default to not waiting to not break upgrades as that is the default behavior today | |
| 19:24:59 | sean-k-mooney[m] | we can then change the default after 1 release | |
| 19:25:20 | mriedem | oh i suppose | |
| 19:25:44 | sean-k-mooney[m] | or put somthing in the neutorn port binding so neutron can tell use if we should wait or not in the future | |
| 19:25:46 | mriedem | older dest computes wouldn't send the value anyway | |
| 19:26:10 | mriedem | neutron telling us if waiting is safe would be great, but i'm not driving that on the neutron side | |
| 19:27:00 | sean-k-mooney[m] | well the sepc said we would only use the new flow if they both supported it but ya old dest would not send it so its safer to assume dont wait | |
| 19:28:01 | sean-k-mooney[m] | mriedem: honestly i dont think that would be too hard to enable in neutron. i dont know if i have time to look at it but it should be a minor enough api extention | |
| 19:28:20 | mriedem | i mention the old dest compute thing because we had also talked about doing this separately from the blueprint as a bug fix so we could backport it | |
| 19:28:28 | mriedem | but if it requires changes to the versioned object, we can't really backport it | |
| 19:28:45 | mriedem | that was also before we knew that ODL didn't send events | |
| 19:29:01 | sean-k-mooney[m] | basicaly i think we could have a singel key in the portbining dict. vif_plugged_event_policy that could be never,on_bind or on_plug then just hard code it for each of the ml2 drivers | |
| 19:30:03 | sean-k-mooney[m] | mriedem: ah ya that makes sense | |
| 19:32:24 | sean-k-mooney[m] | mriedem: do you want me to open an rfe but for the event stuff and we can see what the neutron team says? it would not be a hard dependecy but it would allow us to know in the future if we can wait | |
| 19:33:13 | cdent | edleafe: responded to your coments on forbidden traits in rp in db. I think you're missing a point or I've explained things very poorly | |
| 19:33:57 | openstackgerrit | Merged openstack/nova-specs master: Non-unique network names in Servers IPs API response https://review.openstack.org/521392 | |
| 19:34:10 | mriedem | sean-k-mooney[m]: sure | |
| 19:37:57 | efried | jaypipes, cdent, edleafe: Is there anything preventing two records in the allocations table having the same consumer+rp+rc? | |
| 19:39:29 | cdent | efried: in the table itself, no, but the interface on the object does a full wipe before it does any set (for a given consumer) | |
| 19:40:08 | efried | cdent: duly noted. | |
| 19:40:41 | mriedem | do we have a bp or anything anymore for supporting shared storage pools in nova? there was a bp but i can't find it now, maybe it was marked obsolete? | |
| 19:41:08 | edleafe | cdent: ok, but it seems like overkill. No one would be sending !TRAIT now, so I don't quite get the need to support it | |
| 19:41:48 | efried | mriedem: Since we descoped it in Q, and didn't bring it back up in Dublin... | |
| 19:41:57 | cdent | once that full stack is in place, someone can accidentally use the wrong microversion, and they need an appropriate error | |
| 19:42:18 | mriedem | efried: yeah i'm trying to list it as an alternative in https://review.openstack.org/#/c/551927/ | |
| 19:42:38 | cdent | efried, mriedem: tetsuro is still dilligently trying to make shared, correct, yes? | |
| 19:43:18 | efried | mriedem: IIRC, the shared storage provider spec was approved even before Q as one of those vague "we're headed in this direction" things, which led to the inception of aggregates and MISC_SHARES_VIA_AGGREGATE trait, but was never fully tied off. | |
| 19:43:32 | efried | mriedem: And after that we never (re)proposed anything on it. | |
| 19:45:26 | purplerbot | <cdent> once that full stack is in place, someone can accidentally use the wrong microversion, and they need an appropriate error [2018-03-27 19:41:56.981348] [n 18ze] | |
| 19:45:26 | cdent | edleafe: did you see [t 18ze]? | |
| 19:45:53 | cdent | edleafe: because I don't understand why you think it is unnecessary, and would like to | |
| 19:46:22 | mriedem | efried: ok, replied in https://review.openstack.org/#/c/551927/ | |
| 19:46:28 | mriedem | dansmith: jaypipes: ^ you might have other ideas | |
| 19:46:42 | mriedem | it's the age old "how can i support migration w/o globally shared ssh keys" | |
| 19:47:41 | mriedem | if you know a set of computes are in a shared storage pool, you could do the shared storage aggregate thing and then we could look that up from nova-compute rather than do the ssh check | |
| 19:47:43 | efried | mriedem: I think this is the closest we came to a shared storage pool spec https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/generic-resource-pools.html | |
| 19:48:28 | mriedem | before that, we had https://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/migrate-libvirt-volumes.html | |
| 19:48:42 | openstackgerrit | Merged openstack/nova master: api-ref: Parameter verification for servers.inc (1/3) https://review.openstack.org/528201 | |
| 19:49:31 | mriedem | that got held up on the imagebackend refactor o' doom | |
| 19:54:05 | jaypipes | efried: yes, the primary key is on rp+rc+consumer. | |
| 19:54:17 | jaypipes | efried: so the table itself is preventing that. | |
| 19:54:19 | efried | jaypipes: How hard to change? | |
| 19:54:29 | jaypipes | efried: why would we want to change that? | |
| 19:54:44 | efried | To preserve granular groups in allocation records. | |
| 19:55:15 | efried | jaypipes: Composing an email on it. | |
| 19:55:16 | jaypipes | efried: honestly, I'm not interested in doing that. | |
| 19:55:17 | dansmith | that's going to be a poblem | |
| 19:55:35 | dansmith | unless placement handles all the atomicity of working that into a consistent view from the api | |
| 19:55:44 | dansmith | we depend on allocations being per consumer | |
| 19:55:49 | jaypipes | right | |
| 19:55:51 | efried | per consumer isn't a problem. | |
| 19:56:31 | dansmith | presumably you want multiple allocations per consumer against a single RP right? | |
| 19:57:04 | efried | meaning "one 1G disk, one 2G disk, both from the same provider, allocated to the same consumer" | |
| 19:57:04 | efried | CONSUMER_A, RP_1, DISK_GB, 2048 | |
| 19:57:04 | efried | CONSUMER_A, RP_1, DISK_GB, 1024 | |
| 19:57:04 | efried | dansmith: Yes. I'm saying two records with e.g. | |
| 19:57:15 | cdent | jaypipes: you sure about that primary key? I see it as just on the id column? | |
| 19:57:24 | cdent | and no uniq anywhere | |
| 19:57:26 | dansmith | efried: how do you know which is which? | |
| 19:57:34 | efried | dansmith: I contend it doesn't matter which is which. | |
| 19:57:37 | dansmith | efried: and what is the difference between that and one 3G allocation | |
| 19:57:42 | efried | ditto | |
| 19:57:45 | efried | oh, sorry | |
| 19:58:01 | efried | dansmith: The difference is between "one 1G disk, one 2G disk" and "one 3G disk" | |
| 19:58:12 | dansmith | unless you add a group name into that key I don't see how you can reconstruct the original structure | |
| 19:58:16 | dansmith | oh I see | |
| 19:58:43 | dansmith | if it's the same RP, I don't think that's really placement's job to keep track of that | |
| 19:58:50 | efried | dansmith: Then whose? | |
| 19:59:03 | dansmith | that'd be a nova problem, looking at the fact that we have 3G of allocation and, oh hey, the flavor said two disks" | |
| 19:59:03 | jaypipes | efried: if there isn't one, that's a terrible mistake. | |
| 19:59:33 | dansmith | placement needs only to know that you got 3G of storage from that provider | |
| 19:59:42 | efried | dansmith: It was placement that took in a request of the form resources1=DISK_GB:1024&resources2=DISK_GB:2048 and responded with DISK_GB:3072. | |
| 19:59:43 | dansmith | if we decide to cut it up that's a VM management thing (i.e. nova) | |
| 19:59:59 | efried | dansmith: Yup, that'll work, but only for a little while. | |
| 20:00:01 | dansmith | encoding that you have two disks into an allocation in placement is teaching placement too much about nova, IMHO | |