Page tree
Skip to end of metadata
Go to start of metadata

Multisite Project Meeting

Logistics

Agenda of the week

  • Agenda is sent in the OPNFV mail-list every week: opnfv-tech-discuss@lists.opnfv.org
  • Please subscribe the mail-list for the agenda

Past Meeting Agenda and Minutes

May.18 2017: Agenda & Minutes

  • Agenda
    • Beijing OPNFV Demo discussion 

    • Open discussion
  • Minutes
    • Deployment of the IMS it RegionOne and tenant admin works very well with the cloudify manager automatic deployment (joehuang, 08:13:23)

    • ACTION: check demo shcedule (joehuang, 08:23:53)

    • all regions are available and work (joehuang, 08:24:54)

    • ACTION: test bit rate under VPN connection (joehuang, 08:34:25)

  • Link

Apr.27 2017: Agenda & Minutes

  • Minutes
    • tricircle in VM running in RegionOne succeed, but unfortunately RegionOne data plane was ruined by neutron-ovscleanup (joehuang, 08:15:21)

    • remedy of the tricircle VM is in progress (joehuang, 08:16:08)

    • once the environment is ready, will send msg in the mail-list (joehuang, 08:25:14)

  • Link

Apr.20 2017: Agenda & Minutes

  • Minutes
    • The cloudify-manager VM must have an access to OpenStack public api (joehuang, 08:24:00)
    • a descriptor to deploy the designate service regardless of the platform (joehuang, 08:36:02)
  • Link

Apr.13 2017: Agenda & Minutes

  • Minutes
  • Link

Apr.6 2017: Agenda & Minutes

  • Agenda
    • E release plan and OPNFV Beijing summit  discussion

    • CMCC multi-site requirements discussion(2)

    • Open discussion
  • Minutes
  • Link

Mar.30 2017: Agenda & Minutes

Agenda

    • CMCC multi-site requirements
    • OPNFV Beijing summit preparation
    • Open discussion
    • Contribution to multisite arch guide

Minutes

      • demo environment: Full access to the internet (for package
          installation etc..)  (joehuang, 08:18:05)
      • ACTION: one more baremetal servers  (joehuang, 08:20:55)
      • 3 sites, vIMS in two sites, Video conference in 3 sites  (joehuang,
          08:24:14)
      • Contribution to multisite arch guide  (joehuang, 08:46:00)

Link

Mar.23 2017: Agenda & Minutes

  • Agenda

    * CMCC multi-site requirements

    * Functest issue.

    * E-Release discussion

    * OPNFV Beijing summit preparation

    * Open discussion

  • Minutes
    • CMCC multi-site requirements(joehuang, 08:03:28)
      1. 3 layer NFV deployment architecture (joehuang, 08:05:28)
      functest issue(joehuang, 08:52:07)
      1. functest pass locally (joehuang, 08:55:24)

Mar.16 2017: Agenda & Minutes

  • Agenda

    * Functest issue.

    * E-Release discussion

    * OPNFV Beijing summit prepration

    * Open discussion

  • Minutes

Mar.9 2017: Agenda & Minutes

  • Agenda

* Functest issue.

* D-release branching

* Kingbird feature development.

* Open discussion

  • Minutes
    • kingbird run normally in functest environment (joehuang, 08:17:10)
    • the stable branch will be created by Aric for OPNFV D release on this Friday (joehuang, 08:20:24)
    • Release Danube 1.0 on Mar.27 (joehuang, 08:22:06)

Mar.2 2017: Agenda & Minutes

  • Agenda

* Functest issue.

* D-release preparation.

* Kingbird feature development.

* Open discussion

  • Minutes

 

Feb.23 2017: Agenda & Minutes

  • Agenda

* Multisite deployment/functest environment readiness/restoration.

* D-release preparation.

* Kingbird feature development.

* Open discussion

  • Minutes

Feb.16 2017: Agenda & Minutes

  • Agenda

* Multisite deployment environment.

* (MS6) Test cases implemented, preliminary documentation completed, and stable branch open

* Open discussion 

  • Minutes

Feb.9 2017: Agenda & Minutes

  • Agenda
    1. https://jira.opnfv.org/browse/FUNCTEST-721 (sorantis, 08:09:28)
    2. https://review.openstack.org/#/c/416507/ (goutham, 08:14:10)
    3. adding kbclient to kingbird requirements.txt to see if it succeeds (joehuang, 08:20:19)
    4. https://review.openstack.org/#/c/416507/ (goutham, 08:27:55)
    5. a new commit of tempest test for the quota management bug fix (joehuang, 08:32:35)

 

  • Minutes
    • Multi Region environment ready soon (joehuang, 08:19:21)
    • remove item level quota deletion (joehuang, 08:24:29)
    • ACTIONrelease python-kingbirdclient so that kingbird tempest can use it (joehuang, 08:24:59)

 

Jan.19 2017: Agenda & Minutes

  • Agenda

* Multisite deployment environment.

* Kingbird feature development.

* Open discussion

  • Minutes
    • Multi Region environment ready soon (joehuang, 08:19:21)
    • remove item level quota deletion (joehuang, 08:24:29)
    • ACTIONrelease python-kingbirdclient so that kingbird tempest can use it (joehuang, 08:24:59)

Jan.12 2017: Agenda & Minutes

  • Agenda

* D release discussion

* VNF Geo site disaster recovery

* Kingbird feature development

* Open discussion

  • Minutes
    • stick to the release plan of OPNFV D release and Ocata release. Feature freeze Feb.16, branch created on Feb.17 (joehuang, 08:20:34)
    • VNF Geo site disaster recovery (joehuang, 08:21:52)
    • multisite requirements documentation update is needed for D release (joehuang, 08:43:30)
    • kingbird feature development (joehuang, 08:47:29)
    • migrate curl to use client SDK (joehuang, 08:54:17)

 

Jan.5 2017: Agenda & Minutes

  • Agenda

* D release discussion

* Kingbird feature development

* Open discussion

 

Dec.29 2016: Agenda & Minutes

  • Agenda

* Kingbird feature development

* Open discussion

 

Dec.22 2016: Agenda & Minutes

  • Agenda

* Kingbird feature development

* Open discussion

Dec.15 2016: Agenda & Minutes

  • Agenda

 

    • * Kingbird feature development
    • * mutli-site deployment
    • * Revisit Geographical Redundancy
    • * Open discussion

 

  • Minutes
    1. Kingbird feature development(joehuang, 08:02:26)
      1. https://bugs.launchpad.net/kingbird/+bug/1583967(joehuang, 08:06:31)
      2. https://bugs.launchpad.net/kingbird/+bug/1583965(joehuang, 08:06:44)
      3. https://review.openstack.org/#/c/314995/(sorantis, 08:13:54)
      4. ACTIONupdate the code in the quota usgae calculation for cinder part to enhance the performance (joehuang, 08:17:23)
      5. https://bugs.launchpad.net/kingbird/+bug/1583967(joehuang, 08:18:03)
      6. ACTIONcheck to see whether to report the bug for quota usage retrievement in the neutron (joehuang, 08:22:57)
    2. mutli-site deployment(joehuang, 08:23:30)
      1. https://review.openstack.org/#/c/409653/(joehuang, 08:27:00)
  • Link

Dec.8 2016: Agenda & Minutes

  • Agenda
    • Kingbird os-sync API

    • Revisit Geographical Redundancy

    • Open discussion
  • Minutes
    1. Kingbird os-sync API(joehuang__, 08:15:04)
      1. http://hastebin.com/ajipixukun.scala(goutham, 08:22:48)
      2. focus on a per-resource sync at first (joehuang__, 08:27:38)
      3. https://gerrit.opnfv.org/gerrit/#/c/25007/(sorantis, 08:30:08)
    2. Revisit Geographical Redundancy(joehuang__, 08:32:50)
    3. open discussion(joehuang__, 08:35:58)
      1. register activities in jira (joehuang__, 08:45:05)
  • Link

Dec.1 2016: Agenda & Minutes

  • Agenda

 

    • Kingbird feature implementation
    • Open discussion

  • Minutes
    1. ACTIONput these curl examples in the doc (joehuang, 08:10:20)
    2. Ticket has been registered on INFRA https://jira.opnfv.org/browse/INFRA-38 . (sorantis, 08:20:43)
    3. https://build.opnfv.org/ci/view/multisite/job/multisite-kingbird-virtual-daily-master/ (sorantis, 08:24:30)
  • Link

Nov.24 2016: Agenda & Minutes

Nov.17 2016: Agenda & Minutes

 

Nov.3 2016: Agenda & Minutes

Oct.20 2016: Agenda & Minutes

 

Sept.29 2016: Agenda & Minutes

 

Sept.22 2016: Agenda & Minutes

 

Sept.8 2016: Agenda & Minutes

Sept.1 2016: Agenda & Minutes

  • Agenda
    • Next step for Multisite project, scope, focus, etc

  • Minutes
    • 1)KB CLI (joehuang, 07:26:12)
    • 2)KB SDK (joehuang, 07:26:21)
    • 3)Resources Sync (joehuang, 07:26:37)
    • 3.1)SEG (joehuang, 07:27:36)
    • 3.2)FLAVOR (joehuang, 07:27:54)
    • 3.3)SSH KEY (joehuang, 07:28:08)
    • Revisit Geographical Redundancy
    • 4)cross neutron networking automation (joehuang, 07:28:31)
    • 5) installation cooperation (joehuang, 07:32:18)

Aug. 25 2016: Agenda & Minutes

Aug. 18 2016: Agenda & Minutes

Aug. 11 2016: Agenda & Minutes

  • Agenda
    • functest issues

    • documentation review

    • KB 0.2.0 tagging

  • Minutes
    1. https://gerrit.opnfv.org/gerrit/#/c/18379/ (joehuang, 07:18:03)
    2. https://gerrit.opnfv.org/gerrit/#/c/17687/ (joehuang, 07:18:18)
    3. documentation should be complemented next Monday, Aug.15 (joehuang, 07:21:49)
    4. 1 week window for stable branch creation for Colorado release, by Aug.22. (joehuang, 07:22:18)
    5. https://gerrit.opnfv.org/gerrit/#/c/18379/ (SAshish, 07:30:59)
    6. ACTIONshould we keep CI/functest job for colorado release (joehuang, 07:59:54)

Aug. 4 2016: Agenda & Minutes

  • Agenda
    • KB endpoint access issue and functest

    • User guide documentation

    • KB 0.2.0 tagging

  • Minutes
    1. LINK: http://192.168.0.2:9292  (SAshish, 07:17:21)
    2. fix the test issue first  (joehuang, 08:05:44)
    3. joe help to add the userguide  (joehuang, 08:05:57)

Jul. 28 2016: Agenda & Minutes

 

Jul. 21 2016: Agenda & Minutes

Jul. 14 2016: Agenda & Minutes

 

 

Jul. 7 2016: Agenda & Minutes

  • Agenda 
    • Functest, CI integration
    • Integration test
    • Documentation, user guide/configuration guide

Jun. 30 2016: Agenda & Minutes

Jun. 16 2016: Agenda & Minutes

  • Agenda 
    • test review and integration
    • design summit  topics

 

Jun. 9 2016: Agenda & Minutes

  • Agenda 
    • test review and integration
    • design summit  topics

 

Jun. 2 2016: Agenda & Minutes

May.26 2016: Agenda & Minutes

May.19 2016: Agenda & Minutes

  • Agenda 
    • code left to be implemented in C
    • test needed for quality improvement
    • test integration into pipeline
    • design summit preparation

May.12 2016: Agenda & Minutes

May.5 2016: Agenda & Minutes

  • Agenda
    •  Kingbird feature development and Colorado integration
  • Minutes
  • Links

Apr.14, 2016: Agenda & Minutes

  • Links

Apr. 7, 2016: Agenda & Minutes

  • Links

Mar. 31, 2016: Agenda & Minutes

Mar.17, 2016: Agenda & Minutes

Mar.10, 2016: Agenda & Minutes

Mar.3, 2016: Agenda & Minutes

Feb.25, 2016: Agenda & Minutes

Feb.18, 2016: Agenda & Minutes

Jan.28, 2016: Agenda & Minutes

Jan.21, 2016: Agenda & Minutes

Jan.14, 2016: Agenda & Minutes

Dec.10, 2015: Agenda & Minutes

Dec.3, 2015: Agenda & Minutes

Nov.19, 2015: Agenda & Minutes

Nov.5, 2015: Agenda & Minutes

Oct.14, 2015: Agenda & Minutes

Oct.1, 2015: Agenda & Minutes

Sept 24, 2015: Agenda & Minutes

  • Agenda
    • JIRA ticket follow up and sprint plan for B release
    • Use case 4: Centralized service for resources management and/or replication (sync tenant resources like images, ssh-keys, security groups, etc)
    • one solution for quota management "https://etherpad.opnfv.org/p/centralized_quota_management".
  • Minutes
    • jira ticket and sprint (joehuang, 08:06:02)
      • <joehuang> could we finish review for use case 1/2/3 before the OCT 25, so that we finish the sprint 1, after that we spend 2 month for use case 4/5 review
      • [16:08] <joehuang> and we are now discussing use case 4 and later use case 5
      • [16:08] <joehuang> there are use case 1/3 in review/approve process in gerrit
      • [16:09] <joehuang> and because Colin has some issue in access gira, I will help him prepare use case 2 for review and approve
      • [16:09] <sorantis> I’ll review the commits asap
    • use case 4 discussion (joehuang, 08:11:56)
    • https://etherpad.opnfv.org/p/multisite_usecase_collection (joehuang, 08:13:33)
    • https://etherpad.opnfv.org/p/centralized_quota_management (joehuang, 08:16:38)
    • http://openstack-in-production.blogspot.se/2015/03/nova-quota-usage-synchronization.html (sorantis, 08:26:05)
    • https://docs.google.com/document/d/19BXf0RhkH8wEEymE2eHHqoDZ67gnzgvpr3atk4qwdGs/edit (joehuang, 08:45:05)
    • https://wiki.openstack.org/wiki/Tricircle (joehuang, 08:48:35)
    • [16:53] <joehuang> I also have another idea to have a standalone service for distributed cloud, used for post control for quota , but group resource view and proactive on demand replication for ssh keys/ image/seg
    • [16:54] <joehuang> but service provisioning for VM/volume/network will be directly called to each region seperately
    • [16:55] <sorantis> ok, that’s what I’m also aiming for. Have a service working aside, quite transparent, which has zero impact on the openstack codebase
    • [16:55] <joehuang> even for ceilometer part ( use case 5 ), view will be generated with task maner and collect information on demand
    • [16:57] <joehuang> the centralized service will collect usage from each region periodicly, and send alarm to tenant if the quota is exceeded
    • [16:57] <joehuang> this will be post control
    • [16:58] <sorantis> without any action taken?
    • [16:59] <joehuang> if need, then your proposal is a good compliment
    • [17:01] <sorantis> good. will you have time to describe your idea on etherpad before the next meeting ?
    • [17:01] <joehuang> I'll

Sept 10, 2015: Agenda & Minutes

Sept 3, 2015: Agenda & Minutes

Aug 27, 2015: Agenda & Minutes

Aug 20, 2015: Agenda & Minutes

Jul 23, 2015: Agenda & Minutes

Jul 16, 2015: Agenda & Minutes

  • Agenda
  • Minutes
    • use case 1 identity service management (joehuang, 08:06:19)
      • 08:16:41 <colintd_> My point is that we should be clear about what changes we want to allow if the network is partitioned, and then critically how the resulting system converges when the partition ends.
      • 08:17:23 <colintd_> Many telcos have a very hard requirement that geographic sites should be able to operate as isolated entities to deal with earthquake. flood, fire, etc knocking out interconnects.
      • 08:17:53 <colintd_> They normally need to ability to make changes in the isolated site to deal with changing circumstances
      • if not each site installed with KeyStone service, we have to process "Escape from site level KeyStone failure" use case. I'll go on the prototype, and let's mark what colin's concerns and see how to address it (zhipeng, 08:24:52)
    • use case 2. VNF high availability across VIM
      • 08:32:37 <zhipeng> #agreed #2 is intrasite clouds, #3 is intersite clouds
      • 08:38:13 <colintd_> To my the biggest difference between #2 & #3, is that #2 is all about maintaining media/signalling and calls (which requires IP transfer), whilst #3 is about restoring/continuing service but most likely not calls.
      • 08:38:49 <colintd_> (use case)#3 does not require special openstack networking support, (use case)but #2 does.
      • 08:39:32 <zhipeng> #agreed inter-cloud intra-site L2 and L3 networking enhancement is one requirement from OPNFV Multisite to OpenStack
      • 08:42:06 <joehuang> Agree, but we need to describe that from two aspect, one is for VNF communication to other VNF (inter-VNF), another one is for VNF internal communition for heart-beat, session replication(intra-VNF)
      • For L2 the major requirements relate to config/management of those networks. For L2 do you need to use provider networks? Exactly how do you disable anti-spoof support? etc. For L3 it might make sense to have a common neutron api for the take IP/ free IP support, which can then be plumbed onto multiple underlying technologies. In fact it (zhipeng, 08:43:59)
      • may even make sense to use the same API for L2, just have it trigger GARP. (fzdarsky, 08:44:42)
      • 08:46:12 <colintd_> The latter leads onto cross-cloud tenant networks
      • 08:46:47 <joehuang> agree, it's cross-cloud tenant networks for intra-VNF traffic
      • 08:57:06 <zhipeng> #agreed second req out of use case #2 given intra-site inter-cloud enhancement on L2/L3 IP traffic transfer (inter and intra VNF) is a requirement from OPNFV Multisite to OpenStack
      • ACTION: colintd_ to reword the req to be more accurate (smile) (zhipeng, 08:57:26)

         

        {group3}* link(meetbot doesn't work well, only log linked here, refer to "Minutes" section for the summary):

  • [17:00] <@collabot> Log: http://ircbot.wl.linuxfoundation.org/meetings/opnfv-meeting/2015/opnfv-meeting.2015-07-16-08.01.log.html

Jul 9, 2015: Agenda & Minutes

Jul 2, 2015: Agenda & Minutes

  • Agenda
    • use cases prioritization
      • B-release goal discussion
      • minimum viable use cases
      • want but at risk use cases
      • out plan use cases
  • Minutes
    • use cases merged:
      • Use case 1: multisite identity service management
      • Use case 2. VNF high availability across VIM
      • Use case 3. VNF Geo-site Redundancy
      • Use case 4. Centralized service for resources management and/or replication (sync tenant resources like images, flavor, ssh-keys, security groups, etc)
      • Use case 5. centralized monitoring service
      • proposed use case prioritization, 1, (2), 3,4,5. But the diversity is still on the use case 2, for those who need this deployment scenario, it's the highest priority, but for those who don't want, it's the lowest one.
      • at least deliver use cases/requirements/gap analysis for B-release, for BP/spec/code approvement, it's up to OpenStack
      • meeting log

Jun 25, 2015: Agenda & Minutes

  • Agenda
    • use case 2 discussion:
      • IP movement between OpenStack instances
      • Cross Neutron L2/L3 networking for heart-beat/state(session)replication
      • image replication between OpenStack instances
  • Minutes (the meetbot doesn't work today)
    • [16:07] <joehuang> #info today's agenda: IP movement between OpenStack instances, Cross Neutron L2/L3 networking for heart-beat/state(session)replication
    • [16:08] <joehuang> #info if we have time, then image replication between OpenStack instances
    • [16:10] <joehuang> How about address-pair to be used in the IP movement to archieve the HA for VNF across OpenStack
    • [16:15] <joehuang> the IP address to communicate with other VNF/PNF should be an IP address from provider network
    • [16:15] <joehuang> because the VNF has to talk to PNF at the pratical deployment
    • [16:26] <sorantis> but do we necessarily need to automate this with provider network devices?
    • [16:29] <sorantis> I guess, you can configure the physical router prior to, let’s say MME deployment? and then provide the configured IP addresses upon deployment of MME.
    • [16:31] <sorantis> you can have a separate tool working with that specific provider physical hardware and producing these IP addresses, that later on could be used as deployment parameters for MME
    • [16:31] <sorantis> if you mean that this tool is part of VNFM then yes
    • [16:32] <sorantis> on the other hand why should VNFM be concerned about this.
    • [16:32] <sorantis> A VNF can expect some input parameters. The values for this parameters can come from anywhere, as long as they are correct for deployment
    • [16:33] <sorantis> so I wouldn’t necessarily harden this function into VNFM
    • [16:33] <joehuang> just want to clarify whether these IP address management should be the responsibility of VIM
    • [16:34] <joehuang> we can exclude this functionality (IP address management, which is used for interaction among VNF/PNF) from VIM, i.e from OpenStack
    • [16:35] <sorantis> i think so
    • [16:35] <sorantis> i mean at least for this case
    • [16:36] <tallgren> Sorry to interrupt: some SDN solutions want to manage the IPs for the VNFs, so this should be included
    • [16:37] <sorantis> can SDN be used for that?
    • [16:37] <joehuang> these SDN controller running above OpenStack, and manipulate VNF, isn't it
    • [16:39] <sorantis> SDN controller interacts with network devices, no? sorry, I’m not very familiar with SDN
    • [16:39] <joehuang> to tallgren: can you eloborate how to do that
    • [16:40] <tallgren> When your VNF starts and creates a port, it gets an IP from the SDN controller
    • [16:41] <fzdarsky> SDN controller acting as DHCP server
    • [16:41] <joehuang> but currently, the IP/mac is allocated in Neutron, or with one driver
    • [16:41] <sorantis> so can we say that this is the SDN controller’s responsibility to provide an IP address for the VNF?
    • [16:42] <fzdarsky> that would be an SDN controller plugged under Neutron, right?
    • [16:42] <sorantis> yes
    • [16:43] <fzdarsky> With PNFs, the OSS/BSS currently configures FQDNs (via the EM) and the PNFs then resolve to IP via DNS.
    • [16:44] <tallgren> When you create a network in OpenStack (Neutron), you need to know how the IP management will be done
    • [16:44] <fzdarsky> The IP being assigned from a managed address pool by DHCP.
    • [16:44] <tallgren> Yes
    • [16:45] <joehuang> so the IP is from a VLAN provider network, or as a floating IP from external network
    • [16:46] <joehuang> from your description, it's from a VLAN provider network?
    • [16:49] <joehuang> ok, how the standby will get the IP before it become the master, if the mater failed
    • [16:49] <fzdarsky> Is there a figure somewhere that illustrates the use case?
    • [16:49] <joehuang> we can draw a figure after the meeting, but not now
    • [16:50] <tallgren> BTW, I am not sure if this is a side track, but floating IPs do not really work with IPv6
    • [16:50] <xiaolong> sorry, I change a littel bit the subject of discussion, is there any VNF which should be d eployed across multiple site or multiple openstack instances?
    • [16:50] <joehuang> #action joehuang draw a figure for the use case 2, especially the IP address https://wiki.opnfv.org/_media/multisite/vnf_ha_across_vim.png
    • [16:51] <joehuang> this is the use case 2. two openstack instances in one site, and the master in one OpenStack, the standby in the other one
    • [16:51] <tallgren> I would not deploy a VNF across OpenStack instances
    • [16:51] <fzdarsky> xiaolong, not a single VNF instance, but one active and one standby instance.
    • [16:59] <xiaolong> ok, thanks for the explanation. I think we need more clear definition about the use case
    • [16:59] <fzdarsky> If we talk about failover across regions that's a different thing
    • [17:00] <sorantis> failover between AZs technically means that you have to VNF instances running in the same cloud
    • [17:00] <fzdarsky> --> different API endpoints, no coordination between regions
    • [17:00] <joehuang> It's difficult to draw a conclution today to include the IP address management or not. Let's continue discuss next time. Before next meeting, hope that we can discuss in mailist. And whether the use case shoudl be addressed
    • [17:00] <xiaolong> I also need to understand if we need to have a so complicated architecture : multi-AZ, multi-region inside multi-site

Jun 18, 2015: Agenda & Minutes

  • Agenda
    • Gap analysis for use case 2
  • Minutes
    • I'm was focussing on the need to be able to redirect external traffic between application instances sitting in one or more "local" clouds. (colintd, 08:36:58)
    • Where the example was suggested (I missed who) of a VNF implementing VRRP, with one instance in each of two clouds, and the question being what config/changes are needed to allow this to work ( is anti-spoof an issue) (zhipeng, 08:38:17)
    • I'm was focussing on the need to be able to redirect external traffic between application instances sitting in one or more "local" clouds. (colintd, 08:38:43)
    • We also talked about SND controllers, and how in many telco deployments these control much broader end-to-end traffice than simply intra-cloud. They might however be implemented using multiple redundant control nodes, say one per cloud, but providing a global function. (colintd, 08:39:46)
    • In this case neutron may be used to "connect" to those networks, but isn't the major control interface for the whole system, just a "joining" interface (colintd, 08:40:17)
    • Finally, returning to traffic failover, we talked about how for L2 failover can be triggered by apps just using GARP, but L3 requires protocol level (BGP/SDN) API. We also talked about how L3 convergence times (say BGP) might be too slow by default, especially in error cases (loss of node) as opposed to managed failover. (colintd, 08:42:03)
    • <colintd>Moving the IP address is required when you have a core node serving lots of remote endpoints in the external network (e.g. voip phones with RTP streams). On failover it is too slow to resignal all of those, so you need to redirect traffic to the new node. Given routing is based on IP address, this needs to be moved
    • HA with VRRP http://blog.aaronorosen.com/implementing-high-availability-instances-with-neutron-using-vrrp/ (sorantis, 08:57:36)
    • We are looking at similar function between clouds, for which this may or may not need to be extended. May also be interplay with provider networks. (colintd, 08:58:18)
    • I will investigate before the next meeting. (colintd, 08:58:27)

Jun 11, 2015: Agenda & Minutes

  • Agenda
    • Gap analysis for use case 2, use case 4.1.2, use case 4.1.3, If we have enough time, then discuss use case 4.1.1 and 1
  • Minutes
    • https://etherpad.opnfv.org/p/multisite_usecase_collection (zhipeng, 08:06:47)
    • Centralized resource management required for multi-site resource management. (Malla, 08:09:40)
    • Keystone supports regions concept as part of an endpoint. This enables communicating with all the registered regions via corresponding endpoints (sorantis_, 08:16:50)
    • promise project is working on resource management, maybe we can get some information if discuss with promise project folks. (Malla, 08:17:23)
    • <joehuang>does promise support multi-site?
    • <xiaolong>to make things cear, let's talk about a concret use case: a user wants to know his total virtual resources (cpu, ram, disk) across multiple regions and multiple openstack instances, how can he do that?
    • <sorantis_> can the user use a "for" loop?
    • <xiaolong> no, if it needs that the user programs himself, it is a problem
    • <sorantis_> I think creating another layer of APIs just for the sake for hiding a for loop is overkill
    • some "for" loop multi-tenancy discussion here
    • <xiaolong> let's think more about the user cases, without talk about the presentation layer, is there any more operation we should do beside the simple "for loop", at least, aggregation (sum), sort, select?
    • <joehuang> Is there any one want to use Cells with shared Nova,Cinder,Neutron...in multisite?
    • <sorantis> cells probably are best to use withing a large datacenter
    • AGREED: : cells probably are best to use withing a large datacenter (joehuang, 08:46:21)
    • <sorantis> for me the stated use-case easily be addressed with a simple iteration
    • <joehuang> But if you look at the use case 4.1.4
    • <joehuang> The resource utilization also should be controlled by quatos
    • Quota and usage discussion
    • <joehuang> Total resource view means your total quota in multi-site
    • <sorantis> if we user the same definitions as in nova, neutron, cinder, etc. then quota is a limit you apply on a resource type. Quota usage is the amount of resources currently in use

Jun 4, 2015: Agenda & Minutes

  • Minutes
    • Colin explains on the Geo-Redundancy (zhipeng, 08:09:57)
    • Colin mentions that the current cinder and swift replication scheme risks fault propagation (zhipeng, 08:26:49)
    • Joe explains various currently available OpenStack solutions for multi site scenario (zhipeng, 08:34:34)
    • Dimitri mentions that Nova Cell is now built in and may take momentum (zhipeng, 08:37:09)
    • Dimitri says CERN, Rachspace, Godady all use Cell, although with modification (zhipeng, 08:46:08)

May 28, 2015: Agenda & Minutes

  • Minutes
    • Joe explains the Keystone multisite failover use case (zhipeng, 08:15:33)
    • no question for Keystone Use Case, Joe go on to explain the VNF HA multisite Use Case (zhipeng, 08:20:15)
    • for HA Use Case, two main gaps are targeted (zhipeng, 08:25:06)
    • overlay l2 network and shared floating IP, across multiple sites (zhipeng, 08:25:32)
    • Jun Li (zhipeng, 08:26:49)
    • Xiaolong suggests to have requirements, besides use cases (zhipeng, 08:28:33)
    • Xiaolong suggests to have a centralized platform for mgmt, so item 4 and 5 maybe should be merged (zhipeng, 08:30:17)
    • Malla question about Keystone (zhipeng, 08:32:50)
    • Malla asks it seems the current Keystone solution is already distributed, and can support the requirement (zhipeng, 08:36:44)
    • Joe answers that even if Keystone could be deployed distributed across multisite, it would be almost impossible to manage the DBs (zhipeng, 08:38:14)
    • Malla asks for VNF HA use case, how to hand over to the standby VM seemlessly (zhipeng, 08:39:09)
    • Joe answers that when standby VM detects the failure, or an arbitrator detect the failure, then the handover process starts (zhipeng, 08:40:40)
    • Joe asks Xiaolong which token type would he prefer, UUID, pki or fernet (zhipeng, 08:44:18)
    • Xiaolong expressed maybe pki are prefered (zhipeng, 08:44:43)
    • Resource quota is very difficult in multi-site openstack. (malla, 08:49:33)
    • Malla asks for Telco WG, if they've alreay started the same work (zhipeng, 08:49:41)
    • Joe answers that there is no similar work currently (zhipeng, 08:51:12)
    • Malla suggest to invite OpenStack multisite guys over to the meeting (zhipeng, 08:52:50)
    • maybe a special meeting with North America guys in OpenStack (zhipeng, 08:53:46)
  • Minutes
    • Xiaolong propose to have a wiki for collboration (zhipeng, 08:19:48)
    • Uli propose to use etherpad for early discussion (zhipeng, 08:20:39)
    • AGREED: use Etherpad for early discussion, wiki editing will begin as soon as any conclusion reached at the Etherpad (zhipeng, 08:24:03)
    • AGREED: gather use cases from each committer first, and then do the categorization and owner appointment (zhipeng, 08:29:54)

§  Release C preparation. 

§  Kingbird discussion 

§  Other topics 

May.5 2016: Agenda & Minutes

Agenda of May 26, 2016 

§  test integration into pipeline

§ design summit preparation

  • No labels