devel July 2016

devel@lists.centos.org

36 participants
38 discussions

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

New CentOS Atomic Host release available for download
by Jason Brooks 08 Jul '16

08 Jul '16

An updated version of CentOS Atomic Host (tree version 7.20160707) is now available for download[1], featuring updated versions of docker (1.10.3) and the atomic run tool (1.10.5). 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. [1] https://wiki.centos.org/SpecialInterestGroup/Atomic/Download 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. The backing ostree repo is published to mirror.centos.org. CentOS Atomic Host includes these core component versions: - docker-1.10.3-44.el7.centos.x86_64 - kubernetes-1.2.0-0.12.gita4463d9.el7.x86_64 - kernel-3.10.0-327.22.2.el7.x86_64 - atomic-1.10.5-5.el7.x86_64 - flannel-0.5.3-9.el7.x86_64 - ostree-2016.5-3.atomic.el7.x86_64 - etcd-2.2.5-2.el7.0.1.x86_64 - cloud-init-0.7.5-10.el7.centos.1.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 (467 MB) and CentOS-Atomic-Host-7-Vagrant-Virtualbox.box (477 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 (751 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 image allows users to control the install using kickstarts and to define custom storage, networking and user accounts. This is the recommended option for getting CentOS Atomic Host onto bare metal machines, or for generating your own image sets for custom environments. QCOW2 The CentOS-Atomic-Host-7-GenericCloud.qcow2 (1.1 GB) image 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 NoCloud iso image. Amazon Machine Images Region Image ID us-east-1 ami-956fe882 us-west-2 ami-17569677 us-west-1 ami-191e5879 eu-west-1 ami-a06601d3 eu-central-1 ami-c431dbab ap-southeast-1 ami-9638e5f5 ap-northeast-1 ami-fc867b9d ap-southeast-2 ami-6fab800c ap-northeast-2 ami-aca369c2 sa-east-1 ami-30f96d5c SHA Sums 0eb6fe98706c72635d2f156d3f9cbc4447db3234dafd792ed2b966a562695dcf CentOS-Atomic-Host-7.1606-GenericCloud.qcow2 3af5dba377f31f52817820f8b940d0490da11d74d01edd70182171f21382fc65 CentOS-Atomic-Host-7.1606-GenericCloud.qcow2.gz d28b3f21de85c6c072e277bf873d1657364f6b82f08c91b05ed001ceadb07b79 CentOS-Atomic-Host-7.1606-GenericCloud.qcow2.xz ee98acb5a50288e03dc052d4ae5cf0ccbab518f2f15f35500217c90d8088d627 CentOS-Atomic-Host-7.1606-Installer.iso 43ca397be511a32b3c750a73474039f965d6cc5c7dcfb74846e66366f5d758db CentOS-Atomic-Host-7.1606-Vagrant-Libvirt.box d458714f89b1ee3d4e4b7b097877cec9ceec5e651fec9374b4457e5a6c172f3d CentOS-Atomic-Host-7.1606-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, based on upstream work from Project Atomic. 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 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 mailing list. Have questions about using Atomic? See the atomic mailing list or find us in the #atomic channel on Freenode.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel July 2016