cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Toshiaki Hatano" <toshiaki.hat...@verio.net>
Subject RE: [DISCUSS] Compatibility issue between network plugins and hypervisors
Date Tue, 30 Jul 2013 00:50:35 GMT
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