devel

devel@lists.centos.org

10 participants
4617 discussions

[Infra] - Pre-announced major outage for several services (please read)
by Fabian Arrotin 08 Mar '17

08 Mar '17

Due to some reorganization at the DC/Cage level, we'll have to shutdown/move/reconfigure a big part of our hosted infra for the following services : - cbs.centos.org (Koji) - accounts.centos.org (auth backend) - ci.centos.org (jenkins-driven CI environment) We're working on a plan to minimize the downtime/reconfiguration part, but at first sight, due to the hardware move of the racks/recabling parts/etc, the announced downtime will be probably ~48h. What does that mean ? That during this window, nobody will be able to build/tests packages, nor be able to triggers automatically CI jobs (important). We don't have the final dates confirmed (yet) but it seems that the migration will be scheduled for March 14th. We'll keep you informed when we'll have confirmation about those dates. Feel free to answer in this thread, or find us in #centos-devel on freenode. -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab

1 2

[SCLo SIG] new sclo-php*-php-smbclient packages available for testing
by Remi Collet 07 Mar '17

07 Mar '17

Yet another package available in centos-sclo-sclo-testing smbclient is a PHP extension that uses Samba's libsmbclient library to provide Samba related functions and 'smb' streams to PHP programs. For rh-php56 * sclo-php56-php-smbclient-0.9.0-1 For rh-php70 * sclo-php70-php-smbclient-0.9.0-1 This extension may be used by (among other projects): - nextcloud / owncloud (via icewind/smb) - EGroupware (via php streams). Remi. P.S. https://wiki.centos.org/SpecialInterestGroup/SCLo

1 0

[SCLo SIG] new sclo-php*-php-imap packages available for testing
by Remi Collet 07 Mar '17

07 Mar '17

Yet another package available in centos-sclo-sclo-testing The php-imap package module will add IMAP (Internet Message Access Protocol) support to PHP. IMAP is a protocol for retrieving and uploading e-mail messages on mail servers. PHP is an HTML-embedded scripting language. If you need IMAP support for PHP applications, you will need to install this package. For rh-php56 (EL-7 only) * sclo-php56-php-imap-5.6.25-2.el7 For rh-php70 (EL-7 only) * sclo-php70-php-imap-7.0.14-2.el7 Notices: - this extension is already available in upstream collection for CentOS/RHEL 6 (rh-php56-php-imap andf rh-php70-php-imap) - this extension requires "libc-client" which is not part of CentOS/RHEL 7, but available in EPEL-7. - in both versions the yum install "rh-phpxx-php-imap" will work. Remi. P.S. https://wiki.centos.org/SpecialInterestGroup/SCLo

1 0

CentOS PaaS SIG meeting (2017-03-01)
by Troy Dawson 01 Mar '17

01 Mar '17

Hello, It's time for our weekly PaaS SIG sync-up meeting Time: 1700 UTC - Wedensdays Date: Today Wedensday, 1 March 2017 Where: IRC- Freenode - #centos-devel Agenda: - OpenShift Current StatusI -- rpms -- Documentation -- Automated testing and Automated rpm building -- images / image building -- Multi-arch -- separate repo work - Open Floor

1 1

Getting content to mirrors faster
by Anssi Johansson 01 Mar '17

01 Mar '17

We have 600+ active CentOS mirrors[1] and sometimes there are critical updates that would need to get published to the mirror network as quickly as possible. As of now, it takes around five hours to go from 0 up-to-date mirrors to 80% up-to-date mirrors, with a longer tail for the remaining 20%. Current guidelines for setting up a mirror[2] specify that mirrors should sync 2-4 times per day. Instead of telling mirrors to sync hourly I thought we could come up with something smarter. One option that I have considered would be something similar to what the ClamAV guys use to signal end users that there is new content. They use a DNS TXT record for that purpose. For example, as of this writing "dig txt +short current.cvd.clamav.net" produces "0.99.2:57:23148:1488371340:1:63:45637:290", which shows the version numbers for ClamAV itself, main virus database, daily virus database, timestamp and other version numbers. We could have something similar, showing the timestamps when the content for CentOS, CentOS AltArch and CentOS Vault was last modified, like "1488372781:1487767981:1488113581". "Last modified" in the sense that new packages got added at that time. The idea is that mirrors could set up scripts to check that timestamp from DNS more frequently (such as hourly) without causing load issues to msync nodes by rsyncing hourly. The TTL for the TXT record could be relatively small, like 10 minutes. As you're all aware, DNS is a prime example of a very scalable system, and that's why I'm fond of this solution. Another option would be to publish the same data in a central location and served over http(s), if relaying the timestamp data via DNS is not desired for some reason. The basic principle would be "if timestamp in TXT record > my current timestamp (TIME file), synchronize the mirror". With more frequent syncs, mirror admins would need to take care that no two rsync runs would happen at the same time. Using lockfile in the scripts would help with this. I hope that many of the mirror admins already use lockfiles, but providing an example script might help for the newer mirror admins. The timestamps should be updated only after it has been verified that all (or at least the majority) of msync nodes actually have the content. It takes a while for the data to reach all the msync nodes from the master. On the other hand, this may cause some traffic peaks for the msync nodes. I don't know how well they would handle the peaks. One obvious way to alleviate the peaks would be to instruct mirror admins to pick a random minute when to check for new content. echo $[ $RANDOM % 60 ] works nicely for this. I don't have statistics, but I believe there might be mirrors that sync at "0 */6" ie. at the top of the hour. If the traffic peaks to msync nodes is deemed to be a problem, there might be ways to reduce the load to msync nodes. The following idea could be implemented separately from the above timestamp idea, if needed. There could be some sort of a "web service" which instructs mirrors where to sync from. The core idea in this is that the source might not always be a msync.centos.org server, but it could also be a nearby public mirror that offers rsync and has been verified to have the new content. If requested from Finland, that service could say "ok, you're from .fi, go sync from ftp.funet.fi as it has the new content already" or "uh oh, no nearby external mirrors have the new content, please rsync from eu-msync.centos.org". It could simply return a list of rsync servers in descending priority, with some msync.centos.org addresses at the bottom as fallback. Once the mirror has rsynced, the mirror could ping back and say "I have the content now, please check, and if OK, add me to the list of mirrors that have the new content". One concern is that the list of rsync sources would need to be protected, so that mirrors could not be tricked into syncing from a malicious source (think DNS poisoning). Ways to protect from this include DNSSEC, TLS and PGP signed data. Any thoughts about this? [1] http://mirror-status.centos.org/ [2] https://wiki.centos.org/HowTos/CreatePublicMirrors

2 1

Questions about NFV Sig and Repos
by Thomas F Herbert 23 Feb '17

23 Feb '17

I am beginning to look at NFV Sig again and I have a question about the following. Can Centos NFV SIG create a Repo to be visible in mirrors.centos.org that contains DPDK and other packages as well as VPP once that is built in CBS. If so, what is the process for instancing a repo in mirrors.centos.org like the cloud SIG has? Also, do the following packages appear in any of the Repos. Did I miss something? <http://cbs.centos.org/koji/packageinfo?packageID=737>http://cbs.centos.org/koji/packageinfo?packageID=737 <http://cbs.centos.org/koji/packageinfo?packageID=288>http://cbs.centos.org/koji/packageinfo?packageID=288 --TFH -- *Thomas F Herbert* SDN Group Office of Technology *Red Hat*

4 7

Fwd: [rdo-list] [release] RDO Ocata packages released
by Alan Pevec 22 Feb '17

22 Feb '17

---------- Forwarded message ---------- From: "Javier Pena" <javier.pena(a)redhat.com> Date: Feb 22, 2017 18:27 Subject: [rdo-list] [release] RDO Ocata packages released The RDO community is pleased to announce the general availability of the RDO build for OpenStack Ocata for RPM-based distributions, CentOS Linux 7 and Red Hat Enterprise Linux. RDO is suitable for building private, public, and hybrid clouds. Ocata is the 15th release from the OpenStack project (http://openstack.org) which is the work of more than 2500 contributors from around the world (source http://stackalytics.com/) The RDO community project (https://www.rdoproject.org/) curates, packages, builds, tests and maintains a complete OpenStack component set for RHEL and CentOS Linux and is a member of the CentOS Cloud Infrastructure SIG ( https://wiki.centos.org/SpecialInterestGroup/Cloud) The Cloud Infrastructure SIG focuses on delivering a great user experience for CentOS Linux users looking to build and maintain their own on-premise, public or hybrid clouds. All work on RDO, and on the downstream release, Red Hat OpenStack Platform, is 100% open source, with all code changes going upstream first. Interesting things in the Ocata release include: - Significant Improvements (https://www.rdoproject.org/ blog/2017/02/testing-rdo-with-tempest-new-features-in-ocata/) to Tempest and Tempest plugin packaging in RDO - The OpenStack-Ansible (https://docs.openstack.org/ releasenotes/openstack-ansible/ocata.html#new-features) project now supports deployment on top of CentOS with the help of RDO-packaged dependencies For cloud operators, RDO now provides packages for some new OpenStack Services: - Tacker (https://docs.openstack.org/developer/tacker/) an ETSI MANO NFV Orchestrator and VNF Manager - Congress (https://docs.openstack.org/developer/congress/ architecture.html): an open policy framework for the cloud - Vitrage (https://docs.openstack.org/developer/vitrage/) the OpenStack RCA (Root Cause Analysis) Service - Kolla (https://github.com/openstack/kolla) The Kolla project provides tooling to build production-ready container images for deploying OpenStack clouds Some other notable additions: - novajoin (https://github.com/openstack/novajoin) a dynamic vendordata plugin for the OpenStack nova metadata service to manage automatic host instantiation in an IPA server - ironic-ui (https://docs.openstack.org/developer/ironic-ui/) a new Horizon plugin to view and manage baremetal servers - python-virtualbmc (https://github.com/openstack/virtualbmc) VirtualBMC is a proxy that translates IPMI commands to libvirt calls. This allows projects such as OpenStack Ironic to test IPMI drivers using VMs. - python-muranoclient (https://github.com/openstack/python-muranoclient) a client for the Application Catalog service. - python-monascaclient (https://github.com/openstack/ python-monascaclient): a client for the Monasca monitoring-as-a-service solution. - Shaker (http://pyshaker.readthedocs.io/en/latest/) the distributed data-plane testing tool built for OpenStack - Multi-architecture support: aarch64 builds are now provided through an experimental repository - enable the RDO 'testing' repositories to get started >From a networking perspective, we have added some new Neutron plugins that can help Cloud users and operators to address new use cases and scenarios: - networking-bagpipe (https://docs.openstack.org/ developer/networking-bagpipe/): a mechanism driver for Neutron ML2 plugin using BGP E-VPNs/IP VPNs as a backend - networking-bgpvpn (https://docs.openstack.org/ developer/networking-bgpvpn/): an API and framework to interconnect BGP/MPLS VPNs to Openstack Neutron networks - networking-fujitsu (https://github.com/openstack/networking-fujitsu) FUJITSU ML2 plugins/drivers for OpenStack Neutron - networking-l2gw (https://github.com/openstack/networking-l2gw) APIs and implementations to support L2 Gateways in Neutron - networking-sfc (https://github.com/openstack/networking-sfc) APIs and implementations to support Service Function Chaining in Neutron >From the Packstack (https://github.com/openstack/packstack) side, we have several improvements: - We have added support to install Panko and Magnum - Puppet 4 is now supported, and we have updated our manifests to cover the latest changes in the supported projects **Getting Started** There are three ways to get started with RDO. - To spin up a proof of concept cloud, quickly, and on limited hardware, try the All-In-One Quickstart (http://rdoproject.org/Quickstart) You can run RDO on a single node to get a feel for how it works. - For a production deployment of RDO, use the TripleO Quickstart ( https://www.rdoproject.org/tripleo/) and you'll be running a production cloud in short order. - Finally, if you want to try out OpenStack, but don't have the time or hardware to run it yourself, visit TryStack (http://trystack.org/) where you can use a free public OpenStack instance, running RDO packages, to experiment with the OpenStack management interface and API, launch instances, configure networks, and generally familiarize yourself with OpenStack. (TryStack is not, at this time, running Ocata, although it is running RDO.) **Getting Help** The RDO Project participates in a Q&A service at ask.openstack.org ( http://ask.openstack.org) for more developer-oriented content we recommend joining the rdo-list mailing list (https://www.redhat.com/ mailman/listinfo/rdo-list). Remember to post a brief introduction about yourself and your RDO story. You can also find extensive documentation on the RDO docs site (https://www.rdoproject.org/documentation) The #rdo channel on Freenode IRC is also an excellent place to find help and give help. We also welcome comments and requests on the CentOS mailing lists ( https://lists.centos.org/) and the CentOS and TripleO IRC channels (#centos, #centos-devel, and #tripleo on irc.freenode.net) however we have a more focused audience in the RDO venues. **Getting Involved** To get involved in the OpenStack RPM packaging effort, see the RDO community pages (https://www.rdoproject.org/community/) and the CentOS Cloud SIG page (https://wiki.centos.org/SpecialInterestGroup/Cloud) See also the RDO packaging documentation (https://www.rdoproject.org/packaging/ ). Join us in #rdo on the Freenode IRC network, and follow us at @RDOCommunity (http://twitter.com/rdocommunity) on Twitter. If you prefer Facebook, we're there too (http://facebook.com/rdocommunity) and also Google+ ( http://tm3.org/rdogplus) Cheers, Javier _______________________________________________ rdo-list mailing list rdo-list(a)redhat.com https://www.redhat.com/mailman/listinfo/rdo-list To unsubscribe: rdo-list-unsubscribe(a)redhat.com

1 0

No Paas SIG meeting today
by Troy Dawson 22 Feb '17

22 Feb '17

Due to several key SIG members being gone, thre will be no Paas SIG meeting today. Troy

1 0

Joining OpsTools SIG
by Sandro Bonazzola 22 Feb '17

22 Feb '17

Hi, I'm working close with OpsTool for oVirt project within VIrt SIG and I can help with some of the packaging effort there. According to https://wiki.centos.org/SpecialInterestGroup/OpsTools#line-69 I'm publishing my interest to join the group and applied through FAS2 system to join the group. Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

3 2

CentOS PaaS SIG meeting (2017-02-08)
by Troy Dawson 21 Feb '17

21 Feb '17

Hello, It's time for our weekly PaaS SIG sync-up meeting Time: 1700 UTC - Wedensdays Date: Today Wedensday, 08 February 2017 Where: IRC- Freenode - #centos-devel Agenda: - OpenShift Current StatusI -- rpms --- Pass / No Pass for origin 1.4.1 and openshift-ansible -- Documentation -- Automated testing and Automated rpm building -- images / image building -- Multi-arch - Discussion on having seperate repo for each release -- paas7-openshift-origin-1.4, paas7-openshift-origin-1.5 - Open Floor

2 3

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