devel

devel@lists.centos.org

3 participants
4682 discussions

Atomic SIG Chair Change
by Joe Brockmeier 12 Feb '16

12 Feb '16

Hey all, Discussed at a meeting a few weeks ago, but I failed to send email on this. (And hence another good reason for the change...) Jason Brooks has been heavily active in keeping the rebuilds going and generally moving things forward. I proposed that he take over as chair, and he didn't run screaming - nor did anyone else object. So, I'd like this to be officially official, officially. Lazy consensus rules, so unless there's a -1 from one of the members of the SIG, this should be effective in 72 hours. Apologies again for tardiness in sending this email. Best, jzb -- Joe Brockmeier | Community Team, OSAS jzb(a)redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/

2 1

official centos-7 docker image are wrong
by Farkas Levente 12 Feb '16

12 Feb '16

hi, according to this bug https://bugzilla.redhat.com/show_bug.cgi?id=1142311 rh silently replace iputils with the same version with a fixed capabilities. unfortunately official base centos-7 (ie. latest 7.2) docker images are build with the wrong version, so these images should have to be rebuild with the proper version. currently in the official centos7 docker images: ------------------------------------- # rpm -qi iputils Name : iputils Version : 20121221 Release : 7.el7 Architecture: x86_64 Install Date: Wed 23 Dec 2015 06:09:24 PM UTC Group : System Environment/Daemons Size : 368577 License : BSD and GPLv2+ Signature : RSA/SHA256, Wed 25 Nov 2015 02:43:41 PM UTC, Key ID 24c6a8a7f4a80eb5 Source RPM : iputils-20121221-7.el7.src.rpm Build Date : Fri 20 Nov 2015 07:12:19 PM UTC Build Host : worker1.bsys.centos.org Relocations : (not relocatable) Packager : CentOS BuildSystem <http://bugs.centos.org> Vendor : CentOS URL : http://www.skbuff.net/iputils Summary : Network monitoring tools including ping Description : The iputils package contains basic utilities for monitoring a network, including ping. The ping command sends a series of ICMP protocol ECHO_REQUEST packets to a specified network host to discover whether the target machine is alive and receiving network traffic. ------------------------------------- while in the centos repo: ------------------------------------- # rpm -qi iputils Name : iputils Version : 20121221 Release : 7.el7 Architecture: x86_64 Install Date: Tue 15 Dec 2015 03:15:22 PM CET Group : System Environment/Daemons Size : 368577 License : BSD and GPLv2+ Signature : RSA/SHA256, Wed 25 Nov 2015 03:43:41 PM CET, Key ID 24c6a8a7f4a80eb5 Source RPM : iputils-20121221-7.el7.src.rpm Build Date : Fri 20 Nov 2015 08:12:19 PM CET Build Host : worker1.bsys.centos.org Relocations : (not relocatable) Packager : CentOS BuildSystem <http://bugs.centos.org> Vendor : CentOS URL : http://www.skbuff.net/iputils Summary : Network monitoring tools including ping Description : The iputils package contains basic utilities for monitoring a network, including ping. The ping command sends a series of ICMP protocol ECHO_REQUEST packets to a specified network host to discover whether the target machine is alive and receiving network traffic. ------------------------------------- imho it's a bug! without it ping not working from any docker container based on centos7. -- Levente "Si vis pacem para bellum!"

3 8

New CentOS Atomic Host Available
by Jason Brooks 12 Feb '16

12 Feb '16

An updated version of CentOS Atomic Host (version 7.20160203) is now available for download. CentOS Atomic Host is a lean operating system designed to run Docker containers, built from standard CentOS 7 RPMs, and tracking the component versions included in Red Hat Enterprise Linux Atomic Host 7.2. CentOS Atomic Host is available as a VirtualBox or libvirt-formatted Vagrant box, or as an installable ISO, qcow2 or Amazon Machine image. These images are available for download at cloud.centos.org(http://cloud.centos.org/centos/7/atomic/images/). The backing ostree repo is published to mirror.centos.org(http://mirror.centos.org/centos/7/atomic/x86_64/repo). CentOS Atomic Host includes these core component versions: * kernel-3.10.0-327.4.5.el7.x86_64 * cloud-init-0.7.5-10.el7.centos.1.x86_64 * atomic-1.6-6.gitca1e384.el7.x86_64 * kubernetes-1.0.3-0.2.gitb9a88a7.el7.x86_64 * etcd-2.1.1-2.el7.x86_64 * ostree-2015.9-2.atomic.el7.x86_64 * docker-1.8.2-10.el7.centos.x86_64 * flannel-0.5.3-8.el7.x86_64 ## Upgrading If you're running a previous version of CentOS Atomic Host, you can upgrade to the current image by running the following command: $ sudo atomic host upgrade ## Images ### Vagrant CentOS-Atomic-Host-7-Vagrant-Libvirt.box (http://cloud.centos.org/centos/7/atomic/images/CentOS-Atomic-Host-7-Vagrant -Libvirt.box) (416 MB) and CentOS-Atomic-Host-7-Vagrant-Virtualbox.box (http://cloud.centos.org/centos/7/atomic/images/CentOS-Atomic-Host-7-Vagrant -Virtualbox.box) (428 MB) are Vagrant boxes for Libvirt and Virtualbox providers. The easiest way to consume these images is via the Atlas / Vagrant Cloud setup (see https://atlas.hashicorp.com/centos/boxes/atomic-host) For example, getting the VirtualBox instance up would involve running the following two commands on a machine with vagrant installed: $ vagrant init centos/atomic-host && vagrant up --provider virtualbox ### ISO The installer ISO (http://cloud.centos.org/centos/7/atomic/images/CentOS-Atomic-Host-7-Install er.iso) (737 MB) can be used via regular install methods (PXE, CD, USB image, etc.) and uses the Anaconda installer to deliver the CentOS Atomic Host. This allows flexibility to control the install using kickstarts and define custom storage, networking and user accounts. This is the recommended process for getting CentOS Atomic Host onto bare metal machines, or to generate your own image sets for custom environments. ### QCOW2 The CentOS-Atomic-Host-7-GenericCloud.qcow2 (http://cloud.centos.org/centos/7/atomic/images/CentOS-Atomic-Host-7-Generic Cloud.qcow2) (1 GB) is suitable for use in on-premise and local virtualized environments. We test this on OpenStack, AWS and local Libvirt installs. If your virtualization platform does not provide its own cloud-init metadata source, you can create your own(http://www.projectatomic.io/blog/2014/10/getting-started-with-cloud-init /) NoCloud iso image. ### Amazon Machine Images Region Image ID ------ -------- us-east-1 ami-896653e3 us-west-2 ami-1f94747f us-west-1 ami-dae791ba eu-west-1 ami-430aba30 eu-central-1 ami-40d6cd2c ap-southeast-1 ami-4319d720 ap-northeast-1 ami-b54d4adb ap-southeast-2 ami-27123544 ap-northeast-2 ami-961fd1f8 sa-east-1 ami-238d0e4f ### SHA Sums 4062ef213eed698ac8ec03b32a55dd6903721a44dc8d54a18513644f160ca7d4 CentOS-Atomic-Host-7.20160130-GenericCloud.qcow2 a7dd91736f45101e95e7d9a80c2eede9164eb0392c8c4748b08c98a42d3eda39 CentOS-Atomic-Host-7.20160130-GenericCloud.qcow2.gz 9eca81d3638e4e00fc734d7233b47a3af803237cc82e5a66b3a587552232dcdc CentOS-Atomic-Host-7.20160130-GenericCloud.qcow2.xz be3c1a3326c04026f37bd6b6c2fccca3a285ea40ac663230624854abeaaee135 CentOS-Atomic-Host-7.20160130-Installer.iso 90942c3599e15ae21cdc0b1682b8e0d3fa88f8db2f6fdca0ece28c2bffdbb34f CentOS-Atomic-Host-7.20160130-Vagrant-Libvirt.box ce674573f6d7020b3d04c51f070d7172e71b6a4316c1495c238a7eac0260cb5a CentOS-Atomic-Host-7.20160130-Vagrant-Virtualbox.box ## Release Cycle The CentOS Atomic Host image follows the upstream Red Hat Enterprise Linux Atomic Host cadence. After sources are released, they're rebuilt and included in new images. After the images are tested by the SIG and deemed ready, we announce them. ## Getting Involved CentOS Atomic Host is produced by the CentOS Atomic SIG (http://wiki.centos.org/SpecialInterestGroup/Atomic) based on upstream work from Project Atomic (http://www.projectatomic.io/) If you'd like to work on testing images, help with packaging, documentation -- join us! The SIG meets weekly on Thursdays at 16:00 UTC in the #centos-devel channel, and you'll often find us in #atomic and/or #centos-devel if you have questions. You can also join the atomic-devel (https://lists.projectatomic.io/mailman/listinfo/atomic-devel) mailing list if you'd like to discuss the direction of Project Atomic, its components, or have other questions. ## Getting Help If you run into any problems with the images or components, feel free to ask on the centos-devel (http://lists.centos.org/mailman/listinfo/centos-devel) mailing list. Have questions about using Atomic? See the atomic (https://lists.projectatomic.io/mailman/listinfo/atomic) mailing list or find us in the #atomic channel on Freenode. --- Jason Brooks Red Hat Open Source and Standards @jasonbrooks | @redhatopen http://community.redhat.com

2 1

Registries
by Karanbir Singh 11 Feb '16

11 Feb '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Guys, Zeeshan has offered to look at the wider state of registries and do a short briefing on them ( oci/docker specific as a place to start ) at the next centos buildsystems irc meeting. Brian: what would be the best way to host this ? regards - -- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJWu0VjAAoJEI3Oi2Mx7xbtzq4H/36aBI4WM1Nmu73xcEzhiC7M t3tMsPK7/N9AqckjFQFSe00mJmIVE9ibzNIxmlTzzreHzlxjaKdDaMDES26+Op3e hOPWqsMoQ44wEJ6b7T6t7oP7pnOHo/dIdBwU+KirRfTHDKS/AcMH50GjrleqBIAm Ff7WluJQFwIO1CXH2jLYqbYCNCDdMxG932VnOgCZU0mOSPHS7cZ4VkzvDXnPdey8 VIwZKZwXYl+MBQDqohYJcSmUobiWYeEXlBOKNu6Q9J1+lYrfnrQq6/cpW6ETtpjB NdZfDf2bh7E1h88TpB0N93zPyel30Qkp9Pbe/uKF+fzP0jw6QdFQJLkiTSDUaW0= =Y6hq -----END PGP SIGNATURE-----

3 2

Re: [CentOS-devel] [atomic] official centos-7 docker image are wrong
by Jason Brooks 11 Feb '16

11 Feb '16

----- Original Message ----- > From: "Eric Paris" <eparis(a)redhat.com> > To: "Farkas Levente" <lfarkas(a)lfarkas.org>, "CentOS devel" <centos-devel(a)centos.org>, atomic(a)projectatomic.io > Sent: Wednesday, February 10, 2016 5:00:31 PM > Subject: Re: [atomic] official centos-7 docker image are wrong > > I'm willing to bet one week's pay that RH didn't silently release the > same version twice with different code... > > Wasn't there a problem that one of the base image build systems somehow > didn't support file caps and so the caps were being silently lost? > Maybe something about squashfs not understanding filecaps and rpm not > considering that a permanent failure... Very very hazy... There was this: http://www.projectatomic.io/blog/2015/04/problems-with-ping-in-containers-o… > > I know I remember this bug in the back of my head... > > In any case if you look in the centos base image (after installing > attr) > > # getfattr -n security.capability /usr/bin/ping > /usr/bin/ping: security.capability: No such attribute > > # rpm -V iputils > ........P /usr/bin/ping > ........P /usr/bin/ping6 > ........P /usr/sbin/arping > ........P /usr/sbin/clockdiff > > So while the right version/rpm was installed the actual bits in the > base image aren't what the rpm says they should be! The bug is in how > the base image is created... I don't know where, but just building it > again will likely just keep doing the wrong thing... > > I know this will trigger someone's mind who looking into this months > and months ago... > > -Eric > > On Wed, 2016-02-10 at 11:15 +0100, Farkas Levente wrote: > > hi, > > according to this bug > > https://bugzilla.redhat.com/show_bug.cgi?id=1142311 > > rh silently replace iputils with the same version with a fixed > > capabilities. > > unfortunately official base centos-7 (ie. latest 7.2) docker images > > are > > build with the wrong version, so these images should have to be > > rebuild > > with the proper version. > > currently in the official centos7 docker images: > > ------------------------------------- > > # rpm -qi iputils > > Name : iputils > > Version : 20121221 > > Release : 7.el7 > > Architecture: x86_64 > > Install Date: Wed 23 Dec 2015 06:09:24 PM UTC > > Group : System Environment/Daemons > > Size : 368577 > > License : BSD and GPLv2+ > > Signature : RSA/SHA256, Wed 25 Nov 2015 02:43:41 PM UTC, Key ID > > 24c6a8a7f4a80eb5 > > Source RPM : iputils-20121221-7.el7.src.rpm > > Build Date : Fri 20 Nov 2015 07:12:19 PM UTC > > Build Host : worker1.bsys.centos.org > > Relocations : (not relocatable) > > Packager : CentOS BuildSystem <http://bugs.centos.org> > > Vendor : CentOS > > URL : http://www.skbuff.net/iputils > > Summary : Network monitoring tools including ping > > Description : > > The iputils package contains basic utilities for monitoring a > > network, > > including ping. The ping command sends a series of ICMP protocol > > ECHO_REQUEST packets to a specified network host to discover whether > > the target machine is alive and receiving network traffic. > > ------------------------------------- > > > > while in the centos repo: > > ------------------------------------- > > # rpm -qi iputils > > Name : iputils > > Version : 20121221 > > Release : 7.el7 > > Architecture: x86_64 > > Install Date: Tue 15 Dec 2015 03:15:22 PM CET > > Group : System Environment/Daemons > > Size : 368577 > > License : BSD and GPLv2+ > > Signature : RSA/SHA256, Wed 25 Nov 2015 03:43:41 PM CET, Key ID > > 24c6a8a7f4a80eb5 > > Source RPM : iputils-20121221-7.el7.src.rpm > > Build Date : Fri 20 Nov 2015 08:12:19 PM CET > > Build Host : worker1.bsys.centos.org > > Relocations : (not relocatable) > > Packager : CentOS BuildSystem <http://bugs.centos.org> > > Vendor : CentOS > > URL : http://www.skbuff.net/iputils > > Summary : Network monitoring tools including ping > > Description : > > The iputils package contains basic utilities for monitoring a > > network, > > including ping. The ping command sends a series of ICMP protocol > > ECHO_REQUEST packets to a specified network host to discover whether > > the target machine is alive and receiving network traffic. > > ------------------------------------- > > imho it's a bug! without it ping not working from any docker > > container > > based on centos7. > > > >

1 0

SIGs, versions, and yum update
by George Dunlap 10 Feb '16

10 Feb '16

A couple of weeks ago I was just about to push an update of Xen 4.4 to Xen 4.6 to the Virt SIG repositories, and I suddenly got some push-back from the users, because Xen 4.6 has some fairly significant changes -- particularly the removal of the old toolstack daemon called xend. (xend had been disabled by default and had lots of messages warning about the upcoming deprecation, even in 4.4.) It seems some users have the expectation that they should be able to run "yum update -y" on their servers on a regular basis, without having to worry about accidentally updating to a new major version that break things. So one thing that was proposed was that we make separate packages somehow, such that users would have to actively request the newer version rather than getting it automatically. (This could be done either by having a package named xen46, or by having separate centos-release-xen-46 package that pointed to an entirely different repository.) But of course, other users pushed back on that idea, saying they would always rather have the latest version Just Work, and didn't like the idea of having to manually keep track of what version was installed on any given system, or of actually finding out that there's a new package and what that new package name is. KB and I chatted about it at the Virt SIG meeting, and decided that we should touch base with the other SIGs to have a consistent message. As for my own opinion: I can see both sides of the story, and as a package maintainer I'd be willing to do either one. But on the whole I tend to side with the "latest version" crowd. I think you should always be looking at what "yum update" gives you before installing it; even minor updates I can't guarantee are going to break things. And I'd rather the installation instructions be simple (don't have to mess around with version numbers), and I'd rather people not have to fish around for major updates (or run packages with unpatched security vulnerabilities because they didn't realize their packages were now obsolete). What do other SIGs think? -George

5 6

[Atomic SIG] Signing and Publishing RPMs for ADB
by Lalatendu Mohanty 10 Feb '16

10 Feb '16

For ADB (Atomic Developer Bundle) Vagrantbox we want to add a new RPM i.e. adb-utils [2]. For that to happen we need to sign the adb-utils which we have built in cbs [3] and making it available in CentOS projects official YUM repositories (e.g. buildlogs). So that we can include the repo while building the Vagrantbox. We need a key to sign the content and also need automatic push of builds when it is tagged with "atomic7-adb-common-testing". I have also raised issues in bugs.centos.org [4] [5] for this. At this point the RPMs only make sense inside of the ADB Vagrantbox. So we expect user to use the RPMs through the Vagrantbox. [1] https://github.com/projectatomic/adb-atomic-developer-bundle [2] https://github.com/projectatomic/adb-utils [3] http://cbs.centos.org/koji/buildinfo?buildID=8707 [4] https://bugs.centos.org/view.php?id=10345 [5] https://bugs.centos.org/view.php?id=10346 Thanks, Lala

2 1

adb effort and the PaaS SIG
by Karanbir Singh 10 Feb '16

10 Feb '16

hi, With the PaaS SIG onboarding, and being centralised around OpenShift - does it make sense to consider ADB moving from the Atomic SIG into this space ? Regards -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

1 0

[altarch] multiarch docker images
by Manfred Touron 08 Feb '16

08 Feb '16

Hi everyone, I'm working at Scaleway on the multiarch images system, I'm @moul on IRC and talked with @Arrfab and @Evolution (thanks a lot, guys). --- Context: Today, we are using Docker as a build-step to generate our baremetal servers rootfs, what we call, the "Scaleway images". Here is an example of "1 click app" image: - Public Hub: https://hub.scaleway.com/wordpress.html - DevHub (aggregate APIs): http://devhub.scaleway.com/#/images/wordpress:latest - Source (GitHub): https://github.com/scaleway-community/scaleway-wordpress/ - Docker Hub: https://hub.docker.com/r/scaleway/wordpress/ - Build logs: https://travis-ci.org/scaleway/qa/builds/98515979 We are quite happy today with this method and are succesfully running plenty Linux distributions (Ubuntu, openSUSE, Gentoo, Fedora, Debian, Arch Linux and Alpine Linux). Actually we also have a proof-of-concept of CentOS image, but based on an old development CubieTruck snapshot with no public mirrors. Here is how I built this POC image (I wasn't aware of virt-tar-out): https://github.com/armbuild/centos-img/blob/master/buildcontainers.sh --- We will soon release new server models with new architectures, our next priorities are: `arm64` and `x86_64`, but we plan to support more architectures if we feel enough people will need it so the development worth it. I started to work on "multiarch" images (one image per architecture). Here are some images: - https://github.com/multiarch/alpine -> built with `apk-static` in a chroot - https://github.com/multiarch/busybox -> static binaries extracted from latest busybox-static.deb - https://github.com/multiarch/ubuntu-debootstrap -> qemu-debootstrap - https://github.com/multiarch/debian-debootstrap -> same as above - https://github.com/multiarch/ubuntu-core -> based on released rootfs tarballs at https://partner-images.canonical.com/core/wily/current/ All those images also contains an `x86_64` `qemu-${ARCH}-static` so you can run them on an `x86_64` host with `binfmt-support` available. Look at the README.md files for usage and examples. I began to work on the Centos image https://github.com/multiarch/centos, I successfully built the `armhf` and `arm64` images by `virt-tar-out`ing the CubieTruck released image, i.e.: http://mirror.centos.org/altarch/7.2.1511/isos/armhfp/ I also successfully built the `x86_64` and `i386` images using kickstart: livemedia-creator --arch=i386 --make-disk \ --iso=/tmp/boot7-i386.iso \ --ks=$(pwd)/centos-7.ks \ --image-name=centos-7-base-i386 based on https://github.com/CentOS/sig-cloud-instance-build/tree/livemedia_builds/do… For now I failed to build the `ppc64` nor `ppc64le` images, but that's not a priority. I have now an issue, my `armhf` and `x86_64` images are not the same, the ones based on real boards .img.xz embed about 300M of kernel images, dtb, kernel modules, firmware (I don't want them) + a lot more apps that we can find by default in the <200Mb `x86_64` Docker image. I would like to find a solution to build "same" images for all the targets and avoid as much as possible the need of diffing the outputs of `yum list installed`. My favorite solution would be to use kickstart files, which are very cool to put on GitHub. But the non `x86_64` architectures lack of a `boot.iso` file packing `isolinux`. Is it possible to add those `boot.iso` files on the mirror or tell me how to build them ? Do you see alternative ways to build identical images ? -- Manfred Touron - @moul CTO @ scaleway.com

7 16

NO CBS/Infra Meeting 08-Feb-2016
by Brian Stinson 07 Feb '16

07 Feb '16

Hi Folks, I know some of us (myself included) are traveling or recovering from the Dojo -> FOSDEM -> cfgmgmt -> Devconf marathon, so let's cancel this week's meeting. I'll send out a list of open action items here to the list sometime between airplanes tomorrow. Cheers! --Brian

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel