Hi, We ran into a requirement where we need to mark a DataCenter or Cluster as remote. This is for the feature Gluster Geo-replication management - where the same oVirt instance will be managing both the master volume and as well as the remote site volume The reason we want to call out a Datacenter as remote, is to ensure that the polling frequency on this is different from one that is co-located. Is there a similar requirement for virtualization? thanks sahina

On 08/21/2014 03:42 PM, Itamar Heim wrote: > On 08/21/2014 05:00 AM, Sahina Bose wrote: >> Hi, >> >> We ran into a requirement where we need to mark a DataCenter or Cluster >> as remote. This is for the feature Gluster Geo-replication management - >> where the same oVirt instance will be managing both the master volume >> and as well as the remote site volume >> >> The reason we want to call out a Datacenter as remote, is to ensure >> that >> the polling frequency on this is different from one that is co-located. >> >> Is there a similar requirement for virtualization? >> >> thanks >> sahina > > I thought in the gluster view there are no DCs, only clusters? > (actually, i wonder if we shouldn't consider the same for the virt > use case, and deprecate the DC entity, though that would be a major > effort and not sure worth it). In fact, we were wondering if we need to bring in the concept of DC for the gluster view and mark it remote...or just stick with flagging cluster as Remote :)

Users may be more familiar with DC w.r.t DR > > to your question, yes. there is a similar use case for virt - > flagging a DC or Cluster and Storage as remote for a DR use case. > though i don't think anyone spent cycles on modeling that _______________________________________________ Devel mailing list Devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/devel

From: "Sahina Bose" <sabose(a)redhat.com&gt; To: "Dusmant Kumar Pati" <dpati(a)redhat.com&gt;, "Itamar Heim" <iheim(a)redhat.com&gt;, devel(a)ovirt.org, "Allon Mureinik" <amureini(a)redhat.com&gt;, "Oved Ourfali" <ovedo(a)redhat.com&gt;, "Liron Aravot" <laravot(a)redhat.com&gt;, "Omer Frenkel" <ofrenkel(a)redhat.com&gt;, "Yair Zaslavsky" <yzaslavs(a)redhat.com&gt;, "Roy Golan" <rgolan(a)redhat.com&gt; Sent: Thursday, September 25, 2014 8:31:11 AM Subject: Re: [ovirt-devel] Remote DataCenter/Cluster On 08/25/2014 10:13 AM, Dusmant Kumar Pati wrote: > On 08/21/2014 03:57 PM, Sahina Bose wrote: >> >> On 08/21/2014 03:42 PM, Itamar Heim wrote: >>> On 08/21/2014 05:00 AM, Sahina Bose wrote: >>>> Hi, >>>> >>>> We ran into a requirement where we need to mark a DataCenter or >>>> Cluster >>>> as remote. This is for the feature Gluster Geo-replication >>>> management - >>>> where the same oVirt instance will be managing both the master volume >>>> and as well as the remote site volume >>>> >>>> The reason we want to call out a Datacenter as remote, is to ensure >>>> that >>>> the polling frequency on this is different from one that is >>>> co-located. >>>> >>>> Is there a similar requirement for virtualization? >>>> >>>> thanks >>>> sahina >>> >>> I thought in the gluster view there are no DCs, only clusters? >>> (actually, i wonder if we shouldn't consider the same for the virt >>> use case, and deprecate the DC entity, though that would be a major >>> effort and not sure worth it). >> >> In fact, we were wondering if we need to bring in the concept of DC >> for the gluster view and mark it remote...or just stick with flagging >> cluster as Remote :) > I think your second option looks better, considering gluster does not > have any DC concept. Just stick with flagging cluster as Remote. > Once managed by RHSC (either local or remote), almost all features of > RHSC, should be applicable for that cluster as well. Isn't it? > If we do introduce a Remote cluster, how would that affect the Data Center for virt+gluster mode - having remote as well as local cluster? Thoughts?

>> Users may be more familiar with DC w.r.t DR >> >>> >>> to your question, yes. there is a similar use case for virt - >>> flagging a DC or Cluster and Storage as remote for a DR use case. >>> though i don't think anyone spent cycles on modeling that >> >> _______________________________________________ >> Devel mailing list >> Devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel >