[tc][all] Train Community Goals

Artem Goncharov artem.goncharov at gmail.com
Thu Jan 31 16:52:02 UTC 2019


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 at 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/neutron/v2_0/purge.py
>
> *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 at 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
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190131/b295b094/attachment-0001.html>


More information about the openstack-discuss mailing list