Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-27
15:23:11 mriedem bauwser: i already tried
15:23:13 bauwser mriedem, sdague: it's not like we can pretend it works
15:23:33 bauwser mriedem: the fun part of that is OSC https://github.com/openstack/python-openstackclient/blob/e0d7119c6dcba5666f2a0916b9a6e347e2e2758c/openstackclient/compute/v2/server.py#L621
15:23:44 mriedem bauwser: https://review.openstack.org/#/c/452546/
15:28:00 leakypipes fried_rice, mriedem: I'm just going to wait on updating the REST API n-r-p patch to update the placement-api-ref until fried_rice's patch lands, since I'm gonna need to change to 1.12 anyway.
15:28:11 fried_rice ack
15:28:42 bauwser mriedem: not fully understanding the problem with device names that feodor is mentioning
15:29:42 openstackgerrit Balazs Gibizer proposed openstack/nova master: Deduplicate instance.live_migration notification samples https://review.openstack.org/515745
15:29:55 bauwser mriedem: oh they somehow want some way to identify which BDM to update
15:30:05 bauwser don't BDMs have UUIDs ?
15:30:15 mriedem bauwser: not yet
15:30:26 mriedem bauwser: but mdbooth is adding them in i think
15:31:04 bauwser mriedem: so that would solve the problem IMHO
15:33:12 mdbooth bauwser: Indeed I will add BDM uuids.
15:33:25 mriedem bauwser: idk, it
15:33:37 mriedem it's been a long time since i had ftersin's bfv issue in my head
15:33:42 mriedem but it was something for ec2 of course
15:33:46 mdbooth bauwser: I was thinking during our call earlier, btw, that device names in the context of the api do mean something, just not really what people think.
15:34:05 mdbooth Which looks like what I wrote in that review ages ago that I'd completely forgotten about.
15:34:36 mdbooth i.e. 'sda' means 'the first disk on a scsi bus'
15:35:00 mdbooth It *doesn't* mean that your linux OS will create it as /dev/sda, though
15:35:33 bauwser mdbooth: right, it's an identifier
15:35:51 mdbooth tags mean something specific
15:36:04 bauwser mdbooth: but for the worst, we decided that this identifier should look like a device name, which is IMHO the worst terrible idea
15:36:10 rabel Hi there, can we merge https://review.openstack.org/#/c/494169/ now? I think it is really ready by now.
15:36:12 mdbooth uuids would also mean something specific, although I don't have any plans to expose them to the user explicitly
15:36:46 bauwser mdbooth: looks to me it's a cinder problem
15:36:50 mdbooth bauwser: Yes, agreed.
15:37:01 mdbooth ... but not to cinder ...
15:37:03 bauwser mdbooth: if you need something to tag your volumes, it's cinder, not nova
15:37:06 mdbooth How's it a cinder thing?
15:37:23 mdbooth Nah, that's totally a Nova thing
15:37:52 mdbooth Cinder just gives us a repository of bits. It's entirely Nova's domain how that's presented to the guest.
15:38:37 bauwser mdbooth: what is the purpose of tagging that?
15:39:10 bauwser I'm surely not getting the full picture, but I don't get why I need to keep information on how my volume is presented to the guest
15:39:15 mdbooth Device tagging? It's so the guest OS can identify specific devices which were specified by the api.
15:39:39 bauwser mdbooth: oh, but that's a totally different problem
15:39:52 bauwser mdbooth: and surely device names don't solve it
15:40:15 bauwser mdbooth: if you need some device tagging like we did for NICs, I understand that's a nova problem
15:40:23 mdbooth Device tagging is a much, much better way to solve the same problem.
15:40:34 bauwser I just don't understand why it blocks us to get rid of device names
15:40:52 bauwser because device names wasn't helping to solve the problem you mention on the guest side
15:41:17 bauwser it's even worst : you think it will help
15:41:27 bauwser by 'you', I mean the application developer
15:41:41 bauwser so for example, I'm a user
15:42:01 bauwser I'm using device names because I think it will give me a way to know which device I'm getting on the guest side
15:42:07 bauwser guess what ? It doesn't work
15:42:37 bauwser like I said to you in our meeting, I played with it in Essex
15:42:41 bauwser and Folsom
15:42:45 bauwser totally a mess
15:43:00 openstackgerrit Eric Fried proposed openstack/nova master: Update placement api-ref: allocations link in 1.11 https://review.openstack.org/515748
15:43:01 bauwser I learned hard that device names weren't a firm contract
15:43:18 fried_rice mriedem leakypipes ^ I didn't bother to base it on the one in the gate; should I?
15:43:58 leakypipes fried_rice: I don't personally mind if mriedem is cool with that
15:45:29 mriedem add a depends-on at least
15:45:34 leakypipes fried_rice: +2 from me.
15:45:51 leakypipes fried_rice: good point from mriedem on the depends-on
15:47:21 openstackgerrit Eric Fried proposed openstack/nova master: Update placement api-ref: allocations link in 1.11 https://review.openstack.org/515748
15:47:28 fried_rice leakypipes mriedem depends-on ^
15:47:45 mdbooth bauwser: Was just reading that review back. I've evicted that context from my mental cache ;)
15:48:18 mdbooth bauwser: Sounds like the issue was that there's an existing useful interaction with image-defined bdms
15:48:43 mdbooth Without more spelunking, though, I don't recall what that interaction is
15:49:42 mdbooth If that were the case, though, bdm uuids wouldn't be a replacement.
15:51:40 mdbooth ...but device tags could be
15:51:55 openstackgerrit Balazs Gibizer proposed openstack/nova master: Deduplicate instance.reboot notification samples https://review.openstack.org/515751
15:55:04 fried_rice sdague FYI, I think there's still something wrong with that cinder patch. I should -W it.
15:59:34 leakypipes rabel: reviewed.
16:00:23 rabel leakypipes: thank you
16:09:55 cdent leakypipes: see my response on https://review.openstack.org/#/c/510626/ for why project_id and user_id was not added on /rp/u/allocations _now_
16:19:53 jianghuaw leakypipes, bauwser: I have a question about vGPU's inventory update. it invoking get_inventory() when compute_node is changed: https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L807
16:20:42 jianghuaw But for vGPU, we only report it via inventory no new fields saved in obj of compute_node.
16:22:32 jianghuaw I see there is inventory caching in resource provider tree. and a new function update_inventory() is implemented.
16:22:53 jianghuaw But I assume that's only for nest-RP. right?
16:23:06 openstackgerrit David Rabel proposed openstack/nova master: VMware: add support for graceful shutdown of instances https://review.openstack.org/494169
16:24:00 jianghuaw leakypipes, bauwser: I think our plan is to implement vGPU by associate the inventory on compute node as the first step. so not depending on the n-r-p.
16:25:21 jianghuaw then how to trigger the inventory update without resource provider tree?
16:27:35 bauwser jianghuaw: see my libvirt change
16:27:48 bauwser jianghuaw: I'm hoping to push a new revision by tonight
16:29:18 jianghuaw is this already included in the existing patch? bauwser
16:29:57 jianghuaw or will be in the new revision?
16:30:21 rabel leakypipes: is the new patchset ok?
16:30:25 jianghuaw bauwser, I didn't see that part in https://review.openstack.org/#/c/514763
16:35:18 jianghuaw bauwser, I was thinking we should make it to invoke get_inventory regardless compute_node changed or not. caching inventory locally; and update inventory to placement if inventory changed.
16:36:49 jianghuaw bauwser, Good to know you've already considered it.
16:40:22 jianghuaw leakypipes, bauwser, superdan: it's appreciated if you can have a look at this patch for get_inventory in XenAPI: https://review.openstack.org/#/c/339204/
16:40:43 jianghuaw hope it be an easy one:-)
16:40:47 leakypipes jianghuaw: will do shortly. on phone right now.
16:41:07 jianghuaw leakypipes, thanks:-)
16:45:31 leakypipes cdent: yes, that makes sense.
16:47:30 bauwser jianghuaw: sorry, I was super busy prepping the new rev
16:47:40 bauwser jianghuaw: so, basically, we have the same problem with libvirt
16:47:52 bauwser jianghuaw: for example, we have a list of supported types
16:48:04 bauwser jianghuaw: then, the operator selects a specific type
16:48:16 bauwser (if you see my change, we only support one)
16:48:33 bauwser jianghuaw: so, the inventory is saying N+M
16:48:50 bauwser where N is the allocatable mdevs, and M is the already allocated ones
16:49:38 bauwser if the operator modifies that, then it's creating a problem because when you create a mdev by a type, the other types for the same device are getting 0 allocable mdevs
16:51:13 openstackgerrit Sylvain Bauza proposed openstack/nova master: WIP: libvirt: Provide VGPU inventory for a single GPU type https://review.openstack.org/514763
16:51:23 bauwser jianghuaw: new revision ^
16:51:38 jianghuaw yes. I see. It can't create mdev for the other types once created a specific type of mdev.

Earlier   Later