Mailing List Archive

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 <doug@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-operators@lists.openstack.org>, openstack-sigs <openstack-sigs@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

+1 :)
________________________________________
From: Tim Bell [Tim.Bell@cern.ch]
Sent: Wednesday, September 26, 2018 11:55 AM
To: OpenStack Development Mailing List (not for usage questions); openstack-operators; openstack-sigs
Subject: Re: [Openstack-sigs] [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series

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 <doug@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-operators@lists.openstack.org>, openstack-sigs <openstack-sigs@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
openstack-sigs mailing list
openstack-sigs@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

+1

-----Original Message-----
From: Tim Bell [mailto:Tim.Bell@cern.ch]
Sent: Wednesday, September 26, 2018 1:56 PM
To: OpenStack Development Mailing List (not for usage questions); openstack-operators; openstack-sigs
Subject: Re: [Openstack-sigs] [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series


[EXTERNAL EMAIL]
Please report any suspicious attachments, links, or requests for sensitive information.



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 <doug@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-operators@lists.openstack.org>, openstack-sigs <openstack-sigs@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
openstack-sigs mailing list
openstack-sigs@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

+1
I encountered the negative effects of the disparity between the cinder cli and OpenStack cli just an hour before receiving Tim’s reply. The missing features of OpenStack client relative to individual project clients trip me up multiple times per week on average.

Sent from my iPad

> On Sep 26, 2018, at 2:55 PM, Tim Bell <Tim.Bell@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 <doug@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-operators@lists.openstack.org>, openstack-sigs <openstack-sigs@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@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

+1 Yes please!

--
Mathieu

On Wed, Sep 26, 2018 at 2:56 PM Tim Bell <Tim.Bell@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 <doug@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-operators@lists.openstack.org>, openstack-sigs <openstack-sigs@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@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> openstack-sigs mailing list
> openstack-sigs@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

On 26/09/18 18:55 +0000, 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).

Tim,

First, I endorse this goal.

That said, lack of coverage of Manila in the OpenStack client was
articulated as a need (by CERN and others) during the Vancouver Forum.

At the recent Manila PTG we set addressing this technical debt as a
Stein cycle goal, as well as OpenStack SDK integration for Manila.

-- Tom Barron (tbarron)

> 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 <doug@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-operators@lists.openstack.org>, openstack-sigs <openstack-sigs@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@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>_______________________________________________
>openstack-sigs mailing list
>openstack-sigs@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

On 9/26/2018 3:01 PM, Doug Hellmann wrote:
> Monty Taylor<mordred@inaugust.com> writes:
>
>> 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.

I would personally like to thank the person that put that goal in the
etherpad...they must have had amazing foresight and unparalleled modesty.

>>>
>>> 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.
> Would it be useful to have the SDK work in OSC as a prerequisite to the
> goal work? I would hate to have folks have to write a bunch of things
> twice.
>
> Do we have any sort of list of which projects aren't currently being
> handled by OSC? If we could get some help building such a list, that
> would help us understand the scope of the work.

I started documenting the compute API gaps in OSC last release [1]. It's
a big gap and needs a lot of work, even for existing CLIs (the cold/live
migration CLIs in OSC are a mess, and you can't even boot from volume
where nova creates the volume for you). That's also why I put something
into the etherpad about the OSC core team even being able to handle an
onslaught of changes for a goal like this.

>
> As far as admin features, I think we've been hesitant to add those to
> OSC in the past, but I can see the value. I wonder if having them in a
> separate library makes sense? Or is it better to have commands in the
> tool that regular users can't access, and just report the permission
> error when they try to run the command?

I thought the same, and we talked about this at the Austin summit, but
OSC is inconsistent about this (you can live migrate a server but you
can't evacuate it - there is no CLI for evacuation). It also came up at
the Stein PTG with Dean in the nova room giving us some direction. [2] I
believe the summary of that discussion was:

a) to deal with the core team sprawl, we could move the compute stuff
out of python-openstackclient and into an osc-compute plugin (like the
osc-placement plugin for the placement service); then we could create a
new core team which would have python-openstackclient-core as a superset

b) Dean suggested that we close the compute API gaps in the SDK first,
but that could take a long time as well...but it sounded like we could
use the SDK for things that existed in the SDK and use novaclient for
things that didn't yet exist in the SDK

This might be a candidate for one of these multi-release goals that the
TC started talking about at the Stein PTG. I could see something like
this being a goal for Stein:

"Each project owns its own osc-<service_type> plugin for OSC CLIs"

That deals with the core team and sprawl issue, especially with stevemar
being gone and dtroyer being distracted by shiny x-men bird related
things. That also seems relatively manageable for all projects to do in
a single release. Having a single-release goal of "close all gaps across
all service types" is going to be extremely tough for any older projects
that had CLIs before OSC was created (nova/cinder/glance/keystone). For
newer projects, like placement, it's not a problem because they never
created any other CLI outside of OSC.

[1] https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc
[2] https://etherpad.openstack.org/p/nova-ptg-stein (~L721)

--

Thanks,

Matt

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Oh, very definitely +1000



--------------------------------------------------
Rochelle Grober Rochelle Grober
M: +1-6508889722<tel:+1-6508889722>(preferred)
E: rochelle.grober@huawei.com<mailto:rochelle.grober@huawei.com>
2012<tel:2012>???-?????????????
2012<tel:2012> Laboratories-Silicon Valley Technology Planning & Cooperation,Silicon Valley Research Center
From:Mathieu Gagné
To:openstack-sigs@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.Bell@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 <doug@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-operators@lists.openstack.org>, openstack-sigs <openstack-sigs@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@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> openstack-sigs mailing list
> openstack-sigs@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs

_______________________________________________
openstack-sigs mailing list
openstack-sigs@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs

Dean Troyer <dtroyer@gmail.com> writes:

> On Wed, Sep 26, 2018 at 3:44 PM, Matt Riedemann <mriedemos@gmail.com> wrote:
>> I started documenting the compute API gaps in OSC last release [1]. It's a
>> big gap and needs a lot of work, even for existing CLIs (the cold/live
>> migration CLIs in OSC are a mess, and you can't even boot from volume where
>> nova creates the volume for you). That's also why I put something into the
>> etherpad about the OSC core team even being able to handle an onslaught of
>> changes for a goal like this.
>
> The OSC core team is very thin, yes, it seems as though companies
> don't like to spend money on client-facing things...I'll be in the
> hall following this thread should anyone want to talk...
>
> The migration commands are a mess, mostly because I got them wrong to
> start with and we have only tried to patch it up, this is one area I
> think we need to wipe clean and fix properly. Yay! Major version
> release!

I definitely think having details about the gaps would be a prerequisite
for approving a goal, but I wonder if that's something 1 person could
even do alone. Is this an area where a small team is needed?

>> I thought the same, and we talked about this at the Austin summit, but OSC
>> is inconsistent about this (you can live migrate a server but you can't
>> evacuate it - there is no CLI for evacuation). It also came up at the Stein
>> PTG with Dean in the nova room giving us some direction. [2] I believe the
>> summary of that discussion was:
>
>> a) to deal with the core team sprawl, we could move the compute stuff out of
>> python-openstackclient and into an osc-compute plugin (like the
>> osc-placement plugin for the placement service); then we could create a new
>> core team which would have python-openstackclient-core as a superset
>
> This is not my first choice but is not terrible either...

We built cliff to be based on plugins to support this sort of work
distribution, right?

>> b) Dean suggested that we close the compute API gaps in the SDK first, but
>> that could take a long time as well...but it sounded like we could use the
>> SDK for things that existed in the SDK and use novaclient for things that
>> didn't yet exist in the SDK
>
> Yup, this can be done in parallel. The unit of decision for use sdk
> vs use XXXclient lib is per-API call. If the client lib can use an
> SDK adapter/session it becomes even better. I think the priority for
> what to address first should be guided by complete gaps in coverage
> and the need for microversion-driven changes.
>
>> This might be a candidate for one of these multi-release goals that the TC
>> started talking about at the Stein PTG. I could see something like this
>> being a goal for Stein:
>>
>> "Each project owns its own osc-<service_type> plugin for OSC CLIs"
>>
>> That deals with the core team and sprawl issue, especially with stevemar
>> being gone and dtroyer being distracted by shiny x-men bird related things.
>> That also seems relatively manageable for all projects to do in a single
>> release. Having a single-release goal of "close all gaps across all service
>> types" is going to be extremely tough for any older projects that had CLIs
>> before OSC was created (nova/cinder/glance/keystone). For newer projects,
>> like placement, it's not a problem because they never created any other CLI
>> outside of OSC.

Yeah, I agree this work is going to need to be split up. I'm still not
sold on the idea of multi-cycle goals, personally.

> I think the major difficulty here is simply how to migrate users from
> today state to future state in a reasonable manner. If we could teach
> OSC how to handle the same command being defined in multiple plugins
> properly (hello entrypoints!) it could be much simpler as we could
> start creating the new plugins and switch as the new command
> implementations become available rather than having a hard cutover.
>
> Or maybe the definition of OSC v4 is as above and we just work at it
> until complete and cut over at the end. Note that the current APIs
> that are in-repo (Compute, Identity, Image, Network, Object, Volume)
> are all implemented using the plugin structure, OSC v4 could start as
> the breaking out of those without command changes (except new
> migration commands!) and then the plugins all re-write and update at
> their own tempo. Dang, did I just deconstruct my project?

It sure sounds like it. Congratulations!

I like the idea of moving the existing code into libraries, having
python-openstackclient depend on them, and then asking project teams for
more help with them.

> One thing I don't like about that is we just replace N client libs
> with N (or more) plugins now and the number of things a user must
> install doesn't go down. I would like to hear from anyone who deals
> with installing OSC if that is still a big deal or should I let go of
> that worry?

Don't package managers just deal with this? I can pip/yum/apt install
something and get all of its dependencies, right?

Doug

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators