Transcript CLI - the OPEN

Open-O Client
Project Proposal
Version 0.5
Reviewed Draft
Client: Tao Shen (CMCC)
GUI: Seshu Kumar M (Huawei )
CLI: Kanagaraj Manickam (Huawei)
Overview
• Project Name : Client
• Repository name : Client
• Project Description
– This project aims to provide an unified GUI and CLI for the
Open-O functionalities provided over RESTful API. In
addition, it provides java & js sdk for Open-O services.
• Project Participants
– China Mobile, Huawei, ZTE
Architecture Alignment
Client
GUI
CLI
JS sdk
Java sdk
Orchestrator Service
Global Service-O
Common
Service
SDN-O
NFV-O
Driver
TOOLs
GUI
One Portal to command whole Open-O !!
GUI: Problem Statement
• OPEN-O Portal currently is not unified and no
common framework is provided for the individual
pages.
• No rules and restrictions defined on UCD or
usability.
• Hence OPEN-O currently has a difference in look
and feel between the pages from different
partners.
GUI: Solution
•
Strong extensibility of functional modules
–
•
Low dependence on operation system
–
•
The Client project adopts HTML and Javascript technology to reduce dependence on operation system. Portal
applications can be deployed to the web server more simply and implement orchestrator services by calling RESTful APIs.
Offering identical presentation style
–
•
The Client project can add or delete function modules more easily. Portal applications can be decoupled from each
orchestrator so that developers can work independently and integrate function modules into the Client system for nointerference.
The common module defines coherent presentation style for other functional modules as the framework of Client system.
Function modules can import defined style without concern of details to give users a sense of uniformity.
Providing third-party software
–
The common module can import open source third-party software as developers need. It means that the third-party
software can be managed by Client framework to avoid repeated import.
GUI Single Dashboard
OPEN-O Dashboard
1. Main page for all the views
needed for the OPEN-O User
2. Hop based interlinking
between the different
portals.
OPEN-O Server
3. Easy to integrate the new
portal pages and plug & play
GUI Framework
Browser
Models
(Widgets, like
the combo,
text box, check
box, radio, tree,
table,)
HTML
object
CSS
object
Event and error handling
1. Message dialog
2. Confirmation dialog
3. Warn, error, info dialog
Pre defined Operation
1. Workflow, step1, step2, step3
2. Create , modify
3. Delete
GUI Framework
User
Operation
Browser as view
GUI
Templates
Mustache js
Data
binding
Update
Base for
the MVC
Update
Model
Controller
Notify
Angular JS
GUI: Proposed Solution
GUI
HTML
New
CSS
Existing
Java Script
Model
(Angular JS)
XmlHttpRequest
based request
GSO
SGW
(App Server on
NodeJS)
Driver
SDNO
REST request
NFVO
GUI: Advantages
• We will have the look and feel everywhere in the OPEN-O
application
• Easy to develop the Portal and will reduce the effort for the
developers
• There is a defined place for all the functionality and if any
error occur, stabilizing is much faster
• Even a non experienced person can use it better and can
implement intended business logic
• We will have extension scope much better, i.e., if required
portability of the UI will be much better to a new
technology.
CLI
One Command to command whole Open-O !!
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
CLI: 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)
CLI: Birds-view
Open-o
GUI
GSO
SDK
GSO
developer
NFVO
SDK
Open-o
CLI
Com
SDK
admin
New Projects
Sdk = java/js 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
CLIENT
Client: Project details
•
Contact person
–
•
•
Both CLI and GUI projects will be governed
under new project called ‘client’
Following sub-projects are provided:
–
–
•
•
[email protected] (PTL)
Initial Committers
–
CMCC :
–
Huawei :
•
Openo-gui : For GUI project
Openo-cli : For CLI project
Using swagger, each service would be enabled
to generate version-specific-java library/jar
(sdk)
–
•
•
•
[email protected] (GUI)
[email protected] (CLI)
[email protected]
•
[email protected]
ZTE :
•
•
•
[email protected]
[email protected]
[email protected]
Developers committed to the project
–
CMCC :
–
Huawei :
•
•
•
•
–
[email protected]
[email protected]
[email protected]
[email protected]
ZTE :
•
•
•
•
[email protected]
[email protected]
[email protected]
[email protected]
s
Thanks
Open-O Team