devel December 2014

devel@lists.centos.org

38 participants
39 discussions

el7.i686 Google Hang Out
by Bob Lightfoot 26 Dec '14

26 Dec '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 KB: Let me know what the google hangout url is and I'll be checking in. I see from a web search that Springdale Linux has come out with an i686.el7 linux spin off. So it obviously can be done with the right skill set group to pull it off. Might be beyond my skill set, but I'll lend what I can. Bob Lightfoot -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJUndRWAAoJEKqgpLIhfz3XxswH/1sLqbMXQsLhoA168Pfy17gI 8kKVNOUToVBFsRf5xz2lRcCBoanqEncdyAMlQ3+uEZRLPfD29gj/TW3uW7AoDt2z 01uAEPH1gYTa20IvPfQljBzJLOemNKjfGyzkovM/f8EqTfK/FcHDDwWerCIzgJSg /6+lmoaayXfmYE6HMI9r9krRP1XYcZGNY1yJYpgHmnqYpjrFqnONZf1KXUOAeGIH RjJ1SK4T3at2k2Umllo3ooW05O8lJEgHTnvz/CpK6VOrdjsY5+gQtI+9fNb7qGk7 GTWeaTGSseojilCKYaHbfzsgAZku7EqYqWpcx7AEcfIClJR6WgHWJVcAVER8FO8= =2USa -----END PGP SIGNATURE-----

1 0

Re: [CentOS-devel] Centos 7.i686 & PPC?
by Gabor Zele 26 Dec '14

26 Dec '14

Can you give some hints on the powerpc port, too? I've found a spare Power6 server, and would like to do something useful with it. Gabor ----- Eredeti üzenet ----- Feladó: "Karanbir Singh" <mail-lists(a)karan.org> Címzett: centos-devel(a)centos.org Elküldött üzenetek: Péntek, 2014. december 26. 12:24:23 Tárgy: Re: [CentOS-devel] Centos 7.i686 On 25/12/14 16:54, Bob Lightfoot wrote: > Dear Devs: > I have been reading this mailing list since C7 came out and of > late have not seen much progress on C7.i686 aka 32 bit. I don't see a > SIG for it on the Centos Pages. I am wondering has the idea been > dropped or where does it stand? the larger goal is to let this effort be user-led, so starting up a SIG might be a good way to go here. I know that the original bootstrap had most of the builds done - and Andreas ( assited by others ) had gotten most of the bits done. There would be a need to run the updates, and then also identify what portion of the distro is not going to make it to i686 at all. The rest from there should be easy... As I did with the powerpc effort, happy to host a i686 specific google hangout where I can walk people through the build process, and what they need to do in order to affect builds in the centos buildsystem. - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ CentOS-devel mailing list CentOS-devel(a)centos.org http://lists.centos.org/mailman/listinfo/centos-devel

1 0

CentOS SCLo SIG sync-up meeting on #centos-devel (2014-12-17)
by Honza Horak 19 Dec '14

19 Dec '14

WG meeting will be at 16:00 UTC (11:00 EST, 17:00 Brno, 11:00 Boston, 1:00+1d Tokyo, 2:00+1d Brisbane) in #centos-devel on Freenode. = Topics = * current status * prefix for packages in upstream and downstream SCLs

3 4

deliverable infra for the ci.centos.org effort
by Karanbir Singh 18 Dec '14

18 Dec '14

hi, Over the last few weeks I've been talking with a few projects who are interested in coming onboard to consume the ci.centos.org infra. and based on those conversations, keeping in mind what sort of hardware we have in place and coming up : it looks like were going to need an abstracted api layer between the ci interface and the test hardware itself. As a bootstrap this means jenkins jobs will need to 'request' a machine instance from this middleware api ( lets call it duffy ), once the machine instance comes up, it will need to login or use a preseeded jenkins agent inside the instance to run the job. once the tests are done, we can optionally also collect the artifacts and then let duffy know ( which can then either recycle, or shutdown or rebuild or whatever ). With that in mind, duffy needs to implement atleast the following calls: + requesting new machine for <user> + list of allocated machines for <user> + 'done' with machine for <user> within the duffy mechanism we need to implement a way so the user gets the same'ish platform everytime ( ie. if they are using the intel machines, they should always get the intel machines ), and also make sure we stress every machine in the cluster. The second aspect we need to implement here is machine types. We clearly want most of the people to use baremetal and stress the machines as hard as they can ( with the aim that they deliver tests on a platform that looks most like the user machines will, and also so that they can be 'done' really quick ). However, we are also going to need, for some small numbers, Virtual Machines for some of the tests to run on. There are some use cases where the test suites actually expect VMs instead of physical machines, and we would need to cater for those. Metadata around what type of machines is being requested ( VM or baremetal ) could be something sent to duffy in the request for new machine. Finally, how i envison this as running is that duffy can just be a thin python script running behind bottle.py or flask, backed by some db to store audit trail etc, and executing the tasks using ansible cookbooks. that way we dont need to reinvent the whole interface access to the SeaMicro machines nor whatever Virtualisation environ we end up using for the VM's. regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

2 1

Cloud SIG meeting in one hour
by Kushal Das 18 Dec '14

18 Dec '14

Hi, We will be having our Cloud SIG weekly meeting at 3pm UTC on #centos-devel today. See you all there. Kushal -- Fedora Cloud Engineer CPython Core Developer Director Python Software Foundation http://kushaldas.in

1 0

NFV SIG - draft proposal for comment
by Dave Neary 17 Dec '14

17 Dec '14

Hi everyone, I would like to propose a Network Function Virtualization SIG in CentOS. The entire proposal is below, please respond here with comments, questions, or expressions of interest. I am interested in recruiting steering committee members both from the CentOS project and from OPNFV. Thanks, Dave. ================================================================ NFV SIG proposal NFV (Network Function Virtualization) is revolutionising the telecommunications industry. Telcos are moving to replace specialised telco hardware with virtual machines running on elastic infrastructure as a service. As a result, new telco services can be developed and deployed as "cloud native" applications, building on open source components. The CentOS NFV SIG will provide a CentOS-based stack which will serve as a platform for the deployment and testing of virtual network functions (VNFs). The initial core of the stack will be recent OpenStack packages, using the OpenDaylight SDN controller and Open vSwitch for network virtualization, DPDK for dataplane offload, Ceph for storage virtualization, and libvirt and QEMU/KVM for compute virtualization. The components of the stack will be those defined as being part of the OPNFV (Open Platform for NFV, http://opnfv.org) project. Virtual Network Functions (VNFs) running on the platform perform network node operations (firewall, IDS, NAT, load balancing, etc) and telecommunications services (voice and data services). ## Goals * Provide a vehicle for CentOS users to deploy an OPNFV compliant software stack and open source virtual network functions * Enable the packaging and integration of selected patches and versions of components to satisfy performance constraints of NFV use-cases * Provide documentation and tools that can be used to deploy the stack on a cluster of physical hosts * All code and component projects will be under OSI-approved licenses. ## Mailing List and Communication Work for the NFV SIG relevant to CentOS build systems, etc. will take place on centos-devel. Work related to which components and packages shoul dbe included will take place on the OPNFV project's mailing lists. ## SIG Membership The NFV SIG will have a steering committee and committers. New committers and steering committee members are appointed by the steering committee. The make-up of the steering committee is to be decided. Committer privileges, once earned, do not expire unless revoked by the steering committee. The steering committee will appoint a chair to interface with the CentOS Board. ## Meetings The NFV SIG will initially meet weekly until all pieces are in place for regular releases, then as needed. ## Roadmap and (Action) TODO List * Define package set * Establish builds * Define deployment tool and reference deployment architecture * Establish test / QA processes * Define release cadence and criteria ## Further Info * OPNFV (http://opnfv.org) * ETSI NFV ISG (http://www.etsi.org/technologies-clusters/technologies/nfv) * OpenDaylight: (http://opendaylight.org) * OpenStack: (http://openstack.org) ================================================================ -- Dave Neary - NFV/SDN Community Strategy Open Source and Standards, Red Hat - http://community.redhat.com Ph: +1-978-399-2182 / Cell: +1-978-799-3338

2 1

docker 1.4.0 available (fixes multiple CVEs)
by Lokesh Mandvekar 16 Dec '14

16 Dec '14

Docker users, please upgrade to v1.4.0: http://cbs.centos.org/koji/buildinfo?buildID=239 This version fixes CVE-2014-9357 https://access.redhat.com/security/cve/CVE-2014-9357 CVE-2014-9358 https://access.redhat.com/security/cve/CVE-2014-9358 CVE-2014-9356 https://access.redhat.com/security/cve/CVE-2014-9356 Ping me if any issues. Thanks! -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD

2 1

Re: [CentOS-devel] When anyone has plan to have this patch to CentOS 6.5?
by Subscribe Ling 16 Dec '14

16 Dec '14

I have opened a bug here and hope get response ASAP. https://bugzilla.redhat.com/show_bug.cgi?id=1154747 Thank you, *Johnny!* *Paul*

3 4

Shipping Build Tools in one of the CentOS Repos
by Brian Stinson 15 Dec '14

15 Dec '14

Hi All, I would like to start a discussion on where/how to ship the package building toolchain. Most of these tools shipped in EPEL, but deploying them to one of our repos would allow us to maintain our own patches if necessary and would eliminate any dependencies on 3rd party repositories for our core tools. I propose that the following packages be released into CentOS-Extras when they are ready: Package Primary Contact/Maintainer ======= ========================== centpkg bstinson GitPython bstinson koji alphacc python-async bstinson python-gitdb bstinson python-smmap bstinson rpkg bstinson To support this, I also propose that the appropriate 'extras' build targets be created (or that we designate existing tags) in the CBS. Things we should discuss: 1.) Some of the tools (koji especially) will require config customization, what is the best way to handle that? 2.) What should the testing -> release process look like after a koji build is done? Cheers! Brian -- Brian Stinson bstinson(a)ksu.edu | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk

3 7

CBS/Infra Meeting 15-Dec-2014 14:00 UTC
by Brian Stinson 15 Dec '14

15 Dec '14

Hi All! Every other week we get together to talk about the status of the CentOS Community Build System[1]. We will be meeting on 14-Dec-2014 at 14:00 UTC in #centos-devel on freenode. Agenda: #info Topic: Status Updates #info Subtopic: Centralized Authentication #info Subtopic: Koji/Repos #info Subtopic: Centpkg (Ready for testing!) #info Topic: Building a package to provide the koji client config & cbs binary? #info Topic: Open Floor Cheers! Brian [1] http://cbs.centos.org/

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel December 2014