| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-27 | |||
| 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 | |
| 20:10:26 | dansmith | if you mine it out of placement, you have no idea the semantics of the data you're examining | |
| 20:10:27 | efried | if this was a neutron-specific or nova-specific thing, okay. I don't see it that way, though. | |
| 20:10:33 | jaypipes | sean-k-mooney[m]: that is what granular request groups are for. | |
| 20:10:55 | efried | jaypipes: granular request groups don't solve it. | |
| 20:10:56 | dansmith | efried: the port case is a nova/neutron conversation and placement should C its way out | |
| 20:11:04 | dansmith | efried: for disks, it's nova/nova or nova/cinder or whatever | |
| 20:11:46 | jaypipes | efried: how is granular request groups not for solving the case of "gimme 2 of these resources from different providers"? | |
| 20:11:54 | sean-k-mooney[m] | placement is the thing to model all quantitive resouces with and qualitive tratis however so i may want to express affities between resouce in the future. for now i gues a filter could be used but i would be somewhat concered that we would get no valid host becaue of the limit we pass into placement | |
| 20:11:58 | efried | jaypipes: We have no way to say "from different providers". | |
| 20:12:09 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: tox.ini: remove the stale 'minversion = 1.4' https://review.openstack.org/530776 | |
| 20:12:10 | efried | jaypipes: Unless there happen to be traits we can exploit. | |
| 20:12:11 | dansmith | efried: that's what I was saying, | |
| 20:12:15 | jaypipes | that's the whole dang point behind granular request groups. | |