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

From: Sam Yaple <sam...@yaple.net<mailto:sam...@yaple.net>>
Reply-To: "s...@yaple.net<mailto:s...@yaple.net>" 
<s...@yaple.net<mailto:s...@yaple.net>>
Date: Sunday, September 13, 2015 at 1:35 AM
To: Steven Dake <std...@cisco.com<mailto:std...@cisco.com>>
Cc: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@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) 
<std...@cisco.com<mailto:std...@cisco.com>> wrote:
Response inline.

From: Sam Yaple <sam...@yaple.net<mailto:sam...@yaple.net>>
Reply-To: "s...@yaple.net<mailto:s...@yaple.net>" 
<s...@yaple.net<mailto:s...@yaple.net>>
Date: Saturday, September 12, 2015 at 11:34 PM
To: Steven Dake <std...@cisco.com<mailto:std...@cisco.com>>
Cc: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@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) 
<std...@cisco.com<mailto:std...@cisco.com>> wrote:


From: Sam Yaple <sam...@yaple.net<mailto:sam...@yaple.net>>
Reply-To: "s...@yaple.net<mailto:s...@yaple.net>" 
<s...@yaple.net<mailto:s...@yaple.net>>
Date: Saturday, September 12, 2015 at 11:01 PM
To: Steven Dake <std...@cisco.com<mailto:std...@cisco.com>>
Cc: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@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) 
<std...@cisco.com<mailto:std...@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.

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] https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers


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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to