As the OpenStack feature set expands, the tasks of guest configuration become more granular and complex. For example, it is now possible for operators to configure guests with multiple ips and network interfaces, though at present there is not a standard way for to properly assign addresses to these interfaces. Much of this type of configuration could be accomplished via a guest configuration agent combined with some sort of metadata service. The goal of this document is to propose a reference guest configuration agent, and describe how this agent would interact with a metadata service.
Some responsibilities of a guest agent would include:
- Configuring advanced network settings
- Installing PV Drivers (xen tools, virtio, vmware tools)
- Changing passwords?
Jane wants to run an image in cloud A and cloud B. Unbeknownst to her, cloud A and B use different hypervisors. Fortunately, she has installed the OS Guest Agent on her instance. After her two instances boot, they are both networked properly, and are performing optimally using the correct PV drivers.
For essex, the proposal is to create an OS metadata service that would allow users to access some standard information over a network interface:
- Server details
- Network interface
- May need hints to help guest agent understand which PV driver to install
- BLOBs: Treat userdata and injected files (server personalities) the same.
deprecate server personalities in 2.0 - instead increase the size limit for metadata values kill server personalities in 3.0
- Docs/examples + horizon (dashboard project) should use metadata instead of personalities
For essex, the proposal is to extend the RAX guest agent to communicate with the metadata service and add features to enable 'Golden Image' portability, such as:
- Installation of PV drivers
- Advanced network configuration
- Run-time network changes
- Is it possible to bypass DHCP for initial network configuration? IPV6 + link-local + metadata service?
- Should password-change support be built-in?