Change host link to include 'ucl' prefix

[ageorgou]

Fixes #47.

[jonc125]

This certainly works, but it's a little fragile as you need to put the same prefix here and in deployer.py. It'd be nicer if this was defined in just one place. Perhaps a better design would be to move the naming adjustments out of the deployer class into their own module?

[jonc125]

What do you think @raquel-ucl ?

[raquelalegre]

Yes, I agree. It would be better that the deployer just takes a DNS prefix given from elsewhere. Also perhaps instead of ucl+user_given_prefix we could put something random so we don't end up with several ucldemo urls :) I was using haikunator for the tests, but perhaps it'd be better to have something numeric instead, so we do user given url + random numbers.

[jonc125]

Well, the DNS names the users choose will still have to be unique across UCL, because they'll be accessible via name.cloudlabs.rc.ucl.ac.uk eventually...

But random numbers for the domain within Azure would at least reduce further the chance of unexpected conflicts with non-UCL names.

[raquelalegre]

So there's three things to do:

• [ ] Elaborate DNS prefix from user input outside the deployer so it's done only in one place.
• [ ] Check given URL is unique across Azure cloudapp domain if possible, or at least add some randomicity to the URL.
• [ ] Check given URL is unique across UCL domain.

[ageorgou]

Checking that the URL is unique within UCL is already done when adding a new host, I believe? (I remember getting messages that another VM existed with the same name in the database when playing around)

Edit: In cloudlabs.forms.add_host.py

[raquelalegre]

It is checked in the DB, but there might be (a bit unlikely maybe, specially if we go with the <name>.cloudlabs.rc.ucl.ac.uk) other URLs related outside of cloudlabs that happen to have the same url. But still worth checking in case of inconsistencies between the DB and the real world.

[raquelalegre]

Also it's very late! Let's stop talking about this :)

[ageorgou]

Yes, resuming another day :)

[ageorgou]

Noting this here as it is related: This also potentially affects how services are run from within docker containers on the deployed VM. This is because the setup script running the docker container sets the environment variable AZURE_URL from the raw dns_name field on the form, without any substitution or prefix. This means that any commands in the Dockerfile that refer to $AZURE_URL will have a wrong value, possibly breaking them. For example, this is why bokeh was not playing nice on the levine branch of docker-sample.

[jonc125]

Ouch! Right, probably we need to update it within the DB then, or at least have a property on the Host model that supplies the correct value for everywhere that needs it :)

[ageorgou]

The setup script is built as the new entry is added to the DB (in Host.__init__), using the arguments from the form, so I think changing the DB entry or the model would be too late? We could preprocess the form fields so that the dns_name field has the right format. Maybe (as suggested) move all the name generation to a different module and use that at all stages (DB population, deployment, wherever else).