summaryrefslogtreecommitdiffstats
path: root/README.md
blob: 6e1fc85504be985d1845f74e04261ed6c89c5c6c (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
# ONAP SDC

## Introduction

SDC is the ONAP visual modeling and design tool. It creates internal metadata that describes assets used by all ONAP components, both at design time and run time.

The SDC manages the content of a catalog, and logical assemblies of selected catalog items to completely define how and when VNFs are realized in a target environment. 
A complete virtual assembly of specific catalog items, together with selected workflows and instance configuration data, completely defines how the deployment, activation, and life-cycle management of VNFs are accomplished.

SDC manages four levels of assets:

* Resource - A fundamental capability, implemented either entirely in software, or as software that interacts with a hardware device. 
Each Resource is a combination of one or more Virtual Function Components (VFCs), along with all the information necessary to instantiate, update, delete, and manage the Resource. 
* Service - A well formed object comprising one or more Resources. Service Designers create Services from Resources, and include all of the information about the Service needed to instantiate, update, delete, and manage the Service

The key output of SDC is a set of models containing descriptions of asset capabilities and instructions to manage them. These models are stored in the SDC Master Reference Catalog for the entire enterprise to use.

There are four major components of SDC:

* Catalog - The repository for assets at the Resource, Service and Product levels. Assets are added to the Catalog using the Design Studio.
* Design Studio - Used to create, modify, and add Resource, Service, and Product definitions in the Catalog.
* Certification Studio - Available in a future release, is used to test new assets at all levels. It will be used for sandbox experimentation, and will include support for automated testing.
* Distribution Studio - Used to deploy certified assets. From the Distribution studio, new Product assets, including their underlying Resources and Services, are deployed into lab environments for testing purposes, and into production after certification is complete. In a future release, there will be a way to export Product information to external Business Support Systems for customer ordering and billing.

## Git Configuration

Before cloning the sdc source code it's important to enable long paths on your windows machine, otherwise git won't be able to handle with some files

In order to do so just add this section to your global git.config file under the `[core]` key:

    longpaths = true

## Compiling the Project

SDC is built from several projects, while "sdc-main" contains the main pom.xml for all project:
- asdctool          - set of utilities used for scheme creation and data migration in SDC
- catalog-be		- backend code
- catalog-fe		- frontend java code (servlet, proxy)
- catalog-dao		- database layer
- catalog-model		- data model of the application
- catalog-ui		- front end code (javascript, html, css)
- common            - set of utilities used by the onboarding project
- common-app-api	- common code for frontend and backend
- common-be			- utilities, datatypes and enums
- security-utils	- handle encryption/decryption of passwords
- onboarding-be     - onboarding backend code
- onboarding-ui     - onboarding frontend code
- test-apis-ci      - the automation framework used by SDC for API based testing
- ui-ci             - the automation framework used by SDC for UI based testing, Based on selenium
- sdc-os-chef       - chefs scripts used for docker creation and startup
- utils             - set of dev utils used for working with the project locally

In order to build all the projects, go to sdc-main project and run the command: `mvn clean install`

Currently SDC build process also supports docker building.
In order to build and upload local dockers to a local environment you'll need to define an environment variable on your machine with key: `DOCKER_HOST` and value: `tcp://<ip_address>:2375`
For the dockers to be built during the build process use the "docker" profile by adding this: `-P docker` to the `mvn clean install` command

More flags to use in the build process are:
* -DskipTests - Skips unit tests execution
* -DskipUICleanup=true - Skips deleting the UI folders 
* -Djacoco.skip=true - Skips running jacoco tests
* -DskipPMD - Skips creating a PMD report

**using those flags will speed up the building process of the project**

## Accessing SDC

In order to access the sdc from you're local vagrant environment you'll need to run the webseal_simulator docker.
This can be achieved by using the command: `/data/scripts/simulator_docker_run.sh`

to Access the simulator just go to this url: `http://<ip_address>:8285/login`

For more information regarding using the webseal_simulator please refer to the following guide: [SDC Simulator](https://wiki.onap.org/display/DW/SDC+Simulator)

## Accessing SDC UI in Dev Mode

In order ro access the SDC UI from your dev environment you need to couple of things:

1. First got to the file `webpack.server.js` found under the catalog-ui folder in the main sdc project and update the "localhost" variable to be the ip of your local vagrant machine.
2. Now navigate to the catalog-ui folder and run the command: `npm start -- --env.role <wanted_role>` with stating the wanted role to login to SDC as. 

## SDC Containers

The following table shows the SDC containers found on the vagrant after a successful build:

| Name                | Description                                                                                                                                   |
|---------------------|-----------------------------------------------------------------------------------------------------------------------------------------------|
| sdc-cs              | The Docker contains our Cassandra server. On docker startup the Cassandra server is started.                                                  |
| sdc-cs-init         | The docker contains the logic for creating the needed schemas for SDC catalog server,  On docker startup, the schemes are created.            |
| sdc-cs-onboard-init | The docker contains the logic for creating the needed schemas for SDC onboarding server, On docker startup, the schemes are created.          |
| sdc-es              | The Docker contains Elastic Search server. On docker startup, Elastic Search server is started.                                               |
| sdc-init-es         | The Docker contains the logic for creating the needed mapping for SDC and the views for kibana. On docker startup, the mapping is created.    |
| sdc-onboard-BE      | The Docker contains the onboarding Backend Jetty server. On docker startup, the Jetty server is started with the application.                 |
| sdc-BE              | The Docker contains the catalog Backend Jetty server. On docker startup, the Jetty server is started with the application.                    |
| sdc-BE-init         | The docker contains the logic for importing the SDC Tosca normative types and the logic for configuring external users for SDC external api's.| 
|                     | on start up, the docker executes the rest calls to the catalog server.                                                                        |
| sdc-FE              | The Docker contains the SDC Fronted Jetty server. On docker startup, the Jetty server is started with our application.                        |

For further information and an image explaining the containers dependency map please refer to the following page: [SDC Docker Diagram](https://wiki.onap.org/display/DW/SDC+Troubleshooting)

## Testing the Project

When building SDC dockers part of the dockers that will be built are the dockers that responsible for running automation tests in the local environment.

In order to run the automation tests when starting the dockers on the machine there are 2 falgs to use:

* -tad - Use this flag to run the default suite of API tests
* -tud - Use this flag to run the default suite of UI tests 

You can go to this link to view all the commands in the vagrant-onap: [Vagrant Common Commands](https://wiki.onap.org/display/DW/SDC+Vagrant+Common+Commands)

And to this guide regarding using the docker run script: [SDC docker_run Script Usage](https://wiki.onap.org/display/DW/SDC+docker_run+Script+Usage)

For more information regarding testing the project please refer to the following guide: [SDC Sanity](https://wiki.onap.org/display/DW/SDC+Sanity)

## SDC on OOM

For more information regarding SDC on OOM please refer to the following page: [SDC on OOM](https://wiki.onap.org/display/DW/SDC+on+OOM)

## Frontend Local Env - onboarding

### Steps:

Install nodejs & gulp
1. download nodejs from here: https://nodejs.org/en/ (take the "current" version with latest features) & install it.
2. install gulp by running the following command: npm install --global gulp-cli

### Install DOX-UI a:

1. pull for latest changes
2. go to folder dox-sequence-diagram-ui
3. run npm install
4. wait for it...
5. go to folder dox-ui
6. run npm install
7. create a copy of devConfig.defaults.json file and name it devConfig.json (we already configured git to ignore it so it will not be pushed)
8. in that file, populate the fields of the IP addresses of your BE machine you'd like to connect (pay attention, it is a JSON file): For example http://<host>:<port>
9. after everything was successful, run gulp
10. after server was up, your favorite UI will wait for you at: http://localhost:9000/sdc1/proxy-designer1#/onboardVendor

### Troubleshooting:

| Problem                       |   Why is this happening | Solution                                                                                   |
|-------------------------------|-------------------------|--------------------------------------------------------------------------------------------|
| npm cannot reach destination  | onboarding proxy        | When within onboarding network, you should set onboarding proxy to NPM as the following:   |
|                               |                         | npm config set proxy http://genproxy:8080                                                  |
|                               |                         | npm config set https-proxy http://genproxy:8080                                            |
|                               |                         |                                                                                            |
| git protocol is blocked       | onboarding network      | When within onboarding network, you should set globally that when git                      |
| and cannot connect            | rules for protocols     | protocol is used, then it will be replaced with "https"                                    |
|                               |                         | git config --global url."https://".insteadOf git://                                        |
--------------------------------------------------------------------------------------------------------------------------------------------------------

## SDC Troubleshooting

In order to check the life state of SDC you can run the command `health` from inside the vagrant.
Alternatively you can run the following commands to check the FE and BE status:

FE - `curl http://<ip_address>:8181/sdc1/rest/healthCheck`

BE - `curl http://<ip_address>:8080/sdc2/rest/healthCheck`

Another method to check about problems in SDC in be looking in the log files.
The log files of the SDC can be found in the `/data/logs` folder

The docker logs are found under the directory `/docker_logs`.

The jetty(Applicative) are found in the respective folder according to the wanted section
For Example, the BE logs will found under the directory `/BE`.

For more information regarding SDC Troubleshooting please refer to the following guide: [SDC Troubleshooting](https://wiki.onap.org/display/DW/SDC+Troubleshooting)

## Getting Help

#####  [Mailing list](mailto:onap-sdc@lists.onap.org)

##### [JIRA](http://jira.onap.org)

##### [WIKI](https://wiki.onap.org/display/DW/Service+Design+and+Creation+%28SDC%29+Portal)
#66d9ef } /* Keyword.Type */ .highlight .ld { color: #e6db74 } /* Literal.Date */ .highlight .m { color: #ae81ff } /* Literal.Number */ .highlight .s { color: #e6db74 } /* Literal.String */ .highlight .na { color: #a6e22e } /* Name.Attribute */ .highlight .nb { color: #f8f8f2 } /* Name.Builtin */ .highlight .nc { color: #a6e22e } /* Name.Class */ .highlight .no { color: #66d9ef } /* Name.Constant */ .highlight .nd { color: #a6e22e } /* Name.Decorator */ .highlight .ni { color: #f8f8f2 } /* Name.Entity */ .highlight .ne { color: #a6e22e } /* Name.Exception */ .highlight .nf { color: #a6e22e } /* Name.Function */ .highlight .nl { color: #f8f8f2 } /* Name.Label */ .highlight .nn { color: #f8f8f2 } /* Name.Namespace */ .highlight .nx { color: #a6e22e } /* Name.Other */ .highlight .py { color: #f8f8f2 } /* Name.Property */ .highlight .nt { color: #f92672 } /* Name.Tag */ .highlight .nv { color: #f8f8f2 } /* Name.Variable */ .highlight .ow { color: #f92672 } /* Operator.Word */ .highlight .w { color: #f8f8f2 } /* Text.Whitespace */ .highlight .mb { color: #ae81ff } /* Literal.Number.Bin */ .highlight .mf { color: #ae81ff } /* Literal.Number.Float */ .highlight .mh { color: #ae81ff } /* Literal.Number.Hex */ .highlight .mi { color: #ae81ff } /* Literal.Number.Integer */ .highlight .mo { color: #ae81ff } /* Literal.Number.Oct */ .highlight .sa { color: #e6db74 } /* Literal.String.Affix */ .highlight .sb { color: #e6db74 } /* Literal.String.Backtick */ .highlight .sc { color: #e6db74 } /* Literal.String.Char */ .highlight .dl { color: #e6db74 } /* Literal.String.Delimiter */ .highlight .sd { color: #e6db74 } /* Literal.String.Doc */ .highlight .s2 { color: #e6db74 } /* Literal.String.Double */ .highlight .se { color: #ae81ff } /* Literal.String.Escape */ .highlight .sh { color: #e6db74 } /* Literal.String.Heredoc */ .highlight .si { color: #e6db74 } /* Literal.String.Interpol */ .highlight .sx { color: #e6db74 } /* Literal.String.Other */ .highlight .sr { color: #e6db74 } /* Literal.String.Regex */ .highlight .s1 { color: #e6db74 } /* Literal.String.Single */ .highlight .ss { color: #e6db74 } /* Literal.String.Symbol */ .highlight .bp { color: #f8f8f2 } /* Name.Builtin.Pseudo */ .highlight .fm { color: #a6e22e } /* Name.Function.Magic */ .highlight .vc { color: #f8f8f2 } /* Name.Variable.Class */ .highlight .vg { color: #f8f8f2 } /* Name.Variable.Global */ .highlight .vi { color: #f8f8f2 } /* Name.Variable.Instance */ .highlight .vm { color: #f8f8f2 } /* Name.Variable.Magic */ .highlight .il { color: #ae81ff } /* Literal.Number.Integer.Long */ } @media (prefers-color-scheme: light) { .highlight .hll { background-color: #ffffcc } .highlight .c { color: #888888 } /* Comment */ .highlight .err { color: #a61717; background-color: #e3d2d2 } /* Error */ .highlight .k { color: #008800; font-weight: bold } /* Keyword */ .highlight .ch { color: #888888 } /* Comment.Hashbang */ .highlight .cm { color: #888888 } /* Comment.Multiline */ .highlight .cp { color: #cc0000; font-weight: bold } /* Comment.Preproc */ .highlight .cpf { color: #888888 } /* Comment.PreprocFile */ .highlight .c1 { color: #888888 } /* Comment.Single */ .highlight .cs { color: #cc0000; font-weight: bold; background-color: #fff0f0 } /* Comment.Special */ .highlight .gd { color: #000000; background-color: #ffdddd } /* Generic.Deleted */ .highlight .ge { font-style: italic } /* Generic.Emph */ .highlight .gr { color: #aa0000 } /* Generic.Error */ .highlight .gh { color: #333333 } /* Generic.Heading */ .highlight .gi { color: #000000; background-color: #ddffdd } /* Generic.Inserted */ .highlight .go { color: #888888 } /* Generic.Output */ .highlight .gp { color: #555555 } /* Generic.Prompt */ .highlight .gs { font-weight: bold } /* Generic.Strong */ .highlight .gu { color: #666666 } /* Generic.Subheading */ .highlight .gt { color: #aa0000 } /* Generic.Traceback */ .highlight .kc { color: #008800; font-weight: bold } /* Keyword.Constant */ .highlight .kd { color: #008800; font-weight: bold } /* Keyword.Declaration */ .highlight .kn { color: #008800; font-weight: bold } /* Keyword.Namespace */ .highlight .kp { color: #008800 } /* Keyword.Pseudo */ .highlight .kr { color: #008800; font-weight: bold } /* Keyword.Reserved */ .highlight .kt { color: #888888; font-weight: bold } /* Keyword.Type */ .highlight .m { color: #0000DD; font-weight: bold } /* Literal.Number */ .highlight .s { color: #dd2200; background-color: #fff0f0 } /* Literal.String */ .highlight .na { color: #336699 } /* Name.Attribute */ .highlight .nb { color: #003388 } /* Name.Builtin */ .highlight .nc { color: #bb0066; font-weight: bold } /* Name.Class */ .highlight .no { color: #003366; font-weight: bold } /* Name.Constant */ .highlight .nd { color: #555555 } /* Name.Decorator */ .highlight .ne { color: #bb0066; font-weight: bold } /* Name.Exception */ .highlight .nf { color: #0066bb; font-weight: bold } /* Name.Function */ .highlight .nl { color: #336699; font-style: italic } /* Name.Label */ .highlight .nn { color: #bb0066; font-weight: bold } /* Name.Namespace */ .highlight .py { color: #336699; font-weight: bold } /* Name.Property */ .highlight .nt { color: #bb0066; font-weight: bold } /* Name.Tag */ .highlight .nv { color: #336699 } /* Name.Variable */ .highlight .ow { color: #008800 } /* Operator.Word */ .highlight .w { color: #bbbbbb } /* Text.Whitespace */ .highlight .mb { color: #0000DD; font-weight: bold } /* Literal.Number.Bin */ .highlight .mf { color: #0000DD; font-weight: bold } /* Literal.Number.Float */ .highlight .mh { color: #0000DD; font-weight: bold } /* Literal.Number.Hex */ .highlight .mi { color: #0000DD; font-weight: bold } /* Literal.Number.Integer */ .highlight .mo { color: #0000DD; font-weight: bold } /* Literal.Number.Oct */ .highlight .sa { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Affix */ .highlight .sb { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Backtick */ .highlight .sc { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Char */ .highlight .dl { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Delimiter */ .highlight .sd { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Doc */ .highlight .s2 { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Double */ .highlight .se { color: #0044dd; background-color: #fff0f0 } /* Literal.String.Escape */ .highlight .sh { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Heredoc */ .highlight .si { color: #3333bb; background-color: #fff0f0 } /* Literal.String.Interpol */ .highlight .sx { color: #22bb22; background-color: #f0fff0 } /* Literal.String.Other */ .highlight .sr { color: #008800; background-color: #fff0ff } /* Literal.String.Regex */ .highlight .s1 { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Single */ .highlight .ss { color: #aa6600; background-color: #fff0f0 } /* Literal.String.Symbol */ .highlight .bp { color: #003388 } /* Name.Builtin.Pseudo */ .highlight .fm { color: #0066bb; font-weight: bold } /* Name.Function.Magic */ .highlight .vc { color: #336699 } /* Name.Variable.Class */ .highlight .vg { color: #dd7700 } /* Name.Variable.Global */ .highlight .vi { color: #3333bb } /* Name.Variable.Instance */ .highlight .vm { color: #336699 } /* Name.Variable.Magic */ .highlight .il { color: #0000DD; font-weight: bold } /* Literal.Number.Integer.Long */ }
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
.. Copyright 2017 Huawei Technologies Co., Ltd.

.. _open_cli_schema_version_1_0:

Open Command Line Interface (CLI) Schema Version (OCS) 1.0
==========================================================

Open CLI Platform (OCLIP) provides model based framework to implement
Linux Commands for any given software products, by using YAML template
based on the schematics defined in this document. In version 1.0,
following aspects of commands are modeled as YAML schematics:

* Basic Command information

* Command line arguments

* Command outputs

* Software product information

* REST API details

* Command usage

open_cli_schema_version
-----------------------
OCLIP considers any YAML file with first line having the following entry
as proper template.

    open_cli_schema_version: 1.0

Here, 1.0 version is first version of this schema. In future, this version
number will get incremented based on addition of new schematics or update of
existing schematics.

name
----
*name* entry allows to set the command name and it is recommended to use the
following format:

    <entity>-<action>

    entity - Resource or a feature, for which command is provided

    action - Functionality performed on the entity

    For example, to implement a command to *start* a given *service*.
    set the name as:

    **name** : **service-start**

*CAUTION*: name should not have any space character in it.

description
-----------
*description* entry allows to write detailed usage of the command. It could be
a line or a paragraph as given example here.

**a line**

    description: Start the given service

**a paragraph**

    description: |
        Start the given service. To see the available services in the system
        use the command *service-list*

info
-------
product
~~~~~~~~
*product* entry allows to tag the command template with the software product
name and version, for which command is implemented and is recommended to use
the following format:

    <product>-<version>

    product - Short name of the product

    action - Version of the product

    For example, to implement a command for Open Network Automation Platform
    (onap) version amsterdam, set the version as:

    **product** : **onap-amsterdam**

*CAUTION*: product should not have any space character in it.


parameters
---------
Every command has set of arguments to provide the input values and *parameters*
section allows to add the required arguments details such as name, description,
etc as list of entries.

name
~~~~
*name* entry uniquely identifies the given argument. It can be of any
alpha-numerical characters and dash(-). For example to provide the http port of
an service, the parameter could be:

    parameters:
      \- **name: service-port**

description
~~~~~~~~~~~
*description* entry allows to provide the details of the parameter. Its
supported in similar approach with command *description* defined in above
section. For example service-port could be described as:

    parameters:
      \- name: service-port

      **description: Service HTTP port.**

is_optional
~~~~~~~~~~~
*is_optional* entry allows to set the parameter is mandatory or not. By default,
this entry is false. For example service-port could be made as as optional:

    parameters:
      \- name: service-port

      description: Service HTTP port.

      **is_optional: true**

is_secured
~~~~~~~~~~~
*is_secured* entry allows to set the parameter is secured or not. By default,
this entry is false. This is very useful for password kind of parameters.

For example service-port could be made as in-secured:

    parameters:
      \- name: service-port

      description: Service HTTP port.

      is_optional: true

      **is_secured: false**

default_value
~~~~~~~~~~~~~
*default_value* entry helps to provide the default value for the given parameter
when that parameter is not provided during command execution.

Based on the *type* of parameter, default values are assigned as:

+---------------+------------------------------------------------------------+
|       Type    |              Default value                                 |
+===============+============================================================+
| bool          | false                                                      |
+---------------+------------------------------------------------------------+
| uuid          | Auto-generated uuid-4 string                               |
+---------------+------------------------------------------------------------+
| string        | Blank. Also it can be set default values from the system   |
|               | environment variable by mentioning it in the form of :     |
|               |                                                            |
|               | parameters:                                                |
|               |     - default_value: ${ENV-VARIABLE-NAME}                  |
+---------------+------------------------------------------------------------+

For example to provide the http port of an service, the parameter could be:

    parameters:
      \- name: service-port

      description: Service HTTP port.

      is_optional: true

      is_secured: false

      **default_value: 8080**


type
~~~~
*type* entry allows to set the type of parameter such as boolean, integer, etc.
For example to provide the http port of an service, the parameter type could be:

    parameters:
      \- name: service-port

      description: Service HTTP port.

      is_optional: true

      is_secured: false

      default_value: 8080

      **type: long**

Platform supports following types of parameter:

string
^^^^^^
Any parameter value having a work or a line, string type is appropriate one. By
default it is set to blank.

digit
^^^^^^
Any parameter value having digit such as integers or floating values. For this
type of parameter, platform does not set any default value. so while writing
the parameter schematics, author should set the *default_value* if needed.

json
^^^^
To set the value of parameter as JSON. Platform allows to input the JSON values
either as direct one line string for simple json or complete file path for
providing the complex json value. While user execute the command, based on the
value of the JSON parameter, it could given as string or file path.

File path could start in the form of file://, http://, ftp://.

text
^^^^
To set the value of parameter as text. Platform allows to input the text values
either as direct one line string for simple text or complete file path for
providing the complex text value. While user execute the command, based on the
value of the text parameter, it could given as string or file path.

File path could start in the form of file://, http://, ftp://.

yaml
^^^^
To set the value of parameter as yaml content. Platform allows to input the
yaml values as complete file path. While user execute the command, YAML file
needs to be created and provided that file's complete path as input value.

File path could start in the form of file://, http://, ftp://.

bool
^^^^
This type allows to set the parameter value to either true or false. By
default, its value is false, So, when user wants to input the boolean parameter
its sufficient to mention the parameter option with out mentioning 'true'.
For example, assume that command named 'login' defines the boolean input
parameter 'is_secure_connection' to set the service connection is secured or
not. For this command, while user input the value for parameter
'is_secure_connection', it is sufficient to mention the parameter without
passing value. Both of the following command will have same effect:

    login --is_secure_connection

    login --is_secure_connection true

uuid
^^^^
*uuid* type allows to make the parameter value as UUID. By default platform auto
generates uuid-4 formated string.

url
^^^
*url* type allows to make the parameter value of URL/URI. Platform does not
provide any default value for this type. so Author should provide the
*default_value*, if needed during the template is created.

binary
^^^^^^
*binary* type is very useful to pass the parameter as binary file and user
should pass the complete path of the file.

array
^^^^^^
To provide the same parameter multiple times array type helps. For example, when
the command 'rm' is used, multiple file paths could be provided to remove all of
them. In this kind of scenarios, array type supports and each parameter type
is *string*

map
^^^^
This is similar to *array* type and only differs the way the values are passed.
In this type, values should be in the form of
'<parameter-name>=<parameter-value>'


Optional and Positional parameters
----------------------------------
The input arguments for a given command usually provided with prefixing options
names or directly giving the value. Earlier case is called optional arguments
and later is called as positional arguments. OCLIP platform supports both the
type.

For optional arguments, two type of options are supported:

*short option*: option name is usually single character and when user input
the corresponding parameter, who will prefix with single dash(-).

*long option*: option name is usually more than one characters and when user
input the corresponding parameter, who will prefix with double dash(-).

For example, the service port could be defined as :

    parameters:
      \ - name: service-port

      description: Service HTTP port.

      is_optional: true

      is_secured: false

      default_value: 8080

      type: long

      **short_option: p**

      **long_option:  service-port**

When user inputs the service port, it could either of following formats

    --service-port 8080

    -p 8080

For postional arguments, author should not define both *short_option* and
*long_option* and when OCLIP process this template, it will consider as
positional arguments. There could be more than one positional arguments could
be defined for a command, and OCLIP treats the sequence of the positional
parameters defined under *parameters* section is consider as it's position. For
example, consider the below example:

    parameters:
        \- name: param1

        short_option: p1

        long_option: param1

        \- name: param2

        \- name: param3

        short_option: p3

        long_option: param3

        \- name: param4

        \- name: param5

        short_option: p5

        long_option: param5

In this case, param2 and param4 are positional arguments as they are defined
with out short and long options. so position of param2 is 1, for param4, it's 2.
When user inputs the value as :

    --param1 v1 -p3 v3 v2 -p5 v5 v4

OCLIP platform identifies the positions in sequence. so for param2, value v2
will be assigned and for param4, value v4 will be assigned.

*NOTE*: User should only concern on the sequence of positional arguments while
giving the values and no need to worry about the position at which value should
be provided. so all of below sequence will yield the same result.

    --param1 v1 -p3 v3 **v2** -p5 v5 **v4**

    **v2** --param1 v1 **v4** -p5 v5 -p3 v3

    --param1 v1 -p3 -p5 v5 v3 **v2** **v4**

default_parameters
------------------
OCLIP platform provides following default parameters for every command and
author is allowed to customize the inclusion or exclusion of these input
parameters for a given command.

name: host-username
~~~~~~~~~~~~~~~~~~~

    type: string

    description: Host user name

    short_option: u

    long_option: host-username

    default_value: ${OPEN_CLI_HOST_USERNAME}

    is_optional: false

name: host-password
~~~~~~~~~~~~~~~~~~~

    type: string

    description: Host user password

    short_option: p

    long_option: host-password

    default_value: ${OPEN_CLI_HOST_PASSWORD}

    is_secured: true

    is_optional: false

name: host-url
~~~~~~~~~~~~~~
    type: url

    description: Host url

    short_option: m

    long_option: host-url

    is_optional: false

    default_value: ${OPEN_CLI_HOST_URL}

name: help
~~~~~~~~~~
    type: string

    description: Command help message

    short_option: h

    long_option: help

    default_value: false

name: version
~~~~~~~~~~~~~
    type: string

    description: Command service version

    short_option: v

    long_option: version

    default_value: false

name: debug
~~~~~~~~~~~
    type: bool

    description: Enable debug output

    short_option: d

    long_option: debug

    default_value: false

name: format
~~~~~~~~~~~~
    type: string

    description: Output formats, supported formats such as table, csv, json,
    yaml

    short_option: f

    long_option: format

    default_value: table

name: long
~~~~~~~~~~~
    type: bool

    description: whether to print all attributes or only short attributes

    short_option: s

    long_option: long

    default_value: false

name: no-title
~~~~~~~~~~~~~~
    type: bool

    description: whether to print title or not

    short_option: t

    long_option: no-title

    default_value: true

name: no-auth
~~~~~~~~~~~~~
    type: bool

    description: whether to authenticate user or not

    short_option: a

    long_option: no-auth

    default_value: false

*NOTE*: no-auth parameter is very helpful to by-pass the login and logout phase
of each commands. Please refer *service* section to find more details on login
and logout.

results
-------
Every command produces the output and *results* section helps to define the
details of command outputs such as list of output attributes, the direction in
which, result could be printed. More details are as follows.

direction
~~~~~~~~~
*direction* entity allows to configure the direction in which the results to be
printed. It can be:

* *portrait* : To print the results in two columns. First column is the name of
  the attribute and second column is the value of the attribute. It's more useful
  while command does operations like creation of resource, viewing of resources.

* *landscape* : To print the results row vise in landscape mode. It's more
  useful while command does operations like listing of resource.

attributes
~~~~~~~~~~
name
^^^^
*name* entry uniquely identifies the given attribute. It can be of any
alpha-numerical characters and dash(-). For example to print the status of an
service, the attribute could be:

    attributes:
      \- **name: service-status**

description
^^^^^^^^^^^
*description* entry allows to provide the details of the attribute. It's
supported in similar approach with command *description* defined in above
section. For example service-status could be described as:

    attributes:
      \- name: service-status

        **description: Service current status.**

type
^^^^
*type* entry allows to set the type of attribute such as string, digit, etc.
Similar to the parameter's type. currently it supports only string type.

For example, service-status could be:

 attributes:

 \- name: service-status

 description: Service current status.

 **type: string**

scope
^^^^^
When a given command produces many results, most of the time no need to print
all the attributes. SO OCLIP platform provides this *scope* entry to configure
the attribute is printed by default or user should request to print it. So
there are two scopes:

* *short* : attribute configured with this option will always printed by default

* *long* : attriuted configured with this option will get printed only when
  user inputs the default parameter *long*, defined in *default_parameters*
  section. So to print all attributes of a command, user will input parameter:

    --long

A sample attribute for service-status could be:

  attributes:
      \- name: service-status

      description: Service current status.

      type: string

      **scope: short**

http
----
OCLIP is enhanced to support REST API based products and *http* section is
provided to capture all required details for performing http operation for the
given command.

service
-------
Whether its information technology(IT) domain or communication technology(CT)
domain, every software product is made of one or more service components. For
example, onap has different components like aai, msb, etc and these components
provides different kind of resources/features and functionalities.

*service* entry allows to mention the details of the given software product's
service. This is an section and is having entries defined in below sections.

name
~~~~
*name* entry allows to configure the service name. For example, to configure
service component 'aai' in onap-amsterdam product,

    service:
        name: aai

*CAUTION*: This entry is very signification to discover this service from the
service catalog and name should be matching with the service name registered
in the catalog.

version
~~~~~~~
*version* entry allows to mention the particular version of service for which
command is implemented. For example, the service 'aai' in the product
'onap-amsterdam' having versions like v11.

    service:
        version: v11

*CAUTION*: This entry is very signification to discover this service from the
service catalog and version should be matching with the service version
registered in the catalog.

mode
~~~~
Some software product provides catalog service , where all service of that
product could be discovered. While other product does not. OCLIP provides
support for both kind of these products to implement commands and *mode*
entry allows to configure this mode of operation.

CLIP supports in two different mode.

In *catalog* mode, OCLIP will discover the service details based on given
*name* and *version* from the configured *host-url* parameter. For example,
the product 'onap-amsterdam' provides the service 'msb' as the catalog service where
all other services will get registered. so OCLIP can discover the given
service such as 'aai' from the catalog service 'msb'. In this mode, *host-url*
will be configured with the *msb* service url. In this case:

    service:
        mode: catalog

*NOTE*: To see the details of *host-url*, refer the section default_parameters

In *direct* mode, OCLIP will not perform the discovery operation and consider
the given *host-url* as the direct service url. In this case:

    service:
        mode: direct

*NOTE*: To see the details of *host-url*, refer the section default_parameters

--------------------

auth
~~~~
There are different kind of authentication and authorization approach exist and
for OCLIP provides support for following approaches. Based on the approach
configured in the template, OCLIP will login before executing the command and
logout afterwards.

none
^^^^^
In this approach, no login and logout will be performed. This is useful during
the development cycle, as well as some services are available in public
without authentication of user. In this approach, OCLIP ignores the given
*host-username* and *host-password*. So the none auth is defined by:

    service:
        auth: none

*NOTE*: To see the details of *host-username* and *host-password*, refer the
section default_parameters


basic
^^^^^
This is HTTP basic authentication approach and given *host-username* and
*host-password* values are used to find the hash and use it as Authentication
value. So the none auth is defined by:

    service:
        auth: basic

*NOTE*: To see the details of *host-username* and *host-password*, refer the
section default_parameters

--------------------
request
~~~~~~~
*request* section captures all HTTP request information as:

uri
^^^
*uri* entry allows to mention the REST API URI. Based on the *service mode*,
this entry will vary. * when the mode is 'direct', it should be configured with
out *host-url* portion in it. For example, if the REST API is
'<host-url>/v1/service1/resource1, in which

* /v1/service1 - base path
* /resource1 - service resource path.

then this entry will be:

    request:
        uri: /v1/service1/resource1

when the mode is 'catalog', OCLIP will discover the  base path from the
'catalog' service, so this entry need to be configured only with resource path
as:

    request:
        uri: /resource1

method
^^^^^^
*method* entry allows to configure the HTTP methods GET, PUT, POST, DELETE,
etc. For example, to get the resource1:

    request:
        uri: /resource1

        method: GET

body
^^^^
*body* entry allows to mention the request body in json format, by default.
And OCLIP adds 'application/json' header in the HTTP request. Otherwise, body
could have complete path to binary file, in case request body is binary and
*multipart_entity_name* should be configured with entity name provided by REST
API.

headers
^^^^^^^
*headers* entry allows to add REST API specific headers. By default OCLIP adds
'application/json' as content-type and accept, also it will adds authentication
headers such as 'Authentication' in case *auth* is of type 'basic'.

For example, to add the sample header :

    request:
        uri: /resource1

        method: GET

        headers:
            header1: value1

            header2: value2

queries
^^^^^^^
*queries* entry allows to add REST API specific queries. For example, to add
the sample queries :

    request:
        uri: /resource1

        method: GET

        queries:
            q1: value1

            q2: value2


context
^^^^^^^
*context* entry allows to customize the HTTP request and response processing.

Following are the supported customization parameters:

*remove_empty_node* : By default, OCLIP does not remove the empty json entries
  in request body. Otherwise set this entry to true as below.

    request:

        context:
            remove_empty_node: true

success_codes
~~~~~~~~~~~~~
Every REST API has set of success codes and OCLIP will treat the HTTP request
made based on the value configured in these http sections, only if
*success_codes* contains the HTTP response status code.

result_map
~~~~~~~~~~
This section allows to configure the require 'jpath' expression to retrieve the
values from the HTTP response body.

*NOTE*: Currently only http response body is supported only with json type.

For example, if a http response '{"service_status": "green"} then to retrieve
the service status and assign to result *attribute* service_status as :

    result_map:
        service_status: $b{$.service_status}

Here, $b is detailed in section 'macros' of this document. and
'$.service_status' is jpath expression.

sample_response
~~~~~~~~~~~~~~~
This entry allows to keep the sample HTTP response as reference to understand
the result_map jpath expressions. OCLIP does not use this entry and is optional.

macros
-------
OCLIP platform provides various marcos to fill *http* entries with the value
of *parameters*, *headers* , etc Every macro is in the form of <macro name>
followed by {<macro details>}Followings are the supported macros:

+----------------+------------------------------------------------------------+
|       Macro    |               Definitions                                  |
+================+============================================================+
| ${param-name}  | To retrieve the value from parameter named 'param-name'    |
+----------------+------------------------------------------------------------+
| $h{header-name}| To retrieve the value from header named 'header-name'      |
+----------------+------------------------------------------------------------+
| $q{query-name} | To retrieve the value from query named 'query-name'        |
+----------------+------------------------------------------------------------+
| $b{jpath}      | To retrieve the value from response body using the 'jpath' |
|                | expression.                                                |
+----------------+------------------------------------------------------------+