On 09/26/2018 01:55 PM, Tim Bell 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)

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.

++

It's also worth noting that we're REALLY close to a 1.0 of openstacksdk (all the patches are in flight, we just need to land them) - and once we've got that we'll be in a position to start shifting python-openstackclient to using openstacksdk instead of python-*client.

This will have the additional benefit that, once we've migrated CLIs to python-openstackclient as per this goal, and once we've migrated openstackclient itself to openstacksdk, the number of different libraries one needs to install to interact with openstack will be _dramatically_ lower.

-----Original Message-----
From: Doug Hellmann <d...@doughellmann.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Wednesday, 26 September 2018 at 18:00
To: openstack-dev <openstack-dev@lists.openstack.org>, openstack-operators 
<openstack-operat...@lists.openstack.org>, openstack-sigs 
<openstack-s...@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-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

Reply via email to