5:54 a.m.
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
6 a.m.
On Wed, Oct 21, 2015 at 1:54 PM, 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.
we know that trying to install on BM with network isolation fail to
install the overcloud using the latest bits[1].
We were able to deploy the undercloud[2] and build the images[3].
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1273680
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1273635
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1273647
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
--
Yaniv.
6:05 a.m.
On 10/21/2015 07:00 AM, Yaniv Eylon wrote:
On Wed, Oct 21, 2015 at 1:54 PM, 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.
we know that trying to install on BM with network isolation fail to
install the overcloud using the latest bits[1].
We were able to deploy the undercloud[2] and build the images[3].
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1273680
Looks to be a documentation
issue due to the change that fixed 1273647.
Fixed
in the released package.
Fixed
in the released package.
>
> 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
7:19 a.m.
On 10/21/2015 07:05 AM, John Trowbridge wrote:
On 10/21/2015 07:00 AM, Yaniv Eylon wrote:
> On Wed, Oct 21, 2015 at 1:54 PM, 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.
>
>
> we know that trying to install on BM with network isolation fail to
> install the overcloud using the latest bits[1].
> We were able to deploy the undercloud[2] and build the images[3].
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1273680
Looks to be a documentation issue due to the change that fixed 1273647.
Can we get that at least into assigned and some indication on the bug
regarding the docs update that is needed?
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1273635
Fixed in the released package.
> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1273647
Fixed in the released package.
>
>>
>> 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
6:10 a.m.
Hi John,
I've managed to install on baremetal following this howto:
https://remote-lab.net/rdo-manager-ha-openstack-deployment/ (based on
liberty)
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
10:16 a.m.
----- 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.
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
1:30 p.m.
----- 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
2:10 p.m.
Hi Omri,
I'll test it out thanks. Did you build your overcloud images based on
Liberty?
export RDO_RELEASE='liberty'
openstack overcloud image build --all
On Wed, Oct 21, 2015 at 7:30 PM, Omri Hochman <ohochman(a)redhat.com> 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
>
8:59 a.m.
----- Original Message -----
From: "Pedro Sousa" <pgsousa(a)gmail.com>
To: "Omri Hochman" <ohochman(a)redhat.com>
Cc: "rdo-list" <rdo-list(a)redhat.com>
Sent: Wednesday, October 21, 2015 3:10:22 PM
Subject: Re: [Rdo-list] RDO Manager status for Liberty GA
Hi Omri,
I'll test it out thanks. Did you build your overcloud images based on
Liberty?
export RDO_RELEASE='liberty'
openstack overcloud image build --all
Yes - that's how we built the images.
Omri.
On Wed, Oct 21, 2015 at 7:30 PM, Omri Hochman <ohochman(a)redhat.com> 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
> >
>
9:46 a.m.
Hi,
I've managed to install it, thanks. Another question, how do I scale the
compute nodes?
I've tried: openstack overcloud deploy --compute-scale 2 --templates
~/the-cloud/ however I get this error:
[stack@undercloud ~]$ openstack overcloud deploy --compute-scale 2
--templates ~/the-cloud/
Deploying templates in the directory /home/stack/the-cloud
Stack failed with status: resources.Controller: resources[2]: BadRequest:
resources.Controller: No valid host was found. No valid host found for
resize (HTTP 400) (Request-ID: req-d5ab7497-ea7f-4ecf-ae8c-122f1637c5ea)
Heat Stack update failed.
Thanks
On Thu, Oct 22, 2015 at 2:59 PM, Omri Hochman <ohochman(a)redhat.com> wrote:
----- Original Message -----
> From: "Pedro Sousa" <pgsousa(a)gmail.com>
> To: "Omri Hochman" <ohochman(a)redhat.com>
> Cc: "rdo-list" <rdo-list(a)redhat.com>
> Sent: Wednesday, October 21, 2015 3:10:22 PM
> Subject: Re: [Rdo-list] RDO Manager status for Liberty GA
>
> Hi Omri,
>
> I'll test it out thanks. Did you build your overcloud images based on
> Liberty?
>
> export RDO_RELEASE='liberty'
> openstack overcloud image build --all
Yes - that's how we built the images.
Omri.
>
>
>
> On Wed, Oct 21, 2015 at 7:30 PM, Omri Hochman <ohochman(a)redhat.com>
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
> > >
> >
>
9:59 a.m.
----- Original Message -----
From: "Pedro Sousa" <pgsousa(a)gmail.com>
To: "Omri Hochman" <ohochman(a)redhat.com>
Cc: "rdo-list" <rdo-list(a)redhat.com>
Sent: Thursday, October 22, 2015 10:46:25 AM
Subject: Re: [Rdo-list] RDO Manager status for Liberty GA
Hi,
I've managed to install it, thanks. Another question, how do I scale the
compute nodes?
You should use the exact same command you used for the overcloud deployment (including all
parameters),
just change : '--compute-scale X' To: '--compute-scale X+Num'
Regards,
Omri
I've tried: openstack overcloud deploy --compute-scale 2
--templates
~/the-cloud/ however I get this error:
[stack@undercloud ~]$ openstack overcloud deploy --compute-scale 2
--templates ~/the-cloud/
Deploying templates in the directory /home/stack/the-cloud
Stack failed with status: resources.Controller: resources[2]: BadRequest:
resources.Controller: No valid host was found. No valid host found for
resize (HTTP 400) (Request-ID: req-d5ab7497-ea7f-4ecf-ae8c-122f1637c5ea)
Heat Stack update failed.
Thanks
On Thu, Oct 22, 2015 at 2:59 PM, Omri Hochman <ohochman(a)redhat.com> wrote:
>
>
> ----- Original Message -----
> > From: "Pedro Sousa" <pgsousa(a)gmail.com>
> > To: "Omri Hochman" <ohochman(a)redhat.com>
> > Cc: "rdo-list" <rdo-list(a)redhat.com>
> > Sent: Wednesday, October 21, 2015 3:10:22 PM
> > Subject: Re: [Rdo-list] RDO Manager status for Liberty GA
> >
> > Hi Omri,
> >
> > I'll test it out thanks. Did you build your overcloud images based on
> > Liberty?
> >
> > export RDO_RELEASE='liberty'
> > openstack overcloud image build --all
>
> Yes - that's how we built the images.
>
> Omri.
> >
> >
> >
> > On Wed, Oct 21, 2015 at 7:30 PM, Omri Hochman <ohochman(a)redhat.com>
> 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
> > > >
> > >
> >
>
1:49 p.m.
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
2:47 p.m.
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
3:30 p.m.
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
www.ltgfederal.com <http://www.ltgfederal.com/>
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
>
3:49 p.m.
----- Original Message -----
From: "Ignacio Bravo" <ibravo(a)ltgfederal.com>
To: "Omri Hochman" <ohochman(a)redhat.com>
Cc: rdo-list(a)redhat.com
Sent: Thursday, October 22, 2015 4:30:22 PM
Subject: Re: [Rdo-list] RDO Manager status for Liberty GA
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.
Sure,
You should be able to get successful BM HA deployment without doing network-isolation,
and I think the deployment command you suggested here ^^ should be good for that.
Omri.
IB
__
Ignacio Bravo
LTG Federal, Inc
www.ltgfederal.com <http://www.ltgfederal.com/>
> 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
>>
10:05 p.m.
I just finalized my first successful install of RDO Manager. All I can say is guau! What a
beauty! It just does everything auto-magically. Impressive.
I will need to go into the network isolation and multiple Ceph nodes now, but it is
definitely amazing. Good work and thanks to ohochman, sasha21 and trown for all the long
irc chats.
IB
__
Ignacio Bravo
LTG Federal, Inc
www.ltgfederal.com <http://www.ltgfederal.com/>
On Oct 22, 2015, at 4:49 PM, Omri Hochman <ohochman(a)redhat.com>
wrote:
----- Original Message -----
> From: "Ignacio Bravo" <ibravo(a)ltgfederal.com>
> To: "Omri Hochman" <ohochman(a)redhat.com>
> Cc: rdo-list(a)redhat.com
> Sent: Thursday, October 22, 2015 4:30:22 PM
> Subject: Re: [Rdo-list] RDO Manager status for Liberty GA
>
> 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.
Sure,
You should be able to get successful BM HA deployment without doing network-isolation,
and I think the deployment command you suggested here ^^ should be good for that.
Omri.
>
>
> IB
>
>
>
> __
> Ignacio Bravo
> LTG Federal, Inc
> www.ltgfederal.com <http://www.ltgfederal.com/>
>
>> 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
>>>
>
>
10:10 a.m.
++ for all the work involved in getting RDO Manager back in shape.
GA or not, I'm very happy to aim for it gating for package releases
along with the rest of the CI (packstack et al).
It will greatly improve the quality and stability of what we ship in
the bigger RDO project.
David Moreau Simard
Senior Software Engineer | Openstack RDO
dmsimard = [irc, github, twitter]
On Wed, Oct 21, 2015 at 6: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
3120
days inactive
3122
days old
16 comments
7 participants
participants (7)
-
David Moreau Simard -
Ignacio Bravo -
John Trowbridge -
Mike Orazi -
Omri Hochman -
Pedro Sousa -
Yaniv Eylon