Thanks for the feedback. Sorry for the delayed reply; I was trying your suggestions to see how it works.
Summarized the approach in below mentioned steps: 1. The host update feature will be in a separate plugin and contained in an independent jar file. 2. This will use PluggableService to add the APIs into CloudStack. 3. A manager to schedule a thread to check the updates and update the database with new updates. 4. An agent to call ServerResource which will fetch the list of all the patches applied to a host. This agent will use the objects "HostUpdatesCommand" and "HostUpdatesAnswer" to get the information from ServerResource. These objects will be placed in "api" project under "com.cloud.agent.api" package. I have updated functional spec with this information. FS: https://cwiki.apache.org/confluence/display/CLOUDSTACK/XenServer+updates+notification Does this approach sound right? Please let me know your suggestions. Wido/David/Chip/Alex: Please do share your thoughts on this approach. Regards, Sanjay -----Original Message----- From: Alex Huang [mailto:alex.hu...@citrix.com] Sent: Tuesday, October 02, 2012 3:46 AM To: cloudstack-dev@incubator.apache.org Subject: RE: FS for host updates notifications > Another alternative for achieving this (without adding the > per-hypervisor logic to CloudStack itself) might be to build a > framework for plugging in best- of-breed update tools for the various > hypervisors (and bare metal servers). > Example: provide the KVM update feature via a combination of puppet > manifests and mcollective instructions, where CloudStack isn't > responsible for the actual update tracking or installation of updates, > merely calling an appropriate external tool to query status and force > policy updates. A simple command line specification for inputs and > outputs could allow for various environments to have scripts that > drive the process that's most appropriate for their specific conditions. > > Thoughts? +1 I don't see CloudStack as completely just orchestration. It should be the entire stack of tools to make cloud work including management. However, I don't see any reason to normalize this functionality into one call and provide different adapters for that call. The key is to decouple orchestration from these services. Therefore, I think it makes more sense for this host update feature to be self-contained within a plugin. With a plugin, you can add APIs to cloudstack's APIs via the PluggableService interface to enact the way to update a specific type of hypervisor. For example, I can see the following for XenServer. Cloud-plugin-xenserver.jar contains the following interfaces implemented - PluggableService: to introduce APIs to self-manage. For example, for the administrator to invoke to see if there are updates to XenServer or to set a periodic update check policy. - HypervisorGuru: to implement the provisioning needed for hypervisors when a VM is started - ServerResource: to implement the actual interface to different versions of xenserver - Discoverer: to implement different ways to add different versions of XenServer into CloudStack. You can even write cloud-plugin-xenserver-56, cloud-plugin-xenserver-60, etc to have different plugin jars to work with different versions of the XenServer. By doing this, then KVM or VmWare plugins can introduce its own functionalities and features. --Alex
