cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chiradeep Vittal <Chiradeep.Vit...@citrix.com>
Subject Re: [DISCUSS][PROPOSAL] Support for standard metadata/userdata URL
Date Thu, 06 Aug 2015 18:42:19 GMT
The Apache web server listens only on the eth0 IP.
I added the 169.* address to eth0 and changed the Apache config to listen on that IP as well.
While the Apache Webserver now receives the request, it returns a 404. Fiddling with the .htaccess
file could fix that, but now that’s a bigger change than the one-liner I proposed.


From: Erik Weber <terbolous@gmail.com<mailto:terbolous@gmail.com>>
Reply-To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>>
Date: Thursday, August 6, 2015 at 9:31 AM
To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>>
Subject: Re: [DISCUSS][PROPOSAL] Support for standard metadata/userdata URL

Would it not work to assign the address 169.254.169.254 on the VR?

Erik

Den torsdag 6. august 2015 skrev Chiradeep Vittal <
Chiradeep.Vittal@citrix.com<mailto:Chiradeep.Vittal@citrix.com>> følgende:

Today the metadata / userdata server is retrieved by the guest from
http://<address of DHCP server>/latest/meta-data and
http://<address<http://<address> of DHCP server>/latest/user-data

This of course has been inspired by the EC2 standard[1]
http://169.254.169.254/latest/

While this works and has been incorporated into cloud-init [2], there are
other platforms that do not use cloud-init and consume the
userdata/metadata directly. For example, CloudFoundry [3] does not use
cloud-init, rather it tries to have adapters for different cloud types.
Adding support for CloudStack in this case can take a long time.
Another problem is that cloud-init tries the ec2 way first, times out and
then tries the CloudStack way.

I found a easy way to get the EC2-style metadata addressing working in
Advanced Zone / Isolated / VPC

By adding the following iptables rule in the VR, the guest VM can safely
address the 169.254.169.254 URL
iptables -t nat -A PREROUTING  -i eth0 -p tcp -m tcp --dport 80 -d
169.254.169.254/32 -j DNAT --to-destination <eth0 ip:80>


The current addressing scheme continues to work while supporting the EC2
scheme.
Since the VR is not on the default router in Basic Zone and other cases,
this is not universally applicable.
For KVM & XenServer in Basic Zone we could program the iptables rules in
dom0 (host) to NAT 169.254.169.254 queries to the DHCP server.

For XenServer in Advanced Zone where OVS is the default, there is no
stateful NAT possible.
For other hypervisors  (Hyper-V, VMWare) and Baremetal, there is no
comparable solution for Basic Zone and advanced networks where the VR is
not the default router.


However, note that this is not a breaking change, rather, an enhancement.

Thoughts?
—
Chiradeep
[1]
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html
[2] https://cloudinit.readthedocs.org/en/latest/
[3]
https://github.com/cloudfoundry/bosh-agent/blob/master/settings/settings.go




Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message