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 <gera...@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.b...@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:cecca...@fnal.gov] >> > Sent: 14 September 2013 20:40 >> > To: Tim Bell >> > Cc: openstack@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:cecca...@fnal.gov] >> > > > Sent: 14 September 2013 00:11 >> > > > To: openstack@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@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@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@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
