| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-23 | |||
| 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! | |
| 23:19:17 | openstackgerrit | Merged openstack/nova stable/pike: libvirt: disconnect volume from host during detach https://review.openstack.org/560690 | |
| 23:46:47 | openstackgerrit | Zack Cornelius proposed openstack/nova-specs master: Libvirt file backed memory https://review.openstack.org/563704 | |
| #openstack-nova - 2018-04-24 | |||
| 00:02:11 | alex_xu | mriedem: yes, it is change the API behavior, do you know what happened now if I didn't specific boot_index? | |
| 00:02:23 | alex_xu | for now | |
| 00:04:18 | alex_xu | or I will check then when I reach to the office | |
| 00:36:58 | mriedem | alex_xu: yeah https://review.openstack.org/#/c/563732/ i have to update that, tomorrow | |
| 00:54:35 | openstackgerrit | Adam Harwell proposed openstack/nova stable/pike: Add support for listing hosts in cellv2 https://review.openstack.org/563797 | |
| 01:09:32 | openstackgerrit | Merged openstack/nova master: Add CPUWeigher https://review.openstack.org/379525 | |
| 01:09:41 | openstackgerrit | Merged openstack/nova master: libvirt: add support for virtio-net rx/tx queue sizes https://review.openstack.org/484997 | |
| 01:10:55 | openstackgerrit | Merged openstack/nova master: Move some tests into nova.tests.unit.notifications.objects.test_instance https://review.openstack.org/562793 | |
| 01:11:09 | melwitt | Kevin_Zheng: your blueprint was removed from the review runway today because all of the related code merged. please feel free to add comments to the log area at L144 if you have any comments or feedback about your experience with runways https://etherpad.openstack.org/p/nova-runways-rocky | |
| 01:11:53 | Kevin_Zheng | melwitt cool, I will | |
| 01:44:16 | gmann | alex_xu: testing in tempest too - https://review.openstack.org/#/c/563801/ | |
| 02:22:23 | openstackgerrit | Yikun Jiang (Kero) proposed openstack/nova master: Address nits in Iac23a574a05e62a99aab20ffce4265f4fb5a44d9 https://review.openstack.org/563802 | |
| 02:46:25 | openstackgerrit | jichenjc proposed openstack/nova master: z/VM Driver: add snapshot function https://review.openstack.org/534240 | |
| 02:46:26 | openstackgerrit | jichenjc proposed openstack/nova master: z/VM Driver: add power actions https://review.openstack.org/543340 | |
| 02:46:27 | openstackgerrit | jichenjc proposed openstack/nova master: z/VM Driver: add get console output https://review.openstack.org/543344 | |
| 02:47:43 | openstackgerrit | Yikun Jiang (Kero) proposed openstack/nova master: Address nits in Iac23a574a05e62a99aab20ffce4265f4fb5a44d9 https://review.openstack.org/563802 | |
| 03:36:15 | openstackgerrit | Michael Still proposed openstack/nova master: Use os.rename, not mv. https://review.openstack.org/562463 | |
| 04:45:50 | openstackgerrit | Julia Kreger proposed openstack/nova master: Ironic: Lock the instance if early vif plug https://review.openstack.org/563714 | |
| 06:16:11 | pratik | deletion of snapshot created from volume attached to an instance is getting stuck in 'deleting' state with NFS backend. can anyone help? https://developer.openstack.org/api-ref/compute/#delete-assisted-volume-snapshot this API returns 204 response but not sure why it gets stuck | |
| 06:26:37 | openstackgerrit | XiaojueGuan proposed openstack/nova master: reduce complex if clause to nice or clause https://review.openstack.org/563834 | |
| 06:29:06 | kashyap | stephenfin: Morning | |
| 06:29:31 | kashyap | stephenfin: It's in the commit message :-) | |
| 06:30:51 | openstackgerrit | Merged openstack/nova master: Record the host info in EventReporter https://review.openstack.org/556746 | |
| 06:31:33 | kashyap | stephenfin: IOW: | |
| 06:31:36 | kashyap | The advertized NEXT_MIN_{LIBVIRT,QEMU} versions during | |
| 06:31:36 | kashyap | [quote] | |
| 06:31:37 | kashyap | weren't actually bumped for "Queens". So let's actually bump them for | |
| 06:31:37 | kashyap | "Pike" release were set to: libvirt 1.3.1 and QEMU 2.5.0 -- but they | |
| 06:31:40 | kashyap | the "Rocky" release. | |
| 06:31:42 | kashyap | [/quote] | |
| 06:31:45 | kashyap | (From the commit message) | |
| 07:10:58 | alex_xu | jaypipes, ericyoung, we miss this case in this thread http://lists.openstack.org/pipermail/openstack-dev/2018-April/129763.html | |
| 07:15:10 | kashyap | stephenfin: And for "Stein", we've picked the NEXT_MIN versions here (this is merged): https://review.openstack.org/#/c/558171/ | |
| 07:53:27 | ygl | anyone here can help me with my issue please | |
| 07:54:01 | ygl | i have created a vm using a heat stack. when I delete that stack, I want a user script to be trigerred automatically in the VM before its deltion | |
| 07:54:16 | ygl | is that possible in openstack as of now ? | |
| 08:06:54 | bauzas | ygl: looks like it's not a Nova feature | |
| 08:07:36 | bauzas | ygl: AFAIK | |
| 08:16:02 | stephenfin | kashyap: Ah, so it was a different commit. That's what caught me out :) | |
| 08:16:18 | kashyap | stephenfin: Maybe I should've mentioned it | |
| 08:16:26 | kashyap | stephenfin: Because it requires discussion on the Operators / Dev list | |
| 08:17:39 | stephenfin | kashyap: Ah, it's fine. +Wd now | |
| 08:18:01 | kashyap | stephenfin: Most excellent. I can build other clean-up patches on top of it | |