[rdo-list] Fedora: running RDO (openstack-mitaka)
by Nir Levy
Main goal: installing any RDO over Fedora 24, starting with all in one.
according to:
https://www.rdoproject.org/install/quickstart/ and https://www.rdoproject.org/documentation/packstack-all-in-one-diy-configu...
sudo yum install https://www.rdoproject.org/repos/rdo-release.rpm
sudo yum update -y
sudo yum install -y openstack-packstack
packstack --allinone --gen-answer_file=answer.txt
and afterwords.
setting my interfaces:
CONFIG_NOVA_NETWORK_PUBIF --novanetwork-pubif
CONFIG_NOVA_COMPUTE_PRIVIF --novacompute-privif
CONFIG_NOVA_NETWORK_PRIVIF --novanetwork-privif
setting additional settings:
CONFIG_PROVISION_DEMO --provision-demo n (y for allinone)
CONFIG_SWIFT_INSTALL --os-swift-install (y for allinone) n Set to y if you would like PackStack to install Object Storage.
CONFIG_NAGIOS_INSTALL --nagios-install n (y for allinone) Set to y if you would like to install Nagios. Nagios provides additional tools for monitoring the OpenStack environment.
CONFIG_PROVISION_ALL_IN_ONE_OVS_BRIDGE --provision-all-in-one-ovs-bridge n (y for allinone)
packstack --answer-file=answer.txt
1) first issue I've encountered is :
Error: Parameter mode failed on File[rabbitmq.config]: The file mode specification must be a string, not 'Fixnum' at ...
occurs,
I have to verify:
/usr/lib/python2.7/site-packages/packstack/puppet/templates/amqp.pp
/usr/share/openstack-puppet/modules/module-collectd/manifests/plugin/amqp.pp
and modify the following:
https://review.openstack.org/349908
2) second issue I've encountered is :
https://bugs.launchpad.net/packstack/+bug/1597951
after modifying SELinux
/usr/sbin/getenforce
Enforcing
setenforce permissive
/usr/sbin/getenforce
Permissive
seems to resolve it:
3) third issue is the current issue.
192.168.13.85_amqp.pp: [ DONE ] <-> previously failed.
192.168.13.85_mariadb.pp: [ ERROR ]
Applying Puppet manifests [ ERROR ]
192.168.13.85_mariadb.pp: [ ERROR ]
Applying Puppet manifests [ ERROR ]
ERROR : Error appeared during Puppet run: 192.168.13.85_mariadb.pp
Error: Execution of '/usr/bin/yum -d 0 -e 0 -y install mariadb-galera-server' returned 1: Yum command has been deprecated, redirecting to '/usr/bin/dnf -d 0 -e 0 -y install mariadb-galera-server'.
You will find full trace in log /var/tmp/packstack/20160802-193240-sGLWV3/manifests/192.168.13.85_mariadb.pp.log
Please check log file /var/tmp/packstack/20160802-193240-sGLWV3/openstack-setup.log for more information
Nir Levy
SW Engineer
Web: www.asocstech.com<http://www.asocstech.com/> |
[cid:image001.jpg@01D1B599.5A2C9530]
Nir Levy
SW Engineer
Web: www.asocstech.com<http://www.asocstech.com/> |
[cid:image001.jpg@01D1B599.5A2C9530]
8 years, 3 months
[rdo-list] Future of Tempest packaging in RDO
by Chandan kumar
Hi,
Tempest is the OpenStack integration testing suite which is used by
upstream CI to test functionality against each patchset submitted.
RDO provides:
* RPM of modified version of tempest containing the additional script
for generating tempest config and configuring tempest easily[VI].
* test sub packages and tempest-service packages for all OpenStack
services tempest plugins
These were consumed by upstream puppet CI, Weirdo, and OOOQ CI.
Currently, below are the lists of problem associated with it:
[1]. In upstream puppet CI,OpenStack puppet services modules are
tested using openstack-puppet-integration[I].
which installs tempest from git source and tempest-services
plugins are installed through rpm using puppet-tempest.
The problem here is it allows mixing installing tempest from git
and plugins as RPM which is not a configuration that should be
supported by RDO.
and one of the side effects is you can't use tempest plugins from
pure packages unless installing separately tempest.
[2]. In OOOQ CI, It uses RDO tempest rpm that installs all the test
sub packages.
The tempest rpm is currently outdated in terms of Upstream
Tempest and some of the functionality which works with the tempest
rpm,
might not work with upstream so we are again ending up filling bugs.
[3.] Circular dependency problems with tempest [II].
The tempest rpm installs all the tempest plugins and test sub packages.
Suppose you install the undercloud, try to run tempest from it. You
have many packages with the common code for the various services (say:
python-ceilometer) which
expose the entry point for code which is not available (as it is in
python-ceilometer-tests).When you try to run testr list-tests (or
other discovery wrappers) and you get tons
of errors, until you figure out and install all the required -tests package.
This was and is confusing for many people and lead to bugs again [III].
[4.] Problems in installing and testing a tempest plugins separately.
For now, only two (designate and horizon) tempest-plugin packages
require openstack-tempest [IV][V].
So for installing and testing a tempest plugin, we will again end up
with the problem [3]
Another case is that Tempest plugins differ from each other in terms
of behaviour: some of them need to be specifically disabled if
installed
but not used, others require specific configuration to run (or not).
It causes another problem while testing it.
These are the above lists of problems we found in current tempest rpm
and others might have some more
We are looking forward to discussing the same in order to find a
better solution for everyone.
Links:
[I]. https://github.com/openstack/puppet-openstack-integration/blob/master/run...
[II]. https://review.rdoproject.org/r/#/c/1780/
[III]. https://bugzilla.redhat.com/show_bug.cgi?id=1335541
[IV]. https://github.com/rdo-packages/designate-tempest-plugin-distgit/blob/rpm...
[V]. https://review.rdoproject.org/r/#/c/1820/
[VI]. https://review.gerrithub.io/#/c/266365
Thanks,
Chandan Kumar
8 years, 3 months
[rdo-list] tripleo-quickstart: new features, and upcoming changes
by Wesley Hayutin
Greetings,
It's been a little while since the RDO CI team has updated the community
with new features coming to tripleo-quickstart and CI.
Since I have your attention I'll walk through some upcoming changes that
you need to be aware of.
- We've determined that the role and jinja2 template [1] we use to
configure the overcloud is too large and not very composable. The current
template contains registration, introspection, flavor creation, and
network-isolation setup.
- This will be split into three distinct roles in the future [2]
- ansible-role-tripleo-overcloud-prep-images
- ansible-role-tripleo-overcloud-prep-flavors
- ansible-role-tripleo-overcloud-prep-network
- Additionally we will be creating a role responsible for copying
custom heat templates, nic-conifgs, and other config to the undercloud to
prep for a deployment [2]
- The tripleo-quickstart core's have decided to remove the roles
responsible for configuring and deploying the overcloud from
tripleo-quickstart and make them 3rd party roles (oooq-extras)
Now for the new features:
- Paul Belanger has added tripleo-quickstart doc to the openstack doc
server.
- http://docs.openstack.org/developer/tripleo-quickstart/
- Paul Belanger has added a lint job for tripleo-quickstart in the
openstack ci system
- e.g.
http://logs.openstack.org/90/352990/1/check/gate-tripleo-quickstart-linte...
- Harry Rybacki is about to land a patch to automatically generate
TripleO documentation via CI execution [3]. This is a great feature to
keep TripleO docs up to date, documenting step by step what CI is doing,
and great for reproducing bugs!!
- Attila Darazs has added 3rd party OpenStack CI. You can now run rdo
ci against your openstack reviews.
- To test w/ the latest delorean builds use keyword "rdo-ci-testing"
- To test w/ the latested promoted RDO quickstart image use keyword
"rdo-ci-check"
Upcoming features under development:
- Mathieu Bultel has a working proof of concept that takes an already
deployed TripleO environment (virt only), shuts it down, saves it to a file
server and then restores the environment on a new clean libvirt host. This
has helped Mathieu iterate on upgrade testing more efficiently. This work
has practical implications for sales and other areas.
There is some additional cool stuff on the way, but it's a little too early
to advertise it. Thanks to Paul, Harry, Attila and Mathieu and the rest of
the RDO community!
[1]
https://github.com/openstack/tripleo-quickstart/blob/master/roles/tripleo...
[2] https://trello.com/c/yMoI2i1d
[3]
https://ci.centos.org/artifacts/rdo/jenkins-poc-hrybacki-tripleo-quicksta...
8 years, 3 months
[rdo-list] Tracking package updates between RDO and RHOS
by Damien Ciabrini
Hi folks,
I'm trying to get a full picture of how shared services like rabbitmq or galera
are packaged in RDO and how/when they are updated.
>From what I understand - please correct me if I'm wrong - this is how it works:
* such packages are usually tagged with cloud7-openstack-common-release [1]
* they are generally built with dist git from Fedora or EPEL,
unless specific override is needed [2]
* the version of those packages is the same on RDO liberty and RDO mitaka.
* they are manually updated to keep close to what is in latest RHOS.
Now assuming the above is correct, I wonder how to best deal with package
updates so that RDO community and RHOS maintainers can coordinate efficiently?
Specifically, I can think of a few update scenarios:
1. minor package updates (e.g. new minor upstream release, CVE,...)
How to best notify RDO in case RHOS perform such updates? Push
new specfile review in RDO gerrit?
2. major package upgrade (e.g. mariadb 5.5 -> 10.1)
I suppose major version upgrade should only take place on new RDO version
because it makes it simpler to test. But how should we isolate major
version upgrade to impact several RDO release?
* Should we always move package from common-release to
{mitaka|newton|...}-release tag when we plan to upgrade it to a
new major version, like it was done for mariadb?
* Should we discuss those details via a specfile review in RDO gerrit?
3. package update in RDO needs to reach RHOS
I expect this to be very rare, but in case RDO needs to upgrade a
package version for packaging reasons (e.g. mariadb), how to best
notify RHOS maintainer to plan upgrade scenarios or other tests
ahead of time?
Thanks in advance for your feedback :)
[1] http://cbs.centos.org/koji/packages?tagID=63
[2] https://github.com/rdo-common/
--
Damien
8 years, 3 months
[rdo-list] [minute] RDO meeting (2016-08-10) minutes
by Haïkel
==============================
#rdo: RDO meeting - 2016-08-10
==============================
Meeting started by number80 at 15:02:05 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/rdo/2016-08-10/rdo_meeting_-_2016-08-10...
.
Meeting summary
---------------
* roll call (number80, 15:02:34)
* Add vanilla tempest package (number80, 15:05:09)
* LINK:
https://github.com/openstack/puppet-tempest/blob/master/manifests/params....
(chandankumar, 15:19:57)
* Volunteers wanted to talk about what you're doing in Newton, for RDO
podcast (number80, 15:27:43)
* rbowen is looking for volunteers for RDO Newton release podcasts
(number80, 15:28:16)
* Cleanup old commits from former centos7-master in DLRN instance
(number80, 15:28:58)
* ACTION: jpena to purge old commits from centos-master (jpena,
15:33:27)
* chair for next week meeting (number80, 15:34:11)
* jpena to chair next week meeting (number80, 15:34:36)
* open floor (number80, 15:34:48)
Meeting ended at 15:42:23 UTC.
Action Items
------------
* jpena to purge old commits from centos-master
Action Items, by person
-----------------------
* jpena
* jpena to purge old commits from centos-master
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* number80 (76)
* amoralej (24)
* EmilienM (20)
* chandankumar (16)
* jpena (15)
* tosky (8)
* rbowen (8)
* zodbot (7)
* hrybacki (2)
* weshay (2)
* jruzicka (2)
* coolsvap (1)
* flepied (1)
* jschlueter (1)
* rdogerrit (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
8 years, 3 months
[rdo-list] TripleO Network Template Generator
by Ben Nemec
I sent this to openstack-dev too, but I think we have a number of users
on rdo-list that might benefit from it too. Here's what I sent earlier:
This is something that has existed for a while, but I had been hesitant
to evangelize it until it was a little more proven. At this point I've
used it to generate templates for a number of different environments,
and it has worked well. I decided it was time to record another demo
and throw it out there for the broader community to look at. See
details on my blog:
http://blog.nemebean.com/content/tripleo-network-isolation-template-gener...
Most of what you need to know is either there or in the video itself.
Let me know what you think.
Thanks.
-Ben
8 years, 3 months
[rdo-list] RDO bloggers - week of August 8
by Rich Bowen
Here's what RDO enthusiasts have been blogging about this week:
Customizing a Tripleo Quickstart Deploy by Adam Young
Tripleo Heat Templates allow the deployer to customize the controller
deployment by setting values in the controllerExtraConfig section of the
stack configuration. However, Quickstart already makes use of this in
the file /tmp/deploy_env.yaml, so if you want to continue to customize,
you need to work with this file.
… read more at http://tm3.org/88
fedora-review tool for reviewing RDO packages by Chandan Kumar
This tool makes reviews of rpm packages for Fedora easier. It tries to
automate most of the process. Through a bash API the checks can be
extended in any programming language and for any programming language.
… read more at http://tm3.org/89
OpenStack operators, developers, users… It’s YOUR summit, vote! by David
Simard
Once again, the OpenStack Summit is nigh and this time it’ll be in
Barcelona. The OpenStack Summit event is an opportunity for Operators,
Developers and Users alike to gather, discuss and learn about OpenStack.
What we know is that there’s going to be keynotes, design sessions for
developers to hack on things and operator sessions for discussing and
exchanging around the challenges of operating OpenStack. We also know
there’s going to be a bunch of presentations on a wide range of topics
from the OpenStack community.
… read more at http://tm3.org/8a
TripleO Composable Services 101 by Steve Hardy
Over the newton cycle, we've been working very hard on a major refactor
of our heat templates and puppet manifiests, such that a much more
granular and flexible "Composable Services" pattern is followed
throughout our implementation.
… read more at http://tm3.org/8b
TripleO deep dive session #5 (Undercloud - Under the hood) by Carlos Camacho
This is the fifth video from a series of “Deep Dive” sessions related to
TripleO deployments.
… watch at http://tm3.org/8c
--
Rich Bowen - rbowen(a)redhat.com
RDO Community Liaison
http://rdoproject.org
@RDOCommunity
8 years, 3 months
[rdo-list] FYI: New slaves now in use on ci.centos.org for RDO
by David Moreau Simard
Hi,
We've tested successfully three new slaves out of the "beta" OpenStack
cloud on ci.centos.org.
We're going to be lowering the amount of threads on our existing slave
and spread the load evenly across the 4 slaves.
The objective is two-fold:
- Spread load evenly across four slaves rather than one: redundancy
and additional capacity/concurrency
- Test real workloads on the ci.centos.org OpenStack cloud before it
is opened up to additional tenants
I will be monitoring closely (moreso than usual) the jobs but
everything /should/ work.
You can tell on which slave a particular job was run from at the very
beginning of the console output, it looks like this:
"Building remotely on rdo-ci-cloudslave01 (rdo) in workspace [...]"
If you notice anything odd about jobs running on the new cloudslaves
machines, please let me know directly.
Thanks !
David Moreau Simard
Senior Software Engineer | Openstack RDO
dmsimard = [irc, github, twitter]
8 years, 3 months
