[rdo-list] Multiple tools for deploying and testing TripleO

[Jiří Stránský]

On 4.8.2016 20:55, Wesley Hayutin wrote:
> I would add one thing.. If there are folks out there that rely on CI or CI
> tools and need to be part of this process than please speak up!
> If you have tools, ideas, requirements now's a pretty good time to be
> verbose about it.  Some of you already have, some have not.
>

Thanks for the poke Wes, i'll post my 2 cents as well :) I have a 
developer point of view rather than CI point of view but hopefully 
that's interesting as well.


My subjective view on automation tool requirements:
---------------------------------------------------

I've been using inlunch [1]. It's halfway between a bash script and a 
"usual" Ansible solution. Much of the workflow is exported into an 
answer file which contains bash snippets. From previous discussions i 
know many people don't like such approach and would prefer to properly 
Ansiblize everything, but for my productivity it is vital that i can 
just add a (sometimes temporary) Bash line here and there and go on. 
Ansible is there just to ensure (limited) idempotency and restartability 
of the deployment from somewhere in the middle.

Some other features i consider vital for a TripleO automation tool as a 
developer:

* Allow to deploy trunk and stables as CI deploys them. (E.g. OOOQ is 
really impressive but diverges from the way things are done in CI, 
which, when testing a patch, can result in local failures when CI would 
pass and vice versa. We've hit one such issue wrt undercloud image 
building.)

* Allow to deploy downstream following product docs as close as 
possible. (I know this may not be interesting from a community point of 
view, but it's a must have for me personally, as downstream involvement 
is a part of my job.)


A couple of general points:
---------------------------

* The replacement for instack-virt-setup should be a tool completely 
separate from install workflow automation tool IMO. If we manage to 
extract it into an independent project with a defined interface and 
feature set, we should be able to adopt it in the CI much easier than 
full OOOQ.

* From the past discussions i've been involved in on this topic (e.g. 
inlunch vs. khaleesi vs. OOOQ), the expectations/requirements vary so 
much that coming to a single unified automation tool is very difficult.

   * Whatever automation tool we build, we need to keep in mind that the 
documented manual installation method (which ideally would be the base 
of all automations and CIs anyway) has to be kept as simple as possible 
too. And if the manual installation workflow is sane, maintaining an 
automation tool that fits the needs of a few people is not very time 
consuming (see how few commits per month inlunch needs [2]). Perhaps 
that's why we have so many of these tools :) The benefits of creating 
something that fits *your* use case sometimes outweigh the time spent 
building it and drawbacks of having to adopt and bend some existing 
solution.

   * That said, there's still great value in having one of the tools be 
more official than others, maintained and ready especially for folks who 
are starting with TripleO (again i see the developer use case here more 
clearly than the CI use case). From what i've seen OOOQ seems to be very 
good in this aspect.


Cheers

Jirka

[1] https://github.com/jistr/inlunch
[2] https://github.com/jistr/inlunch/commits/master