[openstack-dev] [Fuel][Fuel-Library] Fuel CI issues

Thomas Goirand zigo at debian.org
Wed Mar 9 17:46:36 UTC 2016

On 02/29/2016 11:19 AM, Vladimir Kuklin wrote:
> Hi Ivan
> Thanks for bringing this up. Frankly, I think that we hurried a little
> bit by making our integration with upstream puppet manifests too
> continuous. I would suppose that we used a little bit different technique.
> First of all, we need to have a set of stable Fuel commits against which
> the changes to upstream manifests should be tested. Could you please
> elaborate on whether we are doing this already?
> Secondly, we need to have FUEL CI working with a set of stable commits
> of puppet openstack manifests which passed those upstream tests as we
> should not have too much moving parts or we will get into situation
> similar to requirements.txt updates when we have pypi updated with new
> library, e.g. oslo-serialization.
> In this case, we will be able to do proper testing against frozen
> code-base for each piece thus avoiding such issues while retaining fair
> amount of integration with upstream puppet manifests for OpenStack.
> So what do you think?

IMO, what needs to happen, is Fuel to use a packaged version of these
puppet scripts. This has numerous advantages:

- the openstack.yaml repository would also point to the corresponding
puppet stuff

- the version of puppet-openstack would automatically match the one of
the target installation, because it would be stored in the corresponding
packaging repository

- we wouldn't need to hack symlinks in /etc/puppet/modules

- there would be no need to use rsync from the master node to the slave
nodes, as the correct version of fuel-library would be installed in the
IBP image by fuel-agent, making it automatically available

What we shouldn't do though, is loose the continuous testing of upstream
puppet-openstack modules, so we make sure they never break Fuel,
otherwise we would discover issues too late.

FYI, I have just finished uploading all of puppet-openstack Mitaka b1
tag (which in fact corresponds to b3, somehow) to Debian Experimental.
This could be reused by Fuel.


Thomas Goirand (zigo)

More information about the OpenStack-dev mailing list