Open Stack

Hi,

See my reply inline.

On Wed, Dec 11, 2013 at 02:44:26PM -0800, James E. Blair wrote:
> Mate Lakat <mate.lakat at citrix.com> writes:
> 
> > Hi,
> >
> > We are working to get test coverage for XenServer, and wanted to share
> > the ideas, to see if we are on the right path. The goal would be to use
> > the official CI to run tests on XenServer.
> >
> > 1 - Installation
> >
> > So the issue, is that there is no XenServer image available in the RS
> > cloud. In order to install an XS instance, we can take a standard image,
> > execute a script on it, and end up with a running XS. The only issue,
> > that during this install phase, several reboots are performed. To add
> > support for the install phase in nodepool, see this change:
> >
> >     https://review.openstack.org/61463
> 
> This seems reasonable.
> 
> > 2 - Prepare your system for imaging
> >
> > After nodepool finished with the installation, it should be able to
> > access a standard distribution on the public IP, so it will happily
> > execute the setup script. However, before creating a snapshot from the
> > instance, we would need to tell the hypervisor, that it'll be
> > snapshotted - so during the next boot, it will be able to pick up new IP
> > addresses, etc (sort of Windows' sysprep)
> >
> >     We haven't committed any patch for this yet
> 
> You could probably just do this in the bootstrap script, right?
We are doing some sort of preparation in the bootstrap scripts:
End of prepare_devstack.sh:
  sync
  sleep 5

I added this entry point, because we might want to do some more with
these hypervisots, which could again include reboots - disconnects. The
key thing for me is to leave the filesystem in a state, where the
snapshot will be consistent. The best way to do it (I might be wrong) is to
halt the hypervisor - this is the reason why I added this extra step.

> 
> > After these bits solved, several instances could be launched from the
> > snapshot, and we expect that with a proper localrc, they will be
> > well-behaving nodes.
> >
> > 3 - Wire up to the system
> >
> > Our understanding, is that we'll need to:
> >
> > Add the install, and prepare scripts to:
> >     config/modules/openstack_project/files/nodepool/scripts
> > Configure the images in:
> >     config/modules/openstack_project/templates/nodepool/nodepool.yaml.erb
> > Add localrc tweaks here:
> >     devstack-gate/devstack-vm-gate.sh
> > Add jobs here:
> >     config/modules/openstack_project/files/jenkins_job_builder/config/devstack-gate.yaml
> > And ask zuul to trigger them here:
> >     config/modules/openstack_project/files/zuul/layout.yaml
> >
> > The wip changes to these are proposed by John:
> >     https://review.openstack.org/#/c/60900/
> >     https://review.openstack.org/#/c/60902/
> >     https://review.openstack.org/#/c/60903/
> 
> Thanks for such a detailed plan.  It is clear and makes a lot of sense,
> and seems to be correct.
> 
> Two points in 60902 caught my attention:
> 
>   The server created is a XenServer with an Ubuntu VM to run the
>   openstack services. This nested Xen virt will only currently work in
>   the Rackspace cloud. Also, because nested virt will slow things down,
>   lets try running this on performance flavors to give us the best
>   chance of running things at a reasonable speed.
> 
> Is it possible for this to run on other cloud providers (eg, HP, and
> potentially others in the future)?  It's important that our gate jobs be
> able to run on multiple providers.
> 
> The image you select has "(PVHVM beta)" in the name.  Is that related?
> What does it mean?
> 
> Thanks,
> 
> Jim

Cheers,
Mate
-- 
Mate Lakat