Hello,
It's time for our weekly PaaS SIG sync-up meeting
Time: 1700 UTC - Wedensdays
Date: Today Wedensday, 05 October 2016
Where: IRC- Freenode - #centos-devel
Agenda:
- OpenShift Current Status
-- rpms
-- Documentation
-- Automated testing
-- images / image building
- Origin LTS ??
- Open Floor
Minutes from last meeting:
https://www.centos.org/minutes/2016/september/centos-devel.2016-09-28-17.00…
FYI, we'll be testing the OpenStack Newton GA packages next week. Please
join us.
-------- Forwarded Message --------
Subject: RDO Newton GA Test Day - October 13, 14
Date: Wed, 5 Oct 2016 10:05:12 -0400
From: Rich Bowen <rbowen(a)redhat.com>
To: rdo-list(a)redhat.com <rdo-list(a)redhat.com>
Please join us for the final test day of the Newton cycle.
Full details of the test day are at
https://www.rdoproject.org/testday/newton/final/
We will be testing on October 13th and 14th. Come to #rdo on the
Freenode IRC network for help and discussion.
Based on discussion on the list, I've moved the test scenarios document
entirely to an etherpad, to make it easier to add test scenarios, as
well as easier for people to add their test day notes.
Please have a look at the test scenario etherpad prior to test day, and
ensure that desired scenarios are listed, and that instructions are
there for testers to follow -
https://etherpad.openstack.org/p/rdo-newton-ga-testday-testplan
--
Rich Bowen - rbowen(a)redhat.com
RDO Community Liaison
http://rdoproject.org
@RDOCommunity
Hello,
I'm traveling this week and won't be near any internet during meeting
time. Let's skip it this week. If you have anything opstools related,
please send it to the list.
Thanks,
Matthias
Hi everyone,
Ceph has released their 10.2.3 packages a few hours ago and the
packages cover many fixes including an important one that blocks
upgrades from Hammer for OSDs which had their placement group numbers
changed.
http://tracker.ceph.com/issues/16672
This is included in the new 10.2.3 release and I would like to know if
we can get those packages into the storage SIG. I am also offering my
help if needed to do the work required to get it done, as it's pretty
important for us to continue with the upgrades of our Ceph cluster.
Thanks!
Mohammed
Reminder: This Thursday and Friday we will be testing the OpenStack
Newton RC packages for CentOS -
https://www.rdoproject.org/testday/newton/rc/
Please try to find a few hours on Thursday and/or Friday to drop by #rdo
on the Freenode IRC network, and give RDO a spin, to help make this the
best version of RDO OpenStack yet.
--Rich
--
Rich Bowen - rbowen(a)redhat.com
RDO Community Liaison
http://rdoproject.org
@RDOCommunity
While making some sanity checks, I noticed that ... has no vendor entry ...
# curl -s -O "http://mirror.centos.org/centos/6/os/x86_64/Packages/certmonger-0.77.5-2.el…"
# rpm -qpi certmonger-0.77.5-2.el6.x86_64.rpm
Name : certmonger Relocations: (not relocatable)
Version : 0.77.5 Vendor: (none)
Release : 2.el6 Build Date: Mo 09 Mai 2016 17:09:47 CEST
Install Date: (not installed) Build Host: CentOS6-Builder.centos.org
Group : System Environment/Daemons Source RPM: certmonger-0.77.5-2.el6.src.rpm
Size : 2588066 License: GPLv3+
Signature : RSA/SHA1, Do 12 Mai 2016 12:49:49 CEST, Key ID 0946fca2c105b9de
URL : http://certmonger.fedorahosted.org
Summary : Certificate status monitor and PKI enrollment client
Description :
Certmonger is a service which is primarily concerned with getting your
system enrolled with a certificate authority (CA) and keeping it enrolled.
--
LF
Hi everyone,
We've just finished setting up CD to get images shipped into our
public cloud with more automation and noticed that the link pointing
from the unversioned file to the latest release is not properly done
for CentOS 6.
http://cloud.centos.org/centos/6/images/
If you notice, CentOS-6-x86_64-GenericCloud.qcow2 has a date of
2016-07-29 which matches the CentOS-6-x86_64-GenericCloud-1607.qcow2
release. However, there is a newer release which is
CentOS-6-x86_64-GenericCloud-1608.qcow2
It seems this problem does not exist for CentOS 7, but perhaps someone
forgot to point things over when they were done!
Thank you,
Mohammed
Hey all,
yesterday and today I had a few runs to install and extend Origin 1.3 on
CentOS. All seem to work pretty well, I did different permutations of
masters/nodes all based on this inventory file at [1] and using
openshift-ansible master to do the install.
Infrastructure was Vagrant with the latest CentOS box, see [2] for known
issues ;)
//G
[1] https://github.com/goern/my-openshift-origin/blob/centos7/inventory.ini
[2]
https://seven.centos.org/2016/09/updated-centos-vagrant-images-available-v1…
--
Principal Software Engineer - Systems Design & Engineering
Mobile: +49 171 2801345
Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn,
Handelsregister: Amtsgericht München, HRB 153243,
Geschäftsführer: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric
Shander
Hi,
In the Storage SIG we provide different versions of Gluster. The new
upstream release schedule[0] defines two different types of releases:
a. Long Term Maintenance - gets updates for ~12 months
b. Short Term Maintenance - gets updates for ~3 months
The actual time depends a little on how releases are keeping their
schedule (a release every 3 months). There are two Long Term Maintenance
versions active at a time. The Short Term Maintenance releases provide
early access to new features, and are recommended only for early
adopters and users who do not mind upgrading their storage environment
everye 3 months.
This makes for an interesting packaging problem. We would like our users
to be able to install the Gluster packages with a command as simple as
this:
# yum install centos-release-gluster
# yum install glusterfs-server
Users should not need to care (or know) about the actual version they
are installing. Currently Gluster 3.8 is provided by the c-r-gluster38
package, with a "Provides: centos-release-gluster = 3.8".
When I add a new c-r-gluster39 package, with a similar "Provides:", I do
not want users to get the 3.9 version by default. Users should get the
Long Term Maintenance versions, and only opt-in on the Short Term
Maintenance version. But, on the other hand, an installed 3.9 version
should be usable for other SIGs that depend on Gluster (like the Virt
SIG for oVirt).
Currently I am thinking to do the "Provides:" like:
# Users can install centos-release-gluster to get the latest, but we
# do not want to have 3.9 (Short Term Stable) to be selected when
# users do install the virtual centos-release-gluster package.
Provides: centos-release-gluster = 0.3.9
Conflicts: centos-release-gluster < 0.3.9
Obsoletes: centos-release-gluster < 0.3.9
Existing (all Long Term Stable) release packages do not have the 0.
prefix:
# Users can install centos-release-gluster to get the latest
Provides: centos-release-gluster = 3.8
Conflicts: centos-release-gluster < 3.8
Obsoletes: centos-release-gluster < 3.8
We do not want automatic updating/replacing of the release package in
any case (might need manual intervention for major releases). The
current approach works sufficiently well. Except for the potential issue
where other SIGs/projects depend on 'centos-release-gluster >= 3.8'.
This will not work with the 3.9 release package.
I am hoping others can suggest a more elegant solution that addresses
all of these use-cases.
Many thanks!
Niels
0. https://www.gluster.org/community/release-schedule/