Open Stack

+1 to one more pass at using the same images. Doing so will become 
practically impossible in a matter of weeks or months, and in the long 
term the additional shared human resources outweigh the interpersonal 
complexities (and for any who don't think so - maybe you're wasting your 
time here?).


Logically, I just view Kolla's existing containers as a thin wrapper 
around OpenStack projects' debs and rpms (though I understand there are 
many differences from a purely technical standpoint, and that the 
containers can be built entirely from source instead). I suppose I view 
them this way because building the existing containers creates 
deployable artifacts (that is, the images) and these images have a lot 
of the same qualities as traditional deb/rpm packages. The resulting 
artifacts in both cases are somewhat immutable, they both put programs 
in certain places, both expect configs in certain places, both configure 
logs to be written in certain places, etc. In fact a lot of these 
locations in the container's case are dictated by where they are 
expected in the packages. Sharing the images could further standardize 
things.


This is different IMHO than deployment tooling in the usual 
configuration management sense, which I presume is one of the reasons 
for this possible Kolla repo-split to begin with. I certainly see the 
upsides to having a diverse set of tooling to deploy project artifacts 
(deb/rpm/container image/git commit [i.e. from source]), but I don't get 
duplicating the artifacts themselves over relatively simple 
technicalities. I highly doubt anyone would create a major packaging 
variation in the deb/rpm packaging (perhaps where all OpenStack projects 
are deployable from a single rpm or deb [wouldn't that be fun!], or 
perhaps a switch to FPM) merely because it made sense for a new 
deployment project. (to be clear though, I am in general happy to have 
more deployment options coming online)


Thank you,
Mark


On 7/28/2016 8:56 AM, 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.
>
> 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?
>
> Thanks,
> Kevin
> ------------------------------------------------------------------------
> *From:* Vladimir Kozhukalov [vkozhukalov at 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 off
>
> >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
>
>
> Frankly, 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) 
> <stdake at cisco.com <mailto:stdake at cisco.com>> wrote:
>
>
>
>     On 7/27/16, 2:12 PM, "Jay Pipes" <jaypipes at gmail.com
>     <mailto:jaypipes at 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.Fox at pnnl.gov
>     <mailto:Kevin.Fox at 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/
>     <https://techcrunch.com/2016/07/25/openstack-will-soon-be-able-to-run-on-top%0A-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
>     -steve
>
>
>
>
>     >
>     >I 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-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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://OpenStack-dev-request@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/20160728/eca066cf/attachment.html>