Open Stack

Hi,

we are using cloud-init to do the VM host contextualization (ie: set the 
right hostname). For this to work we need proper OpenStack metadata, for 
instance we'd like the public-hostname to default to the DNS resolved 
public-ipv4 (or ipv6, if present).

Right now the default behaviour is that public-hostname is the same as 
the hostname and the local-hostname, which is the user-defined instance 
name. I'm not sure if current behaviour is a bug or a feature, but I'd 
expect public-hostname to be related to public-ipv4.

Maybe we're missing something obvious or doing something wrong, are we? 
If not, is there any way we can setup OpenStack (NOVA?) to setup the 
public-hostname metadata to the resolved public-ipv4 name automatically 
for each VM?

Thanks,

Gerard Bernabeu
FermiCloud and FermiGrid Services at Fermilab
Phone (+1) 630-840-6509

On 09/15/2013 07:54 PM, laclasse wrote:
> Agreed, unique FQDNs on every instances is still a big issue for 
> common workloads, hopefully solved by DNS services coming to OpenStack 
> soon... I fully agree that the instance name and the FQDN of the 
> instances should be 2 separate things, and even better, I think 
> instances by default should try a reverse lookup first when they get 
> on the network, and if available, collect a hostname, set it locally 
> and display it in an additional column in the DB/tables/webUI, and 
> allows OpenStack services clients to use either instance ID, name or 
> hostname.
>
> What the OP is trying to do is also feasible by installing a bind 
> service somewhere on the same subnet (bind9 minimum) and using the 
> $GENERATE directive in your zone file, see here on how to write your 
> zone file using that directive: 
> http://www.oit.uci.edu/dcslib/bind/bind-9.2.1/Bv9ARM.ch06.html#AEN4097
>
> FWIW, AWS EC2 has a simple iterator that composes a unique hostname to 
> any instance by parsing the public IP address, replacing '.' (dots) 
> with '-' (to make it viable in a long hostname) and adding 
> prefix/suffix to compose the hostname (compute zones and domain) with 
> added dots for example: "ec2-54-211-89-105.co 
> <http://ec2-54-211-89-105.co>mpute-1.amazonaws.com 
> <http://mpute-1.amazonaws.com>" is an instance with IP 54.211.89.105 
> ... it a simple and useful solution. You can check it yourself:
>
> $ host 54.211.89.105
> 105.89.211.54.in-addr.arpa domain name pointer 
> ec2-54-211-89-105.compute-1.amazonaws.com 
> <http://ec2-54-211-89-105.compute-1.amazonaws.com>.
>
> Not having a unique FQDN on cloud instances can break many apps, and 
> DNS services in IaaS should not be taken for granted (failure may 
> happen), so IMHO, the best approach should be:
> - boot instance, get on the network, do a reverse look up on IP to see 
> if a DNS server answers with a FQDN , collect it and set it
> - if the look up fails, then resort to the iterator running and still 
> end up with an unique hostname per instance.
>
> It seems a lot of public services hide this issue by allowing to 
> launch only one instance at the time, but AFAIK, if you launch several 
> instances at once using the nova CLI, you will end up with ALL 
> instances having the same hostname (which is the instance name you 
> have given to nova CLI) ... which breaks so many things it is not 
> funny ... and is generally not a good idea or best practices either.
>
> If this functionality lands (very soon we hope), it will obviously 
> also allows users to deal with hostnames directly rather than IP 
> address, which in 2013, could give an archaic and 
> old fashioned unfinished impression to users.
>
> Cheers, sorry for the mini-rant but I would think this is one of the 
> most urgent issues to address to see real automation and large scale apps.
>
>
>
>
> On Sun, Sep 15, 2013 at 12:39 PM, Tim Bell <Tim.Bell at cern.ch 
> <mailto:Tim.Bell at cern.ch>> wrote:
>
>
>     I don’t think there is a formal exit inside OpenStack to do this.
>      You may have to make a small patch to Nova.
>
>     It would be an interesting feature to define a plug-in
>     architecture for this which would have several other uses.
>
>     Tim
>
>     > -----Original Message-----
>     > From: Francesco Ceccarelli [mailto:ceccarel at fnal.gov
>     <mailto:ceccarel at fnal.gov>]
>     > Sent: 14 September 2013 20:40
>     > To: Tim Bell
>     > Cc: openstack at lists.openstack.org
>     <mailto:openstack at lists.openstack.org>
>     > Subject: Re: [Openstack] openstack meta-data
>     >
>     > Hello,
>     > thanks for the help! I hadn't seen the command in the
>     documentation, this can be helpful.
>     > BTW my problem is to update metadata every time a machine is
>     launched.
>     > For example let's talk about the hostname. Every time I launch a
>     machine, I would like to have well-configured metadata, with the
>     > parameter public-hostname already set to a customized value. I
>     don't want the instance name as public-hostname.
>     >
>     > I hope I was clear and thanks again for the help, Francesco
>     >
>     >
>     >
>     > On Sat, 2013-09-14 at 07:18 +0000, Tim Bell wrote:
>     > > You can update the metadata associated with an instance using
>     the 'nova meta' command. However, this only updates the metadata
>     > (i.e.
>     > > key value pairs) rather than the other attributes.
>     > >
>     > > Changing the server name would not alter the hostname of the
>     VM, it would only alter the description in Nova.
>     > >
>     > > Can you explain a little more what you would like to be doing ?
>     > >
>     > > Tim
>     > >
>     > > > -----Original Message-----
>     > > > From: Francesco Ceccarelli [mailto:ceccarel at fnal.gov
>     <mailto:ceccarel at fnal.gov>]
>     > > > Sent: 14 September 2013 00:11
>     > > > To: openstack at lists.openstack.org
>     <mailto:openstack at lists.openstack.org>
>     > > > Subject: [Openstack] openstack meta-data
>     > > >
>     > > > Is it possible to update instance meta-data, for example to
>     set the public hostname?
>     > > >
>     > > > Thanks in advance,
>     > > > Francesco
>     > > >
>     > > >
>     > > > _______________________________________________
>     > > > Mailing list:
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>     > > > Post to     : openstack at lists.openstack.org
>     <mailto:openstack at lists.openstack.org>
>     > > > Unsubscribe :
>     > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>     >
>
>
>     _______________________________________________
>     Mailing list:
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>     Post to     : openstack at lists.openstack.org
>     <mailto:openstack at lists.openstack.org>
>     Unsubscribe :
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130916/d52cbe5f/attachment.html>