| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-23 | |||
| 20:38:49 | melwitt | thanks | |
| 20:41:54 | arvindn0_ | mriedem: wanted to quick check something on the scenario 2 i detailed in the comment | |
| 20:43:08 | arvindn0_ | a host with two SRIOV nic. One is normal SRIOV nic, another one with some kind of offload feature. | |
| 20:43:46 | melwitt | yikun: hi, I know you're not around right now but FYI your blueprint "Add host/hostId to instance action events API" has been added to a review runway https://etherpad.openstack.org/p/nova-runways-rocky | |
| 20:44:37 | arvindn0_ | Initial instance launch happens with SRIOV_VF:1 allocated, rebuild lauches with modified request with traits=HW_NIC_OFFLOAD_X, so basically we want the instance to be allocated the second nic | |
| 20:45:30 | arvindn0_ | but the original allocation happens against nic1 and since in rebuild the original allocations are not changed, we have wrong allocations | |
| 20:46:09 | arvindn0_ | mriedem: is the above scenario an issue if we use GET /resource_providers/{rp_uuid}/traits approch? | |
| 20:49:28 | mriedem | arvindn0_: did you see efried's reply in the mailing list? | |
| 20:50:07 | mriedem | even with efried's suggestion, that scenario is likely a gap yes | |
| 20:50:40 | arvindn0_ | mriedem: trying to figure out the mailing list...i only get digests....do you have a link? | |
| 20:50:44 | mriedem | we need to have some way of knowing, will a rebuild with a new image result in new allocations and if so, fail the rebuild | |
| 20:51:13 | mriedem | you can change your subscription to not be digests :) | |
| 20:51:24 | mriedem | http://lists.openstack.org/pipermail/openstack-dev/2018-April/129734.html | |
| 20:51:57 | mriedem | arvindn0_: also, what you're describing above is this bug https://bugs.launchpad.net/nova/+bug/1763766 | |
| 20:51:57 | openstack | Launchpad bug 1763766 in OpenStack Compute (nova) "nova needs to disallow topology changes on image rebuild" [Medium,Triaged] | |
| 20:51:58 | efried | mriedem, arvindn0_: With what I suggested, you will still know that. Because you know the RPs you've already allocated from (and which you haven't). | |
| 20:52:23 | mriedem | efried: i'm not sure we do, we just have the root provider uuid in the scheduler filter | |
| 20:52:36 | mriedem | unless we are going to build a ProviderTree object or something | |
| 20:52:55 | efried | mriedem: Do you have access to a SchedulerReportClient from wherever you are? | |
| 20:53:01 | mriedem | sure | |
| 20:53:03 | efried | mriedem: If so, then yeah, you have that ability with a single call. | |
| 20:54:07 | efried | mriedem: https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L986 would be that call. | |
| 20:54:36 | efried | The 'ensure_root' part is slightly uncomfortable, but you know the root exists when you call this. | |
| 20:54:42 | efried | And we can factor that out of there if it's an issue. | |
| 20:57:06 | munimehan | All, when nova generates VM definition it don't generate the PCIs for guest addresses, is there a way to manipulate those to make it in sync for the interface order | |
| 20:57:58 | arvindn0_ | efried: good suggestion...will look into that. | |
| 20:58:59 | arvindn0_ | btw currently in the image_props_filter.py we dont have SchedulerReportClient...we can create and get access...but now we have 2 API calls from the filter.... | |
| 21:00:15 | efried | arvindn0_: Do you have a resourcetracker? | |
| 21:00:23 | efried | arvindn0_: or a schedulerclient? | |
| 21:01:00 | arvindn0_ | nope...currently the filters make 0 api calls....so no clients of any sort | |
| 21:01:44 | efried | arvindn0_: But we were going to have to call into placement one way or another (unless we went with option 1 and just blocked the whole thing). | |
| 21:02:15 | efried | arvindn0_: So yeah, you're not getting around that. And those should be pretty quick calls, one would hope. | |
| 21:02:49 | efried | arvindn0_: The set logic around required vs forbidden will be a little tricky. | |
| 21:02:54 | arvindn0_ | yup...i was just pointing out that we might now have to make 2 calls, but like you said they should be quick since they are focussed on only the current compute node | |
| 21:03:26 | arvindn0_ | we dont support forbidden traits in images i think... | |
| 21:04:58 | efried | arvindn0_: If you did, I think you would probably have to do two separate GET /resource_providers calls (so three placement calls total) - one for required and one for forbidden. | |
| 21:05:24 | efried | arvindn0_: Sorry, I take that back - I would have to think that through when I'm not so distracted. | |
| 21:06:04 | arvindn0_ | efried: will save you time, we dont support forbidden traits in image...we only support required traits | |
| 21:06:14 | efried | k | |
| 21:07:05 | efried | arvindn0_: I'm thinking through the logic, though, trying to figure out how you will actually know you're good, even with required. | |
| 21:08:36 | efried | arvindn0_: Aha, actually, it's easier than I thought. | |
| 21:09:48 | efried | arvindn0_: You actually *only* need the call to get_provider_tree_and_ensure_root. You can walk that guy and collect the set of all traits from all the RPs you're already allocated from. Subtract that from the set of traits in your image. If there's anything left over, fail. Otherwise you're good. | |
| 21:10:42 | arvindn0_ | how do we know our allocated RP's? | |
| 21:10:48 | arvindn0_ | is that part of the provider tree? | |
| 21:11:15 | efried | Yes, you pass in your compute node UUID | |
| 21:11:21 | efried | You'll get back a ProviderTree. | |
| 21:11:33 | efried | wait, hold on. | |
| 21:12:07 | arvindn0_ | efried: not too familiar with the provider tree object...my understanding provider tree will return all traits etc | |
| 21:12:28 | arvindn0_ | but not which RP is allocated to us... | |
| 21:12:33 | efried | yes it will. For the whole tree, and associated sharing providers. And you need ... | |
| 21:12:34 | efried | exactly. | |
| 21:12:54 | efried | arvindn0_: Now, we're focused on an instance here, right? | |
| 21:12:59 | efried | arvindn0_: Not the whole host. | |
| 21:13:01 | arvindn0_ | yup | |
| 21:13:44 | arvindn0_ | this is rebuild of that instance...so we need to know what resource was allocated with what traits... | |
| 21:14:06 | efried | So what you'll *actually* want to get is the *allocations* for the instance. From that you can get the providers associated with your instance. Walk the ProviderTree on just those, peeling out the traits. Subtract that from the set of traits in your image. If there's anything left over, fail. Otherwise, you're good. | |
| 21:14:08 | arvindn0_ | we cant also do an aggregate of all the traits, because we want to ensure a 1:1 mapping | |
| 21:14:23 | efried | arvindn0_: That doesn't make sense. | |
| 21:14:39 | efried | arvindn0_: What do you mean by 1:1 mapping? | |
| 21:15:01 | efried | arvindn0_: This is one of the limitations with the entire "traits in images" deal. We don't have any way to correlate the traits to nested providers. | |
| 21:15:29 | efried | arvindn0_: So as I mentioned in my email, we just have to assume "anywhere in the tree". Which will actually work 99.9% of the time. | |
| 21:15:40 | efried | And I think the other .1% is an acceptable risk. | |
| 21:16:46 | arvindn0_ | if a instance has multiple allocations to multiple sriov nics with different traits we need to make sure each allocation maps to each instance of sriov nic....i think...let me think about it more and provide a scenario | |
| 21:17:01 | efried | arvindn0_: You can't do that with image traits, at all, sorry. | |
| 21:17:22 | efried | arvindn0_: Because one thing we explicitly said in that spec review was that we can't correlate image traits with individual granular groups. | |
| 21:18:03 | efried | arvindn0_: The best you're going to be able to do is say, "do we have *any* nic already allocated that has this trait?" | |
| 21:18:32 | arvindn0_ | ahh..yea...we dont support granular groups/numbered traits | |
| 21:18:33 | efried | arvindn0_: Which is the exact same level of granularity you would have had when you initially created the instance, if you were using image traits at that time. | |
| 21:18:54 | efried | arvindn0_: And it's just a known limitation that if you used a flavor for creation, and an image for the rebuild, you've got reduced capabilities. | |
| 21:20:00 | arvindn0_ | efried: is this the API GET /allocations/{consumer_uuid} for getting allocations for an instance? | |
| 21:20:17 | efried | yes. Use the instance UUID as the consumer_uuid. | |
| 21:24:36 | efried | arvindn0_: Email followup coming... | |
| 21:25:20 | openstackgerrit | Julia Kreger proposed openstack/nova master: DNM: Test: Ironic: Lock the instance if plug vifs https://review.openstack.org/563714 | |
| 21:25:26 | arvindn0_ | efried: thanks | |
| 21:27:13 | arvindn0_ | efried: wait...another potential issue | |
| 21:27:31 | efried | arvindn0_: http://lists.openstack.org/pipermail/openstack-dev/2018-April/129740.html | |
| 21:27:34 | efried | oh. Too late :) | |
| 21:27:37 | arvindn0_ | efried: nvm...it should work | |
| 21:27:55 | efried | arvindn0_: Okay. Let me know if you see holes. Like I say, I'm distracted atm, so no guarantees. | |
| 21:27:59 | arvindn0_ | If there's anything left over on the image traits, we fail | |
| 21:28:07 | efried | exactly. | |
| 21:28:53 | openstackgerrit | Michael Still proposed openstack/nova master: Move image conversion to privsep. https://review.openstack.org/554437 | |
| 21:28:54 | openstackgerrit | Michael Still proposed openstack/nova master: We don't need utils.trycmd any more. https://review.openstack.org/554439 | |
| 21:28:55 | openstackgerrit | Michael Still proposed openstack/nova master: We no longer need rootwrap. https://review.openstack.org/554438 | |
| 21:30:09 | arvindn0_ | efried: you think fast :) glad i could catch up in IRC | |
| 21:30:24 | openstackgerrit | Michael Still proposed openstack/nova master: Move IVS VIF plugging into the new utilities module. https://review.openstack.org/557552 | |
| 21:30:25 | openstackgerrit | Michael Still proposed openstack/nova master: Move create_tap_dev to the new utility module. https://review.openstack.org/557835 | |
| 21:30:26 | openstackgerrit | Michael Still proposed openstack/nova master: Move set_vf_interface_vlan to the new utility module. https://review.openstack.org/558487 | |
| 21:32:34 | arvindn0_ | efried: btw, GET /allocations/{instance_uuid} does not provide traits? | |
| 21:32:46 | arvindn0_ | that would have made it much easier...any plans to add this? | |
| 21:36:14 | efried | arvindn0_: I've proposed a similar "improvement" in the past (https://review.openstack.org/#/c/521875/), but the PTB deemed this unnecessary, expressing a preference for lots of smaller calls and reduced API breadth/complexity. | |
| 21:36:31 | efried | I should abandon that... | |
| 21:37:40 | arvindn0_ | cool...thanks the history helps so i dont spend time exploring that possibility | |
| 21:38:49 | efried | nod | |
| 21:40:22 | efried | arvindn0_: I suspect your biggest overhead is going to be building up the client. Once you have the comm channel to placement open, the individual calls should be very fast. | |
| 21:41:07 | efried | arvindn0_: ...which is why I asked if you had a resource tracker or scheduler client or any other way to get at an already-built SchedulerReportClient. mriedem, any way to get at those things from a filter without having to build afresh? | |
| 21:42:23 | arvindn0_ | i think the implementation hasnt been figured out...we could implement in the scheduler, so we dont need to recreate some clients...if we do it in the filter, then we have the overhead yes | |
| 21:43:22 | efried | gotcha | |
| 21:43:39 | efried | Well, I leave it in your capable hands. Let me know if further questions. Good luck! | |
| 21:46:27 | arvindn0_ | thanks! | |