Open Stack

On 03/01/2016 12:21 PM, Vladimir Kuklin wrote:
> Moreover, having such git ref as a source in our Puppetfile will lead to
> the situation when we have UNREPRODUCIBLE build of Fuel project. Each
> build may and will result in different code and you will not be able to
> tell which one without actually looking into the build logs.

Which is exactly why we should move away from commit, and start
building, and maybe automatically updating, puppet-module-* Debian (or
CentOS) packages. Such package update could be done the way you
suggested: based on nightly builds with a CI job that check if they work
properly. I do agree with you that a 1 day delay is acceptable, but we
should try to reduce it as much as possible. It'd be easy to keep a copy
of the built package (for a few days?), and make a reference of what was
the used top level commit sha256 hash, so we have a reference point of
what worked, and what didn't.

I'd love to have the Debian package for puppet modules automatically
built in upstream infra (on each commit, and for every CR), though
unfortunately, we're not there yet. Hopefully, we'll see the light at
the end of this tunnel, and it will eventually happen.

BTW, IMO, this discussion is completely orthogonal to having a fully
working check job within puppet-openstack. Mixing both conversations is
a dangerous slope which we should avoid.

> Additionally, we do not have:
> 
> 1) depends-on support
> 2) any process instantiated for monitoring of the Puppet-Openstack FUEL
> CI job
> 3) any person responsible for monitoring of that job

If we do nightly builds of puppet modules, then we *also* need someone
to take the responsibility, don't we? The same way as you wrote, this
may lead to a full one day of work, no? What would be the difference?

Cheers,

Thomas Goirand (zigo)