Oh, very definitely +1000
-------------------------------------------------- Rochelle Grober Rochelle Grober M: +1-6508889722<tel:+1-6508889722>(preferred) E: rochelle.gro...@huawei.com<mailto:rochelle.gro...@huawei.com> 2012<tel:2012>实验室-硅谷研究所技术规划及合作部 2012<tel:2012> Laboratories-Silicon Valley Technology Planning & Cooperation,Silicon Valley Research Center From:Mathieu Gagné To:openstack-s...@lists.openstack.org, Cc:OpenStack Development Mailing List (not for usage questions),OpenStack Operators, Date:2018-09-26 12:41:24 Subject:Re: [Openstack-sigs] [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series +1 Yes please! -- Mathieu On Wed, Sep 26, 2018 at 2: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) > > 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-sigs mailing list > openstack-s...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs _______________________________________________ openstack-sigs mailing list openstack-s...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
__________________________________________________________________________ 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
