Open Stack

Hi Gerard,

I am being told that there is now an iterator in OpenStack when you launch
multiple machines with --num-instances but have not verified this myself as
of yet. I will inquire and test further. I fully agree with your comments
do not think you are doing 'it' wrong at all, just a point below:

The hostname of the machine ideally should be related to the resolved
public/floating ipv4 as you point out, but the unique hostname is also
essential to a machine that might not be exposed externally on that
specific network while still being part of intra-instances communications
on the internal/private 10.X.X.X like network (think multi-tiered
applications for example where a database machine is a datastore for
another and does not need to be exposed publicly. Best practices in IaaS
and OpenStack are to use the internal/private network for this). Maybe this
could maybe be done with multiple 'views' in DNS, and match/map all of them
(public/floating ip space, internal/private ip space and hostnames)?


Cheers

Boris


On Mon, Sep 16, 2013 at 9:18 PM, Gerard Bernabeu <gerard1 at fnal.gov> wrote:

>  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.compute-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.
>
>  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> 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]
>>  > Sent: 14 September 2013 20:40
>> > To: Tim Bell
>> > Cc: 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]
>> > > > Sent: 14 September 2013 00:11
>> > > > To: 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
>> > > > 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
>> 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/20130923/dedf546e/attachment.html>