On 01/08/2016 17:21, Arie Bregman wrote:
 Hi,
 
 I would like to start a discussion on the overlap between tools we
 have for deploying and testing TripleO (RDO & RHOSP) in CI.
 
 Several months ago, we worked on one common framework for deploying
 and testing OpenStack (RDO & RHOSP) in CI. I think you can say it
 didn't work out well, which eventually led each group to focus on
 developing other existing/new tools.
 
 What we have right now for deploying and testing
 --------------------------------------------------------
 === Component CI, Gating ===
 I'll start with the projects we created, I think that's only fair :)
 
 * Ansible-OVB[1] - Provisioning Tripleo heat stack, using the OVB project.
 
 * Ansible-RHOSP[2] - Product installation (RHOSP). Branch per release.
 
 * Octario[3] - Testing using RPMs (pep8, unit, functional, tempest,
 csit) + Patching RPMs with submitted code.
 
 === Automation, QE ===
 * InfraRed[4] - provision install and test. Pluggable and modular,
 allows you to create your own provisioner, installer and tester.
 
 As far as I know, the groups is working now on different structure of
 one main project and three sub projects (provision, install and test).
 
 === RDO ===
 I didn't use RDO tools, so I apologize if I got something wrong:
 
 * About ~25 micro independent Ansible roles[5]. You can either choose
 to use one of them or several together. They are used for
 provisioning, installing and testing Tripleo.
 
 * Tripleo-quickstart[6] - uses the micro roles for deploying tripleo
 and test it.
 
 As I said, I didn't use the tools, so feel free to add more
 information you think is relevant.
 
 === More? ===
 I hope not. Let us know if are familiar with more tools. 
First of all Arie thanks for starting this discussion.
Just as an addition at the moment we(at HA-CI)'re using this [1] to test
OSP downstream (but it supports upstream). For the rdo-stream we are
using with success quickstart, after developing a specific role to
deploys on barmetal [2].
I understand what's your point and I agree with it all the line,
unfortunately I don't have answers, but I can share my experience.
The main problem I found was that it was very difficult to find a
starting point for a newbie. I'm talking for myself of course, but for
me it was quicker to deploy the scripts in [1] (over 8 months ago) than
choose a tool from the table that was suitable for our purpose.
I know that this may sound like a cat that bites his tail, but I think
that without a common entry point it will be always difficult for anyone
to start contributing and collaborate with existing problem.
I mean, if today someone wants to start playing on tripleo/director to
deploy something useful (say, for example, high availability undercloud)
what will be the official suggestion to have a deployed environment?
Does he have to use Octario? But what if he needs provisioning? Does he
have to use quickstart? But then what if he needs to use baremetal?
I don't want to add entropy to the discussion, I'm just saying that
finding something that covers everything is more than complicated at
this point. For sure it does not justify creating new tool for each
need, but in some way it explains it.
Maybe it could be useful having some kind of matrix representing
needs/tools to start from, to be used as a starting point for the
newbies and as way to find common points to see what can be done to
unify the tools.
These are my two cents, sorry for being so long.
[1] 
https://github.com/rscarazz/tripleo-director-installer
[2]
https://github.com/redhat-openstack/ansible-role-tripleo-baremetal-underc...
-- 
Raoul Scarazzini
rasca(a)redhat.com
 Conclusion
 --------------
 So as you can see, there are several projects that eventually overlap
 in many areas. Each group is basically using the same tasks (provision
 resources, build/import overcloud images, run tempest, collect logs,
 etc.)
 
 Personally, I think it's a waste of resources. For each task there is
 at least two people from different groups who work on exactly the same
 task. The most recent example I can give is OVB. As far as I know,
 both groups are working on implementing it in their set of tools right
 now.
 
 On the other hand, you can always claim: "we already tried to work on
 the same framework, we failed to do it successfully" - right, but
 maybe with better ground rules we can manage it. We would defiantly
 benefit a lot from doing that.
 
 What's next?
 ----------------
 So first of all, I would like to hear from you if you think that we
 can collaborate once again or is it actually better to keep it as it
 is now.
 
 If you agree that collaboration here makes sense, maybe you have ideas
 on how we can do it better this time.
 
 I think that setting up a meeting to discuss the right architecture
 for the project(s) and decide on good review/gating process, would be
 a good start.
 
 Please let me know what do you think and keep in mind that this is not
 about which tool is better!. As you can see I didn't mention the time
 it takes for each tool to deploy and test, and also not the full
 feature list it supports.
 If possible, we should keep it about collaborating and not choosing
 the best tool. Our solution could be the combination of two or more
 tools eventually (tripleo-red, infra-quickstart? :D )
 
 "You may say I'm a dreamer, but I'm not the only one. I hope some day
 you'll join us and the infra will be as one" :)
 
 [1] 
https://github.com/redhat-openstack/ansible-ovb
 [2] 
https://github.com/redhat-openstack/ansible-rhosp
 [3] 
https://github.com/redhat-openstack/octario
 [4] 
https://github.com/rhosqeauto/InfraRed
 [5] 
https://github.com/redhat-openstack?utf8=%E2%9C%93&query=ansible-role
 [6] 
https://github.com/openstack/tripleo-quickstart
 
 _______________________________________________
 rdo-list mailing list
 rdo-list(a)redhat.com
 
https://www.redhat.com/mailman/listinfo/rdo-list
 
 To unsubscribe: rdo-list-unsubscribe(a)redhat.com