devel

devel@lists.centos.org

18 participants
4604 discussions

oVirt and CentOS Cloud SIG
by Doron Fediuck 14 Jan '14

14 Jan '14

Hi guys, on behalf of the oVirt project, happy to join the community and we'll be happy to help where possible. Cloud SIG seems very relevant to oVirt. We're looking forward to assist with oVirt support as well. We have some CentOS fans in the oVirt community, so this should work well for everyone. - Currently we have our live oVirt [1] built using CentOS. So having you guys reviewing it would be beneficial. - For the standard el platform, we need some help with dependencies. Here's a short list which we would like to see go in over & above 6.5 * qemu-kvm compiled with RHEV flags * Support of librbd, libgfapi in qemu-kvm & libvirt, including sanlock & kernel modules * Network namespaces, VXLAN, GRE support in the IP stack (kernel through iproute, dnsmasq, etc) * The cloud-init version being used in RHEL 6.5. * Support of cgroups * selinux policies * Anything else you may be aware of. We'll probably find some more things on the way, but this would be a good start ;) Any suggestions from your side or things you'd like help with? Doron Fediuck [1] http://wiki.ovirt.org/OVirt_Live#oVirt-Live-1.1.iso_-_Oct_14th_2013

2 1

Documentation SIG
by Philip Mather 13 Jan '14

13 Jan '14

Has there been any interest or progress in the suggested Documentation SIG? -- Regards, Phil

4 3

A format request to create a Eucalyptus Special Interest Group
by Greg DeKoenigsberg 13 Jan '14

13 Jan '14

Hi folks. As I understand the "variants" proposal as it exists currently: http://www.centos.org/variants/ ...I think that the Eucalyptus installer, which relies upon CentOS currently, would do well as a variant. Which means that I would like to formally request the formation of a Eucalyptus SIG, according to protocol here: http://wiki.centos.org/SpecialInterestGroup So let me go through the requirements, one by one. * The topic for the group must be related to CentOS, or a use scenario for CentOS We build Eucalyptus, a cloud infrastructure application, around CentOS and have for 3 years now. We have an installer that is derived from Anaconda. We've sponsored CentOS events, and we deliver CentOS images to our users. Our packages are currently in a standalone repository, but we would be happy to merge these into whatever CentOS repository emerges (EPEL? Some new version of EPEL? CentOS core itself? I'm unclear on where this sits currently.) * There must be adequate control and feedback into the CentOS community Happy to discuss what this means to members of the CentOS community. * Generally, all communication as to the work of the SIG should be public, understanding that sometimes a matter may need to be private; in such cases, please consult with the Devteam member out of band of the SIG Happy to do business on a centos-eucalyptus mailing list. * All code produced within the SIG must be compatible with a FOSS license presently used by CentOS; if a new license is wanted, again, please consult with the Devteam member All code is GPL or Apache. * All documentation produced within the SIG must be compatible with the license of this wiki Happy to do that. * We would expect teams to be watchful of general CentOS directions from the Devteam It would be a great advantage to have help from the Devteam to do this. * At least one member of the SIG, who need not be the lead, needs to be a member of the CentOS Devteam. We are not trying to enforce any moderation, however, we feel that the actions of each SIG using CentOS resources needs to have visibility to the Devteam Happy to work with anyone on the Devteam for this. How do we proceed? What discussion needs to take place, and who can say yes to move this request forward? --g

5 14

Unified Cloud SIG
by Rich Bowen 13 Jan '14

13 Jan '14

There seems to be some consensus in various different threads that what we need is a single consolidated Cloud SIG effort, and decide, over time, if it's sensible to split into project-specific SIGs. Easier to start consolidated than try to figure out how to merge later. For those of you not following all of the various threads, here's some high points: Dave Neary says: What I would like to see is a CentOS stack which allows all of the cloud storage, networking, virt management and IaaS projects to show themselves in a good light - we will need newer stuff that isn't available in RHEL 6 to do so (and the sam will doubtless happen during the RHEL 7 release cycle), and it makes sense for us to talk & share the burden of supporting those newer components on top of core CentOS. Karanbir says, in response to me: On 01/10/2014 02:36 PM, Rich Bowen wrote: > I'd love to see a "choose your own cloud adventure" LiveCD variant, > where one could easily compare, OpenStack, Eucalyptus, CloudStack, > OpenNebula, etc., either side-by-side, or as options during the startup. > That would be quite cool. Technically, if we can get nested virt going, the livecd need only be a bare min CentOS6 install, with VM's that run complete cloud instances inside it. That would also sort out the massive pain of network setup, since we could make some levels of predictions on what the state is on the host. In a few days time, we should have the live media churn process going, this might be an interesting PoC to start with. Sebastien Gosaquen says: My personal view is that it would seem strange to have one SIG per project, a single cloud SIG will require coordination efforts amongst project to agree on a somewhat common framework for build. We could probably start with a single cloud SIG to discuss and identify requirements/issues and then see if a split is necessary. Does this seem a reasonable approach to everyone as a way forward? -- Rich Bowen - rbowen(a)redhat.com OpenStack Community Liaison http://openstack.redhat.com/

1 0

Cloud SIG interest from CloudStack
by Sebastien Goasguen 13 Jan '14

13 Jan '14

Hi, First, congrats to the centos community on the recent development. Reading the call for SIG, there is definitely interest from CloudStack to participate and create a ClouStack centOS variant for both instances and head/hypervisor nodes. Our default image template is already a centos template and our best quick start guide is based on CentOS. We also have a community run yum repo for all our packages. I see interest to create a Cloud Image for CloudStack clouds as well as creating variants for our management server and our hypervisor setup. I will be at the Dojo on January 31st and would be happy to discuss further. Cheers, -Sebastien Apache CloudStack PMC member

3 3

NethServer as CentOS Variant and SME SIG Proposal
by Alessio Fattorini 13 Jan '14

13 Jan '14

Hello everybody, my name is Alessio Fattorini and I'm part of a team of FLOSS developers that is working on a project named NethServer. We’d like to share with you our experience and our ideas for the future developments. You could think of NethServer as CentOS with some extra packages, particularly a powerful and extensible web interface that simplifies common administration tasks. NethServer is for the sysadmin who appreciates the effectiveness of a user interface which saves time compared to direct configuration file modification and for users who want to approach CentOS without having Linux skills. We didn't reinvent the wheel, NethServer is a partial rewrite of the original SME Server code, focusing on maintainability, extensibility and standard compliance with CentOS. We think we achieved those goals with: * A dynamic, streamlined user-interface * Standard components, tested widespread configurations * Minimal differences with upstream (CentOS) * Easy installation * Simplified administration tasks * Use of templates and text-based db for configuration (configuration will always be consistent) * Built-in extensibility NethServer architecture explicitly supports developers by making it easy to install and integrate additional software. We quickly added some pre-configured modules, installable with a “single click”, for example: LAMP framework Caching + filtering web proxy (with SSL filter) SOGo Groupware Mail Server with Antispam and Antivirus VPN (OpenVPN and IPsec/L2TP) Firewall (Shorewall) Intrusion detection (Snort) ownCloud More informations could be found on the official project website: www.nethserver.it. As soon as we read about CentOS variants, we have developed the idea of releasing NethServer as a CentOS variant and we are thinking of a SME SIG, a group exploring the needs of small enterprises (we are based in Italy, where the vast majority of enterprises is really small). According to you, does NethServer meet the basic requirements? We’ll be at Brussels Dojo and FOSDEM and we'd love to discuss directly with you our ideas. Cheers, Alessio and the NethServer team

10 16

the MRG setup
by Karanbir Singh 11 Jan '14

11 Jan '14

hi, the mrg stack has been in testing for quite some time, and there has been some work around the edges by users to test and make sure that its suiteable for what they are doing : by and large the response has been positive, even if private. I'd like to propose moving it to a more released state on x86_64. Thoughts ? Also, by definition this does not seem to be the sort of thing that the Core SIG should take up, but given that we have no other build route at the moment it might be something we need to handle there ( for the time being ). Anyone want to come help populate the MRG interest group a bit ? Regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

1 0

[REQUEST] Create the CentOS Hosting SIG
by Jim Jagielski 11 Jan '14

11 Jan '14

One of the proposed Future SIGs (http://wiki.centos.org/SpecialInterestGroup) is the Hosting (or "Web Hosters") SIG. Since Web Hosters are one of the key and core users of CentOS, this seems like a SIG that should be started sooner, rather than later :) I'd like to propose that such a SIG be started. Following the proposed requirements listed: * The topic for the group must be related to CentOS, or a use scenario for CentOS. This is an obvious alignment. As noted above, CentOS is a popular choice for Web Hosters and ISPs. -- * There must be adequate control and feedback into the CentOS community Such feedback would be vital to the success of this SIG. -- * Generally, all communication as to the work of the SIG should be public, understanding that sometimes a matter may need to be private; in such cases, please consult with the Devteam member out of band of the SIG. My preference would be to use public, archived lists for all development and communication. -- * All code produced within the SIG must be compatible with a FOSS license presently used by CentOS; if a new license is wanted, again, please consult with the Devteam member My preference that all new code and development be under the ALv2 license. -- * All documentation produced within the SIG must be compatible with the license of this wiki Agreed. -- * We would expect teams to be watchful of general CentOS directions from the Devteam My expectation would be an extremely tight feedback loop between the Hosting SIG and the general CentOS direction. -- * At least one member of the SIG, who need not be the lead, needs to be a member of the CentOS Devteam. Agreed. I welcome suggestions. A bit about myself: Web Hosting is near and dear to my heart, having created a small ISP/Web Hosting business and helping develop the Apache HTTP server. I've been known to speak and write about web hosting. I am currently employed by Red Hat, Inc. but this request is not being made formally with my Red Hat hat on.

11 15

Repositories in new ecosystem and Desktop version
by Ljubomir Ljubojevic 10 Jan '14

10 Jan '14

Hi. Repository policy will define how new ecosystem works, so I thought throwing in few suggestions and see what can be applied. Will one of CentOS variants/SiGs also include something like Desktop/Laptop/Workstation variant that will provide out-of-the-box EPEL and ElRepo packages, mostly drivers? I see lack of (network) drivers on installaion DVD as a main problem for newbies that chose CentOS as their workstation. Something in line with CentOS + ElRepo drivers on the same DVD + current release/.repo packages for EPEL, and maybe other 3rd party repositories. I am trying to image how this would be best to execute, and the first thing that comes to mind is this: 1. yum-plugin-priorities should become mandatory for all CentOS Variants including Base distro. 2. All .repo files should have "Enabled=" and "Priority=" lines for every repository, so it is easier for a user (or SiGs) to set things up as he likes it. 3. There should be debate and consensus (with 3rd party repositories!) how to decide which priority numbers will be assigned to which repository (including base/os and others from current CentOS project) so that that repository system in EL ecosystem is much easier for re-purposing of the already installed systems. Priority for CentOS-Core should be enough to insert 2 repositories above it, and system should use rounded numbers (10,20,30,40 or better 20, 40, 60, 80) for repositories, so there is room to insert additional repositories when/if they appear. The way I see it, there can be two paths to building Variants. * First is to create separate (mostly symlinked) repositories for each Variant. * Second is to use priorities wisely so that packages that need to replace ones from CentOS-Core are placed to a repository that has higher priority (lower number) in "Priority=" line. So if you want to convert CentOS-Core system to CentOS-Desk you only need to ADD centos-desk-release package and update the system. I think second path is much better for 3rd party repositories that will provide things that are not opensource like non-opensource codecs (gstreamer, vlc, ...) without a need for complicated editig of .repo files. Biggest benefit from this will be for newbies that are currently frustrated with lengthy process and rather chose Debian based systems like Ubuntu and Mint for their first Linux distros. Consequence is once they learn Debian way they are not really interested to additionally learn CentOS/RHEL way to run CentOS servers. As a person that is some 5 years in newbie support of CentOS/RHEL (currently main admin on official CentOS Facebook group with 6.000 members), main problem to attracting newbies/future admins is complicated addition of Desktop packages via 3rd party repositories. Sometimes I even give up on explaining total newbie how to add all those extra repositories. 4. Tool for easier management of various repositories should be developed/adjusted existing? so that newbie from GUI (or CLI) can move individual repositories up/down and turn them on/off to adjust them as they see fit, then save various options as profiles (some made by CentOS Project?) and easily switch them (or temporary apply them for current terminal?) to accomplish various tasks. Yum devs could probably help with this. 5. There should be additional "Downloaded" repository that would carry latest packages that do not have their own yum reposiroties like VirtualBox, LibreOffice, Skype, shorewall, flash, etc. I believe an arrangement with providers of those binaries could be achieved for themselves to upload latest versions so users are able to installed them without need to download and apply them manually. Same method could maybe be used to carry a subset of some other repositories, provided as-is, like latest Firefox/Thunderbird from Remi repository for those that do not care about compliance to standards of government datacenters (or whatever it is called). A mechanism for approval of those packages can be carefully designed, but I think they are also an important part of Desktop userbase. At the moment, "downloaded" section in my repository caries about 200 packages manually downloaded (or copied from) from other places, like codecs with accompanying requirements etc. Even tho I do not update them very often, I have them on-hand when I install new system, just a yum command away. -- Ljubomir Ljubojevic (Love is in the Air) PL Computers Serbia, Europe StarOS, Mikrotik and CentOS/RHEL/Linux consultant -- Ljubomir Ljubojevic (Love is in the Air) PL Computers Serbia, Europe StarOS, Mikrotik and CentOS/RHEL/Linux consultant

2 4

Interest in a 32bit tree of the upcoming CentOS7?
by Andreas Thienemann 10 Jan '14

10 Jan '14

Hi, I'm in the process of building myself a 32bit tree of the RHEL7 beta as I do have a few x86 machines I am not ready to retire yet. Now that CentOS is all open and community etc. I was wondering if there'd be some interest for me to rebuild the results within the CentOS project and turn it into an official release long term. My unfinished work so far is based on an older RHEL5 buildsystem I still had lying around but I am happy to switch this to the CentOS toolstack if there's interest. This would mean filing off the serials, removing trademarks and all these things which I hadn't planned on doing initially but on the other hand, it should be very easy doing that benefitting from the regular CentOS work on these topics. Is anyone else interested in a i[36]86 build of CentOS7 and would be willing and able to contribute to it? Or is x86_64 the only release really needed? If there's some interest, I am sure this could be turned into a nice project. cheers, Andreas

9 9

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