Open Stack

Lance,

The comment regarding ‘readers’ is more to explain that the distinction between ‘admin’ and ‘user’ commands is gradually reducing, where OSC has been prioritising ‘user’ commands.

As an example, we give the CERN security team view-only access to many parts of the cloud. This allows them to perform their investigations independently.  Thus, many commands which would be, by default, admin only are also available to roles such as the ‘readers’ (e.g. list, show, … of internals or projects which they are not in the members list)

I don’t think there is any implications for Keystone (and the readers role is a nice improvement to replace the previous manual policy definitions) but more of a question of which subcommands we should aim to support in OSC.

The *-manage commands such as nova-manage, I would consider, out of scope for OSC. Only admins would be migrating between versions or DB schemas.

Tim

From: Lance Bragstad <lbragstad at gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Date: Thursday, 27 September 2018 at 15:30
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series


On Wed, Sep 26, 2018 at 1:56 PM Tim Bell <Tim.Bell at cern.ch<mailto: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<mailto:doug at doughellmann.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Wednesday, 26 September 2018 at 18:00
To: openstack-dev <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>, openstack-operators <openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>>, openstack-sigs <openstack-sigs at lists.openstack.org<mailto: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://OpenStack-dev-request@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://OpenStack-dev-request@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/ea751fec/attachment.html>