Introduction

The current Cloud Stack management server runs only on Linux servers. The purpose of this feature is to run CloudStack management server on windows as well without using Cygwin. This document will illustrate what changes we may need to do at code level and script level. This will also introduce some installation procedures to have in place before running the management server on windows.

Scope

Should able to start/stop/restart management server as a service on windows. Do remember that we are not trying to  manage development setup as well on windows.

We will target for 2k12r2 windows.

Procedure

We need to convert all shell scripts to Pyhton scripts to make sure those are runnable on windows as well.

Make sure the copied files on windows file system will not change the line ending character other wise it will create a mess after copied to hyper-visor host.

The following modules need to run from windows as well to make sure they run without using cygwin

1. Deploy DB
2. Seed system template onto secondary storage location
3. start/stop/restart management server
4. Samba integration

DeployDB

<TODO>

Seed SystemTemplate

This will execute the following scripts

• scripts/storage/secondary/cloud-install-sys-tmplt
• cripts/storage/secondary/createtmplt.sh
• decrypt.sh

Management Server

When we start the management server currently it is calling the following scripts

• scripts/vm/systemvm/injectkeys.sh
  
  

There are some places in Java code where bash scripts are written inside the jave code.The following list of class files are having such scripts

• com.cloud.utils.net.NetUtils.getDefaultEthDevice()
• com.cloud.server.ConfigurationServerImpl.updateKeyPairs()
  • Need to find alternate tool of "ssh-keygen" for windows 

Samba integration

     <TODO>

Installer

Used WiX tool to write the windows installer which creates a .msi at the end. The tool uses XMLs to generate installer. The following things are happening inside installer.

1. Selection of installation path
2. Creating the folder structure at installation path selected above
3. Copying the required files to the respective plcaes
4. Adding the following entries to Environment variables
   CATALINA_BASE
    CLOUDSTACK_HOME
    CATALINA_OPTS
5. Opened the following ports in Windows firewall (Picked from Ports used by CloudStack)
   8080
   8096 
   8787 
   9090 
   3922 
   8250 
6. Adding entry to services (Though the start service is not working in the backend service is getting started when we start the service in services)

Appendix

Feedback

1. SSH (John Kinsella) :
   Putty doesn’t really want to be used for command-line key generation[1].
   Take a look at libssh[2] - from a glance, that looks like it might be the best approach.
   

   http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/puttygen-batch.html
   http://www.libssh.org/
    

   [Damodar] : Sure we will look into libssh as an alternate for ssh key generation. 

2. .(Alex Hitchins) I certainly wouldn't rely on cygwin in production
        [Damodar] : The idea is to remove dependency on cygwin completely.
   I'd be interested to look into performance comparisons between Java on windows and Linux. Technically, there should be no difference I'd have thought 
        [Damodar] : Will check if time permits.

3. (Alex Huang)
   Management server should never have mounted the NFS secondary storage. We need to fix that. Please have a talk with Kelven about this. I don't see us adding Samba to any machine that runs the management server. If this is just about seeding the system template, it can be done as part of installation rather than management server.
    [Damodar] : As I verified in vmware case we mount SSVM onto local storage. This integration as of now we think is only in case of VMWare.
   If I truly think about Windowsification, I think windows installer, windows service, opening ports in windows firewall. I don't see any of that here. Or else it's useless for windows people.
   [Damodar] : Yes we considered this as a separate note
   For java, most people write a windows service that launches the jvm and keeps track of the jvm.
   There's a number of things that CloudStack management server does today at startup that should not be there and those are what complicates the windowfication. These things should be moved out of the management server and into installation. What should be inside the management server startup procedure should be checks, rather than generations. It should check for ssh key exists and the database version matches etc
        [Damodar] : As of now we identified some of them and covered in the above section (For Ex: Deploy DB, Seeding system Template and installing ssh keys)
    it should not do the following. 
          Upgrade of the database
              [Damodar] : This will be covered as part of deploy db
          ssh key generation
               [Damodar] : Already covered in the details section. For now Assumption is already these keys would have been installed.
          iso generation.
               [Damodar] : You mean systemvm.iso here.. If that is the case then I think this will be part of maven build only.
   

   It's not a serious refactoring. Most of these things are actually isolated in plugins that are separated from the management server already. For example, Rohit was able to use the same plugin that does database upgrade to implement deploydb with relative ease. We just never finished the job to remove it from the management server bootstrap. I don't see the code change as big changes. And these changes benefits CloudStack regardless of it it's windows or not.
        [Damodar] :We will keep in mind of refactoring and we will try to do that where ever is needed.
   I think packaging is where most of the changes are. The good thing is that this packaging is obviously going to be entirely in windows package (won't be rpm for example) so hopefully we keep that in mind and don't disrupt the rpm packaging.
         [Damodar] : Sure we will keep this as well in mind.
   I do see a lot of people who can benefit from this. I think people who are implementing true cloud usages will use our current installation. But I do meet a lot of windows admins who needs help. And they might move over to Linux for actual deployment but even just to get started to try out cloudstack is difficult for them. However, if we're targeting this group, then the current spec is insufficient
         [Damodar] : What areas need to be improved here so that we will incorporate the same into the FS. Still we did not add the Database part(replacing MySql with Microsofr Sql) in this as we are thinking to move that to 2nd phase.