<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 2, 2016 at 4:58 AM, 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">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></blockquote><div><br></div><div><div>I am happy to be part of the discussion, and I am also very willing to help and try to drive suggestions to the tripleo-quickstart community.</div></div><div>I need to make a point clear though, just to make sure we're on the same page..  I do not own oooq, I am not a core on oooq.<br></div><div>I can help facilitate a discussion but oooq is an upstream tripleo tool that replaces instack-virt-setup [1].</div><div>It also happens to be a great tool for easily deploying TripleO end to end [3]</div><div><br></div><div>What I *can* do is show everyone how to manipulate tripleo-quickstart and customize it with composable ansible roles, templates, settings etc..</div><div>This would allow any upstream or downstream project to override the native oooq roles and *any* step that does not work for another group w/ 3rd party roles [2].</div><div>These 3rd party roles can be free and opensource or internal only, it works either way.</div><div>This was discussed in depth as part of the production chain meetings,  the message may have been lost unfortunately.</div><div><br></div><div>I hope this resets your expectations of what I can and can not do as part of these discussions.</div><div>Let me know where and when and I'm happy to be part of the discussion.</div><div><br></div><div>Thanks </div><div><br></div><div>[1] <a href="https://blueprints.launchpad.net/tripleo/+spec/tripleo-quickstart">https://blueprints.launchpad.net/tripleo/+spec/tripleo-quickstart</a></div><div>[2] <a href="https://github.com/redhat-openstack/?utf8=%E2%9C%93&query=ansible-role-tripleo">https://github.com/redhat-openstack/?utf8=%E2%9C%93&query=ansible-role-tripleo</a></div><div>[3[ <a href="https://www.rdoproject.org/tripleo/">https://www.rdoproject.org/tripleo/</a></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>
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>
<div class=""><div class="h5"><br>
<br>
<br>
<br>
On Tue, Aug 2, 2016 at 11:12 AM, Christopher Brown <<a href="mailto:cbrown2@ocf.co.uk">cbrown2@ocf.co.uk</a>> 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">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">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">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">rdo-list-unsubscribe@redhat.com</a><br>
>> > _______________________________________________<br>
>> > rdo-list mailing list<br>
>> > <a href="mailto:rdo-list@redhat.com">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">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">+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">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">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">rdo-list-unsubscribe@redhat.com</a><br>
<br>
<br>
<br>
</div></div><span class=""><font color="#888888">--<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>
</font></span></blockquote></div><br></div></div>