@Mark, We believe the decision to limit cloud-init's "poll"ing of network based metadata services is the right decision. That means that cloud-init will only reach out to a metadata service if: a.) it has positive identification that the metadata service will exist. b.) it has been specifically told (configured) to do so.
I gave an example of how to do 'b' in my comment above. The suggestion of adding 'VMWare Virtual Platform' to the list of VALID_DMI_PRODUCT_NAMES is unfortunately not a complete solution. Running on VMWare does not indicate that an OpenStack metadata service will be present. The system could be running in another cloud platform (CloudStack or OpenNebula or even AWS at this point). At best that provides a "maybe". In those other scenarios, attempting to reach http://169.254.169.254/openstack may have negative side effects. We need a way that we can positively identify that we are running in OpenStack. That is why I opened the bug you referenced. This is really just good policy. Platforms *should* identify themselves to software that is running on them. Thoughts? Scott -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1788487 Title: OpenStack detection broken on VMware To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1788487/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
