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