<div dir="ltr">Thanks Arie for starting this discussion! (and sorry for joining in late)<div><br></div><div><div>Some detailed explanations for those not familiar with InfraRed and would like to get the highlights:  (Feel free to skip to my inline comments if you are familiar / too long of a post :) ).<br></div><div><br class="">The InfraRed project is an Ansible based project comprised from three distinct tools: (currently under the InfraRed[1] project, and being split into their own standalone project soon).</div><div><br></div><div>1. ir-provisioner - responsible for building up a custom environment - you can affect the memory, CPU,  HDD size, number of HDD each node has + number of networks (with/without DHCP) so for example one can deploy the following topology: (only an example to show the versatile options)</div><div>1 undercloud on RHEL 7 with 16GB of ram + 60GB of HDD with 3 network interfaces.</div><div>3 controllers on Centos 7 with 8GB of ram  + 40GB of HDD</div><div>2 compute on Centos 7 with 6GB of ram + 60GB HDD</div><div>3 ceph nodes on RHEL 7 with 4GB of ram + 2 HDD one with 20GB + one with 40GB</div><div><br></div><div>Example usage: (setting up the above VMs with four different HW specs)</div><div>ir-provisioner virsh --host-address=<host.address> --host-key=<host.private.key> --topology-nodes=undercloud:1,controller:3,compute:2,ceph:3</div><div><br></div><div>*Note: while it is written "controller/compute/ceph" this is just setting up VMs, the names act more as a reference to the user of what is the role of each node.</div><div>The installation of Openstack is done with a dedicated tool called `ir-installer` (next)</div><div><br></div><div>2. ir-installer - responsible for installing the product - supports "quickstart" mode (setting up a working environment in ~30 minutes) or E2E mode which does a full installation in ~1h.</div><div>The installation process is completely customized. You can supply your own heat templates / overcloud invocation / undercloud.conf file to use / etc. You can also just run a specific task (using ansible --tags), so if you have a deployment ready and just need to run say, the introspection phase, you can fully choose what to run and what to skip even.</div><div><br></div><div>3. ir-tester - responsible for installing / configuring / running the tests - this project is meant to hold all testing tools we use so a user will be able to run any testing utility he would like without the need to "dive in". we supply a simple interface requesting simple to choose the testing tool and the set of tests one wishes to run and we'll do the work for him :)</div><div><br></div><div>More info about InfraRed can be found here[1] (though I must admit that we still need some "love" around our docs)</div><div><br></div><div>[1] - <a href="http://infrared.readthedocs.io/en/latest/" target="_blank">http://infrared.readthedocs.io/en/latest/</a></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 2, 2016 at 9:52 PM, Wesley Hayutin <span dir="ltr"><<a href="mailto:whayutin@redhat.com" target="_blank">whayutin@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Tue, Aug 2, 2016 at 1:51 PM, Arie Bregman <span dir="ltr"><<a href="mailto:abregman@redhat.com" target="_blank">abregman@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>On Tue, Aug 2, 2016 at 3:53 PM, Wesley Hayutin <<a href="mailto:whayutin@redhat.com" target="_blank">whayutin@redhat.com</a>> wrote:<br>
><br>
><br>
> On Tue, Aug 2, 2016 at 4:58 AM, Arie Bregman <<a href="mailto:abregman@redhat.com" target="_blank">abregman@redhat.com</a>> wrote:<br>
>><br>
>> It became a discussion around the official installer and how to<br>
>> improve it. While it's an important discussion, no doubt, I actually<br>
>> want to focus on our automation and CI tools.<br>
>><br>
>> Since I see there is an agreement that collaboration does make sense<br>
>> here, let's move to the hard questions :)<br>
>><br>
>> Wes, Tal - there is huge difference right now between infrared and<br>
>> tripleo-quickstart in their structure. One is all-in-one project and<br>
>> the other one is multiple micro projects managed by one project. Do<br>
>> you think there is a way to consolidate or move to a different model<br>
>> which will make sense for both RDO and RHOSP? something that both<br>
>> groups can work on.<br>
><br>
><br>
> I am happy to be part of the discussion, and I am also very willing to help<br>
> and try to drive suggestions to the tripleo-quickstart community.<br>
> I need to make a point clear though, just to make sure we're on the same<br>
> page..  I do not own oooq, I am not a core on oooq.<br>
> I can help facilitate a discussion but oooq is an upstream tripleo tool that<br>
> replaces instack-virt-setup [1].<br>
> It also happens to be a great tool for easily deploying TripleO end to end<br>
> [3]<br>
><br>
> What I *can* do is show everyone how to manipulate tripleo-quickstart and<br>
> customize it with composable ansible roles, templates, settings etc..<br>
> This would allow any upstream or downstream project to override the native<br>
> oooq roles and *any* step that does not work for another group w/ 3rd party<br>
> roles [2].<br>
> These 3rd party roles can be free and opensource or internal only, it works<br>
> either way.<br>
> This was discussed in depth as part of the production chain meetings,  the<br>
> message may have been lost unfortunately.<br>
><br>
> I hope this resets your expectations of what I can and can not do as part of<br>
> these discussions.<br>
> Let me know where and when and I'm happy to be part of the discussion.<br>
<br>
</div></div>Thanks for clarifying :)<br>
<br>
Next reasonable step would probably be to propose some sort of<br>
blueprint for tripleo-quickstart to include some of InfraRed features<br>
and by that have one tool driven by upstream development that can be<br>
either cloned downstream or used as it is with an internal data<br>
project.<br></blockquote><div><br></div></div></div><div>Sure.. a blueprint would help everyone understand the feature and the motivation.</div><div>You could also just plug in the feature you are looking for to oooq and see if it meets </div><div>your requirements.  See below.</div></div></div></div></blockquote><div><br></div><div>While I think a blueprint is a good starting point, I'm afraid that our approach for provisioning machines is completely different so I'm not sure how to propose such a blueprint as it will probably require quite the design change from today's approach.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
OR<br>
<br>
have InfraRed pushed into tripleo/openstack namespace and expose it to<br>
the RDO community (without internal data of course). Personally, I<br>
really like the pluggable[1] structure (which allows it to actually<br>
consume tripleo-quickstart) so I'm not sure if it can be really merged<br>
with tripleo-quickstart as proposed in the first option.<br></blockquote></span></div></div></div></blockquote><div><br></div><div>I must admit that I like this option better as it introduces a tool to upstream and let the community drive it further / get more feedback on how to improve.</div><div>A second benefit might be that by introducing a new concept / design we can take what is best from two worlds and improve.</div><div>I would love to see an open discussion on the tool upstream and how we can improve the overall process.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"></blockquote><div><br></div></span><div>The way oooq is built one can plugin or override any part at run time</div><div>with custom playbooks, roles, and config.  There isn't anything that needs to be</div><div>checked in directly to oooq to use it.</div><div><br></div><div>It's designed such that third parties can make their own decisions to use something</div><div>native to quickstart, something from our role library, or something completely independent. </div><div>This allows teams, individuals or whom ever to do what they need to with out having to fork or re-roll the entire framework.</div><div><br></div><div>The important step is to note that these 3rd party roles or (oooq-extras) incubate, mature and then graduate to github/openstack.</div><div>The upstream openstack community should lead, evaluate, and via blueprints vote on the canonical CI tool set.   </div><div><br></div><div>We can record a demonstration if required, but there is nothing stopping anyone right now from</div><div>doing this today.  I'm just browsing the role library for an example, I had no idea [1] existed.</div><div>Looks like Raoul had a requirement and just made it work. </div><div><br></div><div>Justin, from the browbeat project has graciously created some documentation regarding 3rd party roles.</div><div>It has yet to merge, but it should help illustrate how these roles are used. [2]</div><div><br></div><div>Thanks Arie for leading the discussion. </div><div><br></div><div>[1] <a href="https://github.com/redhat-openstack/ansible-role-tripleo-overcloud-validate-ha" target="_blank">https://github.com/redhat-openstack/ansible-role-tripleo-overcloud-validate-ha</a></div><div>[2] <a href="https://review.openstack.org/#/c/346733/" target="_blank">https://review.openstack.org/#/c/346733/</a></div><div><div class="h5"><div><br></div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I like the second option, although it still forces us to have two<br>
tools, but after a period of time, I believe it will be clear what the<br>
community prefers, which will allow us to remove one of the projects<br>
eventually.<br>
<br>
So, unless there are other ideas, I think the next move should be made by Tal.<br>
<br>
Tal, I'm willing to help with whatever is needed.<br></blockquote></div></div></div></div></div></blockquote><div><br></div><div>Thanks Arie for starting this discussion again, I believe we have still much work ahead of us but this is definitely a step in the right direction.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
[1] <a href="http://infrared.readthedocs.io/en/latest" rel="noreferrer" target="_blank">http://infrared.readthedocs.io/en/latest</a><br>
<div><div><br>
><br>
> Thanks<br>
><br>
> [1] <a href="https://blueprints.launchpad.net/tripleo/+spec/tripleo-quickstart" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/tripleo/+spec/tripleo-quickstart</a><br>
> [2]<br>
> <a href="https://github.com/redhat-openstack/?utf8=%E2%9C%93&query=ansible-role-tripleo" rel="noreferrer" target="_blank">https://github.com/redhat-openstack/?utf8=%E2%9C%93&query=ansible-role-tripleo</a><br>
> [3[ <a href="https://www.rdoproject.org/tripleo/" rel="noreferrer" target="_blank">https://www.rdoproject.org/tripleo/</a><br>
><br>
><br>
>><br>
>><br>
>> Raoul - I totally agree with you, especially with "difficult for<br>
>> anyone to start contributing and collaborate". This is exactly why<br>
>> this discussion started. If we can agree on one set of tools, it will<br>
>> make everyone's life easier - current groups, new contributors, folks<br>
>> that just want to deploy TripleO quickly. But I'm afraid some<br>
>> sacrifices need to be made by both groups.<br>
>><br>
>> David - I thought WeiRDO is used only for packstack, so I apologize I<br>
>> didn't include it. It does sound like an anther testing project, is<br>
>> there a place to merge it with another existing testing project? like<br>
>> Octario for example or one of TripleO testing projects. Or does it<br>
>> make sense to keep it a standalone project?<br>
>><br>
>><br>
>><br>
>><br>
>> On Tue, Aug 2, 2016 at 11:12 AM, Christopher Brown <<a href="mailto:cbrown2@ocf.co.uk" target="_blank">cbrown2@ocf.co.uk</a>><br>
>> wrote:<br>
>> > Hello RDOistas (I think that is the expression?),<br>
>> ><br>
>> > Another year, another OpenStack deployment tool. :)<br>
>> ><br>
>> > On Mon, 2016-08-01 at 18:59 +0100, Ignacio Bravo wrote:<br>
>> >> If we are talking about tools, I would also want to add something<br>
>> >> with regards to user interface of these tools. This is based on my<br>
>> >> own experience:<br>
>> >><br>
>> >> I started trying to deploy Openstack with Staypuft and The Foreman.<br>
>> >> The UI of The Foreman was intuitive enough for the discovery and<br>
>> >> provisioning of the servers. The OpenStack portion, not so much.<br>
>> ><br>
>> > This is exactly mine also. I think this works really well in very large<br>
>> > enterprise environments where you need to split out services over more<br>
>> > than three controllers. You do need good in-house puppet skills though<br>
>> > so better for enterprise with a good sysadmin team.<br>
>> ><br>
>> >> Forward a couple of releases and we had a TripleO GUI (Tuskar, I<br>
>> >> believe) that allowed you to graphically build your Openstack cloud.<br>
>> >> That was a reasonable good GUI for Openstack.<br>
>> ><br>
>> > Well, I found it barely usable. It was only ever good as a graphical<br>
>> > representiation of what the build was doing. Interacting with it was<br>
>> > not great.<br>
>> ><br>
>> >> Following that, TripleO become a script based installer, that<br>
>> >> required experience in Heat templates. I know I didn’t have it and<br>
>> >> had to ask in the mailing list about how to present this or change<br>
>> >> that. I got a couple of installs working with this setup.<br>
>> ><br>
>> > Works well now that I understand all the foibles and have invested time<br>
>> > into understanding heat templates and puppet modules. Its good in that<br>
>> > it forces you to learn about orchestration which is such an important<br>
>> > end-goal of cloud environments.<br>
>> ><br>
>> >> In the last session in Austin, my goal was to obtain information on<br>
>> >> how others were installing Openstack. I was pointed to Fuel as an<br>
>> >> alternative. I tried it up, and it just worked. It had the<br>
>> >> discovering capability from The Foreman, and the configuration<br>
>> >> options from TripleO. I understand that is based in Ansible and<br>
>> >> because of that, it is not fully CentOS ready for all the nodes (at<br>
>> >> least not in version 9 that I tried). In any case, as a deployer and<br>
>> >> installer, it is the most well rounded tool that I found.<br>
>> ><br>
>> > This is interesting to know. I've heard of Fuel of course but there are<br>
>> > some politics involved - it still has the team:single-vendor tag but<br>
>> > from what I see Mirantis are very keen for it to become the default<br>
>> > OpenStack installer. I don't think being Ansible-based should be a<br>
>> > problem - we are deploying OpenShift on OpenStack which uses Openshift-<br>
>> > ansible - this recently moved to Ansible 2.1 without too much<br>
>> > disruption.<br>
>> ><br>
>> >> I’d love to see RDO moving into that direction, and having an easy to<br>
>> >> use, end user ready deployer tool.<br>
>> ><br>
>> > If its as good as you say its definitely worth evaluating. From our<br>
>> > point of view, we want to be able to add services to the pacemaker<br>
>> > cluster with some ease - for example Magnum and Sahara - and it looks<br>
>> > like there are steps being taken with regards to composable roles and<br>
>> > simplification of the pacemaker cluster to just core services.<br>
>> ><br>
>> > But if someone can explain that better I would appreciate it.<br>
>> ><br>
>> > Regards<br>
>> ><br>
>> >> IB<br>
>> >><br>
>> >><br>
>> >> __<br>
>> >> Ignacio Bravo<br>
>> >> LTG Federal, Inc<br>
>> >> <a href="http://www.ltgfederal.com" rel="noreferrer" target="_blank">www.ltgfederal.com</a><br>
>> >><br>
>> >><br>
>> >> > On Aug 1, 2016, at 1:07 PM, David Moreau Simard <<a href="mailto:dms@redhat.com" target="_blank">dms@redhat.com</a>><br>
>> >> > wrote:<br>
>> >> ><br>
>> >> > The vast majority of RDO's CI relies on using upstream<br>
>> >> > installation/deployment projects in order to test installation of<br>
>> >> > RDO<br>
>> >> > packages in different ways and configurations.<br>
>> >> ><br>
>> >> > Unless I'm mistaken, TripleO Quickstart was originally created as a<br>
>> >> > mean to "easily" install TripleO in different topologies without<br>
>> >> > requiring a massive amount of hardware.<br>
>> >> > This project allows us to test TripleO in virtual deployments on<br>
>> >> > just<br>
>> >> > one server instead of, say, 6.<br>
>> >> ><br>
>> >> > There's also WeIRDO [1] which was left out of your list.<br>
>> >> > WeIRDO is super simple and simply aims to run upstream gate jobs<br>
>> >> > (such<br>
>> >> > as puppet-openstack-integration [2][3] and packstack [4][5])<br>
>> >> > outside<br>
>> >> > of the gate.<br>
>> >> > It'll install dependencies that are expected to be there (i.e,<br>
>> >> > usually<br>
>> >> > set up by the openstack-infra gate preparation jobs), set up the<br>
>> >> > trunk<br>
>> >> > repositories we're interested in testing and the rest is handled by<br>
>> >> > the upstream project testing framework.<br>
>> >> ><br>
>> >> > The WeIRDO project is /very/ low maintenance and brings an<br>
>> >> > exceptional<br>
>> >> > amount of coverage and value.<br>
>> >> > This coverage is important because RDO provides OpenStack packages<br>
>> >> > or<br>
>> >> > projects that are not necessarily used by TripleO and the reality<br>
>> >> > is<br>
>> >> > that not everyone deploying OpenStack on CentOS with RDO will be<br>
>> >> > using<br>
>> >> > TripleO.<br>
>> >> ><br>
>> >> > Anyway, sorry for sidetracking but back to the topic, thanks for<br>
>> >> > opening the discussion.<br>
>> >> ><br>
>> >> > What honestly perplexes me is the situation of CI in RDO and OSP,<br>
>> >> > especially around TripleO/Director, is the amount of work that is<br>
>> >> > spent downstream.<br>
>> >> > And by downstream, here, I mean anything that isn't in TripleO<br>
>> >> > proper.<br>
>> >> ><br>
>> >> > I keep dreaming about how awesome upstream TripleO CI would be if<br>
>> >> > all<br>
>> >> > that effort was spent directly there instead -- and then that all<br>
>> >> > work<br>
>> >> > could bear fruit and trickle down downstream for free.<br>
>> >> > Exactly like how we keep improving the testing coverage in<br>
>> >> > puppet-openstack-integration, it's automatically pulled in RDO CI<br>
>> >> > through WeIRDO for free.<br>
>> >> > We make the upstream better and we benefit from it simultaneously:<br>
>> >> > everyone wins.<br>
>> >> ><br>
>> >> > [1]: <a href="https://github.com/rdo-infra/weirdo" rel="noreferrer" target="_blank">https://github.com/rdo-infra/weirdo</a><br>
>> >> > [2]: <a href="https://github.com/rdo-infra/ansible-role-weirdo-puppet-openst" rel="noreferrer" target="_blank">https://github.com/rdo-infra/ansible-role-weirdo-puppet-openst</a><br>
>> >> > ack<br>
>> >> > [3]: <a href="https://github.com/openstack/puppet-openstack-integration#desc" rel="noreferrer" target="_blank">https://github.com/openstack/puppet-openstack-integration#desc</a><br>
>> >> > ription<br>
>> >> > [4]: <a href="https://github.com/rdo-infra/ansible-role-weirdo-packstack" rel="noreferrer" target="_blank">https://github.com/rdo-infra/ansible-role-weirdo-packstack</a><br>
>> >> > [5]: <a href="https://github.com/openstack/packstack#packstack-integration-t" rel="noreferrer" target="_blank">https://github.com/openstack/packstack#packstack-integration-t</a><br>
>> >> > ests<br>
>> >> ><br>
>> >> > David Moreau Simard<br>
>> >> > Senior Software Engineer | Openstack RDO<br>
>> >> ><br>
>> >> > dmsimard = [irc, github, twitter]<br>
>> >> ><br>
>> >> > David Moreau Simard<br>
>> >> > Senior Software Engineer | Openstack RDO<br>
>> >> ><br>
>> >> > dmsimard = [irc, github, twitter]<br>
>> >> ><br>
>> >> ><br>
>> >> > On Mon, Aug 1, 2016 at 11:21 AM, Arie Bregman <<a href="mailto:abregman@redhat.com" target="_blank">abregman@redhat.com</a>><br>
>> >> > wrote:<br>
>> >> > > Hi,<br>
>> >> > ><br>
>> >> > > I would like to start a discussion on the overlap between tools<br>
>> >> > > we<br>
>> >> > > have for deploying and testing TripleO (RDO & RHOSP) in CI.<br>
>> >> > ><br>
>> >> > > Several months ago, we worked on one common framework for<br>
>> >> > > deploying<br>
>> >> > > and testing OpenStack (RDO & RHOSP) in CI. I think you can say it<br>
>> >> > > didn't work out well, which eventually led each group to focus on<br>
>> >> > > developing other existing/new tools.<br>
>> >> > ><br>
>> >> > > What we have right now for deploying and testing<br>
>> >> > > --------------------------------------------------------<br>
>> >> > > === Component CI, Gating ===<br>
>> >> > > I'll start with the projects we created, I think that's only fair<br>
>> >> > > :)<br>
>> >> > ><br>
>> >> > > * Ansible-OVB[1] - Provisioning Tripleo heat stack, using the OVB<br>
>> >> > > project.<br>
>> >> > ><br>
>> >> > > * Ansible-RHOSP[2] - Product installation (RHOSP). Branch per<br>
>> >> > > release.<br>
>> >> > ><br>
>> >> > > * Octario[3] - Testing using RPMs (pep8, unit, functional,<br>
>> >> > > tempest,<br>
>> >> > > csit) + Patching RPMs with submitted code.<br>
>> >> > ><br>
>> >> > > === Automation, QE ===<br>
>> >> > > * InfraRed[4] - provision install and test. Pluggable and<br>
>> >> > > modular,<br>
>> >> > > allows you to create your own provisioner, installer and tester.<br>
>> >> > ><br>
>> >> > > As far as I know, the groups is working now on different<br>
>> >> > > structure of<br>
>> >> > > one main project and three sub projects (provision, install and<br>
>> >> > > test).<br>
>> >> > ><br>
>> >> > > === RDO ===<br>
>> >> > > I didn't use RDO tools, so I apologize if I got something wrong:<br>
>> >> > ><br>
>> >> > > * About ~25 micro independent Ansible roles[5]. You can either<br>
>> >> > > choose<br>
>> >> > > to use one of them or several together. They are used for<br>
>> >> > > provisioning, installing and testing Tripleo.<br>
>> >> > ><br>
>> >> > > * Tripleo-quickstart[6] - uses the micro roles for deploying<br>
>> >> > > tripleo<br>
>> >> > > and test it.<br>
>> >> > ><br>
>> >> > > As I said, I didn't use the tools, so feel free to add more<br>
>> >> > > information you think is relevant.<br>
>> >> > ><br>
>> >> > > === More? ===<br>
>> >> > > I hope not. Let us know if are familiar with more tools.<br>
>> >> > ><br>
>> >> > > Conclusion<br>
>> >> > > --------------<br>
>> >> > > So as you can see, there are several projects that eventually<br>
>> >> > > overlap<br>
>> >> > > in many areas. Each group is basically using the same tasks<br>
>> >> > > (provision<br>
>> >> > > resources, build/import overcloud images, run tempest, collect<br>
>> >> > > logs,<br>
>> >> > > etc.)<br>
>> >> > ><br>
>> >> > > Personally, I think it's a waste of resources. For each task<br>
>> >> > > there is<br>
>> >> > > at least two people from different groups who work on exactly the<br>
>> >> > > same<br>
>> >> > > task. The most recent example I can give is OVB. As far as I<br>
>> >> > > know,<br>
>> >> > > both groups are working on implementing it in their set of tools<br>
>> >> > > right<br>
>> >> > > now.<br>
>> >> > ><br>
>> >> > > On the other hand, you can always claim: "we already tried to<br>
>> >> > > work on<br>
>> >> > > the same framework, we failed to do it successfully" - right, but<br>
>> >> > > maybe with better ground rules we can manage it. We would<br>
>> >> > > defiantly<br>
>> >> > > benefit a lot from doing that.<br>
>> >> > ><br>
>> >> > > What's next?<br>
>> >> > > ----------------<br>
>> >> > > So first of all, I would like to hear from you if you think that<br>
>> >> > > we<br>
>> >> > > can collaborate once again or is it actually better to keep it as<br>
>> >> > > it<br>
>> >> > > is now.<br>
>> >> > ><br>
>> >> > > If you agree that collaboration here makes sense, maybe you have<br>
>> >> > > ideas<br>
>> >> > > on how we can do it better this time.<br>
>> >> > ><br>
>> >> > > I think that setting up a meeting to discuss the right<br>
>> >> > > architecture<br>
>> >> > > for the project(s) and decide on good review/gating process,<br>
>> >> > > would be<br>
>> >> > > a good start.<br>
>> >> > ><br>
>> >> > > Please let me know what do you think and keep in mind that this<br>
>> >> > > is not<br>
>> >> > > about which tool is better!. As you can see I didn't mention the<br>
>> >> > > time<br>
>> >> > > it takes for each tool to deploy and test, and also not the full<br>
>> >> > > feature list it supports.<br>
>> >> > > If possible, we should keep it about collaborating and not<br>
>> >> > > choosing<br>
>> >> > > the best tool. Our solution could be the combination of two or<br>
>> >> > > more<br>
>> >> > > tools eventually (tripleo-red, infra-quickstart? :D )<br>
>> >> > ><br>
>> >> > > "You may say I'm a dreamer, but I'm not the only one. I hope some<br>
>> >> > > day<br>
>> >> > > you'll join us and the infra will be as one" :)<br>
>> >> > ><br>
>> >> > > [1] <a href="https://github.com/redhat-openstack/ansible-ovb" rel="noreferrer" target="_blank">https://github.com/redhat-openstack/ansible-ovb</a><br>
>> >> > > [2] <a href="https://github.com/redhat-openstack/ansible-rhosp" rel="noreferrer" target="_blank">https://github.com/redhat-openstack/ansible-rhosp</a><br>
>> >> > > [3] <a href="https://github.com/redhat-openstack/octario" rel="noreferrer" target="_blank">https://github.com/redhat-openstack/octario</a><br>
>> >> > > [4] <a href="https://github.com/rhosqeauto/InfraRed" rel="noreferrer" target="_blank">https://github.com/rhosqeauto/InfraRed</a><br>
>> >> > > [5] <a href="https://github.com/redhat-openstack?utf8=%E2%9C%93&query=ansi" rel="noreferrer" target="_blank">https://github.com/redhat-openstack?utf8=%E2%9C%93&query=ansi</a><br>
>> >> > > ble-role<br>
>> >> > > [6] <a href="https://github.com/openstack/tripleo-quickstart" rel="noreferrer" target="_blank">https://github.com/openstack/tripleo-quickstart</a><br>
>> >> > ><br>
>> >> > > _______________________________________________<br>
>> >> > > rdo-list mailing list<br>
>> >> > > <a href="mailto:rdo-list@redhat.com" target="_blank">rdo-list@redhat.com</a><br>
>> >> > > <a href="https://www.redhat.com/mailman/listinfo/rdo-list" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/rdo-list</a><br>
>> >> > ><br>
>> >> > > To unsubscribe: <a href="mailto:rdo-list-unsubscribe@redhat.com" target="_blank">rdo-list-unsubscribe@redhat.com</a><br>
>> >> > _______________________________________________<br>
>> >> > rdo-list mailing list<br>
>> >> > <a href="mailto:rdo-list@redhat.com" target="_blank">rdo-list@redhat.com</a><br>
>> >> > <a href="https://www.redhat.com/mailman/listinfo/rdo-list" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/rdo-list</a><br>
>> >> ><br>
>> >> > To unsubscribe: <a href="mailto:rdo-list-unsubscribe@redhat.com" target="_blank">rdo-list-unsubscribe@redhat.com</a><br>
>> >><br>
>> > --<br>
>> > Regards,<br>
>> ><br>
>> > Christopher Brown<br>
>> > OpenStack Engineer<br>
>> > OCF plc<br>
>> ><br>
>> > Tel: <a href="tel:%2B44%20%280%29114%20257%202200" value="+441142572200" target="_blank">+44 (0)114 257 2200</a><br>
>> > Web: <a href="http://www.ocf.co.uk" rel="noreferrer" target="_blank">www.ocf.co.uk</a><br>
>> > Blog: <a href="http://blog.ocf.co.uk" rel="noreferrer" target="_blank">blog.ocf.co.uk</a><br>
>> > Twitter: @ocfplc<br>
>> ><br>
>> > Please note, any emails relating to an OCF Support request must always<br>
>> > be sent to <a href="mailto:support@ocf.co.uk" target="_blank">support@ocf.co.uk</a> for a ticket number to be generated or<br>
>> > existing support ticket to be updated. Should this not be done then OCF<br>
>> > cannot be held responsible for requests not dealt with in a timely<br>
>> > manner.<br>
>> ><br>
>> > OCF plc is a company registered in England and Wales. Registered number<br>
>> > 4132533, VAT number GB 780 6803 14. Registered office address: OCF plc,<br>
>> > 5 Rotunda Business Centre, Thorncliffe Park, Chapeltown, Sheffield S35<br>
>> > 2PG.<br>
>> ><br>
>> > This message is private and confidential. If you have received this<br>
>> > message in error, please notify us immediately and remove it from your<br>
>> > system.<br>
>> ><br>
>> > _______________________________________________<br>
>> > rdo-list mailing list<br>
>> > <a href="mailto:rdo-list@redhat.com" target="_blank">rdo-list@redhat.com</a><br>
>> > <a href="https://www.redhat.com/mailman/listinfo/rdo-list" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/rdo-list</a><br>
>> ><br>
>> > To unsubscribe: <a href="mailto:rdo-list-unsubscribe@redhat.com" target="_blank">rdo-list-unsubscribe@redhat.com</a><br>
>><br>
>><br>
>><br>
>> --<br>
>> Arie Bregman<br>
>> Red Hat Israel<br>
>> Component CI: <a href="https://mojo.redhat.com/groups/rhos-core-ci/overview" rel="noreferrer" target="_blank">https://mojo.redhat.com/groups/rhos-core-ci/overview</a><br>
><br>
><br>
<br>
<br>
<br>
--<br>
Arie Bregman<br>
Red Hat Israel<br>
Component CI: <a href="https://mojo.redhat.com/groups/rhos-core-ci/overview" rel="noreferrer" target="_blank">https://mojo.redhat.com/groups/rhos-core-ci/overview</a><br>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><font face="arial, helvetica, sans-serif"><span style="color:rgb(51,51,51);font-size:13.3333px;background-color:rgb(253,253,253)">Tal Kammer</span><br style="font-size:13.3333px;color:rgb(51,51,51)"><span style="color:rgb(51,51,51);font-size:13.3333px;background-color:rgb(253,253,253)">Associate manager, automation and infrastracture, Openstack platform.</span><br style="font-size:13.3333px;color:rgb(51,51,51)"><span style="color:rgb(51,51,51);font-size:13.3333px;background-color:rgb(253,253,253)">Red Hat Israel</span><br style="font-size:13.3333px;color:rgb(51,51,51)"><span style="color:rgb(51,51,51);font-size:13.3333px;background-color:rgb(253,253,253)">Automation group mojo: </span><span style="font-size:13.3333px;color:rgb(0,105,144)"><span style="font-size:10pt"><a href="https://mojo.redhat.com/docs/DOC-1011659" style="color:rgb(0,105,144);text-decoration:none;font-size:10pt" target="_blank">https://mojo.redhat.com/docs/DOC-1011659</a></span></span></font><br></div></div></div></div></div></div>
</div></div>