Re: [openstack-dev] Forum Recap - Stein Release Goals

2018-06-05 Thread Doug Hellmann
Excerpts from Matt Riedemann's message of 2018-06-04 18:46:15 -0500:
> On 6/4/2018 4:20 PM, Doug Hellmann wrote:
> > See my comments on the other part of the thread, but I think this is too
> > optimistic until we add a couple of people to the review team on OSC.
> > 
> > Others from the OSC team who have a better perspective on how much work
> > is actually left may have a different opinion though?
> 
> Yeah that is definitely something I was thinking about in Vancouver.
> 
> Would a more realistic goal be to decentralize the OSC code, like the 
> previous goal about how tempest plugins were done? Or similar to the 
> docs being decentralized? That would spread the review load onto the 
> projects that are actually writing CLIs for their resources - which they 
> are already doing in their per-project clients, e.g. python-novaclient 
> and python-cinderclient.
> 

In the past we've tried to avoid that because we wanted some
consistency in the UI design. I don't know if it's time to give up
on that and reconsider dividing the commands into multiple repos,
or just ask that people participate in building this tool for our
users. I don't think it would be any more complicated to do the
work in the OSC repo and gain some minimal experience that could
let folks become cores than it would be to do the same work in a
repo where they are already core. The plugin APIs are relatively
stable so it's basically the same code.

Doug

__
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


Re: [openstack-dev] Forum Recap - Stein Release Goals

2018-06-04 Thread Matt Riedemann

On 6/4/2018 4:20 PM, Doug Hellmann wrote:

See my comments on the other part of the thread, but I think this is too
optimistic until we add a couple of people to the review team on OSC.

Others from the OSC team who have a better perspective on how much work
is actually left may have a different opinion though?


Yeah that is definitely something I was thinking about in Vancouver.

Would a more realistic goal be to decentralize the OSC code, like the 
previous goal about how tempest plugins were done? Or similar to the 
docs being decentralized? That would spread the review load onto the 
projects that are actually writing CLIs for their resources - which they 
are already doing in their per-project clients, e.g. python-novaclient 
and python-cinderclient.


--

Thanks,

Matt

__
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


Re: [openstack-dev] Forum Recap - Stein Release Goals

2018-06-04 Thread Doug Hellmann
Excerpts from Matt Riedemann's message of 2018-06-04 15:26:28 -0500:
> On 5/31/2018 3:59 PM, Sean McGinnis wrote:
> > We were also able to already identify some possible goals for the T cycle:
> > 
> > - Move all CLIs to python-openstackclient
> 
> My understanding was this is something we could do for Stein provided 
> some heavy refactoring in the SDK and OSC got done first in Rocky. Or is 
> that being too aggressive?
> 

See my comments on the other part of the thread, but I think this is too
optimistic until we add a couple of people to the review team on OSC.

Others from the OSC team who have a better perspective on how much work
is actually left may have a different opinion though?

Doug

__
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


Re: [openstack-dev] Forum Recap - Stein Release Goals

2018-06-04 Thread Matt Riedemann

On 5/31/2018 3:59 PM, Sean McGinnis wrote:

We were also able to already identify some possible goals for the T cycle:

- Move all CLIs to python-openstackclient


My understanding was this is something we could do for Stein provided 
some heavy refactoring in the SDK and OSC got done first in Rocky. Or is 
that being too aggressive?


--

Thanks,

Matt

__
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-dev] Forum Recap - Stein Release Goals

2018-05-31 Thread Sean McGinnis
Here's my attempt to recap the goal selection discussion we had last week at
the Forum. Feel free to correct any misstatements and continue the discussion.

For reference, here's the etherpad from the discussion:

https://etherpad.openstack.org/p/YVR-S-release-goals

Overall Goal Discussion
===

We started off by discussing the reason for having the release cycle goals and
what we should actually be trying to achieve with them. There were some who
expressed concerns about the current Rocky goal selections not being the right
things we should be focusing on. The hope with the first part was to come to
some sort of agreement, or at least common understanding, that would inform our
selections for Stein.

Some thought the goals should be entirely operator facing. So things that have
an obvious and direct improvement for operators. At least so far, our goal
selection has mostly been to try to get one goal that is a visible thing like
that while the other is more of a technical debt cleanup. The idea being that
the tech debt ones will keep us in a good and healthy position to be able to
continue to address operator and user needs more easily.

There was also a desire to make the goals more "fully baked" before making them
a goal. This would mean having the necessary changes well documented with
example patches for teams to refer to to help guide them in figuring out what
needs to be done in their own repos.

There was also the desire to make these goals something that can generate some
excitement and be things that can be more of a marketing message. Things like
"OpenStack services now support live configuration changes" vs. "OpenStack got
rid of a testing library that no one has heard of".

And I almost missed it, but there was a great suggestion to have a #goals
channel for folks to go to for help and to discuss goal implementation. I
really like this idea and will bring it up in the next TC office hour to see if
we can get something official set up.

Stein Goals
===

We ended up with only 10-15 minutes to actually discuss some ideas for goal
selection for Stein. This was expected and planned. It will take some further
discussion and thought before I think we are ready to actually pick some goals.

Some of the more popular ones brought up in the session were:

- Cold upgrade support
- Python 3 first
- Addition of "upgrade check" CLIs

We were also able to already identify some possible goals for the T cycle:

- Move all CLIs to python-openstackclient
- Adopt a larger set of default roles

We've been collecting a "goal backlog" with these and other ideas here:

https://etherpad.openstack.org/p/community-goals

---
Sean (smcginnis)

__
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