devel

devel@lists.centos.org

10 participants
4617 discussions

Re: [CentOS-devel] [OpsTools] fluentd packages tagging
by Sandro Bonazzola 29 May '17

29 May '17

On Mon, May 29, 2017 at 12:20 PM, Matthias Runge <mrunge(a)redhat.com> wrote: > On Mon, May 29, 2017 at 10:52:01AM +0200, Sandro Bonazzola wrote: > > On Mon, May 29, 2017 at 10:15 AM, Matthias Runge <mrunge(a)redhat.com> > wrote: > > > > > On Fri, May 26, 2017 at 07:55:32AM -0600, Rich Megginson wrote: > > > > On 05/26/2017 02:59 AM, Sandro Bonazzola wrote: > > > > > Hi, > > > > > I just discovered we have an issue with the package tagging about > > > fluentd. > > > > > fluentd-0.12.26-2.el7 > > > > > > > > $ cbs list-tags |grep opstool|grep release > > > > > opstools7-common-release > > > > > opstools7-elastic-2-release > > > > > opstools7-elastic-common-release > > > > > > > > We should get rid of these elastic tags, or at least ignore them, > and if > > > > there are any packages that we need in those tags, we should add > them to > > > > fluentd-012. > > > > > > > > > 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. > > > > > > Packages tagged and not landing somewhere is unfortunate and should be > > > sorted out. > > > Unfortunately, that is nothing we can do, that is something for > > > CentOS infra folks. > > > > > > > Well, we need to tell CentOS infra folks which tags should be published > and > > where :-) > > So, I can open a ticket for adding the mappings for fluentd-012 tags, > where > > the packages should land? > > > > https://buildlogs.centos.org/centos/7/opstools/$basearch/fluentd/ ? > > guessed above because on mirrors we have: > > http://mirror.centos.org/centos/7/opstools/x86_64/fluentd/ > > on buildlogs, the path is https://buildlogs.centos.org/ > centos/7/opstools/x86_64/logging/ > > There is https://bugs.centos.org/view.php?id=12718 > which also requests to publish packages from > opstools7-fluentd-012-release > to https://mirror.centos.org/centos/$releasever/opstools/$basearch/ > > Maybe I've missed something? > Brian, can you please look again at https://bugs.centos.org/view. php?id=12718 ? As Matthias noted, there was already a request for this publishing. > > Matthias > -- > Matthias Runge <mrunge(a)redhat.com> > -- 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>

1 0

Re: [CentOS-devel] [OpsTools] fluentd packages tagging
by Sandro Bonazzola 29 May '17

29 May '17

On Mon, May 29, 2017 at 10:15 AM, Matthias Runge <mrunge(a)redhat.com> wrote: > On Fri, May 26, 2017 at 07:55:32AM -0600, Rich Megginson wrote: > > On 05/26/2017 02:59 AM, Sandro Bonazzola wrote: > > > Hi, > > > I just discovered we have an issue with the package tagging about > fluentd. > > > fluentd-0.12.26-2.el7 > > > > $ cbs list-tags |grep opstool|grep release > > > opstools7-common-release > > > opstools7-elastic-2-release > > > opstools7-elastic-common-release > > > > We should get rid of these elastic tags, or at least ignore them, and if > > there are any packages that we need in those tags, we should add them to > > fluentd-012. > > > > > 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. > > Packages tagged and not landing somewhere is unfortunate and should be > sorted out. > Unfortunately, that is nothing we can do, that is something for > CentOS infra folks. > Well, we need to tell CentOS infra folks which tags should be published and where :-) So, I can open a ticket for adding the mappings for fluentd-012 tags, where the packages should land? https://buildlogs.centos.org/centos/7/opstools/$basearch/fluentd/ ? guessed above because on mirrors we have: http://mirror.centos.org/centos/7/opstools/x86_64/fluentd/ > > I'm fine with getting rid of opstools7-elastic-* tags, we don't use them > anymore and afaik, we won't do in the future. > Ok, so if nobody objecting, I'll open a ticket tomorrow morning for removing those tags from cbs. > > A while ago, we moved the packages relying on openstack packages to the > cloud sig, and cremoved the dependency of openstack from opstools. > Unfortunately, the resulting centos-release-opstools build[1] > was not tagged and pushed correctly. > > [1] http://cbs.centos.org/koji/buildinfo?buildID=16800 now tagged correctly, not yet in http://mirror.centos.org/centos/7/extras/x86_64/Packages/ but should be just a matter of sign and publish which should hopefully happen soon. > > -- > Matthias Runge <mrunge(a)matthias-runge.de> > -- 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>

1 0

[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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel