| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-09-24 | |||
| 12:59:27 | johnthetubaguy | kashyap: seems to suggest it is discontinued, and no longer supported though | |
| 13:01:06 | kashyap | johnthetubaguy: Oh, yeah. | |
| 13:01:26 | kashyap | For completeness' sake I'll ask the open question for KVM for IBM folks. | |
| 13:01:43 | kashyap | If there's no response, we can pick with a version that aligns with the rest of all the distros. | |
| 13:02:19 | johnthetubaguy | kashyap: http://kvmonz.blogspot.com/2017/03/kvm-for-ibm-z-withdrawal.html | |
| 13:02:42 | kashyap | Ah, it's the blurb | |
| 13:02:46 | johnthetubaguy | kashyap: I think we can ignore it now, basically its all upstream, use a regular distro, appears to be the message | |
| 13:03:00 | kashyap | Okay, then. We're good. | |
| 13:03:03 | kashyap | Thanks for digging! | |
| 13:03:09 | johnthetubaguy | I was curious what it was | |
| 13:06:31 | johnthetubaguy | kashyap: next question is specify the next next, if you get me, seems like Oracle and SLES need a dig | |
| 13:07:01 | kashyap | johnthetubaguy: Right, I'll ask the SLES and Oracle folks to comment | |
| 13:07:14 | kashyap | johnthetubaguy: I'm pretty damn sure they'll also align, if I see their historical releases | |
| 13:07:37 | kashyap | The community edition, openSUSE, already ships the desired "Bionic" versions. | |
| 13:11:27 | kashyap | Thanks for helping me dig! | |
| 13:22:27 | bauzas | mriedem: quick question, when calling update_provider_tree_for_vgpus() we pass a mutable dict of allocations, and then we modify the allocations directly | |
| 13:22:55 | bauzas | mriedem: that means that we will call the placement API with the allocations dict once we call it ? | |
| 13:23:11 | bauzas | I mean, it means that the method will have to modify directly the allocations dict | |
| 13:23:12 | bauzas | ? | |
| 13:23:18 | kashyap | johnthetubaguy: gibi: As promised: http://lists.openstack.org/pipermail/openstack-operators/2018-September/015929.html | |
| 13:23:48 | bauzas | mriedem: so we expect to have the allocations dict to be modified ? | |
| 13:24:38 | mriedem | bauzas: yes https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L943 | |
| 13:24:44 | bauzas | mriedem: cool | |
| 13:29:14 | openstackgerrit | Merged openstack/nova master: nova-status - don't count deleted compute_nodes https://review.openstack.org/604495 | |
| 13:29:27 | openstackgerrit | Merged openstack/nova master: Imported Translations from Zanata https://review.openstack.org/604577 | |
| 13:30:42 | mriedem | imacdonn: you want to backport https://review.openstack.org/#/c/604495/ as well? | |
| 13:48:17 | openstackgerrit | Vlad Gusev proposed openstack/nova stable/rocky: nova-status - don't count deleted compute_nodes https://review.openstack.org/604785 | |
| 13:48:28 | openstackgerrit | Vlad Gusev proposed openstack/nova stable/queens: nova-status - don't count deleted compute_nodes https://review.openstack.org/604786 | |
| 13:50:52 | mriedem | s10: thanks | |
| 13:53:26 | dansmith | mriedem: no test on this? https://review.openstack.org/#/c/554380/ | |
| 13:54:19 | openstackgerrit | Vlad Gusev proposed openstack/nova stable/pike: nova-status - don't count deleted compute_nodes https://review.openstack.org/604788 | |
| 13:55:00 | bauzas | mriedem: just another point, you reshape first and then you only update the child inventories after that | |
| 13:55:04 | mriedem | i guess not? i wrote it in march. | |
| 13:55:15 | dansmith | ...and march is the month of no tests? :D | |
| 13:55:22 | bauzas | mriedem: is this because you don't want to have a child inventory in case the reshape provides an exception ? | |
| 13:55:23 | mriedem | that's what we agreed in dublin | |
| 13:55:37 | dansmith | I didn't realize it was a backport so was about to -1 it out of existence | |
| 13:55:49 | efried | n-sch/placement meeting in 5 minutes in #openstack-meeting-alt | |
| 13:56:54 | openstackgerrit | Merged openstack/nova master: Transform libvirt.error notification https://review.openstack.org/484851 | |
| 13:59:44 | mriedem | dansmith: before you are gone for the rest of the week, we should probably figure out what we expect users to pass for the bdm volume_type value in the compute API, | |
| 13:59:55 | mriedem | because cinder's volume create API allows passing the volume type name or ID | |
| 14:00:05 | mriedem | i was thinking the compute API would just take volume type name | |
| 14:00:07 | dansmith | it would suck to not take either | |
| 14:00:13 | dansmith | just name? | |
| 14:00:24 | mriedem | i didn't realize the volume create API took either | |
| 14:00:27 | mriedem | until 30 seconds ago | |
| 14:00:36 | dansmith | why is it hard for us to take either? | |
| 14:00:39 | mriedem | it's not | |
| 14:01:05 | mriedem | it came up while reviewing the db model changes for nova b/c he had originally restricted the volume_type column to 36 characters for volume type id | |
| 14:01:13 | mriedem | i got him to change it to 255 to allow name | |
| 14:01:16 | dansmith | ah | |
| 14:01:31 | mriedem | anyway, i asked the question on https://review.openstack.org/#/c/604687/ | |
| 14:01:33 | dansmith | and that's their name restriction? | |
| 14:01:42 | mriedem | yes | |
| 14:01:44 | dansmith | that _is_ the downside of proxy apis I suppose, but .. :) | |
| 14:01:45 | dansmith | okay | |
| 14:02:11 | dansmith | surely we're not merging that until the rest of the patches are stacked on top right? | |
| 14:02:21 | mriedem | yes he split this out b/c i asked him to | |
| 14:02:30 | mriedem | and i asked him to rebase the rest back on top | |
| 14:02:36 | dansmith | okay cool | |
| 14:07:15 | mriedem | the other thing is if nova-api is going to validate that the requested volume type exists, we'll need to know if it's an id or a name, which kind of sucks | |
| 14:07:49 | mriedem | we can do is_uuid_like for that, but ... | |
| 14:09:12 | s10 | mriedem: can I ask to add volume_name in https://review.openstack.org/#/c/604687/ or it would be too much? | |
| 14:10:20 | mriedem | s10: and eventually description and az and hints and metadata... | |
| 14:15:29 | mriedem | s10: if people are going to want to also pass volume name for the next several years, i'd rather us just add that now in the same microversion, | |
| 14:15:33 | mriedem | dansmith: ^ what do you think? | |
| 14:15:53 | mriedem | this is the definition of the slippery slope with these proxy apis | |
| 14:16:13 | dansmith | I think I said name+volume already right? | |
| 14:16:17 | dansmith | did I miss other discussion? | |
| 14:16:47 | dansmith | oh | |
| 14:16:49 | dansmith | volume name? | |
| 14:16:50 | mriedem | name + volume_type? | |
| 14:16:56 | mriedem | yes, he's asking that we also proxy a volume name, | |
| 14:17:11 | dansmith | ffs | |
| 14:17:13 | mriedem | today nova-compute doesn't give name/description to any volumes it creates | |
| 14:17:32 | s10 | mriedem: that's what we are doing :( we have our patch for volume name since 2014 and volume type since 2015. I will be happy to drop it and make our OpenStack more close to the upstream... | |
| 14:17:32 | mriedem | ftersin had a patch to at least name the volumes that nova created | |
| 14:18:09 | openstackgerrit | Stephen Finucane proposed openstack/python-novaclient master: docs: Add redirects https://review.openstack.org/604796 | |
| 14:18:10 | dansmith | and we have to handle the multi-create case where they can't be the same name yeah? | |
| 14:18:35 | mriedem | depends on what cinder allows, checking the cinder db model | |
| 14:18:38 | dansmith | presumably that means we have to have all the handling for races even against volumes we didn't reate | |
| 14:19:08 | dansmith | I guess duplicate names may be allowed as long as we refer to them by uuid | |
| 14:19:17 | dansmith | but still... | |
| 14:19:21 | mriedem | yeah i don't see any unique constraint on volume names in the cinder db | |
| 14:19:34 | dansmith | we're five minutes into this and already inches are being given | |
| 14:19:37 | mriedem | nova has that weird config to restrict server names by project or global | |
| 14:19:57 | mriedem | i suppose that's more for fqdns | |
| 14:23:30 | dansmith | well, I dunno | |
| 14:23:46 | dansmith | tbh, taking name or setting it is not something I've heard asked before | |
| 14:24:03 | dansmith | I would tend to think that if we have no real restrictions we could name it after the instance without another param | |
| 14:24:06 | dansmith | but | |
| 14:25:23 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: WIP: libvirt: implement reshaper for vgpu https://review.openstack.org/599208 | |
| 14:26:01 | mriedem | https://review.openstack.org/#/c/213433/ | |
| 14:26:09 | mriedem | ^ ftersin's old patch to name the volumes that nova creates | |
| 14:26:27 | dansmith | yeah, you said that, but... what about the volume/ | |
| 14:26:38 | dansmith | meaning, lots of people ask for volume_type, but was that the only one ask for name | |
| 14:26:39 | dansmith | ? | |
| 14:27:09 | mriedem | idk | |
| 14:27:23 | mriedem | i wouldn't be surprised if others would come out of the woodwork asking for proxying the name later | |
| 14:28:14 | dansmith | where does it end? | |