Hi, See my reply inline.
On Wed, Dec 11, 2013 at 02:44:26PM -0800, James E. Blair wrote: > Mate Lakat <[email protected]> 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 _______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
