#opnfv-meeting: Weekly Technical Discussion

Meeting started by bh526r at 14:01:05 UTC (full logs).

Meeting summary

  1. Roll Call (bh526r, 14:01:14)
    1. Bin Hu (bh526r, 14:01:19)
    2. Al Morton (bh526r, 14:01:25)
    3. Georg Kunz (bh526r, 14:01:33)
    4. Juha Oravanien (bh526r, 14:01:42)
    5. Prakash Ramchandran (bh526r, 14:01:51)
    6. Uli Kleber (uli-k, 14:02:02)
    7. Dan Radez (bh526r, 14:02:04)
    8. Aimee Ukasick (bh526r, 14:03:19)
    9. Bryan Sullivan (bh526r, 14:03:25)
    10. rprakash (rprakash, 14:05:47)

  2. Proposal of DevOps Mode; (bh526r, 14:07:10)
    1. One of the topic is Keystone integration (bh526r, 14:07:31)
    2. If I need to have an OPNFV build, should I be able to pull from stable branch or from master with more recent feature (bh526r, 14:08:08)
    3. rprakash (rprakash_, 14:08:28)
    4. This assumption needs to be validated (bh526r, 14:08:40)
    5. (Uli) we can try it to validate the feasibility (bh526r, 14:09:28)
    6. (Bryan) another implication is, e.g. if I have a test, but dovetail cannot pick it up for a few months, how stable will be the test and python library while we are moving forward (bh526r, 14:10:47)
    7. So we don't leave behind the community too far, while we don't have to wait just for the sake of stable release (bh526r, 14:11:32)
    8. We need to really understand who the users are (bh526r, 14:11:46)
    9. (Uli) we have 2 types of users (bh526r, 14:11:54)
    10. One type is to use the coolest features (bh526r, 14:12:16)
    11. The other type is to use the newest features (bh526r, 14:12:52)
    12. Larry Lamers (bh526r, 14:13:32)
    13. Tapio (bh526r, 14:13:35)
    14. We need to measure the user community proactively and understand their needs (bh526r, 14:14:14)
    15. Talking about the first type of users, some are still trying to use Brahmaputra, even if we don't support it any more (bh526r, 14:14:58)
    16. We need to test feasibility of deploying OPNFV scenarios on trunk? Which installers support that? (bryan_att, 14:15:39)
    17. (Bryan) I am looking for a stable development environment with stable features that enable me to move forward (bh526r, 14:17:50)
    18. ability to devlopoment on trunk on Openstack like with Congress (rprakash_, 14:21:47)
    19. (rprakash) ability to development on trunk with OpenStack Murano, Manila etc. (rprakash_, 14:23:24)
    20. (aimeeu) using Quickstart with trunklevel developement and Dan says in Newtorn Tacker is in (rprakash_, 14:24:10)
    21. (Bryan) ability to develop with multiple components from different upstreams to work together from trunk to suport new features (rprakash_, 14:26:26)
    22. (Bryan) Dvelopment envrionment like RDO, triple-O, Packstack, Quickstart and understand which one are suitable for different features and test plus continuous Devlopment to support OPNFV community (rprakash_, 14:28:48)
    23. (bryan) Feature Devlopment role is different from Packaging and Delivering different upstreams to the releases (rprakash_, 14:30:23)
    24. (Bryan) Resilliancy is imporant for getting Control Plane stability and needs simplicty and flexibility of control plane (rprakash_, 14:31:41)
    25. (Bryant) ability add drop Cielometer for say Billing , Add drop Congree like Policy usgae is different etc. So customization of target deployment is one aspect (rprakash_, 14:33:07)
    26. (Bryan) How light the Control Plane can be with flexibility of installers to choose some of the options from OpenStack for specialized environment that Service Provider needs (rprakash_, 14:34:31)
    27. Uli will try to put those wishes into scenario consolidation (bh526r, 14:35:25)
    28. scenario definitions (bh526r, 14:36:02)
    29. (Bryan) Orchestrator like JujU, Puppet have ability to slect OpenStack Modules and establish relationships and if Scenarios can configure similarly that will be the goal (rprakash_, 14:38:32)
    30. look at scenario descriptor file and pod descriptor file (bh526r, 14:40:27)
    31. (uli) ability to orchetsrate in layers for Hardware(POD), Infra(descriptor), VNFD/NSD (MANO descriptor) etc (rprakash_, 14:42:34)
    32. (Bryan) mentions like L4 service depends of L3 , L2, so there may be cross layer dependency (rprakash_, 14:43:13)
    33. (Bryan) Its possible to add and remove Charm using Juju and similar can be done with Puppet, Ansible playbook etc. (rprakash_, 14:44:11)
    34. (Bryan) Ability to add reomove Tacke eg. could be using VNF using Tacker once and next using JuJu dynamically (rprakash_, 14:46:28)
    35. (Dan Radez) Why do we need this is there value to this? (rprakash_, 14:47:08)
    36. (Bin) How we can leverage Scenarios to do flexible Control plane objectives and lets discuss and come up with some solutions (rprakash_, 14:48:18)

  3. Update of Scenario Consolidation (bh526r, 14:49:12)
    1. (Uli) has submitted a patch in Octopus to be reviewed- request for reveiew (rprakash_, 14:49:32)
    2. Uli submitted a patch of skeleton of scenario document set (bh526r, 14:49:32)
    3. https://gerrit.opnfv.org/gerrit/#/c/28443 (uli-k, 14:49:59)
    4. Uli will send an email to mailing list so that everyone can review the patch (bh526r, 14:51:37)
    5. Then we can move forward to review scenario descriptor patches (bh526r, 14:52:04)
    6. to summarize what we will be doing toward the last topic areas (1) assessing developer-focused options for OpenStack, ODL test envs simpler than full OPNFV deploys, and providing advice on the wiki. (2) assessing over time whether that gives us more dev freedom at a good balance wrt re platform stability (bryan_att, 14:53:24)
    7. (Bryan) mentioned that there was good discussion in MANO WG. (bh526r, 14:54:55)

  4. MANO Update (bh526r, 14:55:06)
    1. (3) looking at how flexible the installers can be for customizing the deployment (e.g. thru the descriptor files); (4) how modeling concepts can be applied to the control plane as well, e.g. how well the blueprint model can cover the needs of the various descriptors we use in CI/CD (bryan_att, 14:55:11)
    2. the goal of (4) being to someday have a common abstraction/specification for the intended control plane deployment, that the installers can "onboard" and then take action to deploy; (bryan_att, 14:56:18)
    3. David M is not present, so Milestone Exception Process discussion deferred to next time (March 2) (bh526r, 14:58:01)
    4. Cross-Community CI process will be on March 2 (bh526r, 14:59:34)
    5. and E release plan (bh526r, 14:59:45)
    6. (rprakash) MANO release E has learining from vIMS VNF about different approach to orchestartion through installers and without it, plus testing (rprakash_, 15:00:01)
    7. (rprkash) the other aspect realted to keystone v 3 v 2 usage based on installers support (rprakash_, 15:00:55)
    8. (rprakash) the bestpractices is still under review for VNF packaing, onboarding, LCM etc. (rprakash_, 15:01:53)
    9. Next week (Feb 23), we will be dedicated to discuss 2 new project proposals (bh526r, 15:02:53)
    10. (rprakash) About the Architecture tehre are different views from different work groups like pipeling of CI,CT,CV, CD form iintegration, Test, Vlaidation to Deployment and Tapio has a Software Architecture viewpoint and thus we need to reflect the upstream integration aspect as we are looking now at Bifrost and working through up[straem Trunk in CI (rprakash_, 15:04:06)
    11. On March 2, we will discuss (1) DevOps/Continuous Delivery and How Scenario Descriptor can enable/support it (2) Cross-Community CI Process (3) Milestone Exception Process (4) E Release Plan (bh526r, 15:04:27)
    12. And the perhaps (5) MANO WG Update and MANO Architecture if time permits (bh526r, 15:04:55)
    13. Meeting adjourned (bh526r, 15:05:09)


Meeting ended at 15:06:52 UTC (full logs).

Action items

  1. (none)


People present (lines said)

  1. bh526r (45)
  2. rprakash_ (23)
  3. bryan_att (5)
  4. collabot` (3)
  5. rprakash (2)
  6. uli-k (2)
  7. radez (1)


Generated by MeetBot 0.1.4.