| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-06 | |||
| 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 | fried_rice | At least, I don't *think* I've seen that. | |
| 12:55:17 | cdent | doesn’t exist yet as far as I’m aware? | |
| 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? | |
| 13:41:01 | mriedem | duh duh duh | |
| 13:41:12 | andreykurilin | superdan: marker doesn't work in some cases | |
| 13:41:49 | superdan | andreykurilin: heh, any more detail than that? :) | |
| 13:42:01 | mriedem | andreykurilin: have a failed job log? | |
| 13:42:03 | mriedem | novaclient or rally? | |
| 13:42:03 | andreykurilin | superdan: sure, just need to collect links:) | |
| 13:42:14 | andreykurilin | give me a sec | |
| 13:44:38 | andreykurilin | rally gates are failing due to an issue with pagination. we use limit=-1 option from novaclient. It is designed to make an inf loop changing the marker until the response will include an empty list. For some reasons API ignores the market in some cases. I copy-pasted the code from novaclient and added some debug messages | |
| 13:44:53 | andreykurilin | here is a ok execution - http://logs.openstack.org/83/509783/3/check/gate-rally-dsvm-neutron-existing-users-rally/1a480ab/console.html#_2017-10-05_23_02_16_892620 | |