Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-04-23
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!
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

Earlier   Later