On Mar 26, 2013, at 10:22 AM, Donal Lafferty <donal.laffe...@citrix.com> wrote:
> I think this split is already accounted for in the existing plugin > architecture. The external C# component you mention fits the definition of > the plugin's "ServerResource". The bit in the management server that talks > to it would be a "ServerComponent". See slide #7 of [1]. > > I agree with your proposal to use a RESTful API to link the two halves of the > plugin. See [2] > > The problem is how best to add the C# component. Does it suffice that the > code and build project are donated, and users left to build their own? > I missing some of the context here. I thought that you could talk directly from the MS to the provided WMI API over the network. If not then why not just using the Python WMI module, expose a REST API from there and get done with it ? > DL > > > [1] > http://www.slideshare.net/DonalLafferty/2013-0219cloud-platformpluginsfinaldistro > [2] http://markmail.org/thread/q2qhbtk2ipny3r2t > > > >> -----Original Message----- >> From: Koushik Das [mailto:koushik....@citrix.com] >> Sent: 26 March 2013 2:07 PM >> To: dev@cloudstack.apache.org >> Cc: cloudstack-...@incubator.apache.org >> Subject: RE: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP Clearance >> >> Think of the external C# component as external to CS. It exposes a REST >> endpoint and has independent lifecycle. The server resource running as part >> of Cloudstack MS will connect to this external REST endpoint. >> >>> -----Original Message----- >>> From: Donal Lafferty [mailto:donal.laffe...@citrix.com] >>> Sent: Tuesday, March 26, 2013 6:50 PM >>> To: dev@cloudstack.apache.org >>> Cc: cloudstack-...@incubator.apache.org >>> Subject: RE: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP >>> Clearance >>> >>> The terminology for plugins has unfortunate overloading when it comes >>> to the term 'ServerResource'. As a Java class, it seems to be used to >>> in the implementation both a plugin's ServerComponent and a plugin's >>> ServerResource. E.g. the KVM plugin has a 'dummy' ServerResource in >>> the management server, and a real ServerResource in the remote agent. >>> >>> With that in mind, do you mean for the C# component to be accessible >>> over a RESTful API from plugin classes loaded into the management server? >>> >>> DL >>> >>>> -----Original Message----- >>>> From: Koushik Das [mailto:koushik....@citrix.com] >>>> Sent: 26 March 2013 12:52 PM >>>> To: dev@cloudstack.apache.org >>>> Cc: cloudstack-...@incubator.apache.org >>>> Subject: RE: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP >>>> Clearance >>>> >>>> Better to write the C# component doing Hyper-V specific stuff as a >>>> standalone component and expose a REST API. The ServerResource class >>>> is still in java and makes REST calls to the C# component. >>>> >>>> -Koushik >>>> >>>>> -----Original Message----- >>>>> From: Donal Lafferty [mailto:donal.laffe...@citrix.com] >>>>> Sent: Tuesday, March 26, 2013 3:29 PM >>>>> To: dev@cloudstack.apache.org >>>>> Cc: cloudstack-...@incubator.apache.org >>>>> Subject: RE: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP >>>>> Clearance >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: rohityada...@gmail.com [mailto:rohityada...@gmail.com] On >>>>> Behalf >>>>>> Of Rohit Yadav >>>>>> Sent: 26 March 2013 4:02 AM >>>>>> To: dev@cloudstack.apache.org >>>>>> Cc: cloudstack-...@incubator.apache.org >>>>>> Subject: Re: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP >>>>>> Clearance >>>>>> >>>>>> On Tue, Mar 26, 2013 at 4:31 AM, Donal Lafferty >>>>>> <donal.laffe...@citrix.com> >>>>>> wrote: >>>>>>> It makes a lot of sense to write the ServerResourse for >>>>>>> Hyper-V in C#, >>>>>> because there's a lot of frameworks written in the Microsoft >>>>>> ecosystem with C# in mind. >>>>>>> >>>>>>> If that's the case, then it also makes sense to use the >>>>>>> Microsoft compiler to >>>>>> compile the ServerResource. >>>>>> >>>>>> This won't get much love, instead of a compiler from the North >>>>>> Atlantic giant, >>>>> [Donal Lafferty] >>>>> Northwest Pacific :) >>>>>> if you were to use C# anyway why not consider using mono for >>>>>> your compiler/build infrastructure? While I would avoid mono and >>>>>> it would be difficult for folks to build/develop, if something >>>>>> could be done in C#, could n't it be done in Java, Scala or >>>>>> anything that could run on JVM? If this is possible, it will >>>>>> save us from nonoss, proprietary >>>>> build/runtime dependency. >>>>> [Donal Lafferty] >>>>> It's a question of what environment is optimal for the ServerResource. >>>>> There is a lot more material for writing a server resource in C# >>>>> than there is for writing it in Java. >>>>> >>>>> Moreover, the ServerResource concept of a plugin was introduced to >>>>> allow developers a degree of freedom in choosing the environment >>>>> for code that controls data centre resource. Adopting >>>>> platform-specific tools seems to flow naturally from this >>>>> definition. I guess you could call this the multi-lingual >>>>> plugin: one where the ServerResource and ServerComponent are not >>>>> homogenous. >>>>> >>>>> What are the barriers to including 'multi-lingual plugins' in CloudStack? >>>>> >>>>>> >>>>>> Cheers. >>>>>> >>>>>>> >>>>>>> I'm unclear how this impacts contributing the code to Apache >>>> CloudStack. >>>>>> In particular: >>>>>>> >>>>>>> >>>>>>> 1. Does dependence on the Microsoft compiler mean that the >>>> source >>>>>> end up in the non-OSS build? >>>>>>> >>>>>>> 2. Is the plugin able to participate in the BVT? >>>>>>> >>>>>>>
