I doubt we can fully automate this one, Mike, for the case when data migration/modification is involved (.java file is modified in this case). Only for the changes to .sql files we can automate the instructions. For data modification, the developer who’s made the changes, still needs to provide the instructions on the dev list.
-Alena. From: Mike Tutkowski <mike.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com>> Date: Wednesday, August 6, 2014 at 11:33 AM To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>> Cc: Alena Prokharchyk <alena.prokharc...@citrix.com<mailto:alena.prokharc...@citrix.com>>, Koushik Das <koushik....@citrix.com<mailto:koushik....@citrix.com>> Subject: Re: [DB-CHANGE] Infrastructure tab fails to load with db exception What about the details for updating your DB? If we just receive a general e-mail notification, then each dev will independently have to examine the DB changes to come up with a workaround to keep his/her current env running properly after a code update. On Wednesday, August 6, 2014, Nitin Mehta <nitin.me...@citrix.com<mailto:nitin.me...@citrix.com>> wrote: Agreed. Added that information in the bug. On 06/08/14 11:08 AM, "Alena Prokharchyk" <alena.prokharc...@citrix.com<javascript:;>> wrote: >Thank you, Nitin. I think we should add one more item to the things that >the script checks: modifications to the older upgrade paths shouldn¹t be >allowed. If we already released 4.4, db upgrade changes should be accepted >only to 4.4-4.5 scripts. If someone makes the changes to, say 4.3-4.4, the >mailing list should be notified, and the changes have to be reverted. > >-Alena. > >On 8/6/14, 11:03 AM, "Nitin Mehta" <nitin.me...@citrix.com<javascript:;>> >wrote: > >>This should be automated. We can't rely on the good intentions of dev. >>All we need is a script which checks changes in the schema/java Upgrade >>files and to sends a notification to the dev list. >>Filed a bug for this - >>https://issues.apache.org/jira/browse/CLOUDSTACK-7273 >> >> >>Thanks, >>-Nitin >> >>On 06/08/14 5:28 AM, "Koushik Das" <koushik....@citrix.com<javascript:;>> >>wrote: >> >>>Thanks Saksham. This fixed the initial issue. But I noticed a new one, >>>after destroying the last VR if you select the infra view it again >>>results in exception. Not sure if anything else needs to be fixed. >>> >>>-----Original Message----- >>>From: Saksham Srivastava [mailto:saksham.srivast...@citrix.com<javascript:;>] >>>Sent: Wednesday, 6 August 2014 3:37 PM >>>To: dev@cloudstack.apache.org<javascript:;> >>>Subject: [DB-CHANGE] Infrastructure tab fails to load with db exception >>> >>>I remember we used to follow the practice of informing others in case db >>>changes are committed, but we do not do it anymore. >>>In case you are on dev setup on master branch post the following commit >>>: >>>commit b9d834e83854009483f6d061f9996e5ffaa9b883 >>>Author: Nitin Mehta <nitin.me...@citrix.com<javascript:;>> >>>Date: Tue Aug 5 17:29:34 2014 -0700 >>>CLOUDSTACK-4200: listSystemVMs API and listRouters API should return >>>hypervisor property since dynamic scaling is not enabled for all the >>>hypervisors and that action can be showed only for the hypervisors t >>> >>>Update your database with : >>> >>>DROP VIEW IF EXISTS `cloud`.`domain_router_view`; CREATE VIEW >>>`cloud`.`domain_router_view` AS >>> select >>> vm_instance.id<http://vm_instance.id> id, >>> vm_instance.name<http://vm_instance.name> name, >>> account.id<http://account.id> account_id, >>> account.uuid account_uuid, >>> account.account_name account_name, >>> account.type account_type, >>> domain.id<http://domain.id> domain_id, >>> domain.uuid domain_uuid, >>> domain.name<http://domain.name> domain_name, >>> domain.path domain_path, >>> projects.id<http://projects.id> project_id, >>> projects.uuid project_uuid, >>> projects.name<http://projects.name> project_name, >>> vm_instance.uuid uuid, >>> vm_instance.created created, >>> vm_instance.state state, >>> vm_instance.removed removed, >>> vm_instance.pod_id pod_id, >>> vm_instance.instance_name instance_name, >>> host_pod_ref.uuid pod_uuid, >>> data_center.id<http://data_center.id> data_center_id, >>> data_center.uuid data_center_uuid, >>> data_center.name<http://data_center.name> data_center_name, >>> data_center.networktype data_center_type, >>> data_center.dns1 dns1, >>> data_center.dns2 dns2, >>> data_center.ip6_dns1 ip6_dns1, >>> data_center.ip6_dns2 ip6_dns2, >>> host.id<http://host.id> host_id, >>> host.uuid host_uuid, >>> host.name<http://host.name> host_name, >>> host.hypervisor_type, >>> host.cluster_id cluster_id, >>> vm_template.id<http://vm_template.id> template_id, >>> vm_template.uuid template_uuid, >>> service_offering.id<http://service_offering.id> service_offering_id, >>> disk_offering.uuid service_offering_uuid, >>> disk_offering.name<http://disk_offering.name> service_offering_name, >>> nics.id<http://nics.id> nic_id, >>> nics.uuid nic_uuid, >>> nics.network_id network_id, >>> nics.ip4_address ip_address, >>> nics.ip6_address ip6_address, >>> nics.ip6_gateway ip6_gateway, >>> nics.ip6_cidr ip6_cidr, >>> nics.default_nic is_default_nic, >>> nics.gateway gateway, >>> nics.netmask netmask, >>> nics.mac_address mac_address, >>> nics.broadcast_uri broadcast_uri, >>> nics.isolation_uri isolation_uri, >>> vpc.id<http://vpc.id> vpc_id, >>> vpc.uuid vpc_uuid, >>> networks.uuid network_uuid, >>> networks.name<http://networks.name> network_name, >>> networks.network_domain network_domain, >>> networks.traffic_type traffic_type, >>> networks.guest_type guest_type, >>> async_job.id<http://async_job.id> job_id, >>> async_job.uuid job_uuid, >>> async_job.job_status job_status, >>> async_job.account_id job_account_id, >>> domain_router.template_version template_version, >>> domain_router.scripts_version scripts_version, >>> domain_router.is_redundant_router is_redundant_router, >>> domain_router.redundant_state redundant_state, >>> domain_router.stop_pending stop_pending, >>> domain_router.role role >>> from >>> `cloud`.`domain_router` >>> inner join >>> `cloud`.`vm_instance` ON vm_instance.id<http://vm_instance.id> = >>> domain_router.id<http://domain_router.id> >>> inner join >>> `cloud`.`account` ON vm_instance.account_id = >>> account.id<http://account.id> >>> inner join >>> `cloud`.`domain` ON vm_instance.domain_id = >>> domain.id<http://domain.id> >>> left join >>> `cloud`.`host_pod_ref` ON vm_instance.pod_id = >>> host_pod_ref.id<http://host_pod_ref.id> >>> left join >>> `cloud`.`projects` ON projects.project_account_id = >>> account.id<http://account.id> >>> left join >>> `cloud`.`data_center` ON vm_instance.data_center_id = >>>data_center.id<http://data_center.id> >>> left join >>> `cloud`.`host` ON vm_instance.host_id = host.id<http://host.id> >>> left join >>> `cloud`.`vm_template` ON vm_instance.vm_template_id = >>>vm_template.id<http://vm_template.id> >>> left join >>> `cloud`.`service_offering` ON vm_instance.service_offering_id = >>>service_offering.id<http://service_offering.id> >>> left join >>> `cloud`.`disk_offering` ON vm_instance.service_offering_id = >>>disk_offering.id<http://disk_offering.id> >>> left join >>> `cloud`.`nics` ON vm_instance.id<http://vm_instance.id> = >>> nics.instance_id and >>>nics.removed is null >>> left join >>> `cloud`.`networks` ON nics.network_id = >>> networks.id<http://networks.id> >>> left join >>> `cloud`.`vpc` ON domain_router.vpc_id = vpc.id<http://vpc.id> and >>> vpc.removed >>>is >>>null >>> left join >>> `cloud`.`async_job` ON async_job.instance_id = >>> vm_instance.id<http://vm_instance.id> >>> and async_job.instance_type = 'DomainRouter' >>> and async_job.job_status = 0; >>> >>> >>> >>>Thanks, >>>Saksham >> > -- Mike Tutkowski Senior CloudStack Developer, SolidFire Inc. e: mike.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com> o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play>™
