Open Stack

On Mon, Apr 2, 2018 at 4:38 PM, Steven Dake (stdake) <stdake at cisco.com> wrote:
>
>
>
> On April 2, 2018 at 6:00:15 AM, Martin André (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 and conditions as someone you are 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.

Collaboration is good, there is no question about it.
I suppose the question we need to answer is "would splitting kolla and
kolla-ansible further benefit kolla and the projects that consume
it?". I believe if you look at it from this angle maybe you'll find
areas that are neglected because they are lower priority for
kolla-ansible developers.

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

One could argue that the environment variables we pass to the
containers to control what extend_start.sh does are also part of the
API. That's not my point. There is a lot of cruft in these scripts
that remain from the days where kolla-ansible was the only consumer of
kolla images.

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

All I'm saying is that we can't truly claim we've fully decoupled
Kolla and Kolla-ansible until we're ready to accept someone who is not
a dedicated contributor to kolla-ansible as kolla PTL. Until then,
some might rightfully say kolla-ansible is driving the kolla project.
It's OK, maybe as the kolla community that's what we want, but we
can't legitimately say all consumers are on an equal footing.

Martin