| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-24 | |||
| 16:27:57 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Import the config drive docs from openstack-manuals https://review.openstack.org/514723 | |
| 16:27:58 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Import user-data page from openstack-manuals https://review.openstack.org/514738 | |
| 16:37:01 | openstackgerrit | Elod Illes proposed openstack/nova master: WIP: Transform scheduler.select_destinations notification https://review.openstack.org/508506 | |
| 16:39:48 | mriedem | stephenfin: well 2 down, 14 to go :) https://bugs.launchpad.net/nova/+bug/1714017/comments/9 | |
| 16:39:50 | openstack | Launchpad bug 1714017 in OpenStack Compute (nova) "User guide was not migrated to the nova repo" [Medium,In progress] - Assigned to Matt Riedemann (mriedem) | |
| 16:40:30 | mgagne | mriedem: yes (re cellv1) | |
| 16:41:00 | mgagne | mriedem: running mainly kilo and very soon mitaka | |
| 16:43:37 | sdague | stephenfin: well, I honestly don't think the on disk structure matters, it's the organizing portals | |
| 16:44:38 | stephenfin | It doesn't, but we shouldn't have content targeted at admins in the user guide (and vice versa, tbh). The folders help with that separation | |
| 16:46:15 | mriedem | btw, this isn't confusing at all https://github.com/openstack/openstack-manuals/blob/stable/ocata/doc/user-guide/source/configure-access-and-security-for-instances.rst vs https://github.com/openstack/openstack-manuals/blob/stable/ocata/doc/user-guide/source/cli-nova-configure-access-security-for-instances.rst | |
| 16:48:53 | openstackgerrit | Merged openstack/nova master: [placement] Confirm that empty resources query causes 400 https://review.openstack.org/511488 | |
| 16:48:58 | openstackgerrit | Merged openstack/nova master: [placement] add coverage for update of standard resource class https://review.openstack.org/511485 | |
| 16:49:44 | mvpnitesh | hi all , i'm trying to migrate the instance in multi node setup, after i run the command to migrate it is in migrating state for some time and later the migration is getting cancelled as the migration timeout has happened | |
| 16:56:11 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: WIP: libvirt: Provide VGPU inventory for a single GPU type https://review.openstack.org/514763 | |
| 16:56:32 | bauzas | efried: dansmith: edleafe: first attempt ^ | |
| 16:57:33 | efried | bauzas Regardant... | |
| 16:57:36 | dansmith | omg -1 no tests! | |
| 16:57:46 | bauzas | yeah, of course | |
| 16:57:56 | bauzas | I'll show the UTs soon | |
| 16:59:11 | openstackgerrit | Merged openstack/nova master: Update libvirt volume drivers to use os-brick constants https://review.openstack.org/510311 | |
| 16:59:38 | dansmith | bauzas: <3 L5833 of driver.py :) | |
| 17:00:41 | bauzas | heh, I branched mdevs from the existing PCI resources, even if libvirt config XML provides them in a PCI tree | |
| 17:03:13 | efried | bauzas This seems reasonable | |
| 17:03:57 | efried | bauzas Once virt has more control over its RPs (e.g. can add own traits) this will get more interesting. | |
| 17:22:58 | openstackgerrit | Dan Smith proposed openstack/nova master: Make live migration hold resources with a migration allocation https://review.openstack.org/507638 | |
| 17:24:35 | dansmith | stephenfin: did these answer your non-blocking questions enough to earn a +W? https://review.openstack.org/#/c/508595/8 | |
| 17:26:07 | openstackgerrit | priyaduggirala proposed openstack/nova master: Rename parameters in call() of nova/image/glance.py https://review.openstack.org/508533 | |
| 17:28:05 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: WIP: libvirt: Provide VGPU inventory for a single GPU type https://review.openstack.org/514763 | |
| 17:30:08 | dansmith | bauzas: do you have any prototype code to actually allocate a gpu device during spawn? | |
| 17:30:19 | dansmith | er, allocate is a loaded term.. "configure" maybe | |
| 17:30:22 | bauzas | dansmith: not yet, tomorrow | |
| 17:30:26 | dansmith | okay | |
| 17:30:38 | bauzas | I mostly see the direction tho | |
| 17:30:43 | dansmith | cool | |
| 17:30:59 | bauzas | once we ask for a specific GPU in the flavor, that goes to the compute | |
| 17:31:11 | bauzas | then in libvirt, I'll lookup the flavor and find the extra spec | |
| 17:31:31 | dansmith | well, in libvirt you get the allocation now | |
| 17:31:32 | bauzas | once that, I'll call out the system to create a mdev if I can't find it | |
| 17:31:43 | bauzas | oh, good to know | |
| 17:31:59 | dansmith | but yeah, same difference | |
| 17:32:24 | bauzas | lemme see where we get those allocations | |
| 17:32:32 | bauzas | my master is quite new | |
| 17:32:47 | bauzas | oh I see | |
| 17:32:54 | bauzas | allocations as a param FTW | |
| 17:33:01 | bauzas | good good | |
| 17:33:54 | bauzas | dansmith: I haven't yet looked but I suspect we call placement to pass the allocation to the virt driver, right? | |
| 17:34:01 | dansmith | yeah | |
| 17:34:03 | bauzas | I mean in the compute service | |
| 17:34:06 | bauzas | okay | |
| 17:34:07 | dansmith | yep | |
| 17:34:11 | bauzas | for that consumer ID ? | |
| 17:34:16 | dansmith | yeah | |
| 17:34:21 | bauzas | all good then | |
| 17:34:38 | bauzas | now I wonder one thing tho | |
| 17:34:56 | bauzas | say we now have the inventory reporting VGPUs | |
| 17:35:15 | bauzas | if the flavor goes asking for that, does placement magically create allocation for that RC ? | |
| 17:35:19 | bauzas | dansmith: ^ | |
| 17:35:28 | bauzas | I tend to do so, but I need confirmation | |
| 17:35:29 | dansmith | well, | |
| 17:35:35 | dansmith | placement doesn't create an allocation, no, | |
| 17:35:40 | bauzas | sorry | |
| 17:35:42 | dansmith | but it returns an allocation candidate with that init, | |
| 17:35:43 | bauzas | the claim I mean | |
| 17:35:53 | dansmith | and then scheduler will try to create an allocation from it yeah | |
| 17:36:04 | dansmith | so you should have an allocation for a vgpu when you get to spawn | |
| 17:36:12 | bauzas | *will* means I need to code ? | |
| 17:36:24 | dansmith | no, will means it will happen if it's in the flavor | |
| 17:36:31 | bauzas | oh, snap | |
| 17:36:34 | bauzas | yeah I remember | |
| 17:36:48 | bauzas | hence the scheduler.utils method that gives you the resource classes | |
| 17:37:09 | bauzas | anyway, I have a devstack, I can give it a try | |
| 17:39:11 | dansmith | good progress, thanks! | |
| 18:28:49 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add FlavorPayload.description for versioned notifications https://review.openstack.org/514782 | |
| 18:30:33 | openstackgerrit | Merged openstack/nova master: xenapi: cached images should be cleaned up by time https://review.openstack.org/465954 | |
| 18:33:52 | openstackgerrit | Dan Smith proposed openstack/nova master: Make live migration hold resources with a migration allocation https://review.openstack.org/507638 | |
| 18:39:31 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM Driver: config drive https://review.openstack.org/409404 | |
| 18:57:24 | efried | dansmith cdent edleafe You know how we've been searching for a name for the RP that's not a sharing RP? Today it's the "compute node RP" but we need a more generic name. And some have been calling it the "root RP" but that's overloading from nested. | |
| 18:57:32 | efried | So what about "anchor"? | |
| 18:57:47 | edleafe | We're sunk if we use that | |
| 18:57:54 | efried | Hah! | |
| 19:01:57 | cdent | efried: what about target? | |
| 19:02:25 | edleafe | "base"? | |
| 19:02:37 | dansmith | I didn't know we were searching for a name | |
| 19:02:48 | efried | dansmith What have you been calling it? | |
| 19:02:59 | cdent | dansmith: it’s come up on some of the reviews that include changes to shared related stuff | |
| 19:03:19 | cdent | and on some of those “root” was used, but that’s overloaded | |
| 19:03:23 | dansmith | efried: I don't know that I have.. but probably "compute node rp" | |
| 19:03:43 | cdent | dansmith: a bit specific, no? | |
| 19:04:06 | efried | Right, we'll be wanting to move away from that long term. | |
| 19:04:07 | edleafe | "radicle" is similar to root | |
| 19:04:07 | dansmith | well, I haven't really needed to refer to anything other than a compute node | |
| 19:04:07 | cdent | presumably there could be a situation where a compute node isn’t involved? | |
| 19:04:22 | edleafe | That'll get the dictionaries dusted off | |
| 19:04:25 | efried | edleafe Far out. | |
| 19:04:25 | dansmith | I guess I'm missing the need for a name | |
| 19:05:00 | efried | dansmith Generically in placement, it's not always a compute node. Or at least, we want to code up placement so that's the case. At least that's what I thought the vision was. | |
| 19:05:22 | dansmith | sure, I'm just saying I don't think I've had a need to refer to this distinction | |
| 19:05:34 | dansmith | like, I'd call it "RP" and "Sharing RP" I guess | |
| 19:05:42 | dansmith | and prefix it with "compute node" when I'm talking about that | |
| 19:05:44 | dansmith | because, you know, | |