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
On 01/09/2014 11:57 PM, Greg DeKoenigsberg wrote:
Hi folks. As I understand the "variants" proposal as it exists currently:
thanks for going through the proposed mechanics!
How do we proceed? What discussion needs to take place, and who can say yes to move this request forward?
Because its something I am quite keen on, I'd like to take up working the devteam angle for the Cloud SIG.
The overall variant plan is a proposal and we had initially hoped to have had atleast one set of people from outside the project come through and offer to work the plan, creating the draft mechanics and working with us on the systems side to make it happen - we have 7 proposals already :)
Do any of the OfficeHours timeslots work for you : http://wiki.centos.org/OfficeHours if so, lets use one of those to thrash through the requirements, the proposal and setup a plan.
If we can get these things done next week, we can push to the board the week after.
- KB
On Thu, Jan 9, 2014 at 7:38 PM, Karanbir Singh mail-lists@karan.org wrote:
On 01/09/2014 11:57 PM, Greg DeKoenigsberg wrote:
Hi folks. As I understand the "variants" proposal as it exists currently:
thanks for going through the proposed mechanics!
How do we proceed? What discussion needs to take place, and who can say yes to move this request forward?
Because its something I am quite keen on, I'd like to take up working the devteam angle for the Cloud SIG.
The overall variant plan is a proposal and we had initially hoped to have had atleast one set of people from outside the project come through and offer to work the plan, creating the draft mechanics and working with us on the systems side to make it happen - we have 7 proposals already :)
Do any of the OfficeHours timeslots work for you : http://wiki.centos.org/OfficeHours if so, lets use one of those to thrash through the requirements, the proposal and setup a plan.
I'm unavailable for most of next week because of the Eucalyptus all-hands, but much more free on the week of 1/20, if that would work.
--g
If we can get these things done next week, we can push to the board the week after.
- 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@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 01/10/2014 12:41 AM, Greg DeKoenigsberg wrote:
Do any of the OfficeHours timeslots work for you : http://wiki.centos.org/OfficeHours if so, lets use one of those to thrash through the requirements, the proposal and setup a plan.
I'm unavailable for most of next week because of the Eucalyptus all-hands, but much more free on the week of 1/20, if that would work.
which one of the same times, for the week after works best for you ?
- KB
On Thu, Jan 9, 2014 at 8:25 PM, Karanbir Singh mail-lists@karan.org wrote:
On 01/10/2014 12:41 AM, Greg DeKoenigsberg wrote:
Do any of the OfficeHours timeslots work for you : http://wiki.centos.org/OfficeHours if so, lets use one of those to thrash through the requirements, the proposal and setup a plan.
I'm unavailable for most of next week because of the Eucalyptus all-hands, but much more free on the week of 1/20, if that would work.
which one of the same times, for the week after works best for you ?
Looks like the Monday or Thursday times could both work. On Monday 1/20 I'll have an hour; on Thursday 1/23 I could have multiple hours.
--g
- 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@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 01/10/2014 01:28 AM, Greg DeKoenigsberg wrote:
Looks like the Monday or Thursday times could both work. On Monday 1/20 I'll have an hour; on Thursday 1/23 I could have multiple hours.
Sounds good - lets do this on the 23rd, in the mean time we can get most of the content together ( or atleast scope up what is needed ).
- KB
On 01/10/2014 06:00 PM, Karanbir Singh wrote:
On 01/10/2014 01:28 AM, Greg DeKoenigsberg wrote:
Looks like the Monday or Thursday times could both work. On Monday 1/20 I'll have an hour; on Thursday 1/23 I could have multiple hours.
Sounds good - lets do this on the 23rd, in the mean time we can get most of the content together ( or atleast scope up what is needed ).
Is this intended to be an open meeting for all the various people interested in Cloud SIG activity?
On 01/13/2014 05:50 PM, Rich Bowen wrote:
On 01/10/2014 06:00 PM, Karanbir Singh wrote:
On 01/10/2014 01:28 AM, Greg DeKoenigsberg wrote:
Looks like the Monday or Thursday times could both work. On Monday 1/20 I'll have an hour; on Thursday 1/23 I could have multiple hours.
Sounds good - lets do this on the 23rd, in the mean time we can get most of the content together ( or atleast scope up what is needed ).
Is this intended to be an open meeting for all the various people interested in Cloud SIG activity?
absolutely, its on google-hangout and posted live to youtube for anyone to come join. we had an initial impromptu session earlier today to see how the format might work. result is here : http://www.youtube.com/watch?v=h96WFFGeN5k
we should have the format and process cleaned up for the next session on Wednesday.
Hi Greg,
On 01/10/2014 12:57 AM, Greg DeKoenigsberg wrote:
How do we proceed? What discussion needs to take place, and who can say yes to move this request forward?
What (if any) packages would you need which are not in the core platform (that is, either packages which aren't there at all, or that would need to be newer/patched compared to core)?
The best option from my point of view would be to have Eucalyptus participating in a Cloud SIG, and spinning a Euca variant from that. Would that be OK with you?
Cheers, Dave.
On 01/10/2014 05:26 AM, Dave Neary wrote:
Hi Greg,
On 01/10/2014 12:57 AM, Greg DeKoenigsberg wrote:
How do we proceed? What discussion needs to take place, and who can say yes to move this request forward?
What (if any) packages would you need which are not in the core platform (that is, either packages which aren't there at all, or that would need to be newer/patched compared to core)?
The best option from my point of view would be to have Eucalyptus participating in a Cloud SIG, and spinning a Euca variant from that. Would that be OK with you?
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.
On 01/10/2014 03:36 PM, Rich Bowen wrote:
On 01/10/2014 05:26 AM, Dave Neary wrote:
Hi Greg,
On 01/10/2014 12:57 AM, Greg DeKoenigsberg wrote:
How do we proceed? What discussion needs to take place, and who can say yes to move this request forward?
What (if any) packages would you need which are not in the core platform (that is, either packages which aren't there at all, or that would need to be newer/patched compared to core)?
The best option from my point of view would be to have Eucalyptus participating in a Cloud SIG, and spinning a Euca variant from that. Would that be OK with you?
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.
Every Cloud initiative should prepare a list of replaced and added packages with minimum versions and any matches should be examined. I am guessing main concern will be a kernel version. SiG Cloud could have separate repositories for each Variant and in it different versions of packages/kernels needed.
If there is a problem with clashing versions of some packet, yum priority can be used to push the correct one.
Bare in mind that ElRepo project already has 3.10 kernels made to fit to EL 6 system, so they can be used as an template for Variants that need newer kernel.
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.
On 01/10/2014 10:26 AM, Dave Neary wrote:
What (if any) packages would you need which are not in the core platform (that is, either packages which aren't there at all, or that would need to be newer/patched compared to core)?
The aim was to give every SIG the ability to run one or more Extras/ like or Plus/ like repos ( Plus/ content can overwrite OS components, Extras/ cant ).
The best option from my point of view would be to have Eucalyptus participating in a Cloud SIG, and spinning a Euca variant from that. Would that be OK with you?
That would get my vote as well, however it might be worth considering a few things here : Do we split Cloud Infra from Cloud Instance SIGs ? Although the core SIG will deliver cloud instances, it will only be for the core distro.
And when multiple vendor or project solutions need to replace or rely on components that otherwise have the same name/ver or similar function ( eg. different libvirt versions ), how do we handle those.
- KB
Hi,
(Also, officially, hello centos-devel! I'm one of the new guys here - been working on growing the community around oVirt, OpenStack on CentOS & RHEL and a few other bits & pieces as part of my job in Red Hat - very eager to see effective collaboration between projects with CentOS)
On 01/11/2014 12:09 AM, Karanbir Singh wrote:
On 01/10/2014 10:26 AM, Dave Neary wrote:
The best option from my point of view would be to have Eucalyptus participating in a Cloud SIG, and spinning a Euca variant from that. Would that be OK with you?
That would get my vote as well, however it might be worth considering a few things here : Do we split Cloud Infra from Cloud Instance SIGs ? Although the core SIG will deliver cloud instances, it will only be for the core distro.
And when multiple vendor or project solutions need to replace or rely on components that otherwise have the same name/ver or similar function ( eg. different libvirt versions ), how do we handle those.
I definitely see provision of cloud instances and collaboration on what infra providers need to be separate problem spaces. I was thinking "cloud infrastructure" when thinking about a cloud SIG, but perhaps it makes sense to frame things as you suggest.
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.
Cheers, Dave.
On 01/12/2014 08:25 AM, Dave Neary wrote:
I definitely see provision of cloud instances and collaboration on what infra providers need to be separate problem spaces. I was thinking "cloud infrastructure" when thinking about a cloud SIG, but perhaps it makes sense to frame things as you suggest.
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.
+1
And it sounds like we've got at least some consensus on that approach from various folks. Hopefully everyone that's interested in this is following all of the various cloud-sig threads. Probably time to consolidate all the various threads into one ...
-
Dave Neary -
Greg DeKoenigsberg -
Karanbir Singh -
Ljubomir Ljubojevic -
Rich Bowen