Jump to: navigation, search

Difference between revisions of "XenServerFileInjection"

m (Text replace - "__NOTOC__" to "")
m (Text replace - "NovaSpec" to "NovaSpec")
Line 1: Line 1:
  
* '''Launchpad Entry''': [[NovaSpec]]:xs-fileinject
+
* '''Launchpad Entry''': NovaSpec:xs-fileinject
 
* '''Created''':
 
* '''Created''':
 
* '''Contributors''': Ed Leafe, Chris Behrens
 
* '''Contributors''': Ed Leafe, Chris Behrens

Revision as of 23:31, 17 February 2013

  • Launchpad Entry: NovaSpec:xs-fileinject
  • Created:
  • Contributors: Ed Leafe, Chris Behrens

Summary

The current Rackspace Cloud Servers system communicates with instances by writing files to the guest. We refer to this as "injecting" the file into the guest. The files are used for configuration and other system-level control.

Release Note

Guest file injection (writing configuration from nova onto guest instances) is now supported. This is used to manage configuration files and other system-level settings. It is carried out in concert with a guest agent program; the owner of the instance has the option of disabling any or all of the agent's functionality.

Rationale

Feature parity with the current Rackspace Cloud Servers system. It is a required ability in order to provide managed cloud servers.

User stories

As a service provider, I want the ability to write to the guest instances so that I can properly manage them.

As a customer with a guest instance, I want my service provider to be able to help me with configuration changes.

Assumptions

  1. XenServer is the hypervisor
  2. guest agent is available on the guest instance

Design

The current Rackspace Cloud Servers implementation will be the model, as it is working well. We will continue to use xenstore as the communication link between the compute module and the guest agent, and values will continue to be encoded using base-64.

One change that has been requested from the current design is to keep the file path and file contents as separate values. Currently, they are concatenated with a comma separator and then the concatenated string is encoded; the new design will encode each separately and pass them as separate values. This will greatly simplify the work that the agent needs to interpret the encoded values written to xenstore.

Implementation

We already have the ability for nova to read/write to the xenstore for a specific instance. This blueprint will require adding the ability to pass in a file and a path, and write that to xenstore in a way that the guest agent can read.

Because the files and even the paths may contain non-ASCII characters, we have to ensure that these are passed through the nova stack unchanged. The current implementation uses base64 encoding to accomplish this, so we will have to ensure that at every step of the nova stack, these values are properly encoded before they are passed along to the next recipient.

UI Changes

None.

Code Changes

The major change will be in plugins/xenserver/xenapi/etc/xapi.d/plugins/agent script, which will handle the reception of the request, the writing of the request to xenstore, and returning the agent's response.

There will also be changes to the stack, including the api layer and compute layer to handle requests for file injection, and properly pass them on to the specific handler for these requests, which is nova/virt/xenapi/vmops.py

Migration

None required

Test/Demo Plan

This need not be added or completed until the specification is nearing beta.

Unresolved issues

None

BoF agenda and discussion

Nothing yet