Download Open-O CLI Project Proposal Mercury v_1_0 - the OPEN

Open-O CLI
One Command to command whole Open-O
v1.0
Project Proposal
[email protected]
Overview
• Project Name : Openo-CLI
• Repository name : openo-cli
• Project Description
– Provides Command Line interface (CLI) and java SDK (java client
library) for all Open-O services.
– One Command to command whole Open-O !!
– Any micro service based architecture, would provide
• Client SDK in different language
• CLI for different OS.
• Project Participants
– Huawei, ???
Why CLI/SDK needed ?
CLI:
– Helps to automation
– Helps to expand Open-O eco-system
• Existing operator environment
• New Business 3rd party integration
– operator-friendly
– concise/powerful
SDK (java api):
– Helps to avoid code-duplication/re-implementation
– Detects the REST API version/schema changes at compile time itself,
than run-time
– 1:1 mapping between REST API and java api
Problems faced in Sun release are addressed !
–
Problem: When micro-service (A) is used by more than one micro-services, say, B & C, both of these
services re-implemented/repeated the integration code for service A. in sun release, ESR and DM
services got integrated by many services and each of them re-implemented (copied) the code across.
Solution: As every micro-service provides sdk jars, dependent micro-services could directly use it via
maven dependency, instead of re-implement/repeating the code (copy & paste)
This will completely avoid maintenance over-head introduced in sun release
–
Problem: When a micro-service (A) depends on another micro-service (B), and when B changes the
REST API, A will fail when user runs it. This has become a BIG blocker issue in CMCC lab during sun
release time.
Solution: As part of CLI project, each micro-service would provide an java client library jar (SDK),
which is auto-generated from swagger.json of that micro-service. So when changes made in REST API
of micro-service A, automatically B will fail as listed below:
•
Now B uses A sdk to connect to A using mvn dependency, instead of re-implementing the integration.
•
A changes REST API
•
A sdk jar got auto-updated (changes in java method signature/model change, etc)
•
Now Mvn build of B will break as dependent A sdk jar is changed.
•
Developer will fix B to use updated A sdk jar.
This problem is identified in compile time than run time. (early detection and recovery)
Birds-view
Open-o
GUI
GSO
SDK
GSO
developer
NFVO
SDK
Open-o
CLI
Com
SDK
admin
New Projects
Sdk = java client api library
SDNO
NFVO
COMMONO
Preferred
by
CLI
admin
GUI
user
SDK (java lib)
developer
Microservice
SDK
MSB
SDNO
SDK
Open-O API gateway
user
Microservice
SDK
interface
Microservice
SDK
Microservice
SDK
Micro-service
Micro-service
Micro-service
Micro-service
Micro-service
Project details
•
•
•
•
•
Using swagger, each service would be enabled to generate version-specific-java
library/jar (sdk) with sub-project ( ex: nfvo/sdk/java-client, sdno-overlay/sdk/java-client)
Developers could make use of SDK to integrate one service with another service.
For implementing the CLI, new gerrit project Openo-cli could be created
Openo-cli project could be governed under O-Common This will avoid to have
separate PTL for CLI project.
Separate Committers group could be defined in open-o gerrit, which would help to
govern better review process
Reference
OpenStack CLI: https://github.com/openstack/pythonopenstackclient
Sample OpenStack service (python) SDK:
https://github.com/openstack/python-heatclient
https://github.com/openstack/python-tackerclient
In OpenStack, SDK are developed by community manually,
where as in Open-O, it would be automated using swagger.
s
Thanks
Open-O Team