[Starlingx-discuss] API requests: stx-nfv

Thu Dec 6 13:38:30 UTC 2018

Abraham,

Good analysis - see my replies in your email below…

Bart

-----Original Message-----
From: Arce Moreno, Abraham [mailto:abraham.arce.moreno at intel.com]
Sent: December 4, 2018 4:25 PM
To: starlingx-discuss at lists.starlingx.io
Subject: [Starlingx-discuss] API requests: stx-nfv

stx-nfv team,

As a result of time spent within stx-nfv and with the objective to align our

REST API Documentation [0] with our REST APIs, we are kindly requesting your

comments for questions "?" under each section [ Section ] [Sub Section]

Please assume:

- The require X-Auth-Token is in place to authenticate:

  $ curl -i -X POST http://10.10.10.2:5000/v2.0/tokens

  $ export TOKEN=...

- StarlingX is configured as Standard Controller: 2 Controllers, 2 Computes.

[ Project Information ]

When we look at the name and description reported out by

    curl -i http://10.10.10.2:4545/

we have the same name and description between documentation [1] and

information via API Query:

    Name: nfv-vim

    Description: NFV - Virtual Infrastructure Manager

  ? Anything to add / change to the name and / or description?

[Bart] The current response seems OK to me.

[ /api ]

Here we are showing 3 different views of what we are seeing within stx-nfv

project:

  - Our initial "Migration WADL to RST", see history here [2]

  - What we have documented in our "Current Official API Documentation" pages [0]

  - What the "API Query Output" is actually showing with

    curl -i http://10.10.10.2:4545/api/...

[ /api ] [ Migration WADL to RST ]

FYI Only. Migration from WADL to RST format requested us to move "NFV VIM API v1"

(NFV VIM Service REST API) into stx-nfv repository, see [2] for the history.

[ /api ] [ Current Official API Documentation ]

Current Official API documentation [1] includes the following REST API methods

under "API Versions" details:

  - /

  - /api

  - /api/orchestration

  - /api/orchestration/sw-patch

  - /api/orchestration/sw-upgrade

And the only documented API REST methods documented are:

  - [3] Patch Strategy

  - [4] Upgrade Strategy

  ? Is "orchestration" not expected to be documented even if we have the GET

    method available?

[Bart] The orchestration level is just a grouping for sw-patch and sw-upgrade. The GET method just returns the links to those and that is documented in [1] - what else would you want to add?

[ /api ] [ API Query Output ]

API queries output shows these API REST methods:

  - api/orchestration

  - api/openstack

    - api/openstack/heat

  - api/virtualised-resources

    - api/virtualised-resources/computes

    - api/virtualised-resources/networks

    - api/virtualised-resources/images

    - api/virtualised-resources/volumes

  ? Our "Current Official API Documentation" does not have "openstack"

    and "virtualised-resources", should they be added?

[Bart] Good question. We have never officially supported the openstack or virtualised-resources APIs and we know that some of them don’t work. I would be open to removing these from our API if that would be less confusing.

[ Project Repository ] [ Directory nfv-doc ]

We took a look at the project repository and we found the "nfv-doc" directory [5]

with the following categories:

  - Software Image Management

  - Virtualised Network Resource

  - Virtualised Storage Resource

  - Virtualised Compute Resource

  ? Since we have our "Current Official API Documentation", should we put a patch

    to remove this directory? Any reason to keep it?

[Bart] I think we should remove the directory.

[ Project Repository ] [ Directory nfv-tests ]

Looking this nfv-tests [6] it includes 3 categories:

  - nfv_api_tests

  - nfv_scenario_tests

  - nfv_unit_tests

  ? Is there any restructure required in this nfv-tests directory?

[Bart] No

  ? Is there any need to think about a general test strategy which includes all

    StarlingX projects moved its execution into another place? e.g. Zuul

[Bart] Once the basic devstack setup is working for stx-nfv, we can look at adding new testcases to be executed in that environment. This won’t replace the existing testcases, but supplement them.

  ? Is this directory still valid? If not should we put a patch to remove it?

[Bart] The directory is still valid.

Thanks for your initial support.

[0] https://docs.starlingx.io/api-ref/stx-nfv

[1] https://docs.starlingx.io/api-ref/stx-nfv/api-ref-nfv-vim-v1.html?expanded=#api-versions

[2] https://wiki.openstack.org/wiki/StarlingX/Developer_Guide/API_Documentation#Analysis

[3] https://docs.starlingx.io/api-ref/stx-nfv/api-ref-nfv-vim-v1.html?expanded=#patch-strategy

[4] https://docs.starlingx.io/api-ref/stx-nfv/api-ref-nfv-vim-v1.html?expanded=#upgrade-strategy

[5] http://git.openstack.org/cgit/openstack/stx-nfv/tree/nfv/nfv-docs

[6] http://git.openstack.org/cgit/openstack/stx-nfv/tree/nfv/nfv-tests

_______________________________________________

Starlingx-discuss mailing list

Starlingx-discuss at lists.starlingx.io

http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20181206/24288070/attachment.html>