Open Stack

Aleksandra Fedorova <afedorova at mirantis.com> writes:

> Hi, everyone,
>
> <tl;dr>
>
> in Fuel project we run two HA deployment tests for every commit in
> openstack/fuel-library repository. Currently these tests are run by
> Fuel CI - the standalone Third-Party CI system, which can vote on
> openstack/fuel* projects. But we'd like it to be the part of the gate.
> As these tests require several vms to be available for the test run,
> we'd like to use nodepool multinode support for that.
>
> </tl;dr>

<tl;dr>

Cool!  In the long run I think this is technically possible and I think
we are at a stage where you can start to make forward progress, but the
current state is not plug-and-play because a lot of the work so far has
been focused on devstack.  It will be great to have more people looking
at this and helping us make it generic.

</tl;dr>

> How this can be addressed in nodepool
> =====================================
>
> The nodepool driver approach
> ----------------------------
>
> fuel-devops is essentially a wrapper and vm's manager, and it was
> originally planned as a tool which can use multiple backends, taking
> libvirt as a default one. There is an still-on-discussion task to
> implement the 'bare-metal driver' for fuel-devops, which would make it
> possible to use vm's from different servers for one particular test
> run.
>
> We can consider implementing nodepool as a driver, so it provides
> vm's, which then are wrapped by fuel-devops and are sent further to
> fuel-qa framework.
>
> Then to run the test we would need a 'manager vm' where fuel-devops
> code is executed, and several empty nodes from nodepool. We'd register
> those empty nodes in fuel-devops database and run the test as usual.

We want our nodes to be supplied by Nodepool and our jobs to be
controlled by Zuul -- we don't want to have a node provisioning system
specific to a single kind of job.  In Zuulv3 [1] we are proposing to make
this more flexible, but still want to keep with that approach.  Your
next suggestion looks more compatible.

[1] http://specs.openstack.org/openstack-infra/infra-specs/specs/zuulv3.html

> No fuel-devops approach
> -----------------------
>
> Direct approach would be to use the nodepool's service for pre-built images.
>
> Given by Fuel ISO image, we regularly generate one vm with deployed
> Fuel node (step 1.), and one with the basic node deployed with
> bootstrap image (step 2.). This images are stored in Glance or another
> storage as usual.
>
> Then for each fuel-library test we request 1 Fuel node and several
> basic nodes, and then operate on them directly without wrappers.
>
> For this scenario to work we need to change a lot in fuel-qa code. But
> this approach seems to be aligned with the initiative [8], which is
> currently in development: if we manage to describe devops environments
> in YAML files, we'd probably be able to map these descriptions to the
> multinode configurations, and then support them in nodepool.

If you need this to boot in a top-level VM (rather than a VM inside of a
VM, which is what happens for trove jobs and others like it), then yes,
this might work as a custom image type for nodepool.

We are trying to reduce the number of custom images we have in nodepool,
but perhaps this is a compelling reason to add one.

Note that right now nodepool multi-node support only lets us get groups
of nodes from identical images.  I think that can change with the Zuulv3
work, so it's good to have potential requirements like this as we get
started on that.

On another subject, you might also want to look at the devstack
multinode documentation[2].

It's obviously very devstack specific, but we might want to pull that
out of devstack and put it in nodepool ready scripts or something similar.

[2] http://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/multinode_setup_info.txt

> Side Question
> =============
>
> Can we build package from a change request so that package is then
> used in test? Are there any best practices?

You can start a job by building a package and then provide it by
building a local package archive.

-Jim