Ack - thanks for the clarification, Tim. On Thu, Sep 27, 2018 at 12:10 PM Tim Bell <tim.b...@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 <lbrags...@gmail.com> > *Reply-To: *"OpenStack Development Mailing List (not for usage > questions)" <openstack-dev@lists.openstack.org> > *Date: *Thursday, 27 September 2018 at 15:30 > *To: *"OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@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.b...@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 <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 >
__________________________________________________________________________ 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