[openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series

Lance Bragstad lbragstad at gmail.com
Thu Sep 27 13:28:42 UTC 2018


On Wed, Sep 26, 2018 at 1:56 PM Tim Bell <Tim.Bell at cern.ch> wrote:

>
> Doug,
>
> Thanks for raising this. I'd like to highlight the goal "Finish moving
> legacy python-*client CLIs to python-openstackclient" from the etherpad and
> propose this for a T/U series goal.
>
> To give it some context and the motivation:
>
> At CERN, we have more than 3000 users of the OpenStack cloud. We write an
> extensive end user facing documentation which explains how to use the
> OpenStack along with CERN specific features (such as workflows for
> requesting projects/quotas/etc.).
>
> One regular problem we come across is that the end user experience is
> inconsistent. In some cases, we find projects which are not covered by the
> unified OpenStack client (e.g. Manila). In other cases, there are subsets
> of the function which require the native project client.
>
> I would strongly support a goal which targets
>
> - All new projects should have the end user facing functionality fully
> exposed via the unified client
> - Existing projects should aim to close the gap within 'N' cycles (N to be
> defined)
> - Many administrator actions would also benefit from integration (reader
> roles are end users too so list and show need to be covered too)
> - Users should be able to use a single openrc for all interactions with
> the cloud (e.g. not switch between password for some CLIs and Kerberos for
> OSC)
>
>
Sorry to back up the conversation a bit, but does reader role require work
in the clients? Last release we incorporated three roles by default during
keystone's installation process [0]. Is the definition in the specification
what you mean by reader role, or am I on a different page?

[0]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html#default-roles


> The end user perception of a solution will be greatly enhanced by a single
> command line tool with consistent syntax and authentication framework.
>
> It may be a multi-release goal but it would really benefit the cloud
> consumers and I feel that goals should include this audience also.
>
> Tim
>
> -----Original Message-----
> From: Doug Hellmann <doug at doughellmann.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Date: Wednesday, 26 September 2018 at 18:00
> To: openstack-dev <openstack-dev at lists.openstack.org>,
> openstack-operators <openstack-operators at lists.openstack.org>,
> openstack-sigs <openstack-sigs at lists.openstack.org>
> Subject: [openstack-dev] [goals][tc][ptl][uc] starting goal selection for
> T     series
>
>     It's time to start thinking about community-wide goals for the T
> series.
>
>     We use community-wide goals to achieve visible common changes, push for
>     basic levels of consistency and user experience, and efficiently
> improve
>     certain areas where technical debt payments have become too high -
>     across all OpenStack projects. Community input is important to ensure
>     that the TC makes good decisions about the goals. We need to consider
>     the timing, cycle length, priority, and feasibility of the suggested
>     goals.
>
>     If you are interested in proposing a goal, please make sure that before
>     the summit it is described in the tracking etherpad [1] and that you
>     have started a mailing list thread on the openstack-dev list about the
>     proposal so that everyone in the forum session [2] has an opportunity
> to
>     consider the details.  The forum session is only one step in the
>     selection process. See [3] for more details.
>
>     Doug
>
>     [1] https://etherpad.openstack.org/p/community-goals
>     [2]
> https://www.openstack.org/summit/berlin-2018/vote-for-speakers#/22814
>     [3] https://governance.openstack.org/tc/goals/index.html
>
>
> __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
> OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180927/9787d199/attachment.html>


More information about the OpenStack-dev mailing list