[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 ?

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)

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: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)

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

[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

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