RE: [DB-CHANGE] Infrastructure tab fails to load with db exception
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] Sent: Wednesday, 6 August 2014 3:37 PM To: dev@cloudstack.apache.org 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 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 id, vm_instance.name name, account.id account_id, account.uuid account_uuid, account.account_name account_name, account.type account_type, domain.id domain_id, domain.uuid domain_uuid, domain.name domain_name, domain.path domain_path, projects.id project_id, projects.uuid project_uuid, 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 data_center_id, data_center.uuid data_center_uuid, 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 host_id, host.uuid host_uuid, host.name host_name, host.hypervisor_type, host.cluster_id cluster_id, vm_template.id template_id, vm_template.uuid template_uuid, service_offering.id service_offering_id, disk_offering.uuid service_offering_uuid, disk_offering.name service_offering_name, 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 vpc_id, vpc.uuid vpc_uuid, networks.uuid network_uuid, networks.name network_name, networks.network_domain network_domain, networks.traffic_type traffic_type, networks.guest_type guest_type, 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 = domain_router.id inner join `cloud`.`account` ON vm_instance.account_id = account.id inner join `cloud`.`domain` ON vm_instance.domain_id = domain.id left join `cloud`.`host_pod_ref` ON vm_instance.pod_id = host_pod_ref.id left join `cloud`.`projects` ON projects.project_account_id = account.id left join `cloud`.`data_center` ON vm_instance.data_center_id = data_center.id left join `cloud`.`host` ON vm_instance.host_id = host.id left join `cloud`.`vm_template` ON vm_instance.vm_template_id = vm_template.id left join `cloud`.`service_offering` ON vm_instance.service_offering_id = service_offering.id left join `cloud`.`disk_offering` ON vm_instance.service_offering_id = disk_offering.id left join `cloud`.`nics` ON vm_instance.id = nics.instance_id and nics.removed is null left join `cloud`.`networks` ON nics.network_id = networks.id left join `cloud`.`vpc` ON domain_router.vpc_id = vpc.id and vpc.removed is null left join `cloud`.`async_job` ON async_job.instance_id =
Re: [DB-CHANGE] Infrastructure tab fails to load with db exception
Thanks for sending this out! These can be really helpful. On Wed, Aug 6, 2014 at 4:06 AM, Saksham Srivastava < saksham.srivast...@citrix.com> wrote: > 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 > 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 id, > vm_instance.name name, > account.id account_id, > account.uuid account_uuid, > account.account_name account_name, > account.type account_type, > domain.id domain_id, > domain.uuid domain_uuid, > domain.name domain_name, > domain.path domain_path, > projects.id project_id, > projects.uuid project_uuid, > 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 data_center_id, > data_center.uuid data_center_uuid, > 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 host_id, > host.uuid host_uuid, > host.name host_name, >host.hypervisor_type, > host.cluster_id cluster_id, > vm_template.id template_id, > vm_template.uuid template_uuid, > service_offering.id service_offering_id, > disk_offering.uuid service_offering_uuid, > disk_offering.name service_offering_name, > 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 vpc_id, > vpc.uuid vpc_uuid, > networks.uuid network_uuid, > networks.name network_name, > networks.network_domain network_domain, > networks.traffic_type traffic_type, > networks.guest_type guest_type, > 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 = domain_router.id > inner join > `cloud`.`account` ON vm_instance.account_id = account.id > inner join > `cloud`.`domain` ON vm_instance.domain_id = domain.id > left join > `cloud`.`host_pod_ref` ON vm_instance.pod_id = host_pod_ref.id > left join > `cloud`.`projects` ON projects.project_account_id = account.id > left join > `cloud`.`data_center` ON vm_instance.data_center_id = > data_center.id > left join > `cloud`.`host` ON vm_instance.host_id = host.id > left join > `cloud`.`vm_template` ON vm_instance.vm_template_id = > vm_template.id > left join >`cloud`.`service_offering` ON vm_instance.service_offering_id = > service_offering.id > left join > `cloud`.`disk_offering` ON vm_instance.service_offering_id = > disk_offering.id > left join > `cloud`.`nics` ON vm_instance.id = nics.instance_id and > nics.removed is null > left join > `cloud`.`networks` ON nics.network_id = networks.id > left join > `cloud`.`vpc` ON domain_router.vpc_id = vpc.id and vpc.removed is > null > left join > `cloud`.`async_job` ON async_job.instance_id = vm_instance.id > and async_job.instance_type = 'D
Re: [DB-CHANGE] Infrastructure tab fails to load with db exception
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" 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] >Sent: Wednesday, 6 August 2014 3:37 PM >To: dev@cloudstack.apache.org >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 >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 id, >vm_instance.name name, >account.id account_id, >account.uuid account_uuid, >account.account_name account_name, >account.type account_type, >domain.id domain_id, >domain.uuid domain_uuid, >domain.name domain_name, >domain.path domain_path, >projects.id project_id, >projects.uuid project_uuid, >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 data_center_id, >data_center.uuid data_center_uuid, >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 host_id, >host.uuid host_uuid, >host.name host_name, > host.hypervisor_type, >host.cluster_id cluster_id, >vm_template.id template_id, >vm_template.uuid template_uuid, >service_offering.id service_offering_id, >disk_offering.uuid service_offering_uuid, >disk_offering.name service_offering_name, >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 vpc_id, >vpc.uuid vpc_uuid, >networks.uuid network_uuid, >networks.name network_name, >networks.network_domain network_domain, >networks.traffic_type traffic_type, >networks.guest_type guest_type, >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 = domain_router.id >inner join >`cloud`.`account` ON vm_instance.account_id = account.id >inner join >`cloud`.`domain` ON vm_instance.domain_id = domain.id >left join >`cloud`.`host_pod_ref` ON vm_instance.pod_id = host_pod_ref.id >left join >`cloud`.`projects` ON projects.project_account_id = account.id >left join >`cloud`.`data_center` ON vm_instance.data_center_id = >data_center.id >left join >`cloud`.`host` ON vm_instance.host_id = host.id >left join >`cloud`.`vm_template` ON vm_instance.vm_template_id = >vm_template.id >left join > `cloud`.`service_offering` ON vm_instance.service_offering_id = >service_offering.id >left join >`clo
Re: [DB-CHANGE] Infrastructure tab fails to load with db exception
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" 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" 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] >>Sent: Wednesday, 6 August 2014 3:37 PM >>To: dev@cloudstack.apache.org >>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 >>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 id, >>vm_instance.name name, >>account.id account_id, >>account.uuid account_uuid, >>account.account_name account_name, >>account.type account_type, >>domain.id domain_id, >>domain.uuid domain_uuid, >>domain.name domain_name, >>domain.path domain_path, >>projects.id project_id, >>projects.uuid project_uuid, >>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 data_center_id, >>data_center.uuid data_center_uuid, >>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 host_id, >>host.uuid host_uuid, >>host.name host_name, >> host.hypervisor_type, >>host.cluster_id cluster_id, >>vm_template.id template_id, >>vm_template.uuid template_uuid, >>service_offering.id service_offering_id, >>disk_offering.uuid service_offering_uuid, >>disk_offering.name service_offering_name, >>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 vpc_id, >>vpc.uuid vpc_uuid, >>networks.uuid network_uuid, >>networks.name network_name, >>networks.network_domain network_domain, >>networks.traffic_type traffic_type, >>networks.guest_type guest_type, >>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 = domain_router.id >>inner join >>`cloud`.`account` ON vm_instance.account_id = account.id >>inner join >>`cloud`.`domain` ON vm_instance.domain_id = domain.id >>left join >>`cloud`.`host_pod_ref` ON vm_instance.pod_id = host_pod_ref
Re: [DB-CHANGE] Infrastructure tab fails to load with db exception
Agreed. Added that information in the bug. On 06/08/14 11:08 AM, "Alena Prokharchyk" 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" 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" 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] >>>Sent: Wednesday, 6 August 2014 3:37 PM >>>To: dev@cloudstack.apache.org >>>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 >>>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 id, >>>vm_instance.name name, >>>account.id account_id, >>>account.uuid account_uuid, >>>account.account_name account_name, >>>account.type account_type, >>>domain.id domain_id, >>>domain.uuid domain_uuid, >>>domain.name domain_name, >>>domain.path domain_path, >>>projects.id project_id, >>>projects.uuid project_uuid, >>>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 data_center_id, >>>data_center.uuid data_center_uuid, >>>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 host_id, >>>host.uuid host_uuid, >>>host.name host_name, >>> host.hypervisor_type, >>>host.cluster_id cluster_id, >>>vm_template.id template_id, >>>vm_template.uuid template_uuid, >>>service_offering.id service_offering_id, >>>disk_offering.uuid service_offering_uuid, >>>disk_offering.name service_offering_name, >>>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 vpc_id, >>>vpc.uuid vpc_uuid, >>>networks.uuid network_uuid, >>>networks.name network_name, >>>networks.network_domain network_domain, >>>networks.traffic_type traffic_type, >>>networks.guest_type guest_type, >>>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 = domain_router.id >>>inner join >>>`cloud`.`account` ON
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 wrote: > Agreed. Added that information in the bug. > > On 06/08/14 11:08 AM, "Alena Prokharchyk" > > 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" > > 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" > 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 > ] > >>>Sent: Wednesday, 6 August 2014 3:37 PM > >>>To: dev@cloudstack.apache.org > >>>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 > > >>>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 id, > >>>vm_instance.name name, > >>>account.id account_id, > >>>account.uuid account_uuid, > >>>account.account_name account_name, > >>>account.type account_type, > >>>domain.id domain_id, > >>>domain.uuid domain_uuid, > >>>domain.name domain_name, > >>>domain.path domain_path, > >>>projects.id project_id, > >>>projects.uuid project_uuid, > >>>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 data_center_id, > >>>data_center.uuid data_center_uuid, > >>>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 host_id, > >>>host.uuid host_uuid, > >>>host.name host_name, > >>> host.hypervisor_type, > >>>host.cluster_id cluster_id, > >>>vm_template.id template_id, > >>>vm_template.uuid template_uuid, > >>>service_offering.id service_offering_id, > >>>disk_offering.uuid service_offering_uuid, > >>>disk_offering.name service_offering_name, > >>>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 vpc_id, > >>>vpc.uuid vpc_uuid, > >>>networks.uuid network_uuid, > >>>networks.name network_name, > >>>networks.network_domain network_domain, > >>>networks.traffic_type traffic_type, > >>>networks.guest_type guest_type, > >>>async_job.id job_id, > >>>async_job.uuid job_uuid, > >>>async_job.job_status job_status, > >>>async_job.account_
Re: [DB-CHANGE] Infrastructure tab fails to load with db exception
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 mailto:mike.tutkow...@solidfire.com>> Date: Wednesday, August 6, 2014 at 11:33 AM To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" mailto:dev@cloudstack.apache.org>> Cc: Alena Prokharchyk mailto:alena.prokharc...@citrix.com>>, Koushik Das 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 mailto:nitin.me...@citrix.com>> wrote: Agreed. Added that information in the bug. On 06/08/14 11:08 AM, "Alena Prokharchyk" > 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" > >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" > >>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] >>>Sent: Wednesday, 6 August 2014 3:37 PM >>>To: dev@cloudstack.apache.org >>>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 > >>>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, >>>da
Re: [DB-CHANGE] Infrastructure tab fails to load with db exception
Mike - I agree that automation might not resolve the issue completely but will better devs lives. I think for schema file changes just the diffs published should do. For Java files it might sometimes require some more analysis and manual input from dev. Nevertheless it will always send a notification that some db changes were made and so people pulling in from master won't be in dark whether there were some db changes or not. Thanks, -Nitin On 06/08/14 11:40 AM, "Alena Prokharchyk" wrote: >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 >mailto:mike.tutkow...@solidfire.com>> >Date: Wednesday, August 6, 2014 at 11:33 AM >To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" >mailto:dev@cloudstack.apache.org>> >Cc: Alena Prokharchyk >mailto:alena.prokharc...@citrix.com>>, >Koushik Das 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 >mailto:nitin.me...@citrix.com>> wrote: >Agreed. Added that information in the bug. > >On 06/08/14 11:08 AM, "Alena Prokharchyk" >> >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" >>> 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" >>>> 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] >>>>Sent: Wednesday, 6 August 2014 3:37 PM >>>>To: dev@cloudstack.apache.org >>>>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 > >>>>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
Re: [DB-CHANGE] Infrastructure tab fails to load with db exception
Yep, I agree. I guess my point was that a manually created e-mail should still be issued by the developer. On Wednesday, August 6, 2014, Alena Prokharchyk < alena.prokharc...@citrix.com> wrote: > 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 > > Date: Wednesday, August 6, 2014 at 11:33 AM > To: "dev@cloudstack.apache.org > " < > dev@cloudstack.apache.org > > > Cc: Alena Prokharchyk >, Koushik > Das > > 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 > wrote: > >> Agreed. Added that information in the bug. >> >> On 06/08/14 11:08 AM, "Alena Prokharchyk" >> 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" 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" 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] >> >>>Sent: Wednesday, 6 August 2014 3:37 PM >> >>>To: dev@cloudstack.apache.org >> >>>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 >> >>>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 id, >> >>>vm_instance.name name, >> >>>account.id account_id, >> >>>account.uuid account_uuid, >> >>>account.account_name account_name, >> >>>account.type account_type, >> >>>domain.id domain_id, >> >>>domain.uuid domain_uuid, >> >>>domain.name domain_name, >> >>>domain.path domain_path, >> >>>projects.id project_id, >> >>>projects.uuid project_uuid, >> >>>projects.name project_name, >> >>>vm_instance.uuid uuid, >> >>>vm_instance.created create
Re: [DB-CHANGE] Infrastructure tab fails to load with db exception
If you care, why not self-police use git hooks: http://markmail.org/message/h5yb27jy6qrrw4dh Cheers. On 06-Aug-2014, at 8:51 pm, Mike Tutkowski wrote: > Yep, I agree. > > I guess my point was that a manually created e-mail should still be issued > by the developer. > > On Wednesday, August 6, 2014, Alena Prokharchyk < > alena.prokharc...@citrix.com> wrote: > >> 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 > > >> Date: Wednesday, August 6, 2014 at 11:33 AM >> To: "dev@cloudstack.apache.org >> " < >> dev@cloudstack.apache.org >> > >> Cc: Alena Prokharchyk > >, Koushik >> Das > > >> 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 > > wrote: >> >>> Agreed. Added that information in the bug. >>> >>> On 06/08/14 11:08 AM, "Alena Prokharchyk" >>> 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" 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" 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] >>>>>> Sent: Wednesday, 6 August 2014 3:37 PM >>>>>> To: dev@cloudstack.apache.org >>>>>> 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 >>>>>> 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 id, >>>>>> vm_instance.name name, >>>>>> account.id account_id, >>>>>> account.uuid account_uuid, >>>>>> account.account_name account_name, &
Re: [DB-CHANGE] Infrastructure tab fails to load with db exception
Here you go, modify and install in your git repositories: https://github.com/apache/cloudstack/blob/master/tools/git/db-police It will audaciously alert you, on OSX using ‘say’ and on GNU/Linux using ‘festival’ (if installed). I was not sure about Windows, so if anyone can cover that case? Cheers. On 06-Aug-2014, at 9:14 pm, Rohit Yadav wrote: > If you care, why not self-police use git hooks: > http://markmail.org/message/h5yb27jy6qrrw4dh > > Cheers. > > On 06-Aug-2014, at 8:51 pm, Mike Tutkowski > wrote: > >> Yep, I agree. >> >> I guess my point was that a manually created e-mail should still be issued >> by the developer. >> >> On Wednesday, August 6, 2014, Alena Prokharchyk < >> alena.prokharc...@citrix.com> wrote: >> >>> 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 >> > >>> Date: Wednesday, August 6, 2014 at 11:33 AM >>> To: "dev@cloudstack.apache.org >>> " < >>> dev@cloudstack.apache.org >>> > >>> Cc: Alena Prokharchyk >> >, Koushik >>> Das >> > >>> 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 >> > wrote: >>> >>>> Agreed. Added that information in the bug. >>>> >>>> On 06/08/14 11:08 AM, "Alena Prokharchyk" >>>> 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" 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" 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] >>>>>>> Sent: Wednesday, 6 August 2014 3:37 PM >>>>>>> To: dev@cloudstack.apache.org >>>>>>> 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 >>>>>>> Date: Tue Aug 5 17:29:34 2014 -0700 >>>>>>> CLOUDSTACK-4200: listSystemVMs API and listRouters API should return >>>&g
Re: [DB-CHANGE] Infrastructure tab fails to load with db exception
H, I got a review that I should remove the update to 4.3 system templates from the 4.4 upgrade path when I added the 4.4 upgrade. Shouldn't I have done that? It seems in contradiction with what you said in this thread. Maybe it is a special case as the upgrade will fail if you don't have them, but you do not want them in the end. I think not trying to upgrade to an intermediate set of templates (hence changing the upgrade code) is not bad in this case. Agree? Daan On Wed, Aug 6, 2014 at 10:51 PM, Rohit Yadav wrote: > Here you go, modify and install in your git repositories: > https://github.com/apache/cloudstack/blob/master/tools/git/db-police > > It will audaciously alert you, on OSX using ‘say’ and on GNU/Linux using > ‘festival’ (if installed). > I was not sure about Windows, so if anyone can cover that case? > > Cheers. > > > On 06-Aug-2014, at 9:14 pm, Rohit Yadav wrote: > >> If you care, why not self-police use git hooks: >> http://markmail.org/message/h5yb27jy6qrrw4dh >> >> Cheers. >> >> On 06-Aug-2014, at 8:51 pm, Mike Tutkowski >> wrote: >> >>> Yep, I agree. >>> >>> I guess my point was that a manually created e-mail should still be issued >>> by the developer. >>> >>> On Wednesday, August 6, 2014, Alena Prokharchyk < >>> alena.prokharc...@citrix.com> wrote: >>> >>>> 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 >>> > >>>> Date: Wednesday, August 6, 2014 at 11:33 AM >>>> To: "dev@cloudstack.apache.org >>>> " < >>>> dev@cloudstack.apache.org >>>> > >>>> Cc: Alena Prokharchyk >>> >, Koushik >>>> Das >>> > >>>> 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 >>> > wrote: >>>> >>>>> Agreed. Added that information in the bug. >>>>> >>>>> On 06/08/14 11:08 AM, "Alena Prokharchyk" >>>>> 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" 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" 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 [mai
Re: [DB-CHANGE] Infrastructure tab fails to load with db exception
Don’t you think we are overlooking the actual problem of handle migrations on the development branch? ~Rajani On 07-Aug-2014, at 12:21 am, Mike Tutkowski wrote: > Yep, I agree. > > I guess my point was that a manually created e-mail should still be issued > by the developer. > > On Wednesday, August 6, 2014, Alena Prokharchyk < > alena.prokharc...@citrix.com> wrote: > >> 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 > > >> Date: Wednesday, August 6, 2014 at 11:33 AM >> To: "dev@cloudstack.apache.org >> " < >> dev@cloudstack.apache.org >> > >> Cc: Alena Prokharchyk > >, Koushik >> Das > > >> 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 > > wrote: >> >>> Agreed. Added that information in the bug. >>> >>> On 06/08/14 11:08 AM, "Alena Prokharchyk" >>> 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" 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" 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] >>>>>> Sent: Wednesday, 6 August 2014 3:37 PM >>>>>> To: dev@cloudstack.apache.org >>>>>> 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 >>>>>> 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 id, >>>>>> vm_instance.name name, >>>>>> account.id account_id, >>>>>> account.uuid account_uuid, >>>>>> accou
Re: [DB-CHANGE] Infrastructure tab fails to load with db exception
We are but the solution seems to be to complicated for us. I think we should go to a model of per commit migrations. (and maybe even downgrades) Any answer on my sysvm question? On Thu, Aug 7, 2014 at 6:04 AM, Rajani Karuturi wrote: > Don’t you think we are overlooking the actual problem of handle migrations on > the development branch? > > ~Rajani > > > > On 07-Aug-2014, at 12:21 am, Mike Tutkowski > wrote: > >> Yep, I agree. >> >> I guess my point was that a manually created e-mail should still be issued >> by the developer. >> >> On Wednesday, August 6, 2014, Alena Prokharchyk < >> alena.prokharc...@citrix.com> wrote: >> >>> 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 >> > >>> Date: Wednesday, August 6, 2014 at 11:33 AM >>> To: "dev@cloudstack.apache.org >>> " < >>> dev@cloudstack.apache.org >>> > >>> Cc: Alena Prokharchyk >> >, Koushik >>> Das >> > >>> 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 >> > wrote: >>> >>>> Agreed. Added that information in the bug. >>>> >>>> On 06/08/14 11:08 AM, "Alena Prokharchyk" >>>> 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" 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" 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] >>>>>>> Sent: Wednesday, 6 August 2014 3:37 PM >>>>>>> To: dev@cloudstack.apache.org >>>>>>> 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 >>>>>>> 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 fo
Re: [DB-CHANGE] Infrastructure tab fails to load with db exception
That is true. It was not my intent to address that problem, though. I was simply commenting on the question of whether we should continue to use the [DB-CHANGE] e-mail tag (I believe we should). On Wed, Aug 6, 2014 at 10:04 PM, Rajani Karuturi wrote: > Don’t you think we are overlooking the actual problem of handle migrations > on the development branch? > > ~Rajani > > > > On 07-Aug-2014, at 12:21 am, Mike Tutkowski > wrote: > > > Yep, I agree. > > > > I guess my point was that a manually created e-mail should still be > issued > > by the developer. > > > > On Wednesday, August 6, 2014, Alena Prokharchyk < > > alena.prokharc...@citrix.com> wrote: > > > >> 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 >> > > >> Date: Wednesday, August 6, 2014 at 11:33 AM > >> To: "dev@cloudstack.apache.org > >> " < > >> dev@cloudstack.apache.org > >> > > >> Cc: Alena Prokharchyk >> >, > Koushik > >> Das >> > > >> 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 >> > wrote: > >> > >>> Agreed. Added that information in the bug. > >>> > >>> On 06/08/14 11:08 AM, "Alena Prokharchyk" < > alena.prokharc...@citrix.com> > >>> 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" 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" 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] > >>>>>> Sent: Wednesday, 6 August 2014 3:37 PM > >>>>>> To: dev@cloudstack.apache.org > >>>>>> 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 > >>>>>> Date: Tue Aug 5 17:29:34 2014 -0700 &g
RE: [DB-CHANGE] Infrastructure tab fails to load with db exception
Agree, we should be using the same tag. https://cwiki.apache.org/confluence/display/CLOUDSTACK/mail+tags+to+use+to+help+each+other -Original Message- From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] Sent: Thursday, August 7, 2014 11:29 PM To: dev@cloudstack.apache.org Cc: Alena Prokharchyk Subject: Re: [DB-CHANGE] Infrastructure tab fails to load with db exception That is true. It was not my intent to address that problem, though. I was simply commenting on the question of whether we should continue to use the [DB-CHANGE] e-mail tag (I believe we should). On Wed, Aug 6, 2014 at 10:04 PM, Rajani Karuturi wrote: > Don’t you think we are overlooking the actual problem of handle > migrations on the development branch? > > ~Rajani > > > > On 07-Aug-2014, at 12:21 am, Mike Tutkowski > > wrote: > > > Yep, I agree. > > > > I guess my point was that a manually created e-mail should still be > issued > > by the developer. > > > > On Wednesday, August 6, 2014, Alena Prokharchyk < > > alena.prokharc...@citrix.com> wrote: > > > >> 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 >> > > >> Date: Wednesday, August 6, 2014 at 11:33 AM > >> To: "dev@cloudstack.apache.org > >> " < > >> dev@cloudstack.apache.org > >> > > >> Cc: Alena Prokharchyk >> >, > Koushik > >> Das >> > > >> 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 >> > wrote: > >> > >>> Agreed. Added that information in the bug. > >>> > >>> On 06/08/14 11:08 AM, "Alena Prokharchyk" < > alena.prokharc...@citrix.com> > >>> 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" 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" 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] > >>>>>> Sent: Wednesday, 6 August 2014 3:37 PM > >>>>>> To: dev@cloudstack.apache.org > >>>>>> Subject: [DB-CHANGE] Infrastructure tab fails to load with db >
Re: [DB-CHANGE] Infrastructure tab fails to load with db exception
Ah Mike, I now see what you where commenting on. It seemed strange that you would urge to send out a mail in the actual thread that was send out as you so desire. 8} On Fri, Aug 8, 2014 at 10:33 AM, Saksham Srivastava wrote: > Agree, we should be using the same tag. > https://cwiki.apache.org/confluence/display/CLOUDSTACK/mail+tags+to+use+to+help+each+other > > -Original Message- > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] > Sent: Thursday, August 7, 2014 11:29 PM > To: dev@cloudstack.apache.org > Cc: Alena Prokharchyk > Subject: Re: [DB-CHANGE] Infrastructure tab fails to load with db exception > > That is true. It was not my intent to address that problem, though. I was > simply commenting on the question of whether we should continue to use the > [DB-CHANGE] e-mail tag (I believe we should). > > > On Wed, Aug 6, 2014 at 10:04 PM, Rajani Karuturi > wrote: > >> Don’t you think we are overlooking the actual problem of handle >> migrations on the development branch? >> >> ~Rajani >> >> >> >> On 07-Aug-2014, at 12:21 am, Mike Tutkowski >> >> wrote: >> >> > Yep, I agree. >> > >> > I guess my point was that a manually created e-mail should still be >> issued >> > by the developer. >> > >> > On Wednesday, August 6, 2014, Alena Prokharchyk < >> > alena.prokharc...@citrix.com> wrote: >> > >> >> 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 > >> > >> >> Date: Wednesday, August 6, 2014 at 11:33 AM >> >> To: "dev@cloudstack.apache.org >> >> " < >> >> dev@cloudstack.apache.org >> >> > >> >> Cc: Alena Prokharchyk > >> >, >> Koushik >> >> Das > >> > >> >> 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 > >> > wrote: >> >> >> >>> Agreed. Added that information in the bug. >> >>> >> >>> On 06/08/14 11:08 AM, "Alena Prokharchyk" < >> alena.prokharc...@citrix.com> >> >>> 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" 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" wrote: >> >>>>> >> >>>>>> Thanks Saksham. This fixed the initial issue. But I noticed a >>
