On Thu, Sep 17, 2015 at 3:22 AM, <h...@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.bou...@oracle.com> >> wrote: >> >> 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)" >>>> >>>> >>> tack-...@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)" >>>> >>>> >>> tack-...@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)" >>>> >>>> >>> tack-...@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/ [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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev