[openstack-dev] [kolla] Followup to review in gerrit relating to RHOS + RDO types

Sam Yaple samuel at yaple.net
Sun Sep 13 06:01:46 UTC 2015


On Sun, Sep 13, 2015 at 12:39 AM, Steven Dake (stdake) <stdake at cisco.com>
wrote:

> Hey folks,
>
> Sam had asked a reasonable set of questions regarding a patchset:
> https://review.openstack.org/#/c/222893/
>
> The purpose of the patchset is to enable both RDO and RHOS as binary
> choices on RHEL platforms.  I suspect over time, from-source deployments
> have the potential to become the norm, but the business logistics of such a
> change are going to take some significant time to sort out.
>
> Red Hat has two distros of OpenStack neither of which are from source.
> One is free called RDO and the other is paid called RHOS.  In order to
> obtain support for RHEL VMs running in an OpenStack cloud, you must be
> running on RHOS RPM binaries.  You must also be running on RHEL.  It
> remains to be seen whether Red Hat will actively support Kolla deployments
> with a RHEL+RHOS set of packaging in containers, but my hunch says they
> will.  It is in Kolla’s best interest to implement this model and not make
> it hard on Operators since many of them do indeed want Red Hat’s support
> structure for their OpenStack deployments.
>
> Now to Sam’s questions:
> "Where does 'binary' fit in if we have 'rdo' and 'rhos'? How many more do
> we add? What's our policy on adding a new type?”
>
> I’m not immediately clear on how binary fits in.  We could make
> binary synonymous with the community supported version (RDO) while still
> implementing the binary RHOS version.  Note Kolla does not “support” any
> distribution or deployment of OpenStack – Operators will have to look to
> their vendors for support.
>

If everything between centos+rdo and rhel+rhos is mostly the same then I
would think it would make more sense to just use the base ('rhel' in this
case) to branch of any differences in the templates. This would also allow
for the least amount of change and most generic implementation of this
vendor specific packaging. This would also match what we do with
oraclelinux, we do not have a special type for that and any specifics would
be handled by an if statement around 'oraclelinux' and not some special
type.

Since we implement multiple bases, some of which are not RPM based, it
doesn't make much sense to me to have rhel and rdo as a type which is why
we removed rdo in the first place in favor of the more generic 'binary'.


>
> As such the implied second question “How many more do we add?” sort of
> sounds like ‘how many do we support?”.  The answer to the second question
> is none – again the Kolla community does not support any deployment of
> OpenStack.  To the question as posed, how many we add, the answer is it is
> really up to community members willing to  implement and maintain the
> work.  In this case, I have personally stepped up to implement RHOS and
> maintain it going forward.
>
> Our policy on adding a new type could be simple or onerous.  I prefer
> simple.  If someone is willing to write the code and maintain it so that is
> stays in good working order, I see no harm in it remaining in tree.  I
> don’t suspect there will be a lot of people interested in adding multiple
> distributions for a particular operating system.  To my knowledge, and I
> could be incorrect, Red Hat is the only OpenStack company with a paid and
> community version available of OpenStack simultaneously and the paid
> version is only available on RHEL.  I think the risk of RPM based
> distributions plus their type count spiraling out of manageability is low.
> Even if the risk were high, I’d prefer to keep an open mind to facilitate
> an increase in diversity in our community (which is already fantastically
> diverse, btw ;)
>
> I am open to questions, comments or concerns.  Please feel free to voice
> them.
>
> Regards,
> -steve
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150913/e43fa967/attachment.html>


More information about the OpenStack-dev mailing list