[DISCUSS] RESTful agent for Hyper-V plugin

[Donal Lafferty <do...@citrix.com>]

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

RE: [DISCUSS] RESTful agent for Hyper-V plugin

[Donal Lafferty <do...@citrix.com>]

Comments below.

> -----Original Message-----
> From: Murali Reddy [mailto:Murali.Reddy@citrix.com]
> Sent: 13 March 2013 1:01 PM
> To: cloudstack-dev@incubator.apache.org
> Cc: Alex Huang
> Subject: Re: [DISCUSS] RESTful agent for Hyper-V plugin
> 
> On 13/03/13 3:14 PM, "Donal Lafferty" <do...@citrix.com> wrote:
> >
> >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.
> 
> Donal, from the integration with Hyper-V perspective this is good way to go.
> AFAIK there are not good Linux/Java C# compilers so how do you plan to take
> care of building C# agent code?
[Donal Lafferty] 
Yes, that is the question I am asking, because I am not clear on how the community deals with ServerResources.  

ServerResources present a problems for testing, building and deploying.
 
What are the testing requirements for a device-specific ServerResource?  For example, the KVM ServerResource needs access to a KVM system where libvirt calls make sense.  Do we have a KVM system in place, or is testing delegated to a community member?

For building, what has been the approach for non-Java tool chains?  How does CloudStack deal with build tools that are not available on all platforms?  In these cases, should the ServerResource be an optional build that is integrated with the CloudStack Maven build, or should the ServerResource build be kicked off through an entirely separate mechanism?  

For deploying, do we need to extend the set of repos with binaries for another platform?  E.g. should a binary of the ServerResource be available on something like NuGet, or are community members responsible for building their own version from source?

I would like to know the precedents for dealing with these issues.

DL

 

Re: [DISCUSS] RESTful agent for Hyper-V plugin

[Murali Reddy <Mu...@citrix.com>]

On 13/03/13 3:14 PM, "Donal Lafferty" <do...@citrix.com> wrote:
>
>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.

Donal, from the integration with Hyper-V perspective this is good way to
go. AFAIK there are not good Linux/Java C# compilers so how do you plan to
take care of building C# agent code?

RE: [DISCUSS] RESTful agent for Hyper-V plugin

[Donal Lafferty <do...@citrix.com>]

Comments inline:

> -----Original Message-----
> From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> Sent: 13 March 2013 12:09 AM
> To: cloudstack-dev@incubator.apache.org
> 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 com.cloud.agent.api.storage.CreateCommand for volume creation and com.cloud.agent.api.GetVmStatsCommand 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" <do...@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

Re: [DISCUSS] RESTful agent for Hyper-V plugin

[Chiradeep Vittal <Ch...@citrix.com>]

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" <do...@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