On Mon, Apr 2, 2018 at 4:38 PM, Steven Dake (stdake) <std...@cisco.com> wrote: > > > > On April 2, 2018 at 6:00:15 AM, Martin André (m.an...@redhat.com) wrote: > > On Sun, Apr 1, 2018 at 12:07 AM, Steven Dake (stdake) <std...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
