Open Stack

Hi folks,

First of all, let me say that it’s a marketing announcement and as all of
you know such announcements aren’t precise from a technical side.
Personally I’ve seen this paper first time on TechCrunch.

First of all, fuel-ccp-* are a set of OpenStack projects and everyone is
welcome to participate. All the regular community process(es) for other
openstack projects apply to fuel-ccp-*. At the moment, in spite of what the
marketing announcements say, it’s a bunch of people from Mirantis working
on the repositories. Please think of this as an incubation process to try
and see what the next incarnation of Fuel would look like in the future.

Regardless of what was written, we aren’t applying to the Big Tent right
now (as it was initially said explicitly when we were creating repos and
it’s still valid). The state of the repos is still experimental, but I’d
like to make things clear and confirm that Mirantis has chosen to use
containers for infrastructure and OpenStack components and to use
Kubernetes as the orchestrator of those containers. In the future, the Fuel
OpenStack installer will use these containerized OpenStack/infrastructure
component images. There are many questions to be solved and things to be
done first in Fuel CCP, such as:

* Freeze technologies and approaches, such as repos structure, image
layers, etc.
* Cleanup deprecated PoC stuff from the code
* Implement basic test coverage for all parts of the project
* Create Release Management approach
* Consume OpenStack CI to run tests
* Fully implement 3rd party CI (with end-to-end integration tests only)
* Make at least initial documentation and ensure that it’s deployable using
this doc

and etc. In general, I would not expect us to seriously consider applying
to the Big Tent for another 5-6 months at the earliest.

Regarding the Fuel mission, that is:

    To streamline and accelerate the process of deploying, testing and
maintaining various configurations of OpenStack at scale.

I think that it’s 100% aligned with that we’re doing in Fuel CCP.

About the Kolla usage in Fuel CCP, I agree with Kevin and we can see in
future that Fuel CCP will be potentially using Kolla containers, it’ll
require some time anyway, but it doesn’t mean that we stop considering it.
And as Kevin correctly noticed, we did it already one time with Fuel
adopting upstream Puppet modules and contributing actively to them.

Thanks.


On Thu, Jul 28, 2016 at 7:43 AM, Flavio Percoco <flavio at redhat.com> wrote:

> On 28/07/16 04:45 +0000, Steven Dake (stdake) 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.
>>
>
> If I can be honest, I think this whole thread is not going anywhere
> because it
> just started based on the wrong assumption, the wrong tone and with poor
> wording. I'd have asked for clarifications before demanding changes from
> anyone.
> To me, the way this thread started violates one of principles of our
> community,
> which is assuming good faith. I'll assume good faith now and interpret this
> thread as a hope to clarify the goals and intentions of this projects and
> not as
> a way to bluntly point fingers, which is how some people might have
> perceived
> it.
>
> 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:
>>
>
> I honestly don't see the violation. The fuel team added these repos and
> explicitly said they are not planning to join the tent right now. Adding
> new
> repos called `fuel-blah` won't make those deliverables official. Whenever
> the
> team decides to make these deliverables part of Fuel, they'll have to send
> a
> patch to the governance repo.
>
> So, again, where's the lack of openess? Is it just based on the content of
> the
> press release? I'm mostly asking because I don't personally read press
> releases
> when reviewing patches for the governance repo. I do see the inconsistency
> between the press release and what's in the repos/reviews but I in those
> cases,
> the governance repository is the source of truth not the press release.
>
> 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
>>
>
> What would have happened if the project names would've been
> "my-super-openstack-container-project"?
>
> Flavio
>
> --
> @flaper87
> Flavio Percoco
>
> __________________________________________________________________________
> 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
>
>


-- 
Sincerely yours,
Sergey Lukjanov
Sr. Development Manager
Mirantis Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160728/2dc1d20d/attachment.html>