[Rdo-list] RDO Manager status for Liberty GA

Thu Oct 22 18:49:55 UTC 2015

Omri,

I was looking at the successful HA deployment in BM that you commented =

openstack overcloud deploy --templates --control-scale 3 --compute-scale 1 --ceph-storage-scale 1 -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /home/stack/network-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml --ntp-server 10.5.26.10 --neutron-network-type vxlan --neutron-tunnel-types vxlan --timeout 9

Can you share the contents of your/home/stack/network-environment.yaml file? I couldn't find this file in the undercloud machine, and want to make sure I get a successful deployment. Feel free to replace any confidential information.

Thanks,
IB

Ignacio Bravo
LTG Federal Inc

On 10/21/2015 02:30 PM, Omri Hochman wrote:
>
> ----- Original Message -----
>> From: "Omri Hochman" <ohochman at redhat.com>
>> To: "Pedro Sousa" <pgsousa at gmail.com>
>> Cc: "rdo-list" <rdo-list at redhat.com>
>> Sent: Wednesday, October 21, 2015 11:16:03 AM
>> Subject: Re: [Rdo-list] RDO Manager status for Liberty GA
>>
>>
>>
>> ----- Original Message -----
>>> From: "Pedro Sousa" <pgsousa at gmail.com>
>>> To: "John Trowbridge" <trown at redhat.com>
>>> Cc: "rdo-list" <rdo-list at redhat.com>
>>> Sent: Wednesday, October 21, 2015 7:10:38 AM
>>> Subject: Re: [Rdo-list] RDO Manager status for Liberty GA
>>>
>>> Hi John,
>>>
>>> I've managed to install on baremetal following this howto:
>>> https://remote-lab.net/rdo-manager-ha-openstack-deployment/ (based on
>>> liberty)
>> Hey Pedro,
>>
>> Are you using:  yum install -y
>> http://rdoproject.org/repos/openstack-liberty/rdo-release-liberty.rpm
>> to get the latest RDO GA bits ?
>>
>> We're failing in overcloud deployment on BM with several issues.
> Actually, an update :
>
> After using the workaround from this issue: https://bugzilla.redhat.com/show_bug.cgi?id=1271289#c9
>
> We've manage to get HA on Bare-Metal (*using the latest rdo-release-liberty.rpm)
>
> That was the deployment command :
>
> openstack overcloud deploy --templates --control-scale 3 --compute-scale 1 --ceph-storage-scale 1 -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /home/stack/network-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml --ntp-server 10.5.26.10 --neutron-network-type vxlan --neutron-tunnel-types vxlan --timeout 90
>
>> Thanks,
>> Omri.
>>
>>> I have 3 Controllers + 1 Compute (HA and Network Isolation). However I'm
>>> having some issues logging on (maybe some keystone issue) and some issue
>>> with openvswitch that I'm trying to address with Marius Cornea help.
>>>
>>> Regards,
>>> Pedro Sousa
>>>
>>>
>>> On Wed, Oct 21, 2015 at 11:54 AM, John Trowbridge < trown at redhat.com >
>>> wrote:
>>>
>>>
>>> Hola rdoers,
>>>
>>> The plan is to GA RDO Liberty today (woot!), so I wanted to send out a
>>> status update for the RDO Manager installer. I would also like to gather
>>> feedback on how other community participants feel about that status as
>>> it relates to RDO Manager participating in the GA. That feedback can
>>> come as replies to this thread, or even better there is a packaging
>>> meeting on #rdo at 1500 UTC today and we can discuss it further then.
>>>
>>> tldr;
>>> RDO Manager installs with 3 controllers, 1 compute, and 1 ceph on
>>> virtual hardware have been verified to work with GA bits, however bare
>>> metal installs have not yet been verified.
>>>
>>> I would like to start with some historical context here, as it seems we
>>> have picked up quite a few new active community members recently (again
>>> woot!). When RDO Kilo GA'd, RDO Manager was barely capable of a
>>> successful end to end demo with a single controller and single compute
>>> node, and only by using a special delorean server pulling bits from a
>>> special github organization (rdo-management). We were able to get it
>>> consistently deploying **virtual** HA w/ ceph in CI by the middle of the
>>> Liberty upstream cycle. Then, due largely to the fact that there was
>>> nobody being paid to work full time on RDO Manager, and the people who
>>> were contributing in more or less "extra" time were getting swamped with
>>> releasing RHEL OSP 7, CI on the Kilo bits became mostly red with brief
>>> 24 hour periods where someone would spend a weekend fixing things only
>>> to have it break again early the following week.
>>>
>>> There have been many improvements in the recent weeks to this sad state
>>> of affairs. Firstly, we have upstreamed almost everything from the
>>> rdo-management github org directly into openstack projects. Secondly,
>>> there is a single source for delorean packages for both core openstack
>>> packages and the tripleo and ironic packages that make up RDO Manager.
>>> These two things may seem a bit trivial to a newcomer to the project,
>>> but they are actually fixes for the biggest cause of the RDO Manager
>>> Kilo CI breaking. I think with those two fixes (plus some work on
>>> upstream tripleo CI) we have set ourselves up to make steady forward
>>> progress rather than spending all our time troubleshooting complete
>>> breakages. (Although this is still openstack so complete breakages will
>>> still happen from time to time :p)
>>>
>>> Another very easy to overlook improvement over where we were at Kilo GA,
>>> is that we actually have all RDO Manager packages (minus a couple EPEL
>>> dep stragglers[1]) in the official RDO GA repo. When RDO Kilo GA'd, we
>>> did not even have everything officially packaged, rather only in our
>>> special delorean instance.
>>>
>>> All this leads to my opinion that RDO Manager should participate in the
>>> RDO GA. I am unconvinced that bare metal installs can not be made to
>>> work with some extra documentation or configuration changes. However,
>>> even if that is not the case, we are in a drastically better place than
>>> we were at the beginning of the Kilo cycle.
>>>
>>> That said, this is a community, and I would like to hear how other
>>> community participants both from RDO in general and RDO Manager
>>> specifically feel about this. Ideally, if someone thinks the RDO Manager
>>> release should be blocked, there should be a BZ with the blocker flag
>>> proposed so that there is actionable criteria to unblock the release.
>>>
>>> Thanks for all your hard work to get to this point, and lets keep it
>>> rolling.
>>>
>>> -trown
>>>
>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1273541
>>>
>>> _______________________________________________
>>> Rdo-list mailing list
>>> Rdo-list at redhat.com
>>> https://www.redhat.com/mailman/listinfo/rdo-list
>>>
>>> To unsubscribe: rdo-list-unsubscribe at redhat.com
>>>
>>>
>>> _______________________________________________
>>> Rdo-list mailing list
>>> Rdo-list at redhat.com
>>> https://www.redhat.com/mailman/listinfo/rdo-list
>>>
>>> To unsubscribe: rdo-list-unsubscribe at redhat.com
>> _______________________________________________
>> Rdo-list mailing list
>> Rdo-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/rdo-list
>>
>> To unsubscribe: rdo-list-unsubscribe at redhat.com
>>
> _______________________________________________
> Rdo-list mailing list
> Rdo-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
>
> To unsubscribe: rdo-list-unsubscribe at redhat.com