| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-09-24 | |||
| 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 | mriedem | ftersin had a patch to at least name the volumes that nova created | |
| 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: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? | |
| 14:29:13 | mriedem | that's what i said above | |
| 14:29:19 | dansmith | I know | |
| 15:02:05 | efried | jaypipes: "efried: I specifically left out the "identification of the provider before you need it" because the clients of such a descriptor file would undoubtedly have different ideas of how to map local identifiers to RP identifiers." | |
| 15:02:44 | efried | jaypipes: If we're talking about RPs representing devices, yeah, which is what those last two specs are trying to define. | |
| 15:03:09 | efried | jaypipes: And those specs are attempting to account for the differences in hypervisors etc. | |
| 15:03:25 | efried | jaypipes: But what about e.g. NUMA node RPs? | |
| 15:03:41 | jaypipes | efried: yes. that is why I didn't put multiple providers in a single provider descriptor file and left it up to the caller to determine whether they use something like a directory with descriptor files named for the provider UUID or the provider's "local name" (NUMA0, compute_node, some PCI address, whatever...) | |
| 15:04:38 | jaypipes | efried: each hypervisor (or thing like Cyborg) is going to have its own way of identifying local devices. | |
| 15:04:54 | efried | I guess the same thing applies: as long as we've specified/documented how those RPs are going to be named, presumably the consumer can figure out what the names are going to be beforehand. | |
| 15:04:57 | jaypipes | efried: and therefore each hypervisor needs to "own" the mapping of its local device name to the resource provider UUID | |
| 15:05:13 | efried | well, yeah, but not everything is a device. | |
| 15:05:13 | jaypipes | efried: yes, exactly my point. | |
| 15:05:37 | bauzas | mmmm | |
| 15:05:49 | jaypipes | efried: if libvirt wants to call its root compute node provider "compute_node_{hostname}" cool. but Xen might call it, e.g. "dom0_{hostname}" | |
| 15:06:01 | bauzas | so the problem is to know which is which, right? | |
| 15:06:01 | jaypipes | efried: my point being we don't want to hard-code the names of things. | |
| 15:06:25 | efried | cdent's concern was that we don't want to require the consumer to go get a report from placement in order to figure out what's named what and then populate the file. His point was that that would be a PITA for deployment tools like ansible. | |
| 15:06:54 | efried | jaypipes: Oh, certainly don't want to hardcode the name of anything - couldn't if we wanted to. | |
| 15:07:40 | efried | but I guess we *do* need to make sure that the names are generated in a deterministic fashion that an operator can reproduce. | |
| 15:07:49 | jaypipes | efried: well, that's essentially what cdent's gripe involves: hard-coding the name of the compute node resource provider so tools like ansible can have a stable way of calling things like `openstack provider-inventory $HOSTNAME` | |
| 15:08:13 | efried | We've got to have a starting point. | |
| 15:08:26 | efried | and we've already established that part, I thought. | |
| 15:08:34 | jaypipes | efried: what part? | |
| 15:08:56 | efried | The root compute RP's UUID (the host UUID) and name (the node UUID) - right? | |
| 15:09:13 | efried | in non-ironic those are the same | |
| 15:09:15 | jaypipes | efried: yes, that ship is sailed. | |
| 15:09:22 | efried | okay, and I don't think that's a bad thing. | |
| 15:09:29 | jaypipes | efried: even for ironic. | |
| 15:09:36 | jaypipes | it's just the compute_nodes.uuid value that is used. | |
| 15:09:59 | efried | um, I thought for ironic the node UUID was different because multiple nodes managed by one host. | |
| 15:09:59 | jaypipes | efried: hold up, that's not true. | |
| 15:10:02 | efried | yeah | |
| 15:10:06 | efried | anyway, beside the point | |
| 15:10:11 | jaypipes | efried: we use compute_nodes.hypervisor_hostname | |
| 15:10:13 | jaypipes | as the RP name. | |
| 15:10:13 | efried | point is that we've already established a rule | |