1. copy template1 from z1 to z2
2. remove template1 from z2
3. copy tempalte1 from z1 to z2 again,
4. template1 for z2 doesn't show up in MyTemplate
fixed
1. copy template1 from z1 to z2
2. remove template1 from z2
3. copy tempalte1 from z1 to z2 again,
4. template1 for z2 doesn't show up in MyTemplate
fixed
in template sync,
1. skip all templates with url null
2. if the template is private, and there is no record for this template in this secondary storage host, skip it
status 10511: resolved fixed
Conflicts:
server/src/com/cloud/storage/download/DownloadMonitorImpl.java
in template sync,
1. skip all templates with url null
2. if the template is private, and there is no record for this template in this secondary storage host, skip it
status 10511: resolved fixed
merge createtemplateresponse and createteisoresponse
on UI template
only show template corresponding hypervisor exists
Conflicts:
api/src/com/cloud/api/ResponseGenerator.java
server/src/com/cloud/storage/StorageManager.java
status 10305: resolved fixed
While creating a system vm offering specify the type. If no type specified the default to domainrouter.
While requesting a set of system offering specify the paramter systemvmtype.
status 10305: resolved fixed
While creating a system vm offering specify the type. If no type specified the default to domainrouter.
While requesting a set of system offering specify the paramter systemvmtype.
1. check if there are snapshotsin this secondary storage, if yes , fails
2. check if there are private templatesin this secondary storage , if yes, fails
1. send purge command only once.
2. in downloadlistener, there are two hosts, one is secondary storage host, the other is secondary storage VM host for this secondary storage.
status 9958: resolved fixed
fixed a DB Exception
5-ThreadPoolExecutor.runWorker:1110-ThreadPoolExecutor$Worker.run:603; called by -Transaction.rollback:783-Transaction.removeUpTo:726-Transaction.close:549-DatabaseCallback.interceptComplete:72
2011-05-19 19:02:41,242 WARN [utils.nio.Task] (AgentManager-Handler-1:null) Caught the following exception but pushing on
com.cloud.utils.exception.CloudRuntimeException: DB Exception on: com.mysql.jdbc.JDBC4PreparedStatement@4faae357: INSERT INTO usage_event (usage_event.type, usage_event.created, usage_event.account_id, usage_event.zone_id, usage_event.resource_id, usage_event.resource_name, usage_event.offering_id, usage_event.template_id, usage_event.size, usage_event.resource_type, usage_event.processed) VALUES (_binary'TEMPLATE.CREATE', '2011-05-20 02:02:41', 2, 2, 202, _binary'anth-te', null, 2, -1, null, 0)
at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1218)
at com.cloud.event.dao.UsageEventDaoImpl$$EnhancerByCGLIB$$377dce70.CGLIB$persist$22(<generated>)
at com.cloud.event.dao.UsageEventDaoImpl$$EnhancerByCGLIB$$377dce70$$FastClassByCGLIB$$30e2aaaf.invoke(<generated>)
at net.sf.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:215)
at com.cloud.utils.db.DatabaseCallback.intercept(DatabaseCallback.java:35)
at com.cloud.event.dao.UsageEventDaoImpl$$EnhancerByCGLIB$$377dce70.persist(<generated>)
at com.cloud.storage.download.DownloadMonitorImpl.handleDownloadEvent(DownloadMonitorImpl.java:410)
at com.cloud.storage.download.DownloadListener.setDownloadInactive(DownloadListener.java:358)
at com.cloud.storage.download.DownloadCompleteState.onEntry(DownloadCompleteState.java:44)
at com.cloud.storage.download.DownloadListener.transition(DownloadListener.java:240)
at com.cloud.storage.download.DownloadListener.processAnswers(DownloadListener.java:224)
at com.cloud.agent.manager.AgentAttache.processAnswers(AgentAttache.java:258)
at com.cloud.agent.manager.AgentManagerImpl$AgentHandler.processResponse(AgentManagerImpl.java:2319)
at com.cloud.agent.manager.AgentManagerImpl$AgentHandler.doTask(AgentManagerImpl.java:2334)
at com.cloud.agent.manager.ClusteredAgentManagerImpl$ClusteredAgentHandler.doTask(ClusteredAgentManagerImpl.java:537)
at com.cloud.utils.nio.Task.run(Task.java:85)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
Caused by: com.mysql.jdbc.MysqlDataTruncation: Data truncation: Out of range value for column 'size' at row 1
status 9623: resolved fixed
Also set ram_size to 1024 for console proxy offering during the upgrade
Conflicts:
core/src/com/cloud/vm/SecondaryStorageVmVO.java
server/src/com/cloud/agent/manager/allocator/impl/UserConcentratedAllocator.java
server/src/com/cloud/consoleproxy/ConsoleProxyManagerImpl.java
server/src/com/cloud/storage/allocator/LocalStoragePoolAllocator.java
server/src/com/cloud/storage/secondary/SecondaryStorageManagerImpl.java
Changes:
- When the ROOT volume of a VM is found to be READY, changed planner to reuse the pool for every volume(root or data) that is READY and that has a pool not in maintenance and not in avoid state
- If ROOT volume is not ready, we dont care about the DATA disk. Both would get re-allocated.
- When a pool is reused for a ready volume, Planner does not call storagepool allocators. And such volumes are not assigned a pool in the deployment destination returned by the planner. Accordingly StorageManager :: prepare method wont recreate these volumes since they are not mentioned in the destination.
Changes:
- Reason was that the old volume's templateId was being updated before volume creation was attempted. So on the retry, we dint find a difference in volume's templateId and VM's templateId and did not enter the recreation logic.
- Fix is to update the new volume's templateId with the VM's templateId while creating the new volume. The old volume's templateId stays the same and the volume is marked as 'Destroy' when a new volume is created.
Changes:
While starting a System VM:
- We check, incase the ROOT volume is READY, if the templateID of the volume matches the SystemVM's template.
- If it does not match, we update the volumes' templateId and ask deployment planner to reassign a pool to this volume even if it is READY.
In general:
- If a root volume is READY, we remove its entry from the deploydestination before calling storagemanager :: prepare()
- StorageManager creates a volume if a pool is assigned to it in deploydestination passed to it.
- If a volume has no pool assigned to it in deploydestination, it means the volume is ready and has a pool already allocated to it.
Changes:
- Planner must reassign the storage pool if the template id for system vms has changed. StorageManager must then recreate the volume if the volume has been
reassigned. This is needed to do automatic update of the system template.
status 7704: resolved fixed
For user vm:
* for default network, take limit from the corresponding service offering
* for all additional networks, take limit from the network offerings
For domainRouter/SSVM/CPVM:
* get info from the network offering
Added new config parameter: "vm.network.throttling.rate". If nw_rate is NULL for serviceOffering, this parameter would be used for default vm's network
- Added a new flag 'allocation_state' to zone,pod,cluster and host
- The possible values for this flag are 'Enabled' or 'Disabled'
- When a new zone,pod,cluster or host is added, allocation_state is 'Disabled' by default.
- For existing zone,pod,cluster or host, the state is 'Enabled'.
- All Add/Update/List commands for each of zone,pod,cluster or host can now take a new parameter 'allocationstate'
- If 'allocation_state' is 'Disabled', Allocators skip that zone or pod or cluster or pod.
- For a root admin, ListZones lists all zones including the 'Disabled' zones. But for any other user, the 'Disabled' zones are not included in the response.
- For any usecase that creates/deploys/adds/registers a resource and takes in zone as parameter, now we check if the Zone is 'Disabled'. If yes then the operation cannot be performed by a user other than root-admin. Add volume, snapshot, templates are examples of this usecase.
- To enable the root admin to test a particular pod/cluster/host, deployVM command takes in 'host_id' parameter that can be passed in only by root admin.
If this parameter is passed in by the admin, allocators do not search for hosts and use that host only. StoragePools are searched in the cluster of that host.
If VM cannot be deployed to that host, allocators and deployVM fails without retrying
Also fixed couple of other issues:
* usage event generation - generate event only when snapshot is created on primary and backed up on secondary
* zoneId was always set to 0 for snapshot.delete event, fixed this.
* Fixed resource_count decrement for manual snapshot deletion
StoragePoolAllocators need to respect storage.capacity.threshold in allocations - this was broken after StatsCollector started maintaining the primary storage Stats separately
Fixed allocator to refer the correct in-memory stats map.
However in case of createVolume from Snapshot, there is no VM associated. So VM passed is null and this can cause a NPE.
Allocators hardly use the VM instance. LocalStoragePoolAllocator was mainly using it for checking if host has capacity. But it need not do this check, since that is done by HostAllocators anyway.
So removing the use of VM in StoragePoolAllocators.
Bug 7723 - merge or re-write host tagging into master / 2.2
Bug 7627 - Need more logging for Allocators
Bug 8317 - Add better resource allocation failure messages
Changes for Deployment Planner to use host and storagePool allocators to find deployment destination.
Also has the changes for host tag feature.
Improved the logging for allocators.
anthony
Kelven Yang
kishan
Nitin
alena
Edison Su
Murali Reddy
Abhinandan Prateek
Alex Huang
Frank
Chiradeep Vittal
prachi
abhishek