08:01:45 <joehuang> #startmeeting multisite
08:01:45 <collabot> Meeting started Thu Aug 27 08:01:45 2015 UTC.  The chair is joehuang. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:01:45 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic.
08:01:45 <collabot> The meeting name has been set to 'multisite'
08:02:10 <Malla> HI
08:02:15 <joehuang> #topic rollcall
08:02:17 <joehuang> hi
08:02:20 <zhipeng> #info zhipeng
08:02:29 <joehuang> #info joehuang
08:02:30 <Malla> #info Malla
08:04:06 <joehuang> #link https://etherpad.opnfv.org/p/multisite_usecase_collection
08:04:25 <joehuang> #topic Use case 3: VNF Geo-site Redundancy
08:05:01 <joehuang> before the use case 3
08:05:20 <joehuang> I 'll introduce the work for use case 1 and 2
08:05:31 <joehuang> for use case 1
08:05:58 <joehuang> #info for the use case 1, after the prototype, one bug regirstered
08:06:25 <joehuang> #link https://bugs.launchpad.net/keystonemiddleware/+bug/1488347
08:06:40 <joehuang> the issue has been confirmed by keystone core
08:07:16 <joehuang> after the bug solved, we at least one way to archieve use case 1 goal
08:07:29 <joehuang> #info after the bug solved, we at least one way to archieve use case 1 goal
08:08:00 <zhipeng> hafe here ?
08:08:06 <joehuang> #info we'll not put more focus on use case 1 then. Only other requirement or issue found
08:09:09 <joehuang> #info for use case 2, conclusion in the meeting is that there are existing cross Neutron L2/L3 networking requirement to OpenStack
08:09:47 <joehuang> #info and for use case 2, two RFE( request for exception ) were registered
08:10:19 <sorantis> can we include the preliminary conclusion for u-c 1 in here https://etherpad.opnfv.org/p/multisite_identity_management
08:10:46 <joehuang> ok, will update it there
08:11:07 <joehuang> Is Hans in this meeting
08:11:25 <zhipeng> I was asking but no reply back from him :)
08:11:36 <joehuang> Hans or I can update the etherpad
08:12:05 <joehuang> for use case 2, these two RFE will be converted to BP for M release
08:12:45 <joehuang> then we can join the discussion/review/coding together there. Other BPs for L2 connection welcome to register
08:13:02 <joehuang> hi, Xiaolong, welcome back
08:13:08 <zhipeng> #info shall we co-sign on the BP so it shows it is from collective effort from Multisite project?
08:13:10 <Xiaolong> hi, sorry I am late
08:13:42 <joehuang> yes, co-author for BP/coding
08:13:54 <zhipeng> #link https://wiki.opnfv.org/multisite/bug_bp
08:14:02 <joehuang> #info co-author for BP/coding
08:14:23 <joehuang> #info or register new BP for same purpose
08:14:37 <zhipeng> since for now joe is leading the effort, and some colleagues from Huawei are supporting him, but these are BPs derived from Multisite use cases
08:14:54 <zhipeng> we need to some how show this is a community effort, not from a single company :)
08:15:05 <joehuang> for sure
08:15:26 <sorantis> Colin had a say on this use case
08:15:30 <sorantis> is he online?
08:15:46 <zhipeng> did't see his irc handle
08:15:48 <joehuang> the second RFE one is linked to the effort from multisite
08:16:46 <joehuang> Not see Colin online
08:17:10 <joehuang> one AI for Colin to rephrase the use case, and a JIRA item will be created for this
08:17:28 <joehuang> now let's talk about the use case 3
08:17:50 <joehuang> VNF DR is a very big topic
08:18:04 <zhipeng> #action Colin to rephrase the use case, and a JIRA item will be created for this
08:18:21 <joehuang> multisite does not intend to cover all the DR e2e
08:18:37 <joehuang> but focus on how to enhance openstack to make it possible
08:19:06 <zhipeng> shall we also involve HA project in this discussion ?
08:20:44 <joehuang> good idea, how to get invovled
08:21:00 <zhipeng> I will let Fuqiao know
08:21:15 <zhipeng> #action zhipeng to contact HA team about DR discussion
08:21:17 <joehuang> great
08:21:31 <sorantis> have these topics been brought up to the Cinder team?
08:21:46 <zhipeng> DR is not a great concern for them
08:22:02 <zhipeng> at least from my experience discussing with them
08:22:05 <sorantis> DR?
08:22:08 <zhipeng> yep
08:22:10 <sorantis> you mean GR?
08:22:33 <joehuang> GR
08:22:45 <zhipeng> ahh
08:22:53 <joehuang> VNF Geo-site Redundancy
08:22:54 <zhipeng> my bad :)
08:23:32 <zhipeng> anyways cinder is still relying on a very primative replication mechanism
08:23:44 <joehuang> one rough idea about GR
08:23:48 <zhipeng> John Griffith proposed something new in L I think
08:23:54 <zhipeng> but no idea how that goes
08:23:59 <mpo> are you using this netmeeting ? https://global.gotomeeting.com/join/959683557
08:24:16 <joehuang> to mpo: not
08:24:22 <joehuang> IRC only
08:24:52 <mpo> ok thanks joehuang
08:24:58 <joehuang> the rough idea is to leverage the volume replication function of cinder and manage/un-manage
08:25:08 <joehuang> of cinder
08:25:27 <Xiaolong> about the use case 3, I have a question: are we talking about application level (VNF) replication or infrastructure level (Openstack, hardware, ...) replication?
08:25:31 <joehuang> #info the rough idea is to leverage the volume replication and manage/un-manag function of cinder
08:25:42 <joehuang> application level
08:25:47 <joehuang> to Xiaolong
08:25:52 <joehuang> application level
08:26:01 <Xiaolong> if so, it doesn't concern cinder
08:26:12 <Xiaolong> and it maybe application dependant?
08:26:20 <zhipeng> enhancement on infra level to support app level GR
08:26:39 <joehuang> to zhipeng: correct
08:27:24 <zhipeng> Xiaolong what Joe meant was that we don't deal with GR on OpenStack itself, rather to make OpenStack more capable to support VNF GR
08:27:37 <sorantis> +1
08:27:50 <joehuang> recover VNF from the geographic sites if catastrophic failures occured
08:28:06 <Xiaolong> ok
08:29:42 <joehuang> the rough idea is to replicate the volume of VNF from local site to remote site based on Cinder volume replication function
08:30:33 <joehuang> and the GR software will get the reference of the volume in the storage in the remote site
08:30:49 <joehuang> when catastrophic failures occured
08:31:20 <joehuang> the GR software will use cinder manage function to restore the replicated volume in the remote site
08:31:34 <sorantis> who triggers replication?
08:31:36 <joehuang> and reboot all VNF in remote site
08:32:09 <joehuang> the replication itself will be triggered by the storage cinder volume driver
08:32:37 <Xiaolong> ok, I see, thanks: it means data/volume replication between remote and local sites
08:32:46 <joehuang> yes
08:33:13 <joehuang> so that the VNF can re-start in remote site quickly
08:33:43 <joehuang> but it's not daily running active-standby or A-A
08:34:52 <joehuang> through this way, we have a relative easy way to restore VNF ( including system volume and data volume )
08:35:31 <joehuang> the missing feature is how to get the remote replicated volume reference in remote storage
08:36:41 <joehuang> your ideas?
08:37:00 <Xiaolong> To do that, instead of replying on cinder or openstack capacity, we can also use replication mechanismes of DBMS (mysql, mongo, ...)
08:38:07 <joehuang> what's the content in the DBMS to be replicated?
08:38:25 <joehuang> VM/Volume metadata, or the data of VNF
08:38:40 <Xiaolong> why not all the content?
08:39:21 <Xiaolong> not vm/volume metadata, vnf configuration and generated data
08:39:34 <joehuang> VM's system volume including OS and application executable binary data, data volume include data generated in running time
08:40:33 <Xiaolong> why do vm/volume level replication? we can remain on app level
08:40:34 <joehuang> yes, if we have file level replication, it's ok. and the remote system should be running two
08:40:53 <joehuang> yes, if we have file level replication, it's ok. and the remote system should be running too
08:41:20 <zhipeng> does Manila mature enough to support this ?
08:43:00 <sorantis> they’ve got 2 releases already
08:43:33 <joehuang> not sure about the mature of Manila
08:47:36 <zhipeng> so regarding Xiaolong's concern, what we could do with additional use of replication mechanisms of DBMS ?
08:47:37 <joehuang> so the file level replication is preferred?
08:47:58 <Xiaolong> my personal opinion about this use cae: for the infra level replication mechanisme, we should work with HA since they have the same(or higher) requirements; for application level replication mechanisme, it should be app dependant (esp DBMS), no generaic solution
08:48:06 <zhipeng> no i think that should be parallel to block level GR
08:49:04 <joehuang> there is one AI that zhipeng will reach HA for this topic
08:49:43 <Xiaolong> yes, so not really necessary to do a specific discussion before that
08:50:11 <joehuang> OK
08:50:20 <zhipeng> Xiaolong HA has a much higher requirement on GR
08:50:30 <zhipeng> active-active or active-standby
08:50:43 <Xiaolong> who can do more can do less
08:50:49 <zhipeng> we also need regular standby-standby GR
08:50:53 <zhipeng> in Multisite
08:51:13 <zhipeng> we cover different levels
08:51:50 <zhipeng> and since we are dealing with OPNFV, we are mostly thinking of the management platform enhancement :)
08:52:04 <zhipeng> hence with the Cinder, Manila, Swift enhancement on GR
08:52:59 <zhipeng> that's why I think the reason for Joe's proposal on cinder volume replication
08:53:25 <zhipeng> no matter what storage backend we use, the mgmt platform need to know what to do with it
08:53:35 <joehuang> I am afraid the overlapping with HA team
08:54:01 <zhipeng> partial overlapping I think
08:54:17 <joehuang> so let's talk this with HA team, to see if we need to put more focus on it or not
08:54:19 <sorantis> does HA team take into account the multisite scenario?
08:54:36 <joehuang> good question
08:54:59 <joehuang> we can confirm with HA team offline
08:55:08 <sorantis> they might have similar issues to tackle, but cross-cloud replication might not be one of those
08:55:19 <zhipeng> sorantis +1
08:55:30 <joehuang> maybe
08:56:34 <joehuang> so let's conclude this meeting #action zhipeng to contact HA team about DR discussion
08:57:36 <joehuang> what'll be discussed next meeting based on the m-l discussion
08:57:55 <zhipeng> great
08:58:05 <joehuang> Thank you for attending today's meeting
08:58:11 <joehuang> see you next time
08:58:26 <Xiaolong> thanks you, bye
08:58:29 <joehuang> byte
08:58:29 <sorantis> bye
08:58:37 <joehuang> #endmeeting