Hi Karanbir,

I'm sorry I missed the office hours hangout, but I listened back over most of the discussion.

I've been thinking a bit about RDO, CentOS and the Cloud SIG and wanted to drop some thoughts here in case it helps the discussion.

The thing is - I'm hugely excited about the changes happening around CentOS and think there are great opportunities here. That said, I want to be realistic about what's likely to happen around CentOS and RDO in the medium term.

So, what does the RDO maintenance team care about?

- our focus is making a usable distro of vanilla OpenStack available on EL distros and persuade OpenStack users that EL is the best choice for running OpenStack than Ubuntu - i.e. we're talking about people who know they want (or want to try) OpenStack and we want to persuade them to use EL

- our instinct would be to show EL as rock-solid in terms of performance and stability even if that's at the expense of newer features. To me, that means replacing as little of the base distro as possible, especially the hypervisor bits. I'd be keen to make zero or very few modifications to the EL kernel, qemu and libvirt.

- to deliver RDO to date, we've been getting by using Fedora infrastructure but it would probably be a big improvement if we could switch over to CentOS infrastructure - e.g. koji, git, yum repos, etc.

- obviously there are other projects which aren't in the base OS that can be very useful to RDO users - e.g. Open vSwitch, Open Daylight, GlusterFS, Ceph, Docker, Xen, etc. If they were available through CentOS, we'd love to make it really easy for RDO users to use them.

- as an opt-in "preview" variant of RDO on CentOS, it would be really cool to have newer base OS features available for people to experiment with - I'd expect this to be fairly rapidly moving and not recommended for real-world use, though. I could definitely imagine the other IaaS projects having a similar need and some shared maintenance happening there.

- the difficulty with both of these is that - despite everyone's best intentions - RDO maintainers aren't necessarily going to be able to make a tonne of time to help out with either of them. Keeping up with OpenStack is enough of a challenge in itself.

- I don't imagine RDO folks being terrifically interested in doing work to make OpenStack co-exist on the same system or in the same distro with other IaaS project, just because it's a tonne of work and hard to imagine it helping users all that much. The "choose your own adventure" LiveCD idea does sound cool, but even that doesn't necessarily require all projects to live together in the same repo.

So, to summarize - the main things of interest to RDO folks would probably be:

- using CentOS koji, git and yum repos to build, maintain and deliver RDO

- builds of CentOS images for RDO users to run in their guests

- collaboration with other projects to experiment with and learn about e.g. packaging with SCLs (either packaging the apps themselves as SCLs, or just their dependency stacks)

- re-using any work other SIGs do around packaging and maintenance of other projects which will be useful to RDO users

- collaboration around the maintenance of a preview/experimental variant which includes newer base OS features which are particularly interesting for IaaS projects

I guess I'm curious whether other projects which have an interest in the Cloud SIG share a similar perspective?

For example, in the office hours chat I think there was an assumption that all of our projects need newer kernels, libvirt and qemu whereas I'd be worried about exposing RDO users to potential instability by doing that.

Thanks in advance, Mark.

On Thu, 2014-01-23 at 15:41 +0000, Karanbir Singh wrote:

Hi guys, we are getting ready to kick this off. The URLS you need for viewers are : youtube: http://www.youtube.com/watch?v=VKKYY_5SOWw and on google plus at https://plus.google.com/+CentOS

For the participants, I have just sent out emails with the url, if you dont have it - please come and find me on #centos-devel on irc.freenode.net

On 01/13/2014 09:56 PM, Karanbir Singh wrote:

...

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=...

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,

On Fri, Jan 24, 2014 at 11:00 AM, David Nalley david@gnsa.us wrote:

...

I personally don't see a huge benefit from just using the CentOS yum repos. Yum repos are effectively a commodity; and you aren't getting away from reading documentation to get going regardless of platform, so enabling a CentOS-hosted repo over a CloudStack-hosted repo doesn't really gain me much.

Yes, I've always thought that once you get to the point of having a live network connection, a VM should be indistinguishable from hardware and managed the same way from the OS perspective. Maybe the images could be minimal but pre-seeded with puppet/chef/salt agents and the rest of the special-purpose tooling can be a recipe/state that tells yum to install a list of packages and tweaks the configs if needed. The salt-minion is able to run standalone if desired/necessary so that might be a starting point for more complicated setups in a way that would work across different cloud infrastructures as well as standalone hardware.

On 01/25/2014 03:31 PM, Matthew Miller wrote:

On Fri, Jan 24, 2014 at 04:33:40PM +0000, Mark McLoughlin wrote:

...

• to deliver RDO to date, we've been getting by using Fedora infrastructure but it would probably be a big improvement if we could switch over to CentOS infrastructure - e.g. koji, git, yum repos, etc.

Can you explain in a little detail why that would be a big improvement? Are there areas where Fedora could do things in a way which would be better for you?

isnt RDO mostly consumed on CentOS / EL instead of on Fedora ?

On 01/27/2014 02:49 AM, Robyn Bergeron wrote:

----- Original Message -----

...

From: "Karanbir Singh" mail-lists@karan.org To: centos-devel@centos.org Sent: Sunday, January 26, 2014 1:59:42 PM Subject: Re: [CentOS-devel] Wider conversation around process and delivery for the Cloud SIG

On 01/25/2014 03:31 PM, Matthew Miller wrote:

...

On Fri, Jan 24, 2014 at 04:33:40PM +0000, Mark McLoughlin wrote:

...

• to deliver RDO to date, we've been getting by using Fedora infrastructure but it would probably be a big improvement if we could switch over to CentOS infrastructure - e.g. koji, git, yum repos, etc.

Can you explain in a little detail why that would be a big improvement? Are there areas where Fedora could do things in a way which would be better for you?

isnt RDO mostly consumed on CentOS / EL instead of on Fedora ?

I would say "probably" - though the cheerleader inside me is certain, deep down to my blue pom-poms, that there are some consuming on Fedora as well :)

Centos / EL being more "server" centric currently, is the main consumer of RDO. Though there are significant users on Fedora too from both developers, casual testers and even some deployments. Both are important, especially considering the closer alignment of Fedora with _current_ EL7 packages.

I think Matt's question is going towards determining if this is a "workflow" thing - which could perhaps be intertwined with where RDO is mostly consumed - or if there are actual, technical issues with Fedora's infrastructure/build system (is it too slow? too bureaucratic? something else) that are of concern, since those are good things for Fedora folks to know.

I think, at least in theory (I know someone will correct me if I'm totally wrong here) - Fedora's ability to actually "deliver RDO" shouldn't differentiate greatly from CentOS's, given that we largely use the same tools, we can do EPEL builds for EL5/6/7, etc. Where this starts to diverge is with the new magic that the CentOS Cloud SIG is working on; if there is essentially a Cloudified EL 6/7, with different bits in it than what is standard in EL 6, and dependencies that are quite possibly newer than what is in EPEL -- that is, for the moment anyway :D, something that Fedora can't really *build for* (build against?). So that might make sense. Or it could be something else.

I guess my question would be - assuming that any of what I guessed at in the previous paragraph is in line with Mark's thinking - would the plan then be to simply build RDO for Fedora and CentOS/EL in each of their respective infrastructure homes? (I am assuming there is not a way to build for Fedora w/in CentOS infra, and keep those things in a CentOS repo, that I am woefully ignorant of... )

So the Fedora infra is fine for delivering RDO on Fedora.

Even for EL it has been very useful, even though OpenStack packages are no longer in EPEL. This was a little awkward though due to branching and supported tags, but nothing too onerous.

Given the different cadences for OpenStack releases combined with the more stringent compatibility constraints of the main EPEL repos, it seems like it might be a more natural fit to use Centos infra for this. We'll be discussing this a the dojo this week.

In addition using/contributing to a Cloud specific repo could allow everyone working in this area to avoid duplicate work.

thanks, Pádraig.

On 01/29/2014 01:33 PM, Daniel Veillard wrote:

One of the thing I would like to double check nd maybe you can help is the Xen support in the RDO build.

if it is possible for someone to bring a RDO repo along with them, we have the xen4centos repo already local, and there will be a few xen people at the hackathon, we can certainly try to atleast scope up the problem / how much work ( if anything ) is needed to make that work

- KB