cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@gmail.com>
Subject Re: [DISCUSS] Compatibility issue between network plugins and hypervisors
Date Tue, 30 Jul 2013 08:05:46 GMT
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
<toshiaki.hatano@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
> <toshiaki.hatano@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" <Chiradeep.Vittal@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" <Alex.Huang@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
>> >>> <mailto:toshiaki.hatano@verio.net>
>> >>>
>> >>> AIM:      toshiaki.hatano@verio.net
> <mailto:toshiaki.hatano@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.

Mime
View raw message