Addition of two new resource types i.e. Primary and Secondary storage space in the existing pool of
resource types.
Added methods to set the limits on these resources using updateResourceLimit
API command and to get a count using updateResourceCount. Also added calls in the
Templates, Volumes, Snapshots life cycle to check these limits and to increment/decrement the new
resource types
Resource Name :: Resource type number
Primary Storage 10
Secondary Storage 11
Also added jUnit Tests for the same.
Reviewed by : nitin mehta<nitin.mehta@citrix.com>
Removed region_id from user/account and domain tables.
Removed forwarding of api calls to owner region.
Removed api_key and secret_key from region table.
Included related DB upgrade changes.
Having `i_op_dc_vnet_alloc__vnet__data_center_id__account_id` will restrict
same account holding the same vnet across different physical networks.
Signed-off-by: Kishan Kavala <kishan@cloud.com>
Enhanced baremetal servers support on Cisco UCS
change UcsXxxDao to Spring xml loading
change ListxxxCmd to inherit ListCmd
change API response in line with current API architecture
adding missing db schema to db upgrade schemaOh
Conflicts:
client/pom.xml
plugins/hypervisors/ucs/src/com/cloud/ucs/database/UcsBladeDaoImpl.java
plugins/hypervisors/ucs/src/com/cloud/ucs/database/UcsManagerDaoImpl.java
Supporting kickstart in CloudStack baremetal
able to start vm
Conflicts:
client/tomcatconf/componentContext.xml.in
server/src/com/cloud/baremetal/BareMetalTemplateAdapter.java
server/src/com/cloud/baremetal/BareMetalVmManagerImpl.java
server/src/com/cloud/vm/UserVmManagerImpl.java
In c63dbb8804 I removed the rule from create-schema:
- `queue_proc_time` datetime COMMENT 'when processing started for the item',
But, upgrade path schema-40to410.sql had a different rule which caused the bug:
+ALTER TABLE `cloud`.`sync_queue_item` ADD `queue_proc_time` DATETIME NOT NULL
COMMENT 'when processing started for the item' AFTER `queue_proc_number`;
In this fix we just revert to whatever rule was defined in create-schema as the
developer may have forgetten to fix same rule in create-schema and upgrade path.
This commit can be reverted or the code be fixed if we want that queue_proc_time
cannot be null.
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
- Move changes since 4.0 to schema upgrade path (schema40-410.sql)
- Comment out some table names where we're trying to copy uuid from id, they
don't exists
- We don't run above step for tables which are newly created for 410 and don't
exist in 4.0 for example autoscale related ones, code is commented and not removed
- Drop indexes which are removed before dropping the column
- Comment out insertion, as for default region we're inserting the same in
code, in ConfigurationServerImpl:createDefaultRegion(), fix same in premium
Testing;
Deployed fresh 4.0 database, compiled and ran mgmt server. It did a smooth
rolling upgrade from 4.0 to 4.1.0 with no database exceptions or any other db error.
TODO:
- 4.2.0 relates changes like ipv6 should go into its schema-410to420.sql
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
Fixed Component annontation for usage parsers
Fixed mvn target to run usage
removed UsageServerComponentConfig which is not required
Added region_id to account table in cloud_usage db
Conflicts:
setup/db/db/schema-40to410.sql
Addition of two new resource types i.e. CPU and Memory in the existing pool of
resource types.
Added some methods to set the limits on these resources using updateResourceLimit
API command and to get a count using updateResourceCount. Also added calls in the
Virtual machine life cycle to check these limits and to increment/decrement the new
resource types
Resource Name :: Resource type number
CPU 8
Memory 9
Also added Unit Tests for the same.
Rajesh Battala
tuna
Anshul Gangwar
frank
Min Chen
Chip Childers
Murali Reddy
Nitin Mehta
Jessica Wang
Mice Xia
Kishan Kavala
Edison Su
Prasanna Santhanam
Sanjay Tripathi
Venkata Swamybabu Budumuru
frank
Sheng Yang
Rohit Yadav
Sanjay Tripathi