I made the changes to make sure that:
1. ISO will be deleted from the UI, but it is not deleted from the secondary storage as long as it is attached to a VM.
2. The storage cleanup thread will check whether the iso is attached to any vm, if not, it removes the ISO from the secondary storage.
3. Detach operation is now working which was failing before for the vms having attached iso(deleted).
Updated the patch for template sync during MS restart.
Manually tested the following:
setup: upload ISO1 and ISO 2
Attach ISO1 to VM1 and VM2
Attach ISO2 to VM3
set storage.cleanup.interval to 300
test cases:
1. delete ISO1 from UI, gets deleted
2. In VM Details of VM1 and VM2, can see detach ISO option
3. ISO1 exists in secondary storage
4. detach ISO1 from VM1, successful
5. ISO1 still exists in secondary storage.
6. Restart MS, template sync will not delete ISO1.
7. Detach ISO1 from VM2, successfull detached.
8. Wait for storage cleanup thread to execute, ISO1 gets deleted from Secondary storage.
9. Detach ISO2 from VM3
10.ISO2 exists in secondary storage, Delete ISO2 form UI, get deleted from secondary storage.
following changes
- introduced notion of event bus with publish, subscribe, unsubscribe
semantics
- a plug-in can implement the EventBus abstraction to provide event
bug to CloudStack
- A rabbitMQ based plug-in that can interact with AMQP servers to
provide message broker based event-bug
- stream lines, action events, usage events, alerts publishing in to
convineance classed which are also used to publish corresponding
event on to event bus
- introduced notion of state change event. On a state change, in the
state machine corrsponding to the resource, a state change event is
published on the event bug
- associated a state machined with Snapshot and Network objects
- Virtual Machine, Volume, Snaphost, Network object state changes wil
result in a state change event
- Fixed new join dao impls as spring components
- Fixed component context xml to load api rate limit checker
- Fixed root pom.xml for duplicate plugin
- Fixed list data centers method
- Fixed following conflicts:
api/src/org/apache/cloudstack/api/command/admin/network/CreateNetworkOfferingCmd.java
api/src/org/apache/cloudstack/api/command/user/offering/ListServiceOfferingsCmd.java
api/src/org/apache/cloudstack/api/command/user/template/DeleteTemplateCmd.java
api/src/org/apache/cloudstack/api/command/user/template/ExtractTemplateCmd.java
plugins/api/discovery/src/org/apache/cloudstack/discovery/ApiDiscoveryServiceImpl.java
server/src/com/cloud/api/ApiDBUtils.java
server/src/com/cloud/api/ApiServer.java
server/src/com/cloud/api/query/QueryManagerImpl.java
server/src/com/cloud/configuration/DefaultComponentLibrary.java
server/src/com/cloud/server/ManagementServerImpl.java
server/src/com/cloud/storage/swift/SwiftManagerImpl.java
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
Corresponding getter/setter is renamed too.
Reason is GenericDao does not update the field unless the method name matches the field name; the setter of this VO was one such case.
Detail: This merges the resizevolume feature branch, which provides the
ability to migrate a disk between disk offerings, thereby changing its
size, or specifying a new size if current disk offering is custom.
BUG-ID: CLOUDSTACK-644
Signed-off-by: Marcus Sorensen <marcus@betterservers.com> 1358358209 -0700
to the api project, ensure that all methods use interfaces from the api project.
By moving it to the api project, it lessens the dependency of plugins on the server components.
Signed-off-by: Chiradeep Vittal <chiradeep@apache.org>
NetworkManager's exclusive focus is now
- handling plugins during orchestration, and
- to deal with ip address allocation.
Those classes that used to refer to NetworkManager to get access to the datamodel now refer to NetworkModel
Signed-off-by: Chiradeep Vittal <chiradeep@apache.org>
Issue seen during system vm template upgrade and restoreVM command
scenarios for vmware. In these cases CS tries to recreate root disk with
same name as the existing one, in case of vmware this results in creation
of vmdk file with same name for both existing and new root volume.
This results in undesired behavior when storage cleanup thread tries to
cleanup old volume. Made the vmdk file name unique by adding the volume
id to it. This will ensure that during volume recreation in the scenarios
mentioned vmdk will get created with a new name and there will be
no undesired side effects of running the storage cleanup thread.
Murali Reddy
Edison Su
Sanjay Tripathi
Deepti Dohare
Edison Su
Chip Childers
Mice Xia
Marcus Sorensen
Kelven Yang
Rohit Yadav
Min Chen
Prachi Damle
Alex Huang
Chiradeep Vittal
Koushik Das