| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-09-24 | |||
| 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 | jaypipes | efried: hold up, that's not true. | |
| 15:09:59 | efried | um, I thought for ironic the node UUID was different because multiple nodes managed by one host. | |
| 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 | efried | point is that we've already established a rule | |
| 15:10:13 | jaypipes | as the RP name. | |
| 15:10:59 | jaypipes | https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L1417 | |
| 15:11:52 | jaypipes | efried: ^ | |
| 15:12:19 | efried | yeah, but didn't we decide hypervisor_hostname was actually the node UUID in the ironic case? | |
| 15:12:24 | jaypipes | efried: so we already use hypervisor_hostname as RP name. | |
| 15:12:32 | mriedem | efried: yes it is | |
| 15:12:35 | jaypipes | efried: oh, I see what you mean. | |
| 15:12:39 | jaypipes | efried: yes, that is true. | |
| 15:12:47 | jaypipes | it's the Ironic node UUID. | |
| 15:13:22 | efried | right, okay, so I was wrong before that the RP UUID and name were the same for non-ironic; the name is actually the hypervisor hostname which is like text. | |
| 15:13:39 | efried | anyway, point is, we've got an established rule for both the name and the UUID of the root RP. | |
| 15:13:56 | efried | And in Denver we talked about using the parent RP's UUID as part of the child RP's name, to ensure name uniqueness | |
| 15:14:09 | efried | So that's one part of the naming rules | |
| 15:14:59 | efried | For each type of child RP as long as we make the remainder of the naming convention deterministic *and document it*, that should allow consumers to figure out how to identify them for purposes of their inventory file. | |
| 15:15:45 | efried | It may be kind of brittle in practice, but I can't think of a better solution. | |
| 15:16:31 | jaypipes | efried: I guess I'd prefer to use the root provider's *name*, not UUID, in the child provider's name. | |
| 15:16:58 | jaypipes | efried: and yes, I realize for Ironic, any child providers would have a UUID-based name since the root provider name is a UUID. | |
| 15:17:08 | efried | if we want the convention to be extensible, we should use something about the parent provider, not the root provider | |
| 15:17:17 | efried | which only gets different when we have >2 levels of tree | |
| 15:17:38 | jaypipes | efried: yes, the parent. | |
| 15:17:57 | efried | but if we use the name, then we'll have N-1 UUIDs in the name for a provider at the Nth level down, which is :( | |
| 15:18:21 | jaypipes | efried: so for a SRIOV NIC under the first NUMA node on a compute node might be cn1_numa0_sriovpf0 or something like that? | |
| 15:18:55 | jaypipes | efried: I don't understand your last comment. could you elaborate? | |
| 15:19:08 | efried | Sorry, I wasn't being as clever as you. | |
| 15:19:32 | efried | I was thinking dumbly $PARENT_NAME - $MY_NAME | |
| 15:19:52 | efried | Which means your example would have ended up being cn1_cn1_numa0_sriovpf0 | |
| 15:20:23 | efried | um | |
| 15:20:25 | jaypipes | ah. no, just use the parent name, not the concat of the ancestry tree | |
| 15:20:26 | efried | that's not even right. | |
| 15:20:29 | efried | yeah | |
| 15:20:56 | jaypipes | so, the "formula" would be just: {$PARENT_NAME}_{$CHILD_NAME} | |
| 15:21:08 | efried | well, since names have to be unique, that should work just fine. | |
| 15:21:09 | jaypipes | or whatever separator you wanted to use instead of _ | |
| 15:21:37 | efried | So we have to establish the naming convention for $CHILD_NAME, which will be different for any given type of provider x hypervisor/virt | |
| 15:21:44 | efried | and document it | |
| 15:21:55 | efried | and then operators ought to be able to figure it out from there | |
| 15:21:56 | efried | if they need to | |
| 15:21:59 | jaypipes | efried: do we really though? | |
| 15:22:13 | efried | well, if we don't, then they have to do the two-step | |
| 15:22:28 | efried | ask placement, figure it out, use that to populate the file, which then gets used to update placement. | |
| 15:22:33 | openstackgerrit | Aditya Vaja proposed openstack/nova stable/queens: fix typo in IVS related privsep method https://review.openstack.org/604817 | |
| 15:22:34 | jaypipes | efried: I mean if the "use case" is just for deployment tooling to be able to list the inventory for a compute node and its children, we already have the one heuristic that would be needed. | |
| 15:22:54 | jaypipes | efried: i.e. ansbile would always call `openstack provider inventory list $HYPERVISOR_HOSTNAME` | |
| 15:23:11 | efried | isn't there a chicken/egg though? | |
| 15:23:15 | jaypipes | efried: and to find the child providers it would be: | |
| 15:23:26 | jaypipes | `openstack provider list --in-tree $HYPERVISOR_HOSTNAME` | |
| 15:24:03 | jaypipes | efried: well, of course, there's not going to be any inventory or provider records until the nova-compute runs, but I don't think that's any different from today's landscape for ansible/deploy tools | |
| 15:24:23 | efried | it is | |
| 15:24:39 | efried | because in today's tooling, you can set cpu_allocation_ratio beforehand | |
| 15:25:08 | jaypipes | and? | |
| 15:25:26 | efried | Well, I don't know if we really care enough to feel it's worth the hoops of fire it would take to make this new world similarly configurable-before-deployment. | |
| 15:25:36 | efried | But if I'm understanding cdent's concern correctly, that was it. | |
| 15:25:36 | jaypipes | what regarding the provider descriptor file format would prevent ansible from writing out an allocation ratio override for the compute node? | |
| 15:26:01 | efried | oh, that's exactly the point. The allocation ratio for CPU may not *live* in the compute node provider. | |
| 15:26:07 | efried | It may live in the (multiple) NUMA node providers | |
| 15:26:29 | efried | which ansible would need a way to figure out how to identify before deployment, if we're wanting to keep this paradigm of pre-deployment configurability. | |
| 15:26:57 | jaypipes | efried: right, but we don't currently set any allocation ratio for NUMA node providers anywhere (certainly not in any config file) | |
| 15:27:10 | efried | NUMA is just an example. | |
| 15:27:16 | efried | and | |
| 15:27:27 | efried | we don't today, but might tomorrow | |
| 15:27:29 | jaypipes | efried: this is why I think setting data for inventory records using configuration files is silly. | |
| 15:27:48 | efried | you think it should be done by invoking placement after all the auto setup is done? | |
| 15:28:01 | jaypipes | as opposed to setting them en-masse after the records have been created. | |
| 15:28:07 | jaypipes | yes. | |
| 15:28:23 | jaypipes | but we have deployers who are insisting on the configuration files... soo.... | |
| 15:28:27 | efried | I'd be cool with that. Requires a fundamental shift in the philosophy | |
| 15:34:03 | efried | basically each virt's update_provider_tree would have to agree to only muck with total and reserved. | |
| 15:34:21 | efried | which is not what we're doing today - today we overwrite everything. | |
| 15:34:34 | efried | but there's still the concern about how to set initial values. | |
| 15:34:54 | efried | The difficult part of that being how to tell that it's initial. | |
| 15:35:13 | efried | cdent suggested something about making use of the updated_at field. | |
| 15:36:23 | efried | bbar (that's "be back after reboot" - something's slowly eating up all my swap space) | |
| 15:40:31 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add native implementation OVSDB API https://review.openstack.org/482226 | |
| 15:42:29 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add native implementation OVSDB API https://review.openstack.org/482226 | |
| 15:43:22 | efried | belmoreira: did you get past your max_unit snafu from last week? | |
| 15:44:27 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add native implementation OVSDB API https://review.openstack.org/482226 | |
| 15:46:36 | belmoreira | efried: we decided to not change it for now | |
| 15:47:10 | efried | belmoreira: Meaning you still can't deploy those flavors to those nodes? | |
| 15:48:42 | belmoreira | efried: correct. People with these flavors can't use them. We're informing the users for now and suggesting smaller flavors | |
| 15:48:50 | efried | okey | |
| 15:49:35 | efried | belmoreira: Have you crystallized any sense of how you'd ideally like to see this handled big-picture/long-term? | |
| 15:49:45 | belmoreira | efried: our main issue is that our compute nodes may be very overcommited (CPU) and for now is saffer to stop scheduling these large flavors | |
| 15:50:04 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add native implementation OVSDB API https://review.openstack.org/482226 | |
| 15:52:40 | belmoreira | efried: last week I was debugging and we just realised the issue in the channel... I believe that letting the operator decide is a good practice. In my specific use case this is not a priority. If we allow these flavors again this is small downstream patch | |
| 15:53:02 | efried | roger that. Thanks for the update. | |
| 15:53:20 | mriedem | dansmith: so circling back on https://review.openstack.org/#/c/604687/3/nova/db/sqlalchemy/migrate_repo/versions/391_add_volume_type_to_bdm.py - you're cool with the compute API taking volume type name or ID yes? | |
| 15:54:24 | dansmith | mriedem: yes, but I'm not sure what that has to do with that migration.. it already has char(255) right? | |
| 15:54:34 | mriedem | yes | |
| 15:54:40 | mriedem | that's just what initiated the question | |