| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-06 | |||
| 12:06:07 | gibi | could a second core look at this code removal patch? https://review.openstack.org/#/c/505164/ | |
| 12:18:33 | gibi | bauwser: hi! you can still support my embarrassment in https://review.openstack.org/#/c/509750 if you would like to :) | |
| 12:19:14 | fried_rice | Gluten free, if you please. | |
| 12:20:11 | fried_rice | cdent Perhaps you'd be willing to give some feedback on these edge cases that came to me in my sleep (or lack thereof) last night. | |
| 12:21:10 | cdent | I can try, but these cases keep confusing me, but since it will probably help to talk about it, shoot. | |
| 12:21:26 | fried_rice | If I ask for CUSTOM_FOO:4, is it *ever* legal for placement to give me 3 CUSTOM_FOOs from one RP and 1 from a different RP? | |
| 12:22:32 | cdent | In the fundament case of resource providers and inventory, no | |
| 12:22:40 | cdent | the request is a for a chunk of size 4 | |
| 12:22:57 | fried_rice | Here's the thing: it makes total sense for the answer to be "yes" for something like VFs on separate PFs, all other traits being equal. Because e.g. what if I ask for 4 VFs and I've only got 2 on each PF? | |
| 12:23:13 | cdent | right, I was just going to say “vfs make that weird" | |
| 12:23:36 | fried_rice | But even there, if I'm asking for e.g. bandwidth inventory along with my VF count, how do I split that up? | |
| 12:23:47 | cdent | and also why I said “fundament[al]” because I think nested makes some of these decisions less clear | |
| 12:24:05 | cdent | (btw, it is great that you are exploring this stuff) | |
| 12:24:06 | fried_rice | And it makes *no* sense for something like DISK_GB. If I ask for 4, I don't want you giving me 1GB from each of 4 providers. | |
| 12:24:28 | fried_rice | So let's put that to bed and say Nay. | |
| 12:24:45 | cdent | this issue may be why in some conversations VFs have been proposed as resource providers | |
| 12:24:55 | fried_rice | eek | |
| 12:25:02 | cdent | ikr | |
| 12:25:23 | fried_rice | I mean, I guess you could do that, in the "pre-create" case like current VF passthrough does. | |
| 12:25:47 | fried_rice | No good in the "create VF dynamically" case of the future. | |
| 12:25:58 | fried_rice | cdent Okay, so next thing: | |
| 12:26:18 | fried_rice | Back to the VF scenario, if I ask for VF:2,BANDWIDTH:20000 | |
| 12:26:33 | fried_rice | I'm answering my own question. | |
| 12:26:35 | zioproto | bauwser: still around here ? | |
| 12:26:42 | fried_rice | Those are total chunks on the RP. | |
| 12:26:48 | zioproto | it comes out that the uuid from the stacktrace is pretty unique | |
| 12:26:53 | fried_rice | Placement doesn't care how they're going to be split up | |
| 12:27:02 | zioproto | it is the only instance in the cloud that matches this query | |
| 12:27:06 | zioproto | select * from instances where vm_state="shelved_offloaded" | |
| 12:27:13 | fried_rice | That's up to the virt driver once it gets that information (which we still don't have a way of doing yet - discussion Monday) | |
| 12:27:45 | cdent | yup | |
| 12:27:56 | fried_rice | So I guess the op would have to assume each VF will get 10000. And if they want a different split, they can specify them as separate request numbers (per the spec I'm composing). | |
| 12:28:02 | fried_rice | Cool cool. | |
| 12:28:10 | fried_rice | cdent Thanks for sounding-boarding. | |
| 12:28:22 | cdent | you’re welcome | |
| 12:28:23 | fried_rice | (Hopefully it wasn't too much like water-boarding) | |
| 12:28:34 | cdent | not today | |
| 12:29:48 | fried_rice | jaypipes I don't need you anymore. | |
| 12:30:36 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add snapshot id to the snapshot notifications https://review.openstack.org/453077 | |
| 12:31:34 | fried_rice | cdent Oh, BUT if I ask for CUSTOM_FOO:3 and CUSTOM_BAR:2, placement *could* give me those guys from different RPs | |
| 12:31:52 | fried_rice | That is, 3 CUSTOM_FOOs from RP1 and 2 CUSTOM_BARs from RP2 | |
| 12:32:32 | cdent | fried_rice: it depends on how you are forming your request and what sort of sharing or nested relationship there is between rp1 and rp2 | |
| 12:32:57 | jaypipes | fried_rice: heh | |
| 12:33:12 | cdent | in a pre-nested universe rp1 and rp2 would need to associated in the same aggregate | |
| 12:33:22 | fried_rice | leakypipes I take it back; feel free to weigh in on the latest craziness | |
| 12:33:47 | fried_rice | cdent Same aggregate, interesting. | |
| 12:33:55 | fried_rice | What if there are no aggregate associations? | |
| 12:34:10 | cdent | fried_rice: same _placement_ aggregate (which is not the same as a nova aggregate) | |
| 12:34:19 | fried_rice | Oh, I get it, because that's the only way you don't get VCPU from one host and MEM_MB from another. | |
| 12:34:31 | fried_rice | Does RT implicitly create aggregates today? | |
| 12:35:02 | cdent | not yet, shared is only implemented on the placement side so far, not the nova side | |
| 12:35:10 | cdent | and it got punted down the priority stack | |
| 12:36:23 | fried_rice | Well. | |
| 12:36:28 | fried_rice | That's going to get interesting. | |
| 12:37:12 | fried_rice | So *with* nested but *without* shared, we would have to enforce that semantic as "same root provider". | |
| 12:38:27 | fried_rice | FYI, the semantic I'm wrestling with is how resources are bound together (or not) with this numbered syntax thingy. | |
| 12:39:26 | fried_rice | And what I've been leaning towards is: When you use the (existing) "un-numbered" deal, the rule is "same root provider". But when you use a "numbered" deal, the rule is "same *provider*". | |
| 12:39:32 | fried_rice | cdent leakypipes ^ | |
| 12:39:57 | cdent | that’s kind of been my assunption too | |
| 12:40:00 | fried_rice | We've gotta have a way to express that second thing; otherwise I might wind up with my VF inventory from one PF and my bandwidth inventory from another. | |
| 12:40:35 | fried_rice | But | |
| 12:40:40 | fried_rice | Do we need to be able to do that first thing at all? | |
| 12:41:04 | fried_rice | Just thinking out loud here. I believe the answer is "yes". Because it's the most flexible and simplest UX. | |
| 12:41:21 | cdent | I think “yes” is correct, because we may not care, we just want some stuff | |
| 12:41:47 | fried_rice | Cool deal. And I can't think of a case you couldn't cover between those two options. | |
| 12:41:57 | fried_rice | Except the ones for which we need aggregates. | |
| 12:42:21 | fried_rice | Whereupon the "same root provider" rule extends to "same root provider *or* aggregate" | |
| 12:42:54 | fried_rice | Hum, (how) does aggregate-ness propagate around a tree? | |
| 12:44:01 | fried_rice | Was gonna say, if it applies to a whole tree, the above reduces to "same aggregate". But that doesn't cover the case where we didn't actually declare any aggregates. | |
| 12:44:27 | fried_rice | I'm inclined to think of an aggregate as kind of a special case of a trait. | |
| 12:45:48 | cdent | I’m not entirely following that logic? | |
| 12:45:50 | fried_rice | In which case, aggregates should propagate downward (from parent to child) like traits. | |
| 12:46:21 | fried_rice | Yeah, it's not fully formed in my bean. Something like... | |
| 12:46:25 | leakypipes | fried_rice: ack | |
| 12:47:57 | fried_rice | An aggregate is an "implicit trait" that you don't actually ask for, but that we kinda add to the request as we go along. That is, once we pick a RP for one piece of the request, we implicitly add its invisible-aggregate-trait for purposes of the rest of the request, so we only get the rest of the inventory from RPs with that same invisible-aggregate-trait. | |
| 12:48:06 | fried_rice | leakypipes What were you acking? | |
| 12:48:10 | leakypipes | fried_rice: ack on thing above about when you use a numbered deal, that means same provider. | |
| 12:48:19 | fried_rice | leakypipes Cool | |
| 12:48:33 | leakypipes | fried_rice: aggregates don't have traits. aggregates are nothing but grouping mechanisms | |
| 12:49:14 | fried_rice | yah, I get that, but am I off base logically thinking of them as described ^x4? | |
| 12:51:49 | cdent | leakypipes: am I right that the nested stack awaits resolutino of the no-orm stack (want to mention that in the rp update if it is in fact true)? | |
| 12:54:27 | fried_rice | cdent That's what I have been led to understand. | |
| 12:54:37 | cdent | ✔ | |
| 12:54:48 | fried_rice | It also occurred to me that I hadn't seen the code on the placement side that handles tree-ness for GET /allocation_candidates | |
| 12:55:04 | fried_rice | Like, the SQL magic that does downward trait propagation and suchlike. | |
| 12:55:17 | cdent | doesn’t exist yet as far as I’m aware? | |
| 12:55:17 | fried_rice | At least, I don't *think* I've seen that. | |
| 12:55:24 | fried_rice | okay. | |
| 12:55:54 | cdent | parts of it will be in https://review.openstack.org/#/q/topic:bp/nested-resource-providers+status:open | |
| 12:56:28 | fried_rice | cdent Yeah, I reviewed that stack and don't recall seeing the bits I'm talking about. | |
| 13:02:34 | openstackgerrit | OpenStack Proposal Bot proposed openstack/os-vif stable/ocata: Updated from global requirements https://review.openstack.org/490256 | |
| 13:14:54 | openstackgerrit | Matthew Booth proposed openstack/nova-specs master: Virtual instance rescue with stable disk devices https://review.openstack.org/510106 | |
| 13:15:30 | mdbooth | lyarwood: ^^^ | |
| 13:16:04 | mdbooth | lyarwood: Although it's your spec with only request REST API changes | |
| 13:18:46 | cdent | https://thebritishdrea.com/?text=Nested+providers+will+fix+That | |
| 13:24:53 | mdbooth | cdent: Lol | |
| 13:40:28 | andreykurilin | mriedem: hi! Do you know anything merged recently which could affect pagination? | |
| 13:40:45 | superdan | andreykurilin: pagination of instances? | |
| 13:40:49 | andreykurilin | yes | |
| 13:40:55 | superdan | andreykurilin: what are you seeing? | |