Hi,
I thought I'd start an article on my personal blog on the various options
for newer PHP (in particular), python, ruby etc options in CentOS -
particularly given some of the base packages in EL6 have now passed EOL
upstream and consequently some applications (eg OwnCloud) now have minimal
dependencies greater than in base.
What I found on initial looks to SCL was at best confusing and in areas
outright misleading, with help needed from Dominic in #centos-devel to work
through the present SCL situation.
Doing a general Google search (or the @scl keyword in #centos) will take
someone to here:
https://wiki.centos.org/AdditionalResources/Repositories/SCL
This refers to an old centos-release-SCL package which is still in the
repos and would direct the user to unmaintained old versions.
The correct package is actually centos-release-scl ... yes just the case
needs to change.
The documentation for centos-release-scl stuff (ie the CentOS SCL SIG
stuff) is pretty much nonexistent for a user needing a newer version of a
package. These pages are very CentOS developer focused and not really
useful for the end user:
https://wiki.centos.org/SpecialInterestGroup/SCLohttps://wiki.centos.org/SpecialInterestGroup/SCLo/CollectionsList
Then once the right package is installed the user can see there is php54,
php55 and rh-php56 packages but it's not clear why the difference in the
naming and there's nothing that highlights to someone that if they want to
use php55 or rh-php56 they'll need to handle a migration to rh-httpd24 as
well.
I'd suggest the first step is to have centos-release-scl obsolete
centos-release-SCL so that users are not left on an unmaintained repository.
Then as I gather data for my article I'd really like to flesh out and
improve the 'user facing' SCL wiki page.
Thoughts on this?
James
Due to some reorganization at the DC/Cage level, we'll have to
shutdown/move/reconfigure a big part of our hosted infra for the
following services :
- cbs.centos.org (Koji)
- accounts.centos.org (auth backend)
- ci.centos.org (jenkins-driven CI environment)
We're working on a plan to minimize the downtime/reconfiguration part,
but at first sight, due to the hardware move of the racks/recabling
parts/etc, the announced downtime will be probably ~48h.
What does that mean ? That during this window, nobody will be able to
build/tests packages, nor be able to triggers automatically CI jobs
(important).
As said, we're working on an agenda with the team operating the DC, but
we'd like you (cbs and ci users) to give us feedback on the best (or
worst ?) time line for such migration.
For example if you know that your $project will have a release soon, and
already have an agenda for such release (and so build/ci) and that you
rely on that infra, we'd like you to communicate those informations to
us, so that we can try to find the best possible time slot for the
migration, minimizing the impact on the whole CentOS ecosystem (and so
for all our users)
Feel free to answer in this thread, or find us in #centos-devel on freenode.
--
Fabian Arrotin
The CentOS Project | http://www.centos.org
gpg key: 56BEC54E | twitter: @arrfab
There are test images available for what will be the next CentOS
Atomic Host release:
https://ci.centos.org/artifacts/sig-atomic/downstream/images/
After we've done some testing, we'll update the official CentOS Atomic
Host ostree repo, probably early next week, and announce the release.
We're going to hold off on producing new release images for a week or
so, in order to sync up with the regular monthly centos media refresh
cycle.
These test images include two versions of docker: docker-1.9.1-40 and
docker-latest-1.10.3-22.1. To read more about docker vs.
docker-latest, see:
https://lists.centos.org/pipermail/centos-devel/2016-May/014731.html.
For your non-atomic needs, these docker pkgs, along with the other
content included in these images, are now available in the standard
centos repositories -- docker, kubernetes and most of the other
"atomic" pkgs live in the extras repo.
Happy testing,
Jason
On Mon, May 16, 2016 at 3:30 PM, Rich Megginson <rmeggins(a)redhat.com> wrote:
> On 05/13/2016 01:12 AM, Matthias Runge wrote:
>
>> Hello,
>>
>> I would like to re-iterate my interest in having a SIG in CentOS
>> to provide all kinds of tools for operators providing
>> infrastructure by using CentOS.
>>
>
> +1
>
>
>> The scope should be more than just simply packaging applications.
>> Another part should be to provide puppet manifests or ansible playbooks
>> to get things quicker up and running.
>>
>
> +1 - should ideally provide a standalone installer, and puppet
> manifests/ansible playbooks that can be included in other projects (puppet
> manifests for RDO TripleO, ansible playbooks for openshift-ansible, etc.)
>
>
>> Ideally, I would start with providing something like
>> * elsasticsearch/fluentd/kibana for centralised logging
>>
>
> +1
>
> * collectd/graphite/grafana for performance monitoring
>> * sensu/uchiwa for availability monitoring
>>
>
+1
>
>> We have already seen around 10 persons interested in helping, testing,
>> trying out and providing feedback.
>>
>> For communcations etc. I would propose to start small, and to share
>> already existent CentOS channels (email-lists, irc-channel).
>>
>
> Emails should use the [opstools] prefix?
>
> This
>> decision should be revisited, once amount of SIG related communication
>> becomes annoying in general channels.
>>
>> Questions? Thoughts? Additions?
>>
>> Best,
>> Matthias
>>
>
>
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel(a)centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
>
I'm in!
Regards,
Martin
--
Martin Mágr
Senior Software Engineer
Red Hat Czech
Hi,
Gluster 3.8 is planned to be released in a few weeks, and we're
preparing for provinding the packages through the Storage SIG. For
Gluster 3.6 amd 3.7 we already have centos-release-gluster36 and
*-gluster37 packages in CentOS Extras. These packages only provide the
.repo files so that users can easily install the packages from the SIG.
The SIGGuide in the wiki [1] mentions the steps to do when adding a new
package to the tags/buildroot of the SIG managed build environment.
Could you add the process to request centos-release-* packages to get
included in CentOS Extras?
Thanks,
Niels
1. https://wiki.centos.org/SIGGuide/Content/Build#Newpkgs
Hello all,
I'm seeing this behaviour since I did `yum update` today on one of my
CentOS 7 boxes in that, `vagrant up` for libvirt provider throws the error:
"The provider 'libvirt' could not be found, but was requested to
back the machine 'default'. Please use a provider that exists."
Details of the issue can be found on [1]. I observed the issue when I
was doing testing for Atomic Developer Bundle (ADB) [2].
Besides that, earlier, one needed to install only two packages -
centos-release-scl and sclo-vagrant1 - to use Vagrant. But now it seems
to have changed and we need to install sclo-vagrant1-vagrant-libvirt as
well as few other packages/dependencies to make it work. I modified my
Ansible playbook [3] which reflects the set of packages I had to add.
What I'm here to understand is that, am I doing something obviously
wrong here to make things work or, did I miss some notification on this
list that had details about the changes? Or is this some kind of
unexpected behaviour?
Thanks!
[1]
https://github.com/projectatomic/adb-atomic-developer-bundle/issues/383#iss…
[2] https://github.com/projectatomic/adb-atomic-developer-bundle
[3]
https://github.com/dharmit/adb-ci-ansible/commit/1da0cbc6961c8161981a15b9d2…
Regards,
Dharmit.
Hi,
there is an integration in place with Gluster, NFS-Ganesha and
Pacemaker. This combination makes it possible to have an active-active
high-available NFS-server backed by Gluster volumes.
We'd like to add automated testing for functional fail-over in the CI.
This requires the use of virtual-IPs that get assigned to the different
NFS-Ganesha servers, which will migrate to other servers upon failure.
On https://wiki.centos.org/QaWiki/PubHardware is a mentioning of
"reserved IP addresses" where the Gluster project in the CI would like
to get listed too. What is the process to request a few IPs, and what
are the restrictions we need to be aware of (and how to put them in the
Jenkins job)?
Thanks,
Niels