[rdo-list] Baremetal Tripleo stable version?
Graeme Gillies
ggillies at redhat.com
Mon Jun 6 23:39:47 UTC 2016
On 06/06/16 23:34, John Trowbridge wrote:
> Hola RDOistas,
>
> First, thanks Graeme for the great write-up of how you use the RDO
> stable Mitaka release. I have some specific thoughts I will put in line,
> but I also have a couple more general responses to this whole thread.
>
> RDO is a distribution of OpenStack. One of the projects we distribute is
> TripleO. In doing so, we provide a lot of feedback into the upstream
> project to improve it, however improvements and feedback need to go
> upstream. It is totally fine to use rdo-list to confer with other RDO
> users about whether an issue is expected behavior, or some issue with
> how things are setup. However, up until this post, this thread has been
> a bit of a pile-on of all the problems people have with TripleO, without
> anything actionable at the RDO level.
>
> What do I mean by actionable at the RDO level? I think the bare minimum
> here would be a bugzilla. Even better would be a launchpad bug for
> upstream TripleO. Even better would be some patch that resolves the
> issue for you. If the issue is one of those three things not getting
> attention, then the mailing list is a totally valid avenue to reach out
> for some help to drive those.
>
> After all, while RDO does provide a lot of free as in free beer. The
> true benefit of open source is the Freedom to help improve things.
So to be clear here, are you saying that with regards to things that
directly relate to tripleo (changing documentation focus, etc) we should
be discussing this in the upstream tripleo communication channels? And
those channels would be openstack-dev mailing list (with the tripleo tag)?
>
> - trown
>
> On 06/05/2016 07:37 PM, Graeme Gillies wrote:
>> Hi Everyone,
>>
>> I just wanted to say I have been following this thread quite closely and
>> can sympathize with some of the pain people are going through to get
>> tripleO to work.
>>
>> Currently it's quite difficult and a bit opaque on how to actually
>> utilise the stable mitaka repos in order to build a functional
>> undercloud and overcloud environment.
>>
>> First I wanted to share the steps I have undergone in order to get a
>> functional overcloud working with RDO Mitaka utilising the RDO stable
>> release built by CentOS, and then I'll talk about some specific steps I
>> think need to be undertaken by the RDO/TripleO team in order to provide
>> a better experience in the future.
>>
>> To get a functional overcloud using RDO Mitaka, you need to do the following
>>
>> 1) Install EPEL on your undercloud
>> 2) Install https://www.rdoproject.org/repos/rdo-release.rpm on your
>> undercloud
>> 3) Following the normal steps to install your undercloud (modifying
>> undercloud.conf, and running openstack undercloud install
>> 4) You will now need to manually patch ironic on the undercloud in order
>> to make sure repeated introspection works. This might not be needed if
>> you don't do any introspection, but I find more often than not you end
>> up having to do it, so it's worthwhile. The bug you need to patch is [1]
>> and I typically run the following commands to apply the patch
>>
>> # sudo su -
>> $ cd /usr/lib/python2.7/site-packages
>> $ curl
>> 'https://review.openstack.org/changes/306421/revisions/abd50d8438e7d371ce24f97d8f8f67052b562007/patch?download'
>> | base64 -d | patch -p1
>> $ systemctl restart openstack-ironic-inspector
>> $ systemctl restart openstack-ironic-inspector-dnsmasq
>> $ exit
>> #
>>
>
> This is actually a good example of something actionable at the RDO
> level. The fix for this is already backported to the stable/mitaka
> branch upstream, and just requires a rebase of the mitaka
> ironic-inspector package.
>
> The only thing that could be improved here is an open bugzilla so that
> there was some RDO level visibility that this package needed a rebase
> for a critical bug. I will take an action to file such a bugzilla, and
> do the rebase.
Thanks for doing that. There is still no clear documented policy (at
least as far as I can tell) on how/when RDO does rebases of the stable
(CBS) packages from stable upstream releases. I know currently the plan
is to just follow when upstream does releases, but it sounds like there
is potential for RDO to release a bit quicker than that?
>
>> 5) Manually patch the undercloud to build overcloud images using
>> rhos-release rpm only (which utilises the stable Mitaka repo from
>> CentOS, and nothing from RDO Trunk [delorean]). I do this by modifying
>> the file
>>
>> /usr/lib/python2.7/site-packages/tripleoclient/v1/overcloud_image.py
>>
>> At around line 467 you will see a reference to epel, I add a new line
>> after that to include the rdo_release DIB element to the build as well.
>> This typically makes the file look something like
>>
>> http://paste.openstack.org/show/508196/
>>
>> (note like 468). Then I create a directory to store my images and build
>> them specifying the mitaka version of rdo_release. I then upload these
>> images
>>
>> # mkdir ~/images
>> # cd ~/images
>> # export RDO_RELEASE=mitaka
>> # openstack overcloud image build --all
>> # openstack overcloud image upload --update-existing
>>
>
> This is an example of something that needs to go into TripleO. I
> personally never recommend folks in RDO build images themselves, mostly
> because the tripleoclient wrapper around DIB is very opinionated and
> difficult to make even simple changes like this. The image building
> process in RDO is actually not even using tripleoclient, but the
> replacement library in tripleo-common that allows building images from a
> declarative YAML:
>
> https://github.com/openstack/tripleo-common/blob/master/scripts/tripleo-build-images
>
> https://github.com/redhat-openstack/ansible-role-tripleo-image-build/blob/master/library/tripleo_build_images.py
>
> What needs to go to TripleO here is a launchpad bug about switching
> tripleoclient to use this new image building library. That is not
> something we can do at the RDO level.
>
> Also, note there are stable release images published as well as the DLRN
> ones:
>
> http://buildlogs.centos.org/centos/7/cloud/x86_64/tripleo_images/mitaka/cbs/
Thanks for pointing out the all of this. I was not aware that there were
stable release images published (how is this not referenced in any
documentation anywhere?) nor that there is a different way to build
images from the standard tooling.
Like it or not there will always be people (myself included) who wish to
build their own images, either to customise and extend them, or to
simply verify that the code they are deploying matches what they are
given (for escrow and security purposes). The current image build
process is quite awkward to modify, and the fact that we already have a
method which seems better (at least, we have a declarative file we can
adjust and customise) seems like a no brainer to me to move all of
tripleo to using that ASAP. Having different methods of building images
just adds more confusion, which provides more uncertainty around what
you are getting and how to extend and customise that.
>
>> 6) Because of the bug at [2] which affects the ironic agent ramdisk, we
>> need to build a set of images utilising RDO Trunk for the mitaka branch
>> (where the fix is applied), and then upload *only* the new ironic
>> ramdisk. This is done with
>>
>> # mkdir ~/images-mitaka-trunk
>> # cd ~/images-mitaka-trunk
>> # export USE_DELOREAN_TRUNK=1
>> # export
>> DELOREAN_TRUNK_REPO="http://trunk.rdoproject.org/centos7-mitaka/current/"
>> # export DELOREAN_REPO_FILE="delorean.repo"
>> # openstack overcloud image build --type agent-ramdisk
>> # sudo cp ironic-python-agent.initramfs /httpboot/agent.ramdisk
>>
>
> This is another example of something actionable at the RDO level, and
> has it all (Bugzilla with links to launchpad and gerrit). I will take an
> action to rebase the ironic-python-agent package to pull in that fix.
>
>> 7) Follow the rest of the documentation to deploy the overcloud normally
>>
>> Please note that obviously your mileage may vary, and this is by all
>> means not an exclusive list of the problems. I have however used these
>> steps to do multiple node deployments (10+ nodes) with HA over different
>> hardware sets with different networking setups (single nic, multiple nic
>> with bonding + vlans).
>>
>> With all the different repos floating around, all which change very
>> rapidly, combined with the documentation defaults targeting developers
>> and CI systems (not end users), it's hard to not only get a stable
>> TripleO install up, but also communicate and discuss clearly with others
>> what is working, what is broken, and how to compare two installations to
>> see if they are experiencing the same issues.
>>
>> To this end I would like to suggest to the RDO and TripleO community
>> that we undertake the following
>>
>> 1) Overhaul all the TripleO documentation so that all the steps default
>> to utilising/deploying using RDO Stable (that is, the releases done by
>> CBS). There should be colored boxes with alt steps for those who wish to
>> use RDO Trunk on the stable branch, and RDO Trunk from master. This
>> basically inverts the current pattern. I think anyone, Operator or
>> developer, who is working through the documentation for the first time,
>> should be given steps that maximise the chance of success, and thus the
>> most stable release we have. Once a user has gone through the process
>> once, they can look at the alternative steps for more aggressive releases
>>
>
> First, I am in 100% agreement that the TripleO documentation could use a
> major overhaul.
>
> That said, this is actually a fairly difficult problem. Your proposal is
> perfect for the RDO case, but it does not seem right for TripleO
> upstream docs to default to a stable release. In any case, this is
> something to be solved in TripleO and not in RDO.
>
> I did try to solve this by forking the TripleO docs and modifying them
> to be more RDO centric. However, this was pretty difficult to maintain,
> and so I abandoned that effort. If there were some group of RDO
> community members dedicated to doing that, it might be a possible
> solution. These would need to be net new contributions though, as I
> personally do not have bandwidth for that.
Ok I guess I understand the need for the tripleO docs to be stable/rdo
agnostic, as techincally it's a purely upstream project that can be
utilised by many different distros/communities, but this kind of leaves
us in a gap at the moment where we don't really have any satisfactory
user docs for people deploying with RDO and want the best stable
experience we can give. I'm wondering do we need to take a copy of the
downstream (docs.redhat.com) and use that as a basis for the TripleO/RDO
user guide on rdoproject.org, and then keep that as the "upstream
reference" for all downstream docs? Or do we take the tripleO docs, then
modify them to be RDO specific, then further modify them to be
downstream specific (tripleo.org -> rdoproject.org -> docs.redhat.com).
I guess I'm trying to get a clear workflow where we can maximise reuse
as much as possible, and avoid duplication of effort and the potential
for doc updates to get "lost" in different places.
>
>> 2) Patch python-tripleoclient so that by default, when you run
>> "openstack overcloud image build" it builds the images utilising the
>> rdo_release DIB element, and sets the RDO_RELEASE environment variable
>> to be 'mitaka' or whenever the current stable release is (and we should
>> endevour to update it with new releases). There should be no extra
>> environment variables necessary to build images, and by default it
>> should never touch anything RDO Trunk (delorean) related
>>
>
> I think in the short term, it is really best to use the pre-built images
> for RDO, using virt-customize where needed to modify them.
>
> In the medium term, I think this would be a pretty benign patch to carry
> on the stable release of python-tripleoclient, but we need to start with
> a bugzilla for that.
>
> Once upstream TripleO switches tripleoclient to use the declarative YAML
> library in tripleo-common, I think carrying a patch on the stable
> release that makes it default to building the stable images makes a lot
> of sense.
>
>> 3) For bugs like the two I have mentioned above, we need to have some
>> sort of robust process for either backporting those patches to the
>> builds in CBS (I understand we don't do this for various reasons), or we
>> need some kind of tooling or solution that allows operators to apply
>> only the fixes they need from RDO Trunk (delorean). We need to ensure
>> that when an Operator utilises TripleO they have the greatest chance of
>> success, and bugs such as these which severely impact the deployment
>> process harm the adoption of TripleO and RDO.
>>
>
> For the ironic bugs I have taken an action to rebase and pick up the
> changes from the upstream stable branch. In general, this is only done
> when there is some critical issue, and not on a periodic basis. I was
> not aware of the two critical issues posted, but thanks to this detailed
> write-up now I am.
Excellent thanks
>
> As far as tooling to apply only fixes needed from RDO Trunk, that is
> just yum. Downloading the delorean.repo and modifying it to exclude all
> but the packages that need hotfixes would get the same result without
> manual patching.
Yep agreed, I was just thinking it would be great if there was even a
simple python tool where you could do something like
rdo-apply-trunk <delorean build id> <package you need>
And it would automate all that for you.
>
>> 4) We should curate and keep an up to date page on rdoproject.org that
>> does highlight the outstanding issues related to TripleO on the RDO
>> Stable (CBS) releases. These should have links to relevant bugzillas,
>> clean instructions on how to work around the issue, or cleanly apply a
>> patch to avoid the issue, and as new releases make it out, we should
>> update the page to drop off workarounds that are no longer needed.
>>
>
> I like this idea. It suffers from the same problem as the TripleO docs
> issue though. That being, that it requires net new community members to
> step up and take ownership of it.
Well perhaps I am wrong, but surely the developers who are maintaining
packages for tripleo can help out? When they see a bugzilla that they
have triaged and looks like something that deserves a workaround note,
they could add it themselves, removing it when the bz is closed.
>
>> The goal is to push Operators/Users to working with our most stable code
>> as much as possible, and track/curate issues around that. This way
>> everyone should be on the same page, issues are easier to discuss and
>> diagnose, and overall peoples experiences should be better.
>>
>> I'm interested in thoughts, feedback, and concerns, both from the RDO
>> and TripleO community, and from the Operator/User community.
>>
>> Regards,
>>
>> Graeme
>>
>> [1] https://bugs.launchpad.net/ironic-inspector/+bug/1570447
>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1322892
>>
>> On 05/06/16 02:04, Pedro Sousa wrote:
>>> Thanks Marius,
>>>
>>> I can confirm that it installs fine with 3 controllers + 3 computes
>>> after recreating the stack
>>>
>>> Regards
>>>
>>> On Sat, Jun 4, 2016 at 4:14 PM, Marius Cornea <marius at remote-lab.net
>>> <mailto:marius at remote-lab.net>> wrote:
>>>
>>> Hi Pedro,
>>>
>>> Scaling out controller nodes is not supported at this moment:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1243312
>>>
>>> On Sat, Jun 4, 2016 at 5:05 PM, Pedro Sousa <pgsousa at gmail.com
>>> <mailto:pgsousa at gmail.com>> wrote:
>>> > Hi,
>>> >
>>> > some update on scaling the cloud:
>>> >
>>> > 1 controller + 1 compute -> 1 controller + 3 computes OK
>>> >
>>> > 1 controller + 3 computes -> 3 controllers + 3 compute FAILS
>>> >
>>> > Problem: The new controller nodes are "stuck" in "pscd start", so
>>> it seems
>>> > to be a problem joining the pacemaker cluster... Did anyone had this
>>> > problem?
>>> >
>>> > Regards
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Sat, Jun 4, 2016 at 1:50 AM, Pedro Sousa <pgsousa at gmail.com
>>> <mailto:pgsousa at gmail.com>> wrote:
>>> >>
>>> >> Hi,
>>> >>
>>> >> I finally managed to install a baremetal in mitaka with 1
>>> controller + 1
>>> >> compute with network isolation. Thank god :)
>>> >>
>>> >> All I did was:
>>> >>
>>> >> #yum install centos-release-openstack-mitaka
>>> >> #sudo yum install python-tripleoclient
>>> >>
>>> >> without epel repos.
>>> >>
>>> >> Then followed instructions from Redhat Site.
>>> >>
>>> >> I downloaded the overcloud images from:
>>> >>
>>> http://buildlogs.centos.org/centos/7/cloud/x86_64/tripleo_images/mitaka/delorean/
>>> >>
>>> >> I do have an issue that forces me to delete a json file and run
>>> >> os-refresh-config inside my overcloud nodes other than that it
>>> installs
>>> >> fine.
>>> >>
>>> >> Now I'll test with more 2 controllers + 2 computes to have a full HA
>>> >> deployment.
>>> >>
>>> >> If anyone needs help to document this I'll be happy to help.
>>> >>
>>> >> Regards,
>>> >> Pedro Sousa
>>> >>
>>> >>
>>> >> On Fri, Jun 3, 2016 at 8:26 PM, Ronelle Landy <rlandy at redhat.com
>>> <mailto:rlandy at redhat.com>> wrote:
>>> >>>
>>> >>> The report says: "Fix Released" as of 2016-05-24.
>>> >>> Are you installing on a clean system with the latest repositories?
>>> >>>
>>> >>> Might also want to check your version of rabbitmq: I have
>>> >>> rabbitmq-server-3.6.2-3.el7.noarch on CentOS 7.
>>> >>>
>>> >>> ----- Original Message -----
>>> >>> > From: "Pedro Sousa" <pgsousa at gmail.com <mailto:pgsousa at gmail.com>>
>>> >>> > To: "Ronelle Landy" <rlandy at redhat.com <mailto:rlandy at redhat.com>>
>>> >>> > Cc: "Christopher Brown" <cbrown2 at ocf.co.uk
>>> <mailto:cbrown2 at ocf.co.uk>>, "Ignacio Bravo"
>>> >>> > <ibravo at ltgfederal.com <mailto:ibravo at ltgfederal.com>>, "rdo-list"
>>> >>> > <rdo-list at redhat.com <mailto:rdo-list at redhat.com>>
>>> >>> > Sent: Friday, June 3, 2016 1:20:43 PM
>>> >>> > Subject: Re: [rdo-list] Baremetal Tripleo stable version?
>>> >>> >
>>> >>> > Anyway to workaround this? Maybe downgrade hiera?
>>> >>> >
>>> >>> > On Fri, Jun 3, 2016 at 5:55 PM, Ronelle Landy
>>> <rlandy at redhat.com <mailto:rlandy at redhat.com>>
>>> >>> > wrote:
>>> >>> >
>>> >>> > > I am not sure exactly where you installed from, and when you
>>> did your
>>> >>> > > installation, but any chance, you've hit:
>>> >>> > > https://bugs.launchpad.net/tripleo/+bug/1584892?
>>> >>> > > There is a link bugzilla record.
>>> >>> > >
>>> >>> > > ----- Original Message -----
>>> >>> > > > From: "Pedro Sousa" <pgsousa at gmail.com
>>> <mailto:pgsousa at gmail.com>>
>>> >>> > > > To: "Ronelle Landy" <rlandy at redhat.com
>>> <mailto:rlandy at redhat.com>>
>>> >>> > > > Cc: "Christopher Brown" <cbrown2 at ocf.co.uk
>>> <mailto:cbrown2 at ocf.co.uk>>, "Ignacio Bravo" <
>>> >>> > > ibravo at ltgfederal.com <mailto:ibravo at ltgfederal.com>>,
>>> "rdo-list"
>>> >>> > > > <rdo-list at redhat.com <mailto:rdo-list at redhat.com>>
>>> >>> > > > Sent: Friday, June 3, 2016 12:26:58 PM
>>> >>> > > > Subject: Re: [rdo-list] Baremetal Tripleo stable version?
>>> >>> > > >
>>> >>> > > > Thanks Ronelle,
>>> >>> > > >
>>> >>> > > > do you think this kind of errors can be related with network
>>> >>> > > > settings?
>>> >>> > > >
>>> >>> > > > "Could not retrieve fact='rabbitmq_nodename',
>>> >>> > > > resolution='<anonymous>':
>>> >>> > > > undefined method `[]' for nil:NilClass Could not retrieve
>>> >>> > > > fact='rabbitmq_nodename', resolution='<anonymous>': undefined
>>> >>> > > > method `[]'
>>> >>> > > > for nil:NilClass"
>>> >>> > > >
>>> >>> > > > On Fri, Jun 3, 2016 at 4:56 PM, Ronelle Landy
>>> <rlandy at redhat.com <mailto:rlandy at redhat.com>>
>>> >>> > > > wrote:
>>> >>> > > >
>>> >>> > > > > Hi Pedro,
>>> >>> > > > >
>>> >>> > > > > You could use the docs you referred to.
>>> >>> > > > > Alternatively, if you want to use a vm for the
>>> undercloud and
>>> >>> > > > > baremetal
>>> >>> > > > > machines for the overcloud, it is possible to use Tripleo
>>> >>> > > > > Qucikstart
>>> >>> > > with a
>>> >>> > > > > few modifications.
>>> >>> > > > > https://bugs.launchpad.net/tripleo-quickstart/+bug/1571028.
>>> >>> > > > >
>>> >>> > > > > ----- Original Message -----
>>> >>> > > > > > From: "Pedro Sousa" <pgsousa at gmail.com
>>> <mailto:pgsousa at gmail.com>>
>>> >>> > > > > > To: "Ronelle Landy" <rlandy at redhat.com
>>> <mailto:rlandy at redhat.com>>
>>> >>> > > > > > Cc: "Christopher Brown" <cbrown2 at ocf.co.uk
>>> <mailto:cbrown2 at ocf.co.uk>>, "Ignacio Bravo" <
>>> >>> > > > > ibravo at ltgfederal.com <mailto:ibravo at ltgfederal.com>>,
>>> "rdo-list"
>>> >>> > > > > > <rdo-list at redhat.com <mailto:rdo-list at redhat.com>>
>>> >>> > > > > > Sent: Friday, June 3, 2016 11:48:38 AM
>>> >>> > > > > > Subject: Re: [rdo-list] Baremetal Tripleo stable version?
>>> >>> > > > > >
>>> >>> > > > > > Hi Ronelle,
>>> >>> > > > > >
>>> >>> > > > > > maybe I understand it wrong but I thought that Tripleo
>>> >>> > > > > > Quickstart
>>> >>> > > was for
>>> >>> > > > > > deploying virtual environments?
>>> >>> > > > > >
>>> >>> > > > > > And for baremetal we should use
>>> >>> > > > > >
>>> >>> > > > >
>>> >>> > >
>>> >>> > >
>>> http://docs.openstack.org/developer/tripleo-docs/installation/installation.html
>>> >>> > > > > > ?
>>> >>> > > > > >
>>> >>> > > > > > Thanks
>>> >>> > > > > >
>>> >>> > > > > >
>>> >>> > > > > >
>>> >>> > > > > >
>>> >>> > > > > >
>>> >>> > > > > > On Fri, Jun 3, 2016 at 4:43 PM, Ronelle Landy
>>> >>> > > > > > <rlandy at redhat.com <mailto:rlandy at redhat.com>>
>>> >>> > > wrote:
>>> >>> > > > > >
>>> >>> > > > > > > Hello,
>>> >>> > > > > > >
>>> >>> > > > > > > We have had success deploying RDO (Mitaka) on baremetal
>>> >>> > > > > > > systems -
>>> >>> > > using
>>> >>> > > > > > > Tripleo Quickstart with both single-nic-vlans and
>>> >>> > > > > > > bond-with-vlans
>>> >>> > > > > network
>>> >>> > > > > > > isolation configurations.
>>> >>> > > > > > >
>>> >>> > > > > > > Baremetal can have some complicated networking
>>> issues but,
>>> >>> > > > > > > from
>>> >>> > > > > previous
>>> >>> > > > > > > experiences, if a single-controller deployment
>>> worked but a
>>> >>> > > > > > > HA
>>> >>> > > > > deployment
>>> >>> > > > > > > did not, I would check:
>>> >>> > > > > > > - does the HA deployment command include: -e
>>> >>> > > > > > >
>>> >>> > > > >
>>> >>> > >
>>> >>> > >
>>> /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml
>>> >>> > > > > > > - are there possible MTU issues?
>>> >>> > > > > > >
>>> >>> > > > > > >
>>> >>> > > > > > > ----- Original Message -----
>>> >>> > > > > > > > From: "Christopher Brown" <cbrown2 at ocf.co.uk
>>> <mailto:cbrown2 at ocf.co.uk>>
>>> >>> > > > > > > > To: pgsousa at gmail.com <mailto:pgsousa at gmail.com>,
>>> ibravo at ltgfederal.com <mailto:ibravo at ltgfederal.com>
>>> >>> > > > > > > > Cc: rdo-list at redhat.com <mailto:rdo-list at redhat.com>
>>> >>> > > > > > > > Sent: Friday, June 3, 2016 10:29:39 AM
>>> >>> > > > > > > > Subject: Re: [rdo-list] Baremetal Tripleo stable
>>> version?
>>> >>> > > > > > > >
>>> >>> > > > > > > > Hello Ignacio,
>>> >>> > > > > > > >
>>> >>> > > > > > > > Thanks for your response and good to know it isn't
>>> just me!
>>> >>> > > > > > > >
>>> >>> > > > > > > > I would be more than happy to provide developers with
>>> >>> > > > > > > > access to
>>> >>> > > our
>>> >>> > > > > > > > bare metal environments. I'll also file some bugzilla
>>> >>> > > > > > > > reports to
>>> >>> > > see
>>> >>> > > > > if
>>> >>> > > > > > > > this generates any interest.
>>> >>> > > > > > > >
>>> >>> > > > > > > > Please do let me know if you make any progress - I am
>>> >>> > > > > > > > trying to
>>> >>> > > > > deploy
>>> >>> > > > > > > > HA with network isolation, multiple nics and vlans.
>>> >>> > > > > > > >
>>> >>> > > > > > > > The RDO web page states:
>>> >>> > > > > > > >
>>> >>> > > > > > > > "If you want to create a production-ready cloud,
>>> you'll
>>> >>> > > > > > > > want to
>>> >>> > > use
>>> >>> > > > > the
>>> >>> > > > > > > > TripleO quickstart guide."
>>> >>> > > > > > > >
>>> >>> > > > > > > > which is a contradiction in terms really.
>>> >>> > > > > > > >
>>> >>> > > > > > > > Cheers
>>> >>> > > > > > > >
>>> >>> > > > > > > > On Fri, 2016-06-03 at 14:30 +0100, Ignacio Bravo
>>> wrote:
>>> >>> > > > > > > > > Pedro / Christopher,
>>> >>> > > > > > > > >
>>> >>> > > > > > > > > Just wanted to share with you that I also had
>>> plenty of
>>> >>> > > > > > > > > issues
>>> >>> > > > > > > > > deploying on bare metal HA servers, and have
>>> paused the
>>> >>> > > deployment
>>> >>> > > > > > > > > using TripleO until better winds start to flow
>>> here. I
>>> >>> > > > > > > > > was
>>> >>> > > able to
>>> >>> > > > > > > > > deploy the QuickStart, but on bare metal the
>>> history was
>>> >>> > > different.
>>> >>> > > > > > > > > Couldn't even deploy a two server configuration.
>>> >>> > > > > > > > >
>>> >>> > > > > > > > > I was thinking that it would be good to have the
>>> >>> > > > > > > > > developers
>>> >>> > > have
>>> >>> > > > > > > > > access to one of our environments and go through
>>> a full
>>> >>> > > > > > > > > install
>>> >>> > > > > with
>>> >>> > > > > > > > > us to better see where things fail. We can do this
>>> >>> > > > > > > > > handholding
>>> >>> > > > > > > > > deployment once every week/month based on
>>> developers time
>>> >>> > > > > > > > > availability. That way we can get a working
>>> install, and
>>> >>> > > > > > > > > we can
>>> >>> > > > > > > > > troubleshoot real life environment problems.
>>> >>> > > > > > > > >
>>> >>> > > > > > > > >
>>> >>> > > > > > > > > IB
>>> >>> > > > > > > > >
>>> >>> > > > > > > > > On Jun 3, 2016, at 6:15 AM, Pedro Sousa
>>> >>> > > > > > > > > <pgsousa at gmail.com <mailto:pgsousa at gmail.com>>
>>> >>> > > wrote:
>>> >>> > > > > > > > >
>>> >>> > > > > > > > > > Yes. I've used this, but I'll try again as there's
>>> >>> > > > > > > > > > seems to
>>> >>> > > be
>>> >>> > > > > new
>>> >>> > > > > > > > > > updates.
>>> >>> > > > > > > > > >
>>> >>> > > > > > > > > >
>>> >>> > > > > > > > > >
>>> >>> > > > > > > > > > Stable Branch Skip all repos mentioned above,
>>> other
>>> >>> > > > > > > > > > than
>>> >>> > > epel-
>>> >>> > > > > > > > > > release which is still required.
>>> >>> > > > > > > > > > Enable latest RDO Stable Delorean repository
>>> for all
>>> >>> > > > > > > > > > packages
>>> >>> > > > > > > > > > sudo curl -o
>>> /etc/yum.repos.d/delorean-liberty.repo
>>> >>> > > > > https://trunk.r
>>> >>> > > > > > > > > >
>>> doproject.org/centos7-liberty/current/delorean.repo
>>> <http://doproject.org/centos7-liberty/current/delorean.repo>
>>> >>> > > > > > > > > > Enable the Delorean Deps repository
>>> >>> > > > > > > > > > sudo curl -o
>>> >>> > > > > > > > > > /etc/yum.repos.d/delorean-deps-liberty.repo
>>> >>> > > > > http://tru
>>> >>> > > > > > > > > >
>>> nk.rdoproject.org/centos7-liberty/delorean-deps.repo
>>> <http://nk.rdoproject.org/centos7-liberty/delorean-deps.repo>
>>> >>> > > > > > > > > >
>>> >>> > > > > > > > > > On Fri, Jun 3, 2016 at 11:10 AM, Christopher
>>> Brown <
>>> >>> > > > > cbrown2 at ocf.co <mailto:cbrown2 at ocf.co>.
>>> >>> > > > > > > > > > uk> wrote:
>>> >>> > > > > > > > > > > No, Liberty deployed ok for us.
>>> >>> > > > > > > > > > >
>>> >>> > > > > > > > > > > It suggests to me a package mismatch. Have you
>>> >>> > > > > > > > > > > completely
>>> >>> > > > > rebuilt
>>> >>> > > > > > > > > > > the
>>> >>> > > > > > > > > > > undercloud and then the images using Liberty?
>>> >>> > > > > > > > > > >
>>> >>> > > > > > > > > > > On Fri, 2016-06-03 at 11:04 +0100, Pedro
>>> Sousa wrote:
>>> >>> > > > > > > > > > > > AttributeError: 'module' object has no
>>> attribute
>>> >>> > > 'PortOpt'
>>> >>> > > > > > > > > > > --
>>> >>> > > > > > > > > > > Regards,
>>> >>> > > > > > > > > > >
>>> >>> > > > > > > > > > > Christopher Brown
>>> >>> > > > > > > > > > > OpenStack Engineer
>>> >>> > > > > > > > > > > OCF plc
>>> >>> > > > > > > > > > >
>>> >>> > > > > > > > > > > Tel: +44 (0)114 257 2200
>>> <tel:%2B44%20%280%29114%20257%202200>
>>> >>> > > > > > > > > > > Web: www.ocf.co.uk <http://www.ocf.co.uk>
>>> >>> > > > > > > > > > > Blog: blog.ocf.co.uk <http://blog.ocf.co.uk>
>>> >>> > > > > > > > > > > Twitter: @ocfplc
>>> >>> > > > > > > > > > >
>>> >>> > > > > > > > > > > Please note, any emails relating to an OCF
>>> Support
>>> >>> > > > > > > > > > > request
>>> >>> > > must
>>> >>> > > > > > > > > > > always
>>> >>> > > > > > > > > > > be sent to support at ocf.co.uk
>>> <mailto:support at ocf.co.uk> for a ticket number to
>>> >>> > > > > > > > > > > be
>>> >>> > > > > generated
>>> >>> > > > > > > > > > > or
>>> >>> > > > > > > > > > > existing support ticket to be updated.
>>> Should this
>>> >>> > > > > > > > > > > not be
>>> >>> > > done
>>> >>> > > > > > > > > > > then OCF
>>> >>> > > > > > > > > > >
>>> >>> > > > > > > > > > > cannot be held responsible for requests not
>>> dealt
>>> >>> > > > > > > > > > > with in a
>>> >>> > > > > > > > > > > timely
>>> >>> > > > > > > > > > > manner.
>>> >>> > > > > > > > > > >
>>> >>> > > > > > > > > > > OCF plc is a company registered in England
>>> and Wales.
>>> >>> > > > > Registered
>>> >>> > > > > > > > > > > number
>>> >>> > > > > > > > > > >
>>> >>> > > > > > > > > > > 4132533, VAT number GB 780 6803 14.
>>> Registered office
>>> >>> > > address:
>>> >>> > > > > > > > > > > OCF plc,
>>> >>> > > > > > > > > > >
>>> >>> > > > > > > > > > > 5 Rotunda Business Centre, Thorncliffe Park,
>>> >>> > > > > > > > > > > Chapeltown,
>>> >>> > > > > > > > > > > Sheffield S35
>>> >>> > > > > > > > > > > 2PG.
>>> >>> > > > > > > > > > >
>>> >>> > > > > > > > > > > If you have received this message in error,
>>> please
>>> >>> > > > > > > > > > > notify
>>> >>> > > us
>>> >>> > > > > > > > > > > immediately and remove it from your system.
>>> >>> > > > > > > > > > >
>>> >>> > > > > > > > >
>>> >>> > > > > > > > > _______________________________________________
>>> >>> > > > > > > > > rdo-list mailing list
>>> >>> > > > > > > > > rdo-list at redhat.com <mailto:rdo-list at redhat.com>
>>> >>> > > > > > > > > https://www.redhat.com/mailman/listinfo/rdo-list
>>> >>> > > > > > > > >
>>> >>> > > > > > > > > To unsubscribe: rdo-list-unsubscribe at redhat.com
>>> <mailto:rdo-list-unsubscribe at redhat.com>
>>> >>> > > > > > > > --
>>> >>> > > > > > > > Regards,
>>> >>> > > > > > > >
>>> >>> > > > > > > > Christopher Brown
>>> >>> > > > > > > > OpenStack Engineer
>>> >>> > > > > > > > OCF plc
>>> >>> > > > > > > >
>>> >>> > > > > > > > Tel: +44 (0)114 257 2200
>>> <tel:%2B44%20%280%29114%20257%202200>
>>> >>> > > > > > > > Web: www.ocf.co.uk <http://www.ocf.co.uk>
>>> >>> > > > > > > > Blog: blog.ocf.co.uk <http://blog.ocf.co.uk>
>>> >>> > > > > > > > Twitter: @ocfplc
>>> >>> > > > > > > >
>>> >>> > > > > > > > Please note, any emails relating to an OCF Support
>>> request
>>> >>> > > > > > > > must
>>> >>> > > > > always
>>> >>> > > > > > > > be sent to support at ocf.co.uk
>>> <mailto:support at ocf.co.uk> for a ticket number to be
>>> >>> > > generated or
>>> >>> > > > > > > > existing support ticket to be updated. Should this
>>> not be
>>> >>> > > > > > > > done
>>> >>> > > then
>>> >>> > > > > OCF
>>> >>> > > > > > > >
>>> >>> > > > > > > > cannot be held responsible for requests not dealt
>>> with in a
>>> >>> > > timely
>>> >>> > > > > > > > manner.
>>> >>> > > > > > > >
>>> >>> > > > > > > > OCF plc is a company registered in England and Wales.
>>> >>> > > > > > > > Registered
>>> >>> > > > > number
>>> >>> > > > > > > >
>>> >>> > > > > > > > 4132533, VAT number GB 780 6803 14. Registered office
>>> >>> > > > > > > > address:
>>> >>> > > OCF
>>> >>> > > > > plc,
>>> >>> > > > > > > >
>>> >>> > > > > > > > 5 Rotunda Business Centre, Thorncliffe Park,
>>> Chapeltown,
>>> >>> > > Sheffield
>>> >>> > > > > S35
>>> >>> > > > > > > > 2PG.
>>> >>> > > > > > > >
>>> >>> > > > > > > > If you have received this message in error, please
>>> notify
>>> >>> > > > > > > > us
>>> >>> > > > > > > > immediately and remove it from your system.
>>> >>> > > > > > > >
>>> >>> > > > > > > > _______________________________________________
>>> >>> > > > > > > > rdo-list mailing list
>>> >>> > > > > > > > rdo-list at redhat.com <mailto:rdo-list at redhat.com>
>>> >>> > > > > > > > https://www.redhat.com/mailman/listinfo/rdo-list
>>> >>> > > > > > > >
>>> >>> > > > > > > > To unsubscribe: rdo-list-unsubscribe at redhat.com
>>> <mailto:rdo-list-unsubscribe at redhat.com>
>>> >>> > > > > > > >
>>> >>> > > > > > >
>>> >>> > > > > >
>>> >>> > > > >
>>> >>> > > >
>>> >>> > >
>>> >>> >
>>> >>
>>> >>
>>> >
>>> >
>>> > _______________________________________________
>>> > rdo-list mailing list
>>> > rdo-list at redhat.com <mailto:rdo-list at redhat.com>
>>> > https://www.redhat.com/mailman/listinfo/rdo-list
>>> >
>>> > To unsubscribe: rdo-list-unsubscribe at redhat.com
>>> <mailto:rdo-list-unsubscribe at redhat.com>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> rdo-list mailing list
>>> rdo-list at redhat.com
>>> https://www.redhat.com/mailman/listinfo/rdo-list
>>>
>>> To unsubscribe: rdo-list-unsubscribe at redhat.com
>>>
>>
>>
--
Graeme Gillies
Principal Systems Administrator
Openstack Infrastructure
Red Hat Australia
More information about the rdo-list
mailing list