Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-27
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
20:01:06 dansmith efried: if you didn't ask (or imply) placement for those disks to be on different providers, then I think replying with a merged allocation or rejecting it as antithetical is legit
20:01:14 sean-k-mooney[m] dansmith: you will have to do that for things like bandwith requests on two different nics that could be allocated form the same pf
20:01:25 sean-k-mooney[m] or tor
20:01:27 sean-k-mooney[m] so its not jsut a nova thing
20:01:39 efried dansmith: Well, that's a separate issue - asking for them to be on different providers can't be expressed currently (assuming traits are the same etc.)
20:02:08 efried dansmith: The problem moving forward is that we're going to have agents other than nova responsible for mapping allocation into actual resources. Plus the fact that we're going to be synthesizing that request string from not just the flavor, but also from image metadata, neutron, eventually cyborg, cinder...
20:02:20 sean-k-mooney[m] dansmith: so are you saying we should be explcit and have some way of saying its ok to merge?
20:02:23 dansmith sean-k-mooney[m]: if the resource comes from a different pile, then it needs to be a different RP (even if the same pf)
20:02:44 dansmith sean-k-mooney[m]: and if it's not then placement doesn't need to know about it
20:03:11 efried dansmith: That doesn't let you express bandwidth on the PFs though.
20:03:17 dansmith sean-k-mooney[m]: rather decide whether not stating them as separate means they're merge-able or if it means it's a 400
20:03:26 edleafe cdent: So you see a case where someone would create flavors with traits that are prefixed with '!', but not specify a microversion that supports it? I guess I can't see that.

Earlier   Later