cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Saksham Srivastava <saksham.srivast...@citrix.com>
Subject RE: [DB-CHANGE] Infrastructure tab fails to load with db exception
Date Fri, 08 Aug 2014 08:33:16 GMT
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.tutkowski@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.Karuturi@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.tutkowski@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.Prokharchyk@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.tutkowski@solidfire.com 
> >> <javascript:_e(%7B%7D,'cvml','mike.tutkowski@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.prokharchyk@citrix.com 
> >> <javascript:_e(%7B%7D,'cvml','alena.prokharchyk@citrix.com');>>,
> Koushik
> >> Das <koushik.das@citrix.com
> >> <javascript:_e(%7B%7D,'cvml','koushik.das@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.Mehta@citrix.com 
> >> <javascript:_e(%7B%7D,'cvml','Nitin.Mehta@citrix.com');>> wrote:
> >>
> >>> Agreed. Added that information in the bug.
> >>>
> >>> On 06/08/14 11:08 AM, "Alena Prokharchyk" <
> Alena.Prokharchyk@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.Mehta@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.das@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.srivastava@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.mehta@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.tutkowski@solidfire.com
> >> <javascript:_e(%7B%7D,'cvml','mike.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play>*™*
Mime
View raw message