Open Stack

On Thu, Sep 17, 2015 at 3:22 AM, <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>
>> 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>>
>>>> Reply-To: "sam at yaple.net<mailto:sam at yaple.net>"
>>>> <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>>
>>>> Cc: "OpenStack Development Mailing List (not for usage
>>>> questions)"
>>>>
>>>>
>>>       tack-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>> wrote:
>>>> Response inline.
>>>>
>>>> From: Sam Yaple <samuel at yaple.net<mailto:samuel at yaple.net>>
>>>> Reply-To: "sam at yaple.net<mailto:sam at yaple.net>"
>>>> <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>>
>>>> Cc: "OpenStack Development Mailing List (not for usage
>>>> questions)"
>>>>
>>>>
>>>       tack-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>> wrote:
>>>>
>>>> From: Sam Yaple <samuel at yaple.net<mailto:samuel at yaple.net>>
>>>> Reply-To: "sam at yaple.net<mailto:sam at yaple.net>"
>>>> <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>>
>>>> Cc: "OpenStack Development Mailing List (not for usage
>>>> questions)"
>>>>
>>>>
>>>       tack-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>> 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 [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 [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://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://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/10c275f7/attachment.html>