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/
On 11/10/15 03:21, Subhendu Ghosh wrote:
> It would also be useful if the repo definitions did not use
> ReleaseVersion to allow use by CentOS and other distroa.
let me see if we can parametrise those from the jenkins side of things -
should be possible, and we can default to something that works here for
the scl/cbs process.
regards,
>
> Sent from Nine <http://www.9folders.com/>
>
> *From:* Karanbir Singh <mail-lists(a)karan.org>
> *Sent:* Oct 10, 2015 6:29 PM
> *To:* centos-devel(a)centos.org; sclorg(a)redhat.com
> *Subject:* [scl.org] validating scls being built
>
> firstly, apologies for the cross post.
>
> I've setup an example to illustrate some very simple things we can do to
> validate a collection. In this case the vagrant collection.
>
> https://github.com/kbsingh/validate-vagrant-scl has the test script.
>
> It does 2 things:
> 1) makes sure all the rpms we expect to have in the repo are there.
> 2) it will install the collection, run a centos/7 vagrant box, and run
> the centos functional test suite inside the box. if this passes, we can
> assert that vagrant installed ok, was able to run a libvirt backed box
> properly, and was able to provide typical expected functionality.
>
> There maybe 100s more features of the collection we are not testing
> here, but that might not be needed if a simple baseline is established.
> And this test can be run, from triggers in ci.centos.org, watching the 3
> repos we care about for the vagrant collection ( ruby22 / ror41 and
> vagrant itself ).
>
> thoughts ?
>
>
> --
> Karanbir Singh
> +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
> GnuPG Key : http://www.karan.org/publickey.asc
>
> _______________________________________________
> SCLorg mailing list
> SCLorg(a)redhat.com
> https://www.redhat.com/mailman/listinfo/sclorg
>
--
Karanbir Singh, Project Lead, The CentOS Project
+44-207-0999389 | http://www.centos.org/ | twitter.com/CentOS
GnuPG Key : http://www.karan.org/publickey.asc
firstly, apologies for the cross post.
I've setup an example to illustrate some very simple things we can do to
validate a collection. In this case the vagrant collection.
https://github.com/kbsingh/validate-vagrant-scl has the test script.
It does 2 things:
1) makes sure all the rpms we expect to have in the repo are there.
2) it will install the collection, run a centos/7 vagrant box, and run
the centos functional test suite inside the box. if this passes, we can
assert that vagrant installed ok, was able to run a libvirt backed box
properly, and was able to provide typical expected functionality.
There maybe 100s more features of the collection we are not testing
here, but that might not be needed if a simple baseline is established.
And this test can be run, from triggers in ci.centos.org, watching the 3
repos we care about for the vagrant collection ( ruby22 / ror41 and
vagrant itself ).
thoughts ?
--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc
Hi,
Asapart of Project Atomic [1], we are working ona toolchain (as of now
it is a Vagrant box),atomic-developer-bundle [2],for helping application
developers package their microservice architecture applications for
delivery vialinux containers.ADB (atomic developer bundle) is supported
on GNU/Linux distributions, OSX and WIndows. It has (or isgoing to have)
all the goodies that are part of Project Atomic to better enableLinux
containers.
Currently, the Vagrant box is based on CentOS. Therefore I think itmakes
more sense toinclude it in the CentOS Atomic SIG. I believe this
willopen channels with thecommunity and lead togreater participation.
Let me know your thoughtson including the ADB as part of the Atomic SIG.
For details please go through the README in ADB github repo [2]
[1] https://github.com/projectatomic
[2] https://github.com/projectatomic/adb-atomic-developer-bundle
Thanks,
Lala
On behalf of ADB developers