December 2018 - Starlingx-discuss

Re: [Starlingx-discuss] API requests: stx-fault
by Liu, Tao 06 Dec '18

06 Dec '18

Hi Abraham, Thank you for your detailed analysis of fault API documents, see my replies in your email below… -----Original Message----- From: "Arce Moreno, Abraham" <abraham.arce.moreno(a)intel.com> To: "starlingx-discuss(a)lists.starlingx.io" <starlingx-discuss(a)lists.starlingx.io> Subject: [Starlingx-discuss] API requests: stx-fault Message-ID: <EB6706F7B12C4A4A8FB342855D7C5DC49D681474(a)FMSMSX119.amr.corp.intel.com> Content-Type: text/plain; charset="us-ascii" stx-fault team, Based in some time spent within stx-fault 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, only URLs might be shown. - 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:18002/ there is a mismatch between documentation [1] and information via API Query: API Documentation: Name: stx-fault API Description: StarlingX Fault API allows for the management of physical servers. This includes inventory collection and configuration of hosts, ports, interfaces, CPUs, disk, memory, and system configuration. The API also supports the configuration of the cloud's SNMP interface. Source Code via API Query: Name: Fault Management API Description: Fault Management is an OpenStack project which provides REST API services for alarms and logs. ? Can you please let us know where the modifications are required? API Documentation or Source Code? <TL> The API document should be modified to match the description returned from API query. [ v1/ ] Here we are showing 3 different views of what we are seeing within stx-metal 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:18002/v1/... [ v1/ ] [ Migration WADL to RST ] Migration analysis from WADL to RST format gave us the REST methods below to include, we are adding in the second column what it seems to be the match for the valid API endpoint name: Alarms > alarms Event Log > event_log Event Suppression > event_suppression ? Are all the names and API nodes correctly matched? <TL> Yes. >From this same output, "links" has a reference to: "http://www.windriver.com/developer/fm/dev/api-spec-v1.html" ? Does his reference needs to change to: https://docs.starlingx.io/api-ref/stx-fault/index.html <TL> Yes, you are correct. [ v1/ ] [ Current Official API Documentation ] Current Official API documentation [3] includes the following 3 REST API methods under "API Versions" v1/ details: - Alarms: http://10.10.10.2:6385/v1/alarms - Event Log: http://10.10.10.2:6385/v1/event_log - Event Suppression: http://10.10.10.2:6385/v1/event_suppression <TL> The port number is wrong here, typo? [ v1/ ] [ API Query Output ] API queries output shows these API REST methods: - alarms - event_log - event_suppression ? Do we need another level of review? <TL> No. ? Is there anything we need to take care of? <TL> No. Thanks for your initial support. [0] https://docs.starlingx.io/api-ref/stx-fault/ [1] https://docs.starlingx.io/api-ref/stx-fault/api-ref-fm-v1-fault.html?expand… [2] https://wiki.openstack.org/wiki/StarlingX/Developer_Guide/API_Documentation… [3] https://docs.starlingx.io/api-ref/stx-fault/api-ref-fm-v1-fault.html?expand… _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss(a)lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss

1 0

[Starlingx-discuss] StarlingX @ Production, Update Basics
by Arce Moreno, Abraham 06 Dec '18

06 Dec '18

Hi StarlingX Community, In today's "Build Team" meeting [0] one of the topics discussed was "ISO for release and milestones" and a couple of basic questions around StarlingX in a production environment came to my mind. I am looking for community guidance in any form how this phase will look like in near future, please consider I am a "early stage cloud knowledge in process" person trying to go beyond the "pip install <package> --upgrade" [ Install ] I am looking for an Edge Computing solution, I found about StarlingX, get the latest official ISO and deployed in a configuration suitable for my needs. Cool! I have it up and running. [ Update ] Sometime later another release or milestone comes and some basic questions and own limited answers start popping up: - Should I do the upgrade or not? This depends entirely if the new release offers a specific feature I need. Any other reason to upgrade? - I have decided that new release is needed, grabbing a new ISO image and deploying could make sense in "All In One" deployment but not in deployments of 2 digits nodes. Is there a preferred way to update? - Here is a list of possible methods to get latest version for OpenStack components and StarlingX Services: - What would be that typical scenario for each of the methods below might be used? - Do we have a priority for each of them? - Are we targeting only one method? Two? Methods: Software Upgrade through stx-update RPM Upgrade Docker Container Any other? Thanks for your comments. [0] http://lists.starlingx.io/pipermail/starlingx-discuss/2018-December/002129.…

1 0

[Starlingx-discuss] starlingX mtce-common build failure
by MacDonald, Eric 06 Dec '18

06 Dec '18

The following update that merged earlier today removed code that now results in a compile error due to the declaration of an unused variable. Merged Update: https://review.openstack.org/#/c/623149/ This update has been reverted and +2/+1. Please repo sync once it gets merged. Cheers, Eric MacDonald, MTS, Engineering, Wind River direct 613.963.1387 fax: 613.492.7870 skype: eric.r.macdonald 350 Terry Fox Drive, Suite 200, Kanata, ON K2K 2W5

1 0

[Starlingx-discuss] Qemu 3.0.0 is ready for your consideration
by Jim Somerville 06 Dec '18

06 Dec '18

Hi Dean, Like with libvirt, I de-squashed all of the patches (around 100 of them) and they are on the end. Note that they consist of 3 parts, namely any fixes I had to further bring in from upstream (1 in this case), followed by the CentOS patches against qemu that we normally bring forward, followed by STX specific patches. The CentOS patches against qemu are good candidates to scrutinize for potentially dropping in the future as part of a non-rebasing exercise. My approach was to limit chaos in this upstream rebasing exercise by not dropping any patches unless made obsolete by the rebasing itself. It's hard enough to debug this complex stuff without adding more uncertainties to it. Extensive testing was done using first our regular sanity test suite, followed by our much larger nova regression test suite. Unexpected failures were found and fixed. The update to 3.0.0 consists of two parts, a pull request for the stx-qemu repo, and the piece in stx-integ which deals with the compilation. Like last time with libvirt, we have to commit these two parts at the same time. The new qemu is here, and I will push a new branch and issue a pull request to it once I'm done dealing with feedback. https://github.com/jsomervi/stx-qemu/commits/working-3.0.0-noavp-12 The stx-integ part for review is here: https://review.openstack.org/#/c/622583/ I also cc'ed anybody who I think is a directly interested party rather than just relying on the discussion list. -Jim

2 3

[Starlingx-discuss] [Container] Public docker registry
by Scott Little 06 Dec '18

06 Dec '18

Here is my proposal for the StarlingX docker repository. **Docker repository location** - hub.docker.com, as a public set of repositories under the organization 'starlingx'** ** *Build frequency* - On demand for release/milestone branches - Will probably start with daily for master branch. Perhaps when things stabilize we'll reduce build frequency, or even use commit driven builds. *Retention policy * - Perhaps two weeks for master branch builds? but always one 'stable' build (see below) - Will start with daily for master branch. Perhaps when things stabilize we'll reduce build frequency, or even use commit driven builds. *Image naming schema* <image-name>=<org>/<image>:<tag> <org>=starlingx <image>=stx-<os>-<openstack-release>-<component> <tag>=<git-tag> | <git-branch>[-<qualifier>] <os>=centos | ubuntu | clear-linux <openstack-release>=pike | queens | rocky ... <component>=aodh | ceilometer| cinder | glance | gnocchi | heat | horizon | ironic | keystone | libvirt | magnum | murano | neutron | nova-api-proxy | nova | panko ... <qualifier>=<timestamp> | latest | stable <git-tag-or-branch>=master | r2018.10 | r2018.10.0 | ... Note: we can't have the '/' or ':' character in a branch name. So r/2018.10 would have to be shortened to 'r2018.10'. However i think it's better to use the tag to allow for rebuilds of a release '2018.10.0'. My only concern here is that our current git tagging convention doesn't distinguish release from milestone. I would prefer a 'r' or 'm' prefix on our git tags. Note: the 'latest' or 'stable' qualifiers would be aliases to the timestamped image. 'Stable' might be over selling it on master branch... perhaps some other term... 'tested', 'usable'? e.g. starlingx/stx-centos-pike-nova:master-20181201 starlingx/stx-centos-pike-nova:master-20181202 starlingx/stx-centos-pike-nova:master-20181203 starlingx/stx-centos-pike-nova:master-latest -> master-20181203 starlingx/stx-centos-pike-nova:master-stable -> master-20181201 starlingx/stx-centos-pike-nova:r2018.10.0 starlingx/stx-centos-pike-nova:r2018.10.1 starlingx/stx-centos-pike-nova:r2018.10-latest -> r2018.10.1 Comments? Scott

4 6

Re: [Starlingx-discuss] StarlingX public roadmap and latest test resutls
by Shuquan Huang 06 Dec '18

06 Dec '18

Hi Wei, You can find the latest priorities here. https://ethercalc.openstack.org/fafyo2729fnr From: <starlingx-discuss-bounces+huang.shuquan=99cloud.net(a)lists.starlingx.io> on behalf of "Hu, Wei W" <wei.w.hu(a)intel.com> Date: Thursday, December 6, 2018 at 10:00 AM To: "'starlingx-discuss(a)lists.starlingx.io'" <starlingx-discuss(a)lists.starlingx.io> Subject: [Starlingx-discuss] StarlingX public roadmap and latest test resutls Hi, We are helping one partner in China to evaluate StarlingX. They have asked if there is any public StarlingX roadmap and latest test results. I find some test results on link: https://wiki.openstack.org/wiki/StarlingX/Test#Latest_ISO_image_Sanity_Summ… and project plan on link: https://wiki.openstack.org/wiki/StarlingX/Project_Priorities (Is there any place we put a roadmap?) -Wei Hu _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss(a)lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss

2 1

[Starlingx-discuss] [build][meetings] Build team meeting Agenda 12/6/2018
by Lara, Cesar 06 Dec '18

06 Dec '18

Build team meeting Agenda 12/6/2018 - Change logs and release notes - Follow up on ISO for releases and milestones - StarlingX Docker repository - opens Regards Cesar Lara Software Engineering Manager OpenSource Technology Center

2 1

[Starlingx-discuss] API requests: stx-nfv
by Arce Moreno, Abraham 06 Dec '18

06 Dec '18

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? [ /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? [ /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? [ 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? [ 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? ? 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 ? Is this directory still valid? If not should we put a patch to remove it? 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=… [2] https://wiki.openstack.org/wiki/StarlingX/Developer_Guide/API_Documentation… [3] https://docs.starlingx.io/api-ref/stx-nfv/api-ref-nfv-vim-v1.html?expanded=… [4] https://docs.starlingx.io/api-ref/stx-nfv/api-ref-nfv-vim-v1.html?expanded=… [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

2 1

[Starlingx-discuss] "Brent's Patch Reduction Plan" - Networking items
by Jones, Bruce E 06 Dec '18

06 Dec '18

I have been working on turning Brent's plan for patch reduction into actionable work items. As part of this effort, I discussed with Brent, Bill and Derek ways we can improve our tracking. We agreed to push all tracking out into the open, and until a better tool becomes available, to use Etherpads. You can find the Etherpad for the Networking part of the Patch Reduction Plan here: https://etherpad.openstack.org/p/stx-openstack-patch-refactoring-neutron. Please review and update as needed. I have updated this with the latest status I have from Forrest. I do not have the latest status from the Networking team beyond that, so there may be additional updates needed. I don't know if we want to track this work within the Networking sub-project or within the distro.openstack sub-project. I'm setting up a global Etherpad [0] with links to the sub-project pads, so as long as we agree to use these pads I'm not sure it matters which sub-project owns the work. We will be able to track all of it across the sub-projects. We should decide, of course. Feedback graciously welcomed! Brucej [0] https://etherpad.openstack.org/p/stx-openstack-patch-refactoring

3 3

[Starlingx-discuss] StarlingX public roadmap and latest test resutls
by Hu, Wei W 05 Dec '18

05 Dec '18

Hi, We are helping one partner in China to evaluate StarlingX. They have asked if there is any public StarlingX roadmap and latest test results. I find some test results on link: https://wiki.openstack.org/wiki/StarlingX/Test#Latest_ISO_image_Sanity_Summ… and project plan on link: https://wiki.openstack.org/wiki/StarlingX/Project_Priorities (Is there any place we put a roadmap?) -Wei Hu

1 0