----- Original Message ----- From: "Rich Bowen" rbowen@redhat.com To: centos-devel@centos.org Sent: Tuesday, 17 June, 2014 3:00:38 PM Subject: [CentOS-devel] RDO on CentOS

Hi,

I work with the RDO project - http://openstack.redhat.com/ - where we're trying to make OpenStack as easy as possible to deploy on CentOS, RHEL, Fedora, et al. Since CentOS is (at least anecdotally) the leading platform that we're seeing used with RDO, we're wondering what we can do to make RDO easier to consume on CentOS, and, more generally, what we can do to make OpenStack easier on CentOS.

Personally when something is in EPEL or the base repo that's where I start trusting being able to install/use it. I realize that RDO likely changes a whole lot quicker than distros like RHEL/CentOS. So solving that so that you can have RDO packages in EPEL - perhaps in parallel (all in the repo but conflicting with each other or something). Would go a long way to getting people to try it I imagine.

On 17 June 2014 12:41, Nathanael D. Noblet nathanael@gnat.ca wrote:

...

----- Original Message ----- From: "Rich Bowen" rbowen@redhat.com To: centos-devel@centos.org Sent: Tuesday, 17 June, 2014 3:00:38 PM Subject: [CentOS-devel] RDO on CentOS

Hi,

I work with the RDO project - http://openstack.redhat.com/ - where we're trying to make OpenStack as easy as possible to deploy on CentOS, RHEL, Fedora, et al. Since CentOS is (at least anecdotally) the leading platform that we're seeing used with RDO, we're wondering what we can do to make RDO easier to consume on CentOS, and, more generally, what we can do to make OpenStack easier on CentOS.

Personally when something is in EPEL or the base repo that's where I start trusting being able to install/use it. I realize that RDO likely changes a whole lot quicker than distros like RHEL/CentOS. So solving that so that you can have RDO packages in EPEL - perhaps in parallel (all in the repo but conflicting with each other or something). Would go a long way to getting people to try it I imagine.

From the EPEL side of the fence, the reason that OpenStack isn't in EPEL

anymore is due to three factors:

1) You really can't parallel y install it unless you do it via software collections 2) Updates to it aren't guaranteed to be without headache (command come, commands go, etc) 3) Lifetimes of the stack are shorter and aren't supportable after they get replaced.

That is pretty much the nature of any large framework from Ruby on Rails to OpenStack in that they are in many ways an OS inside of an OS and need to be treated that way. EPEL is meant to be tools for the outer OS and wasn't designed to be for the Inner OS. This is neither a problem with the frameworks or EPEL, they are just completely different mindsets and problem cases.

This is where one repo to rule them all breaks down :). Maybe a federated repository system might but it would take a lot of co-ordination that EPEL people haven;'t had time for in the past.

I think that the OpenStack easier on CentOS side is to be covered by the CentOS cloud SIG?

On 06/18/2014 09:32 AM, Nathanael D. Noblet wrote:

On Tue, 2014-06-17 at 17:35 -0600, Stephen John Smoogen wrote:

...

From the EPEL side of the fence, the reason that OpenStack isn't in EPEL anymore is due to three factors:

1. You really can't parallel y install it unless you do it via

software collections 2) Updates to it aren't guaranteed to be without headache (command come, commands go, etc) 3) Lifetimes of the stack are shorter and aren't supportable after they get replaced.

So I should clarify. Having packages in EPEL is a signal to me a as a user that the developers/packagers will make sure their released version works with the packages available in the repos, they are following the packaging guidelines/standards, aren't providing newer base packages that may break other dependencies etc. This can be signaled multiple ways, but the biggest thing is that I know if it is in EPEL it already exists as part of an ecosystem - it can't conflict or replace base versions that may be needed by other apps on the system. So somehow that message needs to be communicated. The idea that using RDO packages will not conflict with base packages / whatever and that care is taken to make sure it works and is tested with the targeted system.

I'm more than willing to use not base/epel packages. However doing so often complicates my life afterwards. Granted I would expect systems using RDO to not be running other services/apps since it kinda doesn't make much sense to have a cloud system, and one of the base hardware also running mail/web whatever apps. Those might as well be part of a cloud instance.

BUT ... RDO packages NEED to conflict with base in some ways. We should have a Cloud SIG for this and RDO would be one of participants.

What we need to still hash out, IMHO, is exactly how we host the code and do the builds, etc.

But I am not sure that is exactly what Rich is asking for here. I think (and I could be wrong) that what Rich is asking is for actual current RDO users on CentOS to provide input on how they (RDO) can make their current RDO installs work better???

The SIG would determine lifetimes of releases, etc.

On Tue, Jun 17, 2014 at 6:35 PM, Stephen John Smoogen smooge@gmail.com wrote:

From the EPEL side of the fence, the reason that OpenStack isn't in EPEL anymore is due to three factors:

1. You really can't parallel y install it unless you do it via software

collections 2) Updates to it aren't guaranteed to be without headache (command come, commands go, etc) 3) Lifetimes of the stack are shorter and aren't supportable after they get replaced.

That is pretty much the nature of any large framework from Ruby on Rails to OpenStack in that they are in many ways an OS inside of an OS and need to be treated that way. EPEL is meant to be tools for the outer OS and wasn't designed to be for the Inner OS. This is neither a problem with the frameworks or EPEL, they are just completely different mindsets and problem cases.

This is where one repo to rule them all breaks down :). Maybe a federated repository system might but it would take a lot of co-ordination that EPEL people haven;'t had time for in the past.

But, but, but.... All of those things you mention are artifacts of only having one namespace for packages and their dependencies (and partly by a somewhat related expected PATH and LD_LIBRARY_PATH). And they all just get worse if you add in uncoordinated repositories using the same names for different things. How about a special-case EPEL extension repo to hold/coordinate packages that you can't expect to update cleanly or transparently (and thus should never be left enabled) with documentation of what will break with each version and what to do about it.

Packages/frameworks that don't care about backwards compatibility are never ideal, but if the versions/updates are centralized at least the users will go through the same painful experiences and be able to help each other out when things break.

On 06/18/2014 12:03 PM, Pádraig Brady wrote:

At the last Centos dojo in Belgium I gave a talk on why the RDO repos exist, and why OpenStack packages were moved _from_ EPEL:

http://www.pixelbeat.org/talks/rdo_centos/

This was an extremely productive session, and I made -lots- of notes on the day, but the .odp on that url has everything really relevant here. Everyone, please go look at it.

We need a CentOS story for and around openstack - one, to make it easier to consume and develop / test / play with. OpenStack isnt the easiest thing to get off the ground, and the choices one makes in the early days are the ones that cause most issues later on. And secondly, an increasingly larger number of other projects and code bases are consuming and extending / adding to the openstack base and having an openstack story in CentOS allows those projects and efforts to come work in this ecosystem as well.

The process and SIG structure options that Padraig lays out are prolly the closest thing I've seen so far to a working bootstrap process. Lets get some eyeballs on it, and chart out a getting-started course.

Can we ?