devel

devel@lists.centos.org

4 participants
4696 discussions

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

[question] audio and realtime SIG
by Markus Seeber 17 May '17

17 May '17

Hello, I remember there has been some interest in creating an audio related SIG a few years ago and I'd like to know if anything has come out of that. Related to that, I wonder if there is a realtime related SIG. From a first quick search over the wiki pages there does not seem to be such a thing. On the other hand I know that CERN has put some effort in maintaining rt-kernels for their rt messaging grid. Is there anything going on the CentOS side in regard to these use cases? best regards Markus

1 0

New CentOS Atomic Host with Optional Docker 1.13
by Jason Brooks 16 May '17

16 May '17

An updated version of CentOS Atomic Host (tree version 7.20170428), is now available, featuring the option of substituting the host’s default docker 1.12 container engine with a more recent, docker 1.13-based version, provided via the docker-latest package. https://wiki.centos.org/SpecialInterestGroup/Atomic/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. 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: - atomic-1.15.4-2.el7.x86_64 - cloud-init-0.7.5-10.el7.centos.1.x86_64 - docker-1.12.6-16.el7.centos.x86_64 - etcd-3.1.3-1.el7.x86_64 - flannel-0.7.0-1.el7.x86_64 - kernel-3.10.0-514.16.1.el7.x86_64 - kubernetes-node-1.5.2-0.5.gita552679.el7.x86_64 - ostree-2017.3-2.el7.x86_64 - rpm-ostree-client-2017.3-1.atomic.el7.x86_64 Containerized kubernetes-master The downstream release of CentOS Atomic Host ships without the kubernetes-master package built into the image. Instead, you can run the master kubernetes components (apiserver, scheduler, and controller-manager) in containers, managed via systemd, using the service files and instructions on the CentOS wiki. The containers referenced in these systemd service files are built in and hosted from the CentOS Community Container Pipeline, based on Dockerfiles from the CentOS-Dockerfiles repository. https://wiki.centos.org/SpecialInterestGroup/Atomic/ContainerizedMaster These containers have been tested with the kubernetes ansible scripts provided in the upstream contrib repository, and they work as expected, provided you first copy the service files onto your master. Alternatively, you can install the kubernetes-master components using rpm-ostree package layering using the command: atomic host install kubernetes-master. docker-latest You can switch to the alternate docker version by running: # systemctl disable docker --now # systemctl enable docker-latest --now # sed -i '/DOCKERBINARY/s/^#//g' /etc/sysconfig/docker Because both docker services share the /run/docker directory, you cannot run both docker and docker-latest at the same time on the same system. 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 and CentOS-Atomic-Host-7-Vagrant-Virtualbox.box 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 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 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 ---------------- -------------- ap-south-1 ami-9c7b06f3 eu-west-2 ami-14425570 eu-west-1 ami-a1b9b7c7 ap-northeast-2 ami-e01cc18e ap-northeast-1 ami-2a0d304d sa-east-1 ami-ce7619a2 ca-central-1 ami-8b813def ap-southeast-1 ami-61e36702 ap-southeast-2 ami-84c7cde7 eu-central-1 ami-f970ae96 us-east-1 ami-4a70015c us-east-2 ami-d2cfe8b7 us-west-1 ami-57ba9c37 us-west-2 ami-fbd8bd9b SHA Sums 977c9b6e70dd0170fc092520f01be26c4d256ffe5340928d79c762850e5cedd9 CentOS-Atomic-Host-7.1704-GenericCloud.qcow2 781074c43aa6a6f3cad61a77108541976776eb3cb6fe30f54ca746a8314b5f87 CentOS-Atomic-Host-7.1704-GenericCloud.qcow2.gz aef7fedf01b920ee75449467eb93724405cb22d861311fbc42406a7bd4dbfee2 CentOS-Atomic-Host-7.1704-GenericCloud.qcow2.xz 669c5fd1b97bc2849a7e3dbec325207d98e834ce71e17e0921b583820d91f4f5 CentOS-Atomic-Host-7.1704-Installer.iso b5ef69bff65ab595992649f62c8fc67c61faa59ba7f4ff0cb455a9196e450ae2 CentOS-Atomic-Host-7.1704-Vagrant-Libvirt.box 73757f50ef9cdac2e3ba6d88a216cca23000a32fa96891902feaa86d49147e3f CentOS-Atomic-Host-7.1704-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

[storage] Ceph Jewel 10.2.7 now tagged for -testing
by David Moreau Simard 11 May '17

11 May '17

Hi, Please take note that Ceph Jewel 10.2.7 has been tagged for testing after a successful smoke test of an initial build. It should land on the buildlogs CDN shortly. Ceph Jewel in the stable release repository is currently at 10.2.5 since 10.2.6 had not been built. You can find the release notes for the new versions upstream: - 10.2.6 (March 8th): http://ceph.com/releases/v10-2-6-jewel-released/ - 10.2.7 (April 10th): http://ceph.com/releases/v10-2-7-jewel-released/ The Ceph storage SIG rebuilds straight from upstream source RPMs found here [1]. We version spec file differences on GitHub [2] for information purposes only. You can test this new version with the centos-release-ceph-jewel package, like so: === yum -y install centos-release-ceph-jewel yum-config-manager --enable centos-ceph-jewel-test yum -y install ceph === This will remain in -testing until at least April 24th, after which it will be tagged for release if no problems are reported. Thanks, [1]: http://download.ceph.com/rpm-jewel/ [2]: https://github.com/CentOS-Storage-SIG/ceph David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter]

2 5

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

10 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, 10 May 2017 Where: IRC- Freenode - #centos-devel Agenda: - OpenShift Current Status -- rpms -- Documentation -- Automated testing and Automated rpm building -- Images and Image building -- Multi-arch -- separate repo work -- minishift - Open Floor

1 1

[Minutes] RDO meeting (2017-05-10)
by Chandan kumar 10 May '17

10 May '17

============================== #rdo: RDO meeting - 2017-05-10 ============================== Meeting started by chandankumar at 15:01:38 UTC. The full logs are available at http://eavesdrop.openstack.org/meetings/rdo_meeting___2017_05_10/2017/rdo_m… . Meeting summary --------------- * tripleo-ui dependency reviews (chandankumar, 15:06:07) * ACTION: number80 review tripleo-ui new deps (number80, 15:07:20) * chair for next meeting (chandankumar, 15:18:06) * ACTION: amoralej will be chairing next meeting. (chandankumar, 15:18:57) * openfloor (chandankumar, 15:19:09) * LINK: https://opensourceinfra.org/ (chandankumar, 15:24:45) * LINK: https://www.eventbrite.com/e/rdo-social-at-openstack-summit-boston-tickets-… (number80, 15:28:59) * ACTION: jpena to share the RDO Service Continuity document draft in rdo-list (jpena, 15:29:51) Meeting ended at 15:33:45 UTC. Action items, by person ----------------------- * amoralej * amoralej will be chairing next meeting. * jpena * jpena to share the RDO Service Continuity document draft in rdo-list * number80 * number80 review tripleo-ui new deps People present (lines said) --------------------------- * chandankumar (39) * Duck (17) * openstack (10) * jtomasek (8) * number80 (7) * jpena (6) * dmsimard (2) * amoralej (2) * ykarel_ (1) * jruzicka (1) * EmilienM (1) * jschlueter (1) Generated by `MeetBot`_ 0.1.4

1 0

Update on CentOS Community Container Pipeline
by Bamacharan Kundu 10 May '17

10 May '17

Hi, Below is an update on recent works for CentOS Community Container Pipeline * Now emails from prod and test are distinguished, by prepending test to subject for emails from test. * Filters are added for scanner rpm verify for centos base image issues. * Changed email notification for the user to address the image name properly. * Issues with linter are fixed now to make sure it does not point registry.centos.org as invalid registry. * Configurable logrotate policy is added to make sure worker logs are handled properly. * For every deployment, fresh images are now pulled for container-pipeline dependency images. Our current focus is on: * Get test_worker and internal registry working with build streamline. * Make Dockerfile lint trigger work with Mail worker to send an email if Dockerfile is not present at git_path. * Fix issues with weekly scan mail to point to proper logs * Fix errors coming for services when they are not able to communicate to beanstalk * Work on email module to be able to receive send email request from all other module * Logging - Storing logs per build and also having shadow rotating logfile where all logs are streamlined We are working to get the below projects in registry.centos.org * sentry * ScyllaDB (https://groups.google.com/forum/#!topic/scylladb-dev/T2rIeqjac14) * MonetDB * Review board Regards Bama Charan Kundu

1 0

Vagrant images for Hyper-V
by Patrick Lang 02 May '17

02 May '17

> > > > We now have a working solution for producing regular .vhd images as part > > of our release process: CBS is now using qemu-img-ev and qemu-kvm-ev from > > the Virt SIG, instead of the versions in CentOS Linux base. We don't need > > either VirtualBox or changes in Image Factory. > > > > If anyone has access to Hyper-V on Windows and would be willing to test > > two Vagrant images, please let me know. I received conflicting test > > results from Thomas and Michael, and I'd like to have at least an > > additional test before deciding whether to release them or not. > > > > Thanks, > > Lauren?iu > > > > I just reached out to a friend on the Hyper-V team at MS to see if we can > figure something out. It would be nice to have a way to automate this > testing going forward. > > -Jeff I emailed Laurentiu off list to get the boxes for 6.1.1 and 7.1.1. I'm late to joining this discussion but I'm happy to help. I work on the Hyper-V team and have been doing some testing and improvements to Vagrant and Packer on the side. re: sparse files - NTFS doesn't support sparse files, but Hyper-V does have dynamically expanding VHD and VHDX files. VHDX allocations are configurable but the default of 32MB is tuned to NTFS which puts all metadata at the beginning of the disk. Dropping VHDX allocations down to 1MB helps reduce the slack space left after each inode. VHD uses smaller allocations so it’s less of an issue. Both images are just over a gig on disk which is about what I’d expect. If you’re optimizing the template Vagrantfiles in the boxes, it would be very helpful to add differencing_disk = true to avoid copying the full VHD and reduce IO in vagrant up. Here's what I observed on each image Centos 6.1.1 - Vagrant didn't find an IP address upon bootup. I logged in via the console and the Hyper-V virtual NIC was on eth1 which didn't have dhclient configured. I ran dhclient manually, then vagrant ssh was able to find the IP Centos 7.1.1 - Vagrant worked as expected. It found the IP as the VM booted up. I haven't fully tested everything but wanted to share some of the results. Let me know if there's a list of tests run against the other boxes and I can go through them. Cheers, Patrick Lang (github.com/patricklang) Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

2 4

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