Creating a server with a name that already exists

[Attila Fazekas]

The 'Creating a server with a name that already exists is allowed' test case stopped working.

The source of the test case is here:
https://github.com/openstack/tempest/blob/ee3cc8dbe755d2abf15ad8cf46d3e2d57f85d355/tempest/tests/compute/servers/test_servers.py#L48

I did not found any documentation about the expected behaviour, but it changed.
I did not found any info how the "name" parameter in the post request will be used for DNS entry creation, or any info about the name must be unique.

In the
http://logs.openstack.org/17781/1/check/gate-tempest-devstack-vm/21574/logs/screen-n-cpu.txt
"FloatingIpDNSExists_Remote: The DNS entry server670491 already exists in domain " is related event.
The 2. server was created, but went into the error status around the DNS setting.

It occurred in the https://review.openstack.org/#/c/17781/ and in several other occasion.
The issue seams reproducible.

If the unique name is required constrain, the request should fail on create,
otherwise it should be able to boot (ACTIVE status) the second instance.

[Davanum Srinivas (DIMS) (dims-v)]

* both minidns and ldapdns do not allow duplicate hostnames.
* this problem cropped up since we enabled minidns for the builds, earlier dnsdriver was being used which did not any validation

Do we fix the test case? or is this a "feature" people depend on? Anyone know?

[Dan Prince (dan-prince)]

Attila:

Hi. I just hit the same w/ SmokeStack.... The root cause of the issue is this Nova commit:

  https://github.com/openstack/nova/commit/522ac62ad5cdc2164e6b9a72c86a889f94a7f23a

The solution I think is to switch Nova back to use a No-op DNS driver by default. To clear up any confusion I'm going to suggest we create a new (clearly marked) NoopDNSDriver so that it is hopefully clear the Nova default for this feature is to just pass.

See this review:

  https://review.openstack.org/#/c/17799/

[Attila Fazekas (afazekas)]

The test case can be changed to any well documented behavior.

I even did not find documented evidence the "name" parameter has any relation to the "hostname". But I found a disabled test case which would test it on ssh. (I assume the disable is related to the xml to json auto-convert issues )

The test case originally added with many others, I did not find any specific reason.

Any change which makes invalid the already duplicated name in the database, have effect to the end users.
Migration tools must exists for this case.

auto_assign_floating_ip AFAIK is disabled, but I see "FloatingIpDNSExists_Remote" exception.

I wonder how a fixed network got a domain. I do not remember it wan an option when I created a network.

As we discussed some name could be associated for multiple IP, but AFAIK even in this case the hosts usually have an additional unique name.

I think the name uniqueness should be configuration independent. But until I do not see a clear specification about the normal behavior, I think it is safer to go back to the original.

Just the hostname alone SHOULD not be unique.
Fixed networks MAY have domain part for constructing the FQDN.

The RR kind DNS entires SHOULD not be implicit when two server has the same "name".

[Attila Fazekas (afazekas)]

I have some notes for future consideration about auto creating internal domain names.

Probably all user expects, they can choose user friendly "name"s regardless "name"s used by any other tenant in all configuration.

Some application may expect the FQDN has at least 3 part.
 <hostname>.<domain>.<TLD>.

Someone might want to use a single wildcard certificate even for the "internal" domain names.

AFAIK in several configuration, a tenant can have multiple network, and someone might wants the FQDN contains the network/subnet names too.

Some user might want even more customization...

Option:
Use the VMs UUID in the auto-generated FQDN and let the users to pick another names...
Auto-generated FQDN should be based on the network/subnet topology.
If the VM has multiple interface, it might need at least one entry for all interface.