Skip to content
This repository has been archived by the owner on Sep 26, 2021. It is now read-only.

[Azure driver] Allow custom DNS (cloud service) names #433

Closed
ahmetb opened this issue Jan 29, 2015 · 6 comments · Fixed by #440
Closed

[Azure driver] Allow custom DNS (cloud service) names #433

ahmetb opened this issue Jan 29, 2015 · 6 comments · Fixed by #440
Assignees
Milestone

Comments

@ahmetb
Copy link
Contributor

ahmetb commented Jan 29, 2015

Recently the --azure-name parameter got removed (#219) from machine code and azure driver code now creates the Azure Cloud Service (DNS to the VM) in machinename-YYYYMMDDHHmmss.cloudapp.net format:

Each driver will attempt to set the hostname for the VM, except for Azure, which sets it based on the DNS name.

This is done at: ehazlett@861b16d#diff-93a074128ed8940ea0dafbd000270978R170

I think this should not be done and user should be allowed to specify the DNS names (as it used to be). In my case, I want to spin up 10 different VMs like mydocker-1, mydocker-2... on Azure and I will be able to easily address them like ssh -p 22 mydocker-1.cloudapp.net. However this change gives me VM names like mydocker-1-20150127152433, mydocker-2-20150127152750 which are not easily readable and manageable.

Another case is, if I want to deploy a VM like ahmetsblog.cloudapp.net, there is no way to do this with docker-machine. I think just limits the flexibility of the user.

I see that the date suffix is added to prevent the chances that the DNS name is already registered. I think the solution here should be giving the --azure-name parameter back to the user so that users can have a better control on what's going on. If the DNS name is already taken, user can simply be alerted "Cloud service name is already taken". (I think it used to be like that before #219) If it's really tedious and redundant, code can allow that parameter to be optional and can still use fmt.Sprintf("%s-%s", driver.MachineName, date).

Also, this decision forces MachineName to comply with Azure Cloud Service Name rules (e.g. 3-25 chars and can contain only chars allowed in DNS). The date suffix already takes up 14 chars, so user has to limit their MachineName to 11 chars max. That sounds wrong.

I'm not sure how the decision is made here but here's my 2c.

cc: @jeffmendoza @ehazlett @sthulb @chanezon
followup to #419.

@ehazlett
Copy link
Contributor

Thanks for raising this. Afaik there has never been an alert but I think that's the way to go. (the names used to be dynamically generated with only the cloud service and DNS being named -- the "name" parameter had no effect on the machine name). We recently added this functionality to the EC2 driver to check for the same key pair name. I think we can do the same and query for an existing cloud service and/or DNS lookup (maybe?) to see if the name is taken.

@ahmetb
Copy link
Contributor Author

ahmetb commented Jan 29, 2015

Yes, you can query that if a cloud service name exists, has a bad format or contains reserved/profane words. https://msdn.microsoft.com/en-us/library/azure/jj154116.aspx

I'm not sure how it works with ec2 (or other drivers) in terms of if the machine name also serves as DNS name but in Azure, I can foresee that this would be a big limitation and people would come and ask for this as soon as it's released.

@ehazlett
Copy link
Contributor

None of the other providers mess with DNS (with the exception of EC2 in which you get the instance IP instead). Thanks for the link -- I think we can use that in the PreCreate check to make sure there are no collisions.

Thanks!

@ahmetb
Copy link
Contributor Author

ahmetb commented Jan 29, 2015

It will be pretty much the same (checking DNS availability vs getting error when you attempt to create the Cloud Service). Both will return the same error and user of docker-machine will see an human-readable error.

It's done here: https://github.com/MSOpenTech/azure-sdk-for-go/blob/005406ef924d801298dbf035c87272f3b4bd44b5/clients/vmClient/vmClient.go#L67 and this gets called here: https://github.com/ehazlett/machine/blob/861b16dba9020ae6cb3c62e699683db9554300cc/drivers/azure/azure.go#L174 so you don't need to implement anything (unless you want to provide a friendlier error message).

Older versions of machine was already failing like this when user attempts to use to a taken DNS name:

INFO[0000] Creating Azure host...
ERRO[0009] Error creating host: A hosted service with the specified name already exists. Hosted service name: hellodocker
WARN[0009] Removing created machine. You can run machine with the --debug flag to avoid this.
WARN[0014] You will want to check the provider to make sure the machine and associated resources were properly removed.
FATA[0014] Error creating machine

so what you need to do is probably just bringing --azure-name back and removing the date suffix logic (or making the arg optional and keep the date suffix when the arg is not passed).

@ehazlett ehazlett added this to the 0.1.0 milestone Jan 29, 2015
@sthulb
Copy link
Contributor

sthulb commented Jan 29, 2015

We should definitely allow for nice hostnames. And obviously @ahmetalpbalkan is right about the API.

I chose to append the date since it was easier at the time.

@ahmetb
Copy link
Contributor Author

ahmetb commented Sep 7, 2016

@JohannesHoppe this issue you commented is about the very old azure driver, so your comment is not relevant here.

# for free to subscribe to this conversation on GitHub. Already have an account? #.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants