Open Stack

Ack - thanks for the clarification, Tim.

On Thu, Sep 27, 2018 at 12:10 PM Tim Bell <Tim.Bell at cern.ch> wrote:

>
>
> 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> 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
>
> __________________________________________________________________________
> 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/f2ed5071/attachment.html>