https://etherpad.openstack.org/p/cinder-replication-redoc
https://etherpad.openstack.org/p/cinder-replication-cg
https://etherpad.openstack.org/p/volume-replication-fix-planning
Jay seems to be the champion for moving replication forward, I will let Jay point the way.
-- Ronen
From: Zhipeng Huang <zhipengh...@gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Date: 16/02/2015 09:14 AM
Subject: Re: [openstack-dev] [cinder] volume replication
Hi Ronen,
Xingyang mentioned there's another etherpad on rep and CG, which etherpad should we mainly follow ?
On Mon, Feb 16, 2015 at 2:38 PM, Ronen Kat <ronen...@il.ibm.com> wrote:
Ruijing, hi,
Are you discussing the network/fabric between Storage A and Storage B?
If so, assumption in Cinder is that this is done in advance by the storage administrator.
The design discussions for replication resulted in that the driver is fully responsible for replication and it is up to the driver to implement and manage replication on its own.
Hence, all vendor specific setup actions like creating volume pools, setup network on the storage side are considered prerequisite actions and outside the scope of the Cinder flows.
If someone feels that is not the case, or should not be the case, feel free to chime in.
Or does this relates to setting up the data path for accessing both Storage A and Storage B?
Should this be setup in advance? When we attach the primary volume to the VM? Or when promoting the replica to be primary?
-- Ronen
From: "Guo, Ruijing" <ruijing....@intel.com>
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Date: 16/02/2015 02:29 AM
Subject: Re: [openstack-dev] [cinder] documenting volume replication
Hi, Ronen
3) I mean storage based replication. In normal, volume replication support FC or iSCSI. We need to setup FC or iSCSI before we do volume replication.
Case 1)
Host ------FC------Storage A -------iSCSI -------- Storage B ----FC----- Host
Case 2)
Host ------FC------Storage A -------FC -------- Storage B ----FC----- Host
As above diagram, we need to setup connection (iSCSI or FC) between storage A and Storage B.
For FC, we need to zone storage A & storage B in FC switch.
Thanks,
-Ruijing
From: Ronen Kat [mailto:ronen...@il.ibm.com]
Sent: Sunday, February 15, 2015 4:46 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder] documenting volume replication
Hi Ruijing,
Thanks for the comments.
Re (1) - driver can implement replication in any means the driver see fit. It can be exported and be available to the scheduler/drive via the "capabilities" or "driver" extra-spec prefixes.
Re (3) - Not sure I see how this relates to storage side replication, do you refer to host side replication?
Ronen
From: "Guo, Ruijing" <ruijing....@intel.com>
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Date: 15/02/2015 03:41 AM
Subject: Re: [openstack-dev] [cinder] documenting volume replication
Hi, Ronen,
I don’t know how to edit https://etherpad.openstack.org/p/cinder-replication-redoc and add some comments in email.
1. We may add asynchronized and synchronized type for replication.
2. We may add CG for replication
3. We may add to initialize connection for replication
Thanks,
-Ruijing
From: Ronen Kat [mailto:ronen...@il.ibm.com]
Sent: Tuesday, February 3, 2015 9:41 PM
To: OpenStack Development Mailing List (openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [cinder] documenting volume replication
As some of you are aware the spec for replication is not up to date,
The current developer documentation, http://docs.openstack.org/developer/cinder/api/cinder.volume.driver.html, cover replication but some folks indicated that it need additional details.
In order to get the spec and documentation up to date I created an Etherpad to be a base for the update.
The Etherpad page is on https://etherpad.openstack.org/p/cinder-replication-redoc
I would appreciate if interested parties would take a look at the Etherpad, add comments, details, questions and feedback.
Ronen, __________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Zhipeng (Howard) Huang
Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen
(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402
OpenStack, OpenDaylight, OpenCompute affcienado __________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
