On April 4, 2018 at 4:21:58 PM, Michał Jastrzębski (inc...@gmail.com<mailto:inc...@gmail.com>) wrote: On 4 April 2018 at 14:45, Brandon Jozsa <bjo...@jinkit.com> wrote: > I’ve been a part of the OpenStack-Helm project from the very beginning, and > there was a lot of early brainstorming on how we could collaborate and > contribute directly to Kolla-Kubernetes. In fact, this was the original > intent when we met with Kolla back in Barcelona. We didn’t like the idea of > fragmenting interested Kubernetes developers/operators in the > OpenStack-via-Kubernetes space. Whatever the project, we wanted all the > domain expertise concentrated on a single deployment effort. Even though > OSH/K-k8s couldn’t reach an agreement on how to handle configmaps (our > biggest difference from the start), there was a lot of early collaboration > between the project cores. Early K-k8s contributors may remember Halcyon, > which cores from both sides promoted for early development of > OpenStack-via-Kubernetes, regardless of the project. > > One of the requests from the initial OSH team (in Barcelona) was to formally > separate Kolla from Kolla-foo deployment projects, both at a project level > and from a core perspective. Why have the same cores giving +2’s to Kolla, > Kolla-Ansible, Kolla-Mesos (now dead) and Kolla-Kubernetes, who may not have > any interest in another given discipline? We wanted reviews to be timely, > and laser-focused, and we felt that this more atomic approach would benefit > Kolla in the end. But unfortunately there was heavy resistance with limited > yet very influential cores. I honestly think pushback was also because it > would mean that any Kolla sub-projects would be subject to re-acceptance as > big tent projects. Limited, but very influential cores sounds like bad community, and as it happens I was leading this community at that time, so I feel I should comment. We would love to increase number of cores (raise a limit) of images, but that comes with a cost. Cost being that person who would like to become a core would need to contribute to project in question and review other people contributions. Proper way to address this problem would be just that - contributing to Kolla and reviewing code. If I failed to notice contributions from someone who did that a lot (I hope I didn't), I'm sorry. This is best and only way to solve problem in question. I think you did the best you could, Michal. As I understand it there are essentially three active projects under Kolla today; Kolla, Kolla-Ansible, Kolla-Kubernetes (and others that have been abandoned or dead), and only Kolla shows up under the project navigator. I assume this means they are all still under one project umbrella? I think this is a bit of a stretch for a single-project core team, especially since there are fundamental differences between Ansible and Kubernetes. So my comment was far less about you or anyone personally as a PTL or core, but really more about the “laser-focused” discipline of the group as a whole. Kolla is the only project I am aware of that has this catch all mission allowing it to be any type of deployment that consumes Kolla as a base, and it leverages the same resources. In fact, any other container-based OpenStack projects have been met with a bit of a strange resistance. See: https://review.openstack.org/#/c/449224/ > > There were also countless discussions about the preservation of the Kolla > API, or Ansible + Jinja portions of Kolla-Ansible. It became clear to us > that Kubernetes wasn’t going to be the first class citizen for the > deployment model in Kolla-Kubernetes, forcing operators to troubleshoot > between OpenStack, Kolla (container builds), Ansible, Kubernetes, and Helm. > This is apparent still today. And while I understand the hesitation to > change Kolla/Kolla-Ansible, I think this code-debt has somewhat contributed > to sustainability of Kolla-Kubernetes. Somewhat to the point of tension, I > very much agree with Thierry’s comments earlier. How k8s wasn't first class citizen? I don't understand. All processes were the same, time in PTG was generous compared to ansible etc. More people uses Ansible due to it's maturity so it's obvious it's going to have better testing etc, but again, solved by contributions. I’m not talking about at a project level. I think Kolla has done a wonderful job in that respect. All of my comments above are about the mixed-use of technologies leveraged to drive the project. Compare how Kubernetes configmaps are generated for each of the projects. Then ask yourself what drove that design? Was it simplicity or adherence to previous debt/models? Technical details like these need to be called out (good/bad/indifferent), and planned for accordingly in the event that the projects do merge at some point. I think this is the most confusing part for new users, because both communities have been asked countless times “what are the differences between x and y”. I think the suggestion of combining the projects would really benefit OpenStack operators/users. > I want all of these projects to succeed but consolidation with purposeful > and deliberate planning, which Rich has so kindly agreed to do, could be the > right answer. So I +1 the idea, because I think it puts all like-minded > individuals on the same focus (for the overall benefit of OpenStack and the > overall OpenStack community). But we have to make sure there isn’t a lot of > fallout from the decision either. To Steve Dake's previous point, there > could be orphaned users/operators who feel “forced” into another project. I > would hate to see that. It would be nice to at least plan this with the > user-base and give them fair warning. And to this point, what is the active > specific Kolla-Kubernetes core? Who is “PTL” of Kolla-Kubernetes today? As per election results it's Jeffrey. > On the other hand, I think that OSH has some improvements to make as well. > Gating could use some help and the OpenStack-Infra team has been kindly > helping out recently (a huge "thank you" to them). Docs…I think docs could > always use some love. Please offer your experiences to the OSH team! We > would love to hear your user input. Ultimately, if users/operators want to > run something that even closely resembles production, then we need some > decent production quality docs as opposed to leveraging the nascent gate > scripts (Zuulv3 ansible+heat). Releases and release planning should be > addressed, as users/vendors are going to want to be closer to OpenStack > release dates (recent versions of OpenStack, Helm and Kubernetes). Clear and > open roadmaps, with potential use of community-led planning tools. Open > elections for PTL. Finally, the OSH team may still be be interested in > diversifying it’s core-base. Matt M. would have to address this. I know that > I was actively seeking cores when I was initially PTL, and > truthfully…there’s nobody nicer or easier to work with than Matt. He’s an > awesome PTL, and any project would be fortunate to have him. All these > things could all be improved on, but it requires a diverse base with a lot > of great ideas. Kolla has one of most diverse core team in OpenStack. As I said, all it takes is valuable reviews to become core. > That said, I am in favor of consolidation…if it makes sense and if there's a > strong argument for it. We just need to think what’s best for the OpenStack > community as a whole, and put away the positions of the individual projects > for a moment. To me, that makes things pretty clear, regardless of where the > commits are going. And with the +1’s, I think we’re hearing you. Now we just > have to plan it out and take action (on both sides). > > Brandon > > > On April 2, 2018 at 11:14:01 AM, Martin André (m.an...@redhat.com) wrote: > > 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 > > > __________________________________________________________________________ > 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