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

On 4.8.2016 20:55, Wesley Hayutin wrote: 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