Get Cloud-Init and XenAPI guest agent working together

Registered by John Garbutt on 2013-05-02

For a XenAPI cloud to feel more like libvirt cloud, cloud-init needs to work well.

Ideally XenAPI clouds can work well without the agent and use config drive.

Currently, operations such as setting the root-password depend on the XenAPI agent. For these cases, it would be good to use both the agent and cloud-init.

There are many existing VMs using the agent, and the agent works on more OSes than cloud-init, so the code to use the agent is likely to stay around for some time.

Clearly this depends on projects outside of nova, but the code in the XenAPI driver (for all agent based actions) ideally needs to also work with cloud-init.

Blueprint information

Status:
Complete
Approver:
Russell Bryant
Priority:
Medium
Drafter:
John Garbutt
Direction:
Approved
Assignee:
John Garbutt
Definition:
Approved
Series goal:
Accepted for havana
Implementation:
Implemented
Milestone target:
milestone icon 2013.2
Started by
John Garbutt on 2013-05-03
Completed by
Russell Bryant on 2013-08-30

Related branches

Sprints

Whiteboard

May defer some of the work remaining till the I timeframe. May of the key parts are already complete. (johnthetubaguy)

Moving to H-3 (johnthetubaguy)

This blueprint is likely to be spread across several patches, see the work items for hints.

Gerrit topic: https://review.openstack.org/#q,topic:bp/xenapi-guest-agent-cloud-init-interop,n,z

Addressed by: https://review.openstack.org/28676
    xenapi: make the xenapi agent optional per image

Gerrit topic: https://review.openstack.org/#q,topic:bug/1178223,n,z

Addressed by: https://review.openstack.org/39495
    xenapi: agent not inject ssh-key if cloud-init

(?)

Work Items

Work items:
Allow hints from glance to state the presence (or lack of) the agent (like auto_disk_config): DONE
Allow hints from glance to state if cloud-init is present, so certain agent functions should not be performed: INPROGRESS
Test inject network, files and ssh key without agent, with XenAPI driver + config drive: DONE
Ensure user data works with cloud-init while agent configures rest of the image: DONE
Refactor change password on spawn so it is less agent specific in XenAPI: POSTPONED
Using xenstore as an alternative to passing the password back via metadata service: POSTPONED

This blueprint contains Public information 
Everyone can see this information.