Open Stack

(I moved the description of Fuel CI to wiki page [0] for future references.)

Why i think option with predeployed Fuel node is better for us:

Currently Fuel Build team works on stripping off as much content as
possible from a Fuel node (and, thus, Fuel ISO). We already have a
possibility to use external deb and rpm repositories for Base OS and
OpenStack packages, and now moving out Fuel packages repository as
well. Thus Fuel image is going to be more and more stable. So
deploying Fuel node for every test would be unnecessary overhead.

Thus the test layout as i see it should be the following:

- one "manager vm" which will be responsible for the main test flow.
On this vm we will:
    - build fuel-library package,
    - generate a repository,
    - get fuel-qa code,
    - run the actual test using based on job parameters,
    - collect test result and artifacts.
- one vm with installed Fuel,
- several bootstrapped nodes according to the test configuration -
here probably we can switch from using nodes which are bootstrapped
with Fuel to nodes which are just the most generic ones.

As i got it from reading grenade job log [1], having manager vm is
actually expected: there is a "main" node and list of subnodes which
you can talk to from there. So this setup is not impossible, but
requires support for requesting different types of nodes from
nodepool. And we probably need to patch the Zuul_v3 spec in [2] to add
this case to the format of request-accept calls?

The other question here would be the network configuration: to
function properly Fuel needs 5 (or 6?) different networks and we will
need a way to configure them before we run the actual deployment. What
are the options for configuring network on top of nodes provided by
nodepool?


[0] https://wiki.openstack.org/wiki/Fuel/CI
[1] https://jenkins02.openstack.org/job/gate-grenade-dsvm-multinode/
[2] http://specs.openstack.org/openstack-infra/infra-specs/specs/zuulv3.html


-- 
Aleksandra Fedorova
Fuel CI Team Lead
bookwar