[rdo-list] [Meeting] RDO meeting (2016-10-12) Minutes
by Jakub Ruzicka
==============================
#rdo: RDO meeting - 2016-10-12
==============================
Meeting started by jruzicka at 15:03:49 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/rdo/2016-10-12/rdo_meeting_-_2016-10-12...
.
Meeting summary
---------------
* roll call (jruzicka, 15:04:03)
* https://etherpad.openstack.org/p/RDO-Meeting (jruzicka, 15:05:58)
* Preparation for RCIP-DEV move October 17th (jruzicka, 15:08:51)
* ACTION: dmsimard to post a reminder of oct 17th maintenance of
rcip-dev to rdo-list (dmsimard, 15:12:46)
* Newton GA test day Oct 13/14 -
https://www.rdoproject.org/testday/newton/final/ (jruzicka, 15:16:14)
* Thank you to all the people who have improved the test day
documentation! (jruzicka, 15:17:09)
* FYI: ci.centos.org will soon have an OpenStack cloud based on RDO
Newton! (jruzicka, 15:23:03)
* upcoming rdopkg refactor might break things - let jruzicka know what
rdopkg parts do you use (jruzicka, 15:29:05)
* Help out at the RDO booth (demos, q&a, or just meet our users) -
https://etherpad.openstack.org/p/rdo-barcelona-summit-booth
(jruzicka, 15:35:17)
* open floor (jruzicka, 15:37:38)
Meeting ended at 15:40:18 UTC.
Action Items
------------
* dmsimard to post a reminder of oct 17th maintenance of rcip-dev to
rdo-list
Action Items, by person
-----------------------
* dmsimard
* dmsimard to post a reminder of oct 17th maintenance of rcip-dev to
rdo-list
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* jruzicka (43)
* apevec (34)
* dmsimard (34)
* trown (17)
* zodbot (9)
* rbowen (8)
* jschlueter (7)
* leifmadsen (5)
* rdogerrit (4)
* flepied (3)
* openstack (3)
* wfoster (3)
* jrist (3)
* rook (3)
* jjoyce (2)
* jkilpatr (2)
* misc (1)
* eggmaster (1)
* mengxd (1)
* myoung (1)
* mburned (1)
* Humbedooh (1)
* Duck (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
8 years, 3 months
[rdo-list] Mitaka upgrade to Newton
by Devin Acosta
Last night I shut down my entire RDO Mitaka environment and then did a
"yum -y update" to upgrade to the Newton release. I worked on merging a
lot of the .rpmnew files for Neutron, Nova, Cinder, to be the latest
version of the files. I am a little confused on how I am suppose to
upgrade the Database for each of the individual parts, because the
openstack-db command is no longer available. I was able to update a few
services like Neutron with "neutron-db-manage current", however the one
issue i'm noticing right now is that Cinder won't start.
I am seeing errors about "ServiceTooOld: One of the services is in
Liberty version. We do not provide backward compatibility with Liberty
now, you need to upgrade to Mitaka first.". I was running Mitaka just
fine before the Newton update, I'm not sure what I need to change in
order get get past this error. Anyone that can assist me or provide me a
guide on the proper upgrade path when you take down the whole cluster
would be appreciate!
2016-10-13 23:17:48.740 1037694 CRITICAL cinder
[req-11ed371c-7132-417b-ae55-1c31934b3102 - - - - -] ServiceTooOld: One
of the services is in Liberty version. We do not provide backward
compatibility with Liberty now, you need to upgrade to Mitaka first.
2016-10-13 23:17:48.740 1037694 ERROR cinder Traceback (most recent call
last):
2016-10-13 23:17:48.740 1037694 ERROR cinder File
"/usr/bin/cinder-scheduler", line 10, in <module>
2016-10-13 23:17:48.740 1037694 ERROR cinder sys.exit(main())
2016-10-13 23:17:48.740 1037694 ERROR cinder File
"/usr/lib/python2.7/site-packages/cinder/cmd/scheduler.py", line 53, in main
2016-10-13 23:17:48.740 1037694 ERROR cinder server =
service.Service.create(binary='cinder-scheduler')
2016-10-13 23:17:48.740 1037694 ERROR cinder File
"/usr/lib/python2.7/site-packages/cinder/service.py", line 382, in create
2016-10-13 23:17:48.740 1037694 ERROR cinder cluster=cluster)
2016-10-13 23:17:48.740 1037694 ERROR cinder File
"/usr/lib/python2.7/site-packages/cinder/service.py", line 202, in __init__
2016-10-13 23:17:48.740 1037694 ERROR cinder *args, **kwargs)
2016-10-13 23:17:48.740 1037694 ERROR cinder File
"/usr/lib/python2.7/site-packages/cinder/scheduler/manager.py", line 68,
in __init__
2016-10-13 23:17:48.740 1037694 ERROR cinder self.driver =
importutils.import_object(scheduler_driver)
2016-10-13 23:17:48.740 1037694 ERROR cinder File
"/usr/lib/python2.7/site-packages/oslo_utils/importutils.py", line 44,
in import_object
2016-10-13 23:17:48.740 1037694 ERROR cinder return
import_class(import_str)(*args, **kwargs)
2016-10-13 23:17:48.740 1037694 ERROR cinder File
"/usr/lib/python2.7/site-packages/cinder/scheduler/filter_scheduler.py",
line 40, in __init__
2016-10-13 23:17:48.740 1037694 ERROR cinder super(FilterScheduler,
self).__init__(*args, **kwargs)
2016-10-13 23:17:48.740 1037694 ERROR cinder File
"/usr/lib/python2.7/site-packages/cinder/scheduler/driver.py", line 85,
in __init__
2016-10-13 23:17:48.740 1037694 ERROR cinder self.volume_rpcapi =
volume_rpcapi.VolumeAPI()
2016-10-13 23:17:48.740 1037694 ERROR cinder File
"/usr/lib/python2.7/site-packages/cinder/rpc.py", line 194, in __init__
2016-10-13 23:17:48.740 1037694 ERROR cinder obj_version_cap =
self.determine_obj_version_cap()
2016-10-13 23:17:48.740 1037694 ERROR cinder File
"/usr/lib/python2.7/site-packages/cinder/rpc.py", line 233, in
determine_obj_version_cap
2016-10-13 23:17:48.740 1037694 ERROR cinder
cinder.context.get_admin_context(), cls.BINARY)
2016-10-13 23:17:48.740 1037694 ERROR cinder File
"/usr/lib/python2.7/site-packages/cinder/objects/service.py", line 188,
in get_minimum_obj_version
2016-10-13 23:17:48.740 1037694 ERROR cinder binary)
2016-10-13 23:17:48.740 1037694 ERROR cinder File
"/usr/lib/python2.7/site-packages/cinder/objects/service.py", line 173,
in _get_minimum_version
2016-10-13 23:17:48.740 1037694 ERROR cinder raise
exception.ServiceTooOld(msg)
2016-10-13 23:17:48.740 1037694 ERROR cinder ServiceTooOld: One of the
services is in Liberty version. We do not provide backward compatibility
with Liberty now, you need to upgrade to Mitaka first.
--
Devin Acosta RHCA|LFCE
Red Hat Certified Architect, Linux Geek
e: devin(a)linuxguru.co
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_camp...>
8 years, 3 months
[rdo-list] Manila TripleO Newton
by Charles Short
Hi,
I notice that the Manila NetApp template that was missing in Mitaka is
now present in TripleO Newton. Does this mean I can deploy it?
/usr/share/openstack-tripleo-heat-templates/environments/manila-netapp-config.yaml
What is the official status?
Thanks
Charles
--
Charles Short
Cloud Engineer
Virtualization and Cloud Team
European Bioinformatics Institute (EMBL-EBI)
Tel: +44 (0)1223 494205
8 years, 3 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
8 years, 3 months
[rdo-list] FOSDEM: Virtualization and IaaS devroom call for papers
by Rich Bowen
Submission deadline: 18 November 2016
Acceptance notifications: 04 December 2016
Final schedule announcement: 11 December 2016
Devroom: 04 February 2017 (one day)
Submit Your Proposal
All submissions must be made via the Pentabarf event planning site. If
you have not used Pentabarf before, you will need to create an account.
If you submitted proposals for FOSDEM in previous years, you can use
your existing account.
After creating the account, select Create Event to start the submission
process. Make sure to select Virtualisation and IaaS devroom from the
Track list. Please fill out all the required fields, and provide a
meaningful abstract and description of your proposed session.
More details, and submission form, at
http://www.ovirt.org/blog/2016/10/call-for-proposal-fosdem-2017/
--
Rich Bowen - rbowen(a)redhat.com
RDO Community Liaison
http://rdoproject.org
@RDOCommunity
8 years, 3 months
