Open Stack

It appears the core team is mostly in agreement about the idea of having support for commercial distributions of OpenStack in Kolla.  The vote was nearly unanimous.  That said, there was some feedback that came out of the various comments.

As a community:
We should set standards by which distros of OpenStack should operate in order to stay inside the Kolla tree
We should be willing to remove in-tree distros if their engineering backing disappears or their contributors lose interest in maintaining the distros
We should judge each new distro with an eye towards minimizing maintenance burden
We should be inclusive and make an effort to facilitate participation in Kolla from commercial distributions of OpenStack
Down the road we should sort out our CI requirements, once we actually have effective CI for our free distros of OpenStack

Thanks everyone for your valued time in responding on this vote.

Regards
-steve


From: Martin André <martin.andre at gmail.com<mailto:martin.andre at gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Thursday, September 17, 2015 at 7:07 AM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [kolla] Followup to review in gerrit relating to RHOS + RDO types



On Thu, Sep 17, 2015 at 3:22 AM, <harm at weites.com<mailto:harm at weites.com>> wrote:
There is an apparent need for having official RHOS being supported from our end, and we just so happen to have the possibility of filling that need. Should the need arise to support whatever fancy proprietary backend system or even have Kolla integrate with Oracle Solaris or something, that need would most probably be backed by a company plus developer effort. I believe the burden for our current (great) team would more or less stay the same (eg. lets assume we don't know anything about Solaris), so this company should ship in devvers to aid their 'wish'. The team effort with these additional devvers would indeed grow, bigtime. Keeping our eyes on the matters feels like a fair solution, allowing for these additions while guarding the effort they take. Should Kolla start supporting LXC besides Docker, that would be awesome (uhm...) - but I honestly don't see a need to be thinking about that right now, if someone comes up with a spec about it and wants to invest time+effort we can atleast review it. We shouldn't prepare our Dockerfiles for such a possibility though, whereas the difference between RHOS and CentOS is very little. Hence, support is rather easy to implement.

The question was if Kolla wants/should support integrating with 3rd party tools, and I think we should support it. There should be rules, yes. We probably shouldn't be worrying about proprietary stuff that other projects hardly take seriously (even though drivers have been accepted)...

Vote: +1

- harmw

Sam Yaple schreef op 2015-09-14 13:44:
On Mon, Sep 14, 2015 at 11:19 AM, Paul Bourke <paul.bourke at oracle.com<mailto:paul.bourke at oracle.com>>
wrote:

On 13/09/15 18:34, Steven Dake (stdake) wrote:

Response inline.

From: Sam Yaple <samuel at yaple.net<mailto:samuel at yaple.net><mailto:samuel at yaple.net<mailto:samuel at yaple.net>>>
Reply-To: "sam at yaple.net<mailto:sam at yaple.net><mailto:sam at yaple.net<mailto:sam at yaple.net>>"
<sam at yaple.net<mailto:sam at yaple.net><mailto:sam at yaple.net<mailto:sam at yaple.net>>>
Date: Sunday, September 13, 2015 at 1:35 AM
To: Steven Dake <stdake at cisco.com<mailto:stdake at cisco.com><mailto:stdake at cisco.com<mailto:stdake at cisco.com>>>
Cc: "OpenStack Development Mailing List (not for usage
questions)"


      tack-dev at lists.openstack.org<mailto:tack-dev at lists.openstack.org><mailto:openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>>
Subject: Re: [kolla] Followup to review in gerrit relating to
RHOS + RDO types

On Sun, Sep 13, 2015 at 3:01 AM, Steven Dake (stdake)
<stdake at cisco.com<mailto:stdake at cisco.com><mailto:stdake at cisco.com<mailto:stdake at cisco.com>>> wrote:
Response inline.

From: Sam Yaple <samuel at yaple.net<mailto:samuel at yaple.net><mailto:samuel at yaple.net<mailto:samuel at yaple.net>>>
Reply-To: "sam at yaple.net<mailto:sam at yaple.net><mailto:sam at yaple.net<mailto:sam at yaple.net>>"
<sam at yaple.net<mailto:sam at yaple.net><mailto:sam at yaple.net<mailto:sam at yaple.net>>>
Date: Saturday, September 12, 2015 at 11:34 PM
To: Steven Dake <stdake at cisco.com<mailto:stdake at cisco.com><mailto:stdake at cisco.com<mailto:stdake at cisco.com>>>
Cc: "OpenStack Development Mailing List (not for usage
questions)"


      tack-dev at lists.openstack.org<mailto:tack-dev at lists.openstack.org><mailto:openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>>
Subject: Re: [kolla] Followup to review in gerrit relating to
RHOS + RDO types

Sam Yaple

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

From: Sam Yaple <samuel at yaple.net<mailto:samuel at yaple.net><mailto:samuel at yaple.net<mailto:samuel at yaple.net>>>
Reply-To: "sam at yaple.net<mailto:sam at yaple.net><mailto:sam at yaple.net<mailto:sam at yaple.net>>"
<sam at yaple.net<mailto:sam at yaple.net><mailto:sam at yaple.net<mailto:sam at yaple.net>>>
Date: Saturday, September 12, 2015 at 11:01 PM
To: Steven Dake <stdake at cisco.com<mailto:stdake at cisco.com><mailto:stdake at cisco.com<mailto:stdake at cisco.com>>>
Cc: "OpenStack Development Mailing List (not for usage
questions)"


      tack-dev at lists.openstack.org<mailto:tack-dev at lists.openstack.org><mailto:openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>>
Subject: Re: [kolla] Followup to review in gerrit relating to
RHOS + RDO types

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

Sam had asked a reasonable set of questions regarding a patchset:
https://review.openstack.org/#/c/222893/ [1]


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.

I think what you are proposing is RHEL + RHOS and CENTOS + RDO.
RDO also runs on RHEL.  I want to enable Red Hat customers to
make a choice to have a supported  operating system but not a
supported Cloud environment.  The answer here is RHEL + RDO.
This leads to full support down the road if the Operator chooses
to pay Red Hat for it by an easy transition to RHOS.

I am against including vendor specific things like RHOS in Kolla
outright like you are purposing. Suppose another vendor comes
along with a new base and new packages. They are willing to
maintain it, but its something that no one but their customers
with their licensing can use. This is not something that belongs
in Kolla and I am unsure that it is even appropriate to belong in
OpenStack as a whole. Unless RHEL+RHOS can be used by those that
do not have a license for it, I do not agree with adding it at
all.

Sam,

Someone stepping up to maintain a completely independent set of
docker images hasn’t happened.  To date nobody has done that.
If someone were to make that offer, and it was a significant
change, I think the community as a whole would have to evaluate
such a drastic change.  That would certainly increase our
implementation and maintenance burden, which we don’t want  to
do.  I don’t think what you propose would be in the best
interest of the Kolla project, but I’d have to see the patch set
to evaluated the scenario appropriately.

What we are talking about is 5 additional lines to enable
RHEL+RHOS specific repositories, which is not very onerous.

The fact that you can’t use it directly has little bearing on
whether its valid technology for OpenStack.  There are already
two well-defined historical precedents for non-licensed unusable
integration in OpenStack.  Cinder has 55 [1] Volume drivers which
they SUPPORT.     At-leat 80% of them are completely
proprietary hardware which in reality is mostly just software
which without a license to, it would be impossible to use.  There
are 41 [2] Neutron drivers registered on the Neutron driver page;
almost the entirety require proprietary licenses to what amounts
as integration to access proprietary software.  The OpenStack
preferred license is ASL for a reason – to be business
friendly.  Licensed software has a place in the world of
OpenStack, even it only serves as an integration point which the
proposed patch does.  We are consistent with community values on
this point or I wouldn’t have bothered proposing the patch.

We want to encourage people to use Kolla for proprietary
solutions if they so choose.  This is how support manifests,
which increases the strength of the Kolla project.  The presence
of support increases the likelihood that Kolla will be adopted by
Operators.  If your asking the Operators to maintain a fork for
those 5 RHOS repo lines, that seems unreasonable.

I’d like to hear other Core Reviewer opinions on this matter
and will hold a majority vote on this thread as to whether we will
facilitate integration with third party software such as the
Cinder Block Drivers, the Neutron Network drivers, and various
for-pay versions of OpenStack such as RHOS.  I’d like all core
reviewers to weigh in please.  Without a complete vote it will be
hard to gauge what the Kolla community really wants.

Core reviewers:
Please vote +1 if you ARE satisfied with integration with third
party unusable without a license software, specifically Cinder
volume drivers, Neutron network drivers, and various for-pay
distributions of OpenStack and container runtimes.
Please vote –1 if you ARE NOT satisfied with integration with
third party unusable without a license software, specifically
Cinder volume drivers, Neutron network drivers, and various for
pay distributions of OpenStack and container runtimes.

A bit of explanation on your vote might be helpful.

My vote is +1.  I have already provided my rationale.

Regards,
-steve

[1] https://wiki.openstack.org/wiki/CinderSupportMatrix [2]
[2] https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers
[3]


I appreciate you calling a vote so early. But I haven't had my
questions answered yet enough to even vote on the matter at hand.

In this situation the closest thing we have to a plugin type
system as Cinder or Neutron does is our header/footer system. What
you are proposing is integrating a proprietary solution into the
core of Kolla. Those Cinder and Neutron plugins have external
components and those external components are not baked into the
project.

What happens if and when the RHOS packages require different
tweaks in the various containers? What if it requires changes to
the Ansible playbooks? It begins to balloon out past 5 lines of
code.

Unfortunately, the community _wont_ get to vote on whether or not
to implement those changes because RHOS is already in place.
That's why I am asking the questions now as this _right_ _now_ is
the significant change you are talking about, regardless of the
lines of code.

So the question is not whether we are going to integrate 3rd
party plugins, but whether we are going to allow companies to
build proprietary products in the Kolla repo. If we allow
RHEL+RHOS then we would need to allow another distro+company
packaging and potential Ansible tweaks to get it to work for them.

If you really want to do what Cinder and Neutron do, we need a
better system for injecting code. That would be much closer to the
plugins that the other projects have.

I'd like to have a discussion about this rather than immediately
call for a vote which is why I asked you to raise this question in
a public forum in the first place.

Sam,

While a true code injection system might be interesting and would
be more parallel with the plugin model used in cinder and neutron
(and to some degrees nova), those various systems didn’t begin
that way.  Their driver code at one point was completely
integrated.  Only after 2-3 years was the code broken into a
fully injectable state.  I think that is an awfully high bar to
set to sort out the design ahead of time.  One of the reasons
Neutron has taken so long to mature is the Neutron community
attempted to do plugins at too early a stage which created big
gaps in unit and functional tests.  A more appropriate design
would be for that pattern to emerge from the system over time as
people begin to adopt various distro tech to Kolla.  If you
looked at the patch in gerrit, there is one clear pattern “Setup
distro repos” which at some point in the future could be made to
be injectable much as headers and footers are today.

As for building proprietary products in the Kolla repository, the
license is ASL, which means it is inherently not proprietary.  I
am fine with the code base integrating with proprietary software
as long as the license terms are met; someone has to pay the
mortgages of the thousands of OpenStack developers.  We should
encourage growth of OpenStack, and one of the ways for that to
happen is to be business friendly.  This translates into first
knowing the world is increasingly adopting open source
methodologies and facilitating that transition, and second
accepting the world has a whole slew of proprietary software that
already exists today that requires integration.

Nonetheless, we have a difference of opinion on this matter, and
I want this work to merge prior to rc1.  Since this is a project
policy decision and not a technical issue, it makes sense to put
it to a wider vote to either unblock or kill the work.  It would
be a shame if we reject all driver and supported distro
integration because we as a community take an anti-business stance
on our policies, but I’ll live by what the community decides.
This is not a decision either you or I may dictate which is why it
has been put to a vote.

Regards
-steve

For oracle linux, I’d like to keep RDO for oracle linux and
from source on oracle linux as choices.  RDO also runs on oracle
linux.  Perhaps the patch set needs some later work here to
address this point in more detail, but as is “binary” covers
oracle linu.

Perhaps what we should do is get rid of the binary type
entirely.  Ubuntu doesn’t really have a binary type, they have
a cloudarchive type, so binary doesn’t make a lot of sense.
Since Ubuntu to my knowledge doesn’t have two distributions of
OpenStack the same logic wouldn’t apply to providing a full
support onramp for Ubuntu customers.  Oracle doesn’t provide a
binary type either, their binary type is really RDO.

The binary packages for Ubuntu are _packaged_ by the cloudarchive
team. But in the case of when OpenStack collides with an LTS
release (Icehouse and 14.04 was the last one) you do not add a new
repo because the packages are in the main Ubuntu repo.

Debian provides its own packages as well. I do not want a type
name per distro. 'binary' catches all packaged OpenStack things by
a distro.

FWIW I never liked the transition away from rdo in the repo names
to binary.  I guess I should have –1’ed those reviews back
then, but I think its time to either revisit the decision or
compromise that binary and rdo mean the same thing in a centos and
rhel world.

Regards
-steve

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



   _______________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe> [4]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[5]

Both arguments sound valid to me, both have pros and cons.

I think it's valuable to look to the experiences of Cinder and
Neutron in this area, both of which seem to have the same scenario
and have existed much longer than Kolla. From what I know of how
these operate, proprietary code is allowed to exist in the mainline
so long as certain set of criteria is met. I'd have to look it up
but I think it mostly comprises of the relevant parties must "play
by the rules", e.g. provide a working CI, help with reviews, attend
weekly meetings, etc. If Kolla can look to craft a similar set of
criteria for proprietary code down the line, I think it should work
well for us.

Steve has a good point in that it may be too much overhead to
implement a plugin system or similar up front. Instead, we should
actively monitor the overhead in terms of reviews and code size that
these extra implementations add. Perhaps agree to review it at the
end of Mitaka?

Given the project is young, I think it can also benefit from the
increased usage and exposure from allowing these parties in. I would
hope independent contributors would not feel rejected from not being
able to use/test with the pieces that need a license. The libre
distros will remain #1 for us.

So based on the above explanation, I'm +1.

-Paul


   _______________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe> [4]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[5]

Given Paul's comments I would agree here as well. I would like to get
that 'criteria' required for Kolla to allow this proprietary code into
the main repo down as soon as possible though and suggest that we have
a bare minimum of being able to gate against it as one of the
criteria.

As for a plugin system, I also agree with Paul that we should check
the overhead of including these other distros and any types needed
after we have had time to see if they do introduce any additional
overhead.

So for the question 'Do we allow code that relies on proprietary
packages?' I would vote +1, with the condition that we define the
requirements of allowing that code as soon as possible.


Links:
------
[1] https://review.openstack.org/#/c/222893/
[2] https://wiki.openstack.org/wiki/CinderSupportMatrix
[3] https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers
[4] http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
[5] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

I'm also +1 on principle of opening the Kolla doors to distros with paid licence and accepting them in the source tree. We shouldn't build barriers but bridges.
I would like to make sure we all agree, however, that there is no guarantee that because the code for a distro is in the repo it means it will stay in there. I want to reserve the right as a Kolla dev to remove paid distros from the tree if it becomes a burden, for exemple unreliable CI or lack of commitment from people backing the distro.

Martin

   _______________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/d346002d/attachment.html>