On 2017-05-22 12:31:49 -0600 (-0600), Alex Schultz wrote:
On Mon, May 22, 2017 at 10:34 AM, Jeremy Stanley firstname.lastname@example.org wrote:
On 2017-05-22 09:06:26 -0600 (-0600), Alex Schultz wrote:
We ran into this for the puppet-module-build check job so I created a
puppet-agent-install builder. Perhaps the job needs that added to it
Problem here being these repos share the common tarball jobs used
for generating python sdists, with a little custom logic baked into
run-tarball.sh[*] for detecting and adjusting when the repo is for a
Puppet module. I think this highlights the need to create custom
tarball jobs for Puppet modules, preferably by abstracting this
custom logic into a new JJB builder.
I assume you mean a problem if we added this builder to the job
and it fails for some reason thus impacting the python jobs?
My concern is more that it increases complexity by further embedding
package selection and installation choices into that already complex
script. We'd (Infra team) like to get more of the logic out of that
random pile of shell scripts and directly into job definitions
instead. For one thing, those scripts are only updated when we
regenerate our nodepool images (at best once a day) and leads to
significant job inconsistencies if we have image upload failures in
some providers but not others. In contrast, job configurations are
updated nearly instantly (and can even be self-tested in many cases
once we're on Zuul v3).
As far as adding to the builder to the job that's not really a
problem and wouldn't change those jobs as they don't reference the
installed puppet executable.
It does risk further destabilizing the generic tarball jobs by
introducing more outside dependencies which will only be used by a
scant handful of the projects running them.
The problem I have with putting this in the .sh is that it becomes
yet another place where we're doing this package installation (we
already do it in puppet openstack in
puppet-openstack-integration). I originally proposed the builder
because it could be reused if a job requires puppet be available.
ie. this case. I'd rather not do what we do in the builder in a
shell script in the job and it seems like this is making it more
complicated than it needs to be when we have to manage this in the
Agreed, I'm saying a builder which installs an unnecessary Puppet
toolchain for the generic tarball jobs is not something we'd want,
but it would be pretty trivial to make puppet-specific tarball jobs
which do use that builder (and has the added benefit that
Puppet-specific logic can be moved out of run-tarballs.sh and into
your job configuration instead at that point).
OpenStack Development Mailing List (not for usage questions)