[rdo-list] Python-shade in RDO
by Graeme Gillies
Hi,
A while ago there was a discussion around python-shade library and
getting it into RDO. [1]
It's been a few months since then, and shade is now successfully
packaged and shipped as part of Fedora [2] which is great, but now I
wanted to restart the conversation about how to make it available to
users of CentOS/RDO.
While it was suggested to get it into EPEL, I don't feel that is the
best course of action simply because of the restrictive update policies
of EPEL not allowing us to update it as frequently as needed, and also
because python-shade depends on the python openstack clients, which are
not a part of EPEL (as my understanding).
The best place for us to make this package available is in RDO itself,
as shade is an official Openstack big tent project, and RDOs aims to be
a distribution providing packages for Openstack projects.
So I just wanted to confirm with everyone and get some feedback, but
unless there is any major objections, I was going to start looking at
the process to get a new package into RDO, which I assume means putting
a review request in to the project https://github.com/rdo-packages
(though I assume a new repo needs to be created for it first).
Regards,
Graeme
[1] https://www.redhat.com/archives/rdo-list/2015-November/thread.html
[2] http://koji.fedoraproject.org/koji/packageinfo?packageID=21707
--
Graeme Gillies
Principal Systems Administrator
Openstack Infrastructure
Red Hat Australia
7 years, 5 months
[rdo-list] Multiple tools for deploying and testing TripleO
by Arie Bregman
Hi,
I would like to start a discussion on the overlap between tools we
have for deploying and testing TripleO (RDO & RHOSP) in CI.
Several months ago, we worked on one common framework for deploying
and testing OpenStack (RDO & RHOSP) in CI. I think you can say it
didn't work out well, which eventually led each group to focus on
developing other existing/new tools.
What we have right now for deploying and testing
--------------------------------------------------------
=== Component CI, Gating ===
I'll start with the projects we created, I think that's only fair :)
* Ansible-OVB[1] - Provisioning Tripleo heat stack, using the OVB project.
* Ansible-RHOSP[2] - Product installation (RHOSP). Branch per release.
* Octario[3] - Testing using RPMs (pep8, unit, functional, tempest,
csit) + Patching RPMs with submitted code.
=== Automation, QE ===
* InfraRed[4] - provision install and test. Pluggable and modular,
allows you to create your own provisioner, installer and tester.
As far as I know, the groups is working now on different structure of
one main project and three sub projects (provision, install and test).
=== RDO ===
I didn't use RDO tools, so I apologize if I got something wrong:
* About ~25 micro independent Ansible roles[5]. You can either choose
to use one of them or several together. They are used for
provisioning, installing and testing Tripleo.
* Tripleo-quickstart[6] - uses the micro roles for deploying tripleo
and test it.
As I said, I didn't use the tools, so feel free to add more
information you think is relevant.
=== More? ===
I hope not. Let us know if are familiar with more tools.
Conclusion
--------------
So as you can see, there are several projects that eventually overlap
in many areas. Each group is basically using the same tasks (provision
resources, build/import overcloud images, run tempest, collect logs,
etc.)
Personally, I think it's a waste of resources. For each task there is
at least two people from different groups who work on exactly the same
task. The most recent example I can give is OVB. As far as I know,
both groups are working on implementing it in their set of tools right
now.
On the other hand, you can always claim: "we already tried to work on
the same framework, we failed to do it successfully" - right, but
maybe with better ground rules we can manage it. We would defiantly
benefit a lot from doing that.
What's next?
----------------
So first of all, I would like to hear from you if you think that we
can collaborate once again or is it actually better to keep it as it
is now.
If you agree that collaboration here makes sense, maybe you have ideas
on how we can do it better this time.
I think that setting up a meeting to discuss the right architecture
for the project(s) and decide on good review/gating process, would be
a good start.
Please let me know what do you think and keep in mind that this is not
about which tool is better!. As you can see I didn't mention the time
it takes for each tool to deploy and test, and also not the full
feature list it supports.
If possible, we should keep it about collaborating and not choosing
the best tool. Our solution could be the combination of two or more
tools eventually (tripleo-red, infra-quickstart? :D )
"You may say I'm a dreamer, but I'm not the only one. I hope some day
you'll join us and the infra will be as one" :)
[1] https://github.com/redhat-openstack/ansible-ovb
[2] https://github.com/redhat-openstack/ansible-rhosp
[3] https://github.com/redhat-openstack/octario
[4] https://github.com/rhosqeauto/InfraRed
[5] https://github.com/redhat-openstack?utf8=%E2%9C%93&query=ansible-role
[6] https://github.com/openstack/tripleo-quickstart
7 years, 6 months
[rdo-list] Is Keystone/Identity-v3 supported by RDO Packstack? Multi-node swift --answer-file?
by Taisto Qvist
Hi folks,
I've managed to create a fairly well working packstack-answer file, that I
used for liberty installations, with a 4-multi-node setup, eventually
handling nested kvm, live-migration, LBAAS, etc, so I am quite happy with
that.
Now, my aim is Identity v3. From the packstack answer-file, it seems
supported, but I cant get it to work. I couldnt get it to work with
liberty, and now testing with Mitaka, it still doesnt work, failing on:
ERROR : Error appeared during Puppet run: 10.9.24.100_cinder.pp
Error: Could not prefetch cinder_type provider 'openstack': Execution of
'/usr/bin/openstack volume type list --quiet --format csv --long' returned
1: Expecting to find domain in project - the server could not comply with
the request since it is either malformed or otherwise incorrect. The client
is assumed to be in error. (HTTP 400) (Request-ID:
req-d8cccfb9-c060-4cdd-867d-603bf70ebf24)
I think this is also the same error I got, during my liberty tests.
Has anyone got this working? Should it work?
Another this which I just tested briefly, was to have swift-services on
separate nodes(instead of on the controller, as I have now), but I couldnt
get the syntax correct.
Anyone have an answer-file example that configures multiple swift-nodes?
Many Thanks,
Taisto Qvist
7 years, 7 months
[rdo-list] Tempest Packaging in RDO
by Daniel Mellado
Hi everyone,
As a follow-up from the conversations that we had on the irc, I wanted
to summarize the current issues and possible actions. As we ran out of
time during the meeting I'd really appreciate some feedback on this.
1) Tempest Plugins
With the current situation (project package and project-test package) we
do install the entry point with the main package, even if the
sub-package is not installed. In this case, Tempest will discover the
test entry point without the code and fail.
On this, I'd propose to integrate-back the -tests packages for the
in-tree plugins, even if it would mean adding some more dependencies to
them and remove tempest requirement as a dependency for out-tree ones
(i.e. Designate[2] or tempest-horizon[3]), which will get rid of any
circular dependency.
This seems to breaks RPM logic. This is only to allow mixing packages
and git/pip installations which is a source of troubles. At best, it
could be a temporary measure. If it's about circular dependencies, RPM
knows how to handle them, and the best way to break them would be
plugins requiring tempest and not the reverse.
We could have a a subpackage tempest-all that requires all the plugins
for an AIO install. (alternatively: tempest requires all plugins, and
plugins would require a tempest-core packages. tempest package being
empty and tempest-core containing the framework)
Also, the plugin state is not really optimal, as some of those plugins
would pin to an specific commit of tempest. All of this should be sorted
out in the end by [1] but for now we'll need to find some solution on this.
2) Tempest Requirements
As tempest is installed in the undercloud, it will use whatever
plugins are installed there, so if checking every test from the
overcloud is a must it'd need to have a lot of packages installed as
dependencies (that's the current status).
Some ideas for this have been.
- Create a parent-package/metapackage called 'tempest-all-test' or
similar, which will allow to install all the sub-componants packages.
This would allow not to install all the tempest dependencies but rather
only one component at a time. It would Requires: all test packages for
anyone who needs to install them all.
- Puppet-Tempest: it will install tempest itself (albeit only from
source right now, this can be addressed:
https://bugs.launchpad.net/puppet-tempest/+bug/1549366) but it will also
install tempest plugins based on the parameters that define the
availability of services. For example, if "ceilometer_available" is set
to true, it will install python-ceilometer-tests and set the config in
tempest.conf "[service_available] ceilometer=True"
3) Tempest Config Tool
Right now is the only diff between upstream vanilla and our
downstream fork, on here, our proposal could be to move it to its own
repo and decouple it from tempest so we could use vanilla and not depend
on the downstream fork. This will later on also integrated and used on
RefStack/DefCore (WIP).
There has been quite some discussion around this, and there are
duplicated projects doing the same work with some difference (basically
to use or not api_discovery)
During the past summit and afterwards, we agreed on creating something
that would depend on the installer (fetching the configuration from
TripleO), as the tool as it is won't be accepted on upstream tempest.
This had been dropped dead since, so I'd like to resume the discussion.
Thanks for any ideas!
Daniel
---
[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-August/101552.html
[2] https://review.rdoproject.org/r/#/c/1820/
[3]
https://github.com/openstack/tempest-horizon/blob/master/requirements.txt...
7 years, 7 months
Re: [rdo-list] Failure to build from source for Horizon: three new dependencies (need reviews)
by David Moreau Simard
Thanks Haikel !
I've put up new patches with your feedback and it turns out my
fedora-review problem was a known issue when building xstatic source
[1].
Simply cleaning the fedora-review mockroot resolved that.
[1]: https://bitbucket.org/thomaswaldmann/xstatic/issues/2/cannot-build-a-new-...
David Moreau Simard
Senior Software Engineer | Openstack RDO
dmsimard = [irc, github, twitter]
On Sat, Aug 6, 2016 at 3:22 AM, Haïkel Guémar <hguemar(a)redhat.com> wrote:
> On 06/08/16 05:27, David Moreau Simard wrote:
>> Hi,
>>
>> There's a FTBFS for Horizon, they've added three new dependencies [1].
>> The review.rdo for the ftbfs is here [2].
>>
>> Considering we're friday and we're likely to be the weekend without a
>> consistent build, I've figured I'd at least go ahead and submit
>> reviews for them ASAP.
>> These are my first package reviews ever, be nice :P
>>
>> - XStatic-Angular-Schema-Form:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1364603
>> - XStatic-objectpath: https://bugzilla.redhat.com/show_bug.cgi?id=1364607
>> - XStatic-tv4: https://bugzilla.redhat.com/show_bug.cgi?id=1364620
>>
>> The first one looks okay but the other two, while the koji scratch
>> build works, the fedora-review build fails.
>> It's probably an obvious mistake but I can't spot it right now. Will look later.
>>
>> [1]: https://review.openstack.org/#/c/332745/
>> [2]: https://review.rdoproject.org/r/#/c/1807/
>>
>> David Moreau Simard
>> Senior Software Engineer | Openstack RDO
>>
>> dmsimard = [irc, github, twitter]
>>
>
> As you're not yet a Fedora packager, I blocked the FE-NEEDSPONSOR
> tracker. Sponsoring process requires from you at least, two (good)
> informal reviews. Either Fedora or RDO-NEWTON, just link them back to
> one of your tickets.
>
> Feel free re-assign tickets, but until David is sponsored, just wait
> before setting fedora-review flag.
> I self-assigned the tickets as XStatic embeds javascript library. A
> reviewer that does not know that javascript libraries have a "temporary"
> bundling exception by packaging committee can make it drag on.
>
>
> Only briefly reviewed them, there are few issues here and there, easy
> fixes but not ready to be pre-imported as-is in CBS.
>
> Regards,
> H.
>
> PS: for packaging topic, you may CC jruzicka, he should be able to help.
7 years, 7 months
[rdo-list] [CentOS-devel] [Cloud SIG][RDO] RDO meeting minutes - 2016-08-31
by Chandan kumar
==============================
#rdo: RDO meeting - 2016-09-31
==============================
Meeting started by chandankumar at 15:00:44 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/rdo/2016-08-31/rdo_meeting_-_2016-09-31...
.
Meeting summary
---------------
* roll call (chandankumar, 15:00:59)
* tempest packaging (chandankumar, 15:04:03)
* LINK:
https://www.redhat.com/archives/rdo-list/2016-August/msg00240.html
(chandankumar, 15:05:23)
* ACTION: apevec review and try to simplify egg-info mangling for
-tests-tempest (apevec, 15:17:36)
* ACTION: chandankumar to take a look at python-tempest changes
(chandankumar, 15:17:51)
* config tool can be decoupled from redhat-openstack/tempest in ocata
release cycle, (chandankumar, 15:24:44)
* decoupling tempest config tool will help to consume in refstack in
future. (chandankumar, 15:26:17)
* shade distribution (chandankumar, 15:28:42)
* ACTION: apevec to update rdo-list thread about rdo-tools (apevec,
15:40:20)
* python3 support (chandankumar, 15:40:43)
* LINK: http://cbs.centos.org/koji/packageinfo?packageID=2504 <-
apevec (number80, 15:51:53)
* ACTION: apuimedo to talk to SCL sig for python35 (chandankumar,
15:54:29)
* oooq images (chandankumar, 15:57:06)
* Newton milestone 3 is this week, and so test day is next week,
pending promotions:
https://www.rdoproject.org/testday/newton/milestone3/ (rbowen,
16:01:09)
* If you will be at OpenStack Summit, and wish to give a demo:
https://etherpad.openstack.org/p/rdo-barcelona-summit-booth
(rbowen, 16:01:15)
* chair for next meeting (chandankumar, 16:01:38)
* ACTION: trown to chair for next meeting (chandankumar, 16:02:12)
Meeting ended at 16:02:19 UTC.
Action Items
------------
* apevec review and try to simplify egg-info mangling for
-tests-tempest
* chandankumar to take a look at python-tempest changes
* apevec to update rdo-list thread about rdo-tools
* apuimedo to talk to SCL sig for python35
* trown to chair for next meeting
Action Items, by person
-----------------------
* a
* apevec review and try to simplify egg-info mangling for
-tests-tempest
* chandankumar to take a look at python-tempest changes
* apevec to update rdo-list thread about rdo-tools
* apuimedo to talk to SCL sig for python35
* trown to chair for next meeting
* apevec
* apevec review and try to simplify egg-info mangling for
-tests-tempest
* apevec to update rdo-list thread about rdo-tools
* apuimedo
* apuimedo to talk to SCL sig for python35
* at
* chandankumar to take a look at python-tempest changes
* apevec to update rdo-list thread about rdo-tools
* chandankumar
* chandankumar to take a look at python-tempest changes
* changes
* chandankumar to take a look at python-tempest changes
* look
* chandankumar to take a look at python-tempest changes
* python-tempest
* chandankumar to take a look at python-tempest changes
* take
* chandankumar to take a look at python-tempest changes
* to
* apevec review and try to simplify egg-info mangling for
-tests-tempest
* chandankumar to take a look at python-tempest changes
* apevec to update rdo-list thread about rdo-tools
* apuimedo to talk to SCL sig for python35
* trown to chair for next meeting
* trown
* trown to chair for next meeting
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* apevec (97)
* chandankumar (69)
* apuimedo (41)
* number80 (36)
* dmellado|mtg (26)
* zodbot (17)
* leifmadsen (14)
* rbowen (11)
* jruzicka (11)
* dmellado (10)
* trown (9)
* jpena (9)
* imcsk8_ (6)
* weshay (6)
* eggmaster (5)
* myoung (4)
* openstack (3)
* rdogerrit (3)
* Duck (2)
* rdobot (1)
* jschlueter (1)
* pabelanger (1)
* coolsvap (1)
* hrybacki (1)
* at (0)
* to (0)
* take (0)
* python-tempest (0)
* a (0)
* look (0)
* changes (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
7 years, 7 months
[rdo-list] Upcoming OpenStack meetups
by Rich Bowen
The following are the meetups I'm aware of in the coming week where
OpenStack and/or RDO enthusiasts are likely to be present. If you know
of others, please let me know, and/or add them to
http://rdoproject.org/events
If there's a meetup in your area, please consider attending. If you
attend, please consider taking a few photos, and possibly even writing
up a brief summary of what was covered.
--Rich
* Tuesday August 30 in Tokyo, JP: 日本OpenStackユーザ会 第29回勉強会 -
http://www.meetup.com/Japan-OpenStack-User-Group/events/233195506/
* Wednesday August 31 in Seattle, WA, US: Openstack, Open source, and
Building Companies with Steve Poitras -
http://www.meetup.com/learnatlunch/events/229658042/
* Wednesday August 31 in Amsterdam, NL: Openstack & Ceph End-of-Summer
meetup - http://www.meetup.com/Openstack-Amsterdam/events/232800987/
* Wednesday August 31 in Köln, DE: Stackers Cologne Cloud Meetup -
http://www.meetup.com/OpenStack-Cologne/events/233216972/
* Thursday September 01 in Fort Lauderdale, FL, US: Monthly SFOUG
Meeting -
http://www.meetup.com/South-Florida-OpenStack-Users-Group/events/233134825/
* Thursday September 01 in Pleasanton, CA, US: The Rise of the
Container: The Dev/Ops Technology That Accelerates Ops/Dev -
http://www.meetup.com/EastBay-OpenStack/events/232779623/
* Thursday September 01 in Eindhoven, NL: OpenStack Cloud (IaaS) -
http://www.meetup.com/osbc-eindhoven/events/232221197/
* Saturday September 03 in Frederick, MD, US: OpenStack Encore -
http://www.meetup.com/KeyLUG/events/230704353/
--
Rich Bowen - rbowen(a)redhat.com
RDO Community Liaison
http://rdoproject.org
@RDOCommunity
7 years, 8 months
[rdo-list] Recent RDO blog posts
by Rich Bowen
It's been a few weeks since I posted a blog update, and we've had some
great posts in the meantime. Here's what RDO enthusiasts have been
blogging about for the last few weeks.
*Native DHCP support in OVN* by Numan Siddique
Recently native DHCP support has been added to OVN. In this post we
will see how native DHCP is supported in OVN and how it is used by
OpenStack Neutron OVN ML2 driver. The code which supports native
DHCP can be found here.
… read more at http://tm3.org/8d
<http://tm3.org/8d>
*Manual validation of Cinder A/A patches* by Gorka Eguileor
In the Cinder Midcycle I agreed to create some sort of document
explaining the manual tests I’ve been doing to validate the work on
Cinder’s Active-Active High Availability -as a starting point for
other testers and for the automation of the tests- and writing a
blog post was the most convenient way for me to do so, so here it is.
… read more at http://tm3.org/8e
<http://tm3.org/8e>
*Exploring YAQL Expressions* by Lars Kellogg-Stedman
The Newton release of Heat adds support for a yaql intrinsic
function, which allows you to evaluate yaql expressions in your Heat
templates. Unfortunately, the existing yaql documentation is
somewhat limited, and does not offer examples of many of yaql's more
advanced features.
… read more at http://tm3.org/8f
<http://tm3.org/8f>
*Tripleo HA Federation Proof-of-Concept* by Adam Young
Keystone has supported identity federation for several releases. I
have been working on a proof-of-concept integration of identity
federation in a TripleO deployment. I was able to successfully login
to Horizon via WebSSO, and want to share my notes.
… read more at http://tm3.org/8g
<http://tm3.org/8g>
*TripleO Deploy Artifacts (and puppet development workflow)* by Steve Hardy
For a while now, TripleO has supported a "DeployArtifacts"
interface, aimed at making it easier to deploy modified/additional
files on your overcloud, without the overhead of frequently
rebuilding images.
… read more at http://tm3.org/8h
<http://tm3.org/8h>
*TripleO deep dive session #6 (Overcloud - Physical network)* by Carlos
Camacho
This is the sixth video from a series of “Deep Dive” sessions
related to TripleO deployments.
… read more at http://tm3.org/8i
<http://tm3.org/8i>
*Improving QEMU security part 7: TLS support for migration* by Daniel
Berrange
This blog is part 7 of a series I am writing about work I’ve
completed over the past few releases to improve QEMU security
related features.
… read more at http://tm3.org/8j
<http://tm3.org/8j>
*Running Unit Tests on Old Versions of Keystone* by Adam Young
Just because Icehouse is EOL does not mean no one is running it. One
part of my job is back-porting patches to older versions of Keystone
that my Company supports.
… read more at http://tm3.org/8k
<http://tm3.org/8k>
*BAND-AID for OOM issues with TripleO manual deployments* by Carlos Camacho
First in the Undercloud, when deploying stacks you might find that
heat-engine (4 workers) takes lot of RAM, in this case for specific
usage peaks can be useful to have a swap file. In order to have this
swap file enabled and used by the OS execute the following
instructions in the Undercloud:
… read more at http://tm3.org/8l
<http://tm3.org/8l>
*Debugging submissions errors in TripleO CI* by Carlos Camacho
Landing upstream submissions might be hard if you are not passing
all the CI jobs that try to check that your code actually works.
Let’s assume that CI is working properly without any kind of infra
issue or without any error introduced by mistake from other
submissions. In which case, we might ending having something like:
… read more at http://tm3.org/8m
<http://tm3.org/8m>
*Ceph, TripleO and the Newton release* by Giulio Fidente
Time to roll up some notes on the status of Ceph in TripleO. The
majority of these functionalities were available in the Mitaka
release too but the examples work with code from the Newton release
so they might not apply identical to Mitaka.
… read more at http://tm3.org/8n
--
Rich Bowen - rbowen(a)redhat.com
RDO Community Liaison
http://rdoproject.org
@RDOCommunity
7 years, 8 months
