On April 2, 2018 at 6:00:15 AM, Martin André (m.an...@redhat.com<mailto: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<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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
