Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Join Zoom Meeting: https://zoom.us/j/598290523

One tap mobile
+16699006833,,598290523# US (San Jose)
+16465588656,,598290523# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 598 290 523
Find your local number: https://zoom.us/u/acimKOClJk


Notes

July 24, 2019

News

  • Mandatory tests were discussed in PTL/TSC meeting on July 23
    • Sonobuoy works also on ARM64
  • LF has sent UI VM proposal

Open gerrits

  • [UI] Support UI partial control - are reviews needed or do we wait and see?
  • Add resources for building cord-tester image - has a "-1"
  • sonobuoy testing – waiting for DANM4.0
  • Juha K will be back from holiday on August 5

Old APs

  • Using k8s on our deployments
  • Using versioning for our releases
  • Moving the UI to a new git repo

Jiras


Bluval release/developer info check


July 17, 2019

  • Update about Sonobuoy testing on ARM64: with the latest Sonobuoy version, almost all test cases (except for one) seem to pass
  • Bluval UI:
    • First item was about the Bluval UI implementation hosted at LF.  LF has already a MySQL instance running in AWS as an elastic DB, and if it can be used, then the UI will only need to have the web server and the code to update the data in the database. This means that the UI can be stateless and all state will be in the DB. To be followed up
    • Second issue was about how to check whether bluval has ran all the mandatory tests. The test log will have results of all tests that it has run, but the UI cannot know what tests it was supposed to run (since it is possible to disable tests). The tentative solution is to create a file from bluval.yaml that has all tests that were supposed to be run, and store it in the logs. Bluval.py needs to do that
  • We discussed the Redfish testing. Redfish testing is currently mainly checking that the implementations confirm to the schemas that have been defined. The DMTF has also defined a few interoperability profiles, such as for OCP. It would be useful to define inside Akraino a profile that the different hardwares could be tested against, to make sure that all implementations have common functionality implemented in the same way
  • Recording is here. Unfortunately, it only covers a part of the Redfish discussion

...