Re: [Cloud-init-dev] [Merge] lp:~utlemming/cloud-init/lp1375252 into lp:cloud-init

2015-02-24 Thread Scott Moser
if the user changes /etc/hostname, then their instance will do a dhcp request with the hostname they set. this seems desirable. I'm really confused. -- https://code.launchpad.net/~utlemming/cloud-init/lp1375252/+merge/247494 Your team cloud init development team is requested to review the pro

Re: [Cloud-init-dev] [Merge] lp:~utlemming/cloud-init/lp1375252 into lp:cloud-init

2015-02-24 Thread Ben Howard
That is true on first-boot, but what if the user changes /etc/hostname? If we change to doing this on first-boot only, then it results in a situation where a user who changes their hostname is busted. The purpose of the proposed patch is to enable users to divorce the hostname from the fabric na

Re: [Cloud-init-dev] [Merge] lp:~utlemming/cloud-init/lp1375252 into lp:cloud-init

2015-02-24 Thread Scott Moser
on shutdown/startup, the configured network interface is still brought up (by ubuntu). its just not cycled by cloud-init. that bringup will use the configured hostname as seen in /etc/hostname, which should have been updated. -- https://code.launchpad.net/~utlemming/cloud-init/lp1375252/+mer

Re: [Cloud-init-dev] [Merge] lp:~utlemming/cloud-init/lp1375252 into lp:cloud-init

2015-02-24 Thread Ben Howard
Performing the hostname_bounce on first-boot only would actually break the instance in two cases instance on shutdown/startup as the VIP is released on instance shutdown. When the user restarts the instance, it would be given a new VIP, but keep the instance ID. In this case, scoping the hostnam