| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-05 | |||
| 12:21:51 | bhagyashris | jaypipes: Hi, Is there any placement api to get resource provider for a given instance uuid? | |
| 12:22:31 | bhagyashris | jaypipes: if there is no direct api, is it possible to get resource provider if I know the instance uuid | |
| 12:37:56 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Send soft_delete from context manager https://review.openstack.org/476459 | |
| 12:37:56 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: use context mgr in instance.delete https://review.openstack.org/443764 | |
| 12:37:57 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Transform missing delete notifications https://review.openstack.org/410297 | |
| 12:46:16 | stephenfin | efried: What do you think of this one, in that case? https://review.openstack.org/#/c/465160/ Looks like a change in behavior | |
| 12:46:38 | efried | stephenfin ... | |
| 12:49:08 | efried | stephenfin Well, I definitely don't claim understanding of the plumbing here, but if I'm reading it right, it's making an ugly/unpredictable error into a crisp, predictable one. | |
| 12:49:32 | efried | ...which IMO would not warrant a reno. | |
| 12:50:15 | efried | If it is in fact explicitly removing support for something which used-to-sort-of-work-maybe-sometimes and now definitely won't work ever for anyone, then *maybe* it warrants a reno. RBB kind of thing. | |
| 12:51:17 | stephenfin | efried: Yup, agree with all of the above. I'll drop the -1 for that and let him address sahid's comments | |
| 12:51:23 | stephenfin | efried: Thanks for the input :) | |
| 12:51:41 | efried | stephenfin Sure thing, for whatever it's worth :) | |
| 12:54:26 | efried | sean-k-mooney Can I just say I think it's neat how you start each line of a paragraph with a capital. It's like poetry. | |
| 12:55:55 | efried | One question: you said, "...in this case the bandwidth resource provider will be a child of the PF" -- not to split hairs, but wouldn't the bandwidth resource provider be the PF itself? That is, the PF needs to provide the pool of VFs *and* the pool of bandwidth... units. | |
| 13:09:23 | efried | mriedem Was going to move the pike powervm bp from approved/ to implemented/, but noticed there seems to be a script that does that for everything. Which made me assume someone else (like you) would be doing that at some designated point in the release cycle. True? | |
| 13:10:28 | kashyap | mriedem: When you're about, do you have any further remarks on this - https://review.openstack.org/#/c/498983/ | |
| 13:11:47 | jaypipes | bhagyashris: GET /allocations/{instance_uuid} | |
| 13:12:04 | jaypipes | bhagyashris: no, that's not right... never mind. | |
| 13:12:50 | bhagyashris | jaypipes: ok. | |
| 13:13:05 | efried | jaypipes bhagyashris Not sure what that means, "resource provider for an instance"? | |
| 13:13:08 | mriedem | gmann: i'm missing something here https://review.openstack.org/#/c/500369/2 | |
| 13:13:24 | mriedem | efried: see ^ | |
| 13:13:27 | jaypipes | efried: he means get the resource providers that an instance is consuming from. | |
| 13:13:41 | efried | ah, that makes sense. | |
| 13:14:14 | efried | mriedem Roger that, thanks. | |
| 13:14:59 | bhagyashris | efried, jaypipes: I have tried to search but haven't found any api or anyway I guess we can not get the resource provider if we know the instance uuid | |
| 13:15:05 | jaypipes | bhagyashris: no, I was correct the first time... GET /allocations/{instance_uuid} | |
| 13:15:25 | bhagyashris | jaypipes: ok let me check. | |
| 13:16:06 | jaypipes | bhagyashris: https://github.com/openstack/nova/blob/master/nova/api/openstack/placement/handlers/allocation.py#L111-L128 | |
| 13:16:14 | jaypipes | bhagyashris: that's what the response will look like. | |
| 13:16:33 | jaypipes | bhagyashris: you can get the resource provider UUIDs by grabbing response.get('allocations').keys() | |
| 13:16:48 | bhagyashris | jaypipes: yes | |
| 13:17:25 | bhagyashris | jaypipes: {"allocations": {"0cda7039-eee9-4ea4-90c5-78308b1990e9": {"generation": 1004, "resources": {"VCPU": 1, "MEMORY_MB": 512, "DISK_GB": 1}}}} | |
| 13:17:43 | bhagyashris | jaypipes: like this got it. | |
| 13:18:10 | jaypipes | bhagyashris: also, see here: https://developer.openstack.org/api-ref/placement/ | |
| 13:18:23 | jaypipes | https://developer.openstack.org/api-ref/placement/#list-allocations | |
| 13:19:49 | openstackgerrit | YongMing Zeng proposed openstack/nova master: optimized code https://review.openstack.org/500820 | |
| 13:20:05 | bhagyashris | jaypipes: thanks, I have two doubt can you please guide me | |
| 13:20:38 | bhagyashris | jaypipes: is it possible to assign resources from different resources providers for a given instance? | |
| 13:21:17 | jaypipes | bhagyashris: yes. | |
| 13:21:30 | jaypipes | bhagyashris: see above link for an example. | |
| 13:22:24 | bhagyashris | jaypipes: As per my finding if i used the custom resource classes to create the inventory using the resource provider then it's possible but if i used the existing resource classes then it's not possible | |
| 13:22:46 | bhagyashris | jaypipes: am i correct? | |
| 13:22:55 | bhagyashris | jaypipes: ohh ok. | |
| 13:25:37 | jaypipes | bhagyashris: custom vs. standard resource classes don't matter when creating inventory against multiple providers. | |
| 13:27:23 | bhagyashris | jaypipes: ok. | |
| 13:28:06 | bhagyashris | jaypipes: how a aggregate is selected in placement service? | |
| 13:28:24 | jaypipes | bhagyashris: just remember that when you call PUT /resource_providers/{rp_uuid}/inventory, that you are *replacing* the inventory of the resource provider each time you call that. | |
| 13:29:15 | jaypipes | bhagyashris: aggregates are not selected. only resource providers are selected. aggregates allow relationships between resource providers, for example, to denote a grouping of like providers. | |
| 13:29:31 | bhagyashris | jaypipes: for example, I have host-aggregate-1 and host-aggregate-2, and when a new request comes to boot an instance, then how the placement api decides in which host aggregate this new vm should be created | |
| 13:29:54 | bhagyashris | jaypipes: ok. | |
| 13:30:26 | jaypipes | bhagyashris: that's not how things work :) instances don't get created "in an aggregate". Instead, instances get created on a compute host. That compute host may be associated with one or more aggregates. | |
| 13:30:52 | jaypipes | bhagyashris: perhaps you're confusing availability zone with host aggregate? | |
| 13:31:22 | bhagyashris | jaypipes: yes. | |
| 13:33:53 | jaypipes | bhagyashris: availability zone is an attribute (metadata key/value pair) against a Nova host aggregate. All compute hosts in the host aggregate belong to the availability zone that the host aggregate is marked with. That said, the placement API does not have anything to do with the availability zone. The Nova host aggregate and the placement aggregate are different things. For example, a Nova host aggregate actually refers to the nova-compute | |
| 13:33:54 | jaypipes | service daemon, not the provider of resources. This is why, for example, Ironic baremetal nodes cannot individually be assigned to a Nova host aggregate. But Ironic baremetal nodes *can* be associated individually with a placement aggregate. | |
| 13:34:04 | jaypipes | bhagyashris: it's all ludicrously confusing, I know :( | |
| 13:35:02 | jaypipes | bhagyashris: perhaps you could describe what you're attempting to do so I can assist you in finding the answers you seek :) | |
| 13:43:25 | bhagyashris | jaypipes: actually my doubt was regarding the selection host aggregate in placement when i request to boot instance but host aggregates are not selected to create the instance at placement that is only used for the relationships between the providers | |
| 13:44:12 | efried | jaypipes I also would like to understand what an aggregate is (in placement context). Is this the best thing to read? https://developer.openstack.org/api-ref/placement/#resource-provider-aggregates | |
| 13:44:45 | efried | (though ^ seems to assume a foreknowledge of what a "host aggregate" is... which I lack0 | |
| 13:44:47 | efried | ) | |
| 13:45:14 | mriedem | https://docs.openstack.org/nova/latest/user/aggregates.html | |
| 13:45:22 | mriedem | for host aggregates | |
| 13:46:40 | efried | Thanks | |
| 13:49:49 | jaypipes | efried: placement aggregates are groupings of resource providers, nothing more. Placement aggregates do not have traits associated with them. Placement aggregates are not "in an availability zone" or anything like that. Nova host aggregates are groupings of nova-compute service daemons (NOT the compute hosts that actually provide the resources). Nova host aggregates have metadata key/value pairs associated with them. Nova host aggregates are | |
| 13:49:50 | jaypipes | an entity in any of themselves, whereas placement aggregates are nothing more than a UUID that provides a grouping to resource providers. | |
| 13:49:58 | jaypipes | bhagyashris: ^ you too. :) | |
| 13:50:23 | efried | jaypipes What are placement aggregates useful/used for? | |
| 13:50:38 | jaypipes | efried: associating a resource provider to another. | |
| 13:50:43 | jaypipes | efried: that's it. nothing more. | |
| 13:50:59 | efried | Associating for programmatic or human consumption? | |
| 13:51:23 | jaypipes | efried: right now, mostly programmatic. | |
| 13:51:35 | jaypipes | efried: it's currently how we handle shared resources. | |
| 13:51:48 | efried | So placement aggregates can overlap. | |
| 13:52:00 | efried | I seem to recall asking this very question in Boston :) | |
| 13:52:04 | efried | And the answer was yes | |
| 13:52:06 | stephenfin | mriedem: Could you take another look at this this week? https://review.openstack.org/#/c/412356/ | |
| 13:52:16 | edleafe | efried: placement can't select based on nova host agg | |
| 13:52:19 | jaypipes | efried: in the future, I envision aggregates being associated to each other via a distance attribute. In other words, agg A and agg B are distance 1 apart. agg X and agg A are distance 4 apart, etc. | |
| 13:52:33 | edleafe | efried: that's done in the scheduler filters | |
| 13:52:35 | jaypipes | efried: this will provide us a way to model affinity and anti-affinity concerns in placement. | |
| 13:53:03 | jaypipes | efried: yep, aggregates (either placement or Nova host aggregate) can overlap. | |
| 13:53:44 | efried | jaypipes So it also makes sense that a nested resource provider will be implicitly aggregated with its parent. | |
| 13:54:23 | efried | ...and by extension, with its "siblings" and "cousins"... | |
| 13:55:14 | jaypipes | efried: yes. I was planning on making a constraint that only root provider UUIDs could be associated with an aggregate. | |
| 13:56:55 | mriedem | stephenfin: replied | |
| 13:57:02 | stephenfin | ta | |
| 13:57:04 | mriedem | stephenfin: if we're going to play fast and loose we should at least have a release note | |
| 13:58:51 | bhagyashris | jaypipes: Thanks for your inputs :) | |
| 13:59:02 | stephenfin | mriedem: 'upgrade' section? | |
| 13:59:26 | mriedem | stephenfin: yeah i suppose | |
| 14:03:20 | sean-k-mooney | efried: hehe that is more my email client enforcing it then i doing it intentionally but thanks in any case. | |
| 14:04:32 | openstackgerrit | Stephen Finucane proposed openstack/nova master: rbd: Remove unnecessary 'encode' calls https://review.openstack.org/412356 | |
| 14:04:49 | stephenfin | sean-k-mooney: I'd suggest using something like Evolution but don't - it's buggy af :( | |
| 14:06:00 | sean-k-mooney | stephenfin: currently im still using outlook because im too lazy to figure out how to get tunderbird to work with our exchange servers. but since you helped me to get inline respconces to text only mail working i think it does the job well enough | |
| 14:06:25 | stephenfin | mriedem: Done. The important bit is that this will only affect users running under Python 3 | |
| 14:07:04 | stephenfin | sean-k-mooney: Heh, I actually blogged that when I left Intel https://that.guru/blog/sane-outlook/ | |
| 14:07:13 | stephenfin | one of my very few posts. I should probably use that more | |