Multiple users with same environment names causing clash

[Haw Loeung]

Hi,

Juju currently uses the environment name to generate an instance name. That then is used to update forward DNS. We ran into an issue where someone else was using the same environment name and as a result, the forward DNS entry resolved to multiple IP addresses:

ubuntu@juju-canonistack-instance-1:~$ dig +short juju-canonistack-instance-1.lcy02.canonistack
10.55.63.65
ubuntu@juju-canonistack-instance-1:~$ dig +short juju-canonistack-instance-1.lcy02.canonistack
10.55.63.83

[Kapil Thangavelu (hazmat)]

juju normally does use one provider resources based on env name, the
security group naming (which should be local to the tenant) which is one
per env, and one per machine typically.

looking through the source of the openstack provider, it also sets the
instance name (not id)

         name="juju %s instance %s" %
                (self._provider.environment_name, machine_id,),

effectively though this could be a random string, juju doesn't care about
it per se, its just a reference for the user when looking through other
provider tools. the reverse dns on instance name is bound to conflict
though with normal usage of a cloud provider, so this sounds like a bug in
the canoistack setup. If you'd like we can mitigate via some uuid/rand
string insertion here, but this should get fixed in canonistack as well, as
this name clash is not specific to anything juju is doing, its an inherent
issue.

-k

On Tue, Oct 2, 2012 at 10:59 AM, Haw Loeung <email address hidden>wrote:

> ** Tags added: canonical-webops-juju
>
> --
> You received this bug notification because you are subscribed to juju.
> https://bugs.launchpad.net/bugs/1060147
>
> Title:
> Multiple users with same environment names causing clash
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1060147/+subscriptions
>

[James Troup (elmo)]

Kapil Thangavelu <email address hidden> writes:

> effectively though this could be a random string, juju doesn't care
> about it per se, its just a reference for the user when looking
> through other provider tools. the reverse dns on instance name is
> bound to conflict though with normal usage of a cloud provider, so
> this sounds like a bug in the canoistack setup.

It's a bug in nova (LP #1054212).

> If you'd like we can mitigate via some uuid/rand string insertion
> here, but this should get fixed in canonistack as well, as this name
> clash is not specific to anything juju is doing, its an inherent
> issue.

Depending on how it gets fixed in nova, it may have to be fixed in juju,
e.g. if it's fixed in nova by causing the instance spawn to fail.

If it's fixed in nova by silently changing the instance name, juju's
idea of the instance name and nova's will be out of sync.

It's not a pressing issue, for sure, but (personally) I think it makes
sense to fix this in juju as well as nova.

--
James

[Clint Byrum (clint-fewbar)]

The reference bug was closed, and its not clear how or if this has been addressed in Nova. I do think its worth working around, but I'm not sure how. Leaving as New, but setting to High importance.

[Kapil Thangavelu (hazmat)]

for reference it appears the blueprint referenced is
https://blueprints.launchpad.net/nova/+spec/multi-boot-instance-naming

which appears to be unimplemented (ie bug is still valid). its odd though as i havent heard reports of it the issue from canonistack users in quite a while.

[Haw Loeung (hloeung)]

Andreas has just hit into this recently. https://pastebin.canonical.com/101919/