The four-week release of CentOS Atomic Host is set to consist of CentOS
core plus a set newer "atomic" packages[1], built for CentOS in the CBS,
with versions tracking what's in Fedora Latest Stable (currently F22, soon
to be F23).
In the downstream rebuild version of CentOS Atomic Host, these "atomic"
packages come from the CentOS Extras repository, built from upstream RHEL
AH code.
## Atomic pkgs in the CBS, today and tomorrow
There are versions of all/most of the "atomic" pkgs in the CBS (in the
atomic7-testing and virt7-common-candidate tags), but which versions, and
when they're updated, and where they live, isn't governed by any set
process. It may make sense to add a new tag specifically for the 4wk
release.
### Here's a rough process proposal:
1. We pay attention to upstream releases of "atomic" packages, and pay
attention to the available versions of those packages in Fedora latest
testing. If the packages in Fedora latest testing are older than the
currently released upstream versions, we ping the Fedora package maintainer
about updating to the latest released version.
2. We help move Fedora packages from testing to stable by testing them and
giving them karma.
3. We take the stable "atomic" packages from Fedora latest and rebuild them
for CentOS 7 in the CBS, using a tag for this purpose. We automate this if,
possible.
4. We feed the repo backing this CAH-4wk tag into our 4wk/devel buildscript
(see https://github.com/CentOS/sig-atomic-buildscripts/tree/devel) build
repo/images, test those images, images/trees that pass tests become our
four-week releases, released, presumably, every four weeks or so. Again,
automating as many steps as possible.
[1] The "atomic" packages are:
docker
kubernetes
etcd
flannel
cloud-init
ostree
atomic
cockpit
Finding the latest stable or testing version of a pkg in Fedora. For docker
(replace pkg name as needed):
https://bodhi.fedoraproject.org/updates/?packages=docker&status=stablehttps://bodhi.fedoraproject.org/updates/?packages=docker&status=testing
Let's discuss this here on the list and at next week's atomic sig meeting.
---
Jason Brooks
Red Hat Open Source and Standards
@jasonbrooks | @redhatopen
http://community.redhat.com
hi,
it would be great to implement jobs in the CI infra that can tag or
reject content in cbs tags based on test output. But in order to do
this, we need to be able to run a koji client in the same place, and
that in turn means koji credentials.
since the ci infra is all public and we dont want to publish the creds
there, thoughts around how we might be able to do this ?
One option might be to host the creds and koji itself on the
jenkins-slave nodes, so its not pushed to the ci test infra itself, and
use the feedback from the test run to make a decision on the slave. This
does ofcourse complicate the jenkins job setup dramatically ( from the
existing simple, grab machine, deploy tests, run tests, report
success/fail ).
Thoughts on other mechanics ? if at all possible ?
Regards,
--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc
hi Karanbir
and thanks for your reply.
I just subscribed to centos-del (after intermittent longtime lurking)
so some introduction may help.
I have been experimenting with glusterfs on Fedora and Debian for a good
while now and decided it was time to try and roll out a 'prod like' setup.
After a fair bit of searching through obsolete webpages and reading
through mailing lists
I found the centos CBS and koji builds:
Whilst I do not _require_ to be running absolute latest build
I do need something recent.
I was hoping to find relatively recent builds to enable a workflow
whereby I produce easily maintainable 3.7+ gluster containers without me
having to follow development, apply patches, compile from source etc.
ATM I only actually require a build later than 3.7.2
to fix bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1222065
> use the user-facing content published to the buildlogs, thats what it
> exists for : http://buildlogs.centos.org/centos/7/storage/
While the old-but-stable 3.6.2 build on buildlogs would be fine for
'prod', I am still at the 'dev' or 'pre-prod' stage and feature
development and bugfix is underway in 3.7 series- as you know.
I would be very happy to be able to test 'candidate' or 'testing' builds.
Initially my testing is in VMs but subsequently I will be testing
installing, updating and maintaining (docker) containers.
So any suggestions for how I can access Centos builds of Gluster 3.7+ ?
Once again,
Thanks In Advance.
:-)
> this image highlights content movement from cbs into various places :
> http://www.karan.org/CBS_ContentPromotion.png
Thanks Karanbir for posting that link to the explanatory diagram
That certainly helped my understanding. :-)
So now I am looking at the published builds, rather than koji links
I find
http://cbs.centos.org/repos/storage7-testing/x86_64/os/repoview/
Which seems to me to contain older stuff built from
storage7-testing
http://cbs.centos.org/koji/taginfo?tagID=9
and
http://cbs.centos.org/repos/storage7-gluster-37-candidate/x86_64/os/repovie…
which I try.
# mkdir storage7-gluster-37-candidate
# cd ~/admin/storage7-gluster-37-candidate/
wget --no-verbose --no-parent --recursive --level=1 --no-directories
http://cbs.centos.org/repos/storage7-gluster-37-candidate/x86_64/os/Package…
[root@vm407 storage7-gluster-37-candidate]# ls -alrt
total 4136
-rw-r--r--. 1 root root 46024 Aug 31 16:39
glusterfs-coreutils-0.0.1-0.1.git0c86f7f.el7.x86_64.rpm
-rw-r--r--. 1 root root 46404 Sep 1 10:14
userspace-rcu-devel-0.7.7-1.el7.x86_64.rpm
-rw-r--r--. 1 root root 68672 Sep 1 10:14
userspace-rcu-0.7.7-1.el7.x86_64.rpm
-rw-r--r--. 1 root root 1353308 Oct 14 22:31
glusterfs-server-3.7.5-1.el7.x86_64.rpm
-rw-r--r--. 1 root root 90732 Oct 14 22:31
glusterfs-extra-xlators-3.7.5-1.el7.x86_64.rpm
-rw-r--r--. 1 root root 772464 Oct 14 22:31
glusterfs-client-xlators-3.7.5-1.el7.x86_64.rpm
-rw-r--r--. 1 root root 177420 Oct 14 22:31
glusterfs-cli-3.7.5-1.el7.x86_64.rpm
-rw-r--r--. 1 root root 79104 Oct 14 22:31
glusterfs-api-3.7.5-1.el7.x86_64.rpm
-rw-r--r--. 1 root root 59008 Oct 14 22:31
glusterfs-rdma-3.7.5-1.el7.x86_64.rpm
-rw-r--r--. 1 root root 128812 Oct 14 22:31
glusterfs-fuse-3.7.5-1.el7.x86_64.rpm
-rw-r--r--. 1 root root 26976 Oct 14 22:31
python-gluster-3.7.5-1.el7.noarch.rpm
-rw-r--r--. 1 root root 470360 Oct 14 22:31 glusterfs-3.7.5-1.el7.x86_64.rpm
-rw-r--r--. 1 root root 37996 Oct 14 22:31
glusterfs-ganesha-3.7.5-1.el7.x86_64.rpm
-rw-r--r--. 1 root root 182764 Oct 14 22:31
glusterfs-geo-replication-3.7.5-1.el7.x86_64.rpm
-rw-r--r--. 1 root root 168972 Oct 14 22:31
glusterfs-devel-3.7.5-1.el7.x86_64.rpm
-rw-r--r--. 1 root root 346892 Oct 14 22:31
glusterfs-libs-3.7.5-1.el7.x86_64.rpm
-rw-r--r--. 1 root root 29444 Oct 14 22:31
glusterfs-resource-agents-3.7.5-1.el7.noarch.rpm
-rw-r--r--. 1 root root 36412 Oct 14 22:31
glusterfs-api-devel-3.7.5-1.el7.x86_64.rpm
-rw-r--r--. 1 root root 5595 Oct 21 13:42 index.html
-rw-r--r--. 1 root root 5595 Oct 21 13:42 index.html?C=N;O=D
-rw-r--r--. 1 root root 5595 Oct 21 13:42 index.html?C=M;O=A
-rw-r--r--. 1 root root 5595 Oct 21 13:42 index.html?C=S;O=A
-rw-r--r--. 1 root root 5595 Oct 21 13:42 index.html?C=D;O=A
drwxr-xr-x. 2 root root 4096 Oct 21 13:43 .
drwxr-xr-x. 6 root root 4096 Oct 21 13:59 ..
[root@vm407 storage7-gluster-37-candidate]#
[root@vm407 admin]# cd ..
[root@vm407 admin]# yum localinstall
./storage7-gluster-37-candidate/*.rpm | tee
yum_localinstall_storage7-gluster-37-candidate
<snip>
Error: Package: glusterfs-ganesha-3.7.5-1.el7.x86_64
(/glusterfs-ganesha-3.7.5-1.el7.x86_64)
Requires: nfs-ganesha-gluster
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
[root@vm407 admin]#
A search for nfs-ganesha-gluster
only brought me to obsolete builds:
nfs-ganesha
http://cbs.centos.org/koji/packageinfo?packageID=98
nfs-ganesha-2.1.0-7.el7 2014-10-01 10:45:45
http://cbs.centos.org/koji/buildinfo?buildID=126
which contains:
nfs-ganesha-2.1.0-7.el7.x86_64.rpm
nfs-ganesha-fsal-gluster-2.1.0-7.el7.x86_64.rpm
nfs-ganesha-debuginfo-2.1.0-7.el7.x86_64.rpm
So it appears that I am stuck at that unresolved dependancy.
Any suggestions will be much appreciated.
Thanks In Advance.
:-)
hi,
Quite a few groups in and around the CentOS Project are getting ready to
announce code, releases, images etc. so I thought it might be good to
get a draft of what a good-announcement looks like, as a template others
might ( or might not ) want to follow.
I've had a very brief crack at it here :
https://wiki.centos.org/SpecialInterestGroup/AnnouncingReleases
Everyone in the SIGs space should be able to edit that page, and
add/extend, please do so.
Or just leave comments and patches here on the list, and I'll merge them
into the page.
regards,
--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc
hi,
Julien Pivotto is going to undertake bootstrapping the ConfigManagement
SIG, and I've setup a wiki page under the SIG space. We can use this
co-ordinate the initial proposal and also as a way to bring together and
document scope + deliverables from people who would be interested in
joining this effort.
config management is a core component of many infra setups around the
world these days, and i am sure we have a fair level of interest within
the existing SIGs as well as the existing contributor base. So everyone
lets get behind Julien and help with this effort.
He is putting together his initial thoughts at :
https://wiki.centos.org/SpecialInterestGroup/ConfigManagementSIG ; we
can use this centos-devel mailing list as a means of communication and
for questions etc.
Regards,
--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc
hi folks,
we've now gotten to a point where we regularly have account requests for
various CentOS resources, to a point where its harder to track things
down constantly.
I'd like to move towards a schedule based admin cycle for the following
resources:
- cbs.centos.org
- ci.centos.org
- devcloud
Ideally, this would run through in a way to have the backlog cleared on
every alternate Monday, for the buildsystem meeting every alternate
Monday to confirm new-users onboarded and followup with any new-user
training we need to run through.
Note that every resource needs some level of support or sponsorship, so
folks requesting accounts should make sure that is in place, before the
next cycle.
ofcourse we would look into emergency and downtime situations as soon as
we are able to.
--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc
Starting a new status thread for CentOS 7 POWER Little Endian. On Monday, Arrfab turned over the keys to a pairf of shiny new Fedora 21 ppc64le VMs running atop PowerKVM. I created a f21-ppc64le mock config and built a Linux from Scratch [1] toolchain with CentOS 7.1.1503 sources. This is necessary to jump back in time from Fedora 21 glibc-2.20 to CentOS 7 glibc-2.17. I then proceeded to build enough ppc64le.el7 rpms with the LFS toolchain to construct a minimal c7.01.01-ppc64le mock buildroot.
As of last night, the minimal c7.01.01-ppc64le buildroot is complete and I’m untangling circular dependencies in the CentOS 7.1.1503 source rpms. I’ve built 700 of 2523 source packages so 27% complete with this first pass.
Next, I’ll bootstrap java-1.7.0-openjdk and continue to loop through ppc64le rpm builds with mock. In the next 1-2 weeks, I should have 95+% of the source packages building for ppc64le. At which point we can create the first CentOS 7 ppc64le VMs and rebuild c7.01.02-ppc64le atop CentOS 7 instead of Fedora 21.
CentOS 7.1.1503 ppc64le Alpha images for the early adopters sometime after that.
[1] http://www.linuxfromscratch.org/lfs/view/stable-systemd/