Re: [Rdo-list] image build fails silently on CentOS7
by Christopher Brown
Hi Charles
That's great news.
Would you mind adding this to the wiki if you have time and inclination?
There is a page on tripleo troubleshooting I am updating as I go along as well.
https://www.rdoproject.org/tripleo/troubleshooting/
If not I will add when back at a keyboard.
Regards,
Christopher Brown
OpenStack Engineer
OCF plc
Tel: +44 (0)114 257 2200
Web: www.ocf.co.uk
Blog: blog.ocf.co.uk
Twitter: @ocfplc
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.
This message is private and confidential. If you have received this message in error, please notify us and remove it from your system.
-------- Original message --------
From: Charles Short <cems(a)ebi.ac.uk>
Date: 2016/03/12 10:14 (GMT)
To: rdo-list(a)redhat.com
Subject: Re: [Rdo-list] image build fails silently on CentOS7
Ok, I have resolved my issue.
I am behind a work proxy server, so I already had to create a ~/.curlrc
file with proxy=http://[proxy_server] and added variable 'export
http_proxy=http://[proxy_server]'.
With this in place I had the issues I reported.
It turns out that I also needed to add 'export
https_proxy=http://[proxy_server]' ,( no need for export
DIB\_EPEL\_MIRROR=http://dl.fedoraproject.org/pub/epel, this was a red
herring)
So in summary -
Create ~/.curlrc file with proxy server
export http_proxy=http://[proxy_server:port]'
export https_proxy=http://[proxy_server:port]'
export USE_DELOREAN_TRUNK=1
export
DELOREAN_TRUNK_REPO="http://trunk.rdoproject.org/centos7-liberty/current/"
export DELOREAN_REPO_FILE="delorean.repo"
openstack overcloud image build --all
Charles
On 11/03/2016 16:16, Charles Short wrote:
> I suspect this is due to this sed line not working -
>
> [root@hh-undercloud ~]# grep -ir 'DIB_EPEL_MIRROR'
> /usr/share/diskimage-builder/
> /usr/share/diskimage-builder/elements/epel/README.rst:DIB_EPEL_MIRROR:
> /usr/share/diskimage-builder/elements/epel/pre-install.d/05-rpm-epel-release:BASE_URL=${DIB_EPEL_MIRROR:-https://dl.fedoraproject.org/pub/epel}
>
> /usr/share/diskimage-builder/elements/epel/pre-install.d/05-rpm-epel-release:DIB_EPEL_MIRROR=${DIB_EPEL_MIRROR:-}
>
> /usr/share/diskimage-builder/elements/epel/pre-install.d/05-rpm-epel-release:[
> -n "$DIB_EPEL_MIRROR" ] || exit 0
> /usr/share/diskimage-builder/elements/epel/pre-install.d/05-rpm-epel-release:sed
> -e
> "s|^#baseurl=http://download.fedoraproject.org/pub/epel|baseurl=$DIB_EPEL_..."
> -i /etc/yum.repos.d/epel.repo
>
>
> The change in the epo url has not been made to my
> /etc/yum.repos.d/epel.repo, so exporting the variable fixes this.
>
> /etc/yum.repos.d/epel.repo
>
> All due to this change
>
> https://github.com/openstack/diskimage-builder/commit/2b28993fb8fdfd3130e...
>
>
> ??
>
> On 11/03/2016 15:22, Charles Short wrote:
>> I have managed to find a way to progress.
>>
>> Previously the build was hanging on -
>>
>> /tmp/in_target.d/pre-install.d/05-rpm-epel-release
>>
>> the same as in the bug.
>>
>> However if I additionally add
>>
>> export DIB\_EPEL\_MIRROR=http://dl.fedoraproject.org/pub/epel
>>
>> then the build progresses past this point and finishes.
>>
>> Maybe this should be added to the documentation (if correct)?
>>
>> Charles
>>
>> On 11/03/2016 11:57, Charles Short wrote:
>>> CentOS 7 (1511)/Liberty
>>>
>>> Installed on baremetal using
>>> http://docs.openstack.org/developer/tripleo-docs/index.html
>>>
>>> Seeing this bug -
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1233210
>>>
>>> Anyone else having problems building images on CentOS7?
>>>
>>> Thanks
>>>
>>> Charles
>>>
>>
>
--
Charles Short
Cloud Engineer
Virtualization and Cloud Team
European Bioinformatics Institute (EMBL-EBI)
Tel: +44 (0)1223 494205
_______________________________________________
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 years
[Rdo-list] Triple on sdcard
by Ignacio Bravo
Hi,
I have been using Rdo Manager (Tripleo) to deploy outflows and wanted to check a couple of functionalities with the group.
We are deploying on blade servers which are good for compute but very bad for storage, as they only support two drives plus an sdcard each.
I read that there was some work to deploy ceph on the compute nodes, which would be optimal for our scenario. Do you guys know how this is coming along?
A second alternative is to deploy the overcloud image on an sdcard and boot from there leaving the two disks to be used for ceph. We got 64gb cards but were surprised when the ironic introspection returned just 15gb as available for installation, under the minimum of 40gb of the overcloud image.
Has anyone been able to deploy on an sdcard using ironic?
Thanks,
IB
-
Ignacio Bravo
LTG Federal
9 years
[Rdo-list] A status of the beta platform rpmfactory.beta.rdoproject.org
by Fabien Boucher
Hello everybody,
As you know we are provisioning an instance of Software Factory to host
RDO distgits and validation jobs. The platform can be accessed at the address
https://rpmfactory.beta.rdoproject.org.
By this mail we wanted to give a status of the platform:
- Authentication is setup with Github Oauth. So rpmf need to be authorized
on your Github account (this can be set up upon your first login, you will
be redirected to github to allow rpmf).
- All projects listed in rdoinfo have been imported. For each project there
are two repos:
- the mirror repo: Constantly synced from git.openstack.org
- the distgit repo %project-distgit. Temporarily synced from github.com/openstack-packages
- All repositories in rpmf are replicated to http://github.com/rdo-packages via
the gerrit replication plugin.
- A periodic job in rpmf Zuul is configured to sync all mirror repos from upstream
http://rpmfactory.beta.rdoproject.org/jenkins/job/upstream-update/
- A periodic job in rpmf Zuul is configured to sync (until a migration to rpmf) all
distgit repos
http://rpmfactory.beta.rdoproject.org/jenkins/job/distgit-update/
- RDO maintainers referenced in rdoinfo and belonging to projects have been
added to core/ptl groups of each repo related to those projects.
- <project>-distgit repos have rpm-master, rpm-liberty, rdo-liberty branches
- A delorean-ci job is triggered by Zuul when a change is proposed on
rpm-master branch
http://rpmfactory.beta.rdoproject.org/jenkins/job/delorean-ci/95/console
- rpmf comes with an integration with koji. Default provided JJB builders can
be used to build and export packages against koji. (We are going to test it with CBS).
- We have defined a job called packstack-validate
(An output sample http://rpmfactory.beta.rdoproject.org/jenkins/job/packstack-validate/12/c...)
(http://rpmfactory.beta.rdoproject.org/r/gitweb?p=config.git;a=blob;f=jobs...)
This job use a default builder called base-pkg-validation: http://rpmfactory.beta.rdoproject.org/r/gitweb?p=config.git;a=blob;f=jobs...
This default builder: deals with ZUUL env vars, fetch upstream source, builds a SRPM,
requests a build against koji, retrieves built packages, and creates a local repo
on the slave node.
This job packstack-validate is an example job that just run packstack and smoke validation.
- Another job called pkg-export has been defined to build (non-scratch) when a change
has been approved in Gerrit and is passing through the gate pipeline.
(An output http://rpmfactory.beta.rdoproject.org/jenkins/job/pkg-export/16/console)
(http://rpmfactory.beta.rdoproject.org/r/gitweb?p=config.git;a=blob;f=jobs...)
This job use a default builder called base-pkg-exportation: http://rpmfactory.beta.rdoproject.org/r/gitweb?p=config.git;a=blob;f=jobs...
This builder is designed to wait for job results (for the jobs running for the same
change in the gate pipeline) if there are some. Then it starts a build against koji
(in a non-scratch mode). RPM definitive build as well as change merged in the GIT
repo are then done only if additional jobs have succeeded.
- Jobs/Jobs triggering definition as well as slave nodes are defined in the special
config repo:
http://rpmfactory.beta.rdoproject.org/r/gitweb?p=config.git;a=tree
- Requesting a change in that config repo is done via Gerrit and the typical workflow
of test + review + approval. Approval can only be done by member config-core group.
- A special group rdo-provenpackagers has been created. All projects *-ptl group
include rdo-provenpackagers.
- Additional patches included in a distgit are supposed to be managed in form of gerrit
open reviews. For instance have a look to the patches chain of ironic for liberty:
http://rpmfactory.beta.rdoproject.org/r/#/c/637 This chain of patches is attached to the
liberty-patches branch and each change on it will trigger a job called tox-validate.
- rdopkg is officially hosted in rpmfactory. We are currently working on adding the
RPMFactory workflow to this tool (WIP, but you can play around by checking this
review: http://rpmfactory.beta.rdoproject.org/r/624 )
- You can test the new workflow manually by following the instructions here:
http://softwarefactory-project.io/etherpad/p/testdrivesf
- rdoinfo is forked in rpmfactory until we push into production. This version of rdoinfo
configures the rpmfactory repositories. You can get it here: http://rpmfactory.beta.rdoproject.org/r/gitweb?p=rdoinfo.git;a=summary
and you can use it with rdopkg by running: echo 'RDOINFO_REPO="ssh://rpmfactory.beta.rdoproject.org:29418/rdoinfo.git"' >> ~/.rdopkg/conf.d/myrdoinfo.py
Today the beta platform is not connected to CBS but only to an internal Koji. So submitting
changes and validating them to simulate a real workflow won't have any incidence against the
real RDO RPM repos. Furthermore any test changes merged in some GIT repos on rpmf will be overwritten
by the periodic distgit-update job.
Login with github, if you are a maintainer of a package you should already be provisioned
in rpmfactory with the roles of "core" and "PTL" on your project, allowing you to approve
reviews, please make sure it is the case.
We invite you to have a look to the platform in order to raise issues/questions
about it before the platform is re-deployed for production under review.rdoproject.org.
Regards,
The Cobra Team.
9 years
[Rdo-list] rdoproject.org infra outage post-mortem
by Tristan Cacqueray
Hello folks,
here is a little note about what happened... The underlying cloud
(called rcip-dev) experienced an outage related to rabbitmq cluster
inconsitency:
* No service was not able to connect to rabbitmq on port 5672
* Restarting controllers didn't helped until the rabbitmq cluster was
killed and recreated.
* From that point, qrouter lost the VIP and no VRRP packets was sent.
* Restarting the controller one by one after cleaning rabbitmq cluster
solved that issue.
Timeline:
* 00:00 UTC: API started to timeout
* 17:30 UTC: Network connections was lost
* 18:15 UTC: Network connectivity restored
Services' API and instances are now nominals.
Special kudos to Cédric Lecomte for fixing the cloud and saving the day!
Regards,
-Tristan
9 years
