Open Stack

>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>
wrote:

>
>
> On 7/27/16, 2:12 PM, "Jay Pipes" <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> 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
> -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://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/918429d4/attachment.html>