Is this an accurate summary? 1. Design a REST-ful API that is functionally equivalent to the operations provided in the agent-api package 2. Implement this in C# / .NET 3. Run one of these API servers on every hypervisor
+3 if my understanding is right. If so, - how would the vm orchestrator "find" the REST endpoint? - how would the vm orchestrator authenticate against the REST endpoint? - are there any cluster-level operations that would be implemented? On 3/12/13 2:51 PM, "Donal Lafferty" <donal.laffe...@citrix.com> wrote: >I wanted to get some feedback on a shift to a remote agent for the next >phase of Hyper-V development. > >Controlling Hyper-V directly from the management server makes image >motion tricky. A plugin could use WS-Management to remotely manage >Windows subsystems such as Hyper-V; however, this does not provide an >obvious means of downloading templates when they are stored in S3 or >Swift. > >For Phase 2, I'd like to revise the Hyper-V plugin to use a native >ServerResource with a RESTful API that is consumed by a generic >ServerComponent. > >The ServerComponents is 'generic', because it makes no assumptions beyond >what is in the ServerResource's RESTful API. Instead of using the >message bus, the ServerComponent would convert existing Agent commands to >GET and POST HTTP methods. With the message bus gone, the remote agent >no longer needs to be started using outside tools (e.g. KVM uses SSH). >Ideally the generic ServerComponent would not have to be customised for >the type of hypervisor it was talking to. > >The ServerResource is 'native', because it would run on the hypervisor >and be implemented in a well-supported language. By well-supported, I >mean the remote agent would be implemented in a language designed to call >the hypervisor's API library directly. The Java agent used in Hyper-V >Phase 1 needed scripts to call theHyper-V API, and these were launched in >a separate process outside the JVM. For Phase 2, using C# and the .NET >framework would avoid spinning up this separate process. Also, the >ServerResource would have access to the Hypervisor's file system and >attached devices, which provides more flexibility for downloading and >writing a disk image to primary storage. Therefore, the native >ServerResource gets to exploit the hypervisor's development ecosystem >directly. > >Any comments on this approach, or the IP and technology limits that using >C# / .NET implies would be most welcome. > > >DL
