#opnfv-pharos: OPNFV Pharos

Meeting started by trevor_intel at 16:00:17 UTC (full logs).

Meeting summary

    1. Larry Lamers (ljlamers__, 16:02:17)
    2. Tim Irnich (timirnich, 16:02:25)
    3. Frank Brockners (frankbrockners, 16:02:28)
    4. howard huang (zhipeng, 16:02:34)
    5. trevor_intel (trevor_intel, 16:02:41)
    6. Mark Beierl (StorPerf) (mbeierl, 16:02:42)
    7. Jonas Bjurel ([1]JonasB, 16:02:47)
    8. https://global.gotomeeting.com/join/918206221 (debrascott, 16:02:55)
    9. Don Dugger (KVM) (n0ano, 16:02:57)
    10. Bin Hu (IPv6) (bin_, 16:02:58)
    11. Stefan Berg (s_berg, 16:03:24)
    12. Michael Wynne (iMSWynne, 16:03:36)
    13. Dan Druta (dandruta, 16:05:34)
    14. Iben Rodriguez (iben, 16:06:27)
    15. Billy O'Mahony (OVSNFV & VSPERF) (billyoma, 16:08:19)
    16. Continue discussion on common installer files and configuration - but are missing some key installer folks (mbeierl, 16:08:24)

  2. How to build a plugin (mbeierl, 16:08:46)
    1. Mark Gray (mdgray, 16:08:53)
    2. https://wiki.opnfv.org/fuel_opnfv_integrated-project-guidelines ([1]JonasB, 16:08:57)
    3. the desire is that each project creates their own installer plugin with help from the installer members (mbeierl, 16:09:59)
    4. if a project needs something installed, the project needs to drive that (mbeierl, 16:10:35)
    5. ACTION: Each project identifies what they need and create JIRA tickets for each installer (mbeierl, 16:11:04)
    6. and make sure the project assigns the JIRA ticket to someone (mbeierl, 16:11:45)
    7. Bryan wants to set expectation that the project creates one standard way of driving their installation requirement, and then the installer plugins are a thin wrapper to the project (mbeierl, 16:13:25)
    8. Michael echos that all four installers is too large of a goal for Brahmaputra. Same comment from Tim (mbeierl, 16:15:07)
    9. Jonas states that it should not be the case, that for example, puppet or ansible should be easier to integrate (mbeierl, 16:16:11)
    10. Common use of ansible or puppet with a shim layer should be doable (mbeierl, 16:16:48)
    11. How does each project know what is the right thing to do? (mbeierl, 16:17:03)
    12. High level requirements for install process: say, provide puppet or ansible, and then talk to installer team to integrate it (mbeierl, 16:17:54)
    13. https://wiki.opnfv.org/fuel_opnfv_integrated-project-guidelines ([1]JonasB, 16:18:02)
    14. : Suggestion - use either of the two, and then each installer can provide simple wiki overview (mbeierl, 16:18:40)
    15. See link above for example (mbeierl, 16:18:47)
    16. Compass will update overview and send to mailing list (mbeierl, 16:19:06)
    17. Apex will create and send out (Tim) (mbeierl, 16:19:22)
    18. #link JOID charm (plugin) more info : https://wiki.opnfv.org/joid?&#juju_and_maas_training_materials (iben, 16:19:48)
    19. : Bryan proposes instead of putting onus on installer projects to make it happen - that the individual teams also share info and root that in a central wiki. Here is who is working and here is the icr channel (mbeierl, 16:21:22)
    20. Create an end use wiki approach (mbeierl, 16:21:43)
    21. Mark Gray - agrees wiki is good, but when things go wrong, we don't have the expertise (mbeierl, 16:22:19)
    22. this might slow things down for the core of what the project actually wants to do (mbeierl, 16:22:40)
    23. puts a lot of burden on the project (mbeierl, 16:22:58)
    24. https://wiki.opnfv.org/genesis - now includes to above links to "HOWTO integrate with an installer" (frankbrockners, 16:23:27)
    25. Billy: agrees wiki is nice, but would like to see an example ... and then audio was lost :( (mbeierl, 16:23:57)
    26. Mark G: is there a strong requirement to support all installers? (mbeierl, 16:24:48)
    27. : encouraged but not required. Iben: example is (perhaps) KVM which is only Ubuntu, therefore not all installers would be valid (mbeierl, 16:25:23)
    28. : Bryan - can we have a description of the end state of system after the installation is complete (mbeierl, 16:25:52)
    29. Are all OpenStack services installed on the bare metal host, or are they in containers, and does this change the plugin approach? (mbeierl, 16:26:21)
    30. Not everyone was aware that there is that type of variance (mbeierl, 16:26:42)
    31. That is part of what Genesis tries to define? - Frank (mbeierl, 16:27:05)
    32. based on the distro that is being installed, certain features are available (mbeierl, 16:27:39)
    33. https://review.openstack.org/#/c/222066/1 (mbeierl, 16:28:04)
    34. : Example of Fuel plugin for ovs-nsh-dpdk https://review.openstack.org/#/c/222066/1 (from JonasB) (mbeierl, 16:28:24)
    35. Bryan asks why installers choose different (container vs bare metal) approaches (mbeierl, 16:28:59)
    36. Would be good to have that as part of the overview of the installer project itself (mbeierl, 16:29:14)
    37. Who would be qualified to answer that? Yardstick or other project that has done all 4? (mbeierl, 16:29:48)
    38. Yardstick does not do plugin, they use OpenStack APIs (mbeierl, 16:30:09)
    39. Is there an example available that other projects could study and learn? (mbeierl, 16:30:40)
    40. ACTION: Put that out as a question to the list (mbeierl, 16:31:00)
    41. Not sure if there is one example that does work against all the installers (mbeierl, 16:31:15)
    42. Frank reminds that installers themselves are also moving targets, so they are not complete either (mbeierl, 16:31:43)
    43. Best thing is to gather information, write up guides and share (mbeierl, 16:32:04)
    44. Frank has updated Genesis as per link above (mbeierl, 16:32:42)
    45. Reminder to please engage on IRC channels for installer teams (mbeierl, 16:33:51)
    46. installers install the platform - network controller, storage, etc. Then test project comes in and runs tests (mbeierl, 16:35:20)
    47. Test projects might install their own test VM - say a glance image - and then runs (mbeierl, 16:36:22)
    48. Or even a HOT or Jenkins jobs (mbeierl, 16:36:33)
    49. Example: Congress requires something extra installed in the OpenStack platform, therefore needs an integration point with the installer for that part (mbeierl, 16:38:14)
    50. Example: other projects might require specific distro and therefore would only use one installer (mbeierl, 16:39:10)
    51. Determine if you are just consuming the platform (eg: test platform) or if you are part of the platform (mbeierl, 16:40:14)
    52. If that is required for all four installers, it is appreciated that you help integrate in all (mbeierl, 16:41:08)
    53. from Billy: An end-to-end 'hello-world' plugin/charm/etc. This example plugin would have code for a plugin that would install a) install a package (rpm/deb/etc) on some nodes and b) also run a puppet manifest and/or an ansible playbook (depending on what the installer supports) c) the example MUST support deployment on a single standard server (10-20 core/ 20-30 GB ram / ~200GB disk). (mbeierl, 16:43:50)
    54. from Billy: Requiring several physical nodes (and attendant networking effort and expertise) to deploy is a massive barrier. Hopefully I would have something like this ready for fuel in the near future. This is like operating system wars where the successful OSs are the ones that make it easiest (or at least most praticable) for developers to write programs. (mbeierl, 16:44:28)
    55. Iben suggest we need to think of this as "get the feature installed in OpenStack" vs. "get it installed on Ubuntu" (mbeierl, 16:45:08)
    56. The question was - has anyone does this already? Answer appears to be no, so Congress might actually be that example, so they will work towards documenting their experience (mbeierl, 16:46:44)

  3. Common inventory and common config (mbeierl, 16:47:00)
    1. https://gerrit.opnfv.org/gerrit/#/c/4079/ (frankbrockners, 16:49:26)
    2. has everyone seen the link and had a chance to review and comment? (mbeierl, 16:49:57)
    3. This is for an installer to use when installing in a new lab, not for projects (mbeierl, 16:50:35)
    4. For a CI perspective, this is how to make things simpler, so you don't have to deal with so many differences in installers (mbeierl, 16:51:13)
    5. This is meant to be an extensible framework for future configs (mbeierl, 16:51:43)
    6. Example: L3VPN needs certain ODL features in order to run (mbeierl, 16:52:04)
    7. As part of the configuration, these things need to be turned on/off (mbeierl, 16:52:22)
    8. Not targeting to make /everything/ configurable, but focus on OPNFV requirements instead of generic language (mbeierl, 16:52:52)
    9. Will it describe the Jump Host - the networks between it and the rest of the POD? (mbeierl, 16:53:13)
    10. VLANs, etc are different (mbeierl, 16:53:26)
    11. Yes, want to harmonize this (mbeierl, 16:53:44)
    12. https://gerrit.opnfv.org/gerrit/#/c/4095/ (frankbrockners, 16:54:08)
    13. Is this retroactive? When do we start using it? (mbeierl, 16:54:35)
    14. Frank - want to use it for Brahmaputra (mbeierl, 16:54:53)
    15. As soon as we are able to deploy, want to use the scripts be interpreted and have the installer create their own config from this meta config data (mbeierl, 16:55:27)
    16. Will there be a wiremap? (mbeierl, 16:55:43)
    17. That is the ambition/plan (mbeierl, 16:55:53)
    18. To review: how to describe? see 4095 for that as well (mbeierl, 16:56:56)
    19. Use YAML to describe this - Tim to come up with a common description (mbeierl, 16:57:47)
    20. Tim R, not I. (mbeierl, 16:58:07)
    21. ACTION: Everyone to review Jonas' proposal (mbeierl, 16:58:51)
    22. Plan to conclude this in tomorrow's testing call (mbeierl, 16:59:22)
    23. ACTION: frankbrokners to send out email about tomorrow's call (mbeierl, 17:00:06)
    24. Email tags will be "as many as possible" testing, genesis, pharos (mbeierl, 17:00:50)
    25. Frank has put agenda items up (mbeierl, 17:01:13)


Meeting ended at 17:02:11 UTC (full logs).

Action items

  1. Each project identifies what they need and create JIRA tickets for each installer
  2. Put that out as a question to the list
  3. Everyone to review Jonas' proposal
  4. frankbrokners to send out email about tomorrow's call


People present (lines said)

  1. mbeierl (89)
  2. iben (9)
  3. frankbrockners (9)
  4. collabot (8)
  5. billyoma (8)
  6. trevor_intel (6)
  7. [1]JonasB (6)
  8. debrascott (2)
  9. n0ano (1)
  10. mdgray (1)
  11. s_berg (1)
  12. timirnich (1)
  13. dandruta (1)
  14. ljlamers__ (1)
  15. bin_ (1)
  16. zhipeng (1)
  17. iMSWynne (1)


Generated by MeetBot 0.1.4.