Open Stack

On April 2, 2018 at 6:00:15 AM, Martin André (m.andre at redhat.com<mailto:m.andre at redhat.com>) wrote:

On Sun, Apr 1, 2018 at 12:07 AM, Steven Dake (stdake) <stdake at cisco.com> wrote:
> 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.

Martin,

Personally I think all of OpenStack projects that have a dependency or inverse dependency should cross-gate.  For example, Nova should gate on kolla-ansible, and at one point I think they agreed to this, if we submitted gate work to do so.  We never did that.

Nobody from TripleO or OSH has submitted gates for Kolla.  Submit them and they will follow the standard mechanism used in OpenStack experimental->non-voting->voting (if people are on-call to resolve problems).  I don't think gating is relevant to equal footing.  TripleO for the moment has chosen to gate on their own image builds, which is fine.  If the gating should be enhanced, write the gates :)

Here is a simple definition from the internet:

"with the same rights<https://www.macmillandictionary.com/us/dictionary/american/right_3> and conditions<https://www.macmillandictionary.com/us/dictionary/american/condition_1> as someone you are competing<https://www.macmillandictionary.com/us/dictionary/american/competing> with"

Does that mean if you want to split the kolla repo into 40+ repos for each separate project, the core team will do that?  No.  Does that mean if there is a reasonable addition to the API the patch would merge?  Yes.

Thats right, deployment tools compete, but they also cooperate and collaborate.  The containers (atleast from my perspective) are an area where Kolla has chosen to collaborate.  FWIW I also think we have chosen to collobrate a bit in areas we compete (the deployment tooling itself).  Its a very complex topic.  Splitting the governance and PTLs doesn't change the makeup of the core review team who ultimately makes the decision about what is reasonable.

|

> 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

Most of Kolla unfortunately is undocumented.  The API is simple and straightforward enough that TripleO, OSH, and several proprietary vendors (the ones Jeffrey mentioned) have managed to implement deployment tooling that consume the API.  Documentation for any part of Kolla would be highly valued - IMO it is the Kolla project's biggest weakness.

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.

I don't disagree.  I was never fond of extend_start, and thought any special operations it provided belong in the API itself.  This is why there are mkdir operations and chmod/chown -R operations in the API.  The JSON blob handed to the API during runtime is where the API begins and ends.  The implementation (what set_cfg.py does with start.sh and extend_start.sh) are not part of the API but part of the API implementation.

I don't think I said anywhere the API is perfectly implemented.  I'm not sure I've ever seen this mythical perfection thing in an API anyway :)

Patches are welcome to improve the API to make it more general, as long as they maintain backward compatibility.


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.


We knew people would find creative ways to use the plugin templating technology, and help drive adoption of Kolla as a standard...

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?


Do you mean to imply a conflict of interest?  I guess I don't understand the statement.  Would you clarify please?

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
>

__________________________________________________________________________
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/20180402/ab3dc7ac/attachment.html>