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

Compare with Current View Page History

« Previous Version 19 Next »

Abstract

APPC currently supports VNF level HealthCheck via the APPC LCM API.  Current functionality allows the client to request a VNF HealthCheck and APPC returns either a success or failure.  ONAP Control Loops require a more fine grained HealthCheck that provides a more robust feature set and a more fine grained response. 

Rationale

ONAP Control Loops require an APPC HealthCheck solution that provides a means of performing VNF and VM level checks.  Additionally, the HealthCheck response provided back to the APPC LCM API client needs to contain a payload with details on what and why the HealthCheck failed.  Currently, the APPC HealthCheck is only at the VNF Level and only returns a Success or Failure code.

One useful example of this enhanced functionality is the case where a VNF that contains for instance eight VMs.  The VNF level HealthCheck may find that seven out of the eight VMs are operating satisfactorily but one VM failed the HealthCheck.  The state along with the indication of which VM(s)/VNFC(s) failed and why the HealthCheck failed will be returned to the APPC LCM client.  The details returned for the failed VM(s)/VNFC(s) will allow the decision/policy manager to make a determination on whether or not to restart the one VM/VNFC or all VM(s)/VNFC(s) contained in the VNF.

Proposal

The solution will provide enhancements to the APPC HealthCheck functionality wherein APPC will allow for both a VNF level HealthCheck as well as a VM/VNFC level HealthCheck. Additionally, the response will return more fine grained details on the HealthCheck results.

VNF Level HealthCheck

  • Request:

    • Will conform to the APPC LCM VNF Level Request format per the APPC LCM API Guide.

    • The HealthCheck API will perform LCM request validations.

    1. IF

      1. VNF specific HealthCheck is available on the VNF, execute the VNF HealthCheck on the VNF:

        1. Connect to the VNF via (REST, Chef or Ansible) via the endpoint configured in the APPC CDT Tool.

        2. Initiate the VNF HealthCheck on the VNF.

    2. ELSE:

      1. APPC will obtain VNF details from A&AI
      2. Including:
        1. vserver details in order to enable checking each VM/VNFC in the VNF
      3. APPC performs HealthCheck on each vserver via Cloud Provider API
      4. Obtain Cloud Provider details.
      5. Connect to the Cloud Provider for each VM/VNFC
        1. I.e. for OpenStack Compute API:
          1. Show Server Details
          2. /servers/{server_id} /“OS-EXT-STS:vm_state”
        2. Mark VM/VNFC Failed marking the state.
        3. If any state other than “active” the HealthCheck for the VM/VNFC will be marked failed.
      6. IF ANY VM/VNFC is in a failed state the overall HealthCheck of the VNF will return failed along with the failure reason in the HealthCheck response payload.

  • Response:

    • VNF level HealthCheck response will:

    1. Conform to the APPC LCM Response format per the APPC LCM API Guide.
    2. Return Success/Failed status code as well as status code message (APPC LCM Response includes a “status” section with subsections of “code” and “message.”
    3. Include the Failed VM(s)/VNFC(s) details in the Response Payload.

VM Level HealthCheck

  • Request:

    1. I.e. vserver-id element is included action-identifier section of the request, vm-id and identity-url are included in the request payload.
    • Obtain Cloud Provider details.
    • Connect to the Cloud Provider for each VM/VNFC
    1. I.e. for OpenStack Compute API:
      1. Show Server Details.
      2. /servers/{server_id} /“OS-EXT-STS:vm_state.”
    • IF VM/VNFC is in a failed state, return a failure along with the failure reason in the HealthCheck response payload.

  • Response:

    1. Return Success/Failed status code as well as status code message (APPC LCM Response includes a “status” section with subsections of “code” and “message.”
    2. Include the Failed VM/VNFC details in the Response Payload.

Backward Compatibility

  • The current proposal is to develop a new API and persist the existing HealthCheck API in order to support the integrity of the current HealthCheck.

References


  • No labels