devel January 2014

devel@lists.centos.org

96 participants
59 discussions

Repository structures for SIG and variants in the future
by Jim Perrin 05 Feb '14

05 Feb '14

As part of opening up the possibilities for SIGs and Variants within the CentOS ecosystem, we need to give some thought to how repositories should be structured so that different can cooperate with each other. What we have discussed in the past, and what I'd like to propose to the -devel community, is that we adopt a page similar to the KDE framework. The way I envision this working is as follows: - Tier 1 repositories: Adds packages only. These repos may not update or replace anything in the core distribution. (Example: EPEL) - Tier 2 repositories: These repositories may provide provide packages that update or otherwise enhance packages in the base distribution, but otherwise maintain compatibility. (Example IUS - Tier 3 repositories: These repositories contain packages that conflict with software inside the core distribution. This would be Xen4CentOS for example, which replaces the kernel, and adds in xen functionality. Each tier may choose to rely on dependencies from repositories in the tier above it, but not the other way around. For example, the tier 3 Xen4 repository could choose to rely on packages from a tier1 like EPEL, or a tier2 like IUS. However a tier1 or tier2 could not rely on a tier3. A good real-world example of this would be rpmfusion's dependence on the EPEL repository. The other aspect of this that needs to be discussed is package duplication. For example, several of the proposed SIGs have some overlap in their packages. Would the preference here be that each SIG/Variant maintain their own version of the package, or should there be a common package set established? Both methods fit into the model described above, and both have pros/cons associated. What does the community think about this? -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77

11 51

Re: [CentOS-devel] CentOS 7 Artwork
by Tuomas Kuosmanen 02 Feb '14

02 Feb '14

On Wed, 2014-01-15 at 10:54 +0100, Marcus Moeller wrote: > Hi all. > > Here is my proposal artwork for the upcoming CentOS 7 release. Nice! Marcus, I wanted to share this: The stars picture reminds me of this one I did: https://dl.dropboxusercontent.com/u/2730444/foss/spaceflight.png Pretty nice co-incidence and a common theme we had by accident! =) This was one of the ideas I had while I was helping the guys with the website. (I subscribed after Karanbir showed me your mail in the archives, sorry if I messed up the mail thread headers) /Tuomas

4 5

FreeIPA functional testing
by James Hogarth 01 Feb '14

01 Feb '14

Hi all, The initial commit I made (not carried out pull request just yet) does the following: * Installs IPA packages * Does automated basic configuration of server * Verifies kerberos tickets being issued for host/admin user * Tests adding a user (and checks that the initial password is expired plus the change) In the next few days I'm intending to add: * Test adding a service and getting a keytab and certificate for that service * Test adding a host * Test adding DNS zone and records * Test reloading bind (regression test for RHBA-2013-0739) * Test sudo rules configured via IPA * Test deleting all the stuff added above After that I'll issue the pull request... Next stage subsequent to the server tests working would be client side to tests registration against the IPA server itself... Is there anything else that anyone can think of that would be useful to have in the IPA test suite? Cheers, James

1 1

CentOS Interoperability SIG
by Clint Savage 29 Jan '14

29 Jan '14

One of the major values of the EL rebuild ecosystem is the ability to interoperate, or the ability to fork from the upstream. This provides purpose in many ways, choice being the most heralded. Since the CentOS community has teamed up with Red Hat to allow for Special Interest Groups to join them, it seems that there might be a bit less of an ecosystem available. The goal of the Interoperability SIG is to ensure that the ability to fork and rebuild still exist. Our communities already exist outside of the CentOS community purview. They are currently the GoOSe Project[1] and the Ascendos Project[2]. This shared community will serve as a "reference implementation", yet will still be operated and marketed as a product and community separate from CentOS. Consider it something of CentOS "embassy" of sorts. It would seem that this SIG could be construed as contrary to the goals of the CentOS project. However, we believe there is value added to the CentOS project. We are interested in improving the CentOS community in at least a few ways. * Providing feedback and collaboration on common issues. Including, but not limited to, reporting bugs, providing patches, discussing packaging techniques, rebuilding variants, QA, ISO building, etc. * Collaboration on documentation of the rebuild process, rebranding of documentation, providing new documentation, etc. * Build or maintain tools to ease rebranding of upstream packages as to ease adoption by companies who build upon and release software based on CentOS. * Providing tools to help monitor statuses of builds, repositories, releases, etc. Whether they be part of the CentOS community or otherwise. With these goals in mind, we'd like to formally request an Interoperability Special Interest Group within the CentOS community. Please let us know how to further proceed. Cheers, Clint Savage Lead Developer, GoOSe project 1 - http://gooseproject.org (#gooseproject on irc.freenode.net) 2 - http://ascendos.org (#ascendos on irc.freenode.net)

10 18

Wider conversation around process and delivery for the Cloud SIG
by Karanbir Singh 29 Jan '14

29 Jan '14

hi, I'd like to invite everyone wanting to contribute to the Cloud SIG and representing a project outside centos.org to come along for a chat on google hangout at the CentOS OfficeHours 23rd Jan 2014 @ 16:00 UTC. Because we only have a few slots for people to talk, I've shortlisted these folks: OpenStack: Mike Burns, Dave Neary, Rich Bowen Eucalyptus: Greg DK OpenNebula: Jaime Melis CloudStack: Sebastien Goasguen oVirt: Doron Fediuck If you want to be on this list, please get in touch. If you are on this list but cant make it at that date/time, please nominate someone else in your place and let me know their email address so I can notify them of the url to join. This will be a video/audio session and will be publicly broadcast over youtube/hangouts on air; the recording of the session will be available immediately after. Bonus cookies for everyone who turns up in their project tshirts! You can see what time that is on your local timezone at this url : http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140123T16&am=30 About the session: - Plan on an hour - Every project should do a few minutes worth of a pitch about what they would like to see as a good first goal and a good longer term goal. - We can then discuss delivery mechanis, and how the forward maintenance of the projects payload is going to work ( essentially, workout how the rpms will map to os/ and updates/ ) - Consider the workflow from git.centos.org ( KB to do a 5 min demo ) Regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

12 17

Chromium
by Logan McNaughton 29 Jan '14

29 Jan '14

This is just a ping for whoever manages http://people.centos.org/hughesjr/chromium/6, wondering if you could update to Chromium 32?

4 3

mirrors for contribution paths
by Karanbir Singh 29 Jan '14

29 Jan '14

hi At the moment, we use gitorious.org for inbounc test contributions, but we've adopted github for some of the newer content going into git.centos.org with manual bridges to/from git.centos.org in both cases. I just want to make sure we are doing what people find easiest, and then we do the same thing all around, with that in mind should we : - have mirrors for content on both github.com and gitorious.org - mirror everything to gitorious.org only - mirror everything to github.com only ofcourse, with ACL's coming up into git.centos.org - there will be plenty of opportunity to work directly inside git.centos.org ( with post-recv triggers pushing to whatever wherever we mirror the repos to ). - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

1 0

migrating artwork to git.centos.org
by Jim Perrin 29 Jan '14

29 Jan '14

So, running this by the list for opinions: We're going to be moving the Artwork SIG from its current home at https://projects.centos.org/trac/artwork/ (svn) to a new home on git.centos.org. In this transition, we'd like to clean up some of the older content that's no longer used. The easy way to do this would be to pull current svn repo, strip out the legacy content, and then upload clean into git. While this is my preference, the drawback is that it removes any commit history for the project prior to the cutover date. The benefit is we have a clean, and more importantly, current starting point to work from for the seven beta build, which we'd like to start putting out in public. Are there objections to this approach? -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77

3 4

Cloud-init for CentOS?
by Nux! 28 Jan '14

28 Jan '14

Hello, Can someone more involved with the Cloud SIG advise on how to use cloud-init in such a way that it does not violate the SIG rules? I.e. please add it to one of the CentOS repos so we can use it "legally". :-) The purpose is including it in "official" Cloudstack CentOS images. Regards, Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro

11 34

Cloud Instance SIG Hackathon @ CentOS Dojo 31st Jan 2014
by Karanbir Singh 28 Jan '14

28 Jan '14

hi, We are organising a hack session to try and build, test and deliver a set of CentOS-5/6 32bit/64bit images usable by various onpremise cloud setups. This email aims to give everyone an overview of what to expect on the day, so we can jump right in on the day and get productive. This is a bit of a wordy email, so feel free to skip details - I will have most of the important stuff on paper to hand out on the day as well. The Hack session is expected to start just after lunch, and will run through to the end of the day ( ~ 17:30 ); On the day, I will have a local Wifi network with SSID DojoHackathon running at the time, everyone wanting to participate will need to get onto that. dhcp on the network will hand out 172.30.30.100 - 250 IP's. There is a gateway on .1 that will NAT requests to the upstream internet ( but I'm told its slow, so dont rely on it being there ). If anyone needs content to pull, please let either me or Johnny know, we will mirror it down before the event and make sure its on the mirror host on the network at the time. We are going to have : - CentOS 5/6 on both 32/64 bit x86 - EPEL 5/6 - EPEL-Testing 5/6 Various people representing projects have offered to bring pre-setup cloud infra on their laptops, thanks for that. Lets try and target everyone of those on the day. So far the list is : - OpenNebula - CloudStack - OpenStack ( the HPCloud edition ) - OpenStack ( the RDO edition ) A rather basic idea of what to expect in terms of infra/network on the day : http://bit.ly/1ffXr4G ; Workflow anticipated: - git.centos.org ( hosted locally ) will have the git repos that host kickstarts and metadata files that have some info around the kickstarts. - anyone can clone the git repos ( I will make sure its pretty clear as to what repo to get for what task, ideally there will only be one git repo with all the kickstarts ). - make changes / edits / push back to git.centos.org ( please ensure git user.name and user.email is sane ) - git post-recv triggers kick off the actual image builds on the image-builder node, which will then push the resulting file to cloud.centos.org ( both image-builder and cloud.centos.org mirrors will be hosted locally ). - cloud images from cloud.centos.org can then be downloaded and instantiated on the cloud infra people are running; - once satisfied that the image does everything that is 'required', git clone the t_functional repo, and run the test suite. PASS on that would indicate them that the image is good to ship. For the day, we will trim the test suite down to just the basic stuff that runs in 10 min or less. - Indicate pass with a comment in the metadata file and git commit which starts with 'RELEASEABLE ', git push. rinse & repeat for 32bit and 64bit. Worth noting here that the reason i have all the various components setup to work with real world urls ( faked by dnsmasq on the .1 machine ) is that post hackathon the exact same infra will go live on the same urls. With one major change : we will have little or no ACL's fon the git repos at the hackathon to make live easier and encourage participation. Post Hackathon, we'll need to establish a mechanism for people to request commit access. If we still have time at the end of the day, we can shoot to deliver something that works for vmware, ovirt and docker. I am still waiting to hear back from the Eucalyptus guys if someone from their side is going to be at the hack session. please note: all kickstarst and images will need to only consume content hosted in mirror.centos.org and epel ( or if you need something else, let us know before Wed 29th ). See you there, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

2 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel January 2014