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.hoogl...@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.hat...@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.re...@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.vit...@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.hu...@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.hat...@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.hat...@verio.net > >>> <mailto:toshiaki.hat...@verio.net> > >>> > >>> AIM: toshiaki.hat...@verio.net <mailto:toshiaki.hat...@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.
