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

Compare with Current View Page History

Version 1 Next »

06/06/18 APPC Project Weekly Minutes

6/6/18 - APPC Project Weekly Minutes

Participants: Randa Maher; Mayank Gupta; Patrick Brady; Scott Seabolt; Aaron Hay;  Ryan Young; Arash Hekmat; Lathishbabu Ganesan; Rebecca Lantz; Shashikanth VH; Shubhada Vaze; Takamune Cho; Vidhya Nerella; Vidya Bijoor

Actions from last meeting:

  • Patrick Brady to provide a knowledge share on the changes that upgrade to Nitrogen brings to APPC once he is done with the ODL upgrade.

New Actions Items:

  • Aaron Hay provide a demo on OOM APPC deployment.
  • Randa: Clean up JIRA queries in M1 planning template for R1 (check R2) - they don't show correct list. 

Agenda & Notes:

  • Key Beijing Dates:
    • Release Signoff - 6/7
    • Press Release - 6/12
  • Beijing - AAF OOM support - document workaround: Done: AAF Integration with APPC
  • CDT
    • https://gerrit.onap.org/r/#/c/50587/ - Why is Mayank changing the port after we validated our changes?
      • Looks like this is a needed change; someone changed the port originally defined in OOM project.  Patrick will review Mayank's input and +1 if agrees
  • Intent to participate for Casablanca as an active contributor ? calling for input
    • If you plan to participate in the Casablanca release as a contributor, please send PTL an email.
  • Retrospective: https://wiki.onap.org/display/DW/ONAP+Beijing+Retrospective+and+Lesson+Learned - input during meeting
    • What didn't go so well....
      • OOM - too much overhead due to duplication of configs
      • CCSDK dependency impacting ability to delivery well as we would have liked; getting ODL in the last sprint was a big challenge and limited what we could do.
      • Security guidelines from security team coming very late and making it difficult for teams to delivery - scope creep
      • Appc client library - disconnect on requirements - not enough time to do pairwise testing prior to M4 to uncover these disconnects
      • WindRiver lab stability - lost our VMs a few times; but most definitely improved since Amsterdam (good support for Steven Gooch, WindRiver is a great assest)
      • Network slowness - very slow to download docker images - sometimes it's LF, sometimes WindRiver - a lot of lost time
      • Too many code break with some of the contribution
        • Tighten down on Gerrit submits that refactor the code; submitter will need to provide evidence of run time testing.
        • Long term: automated regression suite that run to ensure no run time brake
      • IM service that easily accessible to broader community
        • IRC is still a problem for some
        • Can RocketChat be the solution? Issue: it's only http, not https
        • Skype for Business is a possible opinion
    • Things that went well
      • after all the Karaf issues, it ended up working - big challenge, but we conquered
      • cross team testing and collaboration when a lot better this release; was easier to get people on to help
      • Great teaming with SDNC, OOM, and Integration teams.
      • Good support & quick response from Stephen Gooch when we had requests and issues in our WindRiver Dev env. Getting additional capacity was also very beneficial to allow multiple deployment types and releases to be tested.
      • Having our own Developer lab was very valuable!!!
      • Great management by team to document their testing
      • Investing in getting our own Jmeter test was a big payoff!!
        • TODO: Expand documentation to get people using jmeter to setup a runtime environment to test changes
        • Connect local appc instance to connect to AAI, VNF, etc.. in the windriver
        • Testing with JMeter
      • Participation from various members & companies (Nokia, TechM, ATT)  to help us get our code coverage!!!
  • Casablanca (theme "Ease of Deploy-ability"?)
    • Non-negotiable - these must be done.
    • Contributions being made to Casablanca
      • Support for Reboot LCM action
        • Difference between Reboot and Restart (already available in Beijing)
          • Restart does an os-stop then an os-start outlined in the API documentation above and outline in the conversation below:
            • Stop: - The action to stop a running server.
            • Start: - The action to start a stopped server.
          • Reboot server:
            • Valid values are HARD and SOFT.
              • A SOFT reboot attempts a graceful shutdown and restart of the server.
              • A HARD reboot attempts a forced shutdown and restart of the server. The HARD reboot corresponds to the power cycles of the server.
      • Various defect fixes
    • Additional items to address "Deploy ability" - …team capacity will determine what can be scoped in
      • Removal of CDT proxy - find long term solution via ODL config change (see APPC-885)
      • Improve OOM deployment  (have dependency on OOM project)
        • What improvements can we make independent of OOM - move configs to shared memory (maybe not needed if we do Ryan's proposed feature? (Aaron)
      • Any other thoughts on improving deploy ability?
        • upgrade all of our properties to use configuration admin (a function of ODL/OSGI) - Ryan Young to open a Story for tracking
          • benefit to change properties and it be dynamic, i.e., no need to restart APPC, this will also address the limitation we have with OOM, which does not allow restart, you have to rebuild the pod
    • Other items under discussion-pipeline…team capacity will determine what can be scoped in
      • Support for auto scale out - discussions being led by Scott Blandford and Lauren Lewis
      • CDT tool evolution/convergence with SNDC proposal to align on one controller tool
      • Secure DMaaP topics (have dependency on DMaaP)
  • No labels