devel July 2016

devel@lists.centos.org

36 participants
39 discussions

Incorrect default governor on CentOS ppc64el builds
by Adi Gangidi 14 Jul '16

14 Jul '16

Hello nice people on CentOS list, ?Default governor on CentOS 7 ppc64le OS bootup is "conservative" . This has about 20% effect on benchmark numbers, if you don't change the governor to ondemand manually (for specific benchmarks). I tested this on our barreleye power 8 server. This even though kernel config is set for "ondemand" as default governor: [root@Barreleye-1 ~]# cat /boot/config-3.10.0-327.el7.ppc64le | grep -i ondemand CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_ONDEMAND=y I filed a bug on this with details and am posting here for info and also to accelerate some response on the bug: https://bugs.centos.org/view.php?id=11094 Best Adi Gangidi Rackspace

1 0

CentOS PaaS SIG meeting (2016-07-13)
by Troy Dawson 13 Jul '16

13 Jul '16

Hello, It's time for our weekly PaaS SIG sync-up meeting Time: 1700 UTC - Wedensdays Date: Today Wedensday, 13 July 2016 Where: IRC- Freenode - #centos-devel Agenda: - OpenShift Current Status -- rpms -- Automated testing --- linch-pin -- Documentation -- images / image building - Open Floor Minutes from last meeting: https://www.centos.org/minutes/2016/july/centos-devel.2016-07-06-16.59.log.…

3 2

network issues to cbs / ci and related services
by Karanbir Singh 13 Jul '16

13 Jul '16

hi guys, As of 3:00 am UTC today 13th July 2016, we've been having networking issues into the facility that hosts : - cbs.centos.org - ci.centos.org and their related services. We've been told that the facilities folks are working on it, but have no ETA. The main symptom is high packet loss. Till this gets rectified, we are going to see timeout's on some of the services and resources hosted from there. If you have any specific concerns, you can find us on #centos-devel on irc.freenode.net Regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

1 0

Re: [CentOS-devel] ConfigMGMT SIG Status
by Ben Hosmer 12 Jul '16

12 Jul '16

Thanks for the bump on this. I'll be happy to represent SALT and submit the bug, however I'm slightly confused on the tagging convention. Would something like configmanagement7-salt-2016.3 be an acceptable tag? I've confirmed my access to CBS: [bhosmer@xur ~]$ cbs moshimoshi zdravstvuite, bhosmer! You are using the hub at https://cbs.centos.org/kojihub/ Authenticated via client certificate /home/bhosmer/.centos.cert

1 0

Interest in a SIG for logging and monitoring?
by Steve Huston 12 Jul '16

12 Jul '16

Apologies for not being able to use a proper reply, since I only just joined the list today; came here to say that I too would be interested in such a SIG. -- Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci Princeton University | ICBM Address: 40.346344 -74.652242 345 Lewis Library |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1'

6 6

AltArch on buildlogs.centos.org
by Karanbir Singh 11 Jul '16

11 Jul '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Last week I finished the work to get altarch content pushed via cbs.centos.org to buildlogs as a first step towards wider release options opening up. Today the scripts are in production and I've incldued the list below to indicate content currently in that push queue. It should be publicly visible in a few minutes time. What this means is that for any tag, where the SIG has requested push - - we can now support aarch64, ppc64, ppc64le, armhfp and i386 content built, tested and delivered via the public community services ( cbs.centos.org / ci.centos.org / buildlogs.centos.org ) and then signed released via whatever delivery mechanism is already in place ( isos, disk media, cloud images, containers, livemedia, rpm repos, vagrant boxs etc ). There are still a few considerations to work through on the build side however. There is no clear path within our existing buildsystem ( koji ) to work with similar content, only different by the intendant target architecture and how the relationships work between build's and status'. Thomas, Brian and I spent an evening last week working through some of these options, and I believe Thomas is going to re-iterate the options in the coming days and we'll need to work through those and arrive at whatever makes most sense in the immediate future - and work on a bigger/better plan longer term. What I do recommend is going through the previous threads on this subject on the centos-devel list ( and there have been a few ), so as to update yourself on the concerns ( they remain largely unchanged, just a lot more thought and understanding now exists for some of them, atleast from my side ). Regards, - -------- Forwarded Message -------- Subject: AltArch Buildlogs Push Date: Mon, 11 Jul 2016 12:13:08 +0000 N: 7/cloud/x86_64/openstack-liberty/common/ openstack-utils-2016.1-1.el7.noarch.rpm N: 7/cloud/x86_64/openstack-kilo/common/ openstack-utils-2016.1-1.el7.noarch.rpm N: 7/cloud/x86_64/openstack-mitaka/common/ openstack-utils-2016.1-1.el7.noarch.rpm N: 7/cloud/x86_64/openstack-newton/common/ openstack-utils-2016.1-1.el7.noarch.rpm N: 7/storage/aarch64/gluster-3.7/ glusterfs-3.7.13-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.7/ glusterfs-api-3.7.13-1.el7.aarch64.rp m N: 7/storage/aarch64/gluster-3.7/ glusterfs-api-devel-3.7.13-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.7/ glusterfs-cli-3.7.13-1.el7.aarch64.rp m N: 7/storage/aarch64/gluster-3.7/ glusterfs-client-xlators-3.7.13-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.7/ glusterfs-devel-3.7.13-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.7/ glusterfs-extra-xlators-3.7.13-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.7/ glusterfs-fuse-3.7.13-1.el7.aarch64.r pm N: 7/storage/aarch64/gluster-3.7/ glusterfs-ganesha-3.7.13-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.7/ glusterfs-geo-replication-3.7.13-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.7/ glusterfs-libs-3.7.13-1.el7.aarch64.r pm N: 7/storage/aarch64/gluster-3.7/ glusterfs-rdma-3.7.13-1.el7.aarch64.r pm N: 7/storage/aarch64/gluster-3.7/ glusterfs-resource-agents-3.7.13-1.el7.noarch.rpm N: 7/storage/aarch64/gluster-3.7/ glusterfs-server-3.7.13-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.7/ nfs-ganesha-2.3.2-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.7/ nfs-ganesha-gluster-2.3.2-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.7/ nfs-ganesha-mount-9P-2.3.2-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.7/ nfs-ganesha-nullfs-2.3.2-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.7/ nfs-ganesha-proxy-2.3.2-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.7/ nfs-ganesha-vfs-2.3.2-1.el7.aarch64.r pm N: 7/storage/aarch64/gluster-3.7/ nfs-ganesha-xfs-2.3.2-1.el7.aarch64.r pm N: 7/storage/aarch64/gluster-3.7/ python-gluster-3.7.13-1.el7.noarch.rp m N: 7/storage/aarch64/gluster-3.7/ userspace-rcu-0.7.16-2.el7.aarch64.rp m N: 7/storage/aarch64/gluster-3.7/ userspace-rcu-devel-0.7.16-2.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.6/ glusterfs-resource-agents-3.6.9-1.el7.noarch.rpm N: 7/storage/aarch64/gluster-3.8/ glusterfs-3.8.1-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.8/ glusterfs-api-3.8.1-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.8/ glusterfs-api-devel-3.8.1-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.8/ glusterfs-cli-3.8.1-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.8/ glusterfs-client-xlators-3.8.1-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.8/ glusterfs-coreutils-0.0.1-0.1.git259f269.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.8/ glusterfs-devel-3.8.1-1.el7.aarch64.r pm N: 7/storage/aarch64/gluster-3.8/ glusterfs-extra-xlators-3.8.1-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.8/ glusterfs-fuse-3.8.1-1.el7.aarch64.rp m N: 7/storage/aarch64/gluster-3.8/ glusterfs-ganesha-3.8.1-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.8/ glusterfs-geo-replication-3.8.1-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.8/ glusterfs-libs-3.8.1-1.el7.aarch64.rp m N: 7/storage/aarch64/gluster-3.8/ glusterfs-rdma-3.8.1-1.el7.aarch64.rp m N: 7/storage/aarch64/gluster-3.8/ glusterfs-resource-agents-3.8.1-1.el7.noarch.rpm N: 7/storage/aarch64/gluster-3.8/ glusterfs-server-3.8.1-1.el7.aarch64.rpm N: 7/storage/aarch64/gluster-3.8/ python-gluster-3.8.1-1.el7.noarch.rpm N: 7/storage/aarch64/gluster-3.8/ userspace-rcu-0.7.16-1.el7.aarch64.rp m N: 7/storage/aarch64/gluster-3.8/ userspace-rcu-devel-0.7.16-1.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ babeltrace-1.2.4-3.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ ceph-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ ceph-base-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ ceph-common-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ ceph-devel-compat-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ cephfs-java-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ ceph-fuse-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ ceph-libs-compat-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ ceph-mds-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ ceph-mon-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ ceph-osd-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ ceph-radosgw-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ ceph-selinux-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ ceph-test-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ fcgi-2.4.0-25.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ fcgi-devel-2.4.0-25.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ leveldb-1.12.0-5.el7.1.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ leveldb-devel-1.12.0-5.el7.1.aarch64.r pm N: 7/storage/aarch64/ceph-jewel/ libbabeltrace-1.2.4-3.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ libbabeltrace-devel-1.2.4-3.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ libcephfs1-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ libcephfs1-devel-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ libcephfs_jni1-10.2.2-0.el7.aarch64.rp m N: 7/storage/aarch64/ceph-jewel/ libcephfs_jni1-devel-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ librados2-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ librados2-devel-10.2.2-0.el7.aarch64.r pm N: 7/storage/aarch64/ceph-jewel/ libradosstriper1-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ libradosstriper1-devel-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ librbd1-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ librbd1-devel-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ librgw2-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ librgw2-devel-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ libunwind-1.1-10.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ libunwind-devel-1.1-10.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ lttng-ust-2.4.1-1.el7.1.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ lttng-ust-devel-2.4.1-1.el7.1.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ python-ceph-compat-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ python-cephfs-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ python-mock-1.0.1-7.1.el7.noarch.rpm N: 7/storage/aarch64/ceph-jewel/ python-rados-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ python-rbd-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ python-tox-1.4.2-8.el7.noarch.rpm N: 7/storage/aarch64/ceph-jewel/ rbd-fuse-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ rbd-mirror-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ rbd-nbd-10.2.2-0.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ userspace-rcu-0.7.16-1.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ userspace-rcu-devel-0.7.16-1.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ xmlstarlet-1.6.1-1.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ yasm-1.2.0-4.el7.aarch64.rpm N: 7/storage/aarch64/ceph-jewel/ yasm-devel-1.2.0-4.el7.aarch64.rpm N: 7/paas/aarch64/openshift-future/ ansible-2.1.0.0-1.el7.noarch.rpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJXg4/bAAoJEI3Oi2Mx7xbtCjkIANHy6FKFtWWCocNJZD1WA1Ap WJsX4Un1dvLSv/Sa/f7JXt/0bA6wnueMzY2uZZyAjxrpup4UN8sjNW0D/3QrDf9o 8o3+YQz7hp/Wy/CoYXTQSXvjR6Iflzsx9FX/CqHpqUbHB2LaHi9fKG+d2ZsOaFiS SCe809NnCxbM1RMoLMdFvsC1GO8SfZlEb3P9JMCVaPzJqj+zhkSodvHIHIvO6Z8z m7kgktznRo29FkUYHl/nnU1t4v2+xYxNhTqFTEe90jlIOordrePsdHlZzaWb/3JW kwqLnYQs1k7OphUno2lqd9lNfN0uCZ1PAKOUoQuuavGp9drfIhu44LMg/4kep90= =/QJh -----END PGP SIGNATURE-----

2 1

Feedback needed: ideas for the Vagrant images
by Laurentiu Pancescu 11 Jul '16

11 Jul '16

Hi there, I would appreciate some feedback on a few ideas for our Vagrant images. Our CentOS images for Vagrant are currently not setup according to the upstream recommendations for base boxes, and I'd like to change that. [1] Here's the list of necessary modifications: I. root password should be 'vagrant': already filed by Lalatendu Mohanty as issue #30 on GitHub [2]. I should mention that Karanbir Singh has some reservations related to security. However, the box already has passwordless sudo, and changing the root password is just a "sudo passwd" away (I tried, it warns about a bad password, but it accepts it). Although public key auth is enabled, password-based authentication isn't disabled, and sshd will happily let anyone log in to any public box as vagrant:vagrant. We should probably only allow local password logins (on the console), for both root and vagrant; not sure if the best way to enforce this is sshd_config or PAM. II. use /vagrant as the sync directory: we currently use /home/vagrant/sync, this change is already planned for the release following 1606 III. "UseDNS no" in sshd_config: this would make connections via ssh faster Additional ideas for optimization: IV. disable requiretty in /etc/sudoers: this allows users to enable the pipelining feature of the Ansible provisioner, which significantly increases its speed (it's about 2 times faster in my tests). [3] V. set GRUB_TIMEOUT to 1 or 0: this reduces or eliminates the waiting time before the default kernel is booted (the VM runs generally without a display, so it makes no sense to wait there) Best regards, Laurențiu [1] https://www.vagrantup.com/docs/boxes/base.html [2] https://github.com/CentOS/sig-cloud-instance-build/issues/30 [3] https://docs.ansible.com/ansible/intro_configuration.html#pipelining

5 7

Rebuilding RDO for ppc64le
by Xiandong Meng 11 Jul '16

11 Jul '16

In RDO Austin BOF meeting, I have proposed to rebuild RDO packages for ppc64le. And a few discussions have been carried over since then. Now with the power builders up and running on cbs (http://cbs.centos.org/koji/hosts) I'd like to write to the mailinglist for more broad discussing. The goal is to rebuild RDO packages for ppc64le in CBS. And we will start with Mitaka release as it is a recent stable release. And one of the idea was to 1. create a new tag (cloud7-openstack-mitaka-candidate-ppc64le?) 2. import all 'noarch' builds from cloud7-openstack-mitaka-* tags 3. send all required packages to the builder 4. test resulting packages for installation & function validation (via ci pipeline?) 5. import/merge all of them to propose cloud7-openstack-* tag I think we need to proceed with this work without touching x86 tags until it is ready for merge. I have experience building the packages with local mock build environment, but i may need help to initiate that build work in CBS. Any comments/suggestions are welcome. Regards, Alex Meng <mengxiandong(a)gmail.com> mengxiandong(a)gmail.com

3 2

[cockpit] Broken dependencies in CentOS Extras
by Haïkel 08 Jul '16

08 Jul '16

Hi, while running repoclosure on Cloud SIG repositories, I found out that cockpit had missing dependencies. <snip> Last metadata expiration check: 0:00:02 ago on Wed Jul 6 19:53:59 2016. package: cockpit-ostree-0.108-1.el7.centos.x86_64 from centos-extras unresolved deps: rpm-ostree-client >= 2015.11-1 /usr/libexec/rpm-ostreed package: cockpit-selinux-0.108-1.el7.centos.noarch from centos-extras unresolved deps: setroubleshoot-server >= 3.3.3 </snip> Could be fine, but it's best to check with you guys. Regards, H.

4 3

Re: [CentOS-devel] [rdo-list] [Arm-dev] next steps for altarch with ceph and openstack
by Jim Perrin 08 Jul '16

08 Jul '16

On 07/08/2016 03:35 AM, Alan Pevec wrote: > On Fri, Jul 8, 2016 at 4:00 AM, Haïkel <hguemar(a)fedoraproject.org> wrote: >> 2016-07-07 17:41 GMT+02:00 Jim Perrin <jperrin(a)centos.org>: > ... >>> I might suggest that for now (until we get the mirror bits sorted), we >>> create a centos-release-mitaka-altarch package. This would avoid needing >>> to mess with the existing x86_64 bits. once everything is aligned, then >>> we can obsolete/provides the replacement and use the standard package >>> across all architectures. >> >> Works for me. > > I didn't understand why we need separate release -altarch package. I > understand we do need separate CBS tags but they could be still mapped > into the same per-arch locations under > http://buildlogs.centos.org/centos/7/cloud/ and > http://mirror.centos.org/centos/7/cloud/ so that current OpenStack > CloudSIG .repo [1] which uses $basearch will work. Mappings for > testing repo request (e.g. for RDO Newton [2]) would be: > The problem here is that the aarch64 builds are currently at mirror.centos.org/altarch/ not at /centos/, so either way we'll end up with split repositories for the architecture. I'm only suggesting a second package as a short term solution until we come up with a better way to manage this. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel July 2016