Open Stack

On Sun, Apr 1, 2018 at 12:07 AM, Steven Dake (stdake) <stdake at cisco.com> wrote:
>
>
>
> On March 31, 2018 at 12:35:31 PM, Jeremy Stanley (fungi at yuggoth.org) wrote:
>
> On 2018-03-31 18:06:07 +0000 (+0000), Steven Dake (stdake) wrote:
>> I appreciate your personal interest in attempting to clarify the
>> Kolla mission statement.
>>
>> The change in the Kolla mission statement you propose is
>> unnecessary.
> [...]
>
> I should probably have been more clear. The Kolla mission statement
> right now says that the Kolla team produces two things: containers
> and deployment tools. This may make it challenging for the team to
> avoid tightly coupling their deployment tooling and images, creating
> a stratification of first-class (those created by the Kolla team)
> and second-class (those created by anyone else) support for
> deployment tools using those images.
>
>
> The problems raised in this thread (tension - tight coupling - second class
> citizens - stratification) was predicted early on - prior to Kolla 1.0.
> That prediction led to the creation of a technical solution - the Kolla API.
> This API permits anyone to reuse the containers as they see fit if they
> conform their implementation to the API.  The API is not specifically tied
> to the Ansible deployment technology.  Instead the API is tied to the
> varying requirements that various deployment teams have had in the past
> around generalized requirements for making container lifecycle management a
> reality while running OpenStack services and their dependencies inside
> containers.
>
> Is the intent to provide "a container-oriented deployment solution
> and the container images it uses" (kolla-ansible as first-class
> supported deployment engine for these images) or "container images
> for use by arbitrary deployment solutions, along with an example
> deployment solution for use with them" (kolla-ansible on equal
> footing with competing systems that make use of the same images)?
>
> My viewpoint is as all deployments projects are already on an equal footing
> when using Kolla containers.

While I acknowledge Kolla reviewers are doing a very good job at
treating all incoming reviews equally, we can't realistically state
these projects stand on an equal footing today.
At the very least we need to have kolla changes _gating_ on TripleO
and OSH jobs before we can say so. Of course, I'm not saying other
kolla devs are opposed to adding more CI jobs to kolla, I'm pretty
sure they would welcome the changes if someone volunteers for it, but
right now when I'm approving a kolla patches I can only say with
confidence that it does not break kolla-ansible. In that sense,
kolla_ansible is special.

> I would invite the TripleO team who did integration with the Kolla API to
> provide their thoughts.

The Kolla API is stable and incredibly useful... it's also
undocumented. I have a stub for a documentation change that's been
collecting dust on my hard drive for month, maybe it's time I brush it
up and finally submit it. Today unless you're a kolla developer
yourself, it's difficult to understand how to use the API, not the
most user friendly.

Another thing that comes for free with Kolla, the extend_start.sh
scripts are for the most part only useful in the context of
kolla_ansible. For instance, hardcoding path for log dirs to
/var/log/kolla and changing groups to 'kolla'.
In TripleO, we've chosen to not depend on the extend_start.sh scripts
whenever possible for this exact reason.

The other critical kolla feature we're making extensive use of in
TripleO is the ability to customize the image in any imaginable way
thanks to the template override mechanism. There would be no
containerized deployments via TripleO without it.

Kolla is a great framework for building container images for OpenStack
services any project can consume. We could do a better job at
advertising it. I guess bringing kolla and kolla-kubernetes under
separate governance (even it the team remains mostly the same) is one
way to enforce the independence of kolla-the-images project and
recognize people may be interested in the images but not the
deployment tools.

One last though. Would you imagine a kolla PTL who is not heavily
invested in kolla_ansible?

Martin

> I haven't kept up with OSH development, but perhaps that team could provide
> their viewpoint as well.
>
>
> Cheers
>
> -steve
>
>
> --
> Jeremy Stanley
> __________________________________________________________________________
> 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
>