On Sun, Sep 13, 2015 at 3:01 AM, Steven Dake (stdake) <std...@cisco.com> wrote:
> Response inline. > > From: Sam Yaple <sam...@yaple.net> > Reply-To: "s...@yaple.net" <s...@yaple.net> > Date: Saturday, September 12, 2015 at 11:34 PM > To: Steven Dake <std...@cisco.com> > Cc: "OpenStack Development Mailing List (not for usage questions)" < > 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> > wrote: > >> >> >> From: Sam Yaple <sam...@yaple.net> >> Reply-To: "s...@yaple.net" <s...@yaple.net> >> Date: Saturday, September 12, 2015 at 11:01 PM >> To: Steven Dake <std...@cisco.com> >> Cc: "OpenStack Development Mailing List (not for usage questions)" < >> 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> >> 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. > > >> 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