devel May 2017

devel@lists.centos.org

29 participants
29 discussions

[OpsTools] fluentd packages tagging
by Sandro Bonazzola 26 May '17

26 May '17

Hi, I just discovered we have an issue with the package tagging about fluentd. fluentd-0.12.26-2.el7 <http://cbs.centos.org/koji/buildinfo?buildID=16789> has been tagged opstools7-fluentd-012-testing and opstools7-fluentd-012-release but never got published. The published package is fluentd-0.12.26-1.el7 <http://cbs.centos.org/koji/buildinfo?buildID=11354> because of opstools7-elastic-common-testing and Now, I don't have a clue on how tagging has been mapped to testing and release repo but I think we need to fix it. Initial request was: https://bugs.centos.org/view.php?id=12718 with following mappings: for opstools SIG, could you please collect packages from opstools7-perfmon-common-release opstools7-common-release opstools7-elastic2-release opstools7-sensu-common-release opstools7-sensu-027-release and sync them to https://mirror.centos.org/centos/$releasever/opstools/$basearch/ Right now we have following tags: $ cbs list-tags |grep opstool|grep release opstools7-common-release opstools7-elastic-2-release opstools7-elastic-common-release opstools7-fluentd-012-release opstools7-perfmon-common-release opstools7-sensu-023-release opstools7-sensu-027-release opstools7-sensu-common-release can we review the mappings in order to get fluentd packages correctly published? Personally I would be happy if fluentd and collectd can be in their own repo so they won't require openstack as dependency repo. Thanks, -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

2 1

CentOS PaaS SIG meeting (2017-05-24)
by Troy Dawson 24 May '17

24 May '17

Hello, It's time for our weekly PaaS SIG sync-up meeting Time: 1700 UTC - Wedensdays (date -d "1700 UTC") Date: Today Wedensday, 24 May 2017 Where: IRC- Freenode - #centos-devel Agenda: - OpenShift Current Status -- rpms --- origin-1.5.1 --- openshift-ansible-3.5.71 --- ansible 2.2.3.0 -- Documentation -- Automated rpm building and Automated testing -- Images and Image building -- Multi-arch -- separate repo work -- minishift --- minishift 1.0.1 has been released. - Open Floor -- Finding new head chairman for PAAS SIG

1 1

Problem logging into cbs.centos.org
by Thomas F Herbert 24 May '17

24 May '17

All: I no longer can log in to https://cbs.centos.org/koji/login I get SSL_ERROR_HANDSHAKE_FAILURE_ALERT Did I forget a procedure along the way after generating new keys as instructed by email? accounts.centos.org works fine. --Tom -- *Thomas F Herbert* Fast Data Planes Office of Technology *Red Hat*

2 2

[storage] ceph-ansible tagged for -testing
by Giulio Fidente 23 May '17

23 May '17

Hi, we have tagged for testing ceph-ansible 2.2 in the jewel repo! Its dependencies, including ansible, are cross-tagged. These can be explored at http://cbs.centos.org/koji/builds?order=nvr&tagID=654 If you wanted to deploy Ceph using ceph-ansible, this is the right time to start testing it! :D -- Giulio Fidente GPG KEY: 08D733BA

1 1

CBS Outage : ppc64/ppc64le builders in offline mode
by Fabian Arrotin 23 May '17

23 May '17

Hi As discussed in CBS meeting today (https://www.centos.org/minutes/2017/may/centos-devel.2017-05-22-14.00.html), and also reflected on https://status.centos.org , we currently suffer from a hardware issue that impacts our connectivity to some nodes, including the ppc64/ppc64le builders. That means that SIG people willing to build against/for those arches will not be able to see their build jobs/tasks running as long as connectivity isn't restored (and no ETA yet) Worth noting that those builders are disabled at the koji level (https://cbs.centos.org/koji/hosts?state=all&order=name) We'll keep you informed when those nodes will be reachable again and so enabled for cbs builds Kind Regards, -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab

1 1

Bazel test cases timing out on CentOS 7.
by Atul Sowani 19 May '17

19 May '17

Hi, I have observed that certain Bazel test cases from the test suite are timing out on CentOS 7 (kernel version 3.10.0-123.el7.x86_64). For example, I tried bazel_coverage_test (using command bazel test //src/test/shell/bazel:bazel_coverage_test) and observed that it just hangs. I tried tracing it using strace (log attached). This seems to be CentOS specific behavior as I did not observe this on Ubuntu 16.04. Has anybody observed this? Is this a regression as far as CentOS is concerned? Thanks, Atul.

5 7

Azure Cloud Images
by Akshay Kumar 18 May '17

18 May '17

Hi, We use the Cloud Generic Images from https://cloud.centos.org/centos/7/images/ as a basis for making custom images for AWS, GCP and Azure. It was great to see an Azure image that includes WALinuxAgent but 1703 and 1704 don't work at all. Here's the bug report: https://bugs.centos.org/view.php?id=13264 Thanks, A

2 2

CentOS 7 extras for alternative arches and Koji workflow.
by Thomas Oulevey 18 May '17

18 May '17

Dear All, I'd like to retake a pending issue with -extras on c7 and ask for feedback. I wear two hats : 1/ User, who would like to use altarch-extras packages soon after they are available in c7-extras. 2/ CBS maintainer, who would like to provide his users consistent buildroot across all architecture. Let's start with 1/. The important point here is to be able to rely on altarch-extras and expect it to be in sync with c7-extras in a reasonable time. (days not weeks) As it was always stated c7 (all repositories) cannot and should not be blocked by any alt-arch rebuild and should be independent. However we should at least try to provide these alt-arches packages in a timely manner. A lot of coordination (and motivated contributors) is needed if this effort is not centralized. For 2/ it is very important that we build package with similar buildroots on all arches. As c7-extras is now enabled for everybody, we should be able to have the altarch equivalent in a timely manner. Also all SIGs who are building for all alt-arches will be blocked in case an extras package is needed in the buildroot (we dealt with these issues during 7.2 -> 7.3 cycle and it will come back at next minor release. Additional challenge is the -cr repository which is enabled in CBS by default) However I understand, we need a way not to block official c7 arches for other arches that need fixes. After reviewing the possibilities with different people last year, one way to tackle this issue, would be to have 2 targets in Koji ; 1 including official arches and the other including official arches + alt-arches and allow SIG to bypass alt-arches by changing one target in their config. In this config we could move easily an altarch to an official one and vice versa. Finally, in my opinion, an easy way to have consistent altarch-extras would be to monitor official repository on the mirror.c.o (or buildlogs.c.o) and rebuild automatically extras packages in Koji, which would be picked by a script and so all altarch-extras would be generated directly by Koji itself and the process pretty much automated. The signing process will still be the key to control what is pushed to buildlogs/mirrors. (and close to what we already do) I don't see many disadvantages for this solution but I would like to know if it is possible to move forward and what the community and core contributors think about it. Is altarch-extras important to you ? thank you for your feedback, -- Thomas Oulevey

7 11

Anyone using the serial console from our Vagrant boxes?
by Laurentiu Pancescu 18 May '17

18 May '17

Hi, The default boot parameters of our Vagrant images activate a serial console. The problem is that VirtualBox doesn't enable a serial port by default, and our boxes hang if they really need to use the console, e.g. during relabeling[1] or during the initial configuration required for sealed VM templates (what I'm currently trying for Hyper-V support). Is anyone using the serial console we provide? If not, I can just remove the console=ttyS0 parameter from the kernel command line. Otherwise, a patch for Image Factory is trivial - I can just the set the port to enabled in the XML file, without the cable connected, and probably move console=tty0 on the last position, so it becomes the active console. Libvirt and VMware don't cause this problem, because they either have a serial port by default, or pretend it's there if the guest tries to use it. No idea if Hyper-V or Xen default to having a serial port. I would like to fix this for version 1704, which should be released in the following days. Regards, Laurențiu [1] https://bugs.centos.org/view.php?id=13213

4 6

office hours May 18th
by Karanbir Singh 17 May '17

17 May '17

hi apologies for the short notice, but I am unable to make the office hrs tomorrow. However, if anyone has pending points for the session - please email me and I will aim to reply within a few hrs. regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel May 2017