On 28/07/16 13:56 +0000, Fox, Kevin M wrote:
I really see 3 issues raised in the spec mentioned that have any disagreement as far as I can tell.1. mirantis would like to see kolla-ansible split from the base kolla repo. This has a lot of support and is likely to come up for a final vote soon. It was postponed due to not wanting to split in the middle of a cycle. - This does not seem like a good reason at this point to spawn a new project. I support the split.
Not just mirantis. *I* would love to see kolla-ansible split (and I'd also love to be able to do `pip install kolla-build, but I digress).
2. mirantis would like to see repos split for each docker container definition to be one per container. This is purely a management style difference. Split or combined both has advantages, and at present scaling issues have not been hit, so change has a cost that doesn't yet have a significant benefit. If it started to be, I'm sure it would be re-evaluated. This does not seem like a good reason at this point to spawn a new project. I think splitting seems unnecessary at this point, but if the whole thing comes down to this one issue, I'd support splitting the repos just so we don't duplicate so much work over such a minor thing. 3. Some bootstrap logic in some of the containers. mirantis would like to see it gone. Its completely optional (just don't set the BOOTSTRAP env vars) and needs to stay for api backwards compatibility in existing containers. It does not have to be used by deployment tools that don't wish to use it. This does not seem like a good reason at this point to spawn a new project. I support keeping it to not break things as its optional. Are these really that contentious that we have to split a community over? Can we get both sides to give in a little and help each other out? Maybe something like: 1. kolla commits to split out kolla-ansible as soon as possible (right after newton tagged) 2. Some middle ground here. Maybe its keep as is, but come up with a formal procedure for re-evaluating when it becomes painful and make a change. (Seems similar to the fuel/puppet repo upstreaming thing, in a way. Maybe some of the same process could work here? Some time to review metrics?) 3. We keep the optional stuff so we don't break existing deployments. Is this reasonable?
This is definitely a better way to encourage collaboration on this topic, which I happen to be interested into as well. :D Flavio
Thanks, Kevin ________________________________ From: Vladimir Kozhukalov [vkozhuka...@mirantis.com] Sent: Thursday, July 28, 2016 5:48 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off1. Alter the mission statement of fuel to match the reality beingpublished by the press and Mirantis's executive team2. Include these non-experimental repos in the projects.yaml governanceRepositoryFrankly, I don’t understand what part of the press release contradicts with Fuel mission. Current Fuel mission is “To streamline and accelerate the process of deploying, testing and maintaining various configurations of OpenStack at scale.” which means we are not bound to any specific technology when deploying OpenStack. At the moment Fuel deploys RPM/DEB packages using Puppet and Fuel specific orchestration mechanism. We are not going to drop this approach immediately, it works quite well and we are working hard to make things better (including ability to upgrade). But we also keep in mind that technologies are constantly changing and we’d like to benefit of this progress. That is why we are now looking at Docker containers and Kubernetes. Our users know that it is not our first experience of trying to use containers. Fuel releases prior to 9.0 used to deploy Fuel services in containers on the Fuel admin node. Many of you know how difficult it is to upgrade OpenStack clusters. We hope that containers could help us to solve not all but some of problems that we encounter when upgrading cluster. Maintaining and hence upgrade of OpenStack clusters is a part of Fuel mission and we are just trying to find a way how to do things. Why not Kolla but Fuel-ccp? It is not a secret that Fuel is driven by Mirantis. At Mirantis we deploy and maintain OpenStack. In attempts to find a way how to make OpenStack easily maintainable, some of Mirantis folks spent some time to contribute to Kolla and Mesos. But there were some concerns that were discussed several times (including this Kolla spec https://review.openstack.org/#/c/330575) that would make it not so easy to use Kolla containers for our use cases. Fuel-ccp is just an attempt to address these concerns. Frankly, I don’t see anything bad in having more than one set of container images (like we have more than one set of RPM/DEB distributions). Those concerns are, for example, container images should not be bound to any specific deployment technology. Containers in some sense are a similar concept to RPM/DEB packages and it does not matter what deployment tool (puppet, ansible) one uses to install them. There should be mature CI pipeline for building/testing/publishing images. There should be a convenient way (kind of DSL) to deal with dozens of images. I’d like to avoid discussing this here once again. Fuel-ccp repositories are public, everyone is welcome to participate. I don’t see where we violate “4 opens”. These repos are now experimental. At the moment the team is working on building CI pipeline and developing functional tests that are to be run as a part of CI process. These repos are not to be a part of Fuel Newton release. From time to time we add and retire git repos and it is a part of development process. Not all these repos are to become a part of Big tent. Vladimir Kozhukalov On Thu, Jul 28, 2016 at 7:45 AM, Steven Dake (stdake) <std...@cisco.com<mailto:std...@cisco.com>> wrote: On 7/27/16, 2:12 PM, "Jay Pipes" <jaypi...@gmail.com<mailto:jaypi...@gmail.com>> wrote:On 07/27/2016 04:42 PM, Ed Leafe wrote:On Jul 27, 2016, at 2:42 PM, Fox, Kevin M <kevin....@pnnl.gov<mailto:kevin....@pnnl.gov>> wrote:Its not an "end user" facing thing, but it is an "operator" facing thing.Well, the end user for Kolla is an operator, no?I deploy kolla containers today on non kolla managed systems in production, and rely on that api being consistent. I'm positive I'm not the only operator doing this either. This sounds like a consumable api to me.I don¹t think that an API has to be RESTful to be considered an interface for we should avoid duplication.Application *Programming* Interface. There's nothing that is being *programmed* or *called* in Kolla's image definitions. What Kolla is/has is not an API. As Stephen said, it's more of an Application Binary Interface (ABI). It's not really an ABI, though, in the traditional sense of the term that I'm used to. It's an agreed set of package bases, installation procedures/directories and configuration recipes for OpenStack and infrastructure components.Jay, From my perspective, this isn't about ABI proliferation or competition. This is about open public discourse. It is the responsibility of all community members to protect the four opens. Given the intent of fuel-ccp to fully adopt K8S into Fuel described here: https://techcrunch.com/2016/07/25/openstack-will-soon-be-able-to-run-on-top -of-kubernetes/ It is hard to understand the arguments in the reviews related to "this is an experimental project, so its not targeted towards big tent" yet Boris wrote in that press release its Fuel's next big thing. I raised the objection early on that a mission statement change was needed by Fuel if they wanted to proceed down this path, to which I was told K8S support is not going into big tent. As a result of Mirantis's change in mind about fuel-ccp being NOT experimental and being targeted for big tent, I'd like the record set straight in the governance repository since the intentions are being published in the press and the current intentions of this project are public. I could see how people could perceive many violations of the four opens in all of the activities related to the fuel-ccp project. We as a community value open discourse because we are all intelligent human beings. We value honesty and integrity because trust is the foundation of how our community operates. I feel the best way for Fuel to repair the perceived violations of the four opens going forward is to: 1. Alter the mission statement of fuel to match the reality being published by the press and Mirantis's executive team 2. Include these non-experimental repos in the projects.yaml governance repository That would satisfy my four opens concerns. If the Fuel PTL doesn't want to do these two things, I'd like a public explanation as to why from Vladimir who thus far has remained quiet on this thread. Thanks -steveI see no reason for the OpenStack community to standardize on those things, frankly. It's like asking RedHat and Canonical to agree to "just use RPM" as their package specification format. I wonder how that conversation would go. Best, -jay __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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://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
-- @flaper87 Flavio Percoco
signature.asc
Description: PGP signature
__________________________________________________________________________ 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
