devel

devel@lists.centos.org

5 participants
4677 discussions

GSoC and SIGs
by Karanbir Singh 10 Feb '15

10 Feb '15

hi As a part of the project we are going to try and get onto the GSoC program again this year. Jeff Sheltren and Karsten Wade have offered to do the work needed towards that goal. I've offered to help in short bursts with specific things as and when they need anything. One thing that would be good to get is : a list of the top 3 things every SIG would like to see done as a part of the GSoC effort; These are just idea, concepts and pending ToDo's SIG specific. Please send them to this list, and we can co-ordinate from there. When trying to put tasks together, try and estimate how long these are going to take and then divide them upto 4 to 6 weeks worth of a junior developers typical velocity. Typically, getting an accurate idea of task-time involves actually starting to do the work - but please dont go down that route as yet. A reasonable process for now would be to think about how long it might take you, just off the top of your head - and then multiply that by 3. That should cover the time it takes folks to get familiar with our process' and also the relative velocity of someone much junior doing the same piece of work. regards -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

3 2

conversations around CI.centos.org
by Karanbir Singh 10 Feb '15

10 Feb '15

hi, as we start onramping the initial projects into ci.centos.org, we are going to need a place to talk about the infra, the process, the actual testing and a find a place to send conversaitons where people need more info around the CICO effort. for now, I suggest we use the centos-devel list, and if volume of traffic grows - or if conversations become too site / role specific, we can move them to its own list as needed. regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

1 0

Suggestions for topics for the 16-Feb CBS/Infra Meeting (No meeting this week)
by Brian Stinson 10 Feb '15

10 Feb '15

Hi All, Our next scheduled Community Build System meeting is Monday 16-February 2015. Here is our usual agenda: #info Topic: Status Updates #info Subtopic: Centralized Authentication #info Subtopic: Koji/Repos #info Subtopic: Centpkg #info Topic: Open Floor If anyone has suggestions for topics, please let me know. I'll send an updated agenda before the meeting. If there's anything more urgent, we can get going here on the list or in #centos-devel on Freenode. Cheers! Brian -- Brian Stinson bstinson(a)ksu.edu | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk

2 1

infrastructure for doing C7 builds?
by Fred Smith 10 Feb '15

10 Feb '15

Hi all! I think I remember seeing postings about there being som infrastructure where people not officially affiliated with the project could submit jobs to be run, that would build C7 RPM packages for them. Am I all wet, do I misremember? I can't find, right now, emails on that subject, nor anything that leaps out at me on centos.org or seven.centos.org, which now seems outdates. Where else should I be looking? thanks! -- ---- Fred Smith -- fredex(a)fcshome.stoneham.ma.us ----------------------------- Show me your ways, O LORD, teach me your paths; Guide me in your truth and teach me, for you are God my Savior, And my hope is in you all day long. -------------------------- Psalm 25:4-5 (NIV) --------------------------------

3 2

setting up an emergency update route
by Karanbir Singh 08 Feb '15

08 Feb '15

Hi, At the end of the Dojo in Brussels, I had the chance to field the question to our contributor audience : how can we get security updates out to the user machines faster. At the moment, things are setup like any other distro or large open source content network is : we rsync in stages, and external mirrors pickup every 4 to 6 hours, some external mirrors pickup from other external mirrors. Net result is that for a given update, it can be upto 16 to 18 hours before we get a majority content sync in front of most users. In cases like the recent Glibc issue, 18 hrs can be a long time since the release ( remember, we already lag RHEL releases since our process starts once theirs ends ). There were a couple of ideas that came up in the conversation at the Dojo, and then in the following conversations over the entire Fosdem weekend. The two that seemed most likely, easiest to implement and perhaps most robust, involved a chunk of the load moving to mirror.centos.org for some period of time. These are : A) we setup a rapid update repo, that would be hosted on and run from mirror.centos.org exclusively. The yum repo definitions would still point at mirrorlist, however they would only expect centos.org urls in the baseurl stack from mirrorlist.centos.org; This would allow us to reduce the overall to-user-visibility in default centos linux installs to under an hour for content upto 250MB in size. B) integrate the mirrorlist backend with the release mechanism in centos linux, so when there is a new updates pushed, all updates are then delivered via mirror.centos.org for the next 24 hrs. After this period, traffic reshapes to be delivered from the external mirrors by default. The Key issue to note with (A) is that while we might push something to this rapid update repo, the same content will also be available in the regular updates/ repo. So once its starts showing up externally, traffic will naturally switch to using the updates repo from local mirrors ( using repo names and cost etc, we can influence repo priority where there is common content ). The second important thing to note here is traffic capacity : we can deliver upto 20 Gbit/sec in the US and EU from centos.org - and around 8 Gbit/sec for everywhere else. Given that we prefer to offload traffic to external mirrors at the moment, its hard to estimate what the overall capacity requirements will be. Ideally, drpms should/would help. Depending on how everyone feels around this, I'd like to go ahead and kick off implementation around this. Lets get it done before the next big security update comes through. Regards -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

11 26

a mainline kernel in centos repos
by Karanbir Singh 08 Feb '15

08 Feb '15

Hi, lots of people in various SIGs and user side projects are keen on bringing up a mainline kernel, that tracks upstream closer than the distro kernel does. I'd like to start a conversation around which kernel we might be able to maintain as a group, that also helps most people solve the problems they are looking at. 3.18 seems to be the stable-release at the moment, but given that 3.19 is just around the corner, should we try and aim for that ? regards -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

5 6

RFC: CentOS Extras & Plus SIG
by Tim Verhoeven 07 Feb '15

07 Feb '15

Hi, This is just a idea that I'm having and I'm looking for feedback. So that is why the RFC tag is in the subject ;) So the idea is to create a SIG that plays the role of coordinater/janitor for the CentOS Extras and Plus repos. With 2 goals in mind: 1. Allow people to contribute packages and patches to the mentioned repo's. Ideally people would own a package, but the SIG would also take on one-offs. I personally would like to contribute updated haproxy and python-spynner packages. 2. It the other SIG's want to this SIG can be the place to hand off common packages between the SIG's and do some coordination between the SIG's to make sure nothing breaks. So what do you think? Good idea, bad idea, suggestions, ... Kind regards, Tim -- Tim Verhoeven - tim.verhoeven.be(a)gmail.com - 0479 / 88 11 83 Hoping the problem magically goes away by ignoring it is the "microsoft approach to programming" and should never be allowed. (Linus Torvalds)

2 1

influence and impact instead of packagers
by Karanbir Singh 07 Feb '15

07 Feb '15

hi One key aspect to the proper functioning of our SIGs is the ability for people to reach out in user, contributor and advisor roles ( each of those is key, in decreasing levels of impact ). However, the way we are setting up right now is still very much driven by the idea of packagers and rpms in repos. For example, $project working off their github repo - delivering sources for a centos userbase should also have some level of influence over what goes in and out of the repos and how the repos are lined up ; just like any other SIG might. And components in a SIG should be able to impact components in other SIG resources. A more specific example locally within the ecosystem might be that Cloud SIG should have some expectation around what the VirtSIG is doing and the StorageSIG is doing without needing to be co-authors on packages. The same would be true for EPEL and other external repos that we might want to rope into a common pool at some point. Folks doing the consumption part of the components should have the ability to assert influence and impact on the providers backing the content. I have some ideas on how we can make this happen, but nothing that is simple nor straightforward in a complete cycle. The biggest challenge is in mindset down the contributor path. Maybe as a first step, we should consider having a common criteria on what is considered stable and what is considered releasable - without removing the ability for the SIG's and their hosted projects to still deliver a user story they want ( and ideally, in line with their ultimate upstream desires ). Thoughts ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

2 1

Gluster Updates for Storage SIG
by Karanbir Singh 06 Feb '15

06 Feb '15

The CentOS Storage SIG, has updated Gluster to 3.6.2 in the community testing repos. You can find more information on howto get started with this repo at : http://wiki.centos.org/SpecialInterestGroup/Storage/gluster-Quickstart The Following rpms have been updated: CentOS-6 i386/glusterfs-3.6.2-2.el6.i386.rpm i386/glusterfs-api-3.6.2-2.el6.i386.rpm i386/glusterfs-api-devel-3.6.2-2.el6.i386.rpm i386/glusterfs-cli-3.6.2-2.el6.i386.rpm i386/glusterfs-devel-3.6.2-2.el6.i386.rpm i386/glusterfs-extra-xlators-3.6.2-2.el6.i386.rpm i386/glusterfs-fuse-3.6.2-2.el6.i386.rpm i386/glusterfs-geo-replication-3.6.2-2.el6.i386.rpm i386/glusterfs-libs-3.6.2-2.el6.i386.rpm i386/glusterfs-rdma-3.6.2-2.el6.i386.rpm i386/glusterfs-resource-agents-3.6.2-2.el6.noarch.rpm i386/glusterfs-server-3.6.2-2.el6.i386.rpm x86_64/glusterfs-3.6.2-2.el6.x86_64.rpm x86_64/glusterfs-api-3.6.2-2.el6.i386.rpm x86_64/glusterfs-api-3.6.2-2.el6.x86_64.rpm x86_64/glusterfs-api-devel-3.6.2-2.el6.i386.rpm x86_64/glusterfs-api-devel-3.6.2-2.el6.x86_64.rpm x86_64/glusterfs-cli-3.6.2-2.el6.x86_64.rpm x86_64/glusterfs-devel-3.6.2-2.el6.i386.rpm x86_64/glusterfs-devel-3.6.2-2.el6.x86_64.rpm x86_64/glusterfs-extra-xlators-3.6.2-2.el6.x86_64.rpm x86_64/glusterfs-fuse-3.6.2-2.el6.x86_64.rpm x86_64/glusterfs-geo-replication-3.6.2-2.el6.x86_64.rpm x86_64/glusterfs-libs-3.6.2-2.el6.i386.rpm x86_64/glusterfs-libs-3.6.2-2.el6.x86_64.rpm x86_64/glusterfs-rdma-3.6.2-2.el6.x86_64.rpm x86_64/glusterfs-resource-agents-3.6.2-2.el6.noarch.rpm x86_64/glusterfs-server-3.6.2-2.el6.x86_64.rpm CentOS-7 x86_64/glusterfs-3.6.2-2.el7.x86_64.rpm x86_64/glusterfs-api-3.6.2-2.el7.x86_64.rpm x86_64/glusterfs-api-devel-3.6.2-2.el7.x86_64.rpm x86_64/glusterfs-cli-3.6.2-2.el7.x86_64.rpm x86_64/glusterfs-devel-3.6.2-2.el7.x86_64.rpm x86_64/glusterfs-extra-xlators-3.6.2-2.el7.x86_64.rpm x86_64/glusterfs-fuse-3.6.2-2.el7.x86_64.rpm x86_64/glusterfs-geo-replication-3.6.2-2.el7.x86_64.rpm x86_64/glusterfs-libs-3.6.2-2.el7.x86_64.rpm x86_64/glusterfs-rdma-3.6.2-2.el7.x86_64.rpm x86_64/glusterfs-resource-agents-3.6.2-2.el7.noarch.rpm x86_64/glusterfs-server-3.6.2-2.el7.x86_64.rpm This release fixes the following bugs. Below containt copied from GlusterFS upstream release mail [1]. 1184191 - Cluster/DHT : Fixed crash due to null deref 1180404 - nfs server restarts when a snapshot is deactivated 1180411 - CIFS:[USS]: glusterfsd OOM killed when 255 snapshots were browsed at CIFS mount and Control+C is issued 1180070 - [AFR] getfattr on fuse mount gives error : Software caused connection abort 1175753 - [readdir-ahead]: indicate EOF for readdirp 1175752 - [USS]: On a successful lookup, snapd logs are filled with Warnings "dict OR key (entry-point) is NULL" 1175749 - glusterfs client crashed while migrating the fds 1179658 - Add brick fails if parent dir of new brick and existing brick is same and volume was accessed using libgfapi and smb. 1146524 - glusterfs.spec.in - synch minor diffs with fedora dist-git glusterfs.spec 1175744 - [USS]: Unable to access .snaps after snapshot restore after directories were deleted and recreated 1175742 - [USS]: browsing .snaps directory with CIFS fails with "Invalid argument" 1175739 - [USS]: Non root user who has no access to a directory, from NFS mount, is able to access the files under .snaps under that directory 1175758 - [USS] : Rebalance process tries to connect to snapd and in case when snapd crashes it might affect rebalance process 1175765 - USS]: When snapd is crashed gluster volume stop/delete operation fails making the cluster in inconsistent state 1173528 - Change in volume heal info command output 1166515 - [Tracker] RDMA support in glusterfs 1166505 - mount fails for nfs protocol in rdma volumes 1138385 - [DHT:REBALANCE]: Rebalance failures are seen with error message " remote operation failed: File exists" 1177418 - entry self-heal in 3.5 and 3.6 are not compatible 1170954 - Fix mutex problems reported by coverity scan 1177899 - nfs: ls shows "Permission denied" with root-squash 1175738 - [USS]: data unavailability for a period of time when USS is enabled/disabled 1175736 - [USS]:After deactivating a snapshot trying to access the remaining activated snapshots from NFS mount gives 'Invalid argument' error 1175735 - [USS]: snapd process is not killed once the glusterd comes back 1175733 - [USS]: If the snap name is same as snap-directory than cd to virtual snap directory fails 1175756 - [USS] : Snapd crashed while trying to access the snapshots under .snaps directory 1175755 - SNAPSHOT[USS]:gluster volume set for uss doesnot check any boundaries 1175732 - [SNAPSHOT]: nouuid is appended for every snapshoted brick which causes duplication if the original brick has already nouuid 1175730 - [USS]: creating file/directories under .snaps shows wrong error message 1175754 - [SNAPSHOT]: before the snap is marked to be deleted if the node goes down than the snaps are propagated on other nodes and glusterd hungs 1159484 - ls -alR can not heal the disperse volume 1138897 - NetBSD port 1175728 - [USS]: All uss related logs are reported under /var/log/glusterfs, it makes sense to move it into subfolder 1170548 - [USS] : don't display the snapshots which are not activated 1170921 - [SNAPSHOT]: snapshot should be deactivated by default when created 1175694 - [SNAPSHOT]: snapshoted volume is read only but it shows rw attributes in mount 1161885 - Possible file corruption on dispersed volumes 1170959 - EC_MAX_NODES is defined incorrectly 1175645 - [USS]: Typo error in the description for USS under "gluster volume set help" 1171259 - mount.glusterfs does not understand -n option [1] http://www.gluster.org/pipermail/gluster-devel/2015-January/043617.html -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

5 7

Adding the NFV SIG to the wiki?
by Dave Neary 06 Feb '15

06 Feb '15

Hi, I noticed that the NFV SIG is not mentioned anywhere on the SIG page wiki: http://wiki.centos.org/SpecialInterestGroup What is involved in getting it added? I think it fits best in "Proposals not yet onboarded" - I am in the process of recruiting initial committers and working through potential issues packaging a key project, and expect to be in a position to propose builds very soon now. Thanks, Dave. -- 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

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