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.hat...@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.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.
