Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

ODL Notes

ODL clustering has no notion of discovery. There is a flat file (akka.conf) on each VM that contains info about its peers.

Basically the two main limitations are (a) the total number of nodes has to be odd (due to how voting works) and (b) if you add additional nodes, you need to update the akka.conf on all the existing nodes as well and bounce them. Make sure to bring up the old ones first to make sure one of those becomes the "shard leader" (otherwise I'd worry that one of the new ones would think it's the leader even though it has no data yet, and "replicate" its lack of data to the others).

ODL clustering was designed for high availability really - not for scaling. So that's why it doesn’t address scaling in any real way. There are some improvements in clustering planned for the next ODL release (Oxygen), the details for the improvements are not yet known.


ConfigScaleOut API Definition 

Note: This is temporary documentation for M2-  LCM API Guide will be updated when everything is finalized.


ConfigScaleOut


The ConfigScaleOut command is used to apply any actions on a VNF as part of a ScaleOut flow.     Actions could include updating the VNF configuration or running a set of other tasks.


The ConfigScaleOut action can have multiple APP-C templates associated with it.  APP-C retrieves the vf-module-name from A&AI which is used as the unique identifier to select the correct APP-C template.


APP-C creates or updates VNFC records in A&AI for the newly instantiated VM’s.  The orchestration-status of the VNFC’s is set to CONFIGURED.


This action is supported via the Netconf (limited to configuration changes), Chef, and Ansible protocols.


 


Target URL

/restconf /operations/ appc-provider-lcm: config-scale-out

Action

ConfigScaleOut

Action-Identifiers

Vnf-id

Payload Parameters

See below

Revision History

New in Beijing


 


Request Payload Parameters:


 


Payload

 Parameter

Description

Required?

Example

request- parameters

vnf-host-ip-address: optional if Netconf or other direct interface to the VNF.   If not provided, the vnf-host-ip-address will be obtained from A&AI.

Vf-module-id:  used to determine the A&AI VM inventory associated with ConfigScaleOut.

No

 

 

Yes

 

"payload":

"{\"request-parameters

\": {

\"vnf-host-ip-address\": \”value\”,

\”vf-module-id\”: \”value\”

}

\"configuration- parameters\": {\"<CONFIG- PARAMS>\"}

configuration- parameters

A set of instance specific configuration parameters should be specified. If provided, APP-C replaces variables in the configuration template with the values supplied.

No


 


ConfigScaleOut Response:


Success:  

  • A successful ConfigScaleOut returns a success status code 400 when completed.


Failure:


  • A failed ConfigScaleOut returns a failure code 401 and the failure message.
  • If the ConfigScaleOut is successfully performed on the VNF but there is a failure to update A&AI inventory, an intermediate failure message with failure code 501 is returned prior to the final 400 success message.


  • No labels