cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@gmail.com>
Subject Re: [DB-CHANGE] Infrastructure tab fails to load with db exception
Date Thu, 07 Aug 2014 08:18:43 GMT
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.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>*™*
>



-- 
Daan

Mime
View raw message