Going back to metadata.name will bring back the issues from #57765.

While we could reimplement the hostname sanitization from https://github.com/openstack/nova/blame/master/nova/utils.py#L543-L580 here, i suspect that we might run into problems when the sanitization implementation in nova changes.

Using metadata.uuid instead might result in weird node names, but we can at least be sure to get node names that work.

@gonzolino the problem with sanitation is that

• you cannot go back from sanitized name to the real name.
• you cannot search for sanitized hostname via API unless you have admin privileges

"bring back" is the wrong wording here because that issue unfortunately still exists ;)

Maybe we could go back to use metadata.name for 1.10 and use metadata.uuid for 1.11 onwards since that results in new node names which could be considered a braking change?

@dims I agree with that. Two more reasons why I favour using the UUID :)

@alvaroaleman Going back to use the name instead of the hostname in 1.10 would also result in new node names. To be honest, I am unsure if that is a breaking change...

Well, I'm perfectly fine with UUID as well, I just dislike the current state of having to use an undocumented config option that is probably going to vanish soon if you don't happen to use .novalocal as dhcp_domain.

@dims Are you opposed to changing this to the UUID within 1.10? If no I'll prepare a patch for that.

@alvaroaleman : yes, let's please not change 1.10.

@dims Can you elaborate on why you do not want to change 1.10? The current status of 1.10 is that you need an undocumented config option that will probably vanish in 1.11 to make it work if you don't happen to use `.novalocal.

Also, I would argue, even with #62228 in place there are still issues.

For example: The method GetNodeNameByID, which should return the NodeName of the instance with the given ID, will return the server name instead the hostname (if I see it correctly).

If we want to keep the 1.10 behaviour, we should try to to handle NodeNames consistently.

@alvaroaleman we will document it. the cherry pick went in yesterday i believe

@gonzolino which exact scenario is affected by GetNodeNameByID?

I could only find a single usage of that Function and it's inside the cloud-provider. It doesn't seem to be critical: https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/openstack/openstack_volumes.go#L338

The private function which is used to map the server to it's name inside GetNodeNameByID is also used at https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/openstack/openstack_routes.go#L67

I am unsure if any of this causes issues or if there are more functions that rely on the server name instead of the hostname, but I think we should verify that there are no more issues if we decide to stay with the hostname for 1.10.

So the input for GetNodeNameByID is the UUID (NOT the host name or instance name). So we are good

/sig openstack

Prior to 1.10, deployments could name their instances with node-name-compatible names and work properly. The changes made in 1.10 (#58502 and #61000) break those deployments.

Additionally, as noted in the referenced comment, they made the getServerByName and mapNodeNameToServerName methods fail unless the instance name and hostname were identical

It seems like the top priority should be to restore pre-1.10 behavior for deployments that were working properly, then revisit how to handle instance names that don't conform to valid node names.

Also, to be clear, new node names has a lot of potential to be a breaking change, depending on how it is done. Deployments provision instances, credentials, and need to coordinate on the resulting node objects. Options or fallback behavior when an instance name is impossible to use as a node name seem reasonable, but should be done in a way that doesn't break deployments that were previously working

Another consideration is that kubelets can skew two releases older than the API server, which needs to consider how older kubelets will register themselves. The 1.10 API server openstack cloud provider is currently only compatible with 1.10 kubelets, which is another breaking change that needs addressing.

It seems like the top priority should be to restore pre-1.10 behavior for deployments that were working properly, then revisit how to handle instance names that don't conform to valid node names.

In service of this, I've opened #63903 to restore pre-1.10 behavior and plan to pick it to the 1.10 release branch once approved.

fyi, I'm documenting the current state of cloud provider node name computation and requirements in kubernetes/website#8873

as this issue is resolved and a method for computing compatible Kubernetes Node names from arbitrary OpenStack instances is implemented, please update the OpenStack section of that document to describe the new method, any configuration requirements, etc.

Hi,

@gonzolino @liggitt
We got an issue may be caused by name and hostname exchange.

Reproduce steps:

1. create an instance in openstack dashboard, named "bbbb-node-4".
2. due to work requirements, we should edit this instance hostname to "vm-10-10-10-10".
3. edit this instance's name to "vm-10-10-10-10" in openstack dashboard.
4. try to start kubelet in vm-10-10-10-10, there will be a failed message.

Kubelet log:

Jun 22 07:25:48 vm-10-197-171-29 kubelet[2886]: I0622 07:25:48.053677    2886 openstack_instances.go:42] openstack.Instances() called
Jun 22 07:25:48 vm-10-197-171-29 kubelet[2886]: I0622 07:25:48.053685    2886 openstack_instances.go:49] Claiming to support Instances
Jun 22 07:25:48 vm-10-197-171-29 kubelet[2886]: I0622 07:25:48.053690    2886 server.go:731] cloud provider determined current node name to be  **bbbb-node-4**
Jun 22 07:25:48 vm-10-197-171-29 kubelet[2886]: I0622 07:25:48.053708    2886 server.go:887] Using root directory: /var/lib/kubelet
Jun 22 07:25:48 vm-10-197-171-29 kubelet[2886]: I0622 07:25:48.053731    2886 openstack_instances.go:42] openstack.Instances() called
Jun 22 07:25:48 vm-10-197-171-29 kubelet[2886]: I0622 07:25:48.053737    2886 openstack_instances.go:49] Claiming to support Instances
Jun 22 07:25:48 vm-10-197-171-29 kubelet[2886]: I0622 07:25:48.053760    2886 kubelet.go:386] cloud provider determined current node name to be  **bbbb-node-4**
Jun 22 07:25:48 vm-10-197-171-29 kubelet[2886]: I0622 07:25:48.053766    2886 openstack_instances.go:78] NodeAddresses(belk-node-4) called
Jun 22 07:25:48 vm-10-197-171-29 kubelet[2886]: F0622 07:25:48.182161    2886 server.go:233] failed to run Kubelet: failed to create kubelet: failed to get the addresses of the current instance from the cloud provider: failed to find object

nova return information

$ nova show f10668e6-a52b-xxxx-8d0a-b0b51c8aeb42
+--------------------------------------+--------------------------------------------------------------------------------------+
| Property                             | Value                                                                                |
+--------------------------------------+--------------------------------------------------------------------------------------+
| OS-DCF:diskConfig                    | AUTO                                                                                 |
| OS-EXT-AZ:availability_zone          | zone2                                                                                |
| OS-EXT-STS:power_state               | 1                                                                                    |
| OS-EXT-STS:task_state                | -                                                                                    |
| OS-EXT-STS:vm_state                  | active                                                                               |
| OS-SRV-USG:launched_at               | 2018-06-21T12:00:54.000000                                                           |
| OS-SRV-USG:terminated_at             | -                                                                                    |
| accessIPv4                           |                                                                                      |
| accessIPv6                           |                                                                                      |
| config_drive                         |                                                                                      |
| created                              | 2018-06-20T07:00:42Z                                                                 |
| flavor                               | m1.large (4)                                                                         |
| hostId                               | 0984875cb592bbb5xxxxxxxx367ecb7931ec7b3730c5be2257                             |
| id                                   | f10668e6-a52b-4e22-8d0a-b0b51c8aeb42                                                 |
| image                                | app-18.03-00_20180331_161334.x86_64.qcow2 (22bc5fa3-b7f0-xxxxxx-b3b4-6ed612cac971) |
| key_name                             | cloud1-user                                                                          |
| locked                               | False                                                                                |
| metadata                             | {}                                                                                   |
| name                                 | **vm-10-10-10-10**                                                                     |
| os-extended-volumes:volumes_attached | []                                                                                   |
| progress                             | 0                                                                                    |
| security_groups                      | bcmt-secgrp, default                                                                 |
| status                               | ACTIVE                                                                               |
| tenant_id                            | 6ccc190ad9fcxxxxxxxxxxxx1fef93cd                                                     |
| updated                              | 2018-06-21T12:01:28Z                                                                 |
| user_id                              | 8acbxxxxxxxxxxb74f289                                                     |
| v439-NODE018-CB-PROVIDER network     | 10.10.10.1                                                                        |
+--------------------------------------+--------------------------------------------------------------------------------------+

meta_data infomation

$ curl -s http://169.254.169.254/openstack/2012-08-10/meta_data.json
{
	"uuid": "f10668e6-a52b-4e22-8d0a-xxxxxxxxxxxxx",
	"availability_zone": "zone2",
	"keys": [{
		"data": "ssh-rsa xxxxxxxxxxxxxxxxxxxxxxxxx Generated-by-Nova\n",
		"type": "ssh",
		"name": "cloud1-user"
	}],
	"hostname": "**bbbb-node-4**",
	"launch_index": 3,
	"public_keys": {
		"cloud1-user": "ssh-rsa xxxxxxxxxxxxxxxxxxxxxxxx Generated-by-Nova\n"
	},
	"name": "**vm-10-10-10-10**"
}

similar issue https://bugzilla.redhat.com/show_bug.cgi?id=1566455

BTW, this is some change rules about name and hostname I summarized.
1, edit instance and change it's name in dashboard will only change "hostname" in meta_data info.
2, change hostname in VM will not change "hostname" in meta_data info.
3, the two operations above will not change "name" in meta_data.

So, if we change name in openstack dashboard, only hostname was changed in meta_data, and function GetNodeNameByID return the server name instead the hostname, and then call function getServerByName in pkg/cloudprovider/providers/openstack/openstack.go::418, it will be failed.
I think one more function should be add named GetNodeHostNameByID, return server's hostname, and enhance the functions who call GetNodeNameByID.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

I'm going to close this and invite you to open a new issue in the kubernetes/cloud-provider-openstack repository if it's still impacting you.

/close

@hogepodge: Closing this issue.