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, > >>>>>> 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* > >> *Senior CloudStack Developer, SolidFire Inc.* > >> e: mike.tutkow...@solidfire.com > >> <javascript:_e(%7B%7D,'cvml','mike.tutkow...@solidfire.com');> > >> o: 303.746.7302 > >> Advancing the way the world uses the cloud > >> <http://solidfire.com/solution/overview/?video=play>*™* > >> > >> > > > > -- > > *Mike Tutkowski* > > *Senior CloudStack Developer, SolidFire Inc.* > > e: mike.tutkow...@solidfire.com > > o: 303.746.7302 > > Advancing the way the world uses the cloud > > <http://solidfire.com/solution/overview/?video=play>*™* > > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud <http://solidfire.com/solution/overview/?video=play>*™*
