devel

devel@lists.centos.org

2 participants
4653 discussions

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

Storage SIG Meeting 12-Dec-2014 15:30 UTC
by Lalatendu Mohanty 15 Dec '14

15 Dec '14

Greetings All! We have been working on Storage SIG for sometime now. We think it is time to get together with the community, talk and discuss about Storage SIG [1]. We will be meeting on 12-Dec-2014 15:30 UTC in #centos-devel on freenode. Agenda: #info Topic: Status Updates #info Subtopic: GlusterFS #info Subtopic: OpenAFS #info Subtopic: Ceph #info Subtopic: SCST in Storage SIG? #info Open Floor _/Minutes from Previous meeting:/_ highlights from this meeting: * Lala offering to take up slack since Patrick is busy and take over running meetings moving forward -- to propose a meeting date/time slot on centos-devel list -- to establish where the meeting to take place ( most people seem to like irc and therefore #centos-devel might be an option ) Status Checks: * gluster is ready to move into testing, BLOCKED ON: sign and release process being implemented * openafs is making progress, using Fedora COPR for builds. Lala to interface with Andrew and JBillings to get them setup with koji access --- for now, build via SRPMS since git -> koji is not quite 100% --- openafs also needs conversation and consideration around building kmod's for multiple kernel versions, and to build/rebuild on every kernel release ( speak to Thomas, Mike and buildsys group for feedback ) --- openafs is not tested client + server side, contributors feel there should be -some- testing on both sides before we pass along confidence in builds to users Other * SCST folks are keen to join the effort, KB to introduce them into group [1] http://wiki.centos.org/SpecialInterestGroup/Storage Thanks, Lala #lalatenduM on Freenode

2 4

RFC: OCaml SIG
by Jon Ludlam 13 Dec '14

13 Dec '14

Hi all, I'd like to propose a new SIG for the OCaml language. OCaml is an industrial strength programming language supporting functional, imperative and object-oriented styles. It has in recent years seen a marked increase in development activity, particularly in the compiler itself [1], core libraries [2] and developer tools [3]. Many of these newer libraries and features are already dependencies of a number of large upstream projects [4]. The version of OCaml in CentOS 6 is quite old (3.11.2, released in Jan 2010), and even that in CentOS 7 is fairly old (4.00.1, released in October 2012). I see the OCaml SIG providing the current stable compiler (4.02.1 at time of writing), and a selection of useful libraries and developer tools. This could then be used as a basis for other applications or SIGs to build upon - for example, it would make CentOS a good platform for building Unikernels [5] and it would be helpful in getting the Xapi Project suite of daemons [4] into one of the virtualisation/cloud SIGs. We actually already have a number of specs that are built for CentOS 6 which could make a good starting point [6]. A number of people have already agreed that they are interested and may be able to help (all CC'd): >From OCaml Labs (http://www.cl.cam.ac.uk/projects/ocamllabs/) - Anil Madhavapeddy - Thomas Gazagnaire >From Jane Street (https://www.janestreet.com/) - Yaron Minsky - Dominick LoBraico >From Citrix (https://www.citrix.com/) - Me - Euan Harris >From OCamlPro (http://www.ocamlpro.com/) - Louis Gesbert Comments? Jon [1] GADTs, record disambiguation, PPX extensions, immutable strings, etc. [2] ocaml-ctypes, Jane Street Core, the openmirage.org suite of libraries, etc. [3] opam, merlin, utop, etc. [4] https://github.com/xapi-project and http://ocsigen.org/ [5] http://queue.acm.org/detail.cfm?id=2566628 [6] https://github.com/xenserver/buildroot

7 20

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