You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Toshiaki Hatano <to...@verio.net> on 2013/07/26 00:01:27 UTC

[DISCUSS] Compatibility issue between network plugins and hypervisors

Hi devs,

 

CloudStack supports many hypervisors and many network isolation methods.

Some isolation method doesn't (or cannot) support some hypervisors,

but it looks cloudstack doesn't check compatibility between network
isolation and hypervisors.

 

Why don't we check it during addCluster, first timing
cloudstack-management know isolation and hypervisor, and fail if it's
incompatible?

 

Best Regards,

--  

Toshiaki Hatano

Verio, an NTT Communications company 
E-mail:  toshiaki.hatano@verio.net <ma...@verio.net> 

AIM:      toshiaki.hatano@verio.net <ma...@verio.net> 

 



This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio Inc. makes no warranty that this email is error or virus free.  Thank you.

Re: [DISCUSS] Compatibility issue between network plugins and hypervisors

Posted by Daan Hoogland <da...@gmail.com>.
Toshaki,

As long as the enabling of features is completely in control by
cloudstack developers this model will probably work fine. If generic
code in cloudstack enables a new feature in the upgrade version of an
SDN implementation or storage provider or hypervisor, it may not. I
think we want to write as much of such generic code as possible to be
vendor/version independent as much as we can. This is the conflict I
am seeing with the model. As a guiding principle it is fine for
specific code that can not be abstracted away from the target
implementations.

regards,

On Tue, Jul 30, 2013 at 2:50 AM, Toshiaki Hatano
<to...@verio.net> wrote:
> Daan,
>
> In my opinion, it's responsibility of the developer to provide
> information and to stop Ops from failing over cliff.
> Obviously Dev knows how code works (sometime not :), but Ops doesn't.
> So, if Dev deny to help Ops, how can Ops setup the cloud in proper way?
>
> When someone enhance hypervisor and/or network implementations, they
> should conduct test of their enhancement before submitting patch.
> Then, they may be able to notice that the checks are not up to date.
> Even if they didn't notice that, someone who try to use the feature
> should notice that.
>
> Do you think this model will not work?
>
> Thanks,
> --
> Toshiaki
>
> -----Original Message-----
> From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
> Sent: Saturday, July 27, 2013 05:06
> To: dev
> Subject: Re: [DISCUSS] Compatibility issue between network plugins and
> hypervisors
>
> H,
>
> isn't it the responsibility of the administrator to setup the cloud in a
> proper way? hypervisor and network implementations may enhance their
> capabilities at minor upgrades so it will not be easy to keep checks on
> this up to date in cloudstack. Am I missing the point here?
>
> regards,
> Daan
>
>
> On Sat, Jul 27, 2013 at 1:10 AM, Toshiaki Hatano
> <to...@verio.net>wrote:
>
>> I agree with Murali.
>>
>> I feel NetworkGuru should know their capability and should called when
>
>> we add cluster.
>> NetworkGurus already provide canHandle(NetworkOffering, NetworkType,
>> PhysicalNetwork) method to check their capability.
>> So, how about overloading this method to get HypervisorType in
> arguments?
>>
>> Thanks,
>> --
>> Toshiaki
>>
>> -----Original Message-----
>> From: Murali Reddy [mailto:Murali.Reddy@citrix.com]
>> Sent: Thursday, July 25, 2013 22:33
>> To: dev@cloudstack.apache.org
>> Subject: Re: [DISCUSS] Compatibility issue between network plugins and
>
>> hypervisors
>>
>> Also, should not we treat 'isolation' as Network Element capability
>> rather than Hypervisor. Tunnelling capability could be a Hypervisor
>> capability, but isolation (STT/GRE) is Network Element capability?
>> So,zone isolation
>> -> isolation provider -> supported hypervisors should be checked
>> -> against
>> add cluster IMO.
>>
>> On 26/07/13 9:24 AM, "Chiradeep Vittal" <Ch...@citrix.com>
>> wrote:
>>
>> >+1 (with a caveat), good idea since isolation method is supported on
>> >+a
>> >per-zone basis.
>> >The caveat is that sometimes it makes sense to support multiple
>> >isolation methods in a zone.
>> >For example, VPC(advanced) + basic in the same zone.
>> >Why would one do this? Simply because someone might start with one
>> >isolation method (basic) and then offer advanced (using overlays like
>
>> >VxLAN f.e). Since templates/snapshots/volumes tend to be
>> >zone-specific, this makes the transition easier.
>> >This is not unlike AWS "EC2-classic" and "VPC" in the same zone.
>> >
>> >
>> >On 7/26/13 3:34 AM, "Alex Huang" <Al...@citrix.com> wrote:
>> >
>> >>+1
>> >>
>> >>I think we should take advantage of hypervisor capabilities to look
>> >>for that compatibility.
>> >>
>> >>--Alex
>> >>
>> >>> -----Original Message-----
>> >>> From: Toshiaki Hatano [mailto:toshiaki.hatano@verio.net]
>> >>> Sent: Thursday, July 25, 2013 3:01 PM
>> >>> To: dev@cloudstack.apache.org
>> >>> Subject: [DISCUSS] Compatibility issue between network plugins and
>
>> >>> hypervisors
>> >>>
>> >>> Hi devs,
>> >>>
>> >>>
>> >>>
>> >>> CloudStack supports many hypervisors and many network isolation
>> >>>methods.
>> >>>
>> >>> Some isolation method doesn't (or cannot) support some
>> >>> hypervisors,
>> >>>
>> >>> but it looks cloudstack doesn't check compatibility between
>> >>>network isolation  and hypervisors.
>> >>>
>> >>>
>> >>>
>> >>> Why don't we check it during addCluster, first timing cloudstack-
>> >>>management know isolation and hypervisor, and fail if it's
>> >>>incompatible?
>> >>>
>> >>>
>> >>>
>> >>> Best Regards,
>> >>>
>> >>> --
>> >>>
>> >>> Toshiaki Hatano
>> >>>
>> >>> Verio, an NTT Communications company
>> >>> E-mail:  toshiaki.hatano@verio.net
>> >>> <ma...@verio.net>
>> >>>
>> >>> AIM:      toshiaki.hatano@verio.net
> <ma...@verio.net>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> This email message is intended for the use of the person to whom
>> >>>it has  been sent, and may contain information that is confidential
>
>> >>>or legally  protected. If you are not the intended recipient or
>> >>>have received this  message in error, you are not authorized to
>> >>>copy, distribute, or otherwise  use this message or its
>> >>>attachments. Please notify the sender immediately by  return e-mail
>
>> >>>and permanently delete this message and any attachments.
>> >>> Verio Inc. makes no warranty that this email is error or virus
> free.
>> >>>Thank you.
>> >
>> >
>>
>>
>>
>>
>> This email message is intended for the use of the person to whom it
>> has been sent, and may contain information that is confidential or
>> legally protected. If you are not the intended recipient or have
>> received this message in error, you are not authorized to copy,
>> distribute, or otherwise use this message or its attachments. Please
>> notify the sender immediately by return e-mail and permanently delete
> this message and any attachments.
>> Verio Inc. makes no warranty that this email is error or virus free.
>> Thank you.
>>
>
>
> This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio Inc. makes no warranty that this email is error or virus free.  Thank you.

RE: [DISCUSS] Compatibility issue between network plugins and hypervisors

Posted by Toshiaki Hatano <to...@verio.net>.
Daan,

In my opinion, it's responsibility of the developer to provide
information and to stop Ops from failing over cliff.
Obviously Dev knows how code works (sometime not :), but Ops doesn't.
So, if Dev deny to help Ops, how can Ops setup the cloud in proper way?

When someone enhance hypervisor and/or network implementations, they
should conduct test of their enhancement before submitting patch.
Then, they may be able to notice that the checks are not up to date.
Even if they didn't notice that, someone who try to use the feature
should notice that.

Do you think this model will not work?

Thanks,
--
Toshiaki

-----Original Message-----
From: Daan Hoogland [mailto:daan.hoogland@gmail.com] 
Sent: Saturday, July 27, 2013 05:06
To: dev
Subject: Re: [DISCUSS] Compatibility issue between network plugins and
hypervisors

H,

isn't it the responsibility of the administrator to setup the cloud in a
proper way? hypervisor and network implementations may enhance their
capabilities at minor upgrades so it will not be easy to keep checks on
this up to date in cloudstack. Am I missing the point here?

regards,
Daan


On Sat, Jul 27, 2013 at 1:10 AM, Toshiaki Hatano
<to...@verio.net>wrote:

> I agree with Murali.
>
> I feel NetworkGuru should know their capability and should called when

> we add cluster.
> NetworkGurus already provide canHandle(NetworkOffering, NetworkType,
> PhysicalNetwork) method to check their capability.
> So, how about overloading this method to get HypervisorType in
arguments?
>
> Thanks,
> --
> Toshiaki
>
> -----Original Message-----
> From: Murali Reddy [mailto:Murali.Reddy@citrix.com]
> Sent: Thursday, July 25, 2013 22:33
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Compatibility issue between network plugins and

> hypervisors
>
> Also, should not we treat 'isolation' as Network Element capability 
> rather than Hypervisor. Tunnelling capability could be a Hypervisor 
> capability, but isolation (STT/GRE) is Network Element capability? 
> So,zone isolation
> -> isolation provider -> supported hypervisors should be checked 
> -> against
> add cluster IMO.
>
> On 26/07/13 9:24 AM, "Chiradeep Vittal" <Ch...@citrix.com>
> wrote:
>
> >+1 (with a caveat), good idea since isolation method is supported on 
> >+a
> >per-zone basis.
> >The caveat is that sometimes it makes sense to support multiple 
> >isolation methods in a zone.
> >For example, VPC(advanced) + basic in the same zone.
> >Why would one do this? Simply because someone might start with one 
> >isolation method (basic) and then offer advanced (using overlays like

> >VxLAN f.e). Since templates/snapshots/volumes tend to be 
> >zone-specific, this makes the transition easier.
> >This is not unlike AWS "EC2-classic" and "VPC" in the same zone.
> >
> >
> >On 7/26/13 3:34 AM, "Alex Huang" <Al...@citrix.com> wrote:
> >
> >>+1
> >>
> >>I think we should take advantage of hypervisor capabilities to look 
> >>for that compatibility.
> >>
> >>--Alex
> >>
> >>> -----Original Message-----
> >>> From: Toshiaki Hatano [mailto:toshiaki.hatano@verio.net]
> >>> Sent: Thursday, July 25, 2013 3:01 PM
> >>> To: dev@cloudstack.apache.org
> >>> Subject: [DISCUSS] Compatibility issue between network plugins and

> >>> hypervisors
> >>>
> >>> Hi devs,
> >>>
> >>>
> >>>
> >>> CloudStack supports many hypervisors and many network isolation 
> >>>methods.
> >>>
> >>> Some isolation method doesn't (or cannot) support some 
> >>> hypervisors,
> >>>
> >>> but it looks cloudstack doesn't check compatibility between 
> >>>network isolation  and hypervisors.
> >>>
> >>>
> >>>
> >>> Why don't we check it during addCluster, first timing cloudstack- 
> >>>management know isolation and hypervisor, and fail if it's 
> >>>incompatible?
> >>>
> >>>
> >>>
> >>> Best Regards,
> >>>
> >>> --
> >>>
> >>> Toshiaki Hatano
> >>>
> >>> Verio, an NTT Communications company
> >>> E-mail:  toshiaki.hatano@verio.net 
> >>> <ma...@verio.net>
> >>>
> >>> AIM:      toshiaki.hatano@verio.net
<ma...@verio.net>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> This email message is intended for the use of the person to whom 
> >>>it has  been sent, and may contain information that is confidential

> >>>or legally  protected. If you are not the intended recipient or 
> >>>have received this  message in error, you are not authorized to 
> >>>copy, distribute, or otherwise  use this message or its 
> >>>attachments. Please notify the sender immediately by  return e-mail

> >>>and permanently delete this message and any attachments.
> >>> Verio Inc. makes no warranty that this email is error or virus
free.
> >>>Thank you.
> >
> >
>
>
>
>
> This email message is intended for the use of the person to whom it 
> has been sent, and may contain information that is confidential or 
> legally protected. If you are not the intended recipient or have 
> received this message in error, you are not authorized to copy, 
> distribute, or otherwise use this message or its attachments. Please 
> notify the sender immediately by return e-mail and permanently delete
this message and any attachments.
> Verio Inc. makes no warranty that this email is error or virus free.  
> Thank you.
>


This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio Inc. makes no warranty that this email is error or virus free.  Thank you.

Re: [DISCUSS] Compatibility issue between network plugins and hypervisors

Posted by Daan Hoogland <da...@gmail.com>.
H,

isn't it the responsibility of the administrator to setup the cloud in a
proper way? hypervisor and network implementations may enhance their
capabilities at minor upgrades so it will not be easy to keep checks on
this up to date in cloudstack. Am I missing the point here?

regards,
Daan


On Sat, Jul 27, 2013 at 1:10 AM, Toshiaki Hatano
<to...@verio.net>wrote:

> I agree with Murali.
>
> I feel NetworkGuru should know their capability and should called when we
> add cluster.
> NetworkGurus already provide canHandle(NetworkOffering, NetworkType,
> PhysicalNetwork) method to check their capability.
> So, how about overloading this method to get HypervisorType in arguments?
>
> Thanks,
> --
> Toshiaki
>
> -----Original Message-----
> From: Murali Reddy [mailto:Murali.Reddy@citrix.com]
> Sent: Thursday, July 25, 2013 22:33
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Compatibility issue between network plugins and
> hypervisors
>
> Also, should not we treat 'isolation' as Network Element capability rather
> than Hypervisor. Tunnelling capability could be a Hypervisor capability,
> but isolation (STT/GRE) is Network Element capability? So,zone isolation
> -> isolation provider -> supported hypervisors should be checked against
> add cluster IMO.
>
> On 26/07/13 9:24 AM, "Chiradeep Vittal" <Ch...@citrix.com>
> wrote:
>
> >+1 (with a caveat), good idea since isolation method is supported on a
> >per-zone basis.
> >The caveat is that sometimes it makes sense to support multiple
> >isolation methods in a zone.
> >For example, VPC(advanced) + basic in the same zone.
> >Why would one do this? Simply because someone might start with one
> >isolation method (basic) and then offer advanced (using overlays like
> >VxLAN f.e). Since templates/snapshots/volumes tend to be zone-specific,
> >this makes the transition easier.
> >This is not unlike AWS "EC2-classic" and "VPC" in the same zone.
> >
> >
> >On 7/26/13 3:34 AM, "Alex Huang" <Al...@citrix.com> wrote:
> >
> >>+1
> >>
> >>I think we should take advantage of hypervisor capabilities to look
> >>for that compatibility.
> >>
> >>--Alex
> >>
> >>> -----Original Message-----
> >>> From: Toshiaki Hatano [mailto:toshiaki.hatano@verio.net]
> >>> Sent: Thursday, July 25, 2013 3:01 PM
> >>> To: dev@cloudstack.apache.org
> >>> Subject: [DISCUSS] Compatibility issue between network plugins and
> >>> hypervisors
> >>>
> >>> Hi devs,
> >>>
> >>>
> >>>
> >>> CloudStack supports many hypervisors and many network isolation
> >>>methods.
> >>>
> >>> Some isolation method doesn't (or cannot) support some hypervisors,
> >>>
> >>> but it looks cloudstack doesn't check compatibility between network
> >>>isolation  and hypervisors.
> >>>
> >>>
> >>>
> >>> Why don't we check it during addCluster, first timing cloudstack-
> >>>management know isolation and hypervisor, and fail if it's
> >>>incompatible?
> >>>
> >>>
> >>>
> >>> Best Regards,
> >>>
> >>> --
> >>>
> >>> Toshiaki Hatano
> >>>
> >>> Verio, an NTT Communications company
> >>> E-mail:  toshiaki.hatano@verio.net
> >>> <ma...@verio.net>
> >>>
> >>> AIM:      toshiaki.hatano@verio.net <ma...@verio.net>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> This email message is intended for the use of the person to whom it
> >>>has  been sent, and may contain information that is confidential or
> >>>legally  protected. If you are not the intended recipient or have
> >>>received this  message in error, you are not authorized to copy,
> >>>distribute, or otherwise  use this message or its attachments. Please
> >>>notify the sender immediately by  return e-mail and permanently
> >>>delete this message and any attachments.
> >>> Verio Inc. makes no warranty that this email is error or virus free.
> >>>Thank you.
> >
> >
>
>
>
>
> This email message is intended for the use of the person to whom it has
> been sent, and may contain information that is confidential or legally
> protected. If you are not the intended recipient or have received this
> message in error, you are not authorized to copy, distribute, or otherwise
> use this message or its attachments. Please notify the sender immediately
> by return e-mail and permanently delete this message and any attachments.
> Verio Inc. makes no warranty that this email is error or virus free.  Thank
> you.
>

RE: [DISCUSS] Compatibility issue between network plugins and hypervisors

Posted by Toshiaki Hatano <to...@verio.net>.
I agree with Murali.

I feel NetworkGuru should know their capability and should called when we add cluster.
NetworkGurus already provide canHandle(NetworkOffering, NetworkType, PhysicalNetwork) method to check their capability.
So, how about overloading this method to get HypervisorType in arguments?

Thanks,
--
Toshiaki

-----Original Message-----
From: Murali Reddy [mailto:Murali.Reddy@citrix.com] 
Sent: Thursday, July 25, 2013 22:33
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Compatibility issue between network plugins and hypervisors

Also, should not we treat 'isolation' as Network Element capability rather than Hypervisor. Tunnelling capability could be a Hypervisor capability, but isolation (STT/GRE) is Network Element capability? So,zone isolation
-> isolation provider -> supported hypervisors should be checked against
add cluster IMO.

On 26/07/13 9:24 AM, "Chiradeep Vittal" <Ch...@citrix.com>
wrote:

>+1 (with a caveat), good idea since isolation method is supported on a
>per-zone basis.
>The caveat is that sometimes it makes sense to support multiple 
>isolation methods in a zone.
>For example, VPC(advanced) + basic in the same zone.
>Why would one do this? Simply because someone might start with one 
>isolation method (basic) and then offer advanced (using overlays like 
>VxLAN f.e). Since templates/snapshots/volumes tend to be zone-specific, 
>this makes the transition easier.
>This is not unlike AWS "EC2-classic" and "VPC" in the same zone.
>
>
>On 7/26/13 3:34 AM, "Alex Huang" <Al...@citrix.com> wrote:
>
>>+1
>>
>>I think we should take advantage of hypervisor capabilities to look 
>>for that compatibility.
>>
>>--Alex
>>
>>> -----Original Message-----
>>> From: Toshiaki Hatano [mailto:toshiaki.hatano@verio.net]
>>> Sent: Thursday, July 25, 2013 3:01 PM
>>> To: dev@cloudstack.apache.org
>>> Subject: [DISCUSS] Compatibility issue between network plugins and 
>>> hypervisors
>>> 
>>> Hi devs,
>>> 
>>> 
>>> 
>>> CloudStack supports many hypervisors and many network isolation 
>>>methods.
>>> 
>>> Some isolation method doesn't (or cannot) support some hypervisors,
>>> 
>>> but it looks cloudstack doesn't check compatibility between network 
>>>isolation  and hypervisors.
>>> 
>>> 
>>> 
>>> Why don't we check it during addCluster, first timing cloudstack-  
>>>management know isolation and hypervisor, and fail if it's 
>>>incompatible?
>>> 
>>> 
>>> 
>>> Best Regards,
>>> 
>>> --
>>> 
>>> Toshiaki Hatano
>>> 
>>> Verio, an NTT Communications company
>>> E-mail:  toshiaki.hatano@verio.net 
>>> <ma...@verio.net>
>>> 
>>> AIM:      toshiaki.hatano@verio.net <ma...@verio.net>
>>> 
>>> 
>>> 
>>> 
>>> 
>>> This email message is intended for the use of the person to whom it 
>>>has  been sent, and may contain information that is confidential or 
>>>legally  protected. If you are not the intended recipient or have 
>>>received this  message in error, you are not authorized to copy, 
>>>distribute, or otherwise  use this message or its attachments. Please 
>>>notify the sender immediately by  return e-mail and permanently 
>>>delete this message and any attachments.
>>> Verio Inc. makes no warranty that this email is error or virus free.
>>>Thank you.
>
>




This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio Inc. makes no warranty that this email is error or virus free.  Thank you.

Re: [DISCUSS] Compatibility issue between network plugins and hypervisors

Posted by Murali Reddy <Mu...@citrix.com>.
Also, should not we treat 'isolation' as Network Element capability rather
than Hypervisor. Tunnelling capability could be a Hypervisor capability,
but isolation (STT/GRE) is Network Element capability? So,zone isolation
-> isolation provider -> supported hypervisors should be checked against
add cluster IMO.

On 26/07/13 9:24 AM, "Chiradeep Vittal" <Ch...@citrix.com>
wrote:

>+1 (with a caveat), good idea since isolation method is supported on a
>per-zone basis.
>The caveat is that sometimes it makes sense to support multiple isolation
>methods in a zone.
>For example, VPC(advanced) + basic in the same zone.
>Why would one do this? Simply because someone might start with one
>isolation method (basic) and then offer advanced (using overlays like
>VxLAN f.e). Since templates/snapshots/volumes tend to be zone-specific,
>this makes the transition easier.
>This is not unlike AWS "EC2-classic" and "VPC" in the same zone.
>
>
>On 7/26/13 3:34 AM, "Alex Huang" <Al...@citrix.com> wrote:
>
>>+1
>>
>>I think we should take advantage of hypervisor capabilities to look for
>>that compatibility.
>>
>>--Alex
>>
>>> -----Original Message-----
>>> From: Toshiaki Hatano [mailto:toshiaki.hatano@verio.net]
>>> Sent: Thursday, July 25, 2013 3:01 PM
>>> To: dev@cloudstack.apache.org
>>> Subject: [DISCUSS] Compatibility issue between network plugins and
>>> hypervisors
>>> 
>>> Hi devs,
>>> 
>>> 
>>> 
>>> CloudStack supports many hypervisors and many network isolation
>>>methods.
>>> 
>>> Some isolation method doesn't (or cannot) support some hypervisors,
>>> 
>>> but it looks cloudstack doesn't check compatibility between network
>>>isolation
>>> and hypervisors.
>>> 
>>> 
>>> 
>>> Why don't we check it during addCluster, first timing cloudstack-
>>> management know isolation and hypervisor, and fail if it's
>>>incompatible?
>>> 
>>> 
>>> 
>>> Best Regards,
>>> 
>>> --
>>> 
>>> Toshiaki Hatano
>>> 
>>> Verio, an NTT Communications company
>>> E-mail:  toshiaki.hatano@verio.net <ma...@verio.net>
>>> 
>>> AIM:      toshiaki.hatano@verio.net <ma...@verio.net>
>>> 
>>> 
>>> 
>>> 
>>> 
>>> This email message is intended for the use of the person to whom it has
>>> been sent, and may contain information that is confidential or legally
>>> protected. If you are not the intended recipient or have received this
>>> message in error, you are not authorized to copy, distribute, or
>>>otherwise
>>> use this message or its attachments. Please notify the sender
>>>immediately by
>>> return e-mail and permanently delete this message and any attachments.
>>> Verio Inc. makes no warranty that this email is error or virus free.
>>>Thank you.
>
>



Re: [DISCUSS] Compatibility issue between network plugins and hypervisors

Posted by Chiradeep Vittal <Ch...@citrix.com>.
+1 (with a caveat), good idea since isolation method is supported on a
per-zone basis.
The caveat is that sometimes it makes sense to support multiple isolation
methods in a zone.
For example, VPC(advanced) + basic in the same zone.
Why would one do this? Simply because someone might start with one
isolation method (basic) and then offer advanced (using overlays like
VxLAN f.e). Since templates/snapshots/volumes tend to be zone-specific,
this makes the transition easier.
This is not unlike AWS "EC2-classic" and "VPC" in the same zone.


On 7/26/13 3:34 AM, "Alex Huang" <Al...@citrix.com> wrote:

>+1
>
>I think we should take advantage of hypervisor capabilities to look for
>that compatibility.
>
>--Alex
>
>> -----Original Message-----
>> From: Toshiaki Hatano [mailto:toshiaki.hatano@verio.net]
>> Sent: Thursday, July 25, 2013 3:01 PM
>> To: dev@cloudstack.apache.org
>> Subject: [DISCUSS] Compatibility issue between network plugins and
>> hypervisors
>> 
>> Hi devs,
>> 
>> 
>> 
>> CloudStack supports many hypervisors and many network isolation methods.
>> 
>> Some isolation method doesn't (or cannot) support some hypervisors,
>> 
>> but it looks cloudstack doesn't check compatibility between network
>>isolation
>> and hypervisors.
>> 
>> 
>> 
>> Why don't we check it during addCluster, first timing cloudstack-
>> management know isolation and hypervisor, and fail if it's incompatible?
>> 
>> 
>> 
>> Best Regards,
>> 
>> --
>> 
>> Toshiaki Hatano
>> 
>> Verio, an NTT Communications company
>> E-mail:  toshiaki.hatano@verio.net <ma...@verio.net>
>> 
>> AIM:      toshiaki.hatano@verio.net <ma...@verio.net>
>> 
>> 
>> 
>> 
>> 
>> This email message is intended for the use of the person to whom it has
>> been sent, and may contain information that is confidential or legally
>> protected. If you are not the intended recipient or have received this
>> message in error, you are not authorized to copy, distribute, or
>>otherwise
>> use this message or its attachments. Please notify the sender
>>immediately by
>> return e-mail and permanently delete this message and any attachments.
>> Verio Inc. makes no warranty that this email is error or virus free.
>>Thank you.


RE: [DISCUSS] Compatibility issue between network plugins and hypervisors

Posted by Alex Huang <Al...@citrix.com>.
+1

I think we should take advantage of hypervisor capabilities to look for that compatibility.

--Alex

> -----Original Message-----
> From: Toshiaki Hatano [mailto:toshiaki.hatano@verio.net]
> Sent: Thursday, July 25, 2013 3:01 PM
> To: dev@cloudstack.apache.org
> Subject: [DISCUSS] Compatibility issue between network plugins and
> hypervisors
> 
> Hi devs,
> 
> 
> 
> CloudStack supports many hypervisors and many network isolation methods.
> 
> Some isolation method doesn't (or cannot) support some hypervisors,
> 
> but it looks cloudstack doesn't check compatibility between network isolation
> and hypervisors.
> 
> 
> 
> Why don't we check it during addCluster, first timing cloudstack-
> management know isolation and hypervisor, and fail if it's incompatible?
> 
> 
> 
> Best Regards,
> 
> --
> 
> Toshiaki Hatano
> 
> Verio, an NTT Communications company
> E-mail:  toshiaki.hatano@verio.net <ma...@verio.net>
> 
> AIM:      toshiaki.hatano@verio.net <ma...@verio.net>
> 
> 
> 
> 
> 
> This email message is intended for the use of the person to whom it has
> been sent, and may contain information that is confidential or legally
> protected. If you are not the intended recipient or have received this
> message in error, you are not authorized to copy, distribute, or otherwise
> use this message or its attachments. Please notify the sender immediately by
> return e-mail and permanently delete this message and any attachments.
> Verio Inc. makes no warranty that this email is error or virus free.  Thank you.