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 rajani.karut...@citrix.com 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 mike.tutkow...@solidfire.com 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 mike.tutkow...@solidfire.com javascript:_e(%7B%7D,'cvml','mike.tutkow...@solidfire.com'); Date: Wednesday, August 6, 2014 at 11:33 AM To: dev@cloudstack.apache.org javascript:_e(%7B%7D,'cvml','dev@cloudstack.apache.org'); dev@cloudstack.apache.org javascript:_e(%7B%7D,'cvml','dev@cloudstack.apache.org'); Cc: Alena Prokharchyk alena.prokharc...@citrix.com javascript:_e(%7B%7D,'cvml','alena.prokharc...@citrix.com');, Koushik Das koushik@citrix.com javascript:_e(%7B%7D,'cvml','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 javascript:_e(%7B%7D,'cvml','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 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 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 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 nitin.me...@citrix.com 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
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 saksham.srivast...@citrix.com 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 rajani.karut...@citrix.com 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 mike.tutkow...@solidfire.com 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 mike.tutkow...@solidfire.com javascript:_e(%7B%7D,'cvml','mike.tutkow...@solidfire.com'); Date: Wednesday, August 6, 2014 at 11:33 AM To: dev@cloudstack.apache.org javascript:_e(%7B%7D,'cvml','dev@cloudstack.apache.org'); dev@cloudstack.apache.org javascript:_e(%7B%7D,'cvml','dev@cloudstack.apache.org'); Cc: Alena Prokharchyk alena.prokharc...@citrix.com javascript:_e(%7B%7D,'cvml','alena.prokharc...@citrix.com');, Koushik Das koushik@citrix.com javascript:_e(%7B%7D,'cvml','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 javascript:_e(%7B%7D,'cvml','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 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 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 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 nitin.me...@citrix.com 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
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 rajani.karut...@citrix.com 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 mike.tutkow...@solidfire.com 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 mike.tutkow...@solidfire.com javascript:_e(%7B%7D,'cvml','mike.tutkow...@solidfire.com'); Date: Wednesday, August 6, 2014 at 11:33 AM To: dev@cloudstack.apache.org javascript:_e(%7B%7D,'cvml','dev@cloudstack.apache.org'); dev@cloudstack.apache.org javascript:_e(%7B%7D,'cvml','dev@cloudstack.apache.org'); Cc: Alena Prokharchyk alena.prokharc...@citrix.com javascript:_e(%7B%7D,'cvml','alena.prokharc...@citrix.com');, Koushik Das koushik@citrix.com javascript:_e(%7B%7D,'cvml','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 javascript:_e(%7B%7D,'cvml','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 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 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 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 nitin.me...@citrix.com 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
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 rajani.karut...@citrix.com 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 mike.tutkow...@solidfire.com 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 mike.tutkow...@solidfire.com javascript:_e(%7B%7D,'cvml','mike.tutkow...@solidfire.com'); Date: Wednesday, August 6, 2014 at 11:33 AM To: dev@cloudstack.apache.org javascript:_e(%7B%7D,'cvml','dev@cloudstack.apache.org'); dev@cloudstack.apache.org javascript:_e(%7B%7D,'cvml','dev@cloudstack.apache.org'); Cc: Alena Prokharchyk alena.prokharc...@citrix.com javascript:_e(%7B%7D,'cvml','alena.prokharc...@citrix.com');, Koushik Das koushik@citrix.com javascript:_e(%7B%7D,'cvml','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 javascript:_e(%7B%7D,'cvml','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 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 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 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 nitin.me...@citrix.com 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
[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 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 = 'DomainRouter' and async_job.job_status = 0; Thanks, Saksham
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 nitin.me...@citrix.com 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
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 nitin.me...@citrix.com 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 = 'DomainRouter' and async_job.job_status = 0; Thanks, Saksham -- *Mike Tutkowski*
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 koushik@citrix.com 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 nitin.me...@citrix.com 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
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 nitin.me...@citrix.com 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 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 nitin.me...@citrix.com 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
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 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 nitin.me...@citrix.com 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 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 nitin.me...@citrix.com 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
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 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 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
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 mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.com Date: Wednesday, August 6, 2014 at 11:33 AM To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Cc: Alena Prokharchyk alena.prokharc...@citrix.commailto:alena.prokharc...@citrix.com, Koushik Das koushik@citrix.commailto: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.commailto:nitin.me...@citrix.com wrote: Agreed. Added that information in the bug. On 06/08/14 11:08 AM, Alena Prokharchyk alena.prokharc...@citrix.comjavascript:; 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.comjavascript:; 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.comjavascript:; 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.comjavascript:;] Sent: Wednesday, 6 August 2014 3:37 PM To: dev@cloudstack.apache.orgjavascript:; 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.comjavascript:; 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.idhttp://vm_instance.id id, vm_instance.namehttp://vm_instance.name name, account.idhttp://account.id account_id, account.uuid account_uuid, account.account_name account_name, account.type account_type, domain.idhttp://domain.id domain_id, domain.uuid domain_uuid, domain.namehttp://domain.name domain_name, domain.path domain_path, projects.idhttp://projects.id project_id, projects.uuid project_uuid, projects.namehttp://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.idhttp://data_center.id data_center_id, data_center.uuid data_center_uuid, data_center.namehttp://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.idhttp://host.id host_id, host.uuid host_uuid, host.namehttp://host.name host_name, host.hypervisor_type, host.cluster_id cluster_id, vm_template.idhttp://vm_template.id template_id, vm_template.uuid template_uuid, service_offering.idhttp://service_offering.id service_offering_id, disk_offering.uuid service_offering_uuid, disk_offering.namehttp://disk_offering.name service_offering_name, nics.idhttp://nics.id nic_id, nics.uuid
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 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 mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.com Date: Wednesday, August 6, 2014 at 11:33 AM To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Cc: Alena Prokharchyk alena.prokharc...@citrix.commailto:alena.prokharc...@citrix.com, Koushik Das koushik@citrix.commailto: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.commailto:nitin.me...@citrix.com wrote: Agreed. Added that information in the bug. On 06/08/14 11:08 AM, Alena Prokharchyk alena.prokharc...@citrix.comjavascript:; 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.comjavascript:; 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.comjavascript:; 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.comjavascript:;] Sent: Wednesday, 6 August 2014 3:37 PM To: dev@cloudstack.apache.orgjavascript:; 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.comjavascript:; 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.idhttp://vm_instance.id id, vm_instance.namehttp://vm_instance.name name, account.idhttp://account.id account_id, account.uuid account_uuid, account.account_name account_name, account.type account_type, domain.idhttp://domain.id domain_id, domain.uuid domain_uuid, domain.namehttp://domain.name domain_name, domain.path domain_path, projects.idhttp://projects.id project_id, projects.uuid project_uuid, projects.namehttp://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.idhttp://data_center.id data_center_id, data_center.uuid data_center_uuid, data_center.namehttp://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.idhttp
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 mike.tutkow...@solidfire.com javascript:_e(%7B%7D,'cvml','mike.tutkow...@solidfire.com'); Date: Wednesday, August 6, 2014 at 11:33 AM To: dev@cloudstack.apache.org javascript:_e(%7B%7D,'cvml','dev@cloudstack.apache.org'); dev@cloudstack.apache.org javascript:_e(%7B%7D,'cvml','dev@cloudstack.apache.org'); Cc: Alena Prokharchyk alena.prokharc...@citrix.com javascript:_e(%7B%7D,'cvml','alena.prokharc...@citrix.com');, Koushik Das koushik@citrix.com javascript:_e(%7B%7D,'cvml','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 javascript:_e(%7B%7D,'cvml','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 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 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 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 nitin.me...@citrix.com 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
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 mike.tutkow...@solidfire.com 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 mike.tutkow...@solidfire.com javascript:_e(%7B%7D,'cvml','mike.tutkow...@solidfire.com'); Date: Wednesday, August 6, 2014 at 11:33 AM To: dev@cloudstack.apache.org javascript:_e(%7B%7D,'cvml','dev@cloudstack.apache.org'); dev@cloudstack.apache.org javascript:_e(%7B%7D,'cvml','dev@cloudstack.apache.org'); Cc: Alena Prokharchyk alena.prokharc...@citrix.com javascript:_e(%7B%7D,'cvml','alena.prokharc...@citrix.com');, Koushik Das koushik@citrix.com javascript:_e(%7B%7D,'cvml','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 javascript:_e(%7B%7D,'cvml','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 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 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 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 nitin.me...@citrix.com 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
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 rohit.ya...@shapeblue.com 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 mike.tutkow...@solidfire.com 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 mike.tutkow...@solidfire.com javascript:_e(%7B%7D,'cvml','mike.tutkow...@solidfire.com'); Date: Wednesday, August 6, 2014 at 11:33 AM To: dev@cloudstack.apache.org javascript:_e(%7B%7D,'cvml','dev@cloudstack.apache.org'); dev@cloudstack.apache.org javascript:_e(%7B%7D,'cvml','dev@cloudstack.apache.org'); Cc: Alena Prokharchyk alena.prokharc...@citrix.com javascript:_e(%7B%7D,'cvml','alena.prokharc...@citrix.com');, Koushik Das koushik@citrix.com javascript:_e(%7B%7D,'cvml','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 javascript:_e(%7B%7D,'cvml','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 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 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 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 nitin.me...@citrix.com 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
