Merge "Deprecate individual CLIs in favour of OSC"
This commit is contained in:
commit
16a0fe966c
|
@ -0,0 +1,192 @@
|
||||||
|
=========================
|
||||||
|
Deprecate Individual CLIs
|
||||||
|
=========================
|
||||||
|
|
||||||
|
https://blueprints.launchpad.net/+spec/deprecate-clis
|
||||||
|
|
||||||
|
Historically, each service has offered a CLI application that is included with
|
||||||
|
the python-\*client that provides administrative and user control over the
|
||||||
|
service. With the popularity of OpenStack Client and the majority of functions
|
||||||
|
having been implemented there we should look to officially deprecate the
|
||||||
|
individual CLI applications.
|
||||||
|
|
||||||
|
This does not imply that the entire python-\*client will be deprecated, just
|
||||||
|
the CLI portion of the library. The python bindings are expected to continue to
|
||||||
|
work.
|
||||||
|
|
||||||
|
Problem description
|
||||||
|
===================
|
||||||
|
|
||||||
|
There is currently no standard workflow for interacting with OpenStack services
|
||||||
|
on the command line. In the beginning it made sense that there was a nova CLI
|
||||||
|
for working with nova. As keystone, glance and cinder split out they cloned
|
||||||
|
novaclient and adapted it to their needs. By the time neutron and the deluge of
|
||||||
|
big tent services came along there was a clear pattern that each service would
|
||||||
|
provide a CLI along with their library.
|
||||||
|
|
||||||
|
Given the common base and some strong persuasion there is at least a common
|
||||||
|
subset of parameters and environment variables that are accepted by all CLI
|
||||||
|
applications. However as new features come up such as YAML based configuration,
|
||||||
|
keystone's v3 authentication or SSL handling issues these must be addressed in
|
||||||
|
each project individually and the way these parameters are handled have
|
||||||
|
drifted or are supported to various levels.
|
||||||
|
|
||||||
|
This also creates a horrible user experience for those trying to interact with
|
||||||
|
the CLI as you have to continually switch between different formatting, command
|
||||||
|
structures, capabilities and requires a deep knowledge of which service is
|
||||||
|
responsible for different tasks - a pattern we have been trying to break in
|
||||||
|
favour of a unified OpenStack interface.
|
||||||
|
|
||||||
|
To deal with this the OpenStack client project has now been around for nearly 2
|
||||||
|
years. It provides a pluggable way to register CLI tasks and a common place to
|
||||||
|
fix security and usability issues.
|
||||||
|
|
||||||
|
Proposed change
|
||||||
|
===============
|
||||||
|
|
||||||
|
Whilst there has been general support for the OpenStack Client project and
|
||||||
|
support from individual services (it is the primary/supported CLI for keystone
|
||||||
|
and several newer services) there is no clear direction on whether our users
|
||||||
|
should use it or continue using the project specific CLIs. Similarly there is
|
||||||
|
no clear direction on whether developers should contribute new features in
|
||||||
|
services to the service specific CLI or to OpenStack client.
|
||||||
|
|
||||||
|
This blueprint proposes that as a community we ratify that OpenStack Client is
|
||||||
|
to be the default supported CLI application going forward. This will give
|
||||||
|
services the direction to deprecate the project CLIs and start pushing their
|
||||||
|
new features to OpenStack Client. It will give our documentation teams the
|
||||||
|
direction to start using OpenStack Client as the command for setting up
|
||||||
|
functionality.
|
||||||
|
|
||||||
|
Given that various projects currently have different needs from their CLI I do
|
||||||
|
not expect that we will be immediately able to deprecate all CLIs. There may be
|
||||||
|
certain tasks for which there will always need to be a project specific CLI.
|
||||||
|
The intent of this blueprint initially is not to provide a timeline or force
|
||||||
|
projects away from their own CLIs. Instead to provide direction to start
|
||||||
|
deprecating the CLIs for which OpenStack Client already has functionality
|
||||||
|
compatibility and properly start the process.
|
||||||
|
|
||||||
|
Alternatives
|
||||||
|
------------
|
||||||
|
|
||||||
|
We could look at an oslo project that handles the common components of CLI
|
||||||
|
generation such that we could standardize parameters and handle client creation
|
||||||
|
in a cross service way. There may be an advantage to doing this anyway as there
|
||||||
|
will likely always be tools that want to provide a CLI interface to an
|
||||||
|
OpenStack API that do not belong in OpenStack Client and these should remain
|
||||||
|
consistent.
|
||||||
|
|
||||||
|
Doing nothing is always an option. OpenStack client is steadily gaining
|
||||||
|
adoption naturally because it can quickly provide new features across a range
|
||||||
|
of services and so CLI deprecation may happen naturally over time. However
|
||||||
|
until then we must duplicate the effort of supporting features in multiple
|
||||||
|
places.
|
||||||
|
|
||||||
|
Implementation
|
||||||
|
==============
|
||||||
|
|
||||||
|
As with all OpenStack applications there will have to be a 2 cycle deprecation
|
||||||
|
period for all these tools.
|
||||||
|
|
||||||
|
There are multiple components to this spec and much of the work required will
|
||||||
|
have to be performed individually in each of the services and documentation
|
||||||
|
projects. The intention of this spec is to indicate to projects that this is
|
||||||
|
the direction of the community so we can figure out the project specific
|
||||||
|
requirements in those groups.
|
||||||
|
|
||||||
|
|
||||||
|
Assignee(s)
|
||||||
|
-----------
|
||||||
|
|
||||||
|
Primary assignee:
|
||||||
|
jamielennox
|
||||||
|
dtroyer
|
||||||
|
|
||||||
|
Work Items
|
||||||
|
----------
|
||||||
|
|
||||||
|
- Add a deprecation warning to clients that have OpenStack Client equivalent
|
||||||
|
functionality.
|
||||||
|
- Update documentation to use OpenStack Client commands instead of project
|
||||||
|
specific CLIs (see Documentation Impact).
|
||||||
|
- Remove CLI components from CLIs after deprecation period complete.
|
||||||
|
|
||||||
|
Service Impact
|
||||||
|
--------------
|
||||||
|
|
||||||
|
For most CLI applications we must first start emitting deprecation warnings for
|
||||||
|
the CLI tools that ship with the deployment libraries.
|
||||||
|
|
||||||
|
For core services most functionality is already present and maintained in the
|
||||||
|
OpenStack Client repository so they would need to ensure feature parity however
|
||||||
|
they would typically not require any additional code.
|
||||||
|
|
||||||
|
As part of core functionality OSC currently supports:
|
||||||
|
|
||||||
|
- Nova
|
||||||
|
- Glance
|
||||||
|
- Cinder
|
||||||
|
- Swift
|
||||||
|
- Neutron
|
||||||
|
- Keystone
|
||||||
|
|
||||||
|
A number of additional projects have already implemented their CLI as an
|
||||||
|
OpenStack Client plugin. These projects will not be affected. Projects that
|
||||||
|
have not created plugins would need to implement a plugin that handles the
|
||||||
|
features they wish to expose via CLI.
|
||||||
|
|
||||||
|
Services that currently include an OpenStack Client plugin in their repository
|
||||||
|
include (but not limited to):
|
||||||
|
|
||||||
|
- Zaqar
|
||||||
|
- Sahara
|
||||||
|
- Designate
|
||||||
|
|
||||||
|
Documentation impact
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
This will be a fairly fundamental change in the way we have communicated with
|
||||||
|
users to consume openstack and so will require significant documentation
|
||||||
|
changes.
|
||||||
|
|
||||||
|
This will include (but not limited to):
|
||||||
|
|
||||||
|
- Install Guides
|
||||||
|
- Admin Guide
|
||||||
|
- Ops Guide
|
||||||
|
- CLI Reference can be deprecated or redirected to OpenStack Client
|
||||||
|
documentation.
|
||||||
|
|
||||||
|
The OpenStack Client is already in use and deployed as a part of most
|
||||||
|
installations (it is required for keystone). Therefore changes to documentation
|
||||||
|
would not be dependant on any work happening in the services. The spec attempts
|
||||||
|
to ratify that this is the correct approach.
|
||||||
|
|
||||||
|
Dependencies
|
||||||
|
============
|
||||||
|
|
||||||
|
There have been many required steps to this goal such as os-client-config,
|
||||||
|
keystoneauth, cliff, stevedore and the work that has already gone into
|
||||||
|
OpenStack client. We are now at the point where we can move forward with the
|
||||||
|
change.
|
||||||
|
|
||||||
|
The OpenStack SDK is not listed as a dependency here because it is not
|
||||||
|
currently a dependency of OpenStack Client. It is intended that when OpenStack
|
||||||
|
SDK is released it will be consumed by OpenStack Client however that can be
|
||||||
|
considered an implementation detail.
|
||||||
|
|
||||||
|
History
|
||||||
|
=======
|
||||||
|
|
||||||
|
.. list-table:: Revisions
|
||||||
|
:header-rows: 1
|
||||||
|
|
||||||
|
* - Release Name
|
||||||
|
- Description
|
||||||
|
* - Mitaka
|
||||||
|
- Introduced
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
|
||||||
|
This work is licensed under a Creative Commons Attribution 3.0 Unported License.
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
Loading…
Reference in New Issue