Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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