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.

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

On Aug 1, 2016, at 1:07 PM, David Moreau Simard <dms(a)redhat.com&gt; wrote: The vast majority of RDO's CI relies on using upstream installation/deployment projects in order to test installation of RDO packages in different ways and configurations. Unless I'm mistaken, TripleO Quickstart was originally created as a mean to "easily" install TripleO in different topologies without requiring a massive amount of hardware. This project allows us to test TripleO in virtual deployments on just one server instead of, say, 6. There's also WeIRDO [1] which was left out of your list. WeIRDO is super simple and simply aims to run upstream gate jobs (such as puppet-openstack-integration [2][3] and packstack [4][5]) outside of the gate. It'll install dependencies that are expected to be there (i.e, usually set up by the openstack-infra gate preparation jobs), set up the trunk repositories we're interested in testing and the rest is handled by the upstream project testing framework. The WeIRDO project is /very/ low maintenance and brings an exceptional amount of coverage and value. This coverage is important because RDO provides OpenStack packages or projects that are not necessarily used by TripleO and the reality is that not everyone deploying OpenStack on CentOS with RDO will be using TripleO. Anyway, sorry for sidetracking but back to the topic, thanks for opening the discussion. What honestly perplexes me is the situation of CI in RDO and OSP, especially around TripleO/Director, is the amount of work that is spent downstream. And by downstream, here, I mean anything that isn't in TripleO proper. I keep dreaming about how awesome upstream TripleO CI would be if all that effort was spent directly there instead -- and then that all work could bear fruit and trickle down downstream for free. Exactly like how we keep improving the testing coverage in puppet-openstack-integration, it's automatically pulled in RDO CI through WeIRDO for free. We make the upstream better and we benefit from it simultaneously: everyone wins. [1]: https://github.com/rdo-infra/weirdo [2]: https://github.com/rdo-infra/ansible-role-weirdo-puppet-openstack [3]: https://github.com/openstack/puppet-openstack-integration#description [4]: https://github.com/rdo-infra/ansible-role-weirdo-packstack [5]: https://github.com/openstack/packstack#packstack-integration-tests David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] On Mon, Aug 1, 2016 at 11:21 AM, Arie Bregman <abregman(a)redhat.com&gt; 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. > > 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 _______________________________________________ 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

I too am an end user and have a similar story. I had tried packstack all in one but when it was time to deploy to actual servers I looked to Ubuntu Maas. It was buggy so after a month or so of several attempts I went to RDO. And was happy when I had my environment up. But it was not reproducible. I spent months trying. And finally I looked elsewhere and was told fuel. With fuel I have ha and ceph and live migration with in 2 hours. And repeatable too And yes. When tripleo quick start showed up. I did not even look at it. Information overload? Too much time spent evaluating and too little building something productive? And now I hear of even more. In honesty with the rename of RDO to triple o is there any need for an installer? /outburst over On Aug 1, 2016 2:01 PM, "Ignacio Bravo" <ibravo(a)ltgfederal.com&gt; wrote: > If we are talking about tools, I would also want to add something with > regards to user interface of these tools. This is based on my own > experience: > > I started trying to deploy Openstack with Staypuft and The Foreman. The > UI of The Foreman was intuitive enough for the discovery and provisioning > of the servers. The OpenStack portion, not so much. > > Forward a couple of releases and we had a TripleO GUI (Tuskar, I believe) > that allowed you to graphically build your Openstack cloud. That was a > reasonable good GUI for Openstack. > > Following that, TripleO become a script based installer, that required > experience in Heat templates. I know I didn’t have it and had to ask in the > mailing list about how to present this or change that. I got a couple of > installs working with this setup. > > In the last session in Austin, my goal was to obtain information on how > others were installing Openstack. I was pointed to Fuel as an alternative. > I tried it up, and it just worked. It had the discovering capability from > The Foreman, and the configuration options from TripleO. I understand that > is based in Ansible and because of that, it is not fully CentOS ready for > all the nodes (at least not in version 9 that I tried). In any case, as a > deployer and installer, it is the most well rounded tool that I found. > > I’d love to see RDO moving into that direction, and having an easy to > use, end user ready deployer tool. > > IB > > > __ > Ignacio Bravo > LTG Federal, Inc > www.ltgfederal.com > > > On Aug 1, 2016, at 1:07 PM, David Moreau Simard <dms(a)redhat.com&gt; wrote: > > The vast majority of RDO's CI relies on using upstream > installation/deployment projects in order to test installation of RDO > packages in different ways and configurations. > > Unless I'm mistaken, TripleO Quickstart was originally created as a > mean to "easily" install TripleO in different topologies without > requiring a massive amount of hardware. > This project allows us to test TripleO in virtual deployments on just > one server instead of, say, 6. > > There's also WeIRDO [1] which was left out of your list. > WeIRDO is super simple and simply aims to run upstream gate jobs (such > as puppet-openstack-integration [2][3] and packstack [4][5]) outside > of the gate. > It'll install dependencies that are expected to be there (i.e, usually > set up by the openstack-infra gate preparation jobs), set up the trunk > repositories we're interested in testing and the rest is handled by > the upstream project testing framework. > > The WeIRDO project is /very/ low maintenance and brings an exceptional > amount of coverage and value. > This coverage is important because RDO provides OpenStack packages or > projects that are not necessarily used by TripleO and the reality is > that not everyone deploying OpenStack on CentOS with RDO will be using > TripleO. > > Anyway, sorry for sidetracking but back to the topic, thanks for > opening the discussion. > > What honestly perplexes me is the situation of CI in RDO and OSP, > especially around TripleO/Director, is the amount of work that is > spent downstream. > And by downstream, here, I mean anything that isn't in TripleO proper. > > I keep dreaming about how awesome upstream TripleO CI would be if all > that effort was spent directly there instead -- and then that all work > could bear fruit and trickle down downstream for free. > Exactly like how we keep improving the testing coverage in > puppet-openstack-integration, it's automatically pulled in RDO CI > through WeIRDO for free. > We make the upstream better and we benefit from it simultaneously: > everyone wins. > > [1]: https://github.com/rdo-infra/weirdo > [2]: https://github.com/rdo-infra/ansible-role-weirdo-puppet-openstack > [3]: > https://github.com/openstack/puppet-openstack-integration#description > [4]: https://github.com/rdo-infra/ansible-role-weirdo-packstack > [5]: https://github.com/openstack/packstack#packstack-integration-tests > > David Moreau Simard > Senior Software Engineer | Openstack RDO > > dmsimard = [irc, github, twitter] > > David Moreau Simard > Senior Software Engineer | Openstack RDO > > dmsimard = [irc, github, twitter] > > > On Mon, Aug 1, 2016 at 11:21 AM, Arie Bregman <abregman(a)redhat.com&gt; > 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. > > 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 > > > _______________________________________________ > 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 > > > > _______________________________________________ > 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 > _______________________________________________ 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

On 02/08/16 08:01, Pedro Sousa wrote: > My 2 cents here as an operator/integrator, since I've been using the > CentOS SIG repositories (mitaka) and following the RHEL Oficial > Documentation, I've managed to install several baremetal tripleo based > clouds with success. I've not tried tripleo quickstart, > > I've also tried Fuel in the past and it works pretty well with the > plugin architecture and the network validation among other things, but > still I prefer tripleo, it gives me more flexibility to setup the > network the way I want it, and using ironic to provision the baremetal > hosts is pretty cool too. Also personally I prefer to use Centos than > Ubuntu as O.S base system, I find it more stable. > > Still tripleo lacks the ease of installation that Fuel has, and an UI > would be great. Also, I'm not sure that using heat templates is the best > approach, specially when someone makes a mistake editing the yaml files > and stack returns an error. This could happen when you try to update the > overcloud nodes, scaling the compute nodes for example. It's not easy to > revert the heat stack when you make a mistake. > > There's a lot of room to improve, specially in terms of complexity of > installation and update. Maybe containers (kolla) could be a good > approach in the future? Hi Pedro, As an Operator and long time user of TripleO, I sympathise with you that the combination of heat templates and puppet are difficult to learn and don't have the mature tooling to help you understand and test how changes to the code will reflect in the real environment. One thing I will point out is that if you do a stack update that fails, more often than not it's not the end of the world. If you go on your controller plane and make sure pacemaker and all services are up and running, the state of the stack in heat on the undercloud doesn't really matter as much. This way we always try to "fail forward". If we do a bad stack update, we make sure the environment is stable again, and then push a new stack update with the fixes. Having a staging or test environment you can utilise to perform changes on first in order to identify these problems is also beneficial. We try and get all our Operators to have a virtual tripleo setup on a desktop for them to "develop" changes on, as well as a shared staging environments to do final testing of any proposed change before rolling into production. If you are interested in understanding our full development/rollout process I can go into more detail. Also kolla already supports centos/RDO, so you can head over to the kolla project and follow their documentation if you are interested in giving it a go. You are able to use Centos and RDO with containers right now, no need to wait for anything in the future. Regards, Graeme > > > > > > > > On Mon, Aug 1, 2016 at 9:45 PM, Mohammed Arafa <mohammed.arafa(a)gmail.com > <mailto:mohammed.arafa@gmail.com>> wrote: > > I too am an end user and have a similar story. I had tried packstack > all in one but when it was time to deploy to actual servers I looked > to Ubuntu Maas. It was buggy so after a month or so of several > attempts I went to RDO. And was happy when I had my environment up. > But it was not reproducible. I spent months trying. And finally I > looked elsewhere and was told fuel. > With fuel I have ha and ceph and live migration with in 2 hours. And > repeatable too > > And yes. When tripleo quick start showed up. I did not even look at > it. Information overload? Too much time spent evaluating and too > little building something productive? And now I hear of even more. > > In honesty with the rename of RDO to triple o is there any need for > an installer? > > /outburst over > > > On Aug 1, 2016 2:01 PM, "Ignacio Bravo" <ibravo(a)ltgfederal.com > <mailto:ibravo@ltgfederal.com>> wrote: > > If we are talking about tools, I would also want to add > something with regards to user interface of these tools. This is > based on my own experience: > > I started trying to deploy Openstack with Staypuft and The > Foreman. The UI of The Foreman was intuitive enough for the > discovery and provisioning of the servers. The OpenStack > portion, not so much. > > Forward a couple of releases and we had a TripleO GUI (Tuskar, I > believe) that allowed you to graphically build your Openstack > cloud. That was a reasonable good GUI for Openstack. > > Following that, TripleO become a script based installer, that > required experience in Heat templates. I know I didn’t have it > and had to ask in the mailing list about how to present this or > change that. I got a couple of installs working with this setup. > > In the last session in Austin, my goal was to obtain information > on how others were installing Openstack. I was pointed to Fuel > as an alternative. I tried it up, and it just worked. It had the > discovering capability from The Foreman, and the configuration > options from TripleO. I understand that is based in Ansible and > because of that, it is not fully CentOS ready for all the nodes > (at least not in version 9 that I tried). In any case, as a > deployer and installer, it is the most well rounded tool that I > found. > > I’d love to see RDO moving into that direction, and having an > easy to use, end user ready deployer tool. > > IB > > > __ > Ignacio Bravo > LTG Federal, Inc > www.ltgfederal.com <http://www.ltgfederal.com> > > >> On Aug 1, 2016, at 1:07 PM, David Moreau Simard >> <dms(a)redhat.com <mailto:dms@redhat.com>> wrote: >> >> The vast majority of RDO's CI relies on using upstream >> installation/deployment projects in order to test installation >> of RDO >> packages in different ways and configurations. >> >> Unless I'm mistaken, TripleO Quickstart was originally created >> as a >> mean to "easily" install TripleO in different topologies without >> requiring a massive amount of hardware. >> This project allows us to test TripleO in virtual deployments >> on just >> one server instead of, say, 6. >> >> There's also WeIRDO [1] which was left out of your list. >> WeIRDO is super simple and simply aims to run upstream gate >> jobs (such >> as puppet-openstack-integration [2][3] and packstack [4][5]) >> outside >> of the gate. >> It'll install dependencies that are expected to be there (i.e, >> usually >> set up by the openstack-infra gate preparation jobs), set up >> the trunk >> repositories we're interested in testing and the rest is >> handled by >> the upstream project testing framework. >> >> The WeIRDO project is /very/ low maintenance and brings an >> exceptional >> amount of coverage and value. >> This coverage is important because RDO provides OpenStack >> packages or >> projects that are not necessarily used by TripleO and the >> reality is >> that not everyone deploying OpenStack on CentOS with RDO will >> be using >> TripleO. >> >> Anyway, sorry for sidetracking but back to the topic, thanks for >> opening the discussion. >> >> What honestly perplexes me is the situation of CI in RDO and OSP, >> especially around TripleO/Director, is the amount of work that is >> spent downstream. >> And by downstream, here, I mean anything that isn't in TripleO >> proper. >> >> I keep dreaming about how awesome upstream TripleO CI would be >> if all >> that effort was spent directly there instead -- and then that >> all work >> could bear fruit and trickle down downstream for free. >> Exactly like how we keep improving the testing coverage in >> puppet-openstack-integration, it's automatically pulled in RDO CI >> through WeIRDO for free. >> We make the upstream better and we benefit from it simultaneously: >> everyone wins. >> >> [1]: https://github.com/rdo-infra/weirdo >> [2]: >> https://github.com/rdo-infra/ansible-role-weirdo-puppet-openstack >> [3]: >> https://github.com/openstack/puppet-openstack-integration#description >> [4]: https://github.com/rdo-infra/ansible-role-weirdo-packstack >> [5]: >> https://github.com/openstack/packstack#packstack-integration-tests >> >> David Moreau Simard >> Senior Software Engineer | Openstack RDO >> >> dmsimard = [irc, github, twitter] >> >> David Moreau Simard >> Senior Software Engineer | Openstack RDO >> >> dmsimard = [irc, github, twitter] >> >> >> On Mon, Aug 1, 2016 at 11:21 AM, Arie Bregman >> <abregman(a)redhat.com <mailto:abregman@redhat.com>> 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. >>> >>> 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 <mailto:rdo-list@redhat.com> >>> https://www.redhat.com/mailman/listinfo/rdo-list >>> >>> To unsubscribe: rdo-list-unsubscribe(a)redhat.com >>> <mailto:rdo-list-unsubscribe@redhat.com> >> >> _______________________________________________ >> rdo-list mailing list >> rdo-list(a)redhat.com <mailto:rdo-list@redhat.com> >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> To unsubscribe: rdo-list-unsubscribe(a)redhat.com >> <mailto:rdo-list-unsubscribe@redhat.com> > > > _______________________________________________ > rdo-list mailing list > rdo-list(a)redhat.com <mailto:rdo-list@redhat.com> > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe(a)redhat.com > <mailto:rdo-list-unsubscribe@redhat.com> > > > _______________________________________________ > rdo-list mailing list > rdo-list(a)redhat.com <mailto:rdo-list@redhat.com> > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe(a)redhat.com > <mailto:rdo-list-unsubscribe@redhat.com> > > > > > _______________________________________________ > 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 > -- Graeme Gillies Principal Systems Administrator Openstack Infrastructure Red Hat Australia

On 02/08/16 09:40, Pedro Sousa wrote: > HI Graeme, > > I'm more interested in following RHEL OSP approach, so I install both > Director or TripleO depending on my customers, but I'll take a close > look on Kolla. Sure thing. To be clear here, we are very interested in containers and looking at how they can currently fit into TripleO/Director. Containers are an amazing technology, but come with a lots of pros and cons for Operators, so we want to make sure we are considering them in a fashion that makes the most sense. Kolla is a great way to use them now if you are just purely interested in looking at a container based deployment. > > I have a question (I know it's out of scope) but if you can answer me, I > appreciate it. For overcloud nodes images do we still need delorean > repos? Or can we just install a clean Centos image with SIG > repositories? I want the images to be as stable as possible. For my stable RDO deployments I make sure not to use any delorean repos, and I would expect that would be the same for most people. You have two ways of doing this. Either using the pre-built stable rdo images at http://buildlogs.centos.org/centos/7/cloud/x86_64/tripleo_images/mitaka/cbs/ Which is preferred as they are what have been tested and validated by us. If you wish to build your own overcloud images using stable pacakges only, you need to do the following Manually patch the undercloud to build overcloud images using rhos-release rpm only (which utilises the stable Mitaka repo from CentOS, and nothing from RDO Trunk [delorean]). I do this by modifying the file /usr/lib/python2.7/site-packages/tripleoclient/v1/overcloud_image.py At around line 467 you will see a reference to epel, I add a new line after that to include the rdo_release DIB element to the build as well. This typically makes the file look something like http://paste.openstack.org/show/508196/ (note like 468). Then I create a directory to store my images and build them specifying the mitaka version of rdo_release. I then upload these images # mkdir ~/images # cd ~/images # export RDO_RELEASE=mitaka # openstack overcloud image build --all # openstack overcloud image upload --update-existing I'm not sure if someone else can shed some light on an easier way to build overcloud images with rdo-release and not delorean. Hope this helps, Regards, Graeme > > Thanks > > > > > > > > On Tue, Aug 2, 2016 at 12:27 AM, Graeme Gillies <ggillies(a)redhat.com > <mailto:ggillies@redhat.com>> wrote: > > On 02/08/16 08:01, Pedro Sousa wrote: > > My 2 cents here as an operator/integrator, since I've been using the > > CentOS SIG repositories (mitaka) and following the RHEL Oficial > > Documentation, I've managed to install several baremetal tripleo based > > clouds with success. I've not tried tripleo quickstart, > > > > I've also tried Fuel in the past and it works pretty well with the > > plugin architecture and the network validation among other things, but > > still I prefer tripleo, it gives me more flexibility to setup the > > network the way I want it, and using ironic to provision the baremetal > > hosts is pretty cool too. Also personally I prefer to use Centos than > > Ubuntu as O.S base system, I find it more stable. > > > > Still tripleo lacks the ease of installation that Fuel has, and an UI > > would be great. Also, I'm not sure that using heat templates is the best > > approach, specially when someone makes a mistake editing the yaml files > > and stack returns an error. This could happen when you try to update the > > overcloud nodes, scaling the compute nodes for example. It's not easy to > > revert the heat stack when you make a mistake. > > > > There's a lot of room to improve, specially in terms of complexity of > > installation and update. Maybe containers (kolla) could be a good > > approach in the future? > > Hi Pedro, > > As an Operator and long time user of TripleO, I sympathise with you that > the combination of heat templates and puppet are difficult to learn and > don't have the mature tooling to help you understand and test how > changes to the code will reflect in the real environment. > > One thing I will point out is that if you do a stack update that fails, > more often than not it's not the end of the world. If you go on your > controller plane and make sure pacemaker and all services are up and > running, the state of the stack in heat on the undercloud doesn't really > matter as much. > > This way we always try to "fail forward". If we do a bad stack update, > we make sure the environment is stable again, and then push a new stack > update with the fixes. > > Having a staging or test environment you can utilise to perform changes > on first in order to identify these problems is also beneficial. We try > and get all our Operators to have a virtual tripleo setup on a desktop > for them to "develop" changes on, as well as a shared staging > environments to do final testing of any proposed change before rolling > into production. > > If you are interested in understanding our full development/rollout > process I can go into more detail. > > Also kolla already supports centos/RDO, so you can head over to the > kolla project and follow their documentation if you are interested in > giving it a go. You are able to use Centos and RDO with containers right > now, no need to wait for anything in the future. > > Regards, > > Graeme > > > > > > > > > > > > > > > > > On Mon, Aug 1, 2016 at 9:45 PM, Mohammed Arafa < mohammed.arafa(a)gmail.com <mailto:mohammed.arafa@gmail.com> > > <mailto:mohammed.arafa@gmail.com <mailto:mohammed.arafa@gmail.com>>> wrote: > > > > I too am an end user and have a similar story. I had tried packstack > > all in one but when it was time to deploy to actual servers I looked > > to Ubuntu Maas. It was buggy so after a month or so of several > > attempts I went to RDO. And was happy when I had my environment up. > > But it was not reproducible. I spent months trying. And finally I > > looked elsewhere and was told fuel. > > With fuel I have ha and ceph and live migration with in 2 hours. And > > repeatable too > > > > And yes. When tripleo quick start showed up. I did not even look at > > it. Information overload? Too much time spent evaluating and too > > little building something productive? And now I hear of even more. > > > > In honesty with the rename of RDO to triple o is there any need for > > an installer? > > > > /outburst over > > > > > > On Aug 1, 2016 2:01 PM, "Ignacio Bravo" <ibravo(a)ltgfederal.com <mailto:ibravo@ltgfederal.com> > > <mailto:ibravo@ltgfederal.com <mailto:ibravo@ltgfederal.com>>> > wrote: > > > > If we are talking about tools, I would also want to add > > something with regards to user interface of these tools. > This is > > based on my own experience: > > > > I started trying to deploy Openstack with Staypuft and The > > Foreman. The UI of The Foreman was intuitive enough for the > > discovery and provisioning of the servers. The OpenStack > > portion, not so much. > > > > Forward a couple of releases and we had a TripleO GUI > (Tuskar, I > > believe) that allowed you to graphically build your Openstack > > cloud. That was a reasonable good GUI for Openstack. > > > > Following that, TripleO become a script based installer, that > > required experience in Heat templates. I know I didn’t have it > > and had to ask in the mailing list about how to present > this or > > change that. I got a couple of installs working with this > setup. > > > > In the last session in Austin, my goal was to obtain > information > > on how others were installing Openstack. I was pointed to Fuel > > as an alternative. I tried it up, and it just worked. It > had the > > discovering capability from The Foreman, and the configuration > > options from TripleO. I understand that is based in > Ansible and > > because of that, it is not fully CentOS ready for all the > nodes > > (at least not in version 9 that I tried). In any case, as a > > deployer and installer, it is the most well rounded tool > that I > > found. > > > > I’d love to see RDO moving into that direction, and having an > > easy to use, end user ready deployer tool. > > > > IB > > > > > > __ > > Ignacio Bravo > > LTG Federal, Inc > > www.ltgfederal.com <http://www.ltgfederal.com> > <http://www.ltgfederal.com> > > > > > >> On Aug 1, 2016, at 1:07 PM, David Moreau Simard > >> <dms(a)redhat.com <mailto:dms@redhat.com> > <mailto:dms@redhat.com <mailto:dms@redhat.com>>> wrote: > >> > >> The vast majority of RDO's CI relies on using upstream > >> installation/deployment projects in order to test > installation > >> of RDO > >> packages in different ways and configurations. > >> > >> Unless I'm mistaken, TripleO Quickstart was originally > created > >> as a > >> mean to "easily" install TripleO in different topologies > without > >> requiring a massive amount of hardware. > >> This project allows us to test TripleO in virtual deployments > >> on just > >> one server instead of, say, 6. > >> > >> There's also WeIRDO [1] which was left out of your list. > >> WeIRDO is super simple and simply aims to run upstream gate > >> jobs (such > >> as puppet-openstack-integration [2][3] and packstack [4][5]) > >> outside > >> of the gate. > >> It'll install dependencies that are expected to be there > (i.e, > >> usually > >> set up by the openstack-infra gate preparation jobs), set up > >> the trunk > >> repositories we're interested in testing and the rest is > >> handled by > >> the upstream project testing framework. > >> > >> The WeIRDO project is /very/ low maintenance and brings an > >> exceptional > >> amount of coverage and value. > >> This coverage is important because RDO provides OpenStack > >> packages or > >> projects that are not necessarily used by TripleO and the > >> reality is > >> that not everyone deploying OpenStack on CentOS with RDO will > >> be using > >> TripleO. > >> > >> Anyway, sorry for sidetracking but back to the topic, > thanks for > >> opening the discussion. > >> > >> What honestly perplexes me is the situation of CI in RDO > and OSP, > >> especially around TripleO/Director, is the amount of work > that is > >> spent downstream. > >> And by downstream, here, I mean anything that isn't in > TripleO > >> proper. > >> > >> I keep dreaming about how awesome upstream TripleO CI > would be > >> if all > >> that effort was spent directly there instead -- and then that > >> all work > >> could bear fruit and trickle down downstream for free. > >> Exactly like how we keep improving the testing coverage in > >> puppet-openstack-integration, it's automatically pulled > in RDO CI > >> through WeIRDO for free. > >> We make the upstream better and we benefit from it > simultaneously: > >> everyone wins. > >> > >> [1]: https://github.com/rdo-infra/weirdo > >> [2]: > >> > https://github.com/rdo-infra/ansible-role-weirdo-puppet-openstack > >> [3]: > >> > https://github.com/openstack/puppet-openstack-integration#description > >> [4]: > https://github.com/rdo-infra/ansible-role-weirdo-packstack > >> [5]: > >> > https://github.com/openstack/packstack#packstack-integration-tests > >> > >> David Moreau Simard > >> Senior Software Engineer | Openstack RDO > >> > >> dmsimard = [irc, github, twitter] > >> > >> David Moreau Simard > >> Senior Software Engineer | Openstack RDO > >> > >> dmsimard = [irc, github, twitter] > >> > >> > >> On Mon, Aug 1, 2016 at 11:21 AM, Arie Bregman > >> <abregman(a)redhat.com <mailto:abregman@redhat.com> > <mailto:abregman@redhat.com <mailto:abregman@redhat.com>>> 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. > >>> > >>> 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 <mailto:rdo-list@redhat.com> > <mailto:rdo-list@redhat.com <mailto:rdo-list@redhat.com>> > >>> https://www.redhat.com/mailman/listinfo/rdo-list > >>> > >>> To unsubscribe: rdo-list-unsubscribe(a)redhat.com <mailto: rdo-list-unsubscribe(a)redhat.com&gt; > >>> <mailto:rdo-list-unsubscribe@redhat.com > <mailto:rdo-list-unsubscribe@redhat.com>> > >> > >> _______________________________________________ > >> rdo-list mailing list > >> rdo-list(a)redhat.com <mailto:rdo-list@redhat.com> > <mailto:rdo-list@redhat.com <mailto:rdo-list@redhat.com>> > >> https://www.redhat.com/mailman/listinfo/rdo-list > >> > >> To unsubscribe: rdo-list-unsubscribe(a)redhat.com <mailto: rdo-list-unsubscribe(a)redhat.com&gt; > >> <mailto:rdo-list-unsubscribe@redhat.com > <mailto:rdo-list-unsubscribe@redhat.com>> > > > > > > _______________________________________________ > > rdo-list mailing list > > rdo-list(a)redhat.com <mailto:rdo-list@redhat.com> > <mailto:rdo-list@redhat.com <mailto:rdo-list@redhat.com>> > > https://www.redhat.com/mailman/listinfo/rdo-list > > > > To unsubscribe: rdo-list-unsubscribe(a)redhat.com <mailto: rdo-list-unsubscribe(a)redhat.com&gt; > > <mailto:rdo-list-unsubscribe@redhat.com > <mailto:rdo-list-unsubscribe@redhat.com>> > > > > > > _______________________________________________ > > rdo-list mailing list > > rdo-list(a)redhat.com <mailto:rdo-list@redhat.com> > <mailto:rdo-list@redhat.com <mailto:rdo-list@redhat.com>> > > https://www.redhat.com/mailman/listinfo/rdo-list > > > > To unsubscribe: rdo-list-unsubscribe(a)redhat.com <mailto: rdo-list-unsubscribe(a)redhat.com&gt; > > <mailto:rdo-list-unsubscribe@redhat.com > <mailto:rdo-list-unsubscribe@redhat.com>> > > > > > > > > > > _______________________________________________ > > rdo-list mailing list > > rdo-list(a)redhat.com <mailto:rdo-list@redhat.com> > > https://www.redhat.com/mailman/listinfo/rdo-list > > > > To unsubscribe: rdo-list-unsubscribe(a)redhat.com <mailto: rdo-list-unsubscribe(a)redhat.com&gt; > > > > > -- > Graeme Gillies > Principal Systems Administrator > Openstack Infrastructure > Red Hat Australia > > -- Graeme Gillies Principal Systems Administrator Openstack Infrastructure Red Hat Australia

I too am an end user and have a similar story. I had tried packstack all in one but when it was time to deploy to actual servers I looked to Ubuntu Maas. It was buggy so after a month or so of several attempts I went to RDO. And was happy when I had my environment up. But it was not reproducible. I spent months trying. And finally I looked elsewhere and was told fuel. With fuel I have ha and ceph and live migration with in 2 hours. And repeatable too And yes. When tripleo quick start showed up. I did not even look at it. Information overload? Too much time spent evaluating and too little building something productive? And now I hear of even more. In honesty with the rename of RDO to triple o is there any need for an installer? /outburst over

On Aug 1, 2016 2:01 PM, "Ignacio Bravo" <ibravo(a)ltgfederal.com <mailto:ibravo@ltgfederal.com>> wrote: If we are talking about tools, I would also want to add something with regards to user interface of these tools. This is based on my own experience: I started trying to deploy Openstack with Staypuft and The Foreman. The UI of The Foreman was intuitive enough for the discovery and provisioning of the servers. The OpenStack portion, not so much. Forward a couple of releases and we had a TripleO GUI (Tuskar, I believe) that allowed you to graphically build your Openstack cloud. That was a reasonable good GUI for Openstack. Following that, TripleO become a script based installer, that required experience in Heat templates. I know I didn’t have it and had to ask in the mailing list about how to present this or change that. I got a couple of installs working with this setup. In the last session in Austin, my goal was to obtain information on how others were installing Openstack. I was pointed to Fuel as an alternative. I tried it up, and it just worked. It had the discovering capability from The Foreman, and the configuration options from TripleO. I understand that is based in Ansible and because of that, it is not fully CentOS ready for all the nodes (at least not in version 9 that I tried). In any case, as a deployer and installer, it is the most well rounded tool that I found. I’d love to see RDO moving into that direction, and having an easy to use, end user ready deployer tool. IB __ Ignacio Bravo LTG Federal, Inc www.ltgfederal.com <http://www.ltgfederal.com> > On Aug 1, 2016, at 1:07 PM, David Moreau Simard <dms(a)redhat.com > <mailto:dms@redhat.com>> wrote: > > The vast majority of RDO's CI relies on using upstream > installation/deployment projects in order to test installation of RDO > packages in different ways and configurations. > > Unless I'm mistaken, TripleO Quickstart was originally created as a > mean to "easily" install TripleO in different topologies without > requiring a massive amount of hardware. > This project allows us to test TripleO in virtual deployments on just > one server instead of, say, 6. > > There's also WeIRDO [1] which was left out of your list. > WeIRDO is super simple and simply aims to run upstream gate jobs (such > as puppet-openstack-integration [2][3] and packstack [4][5]) outside > of the gate. > It'll install dependencies that are expected to be there (i.e, usually > set up by the openstack-infra gate preparation jobs), set up the trunk > repositories we're interested in testing and the rest is handled by > the upstream project testing framework. > > The WeIRDO project is /very/ low maintenance and brings an exceptional > amount of coverage and value. > This coverage is important because RDO provides OpenStack packages or > projects that are not necessarily used by TripleO and the reality is > that not everyone deploying OpenStack on CentOS with RDO will be using > TripleO. > > Anyway, sorry for sidetracking but back to the topic, thanks for > opening the discussion. > > What honestly perplexes me is the situation of CI in RDO and OSP, > especially around TripleO/Director, is the amount of work that is > spent downstream. > And by downstream, here, I mean anything that isn't in TripleO proper. > > I keep dreaming about how awesome upstream TripleO CI would be if all > that effort was spent directly there instead -- and then that all work > could bear fruit and trickle down downstream for free. > Exactly like how we keep improving the testing coverage in > puppet-openstack-integration, it's automatically pulled in RDO CI > through WeIRDO for free. > We make the upstream better and we benefit from it simultaneously: > everyone wins. > > [1]: https://github.com/rdo-infra/weirdo > [2]: https://github.com/rdo-infra/ansible-role-weirdo-puppet-openstack > [3]: > https://github.com/openstack/puppet-openstack-integration#description > [4]: https://github.com/rdo-infra/ansible-role-weirdo-packstack > [5]: > https://github.com/openstack/packstack#packstack-integration-tests > > David Moreau Simard > Senior Software Engineer | Openstack RDO > > dmsimard = [irc, github, twitter] > > David Moreau Simard > Senior Software Engineer | Openstack RDO > > dmsimard = [irc, github, twitter] > > > On Mon, Aug 1, 2016 at 11:21 AM, Arie Bregman <abregman(a)redhat.com > <mailto:abregman@redhat.com>> 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. >> >> 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 <mailto:rdo-list@redhat.com> >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> To unsubscribe: rdo-list-unsubscribe(a)redhat.com >> <mailto:rdo-list-unsubscribe@redhat.com> > > _______________________________________________ > rdo-list mailing list > rdo-list(a)redhat.com <mailto:rdo-list@redhat.com> > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe(a)redhat.com > <mailto:rdo-list-unsubscribe@redhat.com> _______________________________________________ rdo-list mailing list rdo-list(a)redhat.com <mailto:rdo-list@redhat.com> https://www.redhat.com/mailman/listinfo/rdo-list To unsubscribe: rdo-list-unsubscribe(a)redhat.com <mailto:rdo-list-unsubscribe@redhat.com> _______________________________________________ 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

does this tripleo ui integrate into horizon like tuskar did?

and if i recall correclty rdo was _renamed_ to tripleO a few months back

On Mon, Aug 1, 2016 at 7:10 PM, Graeme Gillies <ggillies(a)redhat.com <mailto:ggillies@redhat.com>> wrote: On 02/08/16 06:45, Mohammed Arafa wrote: > I too am an end user and have a similar story. I had tried packstack all > in one but when it was time to deploy to actual servers I looked to > Ubuntu Maas. It was buggy so after a month or so of several attempts I > went to RDO. And was happy when I had my environment up. But it was not > reproducible. I spent months trying. And finally I looked elsewhere and > was told fuel. > With fuel I have ha and ceph and live migration with in 2 hours. And > repeatable too > > And yes. When tripleo quick start showed up. I did not even look at it. > Information overload? Too much time spent evaluating and too little > building something productive? And now I hear of even more. > > In honesty with the rename of RDO to triple o is there any need for an > installer? > > /outburst over Hi, Just to clear up some confusion here, RDO and TripleO are two very different things. RDO Is an RPM distribution of Openstack that aims to track upstream Openstack as closely as possible. We provide stable RPM trees for the current stable releases of Openstack, as well as RPM trees of the latest Openstack code as it's committed upstream (through DLRN). You can deploy and manage Openstack with RDO however you would like including puppet, chef, ansible, saltstack, and RDO also works with some of the complete installer projects like TripleO and even kolla (you can see the containers created by kolla have centos/RDO options at [1]). TripleO is an Openstack project which Red Hat is largely involved in, and aims to make an Openstack installer using Openstack itself. It currently works best with RDO because that's where most of our effort is focussed, but there is no technical reason it can't work with other distros or Operating systems. Both of these pieces go into our downstream commercial Offering. RDO becomes Red Hat Openstack Platform, while TripleO becomes RHOS Director. If you wish to consume RDO there is no reason for you to be forced to use TripleO, and are welcome to use any other deployment method or tool. We welcome people expanding RDO by utilising it however they please, deploying it however they like. I would love to hear from more people in the community who are using RDO and not using the default packstack/TripleO installers, as it allows us to get a better understanding of users needs, and helps us learn more about what tools and workflows work best for people. Regards, Graeme [1] https://hub.docker.com/u/kolla/ > > > On Aug 1, 2016 2:01 PM, "Ignacio Bravo" <ibravo(a)ltgfederal.com <mailto:ibravo@ltgfederal.com> > <mailto:ibravo@ltgfederal.com <mailto:ibravo@ltgfederal.com>>> wrote: > > If we are talking about tools, I would also want to add something > with regards to user interface of these tools. This is based on my > own experience: > > I started trying to deploy Openstack with Staypuft and The Foreman. > The UI of The Foreman was intuitive enough for the discovery and > provisioning of the servers. The OpenStack portion, not so much. > > Forward a couple of releases and we had a TripleO GUI (Tuskar, I > believe) that allowed you to graphically build your Openstack cloud. > That was a reasonable good GUI for Openstack. > > Following that, TripleO become a script based installer, that > required experience in Heat templates. I know I didn’t have it and > had to ask in the mailing list about how to present this or change > that. I got a couple of installs working with this setup. > > In the last session in Austin, my goal was to obtain information on > how others were installing Openstack. I was pointed to Fuel as an > alternative. I tried it up, and it just worked. It had the > discovering capability from The Foreman, and the configuration > options from TripleO. I understand that is based in Ansible and > because of that, it is not fully CentOS ready for all the nodes (at > least not in version 9 that I tried). In any case, as a deployer and > installer, it is the most well rounded tool that I found. > > I’d love to see RDO moving into that direction, and having an easy > to use, end user ready deployer tool. > > IB > > > __ > Ignacio Bravo > LTG Federal, Inc > www.ltgfederal.com <http://www.ltgfederal.com> <http://www.ltgfederal.com> > > >> On Aug 1, 2016, at 1:07 PM, David Moreau Simard <dms(a)redhat.com <mailto:dms@redhat.com> >> <mailto:dms@redhat.com <mailto:dms@redhat.com>>> wrote: >> >> The vast majority of RDO's CI relies on using upstream >> installation/deployment projects in order to test installation of RDO >> packages in different ways and configurations. >> >> Unless I'm mistaken, TripleO Quickstart was originally created as a >> mean to "easily" install TripleO in different topologies without >> requiring a massive amount of hardware. >> This project allows us to test TripleO in virtual deployments on just >> one server instead of, say, 6. >> >> There's also WeIRDO [1] which was left out of your list. >> WeIRDO is super simple and simply aims to run upstream gate jobs (such >> as puppet-openstack-integration [2][3] and packstack [4][5]) outside >> of the gate. >> It'll install dependencies that are expected to be there (i.e, usually >> set up by the openstack-infra gate preparation jobs), set up the trunk >> repositories we're interested in testing and the rest is handled by >> the upstream project testing framework. >> >> The WeIRDO project is /very/ low maintenance and brings an exceptional >> amount of coverage and value. >> This coverage is important because RDO provides OpenStack packages or >> projects that are not necessarily used by TripleO and the reality is >> that not everyone deploying OpenStack on CentOS with RDO will be using >> TripleO. >> >> Anyway, sorry for sidetracking but back to the topic, thanks for >> opening the discussion. >> >> What honestly perplexes me is the situation of CI in RDO and OSP, >> especially around TripleO/Director, is the amount of work that is >> spent downstream. >> And by downstream, here, I mean anything that isn't in TripleO proper. >> >> I keep dreaming about how awesome upstream TripleO CI would be if all >> that effort was spent directly there instead -- and then that all work >> could bear fruit and trickle down downstream for free. >> Exactly like how we keep improving the testing coverage in >> puppet-openstack-integration, it's automatically pulled in RDO CI >> through WeIRDO for free. >> We make the upstream better and we benefit from it simultaneously: >> everyone wins. >> >> [1]: https://github.com/rdo-infra/weirdo >> [2]: https://github.com/rdo-infra/ansible-role-weirdo-puppet-openstack >> [3]: >> https://github.com/openstack/puppet-openstack-integration#description >> [4]: https://github.com/rdo-infra/ansible-role-weirdo-packstack >> [5]: >> https://github.com/openstack/packstack#packstack-integration-tests >> >> David Moreau Simard >> Senior Software Engineer | Openstack RDO >> >> dmsimard = [irc, github, twitter] >> >> David Moreau Simard >> Senior Software Engineer | Openstack RDO >> >> dmsimard = [irc, github, twitter] >> >> >> On Mon, Aug 1, 2016 at 11:21 AM, Arie Bregman <abregman(a)redhat.com <mailto:abregman@redhat.com> >> <mailto:abregman@redhat.com <mailto:abregman@redhat.com>>> 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. >>> >>> 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 <mailto:rdo-list@redhat.com> <mailto:rdo-list@redhat.com <mailto:rdo-list@redhat.com>> >>> https://www.redhat.com/mailman/listinfo/rdo-list >>> >>> To unsubscribe: rdo-list-unsubscribe(a)redhat.com <mailto:rdo-list-unsubscribe@redhat.com> >>> <mailto:rdo-list-unsubscribe@redhat.com <mailto:rdo-list-unsubscribe@redhat.com>> >> >> _______________________________________________ >> rdo-list mailing list >> rdo-list(a)redhat.com <mailto:rdo-list@redhat.com> <mailto:rdo-list@redhat.com <mailto:rdo-list@redhat.com>> >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> To unsubscribe: rdo-list-unsubscribe(a)redhat.com <mailto:rdo-list-unsubscribe@redhat.com> >> <mailto:rdo-list-unsubscribe@redhat.com <mailto:rdo-list-unsubscribe@redhat.com>> > > > _______________________________________________ > rdo-list mailing list > rdo-list(a)redhat.com <mailto:rdo-list@redhat.com> <mailto:rdo-list@redhat.com <mailto:rdo-list@redhat.com>> > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe(a)redhat.com <mailto:rdo-list-unsubscribe@redhat.com> > <mailto:rdo-list-unsubscribe@redhat.com <mailto:rdo-list-unsubscribe@redhat.com>> > > > > _______________________________________________ > rdo-list mailing list > rdo-list(a)redhat.com <mailto:rdo-list@redhat.com> > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe(a)redhat.com <mailto:rdo-list-unsubscribe@redhat.com> > -- Graeme Gillies Principal Systems Administrator Openstack Infrastructure Red Hat Australia -- <https://candidate.peoplecert.org/ReportsLink.aspx?argType=1&id=13D642... *805010942448935* <https://www.redhat.com/wapps/training/certification/verify.html?certNumbe... *GR750055912MA* <https://candidate.peoplecert.org/ReportsLink.aspx?argType=1&id=13D642... *Link to me on LinkedIn <http://www.linkedin.com/in/mohammedarafa>*

If we are talking about tools, I would also want to add something with regards to user interface of these tools. This is based on my own experience: I started trying to deploy Openstack with Staypuft and The Foreman. The UI of The Foreman was intuitive enough for the discovery and provisioning of the servers. The OpenStack portion, not so much.

Forward a couple of releases and we had a TripleO GUI (Tuskar, I believe) that allowed you to graphically build your Openstack cloud. That was a reasonable good GUI for Openstack.

Following that, TripleO become a script based installer, that required experience in Heat templates. I know I didn’t have it and had to ask in the mailing list about how to present this or change that. I got a couple of installs working with this setup.

In the last session in Austin, my goal was to obtain information on how others were installing Openstack. I was pointed to Fuel as an alternative. I tried it up, and it just worked. It had the discovering capability from The Foreman, and the configuration options from TripleO. I understand that is based in Ansible and because of that, it is not fully CentOS ready for all the nodes (at least not in version 9 that I tried). In any case, as a deployer and installer, it is the most well rounded tool that I found.

I’d love to see RDO moving into that direction, and having an easy to use, end user ready deployer tool.

IB __ Ignacio Bravo LTG Federal, Inc www.ltgfederal.com > On Aug 1, 2016, at 1:07 PM, David Moreau Simard <dms(a)redhat.com&gt; > wrote: > > The vast majority of RDO's CI relies on using upstream > installation/deployment projects in order to test installation of > RDO > packages in different ways and configurations. > > Unless I'm mistaken, TripleO Quickstart was originally created as a > mean to "easily" install TripleO in different topologies without > requiring a massive amount of hardware. > This project allows us to test TripleO in virtual deployments on > just > one server instead of, say, 6. > > There's also WeIRDO [1] which was left out of your list. > WeIRDO is super simple and simply aims to run upstream gate jobs > (such > as puppet-openstack-integration [2][3] and packstack [4][5]) > outside > of the gate. > It'll install dependencies that are expected to be there (i.e, > usually > set up by the openstack-infra gate preparation jobs), set up the > trunk > repositories we're interested in testing and the rest is handled by > the upstream project testing framework. > > The WeIRDO project is /very/ low maintenance and brings an > exceptional > amount of coverage and value. > This coverage is important because RDO provides OpenStack packages > or > projects that are not necessarily used by TripleO and the reality > is > that not everyone deploying OpenStack on CentOS with RDO will be > using > TripleO. > > Anyway, sorry for sidetracking but back to the topic, thanks for > opening the discussion. > > What honestly perplexes me is the situation of CI in RDO and OSP, > especially around TripleO/Director, is the amount of work that is > spent downstream. > And by downstream, here, I mean anything that isn't in TripleO > proper. > > I keep dreaming about how awesome upstream TripleO CI would be if > all > that effort was spent directly there instead -- and then that all > work > could bear fruit and trickle down downstream for free. > Exactly like how we keep improving the testing coverage in > puppet-openstack-integration, it's automatically pulled in RDO CI > through WeIRDO for free. > We make the upstream better and we benefit from it simultaneously: > everyone wins. > > [1]: https://github.com/rdo-infra/weirdo > [2]: https://github.com/rdo-infra/ansible-role-weirdo-puppet-openst > ack > [3]: https://github.com/openstack/puppet-openstack-integration#desc > ription > [4]: https://github.com/rdo-infra/ansible-role-weirdo-packstack > [5]: https://github.com/openstack/packstack#packstack-integration-t > ests > > David Moreau Simard > Senior Software Engineer | Openstack RDO > > dmsimard = [irc, github, twitter] > > David Moreau Simard > Senior Software Engineer | Openstack RDO > > dmsimard = [irc, github, twitter] > > > On Mon, Aug 1, 2016 at 11:21 AM, Arie Bregman <abregman(a)redhat.com&gt; > 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. > > > > 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=ansi > > ble-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 > _______________________________________________ > 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

It became a discussion around the official installer and how to improve it. While it's an important discussion, no doubt, I actually want to focus on our automation and CI tools. Since I see there is an agreement that collaboration does make sense here, let's move to the hard questions :) Wes, Tal - there is huge difference right now between infrared and tripleo-quickstart in their structure. One is all-in-one project and the other one is multiple micro projects managed by one project. Do you think there is a way to consolidate or move to a different model which will make sense for both RDO and RHOSP? something that both groups can work on.

Raoul - I totally agree with you, especially with "difficult for anyone to start contributing and collaborate". This is exactly why this discussion started. If we can agree on one set of tools, it will make everyone's life easier - current groups, new contributors, folks that just want to deploy TripleO quickly. But I'm afraid some sacrifices need to be made by both groups. David - I thought WeiRDO is used only for packstack, so I apologize I didn't include it. It does sound like an anther testing project, is there a place to merge it with another existing testing project? like Octario for example or one of TripleO testing projects. Or does it make sense to keep it a standalone project? On Tue, Aug 2, 2016 at 11:12 AM, Christopher Brown <cbrown2(a)ocf.co.uk&gt; wrote: > Hello RDOistas (I think that is the expression?), > > Another year, another OpenStack deployment tool. :) > > On Mon, 2016-08-01 at 18:59 +0100, Ignacio Bravo wrote: >> If we are talking about tools, I would also want to add something >> with regards to user interface of these tools. This is based on my >> own experience: >> >> I started trying to deploy Openstack with Staypuft and The Foreman. >> The UI of The Foreman was intuitive enough for the discovery and >> provisioning of the servers. The OpenStack portion, not so much. > > This is exactly mine also. I think this works really well in very large > enterprise environments where you need to split out services over more > than three controllers. You do need good in-house puppet skills though > so better for enterprise with a good sysadmin team. > >> Forward a couple of releases and we had a TripleO GUI (Tuskar, I >> believe) that allowed you to graphically build your Openstack cloud. >> That was a reasonable good GUI for Openstack. > > Well, I found it barely usable. It was only ever good as a graphical > representiation of what the build was doing. Interacting with it was > not great. > >> Following that, TripleO become a script based installer, that >> required experience in Heat templates. I know I didn’t have it and >> had to ask in the mailing list about how to present this or change >> that. I got a couple of installs working with this setup. > > Works well now that I understand all the foibles and have invested time > into understanding heat templates and puppet modules. Its good in that > it forces you to learn about orchestration which is such an important > end-goal of cloud environments. > >> In the last session in Austin, my goal was to obtain information on >> how others were installing Openstack. I was pointed to Fuel as an >> alternative. I tried it up, and it just worked. It had the >> discovering capability from The Foreman, and the configuration >> options from TripleO. I understand that is based in Ansible and >> because of that, it is not fully CentOS ready for all the nodes (at >> least not in version 9 that I tried). In any case, as a deployer and >> installer, it is the most well rounded tool that I found. > > This is interesting to know. I've heard of Fuel of course but there are > some politics involved - it still has the team:single-vendor tag but > from what I see Mirantis are very keen for it to become the default > OpenStack installer. I don't think being Ansible-based should be a > problem - we are deploying OpenShift on OpenStack which uses Openshift- > ansible - this recently moved to Ansible 2.1 without too much > disruption. > >> I’d love to see RDO moving into that direction, and having an easy to >> use, end user ready deployer tool. > > If its as good as you say its definitely worth evaluating. From our > point of view, we want to be able to add services to the pacemaker > cluster with some ease - for example Magnum and Sahara - and it looks > like there are steps being taken with regards to composable roles and > simplification of the pacemaker cluster to just core services. > > But if someone can explain that better I would appreciate it. > > Regards > >> IB >> >> >> __ >> Ignacio Bravo >> LTG Federal, Inc >> www.ltgfederal.com >> >> >> > On Aug 1, 2016, at 1:07 PM, David Moreau Simard <dms(a)redhat.com&gt; >> > wrote: >> > >> > The vast majority of RDO's CI relies on using upstream >> > installation/deployment projects in order to test installation of >> > RDO >> > packages in different ways and configurations. >> > >> > Unless I'm mistaken, TripleO Quickstart was originally created as a >> > mean to "easily" install TripleO in different topologies without >> > requiring a massive amount of hardware. >> > This project allows us to test TripleO in virtual deployments on >> > just >> > one server instead of, say, 6. >> > >> > There's also WeIRDO [1] which was left out of your list. >> > WeIRDO is super simple and simply aims to run upstream gate jobs >> > (such >> > as puppet-openstack-integration [2][3] and packstack [4][5]) >> > outside >> > of the gate. >> > It'll install dependencies that are expected to be there (i.e, >> > usually >> > set up by the openstack-infra gate preparation jobs), set up the >> > trunk >> > repositories we're interested in testing and the rest is handled by >> > the upstream project testing framework. >> > >> > The WeIRDO project is /very/ low maintenance and brings an >> > exceptional >> > amount of coverage and value. >> > This coverage is important because RDO provides OpenStack packages >> > or >> > projects that are not necessarily used by TripleO and the reality >> > is >> > that not everyone deploying OpenStack on CentOS with RDO will be >> > using >> > TripleO. >> > >> > Anyway, sorry for sidetracking but back to the topic, thanks for >> > opening the discussion. >> > >> > What honestly perplexes me is the situation of CI in RDO and OSP, >> > especially around TripleO/Director, is the amount of work that is >> > spent downstream. >> > And by downstream, here, I mean anything that isn't in TripleO >> > proper. >> > >> > I keep dreaming about how awesome upstream TripleO CI would be if >> > all >> > that effort was spent directly there instead -- and then that all >> > work >> > could bear fruit and trickle down downstream for free. >> > Exactly like how we keep improving the testing coverage in >> > puppet-openstack-integration, it's automatically pulled in RDO CI >> > through WeIRDO for free. >> > We make the upstream better and we benefit from it simultaneously: >> > everyone wins. >> > >> > [1]: https://github.com/rdo-infra/weirdo >> > [2]: https://github.com/rdo-infra/ansible-role-weirdo-puppet-openst >> > ack >> > [3]: https://github.com/openstack/puppet-openstack-integration#desc >> > ription >> > [4]: https://github.com/rdo-infra/ansible-role-weirdo-packstack >> > [5]: https://github.com/openstack/packstack#packstack-integration-t >> > ests >> > >> > David Moreau Simard >> > Senior Software Engineer | Openstack RDO >> > >> > dmsimard = [irc, github, twitter] >> > >> > David Moreau Simard >> > Senior Software Engineer | Openstack RDO >> > >> > dmsimard = [irc, github, twitter] >> > >> > >> > On Mon, Aug 1, 2016 at 11:21 AM, Arie Bregman <abregman(a)redhat.com&gt; >> > 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. >> > > >> > > 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=ansi >> > > ble-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 >> > _______________________________________________ >> > 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 >> > -- > Regards, > > Christopher Brown > OpenStack Engineer > OCF plc > > Tel: +44 (0)114 257 2200 > Web: www.ocf.co.uk > Blog: blog.ocf.co.uk > Twitter: @ocfplc > > Please note, any emails relating to an OCF Support request must always > be sent to support(a)ocf.co.uk for a ticket number to be generated or > existing support ticket to be updated. Should this not be done then OCF > cannot be held responsible for requests not dealt with in a timely > manner. > > OCF plc is a company registered in England and Wales. Registered number > 4132533, VAT number GB 780 6803 14. Registered office address: OCF plc, > 5 Rotunda Business Centre, Thorncliffe Park, Chapeltown, Sheffield S35 > 2PG. > > This message is private and confidential. If you have received this > message in error, please notify us immediately and remove it from your > system. > > _______________________________________________ > 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 -- Arie Bregman Red Hat Israel Component CI: https://mojo.redhat.com/groups/rhos-core-ci/overview

On Tue, Aug 2, 2016 at 3:53 PM, Wesley Hayutin <whayutin(a)redhat.com&gt; wrote: > > > On Tue, Aug 2, 2016 at 4:58 AM, Arie Bregman <abregman(a)redhat.com&gt; wrote: >> >> It became a discussion around the official installer and how to >> improve it. While it's an important discussion, no doubt, I actually >> want to focus on our automation and CI tools. >> >> Since I see there is an agreement that collaboration does make sense >> here, let's move to the hard questions :) >> >> Wes, Tal - there is huge difference right now between infrared and >> tripleo-quickstart in their structure. One is all-in-one project and >> the other one is multiple micro projects managed by one project. Do >> you think there is a way to consolidate or move to a different model >> which will make sense for both RDO and RHOSP? something that both >> groups can work on. > > > 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. > 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. > I can help facilitate a discussion but oooq is an upstream tripleo tool that > replaces instack-virt-setup [1]. > It also happens to be a great tool for easily deploying TripleO end to end > [3] > > What I *can* do is show everyone how to manipulate tripleo-quickstart and > customize it with composable ansible roles, templates, settings etc.. > 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]. > These 3rd party roles can be free and opensource or internal only, it works > either way. > This was discussed in depth as part of the production chain meetings, the > message may have been lost unfortunately. > > I hope this resets your expectations of what I can and can not do as part of > these discussions. > Let me know where and when and I'm happy to be part of the discussion. Thanks for clarifying :) Next reasonable step would probably be to propose some sort of blueprint for tripleo-quickstart to include some of InfraRed features and by that have one tool driven by upstream development that can be either cloned downstream or used as it is with an internal data project.

OR have InfraRed pushed into tripleo/openstack namespace and expose it to the RDO community (without internal data of course). Personally, I really like the pluggable[1] structure (which allows it to actually consume tripleo-quickstart) so I'm not sure if it can be really merged with tripleo-quickstart as proposed in the first option.

I like the second option, although it still forces us to have two tools, but after a period of time, I believe it will be clear what the community prefers, which will allow us to remove one of the projects eventually. So, unless there are other ideas, I think the next move should be made by Tal. Tal, I'm willing to help with whatever is needed. [1] http://infrared.readthedocs.io/en/latest > > Thanks > > [1] https://blueprints.launchpad.net/tripleo/+spec/tripleo-quickstart > [2] > https://github.com/redhat-openstack/?utf8=%E2%9C%93&query=ansible-rol... > [3[ https://www.rdoproject.org/tripleo/ > > >> >> >> Raoul - I totally agree with you, especially with "difficult for >> anyone to start contributing and collaborate". This is exactly why >> this discussion started. If we can agree on one set of tools, it will >> make everyone's life easier - current groups, new contributors, folks >> that just want to deploy TripleO quickly. But I'm afraid some >> sacrifices need to be made by both groups. >> >> David - I thought WeiRDO is used only for packstack, so I apologize I >> didn't include it. It does sound like an anther testing project, is >> there a place to merge it with another existing testing project? like >> Octario for example or one of TripleO testing projects. Or does it >> make sense to keep it a standalone project? >> >> >> >> >> On Tue, Aug 2, 2016 at 11:12 AM, Christopher Brown <cbrown2(a)ocf.co.uk&gt; >> wrote: >> > Hello RDOistas (I think that is the expression?), >> > >> > Another year, another OpenStack deployment tool. :) >> > >> > On Mon, 2016-08-01 at 18:59 +0100, Ignacio Bravo wrote: >> >> If we are talking about tools, I would also want to add something >> >> with regards to user interface of these tools. This is based on my >> >> own experience: >> >> >> >> I started trying to deploy Openstack with Staypuft and The Foreman. >> >> The UI of The Foreman was intuitive enough for the discovery and >> >> provisioning of the servers. The OpenStack portion, not so much. >> > >> > This is exactly mine also. I think this works really well in very large >> > enterprise environments where you need to split out services over more >> > than three controllers. You do need good in-house puppet skills though >> > so better for enterprise with a good sysadmin team. >> > >> >> Forward a couple of releases and we had a TripleO GUI (Tuskar, I >> >> believe) that allowed you to graphically build your Openstack cloud. >> >> That was a reasonable good GUI for Openstack. >> > >> > Well, I found it barely usable. It was only ever good as a graphical >> > representiation of what the build was doing. Interacting with it was >> > not great. >> > >> >> Following that, TripleO become a script based installer, that >> >> required experience in Heat templates. I know I didn’t have it and >> >> had to ask in the mailing list about how to present this or change >> >> that. I got a couple of installs working with this setup. >> > >> > Works well now that I understand all the foibles and have invested time >> > into understanding heat templates and puppet modules. Its good in that >> > it forces you to learn about orchestration which is such an important >> > end-goal of cloud environments. >> > >> >> In the last session in Austin, my goal was to obtain information on >> >> how others were installing Openstack. I was pointed to Fuel as an >> >> alternative. I tried it up, and it just worked. It had the >> >> discovering capability from The Foreman, and the configuration >> >> options from TripleO. I understand that is based in Ansible and >> >> because of that, it is not fully CentOS ready for all the nodes (at >> >> least not in version 9 that I tried). In any case, as a deployer and >> >> installer, it is the most well rounded tool that I found. >> > >> > This is interesting to know. I've heard of Fuel of course but there are >> > some politics involved - it still has the team:single-vendor tag but >> > from what I see Mirantis are very keen for it to become the default >> > OpenStack installer. I don't think being Ansible-based should be a >> > problem - we are deploying OpenShift on OpenStack which uses Openshift- >> > ansible - this recently moved to Ansible 2.1 without too much >> > disruption. >> > >> >> I’d love to see RDO moving into that direction, and having an easy to >> >> use, end user ready deployer tool. >> > >> > If its as good as you say its definitely worth evaluating. From our >> > point of view, we want to be able to add services to the pacemaker >> > cluster with some ease - for example Magnum and Sahara - and it looks >> > like there are steps being taken with regards to composable roles and >> > simplification of the pacemaker cluster to just core services. >> > >> > But if someone can explain that better I would appreciate it. >> > >> > Regards >> > >> >> IB >> >> >> >> >> >> __ >> >> Ignacio Bravo >> >> LTG Federal, Inc >> >> www.ltgfederal.com >> >> >> >> >> >> > On Aug 1, 2016, at 1:07 PM, David Moreau Simard <dms(a)redhat.com&gt; >> >> > wrote: >> >> > >> >> > The vast majority of RDO's CI relies on using upstream >> >> > installation/deployment projects in order to test installation of >> >> > RDO >> >> > packages in different ways and configurations. >> >> > >> >> > Unless I'm mistaken, TripleO Quickstart was originally created as a >> >> > mean to "easily" install TripleO in different topologies without >> >> > requiring a massive amount of hardware. >> >> > This project allows us to test TripleO in virtual deployments on >> >> > just >> >> > one server instead of, say, 6. >> >> > >> >> > There's also WeIRDO [1] which was left out of your list. >> >> > WeIRDO is super simple and simply aims to run upstream gate jobs >> >> > (such >> >> > as puppet-openstack-integration [2][3] and packstack [4][5]) >> >> > outside >> >> > of the gate. >> >> > It'll install dependencies that are expected to be there (i.e, >> >> > usually >> >> > set up by the openstack-infra gate preparation jobs), set up the >> >> > trunk >> >> > repositories we're interested in testing and the rest is handled by >> >> > the upstream project testing framework. >> >> > >> >> > The WeIRDO project is /very/ low maintenance and brings an >> >> > exceptional >> >> > amount of coverage and value. >> >> > This coverage is important because RDO provides OpenStack packages >> >> > or >> >> > projects that are not necessarily used by TripleO and the reality >> >> > is >> >> > that not everyone deploying OpenStack on CentOS with RDO will be >> >> > using >> >> > TripleO. >> >> > >> >> > Anyway, sorry for sidetracking but back to the topic, thanks for >> >> > opening the discussion. >> >> > >> >> > What honestly perplexes me is the situation of CI in RDO and OSP, >> >> > especially around TripleO/Director, is the amount of work that is >> >> > spent downstream. >> >> > And by downstream, here, I mean anything that isn't in TripleO >> >> > proper. >> >> > >> >> > I keep dreaming about how awesome upstream TripleO CI would be if >> >> > all >> >> > that effort was spent directly there instead -- and then that all >> >> > work >> >> > could bear fruit and trickle down downstream for free. >> >> > Exactly like how we keep improving the testing coverage in >> >> > puppet-openstack-integration, it's automatically pulled in RDO CI >> >> > through WeIRDO for free. >> >> > We make the upstream better and we benefit from it simultaneously: >> >> > everyone wins. >> >> > >> >> > [1]: https://github.com/rdo-infra/weirdo >> >> > [2]: https://github.com/rdo-infra/ansible-role-weirdo-puppet-openst >> >> > ack >> >> > [3]: https://github.com/openstack/puppet-openstack-integration#desc >> >> > ription >> >> > [4]: https://github.com/rdo-infra/ansible-role-weirdo-packstack >> >> > [5]: https://github.com/openstack/packstack#packstack-integration-t >> >> > ests >> >> > >> >> > David Moreau Simard >> >> > Senior Software Engineer | Openstack RDO >> >> > >> >> > dmsimard = [irc, github, twitter] >> >> > >> >> > David Moreau Simard >> >> > Senior Software Engineer | Openstack RDO >> >> > >> >> > dmsimard = [irc, github, twitter] >> >> > >> >> > >> >> > On Mon, Aug 1, 2016 at 11:21 AM, Arie Bregman <abregman(a)redhat.com > >> >> > 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. >> >> > > >> >> > > 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=ansi >> >> > > ble-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 >> >> > _______________________________________________ >> >> > 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 >> >> >> > -- >> > Regards, >> > >> > Christopher Brown >> > OpenStack Engineer >> > OCF plc >> > >> > Tel: +44 (0)114 257 2200 >> > Web: www.ocf.co.uk >> > Blog: blog.ocf.co.uk >> > Twitter: @ocfplc >> > >> > Please note, any emails relating to an OCF Support request must always >> > be sent to support(a)ocf.co.uk for a ticket number to be generated or >> > existing support ticket to be updated. Should this not be done then OCF >> > cannot be held responsible for requests not dealt with in a timely >> > manner. >> > >> > OCF plc is a company registered in England and Wales. Registered number >> > 4132533, VAT number GB 780 6803 14. Registered office address: OCF plc, >> > 5 Rotunda Business Centre, Thorncliffe Park, Chapeltown, Sheffield S35 >> > 2PG. >> > >> > This message is private and confidential. If you have received this >> > message in error, please notify us immediately and remove it from your >> > system. >> > >> > _______________________________________________ >> > 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 >> >> >> >> -- >> Arie Bregman >> Red Hat Israel >> Component CI: https://mojo.redhat.com/groups/rhos-core-ci/overview > > -- Arie Bregman Red Hat Israel Component CI: https://mojo.redhat.com/groups/rhos-core-ci/overview

Thanks Arie for starting this discussion! (and sorry for joining in late) 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 :) ). 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). 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) 1 undercloud on RHEL 7 with 16GB of ram + 60GB of HDD with 3 network interfaces. 3 controllers on Centos 7 with 8GB of ram + 40GB of HDD 2 compute on Centos 7 with 6GB of ram + 60GB HDD 3 ceph nodes on RHEL 7 with 4GB of ram + 2 HDD one with 20GB + one with 40GB Example usage: (setting up the above VMs with four different HW specs) ir-provisioner virsh --host-address=<host.address> --host-key=<host.private.key> --topology-nodes=undercloud:1,controller:3,compute:2,ceph:3 *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. The installation of Openstack is done with a dedicated tool called `ir-installer` (next) 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. 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. 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 :) More info about InfraRed can be found here[1] (though I must admit that we still need some "love" around our docs) [1] - http://infrared.readthedocs.io/en/latest/

On Tue, Aug 2, 2016 at 9:52 PM, Wesley Hayutin <whayutin(a)redhat.com&gt; wrote: > > > On Tue, Aug 2, 2016 at 1:51 PM, Arie Bregman <abregman(a)redhat.com&gt; wrote: > >> On Tue, Aug 2, 2016 at 3:53 PM, Wesley Hayutin <whayutin(a)redhat.com&gt; >> wrote: >> > >> > >> > On Tue, Aug 2, 2016 at 4:58 AM, Arie Bregman <abregman(a)redhat.com&gt; >> wrote: >> >> >> >> It became a discussion around the official installer and how to >> >> improve it. While it's an important discussion, no doubt, I actually >> >> want to focus on our automation and CI tools. >> >> >> >> Since I see there is an agreement that collaboration does make sense >> >> here, let's move to the hard questions :) >> >> >> >> Wes, Tal - there is huge difference right now between infrared and >> >> tripleo-quickstart in their structure. One is all-in-one project and >> >> the other one is multiple micro projects managed by one project. Do >> >> you think there is a way to consolidate or move to a different model >> >> which will make sense for both RDO and RHOSP? something that both >> >> groups can work on. >> > >> > >> > 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. >> > 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. >> > I can help facilitate a discussion but oooq is an upstream tripleo >> tool that >> > replaces instack-virt-setup [1]. >> > It also happens to be a great tool for easily deploying TripleO end to >> end >> > [3] >> > >> > What I *can* do is show everyone how to manipulate tripleo-quickstart >> and >> > customize it with composable ansible roles, templates, settings etc.. >> > 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]. >> > These 3rd party roles can be free and opensource or internal only, it >> works >> > either way. >> > This was discussed in depth as part of the production chain meetings, >> the >> > message may have been lost unfortunately. >> > >> > I hope this resets your expectations of what I can and can not do as >> part of >> > these discussions. >> > Let me know where and when and I'm happy to be part of the discussion. >> >> Thanks for clarifying :) >> >> Next reasonable step would probably be to propose some sort of >> blueprint for tripleo-quickstart to include some of InfraRed features >> and by that have one tool driven by upstream development that can be >> either cloned downstream or used as it is with an internal data >> project. >> > > Sure.. a blueprint would help everyone understand the feature and the > motivation. > You could also just plug in the feature you are looking for to oooq and > see if it meets > your requirements. See below. > 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. > > >> >> OR >> >> have InfraRed pushed into tripleo/openstack namespace and expose it to >> the RDO community (without internal data of course). Personally, I >> really like the pluggable[1] structure (which allows it to actually >> consume tripleo-quickstart) so I'm not sure if it can be really merged >> with tripleo-quickstart as proposed in the first option. >> > 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. A second benefit might be that by introducing a new concept / design we can take what is best from two worlds and improve. I would love to see an open discussion on the tool upstream and how we can improve the overall process. > The way oooq is built one can plugin or override any part at run time > with custom playbooks, roles, and config. There isn't anything that > needs to be > checked in directly to oooq to use it. > > It's designed such that third parties can make their own decisions to use > something > native to quickstart, something from our role library, or something > completely independent. > This allows teams, individuals or whom ever to do what they need to with > out having to fork or re-roll the entire framework. > > The important step is to note that these 3rd party roles or (oooq-extras) > incubate, mature and then graduate to github/openstack. > The upstream openstack community should lead, evaluate, and via > blueprints vote on the canonical CI tool set. > > We can record a demonstration if required, but there is nothing stopping > anyone right now from > doing this today. I'm just browsing the role library for an example, I > had no idea [1] existed. > Looks like Raoul had a requirement and just made it work. > > Justin, from the browbeat project has graciously created some > documentation regarding 3rd party roles. > It has yet to merge, but it should help illustrate how these roles are > used. [2] > > Thanks Arie for leading the discussion. > > [1] > https://github.com/redhat-openstack/ansible-role-tripleo-overcloud-valida... > [2] https://review.openstack.org/#/c/346733/ > > > > > > >> >> I like the second option, although it still forces us to have two >> tools, but after a period of time, I believe it will be clear what the >> community prefers, which will allow us to remove one of the projects >> eventually. >> >> So, unless there are other ideas, I think the next move should be made >> by Tal. >> >> Tal, I'm willing to help with whatever is needed. >> > 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. > >> [1] http://infrared.readthedocs.io/en/latest >> >> > >> > Thanks >> > >> > [1] https://blueprints.launchpad.net/tripleo/+spec/tripleo-quickstart >> > [2] >> > >> https://github.com/redhat-openstack/?utf8=%E2%9C%93&query=ansible-rol... >> > [3[ https://www.rdoproject.org/tripleo/ >> > >> > >> >> >> >> >> >> Raoul - I totally agree with you, especially with "difficult for >> >> anyone to start contributing and collaborate". This is exactly why >> >> this discussion started. If we can agree on one set of tools, it will >> >> make everyone's life easier - current groups, new contributors, folks >> >> that just want to deploy TripleO quickly. But I'm afraid some >> >> sacrifices need to be made by both groups. >> >> >> >> David - I thought WeiRDO is used only for packstack, so I apologize I >> >> didn't include it. It does sound like an anther testing project, is >> >> there a place to merge it with another existing testing project? like >> >> Octario for example or one of TripleO testing projects. Or does it >> >> make sense to keep it a standalone project? >> >> >> >> >> >> >> >> >> >> On Tue, Aug 2, 2016 at 11:12 AM, Christopher Brown <cbrown2(a)ocf.co.uk >> > >> >> wrote: >> >> > Hello RDOistas (I think that is the expression?), >> >> > >> >> > Another year, another OpenStack deployment tool. :) >> >> > >> >> > On Mon, 2016-08-01 at 18:59 +0100, Ignacio Bravo wrote: >> >> >> If we are talking about tools, I would also want to add something >> >> >> with regards to user interface of these tools. This is based on my >> >> >> own experience: >> >> >> >> >> >> I started trying to deploy Openstack with Staypuft and The Foreman. >> >> >> The UI of The Foreman was intuitive enough for the discovery and >> >> >> provisioning of the servers. The OpenStack portion, not so much. >> >> > >> >> > This is exactly mine also. I think this works really well in very >> large >> >> > enterprise environments where you need to split out services over >> more >> >> > than three controllers. You do need good in-house puppet skills >> though >> >> > so better for enterprise with a good sysadmin team. >> >> > >> >> >> Forward a couple of releases and we had a TripleO GUI (Tuskar, I >> >> >> believe) that allowed you to graphically build your Openstack >> cloud. >> >> >> That was a reasonable good GUI for Openstack. >> >> > >> >> > Well, I found it barely usable. It was only ever good as a graphical >> >> > representiation of what the build was doing. Interacting with it was >> >> > not great. >> >> > >> >> >> Following that, TripleO become a script based installer, that >> >> >> required experience in Heat templates. I know I didn’t have it and >> >> >> had to ask in the mailing list about how to present this or change >> >> >> that. I got a couple of installs working with this setup. >> >> > >> >> > Works well now that I understand all the foibles and have invested >> time >> >> > into understanding heat templates and puppet modules. Its good in >> that >> >> > it forces you to learn about orchestration which is such an >> important >> >> > end-goal of cloud environments. >> >> > >> >> >> In the last session in Austin, my goal was to obtain information on >> >> >> how others were installing Openstack. I was pointed to Fuel as an >> >> >> alternative. I tried it up, and it just worked. It had the >> >> >> discovering capability from The Foreman, and the configuration >> >> >> options from TripleO. I understand that is based in Ansible and >> >> >> because of that, it is not fully CentOS ready for all the nodes (at >> >> >> least not in version 9 that I tried). In any case, as a deployer >> and >> >> >> installer, it is the most well rounded tool that I found. >> >> > >> >> > This is interesting to know. I've heard of Fuel of course but there >> are >> >> > some politics involved - it still has the team:single-vendor tag but >> >> > from what I see Mirantis are very keen for it to become the default >> >> > OpenStack installer. I don't think being Ansible-based should be a >> >> > problem - we are deploying OpenShift on OpenStack which uses >> Openshift- >> >> > ansible - this recently moved to Ansible 2.1 without too much >> >> > disruption. >> >> > >> >> >> I’d love to see RDO moving into that direction, and having an easy >> to >> >> >> use, end user ready deployer tool. >> >> > >> >> > If its as good as you say its definitely worth evaluating. From our >> >> > point of view, we want to be able to add services to the pacemaker >> >> > cluster with some ease - for example Magnum and Sahara - and it >> looks >> >> > like there are steps being taken with regards to composable roles >> and >> >> > simplification of the pacemaker cluster to just core services. >> >> > >> >> > But if someone can explain that better I would appreciate it. >> >> > >> >> > Regards >> >> > >> >> >> IB >> >> >> >> >> >> >> >> >> __ >> >> >> Ignacio Bravo >> >> >> LTG Federal, Inc >> >> >> www.ltgfederal.com >> >> >> >> >> >> >> >> >> > On Aug 1, 2016, at 1:07 PM, David Moreau Simard <dms(a)redhat.com&gt; >> >> >> > wrote: >> >> >> > >> >> >> > The vast majority of RDO's CI relies on using upstream >> >> >> > installation/deployment projects in order to test installation of >> >> >> > RDO >> >> >> > packages in different ways and configurations. >> >> >> > >> >> >> > Unless I'm mistaken, TripleO Quickstart was originally created >> as a >> >> >> > mean to "easily" install TripleO in different topologies without >> >> >> > requiring a massive amount of hardware. >> >> >> > This project allows us to test TripleO in virtual deployments on >> >> >> > just >> >> >> > one server instead of, say, 6. >> >> >> > >> >> >> > There's also WeIRDO [1] which was left out of your list. >> >> >> > WeIRDO is super simple and simply aims to run upstream gate jobs >> >> >> > (such >> >> >> > as puppet-openstack-integration [2][3] and packstack [4][5]) >> >> >> > outside >> >> >> > of the gate. >> >> >> > It'll install dependencies that are expected to be there (i.e, >> >> >> > usually >> >> >> > set up by the openstack-infra gate preparation jobs), set up the >> >> >> > trunk >> >> >> > repositories we're interested in testing and the rest is handled >> by >> >> >> > the upstream project testing framework. >> >> >> > >> >> >> > The WeIRDO project is /very/ low maintenance and brings an >> >> >> > exceptional >> >> >> > amount of coverage and value. >> >> >> > This coverage is important because RDO provides OpenStack >> packages >> >> >> > or >> >> >> > projects that are not necessarily used by TripleO and the reality >> >> >> > is >> >> >> > that not everyone deploying OpenStack on CentOS with RDO will be >> >> >> > using >> >> >> > TripleO. >> >> >> > >> >> >> > Anyway, sorry for sidetracking but back to the topic, thanks for >> >> >> > opening the discussion. >> >> >> > >> >> >> > What honestly perplexes me is the situation of CI in RDO and OSP, >> >> >> > especially around TripleO/Director, is the amount of work that is >> >> >> > spent downstream. >> >> >> > And by downstream, here, I mean anything that isn't in TripleO >> >> >> > proper. >> >> >> > >> >> >> > I keep dreaming about how awesome upstream TripleO CI would be if >> >> >> > all >> >> >> > that effort was spent directly there instead -- and then that all >> >> >> > work >> >> >> > could bear fruit and trickle down downstream for free. >> >> >> > Exactly like how we keep improving the testing coverage in >> >> >> > puppet-openstack-integration, it's automatically pulled in RDO CI >> >> >> > through WeIRDO for free. >> >> >> > We make the upstream better and we benefit from it >> simultaneously: >> >> >> > everyone wins. >> >> >> > >> >> >> > [1]: https://github.com/rdo-infra/weirdo >> >> >> > [2]: >> https://github.com/rdo-infra/ansible-role-weirdo-puppet-openst >> >> >> > ack >> >> >> > [3]: >> https://github.com/openstack/puppet-openstack-integration#desc >> >> >> > ription >> >> >> > [4]: https://github.com/rdo-infra/ansible-role-weirdo-packstack >> >> >> > [5]: >> https://github.com/openstack/packstack#packstack-integration-t >> >> >> > ests >> >> >> > >> >> >> > David Moreau Simard >> >> >> > Senior Software Engineer | Openstack RDO >> >> >> > >> >> >> > dmsimard = [irc, github, twitter] >> >> >> > >> >> >> > David Moreau Simard >> >> >> > Senior Software Engineer | Openstack RDO >> >> >> > >> >> >> > dmsimard = [irc, github, twitter] >> >> >> > >> >> >> > >> >> >> > On Mon, Aug 1, 2016 at 11:21 AM, Arie Bregman < >> abregman(a)redhat.com&gt; >> >> >> > 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. >> >> >> > > >> >> >> > > 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=ansi >> >> >> > > ble-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 >> >> >> > _______________________________________________ >> >> >> > 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 >> >> >> >> >> > -- >> >> > Regards, >> >> > >> >> > Christopher Brown >> >> > OpenStack Engineer >> >> > OCF plc >> >> > >> >> > Tel: +44 (0)114 257 2200 >> >> > Web: www.ocf.co.uk >> >> > Blog: blog.ocf.co.uk >> >> > Twitter: @ocfplc >> >> > >> >> > Please note, any emails relating to an OCF Support request must >> always >> >> > be sent to support(a)ocf.co.uk for a ticket number to be generated or >> >> > existing support ticket to be updated. Should this not be done then >> OCF >> >> > cannot be held responsible for requests not dealt with in a timely >> >> > manner. >> >> > >> >> > OCF plc is a company registered in England and Wales. Registered >> number >> >> > 4132533, VAT number GB 780 6803 14. Registered office address: OCF >> plc, >> >> > 5 Rotunda Business Centre, Thorncliffe Park, Chapeltown, Sheffield >> S35 >> >> > 2PG. >> >> > >> >> > This message is private and confidential. If you have received this >> >> > message in error, please notify us immediately and remove it from >> your >> >> > system. >> >> > >> >> > _______________________________________________ >> >> > 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 >> >> >> >> >> >> >> >> -- >> >> Arie Bregman >> >> Red Hat Israel >> >> Component CI: https://mojo.redhat.com/groups/rhos-core-ci/overview >> > >> > >> >> >> >> -- >> Arie Bregman >> Red Hat Israel >> Component CI: https://mojo.redhat.com/groups/rhos-core-ci/overview >> > > -- Tal Kammer Associate manager, automation and infrastracture, Openstack platform. Red Hat Israel Automation group mojo: https://mojo.redhat.com/docs/DOC-1011659 _______________________________________________ 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

On Wed, Aug 3, 2016 at 9:28 AM, Tal Kammer <tkammer(a)redhat.com&gt; wrote: > Thanks Arie for starting this discussion! (and sorry for joining in late) > > 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 :) ). > > 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). > > 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) > 1 undercloud on RHEL 7 with 16GB of ram + 60GB of HDD with 3 network > interfaces. > 3 controllers on Centos 7 with 8GB of ram + 40GB of HDD > 2 compute on Centos 7 with 6GB of ram + 60GB HDD > 3 ceph nodes on RHEL 7 with 4GB of ram + 2 HDD one with 20GB + one with > 40GB > > Example usage: (setting up the above VMs with four different HW specs) > ir-provisioner virsh --host-address=<host.address> > --host-key=<host.private.key> > --topology-nodes=undercloud:1,controller:3,compute:2,ceph:3 > > *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. > The installation of Openstack is done with a dedicated tool called > `ir-installer` (next) > > 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. > 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. > > 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 :) > > More info about InfraRed can be found here[1] (though I must admit that > we still need some "love" around our docs) > > [1] - http://infrared.readthedocs.io/en/latest/ > > I agree cleanly separating and modularizing infrastructure provisioining (for some use cases like NFV ideally with mixed VM and baremetal environments), OS installation and testing is a good approach. In that context, what happened to Khaleesi [0]? Haven't seen that mentioned on the original list. Nor Apex [1], the installer from OPNFV that does not only address OpenStack itself, but also integration with complementary projects like ODL?

[0] https://github.com/redhat-openstack/khaleesi [1] https://wiki.opnfv.org/display/apex/Apex > > On Tue, Aug 2, 2016 at 9:52 PM, Wesley Hayutin <whayutin(a)redhat.com&gt; > wrote: > >> >> >> On Tue, Aug 2, 2016 at 1:51 PM, Arie Bregman <abregman(a)redhat.com&gt; >> wrote: >> >>> On Tue, Aug 2, 2016 at 3:53 PM, Wesley Hayutin <whayutin(a)redhat.com&gt; >>> wrote: >>> > >>> > >>> > On Tue, Aug 2, 2016 at 4:58 AM, Arie Bregman <abregman(a)redhat.com&gt; >>> wrote: >>> >> >>> >> It became a discussion around the official installer and how to >>> >> improve it. While it's an important discussion, no doubt, I actually >>> >> want to focus on our automation and CI tools. >>> >> >>> >> Since I see there is an agreement that collaboration does make sense >>> >> here, let's move to the hard questions :) >>> >> >>> >> Wes, Tal - there is huge difference right now between infrared and >>> >> tripleo-quickstart in their structure. One is all-in-one project and >>> >> the other one is multiple micro projects managed by one project. Do >>> >> you think there is a way to consolidate or move to a different model >>> >> which will make sense for both RDO and RHOSP? something that both >>> >> groups can work on. >>> > >>> > >>> > 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. >>> > 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. >>> > I can help facilitate a discussion but oooq is an upstream tripleo >>> tool that >>> > replaces instack-virt-setup [1]. >>> > It also happens to be a great tool for easily deploying TripleO end >>> to end >>> > [3] >>> > >>> > What I *can* do is show everyone how to manipulate tripleo-quickstart >>> and >>> > customize it with composable ansible roles, templates, settings etc.. >>> > 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]. >>> > These 3rd party roles can be free and opensource or internal only, it >>> works >>> > either way. >>> > This was discussed in depth as part of the production chain >>> meetings, the >>> > message may have been lost unfortunately. >>> > >>> > I hope this resets your expectations of what I can and can not do as >>> part of >>> > these discussions. >>> > Let me know where and when and I'm happy to be part of the discussion. >>> >>> Thanks for clarifying :) >>> >>> Next reasonable step would probably be to propose some sort of >>> blueprint for tripleo-quickstart to include some of InfraRed features >>> and by that have one tool driven by upstream development that can be >>> either cloned downstream or used as it is with an internal data >>> project. >>> >> >> Sure.. a blueprint would help everyone understand the feature and the >> motivation. >> You could also just plug in the feature you are looking for to oooq and >> see if it meets >> your requirements. See below. >> > > 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. > > >> >> >>> >>> OR >>> >>> have InfraRed pushed into tripleo/openstack namespace and expose it to >>> the RDO community (without internal data of course). Personally, I >>> really like the pluggable[1] structure (which allows it to actually >>> consume tripleo-quickstart) so I'm not sure if it can be really merged >>> with tripleo-quickstart as proposed in the first option. >>> >> > 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. > A second benefit might be that by introducing a new concept / design we > can take what is best from two worlds and improve. > I would love to see an open discussion on the tool upstream and how we > can improve the overall process. > > >> The way oooq is built one can plugin or override any part at run time >> with custom playbooks, roles, and config. There isn't anything that >> needs to be >> checked in directly to oooq to use it. >> >> It's designed such that third parties can make their own decisions to >> use something >> native to quickstart, something from our role library, or something >> completely independent. >> This allows teams, individuals or whom ever to do what they need to with >> out having to fork or re-roll the entire framework. >> >> The important step is to note that these 3rd party roles or >> (oooq-extras) incubate, mature and then graduate to github/openstack. >> The upstream openstack community should lead, evaluate, and via >> blueprints vote on the canonical CI tool set. >> >> We can record a demonstration if required, but there is nothing stopping >> anyone right now from >> doing this today. I'm just browsing the role library for an example, I >> had no idea [1] existed. >> Looks like Raoul had a requirement and just made it work. >> >> Justin, from the browbeat project has graciously created some >> documentation regarding 3rd party roles. >> It has yet to merge, but it should help illustrate how these roles are >> used. [2] >> >> Thanks Arie for leading the discussion. >> >> [1] >> https://github.com/redhat-openstack/ansible-role-tripleo-overcloud-valida... >> [2] https://review.openstack.org/#/c/346733/ >> >> >> >> >> >> >>> >>> I like the second option, although it still forces us to have two >>> tools, but after a period of time, I believe it will be clear what the >>> community prefers, which will allow us to remove one of the projects >>> eventually. >>> >>> So, unless there are other ideas, I think the next move should be made >>> by Tal. >>> >>> Tal, I'm willing to help with whatever is needed. >>> >> > 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. > > >> >>> [1] http://infrared.readthedocs.io/en/latest >>> >>> > >>> > Thanks >>> > >>> > [1] https://blueprints.launchpad.net/tripleo/+spec/tripleo-quickstart >>> > [2] >>> > >>> https://github.com/redhat-openstack/?utf8=%E2%9C%93&query=ansible-rol... >>> > [3[ https://www.rdoproject.org/tripleo/ >>> > >>> > >>> >> >>> >> >>> >> Raoul - I totally agree with you, especially with "difficult for >>> >> anyone to start contributing and collaborate". This is exactly why >>> >> this discussion started. If we can agree on one set of tools, it will >>> >> make everyone's life easier - current groups, new contributors, folks >>> >> that just want to deploy TripleO quickly. But I'm afraid some >>> >> sacrifices need to be made by both groups. >>> >> >>> >> David - I thought WeiRDO is used only for packstack, so I apologize I >>> >> didn't include it. It does sound like an anther testing project, is >>> >> there a place to merge it with another existing testing project? like >>> >> Octario for example or one of TripleO testing projects. Or does it >>> >> make sense to keep it a standalone project? >>> >> >>> >> >>> >> >>> >> >>> >> On Tue, Aug 2, 2016 at 11:12 AM, Christopher Brown < >>> cbrown2(a)ocf.co.uk&gt; >>> >> wrote: >>> >> > Hello RDOistas (I think that is the expression?), >>> >> > >>> >> > Another year, another OpenStack deployment tool. :) >>> >> > >>> >> > On Mon, 2016-08-01 at 18:59 +0100, Ignacio Bravo wrote: >>> >> >> If we are talking about tools, I would also want to add something >>> >> >> with regards to user interface of these tools. This is based on my >>> >> >> own experience: >>> >> >> >>> >> >> I started trying to deploy Openstack with Staypuft and The >>> Foreman. >>> >> >> The UI of The Foreman was intuitive enough for the discovery and >>> >> >> provisioning of the servers. The OpenStack portion, not so much. >>> >> > >>> >> > This is exactly mine also. I think this works really well in very >>> large >>> >> > enterprise environments where you need to split out services over >>> more >>> >> > than three controllers. You do need good in-house puppet skills >>> though >>> >> > so better for enterprise with a good sysadmin team. >>> >> > >>> >> >> Forward a couple of releases and we had a TripleO GUI (Tuskar, I >>> >> >> believe) that allowed you to graphically build your Openstack >>> cloud. >>> >> >> That was a reasonable good GUI for Openstack. >>> >> > >>> >> > Well, I found it barely usable. It was only ever good as a >>> graphical >>> >> > representiation of what the build was doing. Interacting with it >>> was >>> >> > not great. >>> >> > >>> >> >> Following that, TripleO become a script based installer, that >>> >> >> required experience in Heat templates. I know I didn’t have it and >>> >> >> had to ask in the mailing list about how to present this or change >>> >> >> that. I got a couple of installs working with this setup. >>> >> > >>> >> > Works well now that I understand all the foibles and have invested >>> time >>> >> > into understanding heat templates and puppet modules. Its good in >>> that >>> >> > it forces you to learn about orchestration which is such an >>> important >>> >> > end-goal of cloud environments. >>> >> > >>> >> >> In the last session in Austin, my goal was to obtain information >>> on >>> >> >> how others were installing Openstack. I was pointed to Fuel as an >>> >> >> alternative. I tried it up, and it just worked. It had the >>> >> >> discovering capability from The Foreman, and the configuration >>> >> >> options from TripleO. I understand that is based in Ansible and >>> >> >> because of that, it is not fully CentOS ready for all the nodes >>> (at >>> >> >> least not in version 9 that I tried). In any case, as a deployer >>> and >>> >> >> installer, it is the most well rounded tool that I found. >>> >> > >>> >> > This is interesting to know. I've heard of Fuel of course but >>> there are >>> >> > some politics involved - it still has the team:single-vendor tag >>> but >>> >> > from what I see Mirantis are very keen for it to become the default >>> >> > OpenStack installer. I don't think being Ansible-based should be a >>> >> > problem - we are deploying OpenShift on OpenStack which uses >>> Openshift- >>> >> > ansible - this recently moved to Ansible 2.1 without too much >>> >> > disruption. >>> >> > >>> >> >> I’d love to see RDO moving into that direction, and having an >>> easy to >>> >> >> use, end user ready deployer tool. >>> >> > >>> >> > If its as good as you say its definitely worth evaluating. From our >>> >> > point of view, we want to be able to add services to the pacemaker >>> >> > cluster with some ease - for example Magnum and Sahara - and it >>> looks >>> >> > like there are steps being taken with regards to composable roles >>> and >>> >> > simplification of the pacemaker cluster to just core services. >>> >> > >>> >> > But if someone can explain that better I would appreciate it. >>> >> > >>> >> > Regards >>> >> > >>> >> >> IB >>> >> >> >>> >> >> >>> >> >> __ >>> >> >> Ignacio Bravo >>> >> >> LTG Federal, Inc >>> >> >> www.ltgfederal.com >>> >> >> >>> >> >> >>> >> >> > On Aug 1, 2016, at 1:07 PM, David Moreau Simard <dms(a)redhat.com >>> > >>> >> >> > wrote: >>> >> >> > >>> >> >> > The vast majority of RDO's CI relies on using upstream >>> >> >> > installation/deployment projects in order to test installation >>> of >>> >> >> > RDO >>> >> >> > packages in different ways and configurations. >>> >> >> > >>> >> >> > Unless I'm mistaken, TripleO Quickstart was originally created >>> as a >>> >> >> > mean to "easily" install TripleO in different topologies without >>> >> >> > requiring a massive amount of hardware. >>> >> >> > This project allows us to test TripleO in virtual deployments on >>> >> >> > just >>> >> >> > one server instead of, say, 6. >>> >> >> > >>> >> >> > There's also WeIRDO [1] which was left out of your list. >>> >> >> > WeIRDO is super simple and simply aims to run upstream gate jobs >>> >> >> > (such >>> >> >> > as puppet-openstack-integration [2][3] and packstack [4][5]) >>> >> >> > outside >>> >> >> > of the gate. >>> >> >> > It'll install dependencies that are expected to be there (i.e, >>> >> >> > usually >>> >> >> > set up by the openstack-infra gate preparation jobs), set up the >>> >> >> > trunk >>> >> >> > repositories we're interested in testing and the rest is >>> handled by >>> >> >> > the upstream project testing framework. >>> >> >> > >>> >> >> > The WeIRDO project is /very/ low maintenance and brings an >>> >> >> > exceptional >>> >> >> > amount of coverage and value. >>> >> >> > This coverage is important because RDO provides OpenStack >>> packages >>> >> >> > or >>> >> >> > projects that are not necessarily used by TripleO and the >>> reality >>> >> >> > is >>> >> >> > that not everyone deploying OpenStack on CentOS with RDO will be >>> >> >> > using >>> >> >> > TripleO. >>> >> >> > >>> >> >> > Anyway, sorry for sidetracking but back to the topic, thanks for >>> >> >> > opening the discussion. >>> >> >> > >>> >> >> > What honestly perplexes me is the situation of CI in RDO and >>> OSP, >>> >> >> > especially around TripleO/Director, is the amount of work that >>> is >>> >> >> > spent downstream. >>> >> >> > And by downstream, here, I mean anything that isn't in TripleO >>> >> >> > proper. >>> >> >> > >>> >> >> > I keep dreaming about how awesome upstream TripleO CI would be >>> if >>> >> >> > all >>> >> >> > that effort was spent directly there instead -- and then that >>> all >>> >> >> > work >>> >> >> > could bear fruit and trickle down downstream for free. >>> >> >> > Exactly like how we keep improving the testing coverage in >>> >> >> > puppet-openstack-integration, it's automatically pulled in RDO >>> CI >>> >> >> > through WeIRDO for free. >>> >> >> > We make the upstream better and we benefit from it >>> simultaneously: >>> >> >> > everyone wins. >>> >> >> > >>> >> >> > [1]: https://github.com/rdo-infra/weirdo >>> >> >> > [2]: >>> https://github.com/rdo-infra/ansible-role-weirdo-puppet-openst >>> >> >> > ack >>> >> >> > [3]: >>> https://github.com/openstack/puppet-openstack-integration#desc >>> >> >> > ription >>> >> >> > [4]: https://github.com/rdo-infra/ansible-role-weirdo-packstack >>> >> >> > [5]: >>> https://github.com/openstack/packstack#packstack-integration-t >>> >> >> > ests >>> >> >> > >>> >> >> > David Moreau Simard >>> >> >> > Senior Software Engineer | Openstack RDO >>> >> >> > >>> >> >> > dmsimard = [irc, github, twitter] >>> >> >> > >>> >> >> > David Moreau Simard >>> >> >> > Senior Software Engineer | Openstack RDO >>> >> >> > >>> >> >> > dmsimard = [irc, github, twitter] >>> >> >> > >>> >> >> > >>> >> >> > On Mon, Aug 1, 2016 at 11:21 AM, Arie Bregman < >>> abregman(a)redhat.com&gt; >>> >> >> > 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. >>> >> >> > > >>> >> >> > > 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=ansi >>> >> >> > > ble-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 >>> >> >> > _______________________________________________ >>> >> >> > 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 >>> >> >> >>> >> > -- >>> >> > Regards, >>> >> > >>> >> > Christopher Brown >>> >> > OpenStack Engineer >>> >> > OCF plc >>> >> > >>> >> > Tel: +44 (0)114 257 2200 >>> >> > Web: www.ocf.co.uk >>> >> > Blog: blog.ocf.co.uk >>> >> > Twitter: @ocfplc >>> >> > >>> >> > Please note, any emails relating to an OCF Support request must >>> always >>> >> > be sent to support(a)ocf.co.uk for a ticket number to be generated >>> or >>> >> > existing support ticket to be updated. Should this not be done >>> then OCF >>> >> > cannot be held responsible for requests not dealt with in a timely >>> >> > manner. >>> >> > >>> >> > OCF plc is a company registered in England and Wales. Registered >>> number >>> >> > 4132533, VAT number GB 780 6803 14. Registered office address: OCF >>> plc, >>> >> > 5 Rotunda Business Centre, Thorncliffe Park, Chapeltown, Sheffield >>> S35 >>> >> > 2PG. >>> >> > >>> >> > This message is private and confidential. If you have received this >>> >> > message in error, please notify us immediately and remove it from >>> your >>> >> > system. >>> >> > >>> >> > _______________________________________________ >>> >> > 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 >>> >> >>> >> >>> >> >>> >> -- >>> >> Arie Bregman >>> >> Red Hat Israel >>> >> Component CI: https://mojo.redhat.com/groups/rhos-core-ci/overview >>> > >>> > >>> >>> >>> >>> -- >>> Arie Bregman >>> Red Hat Israel >>> Component CI: https://mojo.redhat.com/groups/rhos-core-ci/overview >>> >> >> > > > -- > Tal Kammer > Associate manager, automation and infrastracture, Openstack platform. > Red Hat Israel > Automation group mojo: https://mojo.redhat.com/docs/DOC-1011659 > > _______________________________________________ > 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 > -- {Kind regards | Mit besten Grüßen}, Frank ________________________________ Frank Zdarsky | NFV Partner Engineering | Office of Technology | Red Hat e: fzdarsky(a)redhat.com | irc: fzdarsky @freenode | m: +49 175 82 11 64 4 | t: +49 711 96 43 70 02

On Wed, Aug 3, 2016 at 5:23 AM, Frank Zdarsky <fzdarsky(a)redhat.com&gt; wrote: > > On Wed, Aug 3, 2016 at 9:28 AM, Tal Kammer <tkammer(a)redhat.com&gt; wrote: >> >> Thanks Arie for starting this discussion! (and sorry for joining in late) >> >> 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 :) ). >> >> 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). >> >> 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) >> 1 undercloud on RHEL 7 with 16GB of ram + 60GB of HDD with 3 network >> interfaces. >> 3 controllers on Centos 7 with 8GB of ram + 40GB of HDD >> 2 compute on Centos 7 with 6GB of ram + 60GB HDD >> 3 ceph nodes on RHEL 7 with 4GB of ram + 2 HDD one with 20GB + one with >> 40GB >> >> Example usage: (setting up the above VMs with four different HW specs) >> ir-provisioner virsh --host-address=<host.address> >> --host-key=<host.private.key> >> --topology-nodes=undercloud:1,controller:3,compute:2,ceph:3 >> >> *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. >> The installation of Openstack is done with a dedicated tool called >> `ir-installer` (next) >> >> 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. >> 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. >> >> 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 :) >> >> More info about InfraRed can be found here[1] (though I must admit that >> we still need some "love" around our docs) >> >> [1] - http://infrared.readthedocs.io/en/latest/ >> > > I agree cleanly separating and modularizing infrastructure provisioining > (for some use cases like NFV ideally with mixed VM and baremetal > environments), OS installation and testing is a good approach. In that > context, what happened to Khaleesi [0]? Haven't seen that mentioned on the > original list. Nor Apex [1], the installer from OPNFV that does not only > address OpenStack itself, but also integration with complementary projects > like ODL? I consider provisioning baremetal for either libvirt hosts or baremetal installs is a separate project and conversation from the CI tools used to deploy tripleo. To be a little more clear, provisioning imho should be completely uncoupled from the CI code that deploys tripleo. Any team should be able to use provisioner tools that best fit their needs. If there is interest in collaborating on provisioners maybe we can do that in another thread. Why in another thread? Again my thought is they should be uncoupled completely from our CI source code. The rdo infra team is using two provisioners, both completely uncoupled from tripleo-quickstart. 1. Ansible extra heat provisioner: for ovb, written by Mathieu Bultel https://github.com/ansible/ansible-modules-extras/commit/c6a45234e0949227... 2. cico, the official client for ci.centos written by David Simard http://python-cicoclient.readthedocs.io/en/latest/cli_usage.html Our baremetal deployments do not require any provisioning outside of what is done w/ ironic and tripleo. Upstream tripleo ci provisioning is done via node pool and ovb. FYI.. khaleesi has been deprecated and is no longer used by RDO infra. Thanks > > > [0] https://github.com/redhat-openstack/khaleesi > [1] https://wiki.opnfv.org/display/apex/Apex > >> >> >> On Tue, Aug 2, 2016 at 9:52 PM, Wesley Hayutin <whayutin(a)redhat.com&gt; >> wrote: >>> >>> >>> >>> On Tue, Aug 2, 2016 at 1:51 PM, Arie Bregman <abregman(a)redhat.com&gt; >>> wrote: >>>> >>>> On Tue, Aug 2, 2016 at 3:53 PM, Wesley Hayutin <whayutin(a)redhat.com&gt; >>>> wrote: >>>> > >>>> > >>>> > On Tue, Aug 2, 2016 at 4:58 AM, Arie Bregman <abregman(a)redhat.com&gt; >>>> > wrote: >>>> >> >>>> >> It became a discussion around the official installer and how to >>>> >> improve it. While it's an important discussion, no doubt, I actually >>>> >> want to focus on our automation and CI tools. >>>> >> >>>> >> Since I see there is an agreement that collaboration does make sense >>>> >> here, let's move to the hard questions :) >>>> >> >>>> >> Wes, Tal - there is huge difference right now between infrared and >>>> >> tripleo-quickstart in their structure. One is all-in-one project and >>>> >> the other one is multiple micro projects managed by one project. Do >>>> >> you think there is a way to consolidate or move to a different model >>>> >> which will make sense for both RDO and RHOSP? something that both >>>> >> groups can work on. >>>> > >>>> > >>>> > 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. >>>> > 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. >>>> > I can help facilitate a discussion but oooq is an upstream tripleo >>>> > tool that >>>> > replaces instack-virt-setup [1]. >>>> > It also happens to be a great tool for easily deploying TripleO end >>>> > to end >>>> > [3] >>>> > >>>> > What I *can* do is show everyone how to manipulate tripleo-quickstart >>>> > and >>>> > customize it with composable ansible roles, templates, settings etc.. >>>> > 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]. >>>> > These 3rd party roles can be free and opensource or internal only, it >>>> > works >>>> > either way. >>>> > This was discussed in depth as part of the production chain meetings, >>>> > the >>>> > message may have been lost unfortunately. >>>> > >>>> > I hope this resets your expectations of what I can and can not do as >>>> > part of >>>> > these discussions. >>>> > Let me know where and when and I'm happy to be part of the >>>> > discussion. >>>> >>>> Thanks for clarifying :) >>>> >>>> Next reasonable step would probably be to propose some sort of >>>> blueprint for tripleo-quickstart to include some of InfraRed features >>>> and by that have one tool driven by upstream development that can be >>>> either cloned downstream or used as it is with an internal data >>>> project. >>> >>> >>> Sure.. a blueprint would help everyone understand the feature and the >>> motivation. >>> You could also just plug in the feature you are looking for to oooq and >>> see if it meets >>> your requirements. See below. >> >> >> 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. >> >>> >>> >>>> >>>> >>>> OR >>>> >>>> have InfraRed pushed into tripleo/openstack namespace and expose it to >>>> the RDO community (without internal data of course). Personally, I >>>> really like the pluggable[1] structure (which allows it to actually >>>> consume tripleo-quickstart) so I'm not sure if it can be really merged >>>> with tripleo-quickstart as proposed in the first option. >> >> >> 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. >> A second benefit might be that by introducing a new concept / design we >> can take what is best from two worlds and improve. >> I would love to see an open discussion on the tool upstream and how we >> can improve the overall process. >> >>> >>> The way oooq is built one can plugin or override any part at run time >>> with custom playbooks, roles, and config. There isn't anything that >>> needs to be >>> checked in directly to oooq to use it. >>> >>> It's designed such that third parties can make their own decisions to >>> use something >>> native to quickstart, something from our role library, or something >>> completely independent. >>> This allows teams, individuals or whom ever to do what they need to with >>> out having to fork or re-roll the entire framework. >>> >>> The important step is to note that these 3rd party roles or >>> (oooq-extras) incubate, mature and then graduate to github/openstack. >>> The upstream openstack community should lead, evaluate, and via >>> blueprints vote on the canonical CI tool set. >>> >>> We can record a demonstration if required, but there is nothing stopping >>> anyone right now from >>> doing this today. I'm just browsing the role library for an example, I >>> had no idea [1] existed. >>> Looks like Raoul had a requirement and just made it work. >>> >>> Justin, from the browbeat project has graciously created some >>> documentation regarding 3rd party roles. >>> It has yet to merge, but it should help illustrate how these roles are >>> used. [2] >>> >>> Thanks Arie for leading the discussion. >>> >>> [1] >>> https://github.com/redhat-openstack/ansible-role-tripleo-overcloud-valida... >>> [2] https://review.openstack.org/#/c/346733/ >>> >>> >>> >>> >>> >>>> >>>> >>>> I like the second option, although it still forces us to have two >>>> tools, but after a period of time, I believe it will be clear what the >>>> community prefers, which will allow us to remove one of the projects >>>> eventually. >>>> >>>> So, unless there are other ideas, I think the next move should be made >>>> by Tal. >>>> >>>> Tal, I'm willing to help with whatever is needed. >> >> >> 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. >> >>>> >>>> >>>> [1] http://infrared.readthedocs.io/en/latest >>>> >>>> > >>>> > Thanks >>>> > >>>> > [1] https://blueprints.launchpad.net/tripleo/+spec/tripleo-quickstart >>>> > [2] >>>> > >>>> > https://github.com/redhat-openstack/?utf8=%E2%9C%93&query=ansible-rol... >>>> > [3[ https://www.rdoproject.org/tripleo/ >>>> > >>>> > >>>> >> >>>> >> >>>> >> Raoul - I totally agree with you, especially with "difficult for >>>> >> anyone to start contributing and collaborate". This is exactly why >>>> >> this discussion started. If we can agree on one set of tools, it >>>> >> will >>>> >> make everyone's life easier - current groups, new contributors, >>>> >> folks >>>> >> that just want to deploy TripleO quickly. But I'm afraid some >>>> >> sacrifices need to be made by both groups. >>>> >> >>>> >> David - I thought WeiRDO is used only for packstack, so I apologize >>>> >> I >>>> >> didn't include it. It does sound like an anther testing project, is >>>> >> there a place to merge it with another existing testing project? >>>> >> like >>>> >> Octario for example or one of TripleO testing projects. Or does it >>>> >> make sense to keep it a standalone project? >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> On Tue, Aug 2, 2016 at 11:12 AM, Christopher Brown >>>> >> <cbrown2(a)ocf.co.uk&gt; >>>> >> wrote: >>>> >> > Hello RDOistas (I think that is the expression?), >>>> >> > >>>> >> > Another year, another OpenStack deployment tool. :) >>>> >> > >>>> >> > On Mon, 2016-08-01 at 18:59 +0100, Ignacio Bravo wrote: >>>> >> >> If we are talking about tools, I would also want to add something >>>> >> >> with regards to user interface of these tools. This is based on >>>> >> >> my >>>> >> >> own experience: >>>> >> >> >>>> >> >> I started trying to deploy Openstack with Staypuft and The >>>> >> >> Foreman. >>>> >> >> The UI of The Foreman was intuitive enough for the discovery and >>>> >> >> provisioning of the servers. The OpenStack portion, not so much. >>>> >> > >>>> >> > This is exactly mine also. I think this works really well in very >>>> >> > large >>>> >> > enterprise environments where you need to split out services over >>>> >> > more >>>> >> > than three controllers. You do need good in-house puppet skills >>>> >> > though >>>> >> > so better for enterprise with a good sysadmin team. >>>> >> > >>>> >> >> Forward a couple of releases and we had a TripleO GUI (Tuskar, I >>>> >> >> believe) that allowed you to graphically build your Openstack >>>> >> >> cloud. >>>> >> >> That was a reasonable good GUI for Openstack. >>>> >> > >>>> >> > Well, I found it barely usable. It was only ever good as a >>>> >> > graphical >>>> >> > representiation of what the build was doing. Interacting with it >>>> >> > was >>>> >> > not great. >>>> >> > >>>> >> >> Following that, TripleO become a script based installer, that >>>> >> >> required experience in Heat templates. I know I didn’t have it >>>> >> >> and >>>> >> >> had to ask in the mailing list about how to present this or >>>> >> >> change >>>> >> >> that. I got a couple of installs working with this setup. >>>> >> > >>>> >> > Works well now that I understand all the foibles and have invested >>>> >> > time >>>> >> > into understanding heat templates and puppet modules. Its good in >>>> >> > that >>>> >> > it forces you to learn about orchestration which is such an >>>> >> > important >>>> >> > end-goal of cloud environments. >>>> >> > >>>> >> >> In the last session in Austin, my goal was to obtain information >>>> >> >> on >>>> >> >> how others were installing Openstack. I was pointed to Fuel as an >>>> >> >> alternative. I tried it up, and it just worked. It had the >>>> >> >> discovering capability from The Foreman, and the configuration >>>> >> >> options from TripleO. I understand that is based in Ansible and >>>> >> >> because of that, it is not fully CentOS ready for all the nodes >>>> >> >> (at >>>> >> >> least not in version 9 that I tried). In any case, as a deployer >>>> >> >> and >>>> >> >> installer, it is the most well rounded tool that I found. >>>> >> > >>>> >> > This is interesting to know. I've heard of Fuel of course but >>>> >> > there are >>>> >> > some politics involved - it still has the team:single-vendor tag >>>> >> > but >>>> >> > from what I see Mirantis are very keen for it to become the >>>> >> > default >>>> >> > OpenStack installer. I don't think being Ansible-based should be a >>>> >> > problem - we are deploying OpenShift on OpenStack which uses >>>> >> > Openshift- >>>> >> > ansible - this recently moved to Ansible 2.1 without too much >>>> >> > disruption. >>>> >> > >>>> >> >> I’d love to see RDO moving into that direction, and having an >>>> >> >> easy to >>>> >> >> use, end user ready deployer tool. >>>> >> > >>>> >> > If its as good as you say its definitely worth evaluating. From >>>> >> > our >>>> >> > point of view, we want to be able to add services to the pacemaker >>>> >> > cluster with some ease - for example Magnum and Sahara - and it >>>> >> > looks >>>> >> > like there are steps being taken with regards to composable roles >>>> >> > and >>>> >> > simplification of the pacemaker cluster to just core services. >>>> >> > >>>> >> > But if someone can explain that better I would appreciate it. >>>> >> > >>>> >> > Regards >>>> >> > >>>> >> >> IB >>>> >> >> >>>> >> >> >>>> >> >> __ >>>> >> >> Ignacio Bravo >>>> >> >> LTG Federal, Inc >>>> >> >> www.ltgfederal.com >>>> >> >> >>>> >> >> >>>> >> >> > On Aug 1, 2016, at 1:07 PM, David Moreau Simard >>>> >> >> > <dms(a)redhat.com&gt; >>>> >> >> > wrote: >>>> >> >> > >>>> >> >> > The vast majority of RDO's CI relies on using upstream >>>> >> >> > installation/deployment projects in order to test installation >>>> >> >> > of >>>> >> >> > RDO >>>> >> >> > packages in different ways and configurations. >>>> >> >> > >>>> >> >> > Unless I'm mistaken, TripleO Quickstart was originally created >>>> >> >> > as a >>>> >> >> > mean to "easily" install TripleO in different topologies >>>> >> >> > without >>>> >> >> > requiring a massive amount of hardware. >>>> >> >> > This project allows us to test TripleO in virtual deployments >>>> >> >> > on >>>> >> >> > just >>>> >> >> > one server instead of, say, 6. >>>> >> >> > >>>> >> >> > There's also WeIRDO [1] which was left out of your list. >>>> >> >> > WeIRDO is super simple and simply aims to run upstream gate >>>> >> >> > jobs >>>> >> >> > (such >>>> >> >> > as puppet-openstack-integration [2][3] and packstack [4][5]) >>>> >> >> > outside >>>> >> >> > of the gate. >>>> >> >> > It'll install dependencies that are expected to be there (i.e, >>>> >> >> > usually >>>> >> >> > set up by the openstack-infra gate preparation jobs), set up >>>> >> >> > the >>>> >> >> > trunk >>>> >> >> > repositories we're interested in testing and the rest is >>>> >> >> > handled by >>>> >> >> > the upstream project testing framework. >>>> >> >> > >>>> >> >> > The WeIRDO project is /very/ low maintenance and brings an >>>> >> >> > exceptional >>>> >> >> > amount of coverage and value. >>>> >> >> > This coverage is important because RDO provides OpenStack >>>> >> >> > packages >>>> >> >> > or >>>> >> >> > projects that are not necessarily used by TripleO and the >>>> >> >> > reality >>>> >> >> > is >>>> >> >> > that not everyone deploying OpenStack on CentOS with RDO will >>>> >> >> > be >>>> >> >> > using >>>> >> >> > TripleO. >>>> >> >> > >>>> >> >> > Anyway, sorry for sidetracking but back to the topic, thanks >>>> >> >> > for >>>> >> >> > opening the discussion. >>>> >> >> > >>>> >> >> > What honestly perplexes me is the situation of CI in RDO and >>>> >> >> > OSP, >>>> >> >> > especially around TripleO/Director, is the amount of work that >>>> >> >> > is >>>> >> >> > spent downstream. >>>> >> >> > And by downstream, here, I mean anything that isn't in TripleO >>>> >> >> > proper. >>>> >> >> > >>>> >> >> > I keep dreaming about how awesome upstream TripleO CI would be >>>> >> >> > if >>>> >> >> > all >>>> >> >> > that effort was spent directly there instead -- and then that >>>> >> >> > all >>>> >> >> > work >>>> >> >> > could bear fruit and trickle down downstream for free. >>>> >> >> > Exactly like how we keep improving the testing coverage in >>>> >> >> > puppet-openstack-integration, it's automatically pulled in RDO >>>> >> >> > CI >>>> >> >> > through WeIRDO for free. >>>> >> >> > We make the upstream better and we benefit from it >>>> >> >> > simultaneously: >>>> >> >> > everyone wins. >>>> >> >> > >>>> >> >> > [1]: https://github.com/rdo-infra/weirdo >>>> >> >> > [2]: >>>> >> >> > https://github.com/rdo-infra/ansible-role-weirdo-puppet-openst >>>> >> >> > ack >>>> >> >> > [3]: >>>> >> >> > https://github.com/openstack/puppet-openstack-integration#desc >>>> >> >> > ription >>>> >> >> > [4]: https://github.com/rdo-infra/ansible-role-weirdo-packstack >>>> >> >> > [5]: >>>> >> >> > https://github.com/openstack/packstack#packstack-integration-t >>>> >> >> > ests >>>> >> >> > >>>> >> >> > David Moreau Simard >>>> >> >> > Senior Software Engineer | Openstack RDO >>>> >> >> > >>>> >> >> > dmsimard = [irc, github, twitter] >>>> >> >> > >>>> >> >> > David Moreau Simard >>>> >> >> > Senior Software Engineer | Openstack RDO >>>> >> >> > >>>> >> >> > dmsimard = [irc, github, twitter] >>>> >> >> > >>>> >> >> > >>>> >> >> > On Mon, Aug 1, 2016 at 11:21 AM, Arie Bregman >>>> >> >> > <abregman(a)redhat.com&gt; >>>> >> >> > 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. >>>> >> >> > > >>>> >> >> > > 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=ansi >>>> >> >> > > ble-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 >>>> >> >> > _______________________________________________ >>>> >> >> > 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 >>>> >> >> >>>> >> > -- >>>> >> > Regards, >>>> >> > >>>> >> > Christopher Brown >>>> >> > OpenStack Engineer >>>> >> > OCF plc >>>> >> > >>>> >> > Tel: +44 (0)114 257 2200 >>>> >> > Web: www.ocf.co.uk >>>> >> > Blog: blog.ocf.co.uk >>>> >> > Twitter: @ocfplc >>>> >> > >>>> >> > Please note, any emails relating to an OCF Support request must >>>> >> > always >>>> >> > be sent to support(a)ocf.co.uk for a ticket number to be generated >>>> >> > or >>>> >> > existing support ticket to be updated. Should this not be done >>>> >> > then OCF >>>> >> > cannot be held responsible for requests not dealt with in a timely >>>> >> > manner. >>>> >> > >>>> >> > OCF plc is a company registered in England and Wales. Registered >>>> >> > number >>>> >> > 4132533, VAT number GB 780 6803 14. Registered office address: OCF >>>> >> > plc, >>>> >> > 5 Rotunda Business Centre, Thorncliffe Park, Chapeltown, Sheffield >>>> >> > S35 >>>> >> > 2PG. >>>> >> > >>>> >> > This message is private and confidential. If you have received >>>> >> > this >>>> >> > message in error, please notify us immediately and remove it from >>>> >> > your >>>> >> > system. >>>> >> > >>>> >> > _______________________________________________ >>>> >> > 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 >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> Arie Bregman >>>> >> Red Hat Israel >>>> >> Component CI: https://mojo.redhat.com/groups/rhos-core-ci/overview >>>> > >>>> > >>>> >>>> >>>> >>>> -- >>>> Arie Bregman >>>> Red Hat Israel >>>> Component CI: https://mojo.redhat.com/groups/rhos-core-ci/overview >>> >>> >> >> >> >> -- >> Tal Kammer >> Associate manager, automation and infrastracture, Openstack platform. >> Red Hat Israel >> Automation group mojo: https://mojo.redhat.com/docs/DOC-1011659 >> >> _______________________________________________ >> 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 > > > > > -- > {Kind regards | Mit besten Grüßen}, > > Frank > > ________________________________ > Frank Zdarsky | NFV Partner Engineering | Office of Technology | Red Hat > e: fzdarsky(a)redhat.com | irc: fzdarsky @freenode | m: +49 175 82 11 64 4 | > t: +49 711 96 43 70 02 _______________________________________________ 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

However, IMO, incubating these things downstream and then trying to get them upstream or get upstream to adopt them is not ideal or a good example. The same topic came up and was pushed several times with khaleesi, and it just never happened, it was continually DOA upstream.

On Wed, Aug 3, 2016 at 12:51 PM, James Slagle <jslagle(a)redhat.com&gt; wrote: > > On Wed, Aug 03, 2016 at 11:36:57AM -0400, David Moreau Simard wrote: > > Please hear me out. > > TL;DR, Let's work upstream and make it awesome so that downstream can > > be awesome. > > > > I've said this before but I'm going to re-iterate that I do not > > understand why there is so much effort spent around testing TripleO > > downstream. > > By downstream, I mean anything that isn't in TripleO or TripleO-CI > > proper. > > > > All this work should be done upstream to make TripleO and it's CI > > super awesome and this would trickle down for free downstream. > > > > The RDO Trunk testing pipeline is composed of two tools, today. > > The TripleO-Quickstart project [1] is a good example of an initiative > > that started downstream but always had the intention of being proposed > > upstream [2] after being "incubated" and fleshed out. > > tripleo-quickstart was proposed to upstream TripleO as a replacement for > the > virtual environment setup done by instack-virt-setup. 3rd party CI would > be > used to gate tripleo-quickstart so that we'd be sure the virt setup was > always > working. That was the extent of the CI scope defined in the spec. That > work is > not yet completed (see work items in the spec). > > Now it seems it is a much more all encompassing CI/automation/testing > project > that is competing in scope with tripleo-ci itself. IMHO you are correct here. There has been quite a bit of discussion about removing the parts of oooq that are outside of the original blueprint to replace instack-virt-setup w/ oooq. As usual there are many different opinions here. I think there are a lot of RDO guys that would prefer a lot of the native oooq roles stay where they are, I think that is short sighted imho. I agree that anything outside of the blueprint be removed from oooq. This would hopefully allow the upstream to be more comfortable with oooq and allow us to really start consolidating tools. Luckily for the users that still want to use oooq as a full end-to-end solution the 3rd party roles can be used even after tearing out these native roles. > > > I'm all for consolidation of these types of tools *if* there is interest. Roll call.. is there interest? +1 from me. > > > However, IMO, incubating these things downstream and then trying to get > them > upstream or get upstream to adopt them is not ideal or a good example. The > same > topic came up and was pushed several times with khaleesi, and it just > never > happened, it was continually DOA upstream. True, however that could be a result of the downstream perceiving barriers ( real or not ) in incubating projects in upstream openstack. > > > I think it would be fairly difficult to get tripleo-ci to wholesale adopt > tripleo-quickstart at this stage. The separate irc channel from #tripleo > is not > conducive to consolidation on tooling and direction imo. The irc channel is easily addressed. We do seem to generate an awful amount of chatter though :) > > > The scope of quickstart is actually not fully understood by myself. I've > also > heard from some in the upstream TripleO community as well who are confused > by > its direction and are facing similar difficulties using its generated bash > scripts that they'd be facing if they were just using TripleO > documentation > instead. The point of the generated bash scripts is to create rst documentation and reusable scripts for the end user. Since the documentation and the generated scripts are equivalent I would expect the same errors, problems and issues. I see this as a good thing really. We *want* the CI to hit the same issues as those who are following the doc. > > > I do think that this sort of problem lends itself easily to one off > implementations as is quite evidenced in this thread. Everyone/group wants > and > needs to automate something in a different way. And imo, none of these > tools > are building end-user or operator facing interfaces, so they're not fully > focused on building something that "just works for everyone". Those > interfaces > should be developed in TripleO user facing tooling anyway > (tripleoclient/openstackclient/etc). > > So, I actually think it's ok in some degree that things have been > automated > differently in different tools. Anecdotally, I suspect many users of > TripleO in > production have their own automation tools as well. And none of the > implementations mentioned in this thread would likely meet their needs > either. This is true.. without a tool in the upstream that addresses ci, dev, test use cases across the development cycle this will continue to be the case. I suspect even with a perfect tool, it won't ever be perfect for everyone. > > > However, if there is a desire to focus resources on consolidated tooling > and > someone to drive it forward, then I definitely agree that the effort needs > to > start upstream with a singular plan for tripleo-ci. From what I gather, > that > would be some sort of alignment and reuse of tripleo-quickstart, and then > we > could build from there. +1 > > > That could start as a discussion and plan within that community with some > agreed on concensus around that plan. There was an initial thread on > openstack-dev related to this topic but it is stalled a bit. It could be > continually driven to resolution via specs, the tripleo meeting, email or > irc > discussion until a plan is formed. +1, I think the first step is to complete the original blueprint and move on from there. I think there has also been interest in having an in person meeting at summit. Thanks! > > > -- > -- James Slagle > -- > > _______________________________________________ > 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 _______________________________________________ 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

On Wed, Aug 3, 2016 at 6:19 PM, Emilien Macchi <emilien(a)redhat.com&gt; wrote: > > On Wed, Aug 3, 2016 at 1:33 PM, Wesley Hayutin <whayutin(a)redhat.com&gt; > wrote: > > > > > > On Wed, Aug 3, 2016 at 12:51 PM, James Slagle <jslagle(a)redhat.com&gt; > > wrote: > >> > >> On Wed, Aug 03, 2016 at 11:36:57AM -0400, David Moreau Simard wrote: > >> > Please hear me out. > >> > TL;DR, Let's work upstream and make it awesome so that downstream can > >> > be awesome. > >> > > >> > I've said this before but I'm going to re-iterate that I do not > >> > understand why there is so much effort spent around testing TripleO > >> > downstream. > >> > By downstream, I mean anything that isn't in TripleO or TripleO-CI > >> > proper. > >> > > >> > All this work should be done upstream to make TripleO and it's CI > >> > super awesome and this would trickle down for free downstream. > >> > > >> > The RDO Trunk testing pipeline is composed of two tools, today. > >> > The TripleO-Quickstart project [1] is a good example of an initiative > >> > that started downstream but always had the intention of being > >> > proposed > >> > upstream [2] after being "incubated" and fleshed out. > >> > >> tripleo-quickstart was proposed to upstream TripleO as a replacement > >> for > >> the > >> virtual environment setup done by instack-virt-setup. 3rd party CI > >> would > >> be > >> used to gate tripleo-quickstart so that we'd be sure the virt setup was > >> always > >> working. That was the extent of the CI scope defined in the spec. That > >> work is > >> not yet completed (see work items in the spec). > >> > >> Now it seems it is a much more all encompassing CI/automation/testing > >> project > >> that is competing in scope with tripleo-ci itself. > > > > > > IMHO you are correct here. There has been quite a bit of discussion > > about > > removing the parts > > of oooq that are outside of the original blueprint to replace > > instack-virt-setup w/ oooq. As usual there are many different opinions > > here. I think there are a lot of RDO guys that would prefer a lot of > > the > > native oooq roles stay where they are, I think that is short sighted > > imho. > > I agree that anything outside of the blueprint be removed from oooq. > > This > > would hopefully allow the upstream to be more comfortable with oooq and > > allow us to really start consolidating tools. > > > > Luckily for the users that still want to use oooq as a full end-to-end > > solution the 3rd party roles can be used even after tearing out these > > native > > roles. > > > >> > >> > >> I'm all for consolidation of these types of tools *if* there is > >> interest. > > > > > > Roll call.. is there interest? +1 from me. > > > >> > >> > >> However, IMO, incubating these things downstream and then trying to get > >> them > >> upstream or get upstream to adopt them is not ideal or a good example. > >> The > >> same > >> topic came up and was pushed several times with khaleesi, and it just > >> never > >> happened, it was continually DOA upstream. > > > > > > True, however that could be a result of the downstream perceiving > > barriers ( > > real or not ) in incubating projects in upstream openstack. > > > >> > >> > >> I think it would be fairly difficult to get tripleo-ci to wholesale > >> adopt > >> tripleo-quickstart at this stage. The separate irc channel from > >> #tripleo > >> is not > >> conducive to consolidation on tooling and direction imo. > > > > > > The irc channel is easily addressed. We do seem to generate an awful > > amount > > of chatter though :) > > > >> > >> > >> The scope of quickstart is actually not fully understood by myself. > >> I've > >> also > >> heard from some in the upstream TripleO community as well who are > >> confused > >> by > >> its direction and are facing similar difficulties using its generated > >> bash > >> scripts that they'd be facing if they were just using TripleO > >> documentation > >> instead. > > > > > > The point of the generated bash scripts is to create rst documentation > > and > > reusable scripts for the end user. Since the documentation and the > > generated scripts are equivalent I would expect the same errors, > > problems > > and issues. I see this as a good thing really. We *want* the CI to hit > > the > > same issues as those who are following the doc. > > > >> > >> > >> I do think that this sort of problem lends itself easily to one off > >> implementations as is quite evidenced in this thread. Everyone/group > >> wants > >> and > >> needs to automate something in a different way. And imo, none of these > >> tools > >> are building end-user or operator facing interfaces, so they're not > >> fully > >> focused on building something that "just works for everyone". Those > >> interfaces > >> should be developed in TripleO user facing tooling anyway > >> (tripleoclient/openstackclient/etc). > >> > >> So, I actually think it's ok in some degree that things have been > >> automated > >> differently in different tools. Anecdotally, I suspect many users of > >> TripleO in > >> production have their own automation tools as well. And none of the > >> implementations mentioned in this thread would likely meet their needs > >> either. > > > > > > This is true.. without a tool in the upstream that addresses ci, dev, > > test > > use cases across the development cycle this will continue to be the > > case. I > > suspect even with a perfect tool, it won't ever be perfect for everyone. > > > >> > >> > >> However, if there is a desire to focus resources on consolidated > >> tooling > >> and > >> someone to drive it forward, then I definitely agree that the effort > >> needs > >> to > >> start upstream with a singular plan for tripleo-ci. From what I gather, > >> that > >> would be some sort of alignment and reuse of tripleo-quickstart, and > >> then > >> we > >> could build from there. > > > > > > +1 > > > >> > >> > >> That could start as a discussion and plan within that community with > >> some > >> agreed on concensus around that plan. There was an initial thread on > >> openstack-dev related to this topic but it is stalled a bit. It could > >> be > >> continually driven to resolution via specs, the tripleo meeting, email > >> or > >> irc > >> discussion until a plan is formed. > > > > > > +1, I think the first step is to complete the original blueprint and > > move > > on from there. > > I think there has also been interest in having an in person meeting at > > summit. > > > > Thanks! > > > >> > >> > >> -- > >> -- James Slagle > >> -- > >> > >> _______________________________________________ > >> 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 > > > > > > > > _______________________________________________ > > 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 > > I like how the discussion goes though I have some personal (and > probably shared) feeling that I would like to share here, more or less > related. > > As a TripleO core developer, I have some frustration to see that a lot > of people are involved in making TripleO Quickstart better, while we > have a few people actually working on tripleo-ci tool and try to > maintain upstream CI stable. > As a reminder, tripleo-ci tool is currently the ONLY ONE thing that > actually gates TripleO, even if we don't like the tool. It is right > now, testing TripleO upstream, everything that is not tested in there > will probably break one day downstream CIs. > Yes we have this tooling discussion here and that's awesome, but words > are words. I would like to see some real engagement to help TripleO CI > to converge into something better and not only everyone working on > their side. You have a valid point and reason to be frustrated. Is the point here that everyone downstream should use tripleo.sh or that everyone should be focused on ci and testing at the tripleo level?

> > > Some examples: > - TripleO Quickstart (downstream) CI has coverage for undercloud & > overcloud upgrades while TripleO CI freshly has a undercloud upgrade > job and used to have a overcloud (minor) upgrade job (disabled now, > for some reasons related to our capacity to run jobs and also some > blockers into code itself). > - TripleO CI has some TripleO Heat templates that could also be re-use > by TripleO Quickstart (I'm working on moving them from tripleo-ci to > THT, WIP here: https://review.openstack.org/350775). > - TripleO CI deploys Ceph Jewel repository, TripleO Quickstart doesn't. > - (...) As others have mentioned, there are at least 5-10 tools in development that are used to deploy tripleo in some CI fashion. Calling out tripleo-quickstart alone is not quite right imho. There are a number of tripleo devs that burn cycles on their own ci tools and maybe that is fine thing to do.

TripleO-Quickstart is meant to replace instack-virt-setup which it does quite well. The only group that was actually running instack-virt-setup was the RDO CI team, upstream had taken it out of the ci system. I think it's not unfair to say gaps have been left for other teams to fill.

> > > We have been having this discussion for a while now but we're still > not making much progress here, I feel like we're in statu quo. > James mentioned a blueprint, I like it. We need to engage some > upstream discussion about this major CI refactor, like we need with > specs and then we'll decide if whether or not we need to change the > tool, and how. Well, this would take some leadership imho. We need some people that are familiar with the upstream, midstream and downstream requirements of CI. This was addressed at the production chain meetings initially but then pretty much ignored. The leaders responsible at the various stages of a build (upstream -> downstream ) failed to take this issue on. Here we are today. Would it be acceptable by anyone.. IF tripleo-quickstart replaced instack-virt-setup [1] and walked through the undercloud install, then handed off to tripleo.sh to deploy, upgrade, update, scale, validate etc???

That these two tools *would* in fact be the the official CI tools of tripleo at the upstream, RDO, and at least parts of the downstream?

Would that help to ease the current frustration around CI? Emilien what do you think?

On Wed, Aug 3, 2016 at 7:38 PM, Wesley Hayutin <whayutin(a)redhat.com&gt; wrote: > > > On Wed, Aug 3, 2016 at 6:19 PM, Emilien Macchi <emilien(a)redhat.com&gt; wrote: >> >> On Wed, Aug 3, 2016 at 1:33 PM, Wesley Hayutin <whayutin(a)redhat.com&gt; >> wrote: >> > >> > >> > On Wed, Aug 3, 2016 at 12:51 PM, James Slagle <jslagle(a)redhat.com&gt; >> > wrote: >> >> >> >> On Wed, Aug 03, 2016 at 11:36:57AM -0400, David Moreau Simard wrote: >> >> > Please hear me out. >> >> > TL;DR, Let's work upstream and make it awesome so that downstream can >> >> > be awesome. >> >> > >> >> > I've said this before but I'm going to re-iterate that I do not >> >> > understand why there is so much effort spent around testing TripleO >> >> > downstream. >> >> > By downstream, I mean anything that isn't in TripleO or TripleO-CI >> >> > proper. >> >> > >> >> > All this work should be done upstream to make TripleO and it's CI >> >> > super awesome and this would trickle down for free downstream. >> >> > >> >> > The RDO Trunk testing pipeline is composed of two tools, today. >> >> > The TripleO-Quickstart project [1] is a good example of an initiative >> >> > that started downstream but always had the intention of being >> >> > proposed >> >> > upstream [2] after being "incubated" and fleshed out. >> >> >> >> tripleo-quickstart was proposed to upstream TripleO as a replacement >> >> for >> >> the >> >> virtual environment setup done by instack-virt-setup. 3rd party CI >> >> would >> >> be >> >> used to gate tripleo-quickstart so that we'd be sure the virt setup was >> >> always >> >> working. That was the extent of the CI scope defined in the spec. That >> >> work is >> >> not yet completed (see work items in the spec). >> >> >> >> Now it seems it is a much more all encompassing CI/automation/testing >> >> project >> >> that is competing in scope with tripleo-ci itself. >> > >> > >> > IMHO you are correct here. There has been quite a bit of discussion >> > about >> > removing the parts >> > of oooq that are outside of the original blueprint to replace >> > instack-virt-setup w/ oooq. As usual there are many different opinions >> > here. I think there are a lot of RDO guys that would prefer a lot of >> > the >> > native oooq roles stay where they are, I think that is short sighted >> > imho. >> > I agree that anything outside of the blueprint be removed from oooq. >> > This >> > would hopefully allow the upstream to be more comfortable with oooq and >> > allow us to really start consolidating tools. >> > >> > Luckily for the users that still want to use oooq as a full end-to-end >> > solution the 3rd party roles can be used even after tearing out these >> > native >> > roles. >> > >> >> >> >> >> >> I'm all for consolidation of these types of tools *if* there is >> >> interest. >> > >> > >> > Roll call.. is there interest? +1 from me. >> > >> >> >> >> >> >> However, IMO, incubating these things downstream and then trying to get >> >> them >> >> upstream or get upstream to adopt them is not ideal or a good example. >> >> The >> >> same >> >> topic came up and was pushed several times with khaleesi, and it just >> >> never >> >> happened, it was continually DOA upstream. >> > >> > >> > True, however that could be a result of the downstream perceiving >> > barriers ( >> > real or not ) in incubating projects in upstream openstack. >> > >> >> >> >> >> >> I think it would be fairly difficult to get tripleo-ci to wholesale >> >> adopt >> >> tripleo-quickstart at this stage. The separate irc channel from >> >> #tripleo >> >> is not >> >> conducive to consolidation on tooling and direction imo. >> > >> > >> > The irc channel is easily addressed. We do seem to generate an awful >> > amount >> > of chatter though :) >> > >> >> >> >> >> >> The scope of quickstart is actually not fully understood by myself. >> >> I've >> >> also >> >> heard from some in the upstream TripleO community as well who are >> >> confused >> >> by >> >> its direction and are facing similar difficulties using its generated >> >> bash >> >> scripts that they'd be facing if they were just using TripleO >> >> documentation >> >> instead. >> > >> > >> > The point of the generated bash scripts is to create rst documentation >> > and >> > reusable scripts for the end user. Since the documentation and the >> > generated scripts are equivalent I would expect the same errors, >> > problems >> > and issues. I see this as a good thing really. We *want* the CI to hit >> > the >> > same issues as those who are following the doc. >> > >> >> >> >> >> >> I do think that this sort of problem lends itself easily to one off >> >> implementations as is quite evidenced in this thread. Everyone/group >> >> wants >> >> and >> >> needs to automate something in a different way. And imo, none of these >> >> tools >> >> are building end-user or operator facing interfaces, so they're not >> >> fully >> >> focused on building something that "just works for everyone". Those >> >> interfaces >> >> should be developed in TripleO user facing tooling anyway >> >> (tripleoclient/openstackclient/etc). >> >> >> >> So, I actually think it's ok in some degree that things have been >> >> automated >> >> differently in different tools. Anecdotally, I suspect many users of >> >> TripleO in >> >> production have their own automation tools as well. And none of the >> >> implementations mentioned in this thread would likely meet their needs >> >> either. >> > >> > >> > This is true.. without a tool in the upstream that addresses ci, dev, >> > test >> > use cases across the development cycle this will continue to be the >> > case. I >> > suspect even with a perfect tool, it won't ever be perfect for everyone. >> > >> >> >> >> >> >> However, if there is a desire to focus resources on consolidated >> >> tooling >> >> and >> >> someone to drive it forward, then I definitely agree that the effort >> >> needs >> >> to >> >> start upstream with a singular plan for tripleo-ci. From what I gather, >> >> that >> >> would be some sort of alignment and reuse of tripleo-quickstart, and >> >> then >> >> we >> >> could build from there. >> > >> > >> > +1 >> > >> >> >> >> >> >> That could start as a discussion and plan within that community with >> >> some >> >> agreed on concensus around that plan. There was an initial thread on >> >> openstack-dev related to this topic but it is stalled a bit. It could >> >> be >> >> continually driven to resolution via specs, the tripleo meeting, email >> >> or >> >> irc >> >> discussion until a plan is formed. >> > >> > >> > +1, I think the first step is to complete the original blueprint and >> > move >> > on from there. >> > I think there has also been interest in having an in person meeting at >> > summit. >> > >> > Thanks! >> > >> >> >> >> >> >> -- >> >> -- James Slagle >> >> -- >> >> >> >> _______________________________________________ >> >> 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 >> > >> > >> > >> > _______________________________________________ >> > 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 >> >> I like how the discussion goes though I have some personal (and >> probably shared) feeling that I would like to share here, more or less >> related. >> >> As a TripleO core developer, I have some frustration to see that a lot >> of people are involved in making TripleO Quickstart better, while we >> have a few people actually working on tripleo-ci tool and try to >> maintain upstream CI stable. >> As a reminder, tripleo-ci tool is currently the ONLY ONE thing that >> actually gates TripleO, even if we don't like the tool. It is right >> now, testing TripleO upstream, everything that is not tested in there >> will probably break one day downstream CIs. >> Yes we have this tooling discussion here and that's awesome, but words >> are words. I would like to see some real engagement to help TripleO CI >> to converge into something better and not only everyone working on >> their side. > > > You have a valid point and reason to be frustrated. > Is the point here that everyone downstream should use tripleo.sh or that > everyone should be focused on ci and testing at the tripleo level? Not everyone should use tripleo.sh. My point is that we should move forward with a common tool, and stop enlarging the gap between tools. We have created (and are still doing) a technical dept where we have multiple tools with a ton of overlap, the more we wait, more difficult it will be to clean this up. >> >> >> Some examples: >> - TripleO Quickstart (downstream) CI has coverage for undercloud & >> overcloud upgrades while TripleO CI freshly has a undercloud upgrade >> job and used to have a overcloud (minor) upgrade job (disabled now, >> for some reasons related to our capacity to run jobs and also some >> blockers into code itself). >> - TripleO CI has some TripleO Heat templates that could also be re-use >> by TripleO Quickstart (I'm working on moving them from tripleo-ci to >> THT, WIP here: https://review.openstack.org/350775). >> - TripleO CI deploys Ceph Jewel repository, TripleO Quickstart doesn't. >> - (...) > > > As others have mentioned, there are at least 5-10 tools in development that > are used to deploy tripleo in some CI fashion. Calling out > tripleo-quickstart alone is not quite right imho. There are a number of > tripleo devs that burn cycles on their own ci tools and maybe that is fine > thing to do. I called quickstart because that's the one I see everyday but my frustration is about all our tools in general. I'm actually a OOOQ user and I like this tool, really. But as you can see, I'm also working on tripleo-ci right now because I want TripleO CI better and I haven't seen until now some interest to converge. James started something cool by trying to deploy an undercloud using OOOQ from tripleo-ci. That's a start ! We need things like this, prototyping convergence, and see what we can do. > TripleO-Quickstart is meant to replace instack-virt-setup which it does > quite well. The only group that was actually running instack-virt-setup > was the RDO CI team, upstream had taken it out of the ci system. I think > it's not unfair to say gaps have been left for other teams to fill. Gotcha. It was just some examples. >> >> >> We have been having this discussion for a while now but we're still >> not making much progress here, I feel like we're in statu quo. >> James mentioned a blueprint, I like it. We need to engage some >> upstream discussion about this major CI refactor, like we need with >> specs and then we'll decide if whether or not we need to change the >> tool, and how. > > > Well, this would take some leadership imho. We need some people that are > familiar with the upstream, midstream and downstream requirements of CI. > This was addressed at the production chain meetings initially but then > pretty much ignored. The leaders responsible at the various stages of a > build (upstream -> downstream ) failed to take this issue on. Here we are > today. > > Would it be acceptable by anyone.. IF > > tripleo-quickstart replaced instack-virt-setup [1] and walked through the > undercloud install, then handed off to tripleo.sh to deploy, upgrade, > update, scale, validate etc??? That's something we can try. > That these two tools *would* in fact be the the official CI tools of tripleo > at the upstream, RDO, and at least parts of the downstream? My opinion on this is that upstream and downstream CI should only differ on: * the packages (OSP vs RDO) * the scenarios (downstream could have customer-specific things) And that's it. Tools should remain the same IMHO. > Would that help to ease the current frustration around CI? Emilien what do > you think? I spent the last months working on composable roles and I have now more time to work on CI; $topic is definitely something where I would like to help. -- Emilien Macchi _______________________________________________ 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

Resurrecting a old thread... On Thu, Aug 4, 2016 at 5:10 AM, Tal Kammer <tkammer(a)redhat.com&gt; wrote: > Reading this through I can't help but feel that once again we are straying > from the original intent of the discussion. > I also share the same feeling as Emilien and believe we should focus our > efforts on where it matters rather than having each group focus on one part > trying to "win" over the other. > > My concern since day 1 was that no one has asked what are the requirements > of each group and how does the tool serve that requirement. Simply put, the > requirement was "we need a CI tool" while I feel that the question of "what > is a CI tool?" or "what/who does it need to serve?" was never raised and was > left to self interpretation. > The result became that each group started working according to its own > understanding of a "CI tool" and I feel that even now, going over the e-mail > thread, this question is left unanswered. Wouldn't things be better if we as a collective team standardize on a "CI Tool"? > > I believe that in order to achieve a consensus around a tool, we should at > least agree first on the needs. > Some questions that come to mind: (feel free to pitch in more questions) > 1. should the tool provide provisioning? if yes, what type? (virsh? > openstack? foreman? etc..) --> this can be further discussed as it's quite a > subject to cover > 2. should the tool be Ansible based / other language? > 3. where do we push / maintain this tool? (I believe 'upstream' is the > answer but before it can officially accepted, we need a "midstream" place to > hold it) > 4. what other requirements does this tool needs to support? (does it need to > include testing as well? what is the proper "plugin" mechanism to maintain, > etc) > > Once we understand the above, we can ask: > 1. "is oooq the right tool to use/push upstream?" (maybe one of the other > projects like Octario, Weirdo, InfraRed, etc, has a better base / better > suited for the job?) > 2. "what are we looking for in such a tool?" (are we developing a tool for > CI? for Automation? can it be shared across products/projects or dedicated > Openstack tool? etc..) Khaleesi, InfraRed, and OOOQ, what is next? Within the scale and performance team we have been developing performance CI which is integrated with oooq. Since a different group uses InfraRed, they cannot take advantage of the work we have already done with oooq -- and this is much larger then just running tests. We have playbooks to monitor performance metrics of the under/overcloud so you can trend if memory usage is growing with each release/puddle/poodle (or whatever we call them now). From my view, we are telling the community to choose which "CI tool" to go with. Instead we should converge on a single tool, and improve on that tool - fill whatever gaps exist. > > I propose that all CI groups meet up and present their tool to each other. > After that, we should have an open discussion on the pros and cons of each > tool allowing everyone to comment on the design openly. > Then after everyone shared their thoughts, we can start improving / create a > proper tool from the experience of everyone. > Whether it will be oooq based, InfraRed based or Octario based, it really > doesn't matter, as long as there is an open discussion (ego aside) and an > honest decision between all parties on how we can improve, we can get to > where everyone is aiming, a truly collaborative project by all groups. > > Thoughts? I agree, agenda's aside, egos left at the door. Let's come to some conclusion on what as a community we move forward with.

> > On Thu, Aug 4, 2016 at 3:45 AM, Emilien Macchi <emilien(a)redhat.com&gt; wrote: >> >> On Wed, Aug 3, 2016 at 7:38 PM, Wesley Hayutin <whayutin(a)redhat.com&gt; >> wrote: >> > >> > >> > On Wed, Aug 3, 2016 at 6:19 PM, Emilien Macchi <emilien(a)redhat.com&gt; >> > wrote: >> >> >> >> On Wed, Aug 3, 2016 at 1:33 PM, Wesley Hayutin <whayutin(a)redhat.com&gt; >> >> wrote: >> >> > >> >> > >> >> > On Wed, Aug 3, 2016 at 12:51 PM, James Slagle <jslagle(a)redhat.com&gt; >> >> > wrote: >> >> >> >> >> >> On Wed, Aug 03, 2016 at 11:36:57AM -0400, David Moreau Simard wrote: >> >> >> > Please hear me out. >> >> >> > TL;DR, Let's work upstream and make it awesome so that downstream >> >> >> > can >> >> >> > be awesome. >> >> >> > >> >> >> > I've said this before but I'm going to re-iterate that I do not >> >> >> > understand why there is so much effort spent around testing >> >> >> > TripleO >> >> >> > downstream. >> >> >> > By downstream, I mean anything that isn't in TripleO or TripleO-CI >> >> >> > proper. >> >> >> > >> >> >> > All this work should be done upstream to make TripleO and it's CI >> >> >> > super awesome and this would trickle down for free downstream. >> >> >> > >> >> >> > The RDO Trunk testing pipeline is composed of two tools, today. >> >> >> > The TripleO-Quickstart project [1] is a good example of an >> >> >> > initiative >> >> >> > that started downstream but always had the intention of being >> >> >> > proposed >> >> >> > upstream [2] after being "incubated" and fleshed out. >> >> >> >> >> >> tripleo-quickstart was proposed to upstream TripleO as a replacement >> >> >> for >> >> >> the >> >> >> virtual environment setup done by instack-virt-setup. 3rd party CI >> >> >> would >> >> >> be >> >> >> used to gate tripleo-quickstart so that we'd be sure the virt setup >> >> >> was >> >> >> always >> >> >> working. That was the extent of the CI scope defined in the spec. >> >> >> That >> >> >> work is >> >> >> not yet completed (see work items in the spec). >> >> >> >> >> >> Now it seems it is a much more all encompassing >> >> >> CI/automation/testing >> >> >> project >> >> >> that is competing in scope with tripleo-ci itself. >> >> > >> >> > >> >> > IMHO you are correct here. There has been quite a bit of discussion >> >> > about >> >> > removing the parts >> >> > of oooq that are outside of the original blueprint to replace >> >> > instack-virt-setup w/ oooq. As usual there are many different >> >> > opinions >> >> > here. I think there are a lot of RDO guys that would prefer a lot of >> >> > the >> >> > native oooq roles stay where they are, I think that is short sighted >> >> > imho. >> >> > I agree that anything outside of the blueprint be removed from oooq. >> >> > This >> >> > would hopefully allow the upstream to be more comfortable with oooq >> >> > and >> >> > allow us to really start consolidating tools. >> >> > >> >> > Luckily for the users that still want to use oooq as a full >> >> > end-to-end >> >> > solution the 3rd party roles can be used even after tearing out these >> >> > native >> >> > roles. >> >> > >> >> >> >> >> >> >> >> >> I'm all for consolidation of these types of tools *if* there is >> >> >> interest. >> >> > >> >> > >> >> > Roll call.. is there interest? +1 from me. >> >> > >> >> >> >> >> >> >> >> >> However, IMO, incubating these things downstream and then trying to >> >> >> get >> >> >> them >> >> >> upstream or get upstream to adopt them is not ideal or a good >> >> >> example. >> >> >> The >> >> >> same >> >> >> topic came up and was pushed several times with khaleesi, and it >> >> >> just >> >> >> never >> >> >> happened, it was continually DOA upstream. >> >> > >> >> > >> >> > True, however that could be a result of the downstream perceiving >> >> > barriers ( >> >> > real or not ) in incubating projects in upstream openstack. >> >> > >> >> >> >> >> >> >> >> >> I think it would be fairly difficult to get tripleo-ci to wholesale >> >> >> adopt >> >> >> tripleo-quickstart at this stage. The separate irc channel from >> >> >> #tripleo >> >> >> is not >> >> >> conducive to consolidation on tooling and direction imo. >> >> > >> >> > >> >> > The irc channel is easily addressed. We do seem to generate an awful >> >> > amount >> >> > of chatter though :) >> >> > >> >> >> >> >> >> >> >> >> The scope of quickstart is actually not fully understood by myself. >> >> >> I've >> >> >> also >> >> >> heard from some in the upstream TripleO community as well who are >> >> >> confused >> >> >> by >> >> >> its direction and are facing similar difficulties using its >> >> >> generated >> >> >> bash >> >> >> scripts that they'd be facing if they were just using TripleO >> >> >> documentation >> >> >> instead. >> >> > >> >> > >> >> > The point of the generated bash scripts is to create rst >> >> > documentation >> >> > and >> >> > reusable scripts for the end user. Since the documentation and the >> >> > generated scripts are equivalent I would expect the same errors, >> >> > problems >> >> > and issues. I see this as a good thing really. We *want* the CI to >> >> > hit >> >> > the >> >> > same issues as those who are following the doc. >> >> > >> >> >> >> >> >> >> >> >> I do think that this sort of problem lends itself easily to one off >> >> >> implementations as is quite evidenced in this thread. Everyone/group >> >> >> wants >> >> >> and >> >> >> needs to automate something in a different way. And imo, none of >> >> >> these >> >> >> tools >> >> >> are building end-user or operator facing interfaces, so they're not >> >> >> fully >> >> >> focused on building something that "just works for everyone". Those >> >> >> interfaces >> >> >> should be developed in TripleO user facing tooling anyway >> >> >> (tripleoclient/openstackclient/etc). >> >> >> >> >> >> So, I actually think it's ok in some degree that things have been >> >> >> automated >> >> >> differently in different tools. Anecdotally, I suspect many users of >> >> >> TripleO in >> >> >> production have their own automation tools as well. And none of the >> >> >> implementations mentioned in this thread would likely meet their >> >> >> needs >> >> >> either. >> >> > >> >> > >> >> > This is true.. without a tool in the upstream that addresses ci, >> >> > dev, >> >> > test >> >> > use cases across the development cycle this will continue to be the >> >> > case. I >> >> > suspect even with a perfect tool, it won't ever be perfect for >> >> > everyone. >> >> > >> >> >> >> >> >> >> >> >> However, if there is a desire to focus resources on consolidated >> >> >> tooling >> >> >> and >> >> >> someone to drive it forward, then I definitely agree that the effort >> >> >> needs >> >> >> to >> >> >> start upstream with a singular plan for tripleo-ci. From what I >> >> >> gather, >> >> >> that >> >> >> would be some sort of alignment and reuse of tripleo-quickstart, and >> >> >> then >> >> >> we >> >> >> could build from there. >> >> > >> >> > >> >> > +1 >> >> > >> >> >> >> >> >> >> >> >> That could start as a discussion and plan within that community with >> >> >> some >> >> >> agreed on concensus around that plan. There was an initial thread on >> >> >> openstack-dev related to this topic but it is stalled a bit. It >> >> >> could >> >> >> be >> >> >> continually driven to resolution via specs, the tripleo meeting, >> >> >> email >> >> >> or >> >> >> irc >> >> >> discussion until a plan is formed. >> >> > >> >> > >> >> > +1, I think the first step is to complete the original blueprint and >> >> > move >> >> > on from there. >> >> > I think there has also been interest in having an in person meeting >> >> > at >> >> > summit. >> >> > >> >> > Thanks! >> >> > >> >> >> >> >> >> >> >> >> -- >> >> >> -- James Slagle >> >> >> -- >> >> >> >> >> >> _______________________________________________ >> >> >> 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 >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > 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 >> >> >> >> I like how the discussion goes though I have some personal (and >> >> probably shared) feeling that I would like to share here, more or less >> >> related. >> >> >> >> As a TripleO core developer, I have some frustration to see that a lot >> >> of people are involved in making TripleO Quickstart better, while we >> >> have a few people actually working on tripleo-ci tool and try to >> >> maintain upstream CI stable. >> >> As a reminder, tripleo-ci tool is currently the ONLY ONE thing that >> >> actually gates TripleO, even if we don't like the tool. It is right >> >> now, testing TripleO upstream, everything that is not tested in there >> >> will probably break one day downstream CIs. >> >> Yes we have this tooling discussion here and that's awesome, but words >> >> are words. I would like to see some real engagement to help TripleO CI >> >> to converge into something better and not only everyone working on >> >> their side. >> > >> > >> > You have a valid point and reason to be frustrated. >> > Is the point here that everyone downstream should use tripleo.sh or that >> > everyone should be focused on ci and testing at the tripleo level? >> >> Not everyone should use tripleo.sh. My point is that we should move >> forward with a common tool, and stop enlarging the gap between tools. >> We have created (and are still doing) a technical dept where we have >> multiple tools with a ton of overlap, the more we wait, more difficult >> it will be to clean this up. >> >> >> >> >> >> >> Some examples: >> >> - TripleO Quickstart (downstream) CI has coverage for undercloud & >> >> overcloud upgrades while TripleO CI freshly has a undercloud upgrade >> >> job and used to have a overcloud (minor) upgrade job (disabled now, >> >> for some reasons related to our capacity to run jobs and also some >> >> blockers into code itself). >> >> - TripleO CI has some TripleO Heat templates that could also be re-use >> >> by TripleO Quickstart (I'm working on moving them from tripleo-ci to >> >> THT, WIP here: https://review.openstack.org/350775). >> >> - TripleO CI deploys Ceph Jewel repository, TripleO Quickstart doesn't. >> >> - (...) >> > >> > >> > As others have mentioned, there are at least 5-10 tools in development >> > that >> > are used to deploy tripleo in some CI fashion. Calling out >> > tripleo-quickstart alone is not quite right imho. There are a number >> > of >> > tripleo devs that burn cycles on their own ci tools and maybe that is >> > fine >> > thing to do. >> >> I called quickstart because that's the one I see everyday but my >> frustration is about all our tools in general. >> I'm actually a OOOQ user and I like this tool, really. >> But as you can see, I'm also working on tripleo-ci right now because I >> want TripleO CI better and I haven't seen until now some interest to >> converge. >> James started something cool by trying to deploy an undercloud using >> OOOQ from tripleo-ci. That's a start ! We need things like this, >> prototyping convergence, and see what we can do. >> >> > TripleO-Quickstart is meant to replace instack-virt-setup which it does >> > quite well. The only group that was actually running >> > instack-virt-setup >> > was the RDO CI team, upstream had taken it out of the ci system. I >> > think >> > it's not unfair to say gaps have been left for other teams to fill. >> >> Gotcha. It was just some examples. >> >> >> >> >> >> >> We have been having this discussion for a while now but we're still >> >> not making much progress here, I feel like we're in statu quo. >> >> James mentioned a blueprint, I like it. We need to engage some >> >> upstream discussion about this major CI refactor, like we need with >> >> specs and then we'll decide if whether or not we need to change the >> >> tool, and how. >> > >> > >> > Well, this would take some leadership imho. We need some people that >> > are >> > familiar with the upstream, midstream and downstream requirements of CI. >> > This was addressed at the production chain meetings initially but then >> > pretty much ignored. The leaders responsible at the various stages of >> > a >> > build (upstream -> downstream ) failed to take this issue on. Here we >> > are >> > today. >> > >> > Would it be acceptable by anyone.. IF >> > >> > tripleo-quickstart replaced instack-virt-setup [1] and walked through >> > the >> > undercloud install, then handed off to tripleo.sh to deploy, upgrade, >> > update, scale, validate etc??? >> >> That's something we can try. >> >> > That these two tools *would* in fact be the the official CI tools of >> > tripleo >> > at the upstream, RDO, and at least parts of the downstream? >> >> My opinion on this is that upstream and downstream CI should only differ >> on: >> * the packages (OSP vs RDO) >> * the scenarios (downstream could have customer-specific things) >> And that's it. Tools should remain the same IMHO. >> >> > Would that help to ease the current frustration around CI? Emilien what >> > do >> > you think? >> >> I spent the last months working on composable roles and I have now >> more time to work on CI; $topic is definitely something where I would >> like to help. >> -- >> Emilien Macchi >> >> _______________________________________________ >> 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 > > > > > -- > Tal Kammer > Associate manager, automation and infrastracture, Openstack platform. > Red Hat Israel > Automation group mojo: https://mojo.redhat.com/docs/DOC-1011659 > > _______________________________________________ > 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

On Wed, Aug 3, 2016 at 7:38 PM, Wesley Hayutin <whayutin(a)redhat.com&gt; wrote: > > > On Wed, Aug 3, 2016 at 6:19 PM, Emilien Macchi <emilien(a)redhat.com&gt; wrote: >> >> On Wed, Aug 3, 2016 at 1:33 PM, Wesley Hayutin <whayutin(a)redhat.com&gt; >> wrote: >> > >> > >> > On Wed, Aug 3, 2016 at 12:51 PM, James Slagle <jslagle(a)redhat.com&gt; >> > wrote: >> >> >> >> On Wed, Aug 03, 2016 at 11:36:57AM -0400, David Moreau Simard wrote: >> >> > Please hear me out. >> >> > TL;DR, Let's work upstream and make it awesome so that downstream can >> >> > be awesome. >> >> > >> >> > I've said this before but I'm going to re-iterate that I do not >> >> > understand why there is so much effort spent around testing TripleO >> >> > downstream. >> >> > By downstream, I mean anything that isn't in TripleO or TripleO-CI >> >> > proper. >> >> > >> >> > All this work should be done upstream to make TripleO and it's CI >> >> > super awesome and this would trickle down for free downstream. >> >> > >> >> > The RDO Trunk testing pipeline is composed of two tools, today. >> >> > The TripleO-Quickstart project [1] is a good example of an initiative >> >> > that started downstream but always had the intention of being >> >> > proposed >> >> > upstream [2] after being "incubated" and fleshed out. >> >> >> >> tripleo-quickstart was proposed to upstream TripleO as a replacement >> >> for >> >> the >> >> virtual environment setup done by instack-virt-setup. 3rd party CI >> >> would >> >> be >> >> used to gate tripleo-quickstart so that we'd be sure the virt setup was >> >> always >> >> working. That was the extent of the CI scope defined in the spec. That >> >> work is >> >> not yet completed (see work items in the spec). >> >> >> >> Now it seems it is a much more all encompassing CI/automation/testing >> >> project >> >> that is competing in scope with tripleo-ci itself. >> > >> > >> > IMHO you are correct here. There has been quite a bit of discussion >> > about >> > removing the parts >> > of oooq that are outside of the original blueprint to replace >> > instack-virt-setup w/ oooq. As usual there are many different opinions >> > here. I think there are a lot of RDO guys that would prefer a lot of >> > the >> > native oooq roles stay where they are, I think that is short sighted >> > imho. >> > I agree that anything outside of the blueprint be removed from oooq. >> > This >> > would hopefully allow the upstream to be more comfortable with oooq and >> > allow us to really start consolidating tools. >> > >> > Luckily for the users that still want to use oooq as a full end-to-end >> > solution the 3rd party roles can be used even after tearing out these >> > native >> > roles. >> > >> >> >> >> >> >> I'm all for consolidation of these types of tools *if* there is >> >> interest. >> > >> > >> > Roll call.. is there interest? +1 from me. >> > >> >> >> >> >> >> However, IMO, incubating these things downstream and then trying to get >> >> them >> >> upstream or get upstream to adopt them is not ideal or a good example. >> >> The >> >> same >> >> topic came up and was pushed several times with khaleesi, and it just >> >> never >> >> happened, it was continually DOA upstream. >> > >> > >> > True, however that could be a result of the downstream perceiving >> > barriers ( >> > real or not ) in incubating projects in upstream openstack. >> > >> >> >> >> >> >> I think it would be fairly difficult to get tripleo-ci to wholesale >> >> adopt >> >> tripleo-quickstart at this stage. The separate irc channel from >> >> #tripleo >> >> is not >> >> conducive to consolidation on tooling and direction imo. >> > >> > >> > The irc channel is easily addressed. We do seem to generate an awful >> > amount >> > of chatter though :) >> > >> >> >> >> >> >> The scope of quickstart is actually not fully understood by myself. >> >> I've >> >> also >> >> heard from some in the upstream TripleO community as well who are >> >> confused >> >> by >> >> its direction and are facing similar difficulties using its generated >> >> bash >> >> scripts that they'd be facing if they were just using TripleO >> >> documentation >> >> instead. >> > >> > >> > The point of the generated bash scripts is to create rst documentation >> > and >> > reusable scripts for the end user. Since the documentation and the >> > generated scripts are equivalent I would expect the same errors, >> > problems >> > and issues. I see this as a good thing really. We *want* the CI to hit >> > the >> > same issues as those who are following the doc. >> > >> >> >> >> >> >> I do think that this sort of problem lends itself easily to one off >> >> implementations as is quite evidenced in this thread. Everyone/group >> >> wants >> >> and >> >> needs to automate something in a different way. And imo, none of these >> >> tools >> >> are building end-user or operator facing interfaces, so they're not >> >> fully >> >> focused on building something that "just works for everyone". Those >> >> interfaces >> >> should be developed in TripleO user facing tooling anyway >> >> (tripleoclient/openstackclient/etc). >> >> >> >> So, I actually think it's ok in some degree that things have been >> >> automated >> >> differently in different tools. Anecdotally, I suspect many users of >> >> TripleO in >> >> production have their own automation tools as well. And none of the >> >> implementations mentioned in this thread would likely meet their needs >> >> either. >> > >> > >> > This is true.. without a tool in the upstream that addresses ci, dev, >> > test >> > use cases across the development cycle this will continue to be the >> > case. I >> > suspect even with a perfect tool, it won't ever be perfect for everyone. >> > >> >> >> >> >> >> However, if there is a desire to focus resources on consolidated >> >> tooling >> >> and >> >> someone to drive it forward, then I definitely agree that the effort >> >> needs >> >> to >> >> start upstream with a singular plan for tripleo-ci. From what I gather, >> >> that >> >> would be some sort of alignment and reuse of tripleo-quickstart, and >> >> then >> >> we >> >> could build from there. >> > >> > >> > +1 >> > >> >> >> >> >> >> That could start as a discussion and plan within that community with >> >> some >> >> agreed on concensus around that plan. There was an initial thread on >> >> openstack-dev related to this topic but it is stalled a bit. It could >> >> be >> >> continually driven to resolution via specs, the tripleo meeting, email >> >> or >> >> irc >> >> discussion until a plan is formed. >> > >> > >> > +1, I think the first step is to complete the original blueprint and >> > move >> > on from there. >> > I think there has also been interest in having an in person meeting at >> > summit. >> > >> > Thanks! >> > >> >> >> >> >> >> -- >> >> -- James Slagle >> >> -- >> >> >> >> _______________________________________________ >> >> 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 >> > >> > >> > >> > _______________________________________________ >> > 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 >> >> I like how the discussion goes though I have some personal (and >> probably shared) feeling that I would like to share here, more or less >> related. >> >> As a TripleO core developer, I have some frustration to see that a lot >> of people are involved in making TripleO Quickstart better, while we >> have a few people actually working on tripleo-ci tool and try to >> maintain upstream CI stable. >> As a reminder, tripleo-ci tool is currently the ONLY ONE thing that >> actually gates TripleO, even if we don't like the tool. It is right >> now, testing TripleO upstream, everything that is not tested in there >> will probably break one day downstream CIs. >> Yes we have this tooling discussion here and that's awesome, but words >> are words. I would like to see some real engagement to help TripleO CI >> to converge into something better and not only everyone working on >> their side. > > > You have a valid point and reason to be frustrated. > Is the point here that everyone downstream should use tripleo.sh or that > everyone should be focused on ci and testing at the tripleo level? Not everyone should use tripleo.sh. My point is that we should move forward with a common tool, and stop enlarging the gap between tools. We have created (and are still doing) a technical dept where we have multiple tools with a ton of overlap, the more we wait, more difficult it will be to clean this up.

>> >> >> Some examples: >> - TripleO Quickstart (downstream) CI has coverage for undercloud & >> overcloud upgrades while TripleO CI freshly has a undercloud upgrade >> job and used to have a overcloud (minor) upgrade job (disabled now, >> for some reasons related to our capacity to run jobs and also some >> blockers into code itself). >> - TripleO CI has some TripleO Heat templates that could also be re-use >> by TripleO Quickstart (I'm working on moving them from tripleo-ci to >> THT, WIP here: https://review.openstack.org/350775). >> - TripleO CI deploys Ceph Jewel repository, TripleO Quickstart doesn't. >> - (...) > > > As others have mentioned, there are at least 5-10 tools in development that > are used to deploy tripleo in some CI fashion. Calling out > tripleo-quickstart alone is not quite right imho. There are a number of > tripleo devs that burn cycles on their own ci tools and maybe that is fine > thing to do. I called quickstart because that's the one I see everyday but my frustration is about all our tools in general. I'm actually a OOOQ user and I like this tool, really. But as you can see, I'm also working on tripleo-ci right now because I want TripleO CI better and I haven't seen until now some interest to converge. James started something cool by trying to deploy an undercloud using OOOQ from tripleo-ci. That's a start ! We need things like this, prototyping convergence, and see what we can do.

> TripleO-Quickstart is meant to replace instack-virt-setup which it does > quite well. The only group that was actually running instack-virt-setup > was the RDO CI team, upstream had taken it out of the ci system. I think > it's not unfair to say gaps have been left for other teams to fill. Gotcha. It was just some examples. >> >> >> We have been having this discussion for a while now but we're still >> not making much progress here, I feel like we're in statu quo. >> James mentioned a blueprint, I like it. We need to engage some >> upstream discussion about this major CI refactor, like we need with >> specs and then we'll decide if whether or not we need to change the >> tool, and how. > > > Well, this would take some leadership imho. We need some people that are > familiar with the upstream, midstream and downstream requirements of CI. > This was addressed at the production chain meetings initially but then > pretty much ignored. The leaders responsible at the various stages of a > build (upstream -> downstream ) failed to take this issue on. Here we are > today. > > Would it be acceptable by anyone.. IF > > tripleo-quickstart replaced instack-virt-setup [1] and walked through the > undercloud install, then handed off to tripleo.sh to deploy, upgrade, > update, scale, validate etc??? That's something we can try. > That these two tools *would* in fact be the the official CI tools of tripleo > at the upstream, RDO, and at least parts of the downstream? My opinion on this is that upstream and downstream CI should only differ on: * the packages (OSP vs RDO) * the scenarios (downstream could have customer-specific things) And that's it. Tools should remain the same IMHO. > Would that help to ease the current frustration around CI? Emilien what do > you think? I spent the last months working on composable roles and I have now more time to work on CI; $topic is definitely something where I would like to help.

-- Emilien Macchi

On Thu, Aug 4, 2016 at 9:43 AM, Wesley Hayutin <whayutin(a)redhat.com&gt; wrote: > > > On Wed, Aug 3, 2016 at 8:45 PM, Emilien Macchi <emilien(a)redhat.com&gt; > wrote: > >> On Wed, Aug 3, 2016 at 7:38 PM, Wesley Hayutin <whayutin(a)redhat.com&gt; >> wrote: >> > >> > >> > On Wed, Aug 3, 2016 at 6:19 PM, Emilien Macchi <emilien(a)redhat.com&gt; >> wrote: >> >> >> >> On Wed, Aug 3, 2016 at 1:33 PM, Wesley Hayutin <whayutin(a)redhat.com&gt; >> >> wrote: >> >> > >> >> > >> >> > On Wed, Aug 3, 2016 at 12:51 PM, James Slagle <jslagle(a)redhat.com&gt; >> >> > wrote: >> >> >> >> >> >> On Wed, Aug 03, 2016 at 11:36:57AM -0400, David Moreau Simard >> wrote: >> >> >> > Please hear me out. >> >> >> > TL;DR, Let's work upstream and make it awesome so that >> downstream can >> >> >> > be awesome. >> >> >> > >> >> >> > I've said this before but I'm going to re-iterate that I do not >> >> >> > understand why there is so much effort spent around testing >> TripleO >> >> >> > downstream. >> >> >> > By downstream, I mean anything that isn't in TripleO or >> TripleO-CI >> >> >> > proper. >> >> >> > >> >> >> > All this work should be done upstream to make TripleO and it's CI >> >> >> > super awesome and this would trickle down for free downstream. >> >> >> > >> >> >> > The RDO Trunk testing pipeline is composed of two tools, today. >> >> >> > The TripleO-Quickstart project [1] is a good example of an >> initiative >> >> >> > that started downstream but always had the intention of being >> >> >> > proposed >> >> >> > upstream [2] after being "incubated" and fleshed out. >> >> >> >> >> >> tripleo-quickstart was proposed to upstream TripleO as a >> replacement >> >> >> for >> >> >> the >> >> >> virtual environment setup done by instack-virt-setup. 3rd party CI >> >> >> would >> >> >> be >> >> >> used to gate tripleo-quickstart so that we'd be sure the virt >> setup was >> >> >> always >> >> >> working. That was the extent of the CI scope defined in the spec. >> That >> >> >> work is >> >> >> not yet completed (see work items in the spec). >> >> >> >> >> >> Now it seems it is a much more all encompassing >> CI/automation/testing >> >> >> project >> >> >> that is competing in scope with tripleo-ci itself. >> >> > >> >> > >> >> > IMHO you are correct here. There has been quite a bit of discussion >> >> > about >> >> > removing the parts >> >> > of oooq that are outside of the original blueprint to replace >> >> > instack-virt-setup w/ oooq. As usual there are many different >> opinions >> >> > here. I think there are a lot of RDO guys that would prefer a lot >> of >> >> > the >> >> > native oooq roles stay where they are, I think that is short >> sighted >> >> > imho. >> >> > I agree that anything outside of the blueprint be removed from oooq. >> >> > This >> >> > would hopefully allow the upstream to be more comfortable with oooq >> and >> >> > allow us to really start consolidating tools. >> >> > >> >> > Luckily for the users that still want to use oooq as a full >> end-to-end >> >> > solution the 3rd party roles can be used even after tearing out >> these >> >> > native >> >> > roles. >> >> > >> >> >> >> >> >> >> >> >> I'm all for consolidation of these types of tools *if* there is >> >> >> interest. >> >> > >> >> > >> >> > Roll call.. is there interest? +1 from me. >> >> > >> >> >> >> >> >> >> >> >> However, IMO, incubating these things downstream and then trying >> to get >> >> >> them >> >> >> upstream or get upstream to adopt them is not ideal or a good >> example. >> >> >> The >> >> >> same >> >> >> topic came up and was pushed several times with khaleesi, and it >> just >> >> >> never >> >> >> happened, it was continually DOA upstream. >> >> > >> >> > >> >> > True, however that could be a result of the downstream perceiving >> >> > barriers ( >> >> > real or not ) in incubating projects in upstream openstack. >> >> > >> >> >> >> >> >> >> >> >> I think it would be fairly difficult to get tripleo-ci to wholesale >> >> >> adopt >> >> >> tripleo-quickstart at this stage. The separate irc channel from >> >> >> #tripleo >> >> >> is not >> >> >> conducive to consolidation on tooling and direction imo. >> >> > >> >> > >> >> > The irc channel is easily addressed. We do seem to generate an >> awful >> >> > amount >> >> > of chatter though :) >> >> > >> >> >> >> >> >> >> >> >> The scope of quickstart is actually not fully understood by myself. >> >> >> I've >> >> >> also >> >> >> heard from some in the upstream TripleO community as well who are >> >> >> confused >> >> >> by >> >> >> its direction and are facing similar difficulties using its >> generated >> >> >> bash >> >> >> scripts that they'd be facing if they were just using TripleO >> >> >> documentation >> >> >> instead. >> >> > >> >> > >> >> > The point of the generated bash scripts is to create rst >> documentation >> >> > and >> >> > reusable scripts for the end user. Since the documentation and the >> >> > generated scripts are equivalent I would expect the same errors, >> >> > problems >> >> > and issues. I see this as a good thing really. We *want* the CI >> to hit >> >> > the >> >> > same issues as those who are following the doc. >> >> > >> >> >> >> >> >> >> >> >> I do think that this sort of problem lends itself easily to one off >> >> >> implementations as is quite evidenced in this thread. >> Everyone/group >> >> >> wants >> >> >> and >> >> >> needs to automate something in a different way. And imo, none of >> these >> >> >> tools >> >> >> are building end-user or operator facing interfaces, so they're not >> >> >> fully >> >> >> focused on building something that "just works for everyone". Those >> >> >> interfaces >> >> >> should be developed in TripleO user facing tooling anyway >> >> >> (tripleoclient/openstackclient/etc). >> >> >> >> >> >> So, I actually think it's ok in some degree that things have been >> >> >> automated >> >> >> differently in different tools. Anecdotally, I suspect many users >> of >> >> >> TripleO in >> >> >> production have their own automation tools as well. And none of the >> >> >> implementations mentioned in this thread would likely meet their >> needs >> >> >> either. >> >> > >> >> > >> >> > This is true.. without a tool in the upstream that addresses ci, >> dev, >> >> > test >> >> > use cases across the development cycle this will continue to be the >> >> > case. I >> >> > suspect even with a perfect tool, it won't ever be perfect for >> everyone. >> >> > >> >> >> >> >> >> >> >> >> However, if there is a desire to focus resources on consolidated >> >> >> tooling >> >> >> and >> >> >> someone to drive it forward, then I definitely agree that the >> effort >> >> >> needs >> >> >> to >> >> >> start upstream with a singular plan for tripleo-ci. From what I >> gather, >> >> >> that >> >> >> would be some sort of alignment and reuse of tripleo-quickstart, >> and >> >> >> then >> >> >> we >> >> >> could build from there. >> >> > >> >> > >> >> > +1 >> >> > >> >> >> >> >> >> >> >> >> That could start as a discussion and plan within that community >> with >> >> >> some >> >> >> agreed on concensus around that plan. There was an initial thread >> on >> >> >> openstack-dev related to this topic but it is stalled a bit. It >> could >> >> >> be >> >> >> continually driven to resolution via specs, the tripleo meeting, >> email >> >> >> or >> >> >> irc >> >> >> discussion until a plan is formed. >> >> > >> >> > >> >> > +1, I think the first step is to complete the original blueprint >> and >> >> > move >> >> > on from there. >> >> > I think there has also been interest in having an in person meeting >> at >> >> > summit. >> >> > >> >> > Thanks! >> >> > >> >> >> >> >> >> >> >> >> -- >> >> >> -- James Slagle >> >> >> -- >> >> >> >> >> >> _______________________________________________ >> >> >> 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 >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > 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 >> >> >> >> I like how the discussion goes though I have some personal (and >> >> probably shared) feeling that I would like to share here, more or less >> >> related. >> >> >> >> As a TripleO core developer, I have some frustration to see that a lot >> >> of people are involved in making TripleO Quickstart better, while we >> >> have a few people actually working on tripleo-ci tool and try to >> >> maintain upstream CI stable. >> >> As a reminder, tripleo-ci tool is currently the ONLY ONE thing that >> >> actually gates TripleO, even if we don't like the tool. It is right >> >> now, testing TripleO upstream, everything that is not tested in there >> >> will probably break one day downstream CIs. >> >> Yes we have this tooling discussion here and that's awesome, but words >> >> are words. I would like to see some real engagement to help TripleO CI >> >> to converge into something better and not only everyone working on >> >> their side. >> > >> > >> > You have a valid point and reason to be frustrated. >> > Is the point here that everyone downstream should use tripleo.sh or >> that >> > everyone should be focused on ci and testing at the tripleo level? >> >> Not everyone should use tripleo.sh. My point is that we should move >> forward with a common tool, and stop enlarging the gap between tools. >> We have created (and are still doing) a technical dept where we have >> multiple tools with a ton of overlap, the more we wait, more difficult >> it will be to clean this up. >> > > +1 > >> >> >> >> >> >> >> Some examples: >> >> - TripleO Quickstart (downstream) CI has coverage for undercloud & >> >> overcloud upgrades while TripleO CI freshly has a undercloud upgrade >> >> job and used to have a overcloud (minor) upgrade job (disabled now, >> >> for some reasons related to our capacity to run jobs and also some >> >> blockers into code itself). >> >> - TripleO CI has some TripleO Heat templates that could also be re-use >> >> by TripleO Quickstart (I'm working on moving them from tripleo-ci to >> >> THT, WIP here: https://review.openstack.org/350775). >> >> - TripleO CI deploys Ceph Jewel repository, TripleO Quickstart >> doesn't. >> >> - (...) >> > >> > >> > As others have mentioned, there are at least 5-10 tools in development >> that >> > are used to deploy tripleo in some CI fashion. Calling out >> > tripleo-quickstart alone is not quite right imho. There are a number >> of >> > tripleo devs that burn cycles on their own ci tools and maybe that is >> fine >> > thing to do. >> >> I called quickstart because that's the one I see everyday but my >> frustration is about all our tools in general. >> I'm actually a OOOQ user and I like this tool, really. >> But as you can see, I'm also working on tripleo-ci right now because I >> want TripleO CI better and I haven't seen until now some interest to >> converge. >> James started something cool by trying to deploy an undercloud using >> OOOQ from tripleo-ci. That's a start ! We need things like this, >> prototyping convergence, and see what we can do. >> > > +1 working in multiple ci systems is painful, I know your pain! > I've been playing around w/ Jame's patch [1] to see if I can help. > I like Jame's approach, I think I may be missing some setup steps that > nodepool provides. > > [1] https://review.openstack.org/#/c/348530/ > > >> >> > TripleO-Quickstart is meant to replace instack-virt-setup which it does >> > quite well. The only group that was actually running >> instack-virt-setup >> > was the RDO CI team, upstream had taken it out of the ci system. I >> think >> > it's not unfair to say gaps have been left for other teams to fill. >> >> Gotcha. It was just some examples. >> >> >> >> >> >> >> We have been having this discussion for a while now but we're still >> >> not making much progress here, I feel like we're in statu quo. >> >> James mentioned a blueprint, I like it. We need to engage some >> >> upstream discussion about this major CI refactor, like we need with >> >> specs and then we'll decide if whether or not we need to change the >> >> tool, and how. >> > >> > >> > Well, this would take some leadership imho. We need some people that >> are >> > familiar with the upstream, midstream and downstream requirements of >> CI. >> > This was addressed at the production chain meetings initially but then >> > pretty much ignored. The leaders responsible at the various stages >> of a >> > build (upstream -> downstream ) failed to take this issue on. Here we >> are >> > today. >> > >> > Would it be acceptable by anyone.. IF >> > >> > tripleo-quickstart replaced instack-virt-setup [1] and walked through >> the >> > undercloud install, then handed off to tripleo.sh to deploy, upgrade, >> > update, scale, validate etc??? >> >> That's something we can try. >> >> > That these two tools *would* in fact be the the official CI tools of >> tripleo >> > at the upstream, RDO, and at least parts of the downstream? >> >> My opinion on this is that upstream and downstream CI should only differ >> on: >> * the packages (OSP vs RDO) >> * the scenarios (downstream could have customer-specific things) >> And that's it. Tools should remain the same IMHO. >> >> > Would that help to ease the current frustration around CI? Emilien >> what do >> > you think? >> >> I spent the last months working on composable roles and I have now >> more time to work on CI; $topic is definitely something where I would >> like to help. >> > > woot, I'm excited that you are freeing up and can be more involved! > Thanks as usual Emilien! > > >> -- >> Emilien Macchi >> > > 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 _______________________________________________ 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

On Tue, Aug 2, 2016 at 1:51 PM, Arie Bregman <abregman(a)redhat.com <mailto:abregman@redhat.com>> wrote: On Tue, Aug 2, 2016 at 3:53 PM, Wesley Hayutin <whayutin(a)redhat.com <mailto:whayutin@redhat.com>> wrote: > > > On Tue, Aug 2, 2016 at 4:58 AM, Arie Bregman <abregman(a)redhat.com <mailto:abregman@redhat.com>> wrote: >> >> It became a discussion around the official installer and how to >> improve it. While it's an important discussion, no doubt, I actually >> want to focus on our automation and CI tools. >> >> Since I see there is an agreement that collaboration does make sense >> here, let's move to the hard questions :) >> >> Wes, Tal - there is huge difference right now between infrared and >> tripleo-quickstart in their structure. One is all-in-one project and >> the other one is multiple micro projects managed by one project. Do >> you think there is a way to consolidate or move to a different model >> which will make sense for both RDO and RHOSP? something that both >> groups can work on. > > > 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. > 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. > I can help facilitate a discussion but oooq is an upstream tripleo tool that > replaces instack-virt-setup [1]. > It also happens to be a great tool for easily deploying TripleO end to end > [3] > > What I *can* do is show everyone how to manipulate tripleo-quickstart and > customize it with composable ansible roles, templates, settings etc.. > 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]. > These 3rd party roles can be free and opensource or internal only, it works > either way. > This was discussed in depth as part of the production chain meetings, the > message may have been lost unfortunately. > > I hope this resets your expectations of what I can and can not do as part of > these discussions. > Let me know where and when and I'm happy to be part of the discussion. Thanks for clarifying :) Next reasonable step would probably be to propose some sort of blueprint for tripleo-quickstart to include some of InfraRed features and by that have one tool driven by upstream development that can be either cloned downstream or used as it is with an internal data project. Sure.. a blueprint would help everyone understand the feature and the motivation. You could also just plug in the feature you are looking for to oooq and see if it meets your requirements. See below. OR have InfraRed pushed into tripleo/openstack namespace and expose it to the RDO community (without internal data of course). Personally, I really like the pluggable[1] structure (which allows it to actually consume tripleo-quickstart) so I'm not sure if it can be really merged with tripleo-quickstart as proposed in the first option. The way oooq is built one can plugin or override any part at run time with custom playbooks, roles, and config. There isn't anything that needs to be checked in directly to oooq to use it. It's designed such that third parties can make their own decisions to use something native to quickstart, something from our role library, or something completely independent. This allows teams, individuals or whom ever to do what they need to with out having to fork or re-roll the entire framework. The important step is to note that these 3rd party roles or (oooq-extras) incubate, mature and then graduate to github/openstack. The upstream openstack community should lead, evaluate, and via blueprints vote on the canonical CI tool set. We can record a demonstration if required, but there is nothing stopping anyone right now from doing this today. I'm just browsing the role library for an example, I had no idea [1] existed. Looks like Raoul had a requirement and just made it work.

From this point of view I find quickstart (in truth everything for me

Justin, from the browbeat project has graciously created some documentation regarding 3rd party roles. It has yet to merge, but it should help illustrate how these roles are used. [2] Thanks Arie for leading the discussion. [1] https://github.com/redhat-openstack/ansible-role-tripleo-overcloud-valida... [2] https://review.openstack.org/#/c/346733/ I like the second option, although it still forces us to have two tools, but after a period of time, I believe it will be clear what the community prefers, which will allow us to remove one of the projects eventually. So, unless there are other ideas, I think the next move should be made by Tal. Tal, I'm willing to help with whatever is needed. [1] http://infrared.readthedocs.io/en/latest > > Thanks > > [1] https://blueprints.launchpad.net/tripleo/+spec/tripleo-quickstart > [2] > https://github.com/redhat-openstack/?utf8=%E2%9C%93&query=ansible-rol... > [3[ https://www.rdoproject.org/tripleo/ > > >> >> >> Raoul - I totally agree with you, especially with "difficult for >> anyone to start contributing and collaborate". This is exactly why >> this discussion started. If we can agree on one set of tools, it will >> make everyone's life easier - current groups, new contributors, folks >> that just want to deploy TripleO quickly. But I'm afraid some >> sacrifices need to be made by both groups. >> >> David - I thought WeiRDO is used only for packstack, so I apologize I >> didn't include it. It does sound like an anther testing project, is >> there a place to merge it with another existing testing project? like >> Octario for example or one of TripleO testing projects. Or does it >> make sense to keep it a standalone project? >> >> >> >> >> On Tue, Aug 2, 2016 at 11:12 AM, Christopher Brown <cbrown2(a)ocf.co.uk <mailto:cbrown2@ocf.co.uk>> >> wrote: >> > Hello RDOistas (I think that is the expression?), >> > >> > Another year, another OpenStack deployment tool. :) >> > >> > On Mon, 2016-08-01 at 18:59 +0100, Ignacio Bravo wrote: >> >> If we are talking about tools, I would also want to add something >> >> with regards to user interface of these tools. This is based on my >> >> own experience: >> >> >> >> I started trying to deploy Openstack with Staypuft and The Foreman. >> >> The UI of The Foreman was intuitive enough for the discovery and >> >> provisioning of the servers. The OpenStack portion, not so much. >> > >> > This is exactly mine also. I think this works really well in very large >> > enterprise environments where you need to split out services over more >> > than three controllers. You do need good in-house puppet skills though >> > so better for enterprise with a good sysadmin team. >> > >> >> Forward a couple of releases and we had a TripleO GUI (Tuskar, I >> >> believe) that allowed you to graphically build your Openstack cloud. >> >> That was a reasonable good GUI for Openstack. >> > >> > Well, I found it barely usable. It was only ever good as a graphical >> > representiation of what the build was doing. Interacting with it was >> > not great. >> > >> >> Following that, TripleO become a script based installer, that >> >> required experience in Heat templates. I know I didn’t have it and >> >> had to ask in the mailing list about how to present this or change >> >> that. I got a couple of installs working with this setup. >> > >> > Works well now that I understand all the foibles and have invested time >> > into understanding heat templates and puppet modules. Its good in that >> > it forces you to learn about orchestration which is such an important >> > end-goal of cloud environments. >> > >> >> In the last session in Austin, my goal was to obtain information on >> >> how others were installing Openstack. I was pointed to Fuel as an >> >> alternative. I tried it up, and it just worked. It had the >> >> discovering capability from The Foreman, and the configuration >> >> options from TripleO. I understand that is based in Ansible and >> >> because of that, it is not fully CentOS ready for all the nodes (at >> >> least not in version 9 that I tried). In any case, as a deployer and >> >> installer, it is the most well rounded tool that I found. >> > >> > This is interesting to know. I've heard of Fuel of course but there are >> > some politics involved - it still has the team:single-vendor tag but >> > from what I see Mirantis are very keen for it to become the default >> > OpenStack installer. I don't think being Ansible-based should be a >> > problem - we are deploying OpenShift on OpenStack which uses Openshift- >> > ansible - this recently moved to Ansible 2.1 without too much >> > disruption. >> > >> >> I’d love to see RDO moving into that direction, and having an easy to >> >> use, end user ready deployer tool. >> > >> > If its as good as you say its definitely worth evaluating. From our >> > point of view, we want to be able to add services to the pacemaker >> > cluster with some ease - for example Magnum and Sahara - and it looks >> > like there are steps being taken with regards to composable roles and >> > simplification of the pacemaker cluster to just core services. >> > >> > But if someone can explain that better I would appreciate it. >> > >> > Regards >> > >> >> IB >> >> >> >> >> >> __ >> >> Ignacio Bravo >> >> LTG Federal, Inc >> >> www.ltgfederal.com <http://www.ltgfederal.com> >> >> >> >> >> >> > On Aug 1, 2016, at 1:07 PM, David Moreau Simard <dms(a)redhat.com <mailto:dms@redhat.com>> >> >> > wrote: >> >> > >> >> > The vast majority of RDO's CI relies on using upstream >> >> > installation/deployment projects in order to test installation of >> >> > RDO >> >> > packages in different ways and configurations. >> >> > >> >> > Unless I'm mistaken, TripleO Quickstart was originally created as a >> >> > mean to "easily" install TripleO in different topologies without >> >> > requiring a massive amount of hardware. >> >> > This project allows us to test TripleO in virtual deployments on >> >> > just >> >> > one server instead of, say, 6. >> >> > >> >> > There's also WeIRDO [1] which was left out of your list. >> >> > WeIRDO is super simple and simply aims to run upstream gate jobs >> >> > (such >> >> > as puppet-openstack-integration [2][3] and packstack [4][5]) >> >> > outside >> >> > of the gate. >> >> > It'll install dependencies that are expected to be there (i.e, >> >> > usually >> >> > set up by the openstack-infra gate preparation jobs), set up the >> >> > trunk >> >> > repositories we're interested in testing and the rest is handled by >> >> > the upstream project testing framework. >> >> > >> >> > The WeIRDO project is /very/ low maintenance and brings an >> >> > exceptional >> >> > amount of coverage and value. >> >> > This coverage is important because RDO provides OpenStack packages >> >> > or >> >> > projects that are not necessarily used by TripleO and the reality >> >> > is >> >> > that not everyone deploying OpenStack on CentOS with RDO will be >> >> > using >> >> > TripleO. >> >> > >> >> > Anyway, sorry for sidetracking but back to the topic, thanks for >> >> > opening the discussion. >> >> > >> >> > What honestly perplexes me is the situation of CI in RDO and OSP, >> >> > especially around TripleO/Director, is the amount of work that is >> >> > spent downstream. >> >> > And by downstream, here, I mean anything that isn't in TripleO >> >> > proper. >> >> > >> >> > I keep dreaming about how awesome upstream TripleO CI would be if >> >> > all >> >> > that effort was spent directly there instead -- and then that all >> >> > work >> >> > could bear fruit and trickle down downstream for free. >> >> > Exactly like how we keep improving the testing coverage in >> >> > puppet-openstack-integration, it's automatically pulled in RDO CI >> >> > through WeIRDO for free. >> >> > We make the upstream better and we benefit from it simultaneously: >> >> > everyone wins. >> >> > >> >> > [1]: https://github.com/rdo-infra/weirdo >> >> > [2]: https://github.com/rdo-infra/ansible-role-weirdo-puppet-openst >> >> > ack >> >> > [3]: https://github.com/openstack/puppet-openstack-integration#desc >> >> > ription >> >> > [4]: https://github.com/rdo-infra/ansible-role-weirdo-packstack >> >> > [5]: https://github.com/openstack/packstack#packstack-integration-t >> >> > ests >> >> > >> >> > David Moreau Simard >> >> > Senior Software Engineer | Openstack RDO >> >> > >> >> > dmsimard = [irc, github, twitter] >> >> > >> >> > David Moreau Simard >> >> > Senior Software Engineer | Openstack RDO >> >> > >> >> > dmsimard = [irc, github, twitter] >> >> > >> >> > >> >> > On Mon, Aug 1, 2016 at 11:21 AM, Arie Bregman <abregman(a)redhat.com <mailto:abregman@redhat.com>> >> >> > 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. >> >> > > >> >> > > 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=ansi >> >> > > ble-role >> >> > > [6] https://github.com/openstack/tripleo-quickstart >> >> > > >> >> > > _______________________________________________ >> >> > > rdo-list mailing list >> >> > > rdo-list(a)redhat.com <mailto:rdo-list@redhat.com> >> >> > > https://www.redhat.com/mailman/listinfo/rdo-list >> >> > > >> >> > > To unsubscribe: rdo-list-unsubscribe(a)redhat.com <mailto:rdo-list-unsubscribe@redhat.com> >> >> > _______________________________________________ >> >> > rdo-list mailing list >> >> > rdo-list(a)redhat.com <mailto:rdo-list@redhat.com> >> >> > https://www.redhat.com/mailman/listinfo/rdo-list >> >> > >> >> > To unsubscribe: rdo-list-unsubscribe(a)redhat.com <mailto:rdo-list-unsubscribe@redhat.com> >> >> >> > -- >> > Regards, >> > >> > Christopher Brown >> > OpenStack Engineer >> > OCF plc >> > >> > Tel: +44 (0)114 257 2200 <tel:%2B44%20%280%29114%20257%202200> >> > Web: www.ocf.co.uk <http://www.ocf.co.uk> >> > Blog: blog.ocf.co.uk <http://blog.ocf.co.uk> >> > Twitter: @ocfplc >> > >> > Please note, any emails relating to an OCF Support request must always >> > be sent to support(a)ocf.co.uk <mailto:support@ocf.co.uk> for a ticket number to be generated or >> > existing support ticket to be updated. Should this not be done then OCF >> > cannot be held responsible for requests not dealt with in a timely >> > manner. >> > >> > OCF plc is a company registered in England and Wales. Registered number >> > 4132533, VAT number GB 780 6803 14. Registered office address: OCF plc, >> > 5 Rotunda Business Centre, Thorncliffe Park, Chapeltown, Sheffield S35 >> > 2PG. >> > >> > This message is private and confidential. If you have received this >> > message in error, please notify us immediately and remove it from your >> > system. >> > >> > _______________________________________________ >> > rdo-list mailing list >> > rdo-list(a)redhat.com <mailto:rdo-list@redhat.com> >> > https://www.redhat.com/mailman/listinfo/rdo-list >> > >> > To unsubscribe: rdo-list-unsubscribe(a)redhat.com <mailto:rdo-list-unsubscribe@redhat.com> >> >> >> >> -- >> Arie Bregman >> Red Hat Israel >> Component CI: https://mojo.redhat.com/groups/rhos-core-ci/overview > > -- Arie Bregman Red Hat Israel Component CI: https://mojo.redhat.com/groups/rhos-core-ci/overview _______________________________________________ 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