Hi Lance and everybody thanks for recap. With respect to *moving legacy clients to python-openstackclient*. At the page Lance already mentioned [1] bottom I have listed different options and a small volunteering table to understand what will be feasible to achieve. If people are interested and ready to contribute - please fill yourself in. I personally do not think any target is reachable, unless people start picking things to be done. [1] https://etherpad.openstack.org/p/osc-gaps-analysis Regards, Artem On Thu, Jan 31, 2019 at 5:03 PM Lance Bragstad <lbragstad@gmail.com> wrote:
Hello everyone,
I thought it would be good to have a quick recap of the various goal proposals.
*Project clean-up*
Adrian and Tobias Rydberg have volunteered to champion the goal. There has also been some productive discussion around the approaches detailed in the etherpad [0]. At this point is it safe to assume we've come to a conclusion on the proposed approach? If so, I think the next logical step would be to do a gap analysis on what the proposed approach would mean work-wise for all projects. Note, Assaf Muller brought the approach Neutron takes to my attention [1] and I wanted to highlight this here since it establishes a template for us to follow, or at least look at. Note, Neutron's approach is client-based, which might not be orthogonal with the client goal. Just something to keep in mind if those two happen to be accepted for the same release.
[0] https://etherpad.openstack.org/p/community-goal-project-deletion [1] https://github.com/openstack/python-neutronclient/blob/master/neutronclient/...
*Moving legacy clients to python-openstackclient*
Artem has done quite a bit of pre-work here [2], which has been useful in understanding the volume of work required to complete this goal in its entirety. I suggest we look for seams where we can break this into more consumable pieces of work for a given release.
For example, one possible goal would be to work on parity with python-openstackclient and openstacksdk. A follow-on goal would be to move the legacy clients. Alternatively, we could start to move all the project clients logic into python-openstackclient, and then have another goal to implement the common logic gaps into openstacksdk. Arriving at the same place but using different paths. The approach still has to be discussed and proposed. I do think it is apparent that we'll need to break this up, however.
[2] https://etherpad.openstack.org/p/osc-gaps-analysis
*Healthcheck middleware*
There is currently no volunteer to champion for this goal. The first iteration of the work on the oslo.middleware was updated [3], and a gap analysis was started on the mailing lists [4]. If you want to get involved in this goal, don't hesitate to answer on the ML thread there.
[3] https://review.openstack.org/#/c/617924/2 [4] https://ethercalc.openstack.org/di0mxkiepll8
Just a reminder that we would like to have all potential goals proposed for review in openstack/governance by the middle of this month, giving us 6 weeks to hash out details in Gerrit if we plan to have the goals merged by the end of March. This timeframe should give us 4 weeks to prepare any discussions we'd like to have in-person pertaining to those goals.
Thanks for the time,
Lance
On Tue, Jan 8, 2019 at 4:11 AM Jean-Philippe Evrard < jean-philippe@evrard.me> wrote:
On Wed, 2018-12-19 at 06:58 +1300, Adrian Turjak wrote:
I put my hand up during the summit for being at least one of the champions for the deletion of project resources effort.
I have been meaning to do a follow up email and options as well as steps for how the goal might go, but my working holiday in Europe after the summit turned into more of a holiday than originally planned.
I'll get a thread going around what I (and the public cloud working group) think project resource deletion should look like, and what the options are, and where we should aim to be with it. We can then turn that discussion into a final 'spec' of sorts.
Great news!
Do you need any help to get started there?
Regards, JP