Open Stack

On Thu, Jul 28, 2016 at 9:24 AM, Sergey Lukjanov <slukjanov at mirantis.com>
wrote:

> 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.
>
​All the other stuff aside, the above was my take away from the first or
second message in this thread so I fail to understand the debate around
this.  The mission statement is simply around deploying, how that deploy
mechanism is implemented (Kubernetes, Ironic whatever) doesn't really seem
to be an issue here.

The point about API's that Jay Pipes made was spot on in my opinion as
well.  We're not talking about service or project API's that the end users
or operators deal with on a daily basis.  Until there's a standard install
API I fail to see the argument against this.

Other questions about the 4 opens etc seem to have been answered, but I
don't have any real insight here.  Personally I'm looking forward to seeing
if somebody can come up with a reliable and relatively easy deployment
tool.  If it means competition then that's great as far as I'm concerned.
I'll use whichever one doesn't make me want to rip my hair out.

​


>
> 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.
>
> __________________________________________________________________________
> 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/20160729/e2fe8ad7/attachment.html>