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,
>> >>>>>>       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>*™*



-- 
Daan

Reply via email to