----- Original Message -----
> From: "Eli Mesika" <emesika(a)redhat.com>
> To: engine-devel(a)ovirt.org
> Sent: Thursday, March 27, 2014 1:43:22 PM
> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to decrease
DC compatibility...
>
>
>
> ----- Original Message -----
>> From: "Moti Asayag" <masayag(a)redhat.com>
>> To: "Itamar Heim" <iheim(a)redhat.com>
>> Cc: "Eli Mesika" <emesika(a)redhat.com>, engine-devel(a)ovirt.org
>> Sent: Sunday, March 23, 2014 2:47:53 PM
>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to
>> decrease DC compatibility...
>>
>>
>>
>> ----- Original Message -----
>>> From: "Itamar Heim" <iheim(a)redhat.com>
>>> To: "Eli Mesika" <emesika(a)redhat.com>,
engine-devel(a)ovirt.org
>>> Sent: Sunday, March 23, 2014 12:14:37 PM
>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable
>>> to
>>> decrease DC compatibility...
>>>
>>> On 03/23/2014 12:13 PM, Eli Mesika wrote:
>>>>
>>>> So, as far a I understand for resolving this bug the following is OK :
>>>>
>>>> Block downgrading if there are Hosts or Networks (other than the
>>>> default
>>>> management network) or SD in the DC when downgrading.
>>>
>>> yes
>>>
>>
>> I don't think it is enough. There is a need to verify the management
>> network
>> wasn't modified to use unsupported features in the new data-center.
>>
>> On the same matter, we can allow downgrading if all of the networks in the
>> data center are using only features that are supported on the target DC
>> version
>> and not to restrict it only to the management network.
>
> Since Moti is in PTO, talked with Mike K to get advanced with that , we came
> to the following conclusion:
>
> when DC is downgraded :
> Block downgrading if there are Hosts or Networks (other than the default
> management network) or SD in the DC.
> In case that only default management network exists we should check that all
> network features are still supported (This can be done by adding a method
> to the NetworkValidator that will check for support of all relevant
> features)
>
> when Cluster is downgraded :
> Same as above , but we don't need to check for features validation since we
> can not downgrade below the DC version and therefor the cluster network is
> supposed to be valid already
>
> Mike, please let me know If I miss something from our discussion (and thanks
> for your kind help :-) )
+1 from me and Mike for the above.
Eli -
please note there is no need to block the DC downgrade if there are
hosts in the DC.
Thanks, Livnat
>
>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Livnat Peer" <lpeer(a)redhat.com>
>>>>> To: "Moti Asayag" <masayag(a)redhat.com>
>>>>> Cc: engine-devel(a)ovirt.org
>>>>> Sent: Friday, March 21, 2014 8:33:59 AM
>>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core:
>>>>> enable
>>>>> to decrease DC compatibility...
>>>>>
>>>>> On 03/20/2014 09:20 PM, Moti Asayag wrote:
>>>>>> ----- Original Message -----
>>>>>>> From: "Moti Asayag" <masayag(a)redhat.com>
>>>>>>> To: "Livnat Peer" <lpeer(a)redhat.com>
>>>>>>> Cc: "Itamar Heim" <iheim(a)redhat.com>,
engine-devel(a)ovirt.org
>>>>>>> Sent: Wednesday, March 12, 2014 10:44:07 PM
>>>>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]:
core:
>>>>>>> enable
>>>>>>> to decrease DC compatibility...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Livnat Peer" <lpeer(a)redhat.com>
>>>>>>>> To: "Moti Asayag" <masayag(a)redhat.com>
>>>>>>>> Cc: "Itamar Heim" <iheim(a)redhat.com>,
engine-devel(a)ovirt.org
>>>>>>>> Sent: Wednesday, March 12, 2014 10:33:45 PM
>>>>>>>> Subject: Re: [Engine-devel] Change in
ovirt-engine[master]: core:
>>>>>>>> enable
>>>>>>>> to
>>>>>>>> decrease DC compatibility...
>>>>>>>>
>>>>>>>> On 03/12/2014 10:20 PM, Moti Asayag wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: "Livnat Peer"
<lpeer(a)redhat.com>
>>>>>>>>>> To: "Itamar Heim"
<iheim(a)redhat.com>, engine-devel(a)ovirt.org
>>>>>>>>>> Sent: Wednesday, March 12, 2014 12:42:44 PM
>>>>>>>>>> Subject: Re: [Engine-devel] Change in
ovirt-engine[master]: core:
>>>>>>>>>> enable
>>>>>>>>>> to decrease DC compatibility...
>>>>>>>>>>
>>>>>>>>>> On 03/12/2014 11:59 AM, Itamar Heim wrote:
>>>>>>>>>>> On 03/12/2014 12:26 AM, emesika(a)redhat.com
wrote:
>>>>>>>>>>>> Eli Mesika has submitted this change and
it was merged.
>>>>>>>>>>>>
>>>>>>>>>>>> Change subject: core: enable to decrease
DC compatibility...
>>>>>>>>>>>>
......................................................................
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> core: enable to decrease DC
compatibility...
>>>>>>>>>>>>
>>>>>>>>>>>> enable to decrease DC compatibility
version if DC has no
>>>>>>>>>>>> clusters
>>>>>>>>>>>>
>>>>>>>>>>>> This patch enables to decrease the DC
compatibility version if
>>>>>>>>>>>> DC
>>>>>>>>>>>> has
>>>>>>>>>>>> no
>>>>>>>>>>>> clusters.
>>>>>>>>>>>
>>>>>>>>>>> Eli - just saw this. I'm pretty sure it
would be *bad* to
>>>>>>>>>>> downgrade
>>>>>>>>>>> a
>>>>>>>>>>> DC
>>>>>>>>>>> version if it has storage domains as well.
not sure if this is
>>>>>>>>>>> checked
>>>>>>>>>>> already or not.
>>>>>>>>>>>
>>>>>>>>>>> may also be an issue with some logical
network features.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Most of the network features are driven from
cluster level, we
>>>>>>>>>> enable
>>>>>>>>>> using the features on all DC level (actually
>=3.1) but actually
>>>>>>>>>> enable
>>>>>>>>>> /disable the feature when attaching the network
to a cluster.
>>>>>>>>>>
>>>>>>>>>> So from network perspective I think it should be
fine to
>>>>>>>>>> downgrade
>>>>>>>>>> the
>>>>>>>>>> DC level even if there are networks in the DC (at
least now this
>>>>>>>>>> could
>>>>>>>>>> change in future versions).
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Actually we block adding or updating networks if the
feature is
>>>>>>>>> not
>>>>>>>>> supported
>>>>>>>>> on the network's DC level, for example: STP,
Jumbo frames and
>>>>>>>>> non-vm
>>>>>>>>> network.
>>>>>>>>>
>>>>>>>>
>>>>>>>> From which DC level we support STP? Jumbo frames?
non-vm network?
>>>>>>>> isn't
>>>>>>>> all of them supported in >=3.1 ?
>>>>>>>>
>>>>>>>
>>>>>>> Yes, mainly the problem with downgrading a DC to 3.0.
>>>>>>>
>>>>>>
>>>>>> I had a discussion with Mike (cc'ed) about several possible
solutions
>>>>>> for the networks compatibility within the data-center.
>>>>>>
>>>>>> The first proposed solution would utilize the
NetworkUpdateValidator,
>>>>>> a validation utility that verifies the compatibility of a
network
>>>>>> to the data-center. This solution preserves the same behaviour
as
>>>>>> today,
>>>>>> that the features of network-level are dictated by the DC
version. No
>>>>>> need to reimplement any logic in the decrease DC version flow,
just
>>>>>> use
>>>>>> an existing one to be applied for any network within the DC.
>>>>>>
>>>>>> The second solution suggests we allow any settings of a network,
and
>>>>>> compatibility enforcement is done on attaching the network to
the
>>>>>> clusters.
>>>>>> This modifies the existing behaviour and expands the capabilities
of
>>>>>> the
>>>>>> engine to support advanced network feature in advanced cluster
within
>>>>>> an
>>>>>> old data center (i.e. cluster 3.4 in 3.0 data-center could and
>>>>>> probably
>>>>>> should use non-vm network, jumbo-frames and more).
>>>>>> This option requires more work in add/update network and attach
>>>>>> network
>>>>>> to
>>>>>> cluster
>>>>>> flows, both on the backend and UI. Specifically since by default
a
>>>>>> new
>>>>>> network
>>>>>> created in a DC is being attached to all of the clusters.
>>>>>> Perhaps the second option deserves to be treated as RFE and not
as a
>>>>>> bug
>>>>>> fix.
>>>>>>
>>>>>> Thoughts ?
>>>>>>
>>>>>
>>>>> The second approach you suggested is equivalent to creating networks
>>>>> in
>>>>> cluster level vs. DC level, which is used today.
>>>>>
>>>>> We should consider that for 4.0 and think on the pros and cons of
>>>>> doing
>>>>> so.
>>>>>
>>>>> In general for this specific discussion I think a simple block on DC
>>>>> downgrade should be enough.
>>>>>
>>>>>> Moti
>>>>>>
>>>>>>>>> Therefore if the management network was configured
with any of
>>>>>>>>> those
>>>>>>>>> feature,
>>>>>>>>> there is a need to either block the action or to
'initialize' the
>>>>>>>>> network
>>>>>>>>> to
>>>>>>>>> the default settings (as new network being added).
>>>>>>>>>
>>>>>>>>>> In general I believe the use case for this patch
is mostly for
>>>>>>>>>> empty
>>>>>>>>>> DCs
>>>>>>>>>> so for simplicity we should block it if there are
networks or SD
>>>>>>>>>> in
>>>>>>>>>> the
>>>>>>>>>> DC when downgrading.
>>>>>>>>>>
>>>>>>>>>> Livnat
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Change-Id:
I73284f641b7f80b380b39efbbd7b4566f55119b6
>>>>>>>>>>>> Bug-Url:
https://bugzilla.redhat.com/show_bug.cgi?id=1057029
>>>>>>>>>>>> Signed-off-by: Eli Mesika
<emesika(a)redhat.com>
>>>>>>>>>>>> ---
>>>>>>>>>>>> M
>>>>>>>>>>>>
backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/storage/UpdateStoragePoolCommand.java
>>>>>>>>>>>>
>>>>>>>>>>>> 1 file changed, 5 insertions(+), 2
deletions(-)
>>>>>>>>>>>>
>>>>>>>>>>>> Approvals:
>>>>>>>>>>>> Eli Mesika: Verified
>>>>>>>>>>>> Ravi Nori: Looks good to me, but
someone else must approve
>>>>>>>>>>>> Yair Zaslavsky: Looks good to me,
approved
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Engine-devel mailing list
>>>>>>>>>> Engine-devel(a)ovirt.org
>>>>>>>>>>
http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Engine-devel mailing list
>>>>>> Engine-devel(a)ovirt.org
>>>>>>
http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel(a)ovirt.org
>>>>>
http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel(a)ovirt.org
>>>>
http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>
>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel(a)ovirt.org
>>>
http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
>
http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel