Open Stack

On 28/07/16 15:48 +0300, Vladimir Kozhukalov wrote:
>>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.

TBH, I also think this statement is broad enough to cover containers. Unless the
request is to explicitly mention "containers" in the mission statement, I think
there's no need to change it. I'd also be against having "containers" being
explicitly mentioned in Fuel's statement, FWIW. I don't think it'd be of any
benefit/use. Unless I'm missing something fundamental here, of course.

>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).

++

Flavio

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

>__________________________________________________________________________
>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


-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 847 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160728/c9aa7731/attachment.pgp>