cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donal Lafferty <>
Subject RE: [DISCUSS] RESTful agent for Hyper-V plugin
Date Wed, 13 Mar 2013 09:44:14 GMT
Comments inline:

> -----Original Message-----
> From: Chiradeep Vittal []
> Sent: 13 March 2013 12:09 AM
> To:
> Cc: Alex Huang
> Subject: Re: [DISCUSS] RESTful agent for Hyper-V plugin
> 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
[Donal Lafferty] 
WRT #1:  Operations in the agent-api package are used by cloudstack's orchestration engine
to tell a provisioning plugin what it wants done.  Examples include
for volume creation and to request detailed VM status.
 The REST-ful API would offer functionally equivalent web services.  These web services would
be implemented by the native ServerResource.  The generic ServerComponent would be responsible
for mapping between commands in the agent-api package and this web service.

WRT #2:  C# code on a .NET framework classes is a well-supported implementation option.  The
code's copyright would be held by Apache CloudStack.  The libraries on which it depended would
be proprietary to Microsoft (.NET Runtime, and ASP.NET Web API framework).  AFAIK, the tool
chain would be licensed by Microsoft as part their Visual Studio product.  I would like to
know better how model would fit with our existing tool chain.

WRT #3:  we would need to deploy a ServerResource on each Hyper-V server.  The ServerResource
would run as a Windows Service.  A Windows Service performs the functions of a daemon.  The
ServerResource would be self-hosting to avoid the need for a separate web server such as IIS.
 In Windows, the term 'self-hosting' refers to a web service that does not rely on a distinct
container for its communications stack.  The alternative is for the ServerResource to execute
as a module of a web server such as IIS (Microsoft's httpd).  

> +3 if my understanding is right.
[Donal Lafferty] 
Yes, difficulty increases with the maximum score.  However, the experience from Phase 1 and
the tools available for C#/.NET work should reduce the risk involved.

> If so,
>  - how would the vm orchestrator "find" the REST endpoint?
[Donal Lafferty] 
The web service location would be constructed from the server's URL and a well known path.
 This would allow the existing mechanisms for adding servers to a cluster to be used for Hyper-V.

>  - how would the vm orchestrator authenticate against the REST endpoint?
[Donal Lafferty] 
Initially, Basic Authentication would be used.  CloudStack's GUI may need a slight update
to deal with backslashes that appear in domain-based user accounts.

>  - are there any cluster-level operations that would be implemented?
[Donal Lafferty] 
Initially, cluster semantics would be implemented in CloudStack.  At the hypervisor level,
Hyper-V servers would be unaware of their cluster peers. 

> On 3/12/13 2:51 PM, "Donal Lafferty" <> 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

View raw message