Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-27
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.
20:03:44 edleafe But if it's necessary, so be it
20:04:04 sean-k-mooney[m] efried: well it kind of does
20:04:08 cdent edleafe: no I see a non-nova client of the placement api make requests to get resource providers filtered by traits, forgetting to set the microversion
20:04:20 jaypipes efried, sean-k-mooney[m]: I think you are both over-thinking this.
20:04:22 efried dansmith: Example that sean-k-mooney[m] is talking about: resources1=VF:1,NET_EGRESS_BW:200&resources2=VF:1,NET_EGRESS_BW:300 -- you can get back a candidate like { PF_RP1: { VF: 2, NET_EGRESS_BW: 500 } }
20:04:25 cdent edleafe: as in: a human
20:04:47 sean-k-mooney[m] the case that is not covered today would be anti afintiy of PFs for VFs for ha bonds
20:04:56 dansmith efried: right, it's still nova asking neutron for the fine-grained quota on each port though
20:05:06 efried neutron is responsible for carving out two PFs. How does it know that one needs BW:200 and the other needs 300?
20:05:09 dansmith efried: placement doesn't need more information than that 500 is committed to that consumer
20:05:19 dansmith efried: it doesn't imply it from placement, IMHO
20:05:20 jaypipes dansmith: zactly.
20:05:38 efried then from where?
20:05:44 dansmith from where what?
20:06:05 dansmith either in the port you created ahead of time, or from the flavor details when nova goes to create it for you
20:06:06 jaypipes efried: the allocation is the amount of that resource that is being provided by that specific resourc eprovider. it's 500.
20:06:07 efried Where does it get the information that that request entails one VF with BW:200 and one with BW:300?
20:06:22 efried neutron has access to the flavor? And the image?
20:06:31 sean-k-mooney[m] efried: if there are no different traits between resouce1 and resouce2 its ok to merge
20:06:36 dansmith efried: are you being difficult now or what?
20:06:45 dansmith efried: neutron ports don't just magically get created
20:07:22 dansmith efried: normally nova creates ports for you based on what you asked for in terms of --nic arguments, presumably influenced by the flavor if this sort of bw quota was encoded there
20:07:28 dansmith nova uses that to decide what to ask placement for,
20:07:37 dansmith and then uses it to talk to neutron to create the ports for you
20:07:52 dansmith placement is not the Windows Registry of information about instances for other services to mine :)
20:07:58 dansmith jaypipes: quote of the day for you ^
20:08:23 efried dansmith: Okay, so for this case we get it from here, for that case we get it from there, for this other case maybe we have to invent something convoluted to pass it through... Whereas if we split up the allocations in placement, it could all come from the same place in a consistent way.
20:08:30 efried and no, I'm not *trying* to be difficult.
20:08:45 efried I'm predicting that we will suffer a death of a thousand cuts by solving this problem differently every time we encounter it.
20:08:45 dansmith efried: the answer to the above leading question is not "mine it from placement"
20:08:57 sean-k-mooney[m] efried: neutron has acess to neither the flavor or image
20:08:58 dansmith efried: haaaaave you met us?
20:09:04 dansmith either way,
20:09:24 dansmith placement is not the database of things for neutron to imply random things about your quota or policy from
20:09:48 jaypipes WHAT dansmith SAID.
20:10:04 sean-k-mooney[m] the enutron port case i was thinking of is i create two sriov ports in enutron tell nova to use both and want to express anti afinity for those at the pf level so in the granualr request to placment we need some what to tell placement they cannont come form the same RP even though they have not other differences
20:10:08 jaypipes this is precisely the conversation I had with gibi and mlavalle earlier today.
20:10:16 dansmith nova could, for example, be configured to ask placement for bandwidth resource, but never tell neutron about it, if we want general recordkeeping and kinda soft quotas for distribution, but we don't need actual administrative limiting of bandwidth, for example

Earlier   Later