Do I have to have network isolation for a test HA environment? Something like:
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 /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
I wanted to leave network isolation for my last test (after the others have passed) :)
That way, I don’t require yet the
-e /home/stack/network-environment.yaml
and the modifications of the nic-config files, and most importantly, reading the network
isolation part just yet.
IB
__
Ignacio Bravo
LTG Federal, Inc
On Oct 22, 2015, at 3:47 PM, Omri Hochman <ohochman(a)redhat.com>
wrote:
Hey Ignacio,
I guess you can use my file as example ( I've switched the internal IPs with
'XX.XX.XX.XX' )
http://paste.openstack.org/show/477193/
Note: that configuration file is fit to my environment and It's according the native
vlans that already pre-configured on the switch.
you will also need to create all the network-isolation configuration yaml files under
/home/stack/nic-configs
[ohochman@dhcp-1-111 nic-configs_new]$ ls
ceph-storage.yaml cinder-storage.yaml compute.yaml controller.yaml
swift-storage.yaml
Try to according :
http://docs.openstack.org/developer/tripleo-docs/advanced_deployment/netw...
Regards,
Omri.
----- Original Message -----
> From: "Ignacio Bravo" <ibravo(a)ltgfederal.com>
> To: rdo-list(a)redhat.com
> Sent: Thursday, October 22, 2015 2:49:55 PM
> Subject: Re: [Rdo-list] RDO Manager status for Liberty GA
>
> 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(a)redhat.com>
>>> To: "Pedro Sousa" <pgsousa(a)gmail.com>
>>> Cc: "rdo-list" <rdo-list(a)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(a)gmail.com>
>>>> To: "John Trowbridge" <trown(a)redhat.com>
>>>> Cc: "rdo-list" <rdo-list(a)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(a)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(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
>
> _______________________________________________
> 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
>