Open-O CLI One Command to command whole Open-O v1.0 Project Proposal kanagaraj.manickam@huawei.com

Overview Any micro service based architecture, would provide 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: SDK (java api): 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 SDNO Open-O API gateway Micro-service interface Preferred by CLI admin GUI user SDK (java lib) developer GSO SDK GSO Micro-service SDK user SDNO SDK Micro-service SDK SDNO Micro-service Micro-service developer Open-O API gateway MSB Micro-service Micro-service Micro-service NFVO SDK NFVO Micro-service SDK Open-o CLI Micro-service SDK ComSDK COMMON-O admin Sdk = java client api library New Projects

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/python-openstackclient 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.

Thanks Open-O Team