From didi at redhat.com  Sun Mar  2 09:32:47 2014
From: didi at redhat.com (Yedidyah Bar David)
Date: Sun, 2 Mar 2014 04:32:47 -0500 (EST)
Subject: [Engine-devel] hosted-engine rebooting in the middle of setup (was:
 [vdsm] [Users] [ANN] oVirt 3.4.0 Release Candidate is now available)
In-Reply-To: <05A42C7A-7A44-405D-849C-BDCF233469AB@zenfire.com>
References: <5310B530.6090504@redhat.com>
	<05A42C7A-7A44-405D-849C-BDCF233469AB@zenfire.com>
Message-ID: <340077152.10472996.1393752767799.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Darrell Budic" <darrell.budic at zenfire.com>
> To: "Sandro Bonazzola" <sbonazzo at redhat.com>
> Cc: announce at ovirt.org, "engine-devel" <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>, Users at ovirt.org, "VDSM
> Project Development" <vdsm-devel at lists.fedorahosted.org>
> Sent: Saturday, March 1, 2014 1:56:23 AM
> Subject: Re: [vdsm] [Users] [ANN] oVirt 3.4.0 Release Candidate is now	available
> 
> Started testing this on two self-hosted clusters, with mixed results. There
> were updates from 3.4.0 beta 3.
> 
> On both, got informed the system was going to reboot in 2 minutes while it
> was still installing yum updates.
> 
> On the faster system, the whole update process finished before the 2 minutes
> were up, the VM restarted, and all appears normal.
> 
> On the other, slower cluster, the 2 minutes hit while the yum updates were
> still being installed, and the system rebooted. It continued rebooting every
> 3 minutes or so, and the engine console web pages are not available because
> the engine doesn?t start. it did this at least 3 times before I went ahead
> and reran engine-setup, which completed successfully. The system stopped
> restarting and the web interface was available again. A quick perusal of
> system logs and engine-setup logs didn?t reveal what requested the reboot.
> 
> That was rather impolite of something to do that without warning :) At least
> it was recoverable. Seems like scheduling the reboot while the yum updates
> were still running seems like a poor idea as well.

Can you please post relevant logs?
hosts: /var/log/ovirt-hosted-engine-setup/*, /var/log/ovirt-hosted-engine-ha/*,
/var/log/vdsm/*
engine: /var/log/ovirt-engine/setup/*, /var/log/ovirt-engine/*

You can of course open a bug on bugzilla and attach there logs if you want.

Thanks, and thanks for the report!
-- 
Didi


From alonbl at redhat.com  Sun Mar  2 10:39:16 2014
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sun, 2 Mar 2014 05:39:16 -0500 (EST)
Subject: [Engine-devel] [ATN] ovirt-engine dbscritps cleanup (master)
In-Reply-To: <1928661724.6478064.1393756285235.JavaMail.zimbra@redhat.com>
Message-ID: <1443115816.6478169.1393756756557.JavaMail.zimbra@redhat.com>

Hello All,

The dbscripts of ovirt-engine master were cleaned up, to match other scripts in tree.

Developer visible changes are:

1. Removal of create_schema.sh, upgrade.sh, cleandb.sh, refreshStoredProcedures.sh in favour of single schema.sh script, note the -c parameter.

Usage: ./schema.sh [options]

    -h            - This help text.
    -v            - Turn on verbosity                         (WARNING: lots of output)
    -l LOGFILE    - The logfile for capturing output          (def. )
    -s HOST       - The database servername for the database  (def. localhost)
    -p PORT       - The database port for the database        (def. 5432)
    -u USER       - The username for the database             (def. engine)
    -d DATABASE   - The database name                         (def. engine)
    -m MD5FILE    - Where to store schema MD5 files           (def. )
    -c COMMAND    - Command: apply|refresh|drop
    -t            - Force cleaning tasks and compensation info.

2. Introduction of schema-dev.sh as a wrapper to schema.sh with defaults as a utility for developers.

- always enable md5.
- always enable logging.
- apply command as default.

3. Shell upgrade script is not receives entire settings via DBFUNC_* environment variables.

Regards,
Alon Bar-Lev


From emesika at redhat.com  Sun Mar  2 12:28:00 2014
From: emesika at redhat.com (Eli Mesika)
Date: Sun, 2 Mar 2014 07:28:00 -0500 (EST)
Subject: [Engine-devel] [ATN] ovirt-engine dbscritps cleanup (master)
In-Reply-To: <1443115816.6478169.1393756756557.JavaMail.zimbra@redhat.com>
References: <1443115816.6478169.1393756756557.JavaMail.zimbra@redhat.com>
Message-ID: <1581639761.11798491.1393763280350.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>, "infra" <infra at ovirt.org>
> Cc: "Eli Mesika" <emesika at redhat.com>
> Sent: Sunday, March 2, 2014 12:39:16 PM
> Subject: [ATN] ovirt-engine dbscritps cleanup (master)
> 
> Hello All,
> 
> The dbscripts of ovirt-engine master were cleaned up, to match other scripts
> in tree.
> 
> Developer visible changes are:
> 
> 1. Removal of create_schema.sh, upgrade.sh, cleandb.sh,
> refreshStoredProcedures.sh in favour of single schema.sh script, note the -c
> parameter.
> 
> Usage: ./schema.sh [options]
> 
>     -h            - This help text.
>     -v            - Turn on verbosity                         (WARNING: lots
>     of output)
>     -l LOGFILE    - The logfile for capturing output          (def. )
>     -s HOST       - The database servername for the database  (def.
>     localhost)
>     -p PORT       - The database port for the database        (def. 5432)
>     -u USER       - The username for the database             (def. engine)
>     -d DATABASE   - The database name                         (def. engine)
>     -m MD5FILE    - Where to store schema MD5 files           (def. )
>     -c COMMAND    - Command: apply|refresh|drop
>     -t            - Force cleaning tasks and compensation info.
> 
> 2. Introduction of schema-dev.sh as a wrapper to schema.sh with defaults as a
> utility for developers.
> 
> - always enable md5.
> - always enable logging.
> - apply command as default.

you should use this for create new DB or upgrade the existing one with the same call

Example : ./schema-dev.sh -u engine -d engine

This will create the engine DB if not exists and upgrade the DB if engine database exists 


> 
> 3. Shell upgrade script is not receives entire settings via DBFUNC_*
> environment variables.
> 
> Regards,
> Alon Bar-Lev
> 


From iheim at redhat.com  Sun Mar  2 19:36:47 2014
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 02 Mar 2014 21:36:47 +0200
Subject: [Engine-devel] ReST API docs
In-Reply-To: <CAKpxQk1NxUmADrF2hXedZSqfF=CC8avX=ScDJdtpb8nYmivnJQ@mail.gmail.com>
References: <CAKpxQk1NxUmADrF2hXedZSqfF=CC8avX=ScDJdtpb8nYmivnJQ@mail.gmail.com>
Message-ID: <5313884F.4020007@redhat.com>

On 02/28/2014 08:21 PM, Vikas Kokare wrote:
> Only
> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.0/
> has the ReST API document available, and not corresponding versions for
> 3.1, 3.2 and 3.3.
>
> I see differences in 3.0 ReST data structure and what is returned back
> from RHEVM 3.2 installation.
>
> Please point to the REST API Guide for RHEVM 3.2.

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.3/html/Developer_Guide/index.html

>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>



From iheim at redhat.com  Sun Mar  2 21:46:00 2014
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 02 Mar 2014 23:46:00 +0200
Subject: [Engine-devel] Install rhevm-guest-agent on SLES guest
In-Reply-To: <1517939.HdhaHoBtyL@awels>
References: <CAKpxQk3Ocibcjj8wOaGModGgK7tiiNg8HRR4z4UZermBCx4-ug@mail.gmail.com>
	<1517939.HdhaHoBtyL@awels>
Message-ID: <5313A698.3000303@redhat.com>

On 02/21/2014 03:43 PM, Alexander Wels wrote:
> Doesn't look like the package exists yet, there is an open bug for it:
> https://bugzilla.redhat.com/show_bug.cgi?id=1043471
>
> On Friday, February 21, 2014 11:00:40 AM Vikas Kokare wrote:
>> We want to install the rhevm-guest-agent package on a virtual machine with
>> Suse Linux as the guest OS. The RHEVM 3.2 documentation provides install
>> instructions for RHEL and Windows guests but not for Suse Linux. This agent
>> is important to monitor virtual resources on guest machines, hence the need.
>> How can this be done?
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>

is the suse one relevant for this?
http://www.ovirt.org/Feature/GuestAgentOpenSUSE


From liran.zelkha at gmail.com  Mon Mar  3 12:54:28 2014
From: liran.zelkha at gmail.com (Liran Zelkha)
Date: Mon, 3 Mar 2014 14:54:28 +0200
Subject: [Engine-devel] Usage of Dynamic Queries
Message-ID: <CAJ3aYLeiCKM0YYyUZCXB0GFM-LeL18QBHmcVJihx2coCD91=9A@mail.gmail.com>

Hi All,

As part of an ongoing effort to improve oVirt performance, we're trying to
reduce the number of Dynamic Queries usage in the code, and replace it with
Postgres stored procedures. You wouldn't believe the performance gain.

Please consider before making use of the Dynamic Queries feature - it
should ONLY be used for places where users can enter search queries - and
not for any other usage.

Thanks.
Liran
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140303/e9d03c60/attachment.html>

From sbonazzo at redhat.com  Mon Mar  3 14:25:41 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Mon, 03 Mar 2014 15:25:41 +0100
Subject: [Engine-devel] oVirt 3.4.0 branch creation
Message-ID: <531490E5.8060608@redhat.com>

Hi,
we're going to create ovirt-engine-3.4.0 branch tomorrow morning 09:00 UTC.
oVirt 3.4.1 development will continue on ovirt-engine-3.4 branch.
Critical fixes for oVirt 3.4.0 GA will need to be pushed to 3.4.0 branch too starting tomorrow morning 09:00 UTC.
Thanks,

-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From danken at redhat.com  Mon Mar  3 14:28:27 2014
From: danken at redhat.com (Dan Kenigsberg)
Date: Mon, 3 Mar 2014 14:28:27 +0000
Subject: [Engine-devel] Asynchronous tasks for live merge
In-Reply-To: <20140228143016.GC29304@redhat.com>
References: <20140228143016.GC29304@redhat.com>
Message-ID: <20140303142827.GG17073@redhat.com>

On Fri, Feb 28, 2014 at 09:30:16AM -0500, Adam Litke wrote:
> Hi all,
> 
> As part of our plan to support live merging of VM disk snapshots it
> seems we will need a new form of asynchronous task in ovirt-engine.  I
> am aware of AsyncTaskManager but it seems to be limited to managing
> SPM tasks.  For live merge, we are going to need something called
> VmTasks since the async command can be run only on the host that
> currently runs the VM.
> 
> The way I see this working from an engine perspective is:
> 1. RemoveSnapshotCommand in bll is invoked as usual but since the VM is
>   found to be up, we activate an alternative live merge flow.
> 2. We submit a LiveMerge VDS Command for each impacted disk.  This is
>   an asynchronous command which we need to monitor for completion.
> 3. A VmJob is inserted into the DB so we'll remember to handle it.
> 4. The VDS Broker monitors the operation via an extension to the
>   already collected VmStatistics data.  Vdsm will report active Block
>   Jobs only.  Once the job stops (in error or success) it will cease
>   to be reported by vdsm and engine will know to proceed.

You describe a reasonable way for Vdsm to report whether an async
operation has finished. However, may we instead use the oportunity to
introduce generic "hsm" tasks?

I suggest to have something loosely modeled on posix fork/wait.

- Engine asks Vdsm to start an API verb asynchronously and supplies a
  uuid. This is unlike fork(2), where the system chooses the pid, but
  that's required so that Engine could tell if the command has reached
  Vdsm in case of a network error.

- Engine may monitor the task (a-la wait(WNOHANG))

- When the task is finished, Engine may collect its result (a-la wait).
  Until that happens, Vdsm must report the task forever; restart or
  upgrade are no excuses. On reboot, though, all tasks are forgotten, so
  Engine may stop monitoring tasks on a fenced host.

This may be an over kill for your use case, but it would come useful for
other cases. In particular, setupNetwork returns before it is completely
done, since dhcp address acquisition may take too much time. Engine may
poll getVdsCaps to see when it's done (or timeout), but it would be
nicer to have a generic mechanism that can serve us all.

Note that I'm suggesting a completely new task framwork, at least on
Vdsm side, as the current one (with its broken persistence, arcane
states and never-reliable rollback) is beyond redemption, imho.

> 5. When the job has completed, VDS Broker raises an event up to bll.
>   Maybe this could be done via VmJobDAO on the stored VmJob?
> 6. Bll receives the event and issues a series of VDS commands to
>   complete the operation:
>   a) Verify the new image chain matches our expectations (the snap is
>      no longer present in the chain).
>   b) Delete the snapshot volume
>   c) Remove the VmJob from the DB
> 
> Could you guys review this proposed flow for sanity?  The main
> conceptual gaps I am left with concern #5 and #6.  What is the
> appropriate way for VDSBroker to communicate with BLL?  Is there an
> event mechanism I can explore or should I use the database?  I am
> leaning toward the database because it is persistent and will ensure
> #6 gets completed even if engine is restarted somewhere in the middle.
> For #6, is there an existing polling / event loop in bll that I can
> plug into?
> 
> Thanks in advance for taking the time to think about this flow and for
> providing your insights!


From iheim at redhat.com  Mon Mar  3 14:36:34 2014
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 03 Mar 2014 16:36:34 +0200
Subject: [Engine-devel] Asynchronous tasks for live merge
In-Reply-To: <20140303142827.GG17073@redhat.com>
References: <20140228143016.GC29304@redhat.com>
	<20140303142827.GG17073@redhat.com>
Message-ID: <53149372.2050203@redhat.com>

On 03/03/2014 04:28 PM, Dan Kenigsberg wrote:
> On Fri, Feb 28, 2014 at 09:30:16AM -0500, Adam Litke wrote:
>> Hi all,
>>
>> As part of our plan to support live merging of VM disk snapshots it
>> seems we will need a new form of asynchronous task in ovirt-engine.  I
>> am aware of AsyncTaskManager but it seems to be limited to managing
>> SPM tasks.  For live merge, we are going to need something called
>> VmTasks since the async command can be run only on the host that
>> currently runs the VM.
>>
>> The way I see this working from an engine perspective is:
>> 1. RemoveSnapshotCommand in bll is invoked as usual but since the VM is
>>    found to be up, we activate an alternative live merge flow.
>> 2. We submit a LiveMerge VDS Command for each impacted disk.  This is
>>    an asynchronous command which we need to monitor for completion.
>> 3. A VmJob is inserted into the DB so we'll remember to handle it.
>> 4. The VDS Broker monitors the operation via an extension to the
>>    already collected VmStatistics data.  Vdsm will report active Block
>>    Jobs only.  Once the job stops (in error or success) it will cease
>>    to be reported by vdsm and engine will know to proceed.
>
> You describe a reasonable way for Vdsm to report whether an async
> operation has finished. However, may we instead use the oportunity to
> introduce generic "hsm" tasks?
>
> I suggest to have something loosely modeled on posix fork/wait.
>
> - Engine asks Vdsm to start an API verb asynchronously and supplies a
>    uuid. This is unlike fork(2), where the system chooses the pid, but
>    that's required so that Engine could tell if the command has reached
>    Vdsm in case of a network error.
>
> - Engine may monitor the task (a-la wait(WNOHANG))
>
> - When the task is finished, Engine may collect its result (a-la wait).
>    Until that happens, Vdsm must report the task forever; restart or
>    upgrade are no excuses. On reboot, though, all tasks are forgotten, so
>    Engine may stop monitoring tasks on a fenced host.
>
> This may be an over kill for your use case, but it would come useful for
> other cases. In particular, setupNetwork returns before it is completely
> done, since dhcp address acquisition may take too much time. Engine may
> poll getVdsCaps to see when it's done (or timeout), but it would be
> nicer to have a generic mechanism that can serve us all.
>
> Note that I'm suggesting a completely new task framwork, at least on
> Vdsm side, as the current one (with its broken persistence, arcane
> states and never-reliable rollback) is beyond redemption, imho.
>
>> 5. When the job has completed, VDS Broker raises an event up to bll.
>>    Maybe this could be done via VmJobDAO on the stored VmJob?
>> 6. Bll receives the event and issues a series of VDS commands to
>>    complete the operation:
>>    a) Verify the new image chain matches our expectations (the snap is
>>       no longer present in the chain).
>>    b) Delete the snapshot volume
>>    c) Remove the VmJob from the DB
>>
>> Could you guys review this proposed flow for sanity?  The main
>> conceptual gaps I am left with concern #5 and #6.  What is the
>> appropriate way for VDSBroker to communicate with BLL?  Is there an
>> event mechanism I can explore or should I use the database?  I am
>> leaning toward the database because it is persistent and will ensure
>> #6 gets completed even if engine is restarted somewhere in the middle.
>> For #6, is there an existing polling / event loop in bll that I can
>> plug into?
>>
>> Thanks in advance for taking the time to think about this flow and for
>> providing your insights!
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>

the way i read Adam's proposal, there is no "task" entity at vdsm side 
to monitor, rather the state of the object the operation is performed on 
(similar to CreateVM, where the engine monitors the state of the VM, 
rather than the CreateVM request).


From vfeenstr at redhat.com  Mon Mar  3 14:44:40 2014
From: vfeenstr at redhat.com (Vinzenz Feenstra)
Date: Mon, 03 Mar 2014 15:44:40 +0100
Subject: [Engine-devel] Install rhevm-guest-agent on SLES guest
In-Reply-To: <5313A698.3000303@redhat.com>
References: <CAKpxQk3Ocibcjj8wOaGModGgK7tiiNg8HRR4z4UZermBCx4-ug@mail.gmail.com>	<1517939.HdhaHoBtyL@awels>
	<5313A698.3000303@redhat.com>
Message-ID: <53149558.3030104@redhat.com>

On 03/02/2014 10:46 PM, Itamar Heim wrote:
> On 02/21/2014 03:43 PM, Alexander Wels wrote:
>> Doesn't look like the package exists yet, there is an open bug for it:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1043471
>>
>> On Friday, February 21, 2014 11:00:40 AM Vikas Kokare wrote:
>>> We want to install the rhevm-guest-agent package on a virtual 
>>> machine with
>>> Suse Linux as the guest OS. The RHEVM 3.2 documentation provides 
>>> install
>>> instructions for RHEL and Windows guests but not for Suse Linux. 
>>> This agent
>>> is important to monitor virtual resources on guest machines, hence 
>>> the need.
>>> How can this be done?
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>
> is the suse one relevant for this?
> http://www.ovirt.org/Feature/GuestAgentOpenSUSE
Only if it is openSUSE, SLES won't currently work though.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel


-- 
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com



From alitke at redhat.com  Mon Mar  3 14:51:15 2014
From: alitke at redhat.com (Adam Litke)
Date: Mon, 3 Mar 2014 09:51:15 -0500
Subject: [Engine-devel] Asynchronous tasks for live merge
In-Reply-To: <20140303142827.GG17073@redhat.com>
References: <20140228143016.GC29304@redhat.com>
	<20140303142827.GG17073@redhat.com>
Message-ID: <20140303145115.GC356@redhat.com>

On 03/03/14 14:28 +0000, Dan Kenigsberg wrote:
>On Fri, Feb 28, 2014 at 09:30:16AM -0500, Adam Litke wrote:
>> Hi all,
>>
>> As part of our plan to support live merging of VM disk snapshots it
>> seems we will need a new form of asynchronous task in ovirt-engine.  I
>> am aware of AsyncTaskManager but it seems to be limited to managing
>> SPM tasks.  For live merge, we are going to need something called
>> VmTasks since the async command can be run only on the host that
>> currently runs the VM.
>>
>> The way I see this working from an engine perspective is:
>> 1. RemoveSnapshotCommand in bll is invoked as usual but since the VM is
>>   found to be up, we activate an alternative live merge flow.
>> 2. We submit a LiveMerge VDS Command for each impacted disk.  This is
>>   an asynchronous command which we need to monitor for completion.
>> 3. A VmJob is inserted into the DB so we'll remember to handle it.
>> 4. The VDS Broker monitors the operation via an extension to the
>>   already collected VmStatistics data.  Vdsm will report active Block
>>   Jobs only.  Once the job stops (in error or success) it will cease
>>   to be reported by vdsm and engine will know to proceed.
>
>You describe a reasonable way for Vdsm to report whether an async
>operation has finished. However, may we instead use the oportunity to
>introduce generic "hsm" tasks?

Sure, I am happy to have that conversation :)  If I understand
correctly, HSM tasks, while ideal, might be too complex to get right
and would block the Live Merge feature for longer than we would like.
Has anyone looked into what it would take to implement a HSM Tasks
framework like this in vdsm?  Are there any WIP implementations?  If
the scope of this is not too big, it can be completed relatively
quickly, and the resulting implementation would cover all known use
cases, then this could be worth it.  It's important to support Live
Merge soon.

Regarding deprecation of the current tasks API:  Could your suggested
HSM Tasks framework be extended to cover SPM/SDM tasks as well?  I
would hope that a it could.  In that case, we could look forward to a
unified async task architecture in vdsm.

>I suggest to have something loosely modeled on posix fork/wait.
>
>- Engine asks Vdsm to start an API verb asynchronously and supplies a
>  uuid. This is unlike fork(2), where the system chooses the pid, but
>  that's required so that Engine could tell if the command has reached
>  Vdsm in case of a network error.
>
>- Engine may monitor the task (a-la wait(WNOHANG))

Allon has communicated a desire to limit engine-side polling.  Perhaps
the active tasks could be added to the host stats?

>- When the task is finished, Engine may collect its result (a-la wait).
>  Until that happens, Vdsm must report the task forever; restart or
>  upgrade are no excuses. On reboot, though, all tasks are forgotten, so
>  Engine may stop monitoring tasks on a fenced host.

This could be a good comprimise.  I hate the idea of requiring engine
to play janitor and clean up stale vdsm data, but there is not much
better of a way to do it.  Allowing reboot to auto-clear tasks will at
least provide some backstop to how long tasks could pile up if
forgotten.

>This may be an over kill for your use case, but it would come useful for
>other cases. In particular, setupNetwork returns before it is completely
>done, since dhcp address acquisition may take too much time. Engine may
>poll getVdsCaps to see when it's done (or timeout), but it would be
>nicer to have a generic mechanism that can serve us all.

If we were to consider this, I would want to vet the architecture
against all known use cases for tasks to make sure we don't need to
create a new framework in 3 months.

>Note that I'm suggesting a completely new task framwork, at least on
>Vdsm side, as the current one (with its broken persistence, arcane
>states and never-reliable rollback) is beyond redemption, imho.

Are we okay with abandoning vdsm-side rollback entirely as we move
forward?  Won't that be a regression for at least some error flows
(especially in the realm of SPM tasks)?

>> 5. When the job has completed, VDS Broker raises an event up to bll.
>>   Maybe this could be done via VmJobDAO on the stored VmJob?
>> 6. Bll receives the event and issues a series of VDS commands to
>>   complete the operation:
>>   a) Verify the new image chain matches our expectations (the snap is
>>      no longer present in the chain).
>>   b) Delete the snapshot volume
>>   c) Remove the VmJob from the DB
>>
>> Could you guys review this proposed flow for sanity?  The main
>> conceptual gaps I am left with concern #5 and #6.  What is the
>> appropriate way for VDSBroker to communicate with BLL?  Is there an
>> event mechanism I can explore or should I use the database?  I am
>> leaning toward the database because it is persistent and will ensure
>> #6 gets completed even if engine is restarted somewhere in the middle.
>> For #6, is there an existing polling / event loop in bll that I can
>> plug into?
>>
>> Thanks in advance for taking the time to think about this flow and for
>> providing your insights!

-- 
Adam Litke


From iheim at redhat.com  Mon Mar  3 14:25:07 2014
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 03 Mar 2014 16:25:07 +0200
Subject: [Engine-devel] oVirt February 2014 Updates
Message-ID: <531490C3.8060904@redhat.com>

1. Releases

- oVirt 3.3.3 was released early in the month:
   http://www.ovirt.org/OVirt_3.3.3_release_notes

- oVirt 3.3.4 about to release.
   http://www.ovirt.org/OVirt_3.3.4_release_notes

- oVirt 3.4.0 about to release!

2. Events
- Leonardo Vaz is organizing ovirt attendance at FISL15, the largest
   FOSS conference in LATAM which will happen from 7th to 10th of May in
   Porto Alegre, Brazil:
   http://softwarelivre.org/fisl15

- Allon Mureinik gave a presentation on DR with oVirt at devconf.cz
   http://www.slideshare.net/AllonMureinik/dev-conf-ovirt-dr

- oVirt workshop in korea slides (korean)
   http://www.slideshare.net/rogan/20140208-ovirtkorea-01
   https://www.facebook.com/groups/ovirt.korea

- Rogan also presented oVirt integration with OpenStack in OpenStack
   day in Korea
   http://alturl.com/m3jnx

- Pat Pierson posted on basic network setup
   http://izen.ghostpeppersrus.com/setting-up-networks/

- Fosdem 2014 sessions (slides and videos) are at:
   http://www.ovirt.org/FOSDEM_2014

- and some at Infrastructure.Next Ghent the week after forsdem.

3. oVirt Activity (software)

- oVirt Jenkins plugin by Dustin Kut Moy Cheung to control VM slaves
   managed by ovirt/RHEV
   https://github.com/thescouser89/ovirt-slaves-plugin

- Opaque oVirt/RHEV/Proxmox client and source code released
    https://play.google.com/store/apps/details?id=com.undatech.opaque

- great to see the NUMA push from HP:
   http://www.ovirt.org/Features/NUMA_and_Virtual_NUMA
   http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA

4. oVirt Activity (blogs, preso's)

- oVirt's has been accepted as a mentoring project for the Google
   Summer of Code 2014.

- Oved Ourfali posted on "Importing Glance images as oVirt templates"
   http://alturl.com/h7xid

- v2v had seen many active discussions. here's a post by Jon Archer on
   how to Import regular kvm image to oVirt or RHEV
   http://jonarcher.info/2014/02/import-regular-kvm-image-ovirt-rhev/

- great reviews on amazon.com for "Getting Started with oVirt 3.3"
   http://alturl.com/5rk2p

- oVirt Deep Dive 3.3 slides (Chinese)
   http://www.slideshare.net/mobile/johnwoolee/ovirt-deep-dive#

- oVirt intro video (russian)
   http://alturl.com/it546

- how to install oVirt 3.3 on CentOS 6.5
   http://www.youtube.com/watch?v=5i5ilSKsmbo

5. Related
- NetApp GA'd their Virtual Storage Console for RHEV, which is
   implemented as an oVirt UI plugin (and then some)
   http://captainkvm.com/2014/02/vsc-for-rhev-is-ga-today/#more-660


From alitke at redhat.com  Mon Mar  3 14:56:56 2014
From: alitke at redhat.com (Adam Litke)
Date: Mon, 3 Mar 2014 09:56:56 -0500
Subject: [Engine-devel] Asynchronous tasks for live merge
In-Reply-To: <53149372.2050203@redhat.com>
References: <20140228143016.GC29304@redhat.com>
	<20140303142827.GG17073@redhat.com> <53149372.2050203@redhat.com>
Message-ID: <20140303145656.GD356@redhat.com>

On 03/03/14 16:36 +0200, Itamar Heim wrote:
>On 03/03/2014 04:28 PM, Dan Kenigsberg wrote:
>>On Fri, Feb 28, 2014 at 09:30:16AM -0500, Adam Litke wrote:
>>>Hi all,
>>>
>>>As part of our plan to support live merging of VM disk snapshots it
>>>seems we will need a new form of asynchronous task in ovirt-engine.  I
>>>am aware of AsyncTaskManager but it seems to be limited to managing
>>>SPM tasks.  For live merge, we are going to need something called
>>>VmTasks since the async command can be run only on the host that
>>>currently runs the VM.
>>>
>>>The way I see this working from an engine perspective is:
>>>1. RemoveSnapshotCommand in bll is invoked as usual but since the VM is
>>>   found to be up, we activate an alternative live merge flow.
>>>2. We submit a LiveMerge VDS Command for each impacted disk.  This is
>>>   an asynchronous command which we need to monitor for completion.
>>>3. A VmJob is inserted into the DB so we'll remember to handle it.
>>>4. The VDS Broker monitors the operation via an extension to the
>>>   already collected VmStatistics data.  Vdsm will report active Block
>>>   Jobs only.  Once the job stops (in error or success) it will cease
>>>   to be reported by vdsm and engine will know to proceed.
>>
>>You describe a reasonable way for Vdsm to report whether an async
>>operation has finished. However, may we instead use the oportunity to
>>introduce generic "hsm" tasks?
>>
>>I suggest to have something loosely modeled on posix fork/wait.
>>
>>- Engine asks Vdsm to start an API verb asynchronously and supplies a
>>   uuid. This is unlike fork(2), where the system chooses the pid, but
>>   that's required so that Engine could tell if the command has reached
>>   Vdsm in case of a network error.
>>
>>- Engine may monitor the task (a-la wait(WNOHANG))
>>
>>- When the task is finished, Engine may collect its result (a-la wait).
>>   Until that happens, Vdsm must report the task forever; restart or
>>   upgrade are no excuses. On reboot, though, all tasks are forgotten, so
>>   Engine may stop monitoring tasks on a fenced host.
>>
>>This may be an over kill for your use case, but it would come useful for
>>other cases. In particular, setupNetwork returns before it is completely
>>done, since dhcp address acquisition may take too much time. Engine may
>>poll getVdsCaps to see when it's done (or timeout), but it would be
>>nicer to have a generic mechanism that can serve us all.
>>
>>Note that I'm suggesting a completely new task framwork, at least on
>>Vdsm side, as the current one (with its broken persistence, arcane
>>states and never-reliable rollback) is beyond redemption, imho.
>>
>>>5. When the job has completed, VDS Broker raises an event up to bll.
>>>   Maybe this could be done via VmJobDAO on the stored VmJob?
>>>6. Bll receives the event and issues a series of VDS commands to
>>>   complete the operation:
>>>   a) Verify the new image chain matches our expectations (the snap is
>>>      no longer present in the chain).
>>>   b) Delete the snapshot volume
>>>   c) Remove the VmJob from the DB
>>>
>>>Could you guys review this proposed flow for sanity?  The main
>>>conceptual gaps I am left with concern #5 and #6.  What is the
>>>appropriate way for VDSBroker to communicate with BLL?  Is there an
>>>event mechanism I can explore or should I use the database?  I am
>>>leaning toward the database because it is persistent and will ensure
>>>#6 gets completed even if engine is restarted somewhere in the middle.
>>>For #6, is there an existing polling / event loop in bll that I can
>>>plug into?
>>>
>>>Thanks in advance for taking the time to think about this flow and for
>>>providing your insights!
>>_______________________________________________
>>Engine-devel mailing list
>>Engine-devel at ovirt.org
>>http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>
>the way i read Adam's proposal, there is no "task" entity at vdsm side 
>to monitor, rather the state of the object the operation is performed 
>on (similar to CreateVM, where the engine monitors the state of the 
>VM, rather than the CreateVM request).

Yeah, we use the term "job" in order to avoid assumptions and
implications (ie. rollback/cancel, persistence) that come with the
word "task".  "Job" essentially means "libvirt Block Job", but I am
trying to allow for extension in the future.  Vdsm would collect block
job information for devices it expects to have active block jobs and
report them all under a single structure in the VM statistics.  There
would be no persistence of information so when a libvirt block job
goes poof, vdsm will stop reporting it.

-- 
Adam Litke


From danken at redhat.com  Mon Mar  3 15:53:02 2014
From: danken at redhat.com (Dan Kenigsberg)
Date: Mon, 3 Mar 2014 15:53:02 +0000
Subject: [Engine-devel] Asynchronous tasks for live merge
In-Reply-To: <20140303145656.GD356@redhat.com>
References: <20140228143016.GC29304@redhat.com>
	<20140303142827.GG17073@redhat.com> <53149372.2050203@redhat.com>
	<20140303145656.GD356@redhat.com>
Message-ID: <20140303155302.GH17073@redhat.com>

On Mon, Mar 03, 2014 at 09:56:56AM -0500, Adam Litke wrote:
> On 03/03/14 16:36 +0200, Itamar Heim wrote:
> >On 03/03/2014 04:28 PM, Dan Kenigsberg wrote:
> >>On Fri, Feb 28, 2014 at 09:30:16AM -0500, Adam Litke wrote:
> >>>Hi all,
> >>>
> >>>As part of our plan to support live merging of VM disk snapshots it
> >>>seems we will need a new form of asynchronous task in ovirt-engine.  I
> >>>am aware of AsyncTaskManager but it seems to be limited to managing
> >>>SPM tasks.  For live merge, we are going to need something called
> >>>VmTasks since the async command can be run only on the host that
> >>>currently runs the VM.
> >>>
> >>>The way I see this working from an engine perspective is:
> >>>1. RemoveSnapshotCommand in bll is invoked as usual but since the VM is
> >>>  found to be up, we activate an alternative live merge flow.
> >>>2. We submit a LiveMerge VDS Command for each impacted disk.  This is
> >>>  an asynchronous command which we need to monitor for completion.
> >>>3. A VmJob is inserted into the DB so we'll remember to handle it.
> >>>4. The VDS Broker monitors the operation via an extension to the
> >>>  already collected VmStatistics data.  Vdsm will report active Block
> >>>  Jobs only.  Once the job stops (in error or success) it will cease
> >>>  to be reported by vdsm and engine will know to proceed.
> >>
> >>You describe a reasonable way for Vdsm to report whether an async
> >>operation has finished. However, may we instead use the oportunity to
> >>introduce generic "hsm" tasks?
> >>
> >>I suggest to have something loosely modeled on posix fork/wait.
> >>
> >>- Engine asks Vdsm to start an API verb asynchronously and supplies a
> >>  uuid. This is unlike fork(2), where the system chooses the pid, but
> >>  that's required so that Engine could tell if the command has reached
> >>  Vdsm in case of a network error.
> >>
> >>- Engine may monitor the task (a-la wait(WNOHANG))
> >>
> >>- When the task is finished, Engine may collect its result (a-la wait).
> >>  Until that happens, Vdsm must report the task forever; restart or
> >>  upgrade are no excuses. On reboot, though, all tasks are forgotten, so
> >>  Engine may stop monitoring tasks on a fenced host.
> >>
> >>This may be an over kill for your use case, but it would come useful for
> >>other cases. In particular, setupNetwork returns before it is completely
> >>done, since dhcp address acquisition may take too much time. Engine may
> >>poll getVdsCaps to see when it's done (or timeout), but it would be
> >>nicer to have a generic mechanism that can serve us all.
> >>
> >>Note that I'm suggesting a completely new task framwork, at least on
> >>Vdsm side, as the current one (with its broken persistence, arcane
> >>states and never-reliable rollback) is beyond redemption, imho.
> >>
> >>>5. When the job has completed, VDS Broker raises an event up to bll.
> >>>  Maybe this could be done via VmJobDAO on the stored VmJob?
> >>>6. Bll receives the event and issues a series of VDS commands to
> >>>  complete the operation:
> >>>  a) Verify the new image chain matches our expectations (the snap is
> >>>     no longer present in the chain).
> >>>  b) Delete the snapshot volume
> >>>  c) Remove the VmJob from the DB
> >>>
> >>>Could you guys review this proposed flow for sanity?  The main
> >>>conceptual gaps I am left with concern #5 and #6.  What is the
> >>>appropriate way for VDSBroker to communicate with BLL?  Is there an
> >>>event mechanism I can explore or should I use the database?  I am
> >>>leaning toward the database because it is persistent and will ensure
> >>>#6 gets completed even if engine is restarted somewhere in the middle.
> >>>For #6, is there an existing polling / event loop in bll that I can
> >>>plug into?
> >>>
> >>>Thanks in advance for taking the time to think about this flow and for
> >>>providing your insights!
> >>_______________________________________________
> >>Engine-devel mailing list
> >>Engine-devel at ovirt.org
> >>http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> >
> >the way i read Adam's proposal, there is no "task" entity at vdsm
> >side to monitor, rather the state of the object the operation is
> >performed on (similar to CreateVM, where the engine monitors the
> >state of the VM, rather than the CreateVM request).
> 
> Yeah, we use the term "job" in order to avoid assumptions and
> implications (ie. rollback/cancel, persistence) that come with the
> word "task".  "Job" essentially means "libvirt Block Job", but I am
> trying to allow for extension in the future.  Vdsm would collect block
> job information for devices it expects to have active block jobs and
> report them all under a single structure in the VM statistics.  There
> would be no persistence of information so when a libvirt block job
> goes poof, vdsm will stop reporting it.

I know, but since we need someothing quite similar for setupNetwork, I'm
suggesting to have have something generic enough to fulfill both use
cases. Instead of having one part of Engine poll for pending VmJobs, and
another polling on whether a network finally got its address from the
dhcp server. As Itamar said, a very similar logic exists for migration,
and for starting up a new VM.

I'm not suggesting rollback, cancelation or fancy persistence. And not
even a progress indication, although I'm pretty sure it would come up
handy in the future.


From danken at redhat.com  Mon Mar  3 16:23:33 2014
From: danken at redhat.com (Dan Kenigsberg)
Date: Mon, 3 Mar 2014 16:23:33 +0000
Subject: [Engine-devel] Asynchronous tasks for live merge
In-Reply-To: <20140303145115.GC356@redhat.com>
References: <20140228143016.GC29304@redhat.com>
	<20140303142827.GG17073@redhat.com>
	<20140303145115.GC356@redhat.com>
Message-ID: <20140303162333.GI17073@redhat.com>

On Mon, Mar 03, 2014 at 09:51:15AM -0500, Adam Litke wrote:
> On 03/03/14 14:28 +0000, Dan Kenigsberg wrote:
> >On Fri, Feb 28, 2014 at 09:30:16AM -0500, Adam Litke wrote:
> >>Hi all,
> >>
> >>As part of our plan to support live merging of VM disk snapshots it
> >>seems we will need a new form of asynchronous task in ovirt-engine.  I
> >>am aware of AsyncTaskManager but it seems to be limited to managing
> >>SPM tasks.  For live merge, we are going to need something called
> >>VmTasks since the async command can be run only on the host that
> >>currently runs the VM.
> >>
> >>The way I see this working from an engine perspective is:
> >>1. RemoveSnapshotCommand in bll is invoked as usual but since the VM is
> >>  found to be up, we activate an alternative live merge flow.
> >>2. We submit a LiveMerge VDS Command for each impacted disk.  This is
> >>  an asynchronous command which we need to monitor for completion.
> >>3. A VmJob is inserted into the DB so we'll remember to handle it.
> >>4. The VDS Broker monitors the operation via an extension to the
> >>  already collected VmStatistics data.  Vdsm will report active Block
> >>  Jobs only.  Once the job stops (in error or success) it will cease
> >>  to be reported by vdsm and engine will know to proceed.
> >
> >You describe a reasonable way for Vdsm to report whether an async
> >operation has finished. However, may we instead use the oportunity to
> >introduce generic "hsm" tasks?
> 
> Sure, I am happy to have that conversation :)  If I understand
> correctly, HSM tasks, while ideal, might be too complex to get right
> and would block the Live Merge feature for longer than we would like.
> Has anyone looked into what it would take to implement a HSM Tasks
> framework like this in vdsm?  Are there any WIP implementations?  If
> the scope of this is not too big, it can be completed relatively
> quickly, and the resulting implementation would cover all known use
> cases, then this could be worth it.  It's important to support Live
> Merge soon.
> 
> Regarding deprecation of the current tasks API:  Could your suggested
> HSM Tasks framework be extended to cover SPM/SDM tasks as well?  I
> would hope that a it could.  In that case, we could look forward to a
> unified async task architecture in vdsm.

The current task framework in Vdsm is outrageously complex, yet
unreliable. It meant to do all kinds of things, like having the new spm
take over a task that was orphaned by the former spm. This has never
worked properly.

I'm looking for a much simpler infrastructure, where rollback is done by
virtue of having an "except" clause, and spm-only verbs simply fail when
the host loses spm status for some reason.

> 
> >I suggest to have something loosely modeled on posix fork/wait.
> >
> >- Engine asks Vdsm to start an API verb asynchronously and supplies a
> > uuid. This is unlike fork(2), where the system chooses the pid, but
> > that's required so that Engine could tell if the command has reached
> > Vdsm in case of a network error.
> >
> >- Engine may monitor the task (a-la wait(WNOHANG))
> 
> Allon has communicated a desire to limit engine-side polling.  Perhaps
> the active tasks could be added to the host stats?

Engine is reluctant to add more polling, I understand that. I'd prefer a
standalone new getAllTaskStats2() verb, but if lumping it into
getVdsStats is going to convince everybody to have it, I'd put my
aesthetic taste in the fridge.

> >- When the task is finished, Engine may collect its result (a-la wait).
> > Until that happens, Vdsm must report the task forever; restart or
> > upgrade are no excuses. On reboot, though, all tasks are forgotten, so
> > Engine may stop monitoring tasks on a fenced host.
> 
> This could be a good comprimise.  I hate the idea of requiring engine
> to play janitor and clean up stale vdsm data, but there is not much
> better of a way to do it.  Allowing reboot to auto-clear tasks will at
> least provide some backstop to how long tasks could pile up if
> forgotten.
> 
> >This may be an over kill for your use case, but it would come useful for
> >other cases. In particular, setupNetwork returns before it is completely
> >done, since dhcp address acquisition may take too much time. Engine may
> >poll getVdsCaps to see when it's done (or timeout), but it would be
> >nicer to have a generic mechanism that can serve us all.
> 
> If we were to consider this, I would want to vet the architecture
> against all known use cases for tasks to make sure we don't need to
> create a new framework in 3 months.

I'm afraid that our time scale is a bit longer (for good and for worse),
but for sure, we'd need to list all possible users of such an
infrastructure.

> 
> >Note that I'm suggesting a completely new task framwork, at least on
> >Vdsm side, as the current one (with its broken persistence, arcane
> >states and never-reliable rollback) is beyond redemption, imho.
> 
> Are we okay with abandoning vdsm-side rollback entirely as we move
> forward?  Won't that be a regression for at least some error flows
> (especially in the realm of SPM tasks)?

We would have to maintain the current spm task framework. But depending
on a Vdsm-side rollback to succeed was an old mistake. Rollback may fail
just as roll-forward does; thus Engine must handle the case of a lost
task. So why bother? Vdsm should do its best to finish a task, and clean
after itself. If it dies while at it, only Engine can ask another Vdsm
to pick up the pieces.

>
> >>5. When the job has completed, VDS Broker raises an event up to bll.
> >>  Maybe this could be done via VmJobDAO on the stored VmJob?
> >>6. Bll receives the event and issues a series of VDS commands to
> >>  complete the operation:
> >>  a) Verify the new image chain matches our expectations (the snap is
> >>     no longer present in the chain).
> >>  b) Delete the snapshot volume
> >>  c) Remove the VmJob from the DB


From S.Kieske at mittwald.de  Mon Mar  3 16:25:39 2014
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Mon, 3 Mar 2014 16:25:39 +0000
Subject: [Engine-devel] Tweaking backup/restore of engine
Message-ID: <5314ACBF.90305@mittwald.de>

Hi,

currently all events are stored in the table audit_log
which all gets saved when you use the engine-backup
shell script.


the event log is full of these login lines (engine 3.3.2):

25652	fdfc627c-d875-11e0-90f0-83df133b58cc	admin at internal
00000000-0000-0000-0000-000000000000	\N	\N	\N	\N	\N	2014-01-20
06:39:17.222+01	USER_VDC_LOGIN	30	0	User admin at internal
logged in.	f	\N		\N		00000000-0000-0000-0000-000000000000		\N	\N	\N
\N	00000000-0000-0000-0000-000000000000	\N	oVirt	-1	30		f	\N

this makes the log and db grow very large when you use the REST-API
to query ovirt for various data.

Is this necessary for a working restore?
It would be cool if we could tweak the engine-backup
tool to just dump necessary tables so you don't have
to restore events from the past no one is interested
in.

How does ovirt react, if I do not restore the content of the audit_log
table?

If this works (restore without audit_log) I would prefer to have
this code upstream in ovirt git so I don't have to maintain
my own backupscript.

Would it be possible to extend the existing backupscript
with a switch to not backup logs?
Currently it's just "all" or "just db".

I also recall that there shouldn't occur multiple login events any
more since ovirt 3.3. but it still seems to be the case.

I also do not understand how you would manage a stored authentication
via REST as REST is stateless.

I would appreciate any feedback or thoughts on this topic.
-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Gesch?ftsf?hrer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplement?rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

From didi at redhat.com  Mon Mar  3 20:41:14 2014
From: didi at redhat.com (Yedidyah Bar David)
Date: Mon, 3 Mar 2014 15:41:14 -0500 (EST)
Subject: [Engine-devel] Tweaking backup/restore of engine and the table
 'audit_log'
In-Reply-To: <5314ACBF.90305@mittwald.de>
References: <5314ACBF.90305@mittwald.de>
Message-ID: <1120227780.11414666.1393879274330.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Sven Kieske" <S.Kieske at mittwald.de>
> To: engine-devel at ovirt.org
> Sent: Monday, March 3, 2014 6:25:39 PM
> Subject: [Engine-devel] Tweaking backup/restore of engine
> 
> Hi,
> 
> currently all events are stored in the table audit_log
> which all gets saved when you use the engine-backup
> shell script.
> 
> 
> the event log is full of these login lines (engine 3.3.2):
> 
> 25652	fdfc627c-d875-11e0-90f0-83df133b58cc	admin at internal
> 00000000-0000-0000-0000-000000000000	\N	\N	\N	\N	\N	2014-01-20
> 06:39:17.222+01	USER_VDC_LOGIN	30	0	User admin at internal
> logged in.	f	\N		\N		00000000-0000-0000-0000-000000000000		\N	\N	\N
> \N	00000000-0000-0000-0000-000000000000	\N	oVirt	-1	30		f	\N
> 
> this makes the log and db grow very large when you use the REST-API
> to query ovirt for various data.
> 
> Is this necessary for a working restore?

I have no idea - I guess the data is not necessary.

I also guess that the schema is.

> It would be cool if we could tweak the engine-backup
> tool to just dump necessary tables so you don't have
> to restore events from the past no one is interested
> in.
> 
> How does ovirt react, if I do not restore the content of the audit_log
> table?
> 
> If this works (restore without audit_log) I would prefer to have
> this code upstream in ovirt git so I don't have to maintain
> my own backupscript.
> 
> Would it be possible to extend the existing backupscript
> with a switch to not backup logs?
> Currently it's just "all" or "just db".

It would be easy to let you pass an "extra options" argument for pg_dump.
This will allow adding '-T audit_log'. As I said, I am pretty certain
that you do need the table itself, so this will not help you much.

I personally think that this isn't the right way to go. If you do not need
the data, create a cron job that will periodically truncate it - say, keep
the last X days and delete the rest. Perhaps also archive before deleting
if you want. If you want, open a bug to provide a script to do that for you.
Or make the engine itself do that, etc.

Of course, after verifying that this does not have a significant impact on
the engine :-)

> 
> I also recall that there shouldn't occur multiple login events any
> more since ovirt 3.3. but it still seems to be the case.
> 
> I also do not understand how you would manage a stored authentication
> via REST as REST is stateless.
> 
> I would appreciate any feedback or thoughts on this topic.

Best regards,
-- 
Didi


From alitke at redhat.com  Mon Mar  3 22:26:28 2014
From: alitke at redhat.com (Adam Litke)
Date: Mon, 3 Mar 2014 17:26:28 -0500
Subject: [Engine-devel] Schema upgrade failure on master
Message-ID: <20140303222628.GE31669@redhat.com>

Hi,

I've recently rebased to master and it looks like the
03_05_0050_event_notification_methods.sql script is failing on schema
upgrade.  Is this a bug or am I doing something wrong?  To upgrade I
did the normal proceedure with my development installation:

make install-dev ...
~/ovirt/bin/engine-setup

Got this result in the log file:

psql:/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/dbscripts/upgrade/03_05_0050_event_notification_methods.sql:10: ERROR:  column "notification_method" contains null values
FATAL: Cannot execute sql command: --file=/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/dbscripts/upgrade/03_05_0050_event_notification_methods.sql

2014-03-03 17:20:34 DEBUG otopi.context context._executeMethod:152 method exception
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/otopi/context.py", line 142, in _executeMethod
    method['method']()
  File "/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/setup/bin/../plugins/ovirt-**FILTERED**-setup/ovirt-**FILTERED**/db/schema.py", line 280, in _misc
    osetupcons.DBEnv.PGPASS_FILE
  File "/usr/lib/python2.7/site-packages/otopi/plugin.py", line 451, in execute
    command=args[0],
RuntimeError: Command '/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/dbscripts/schema.sh' failed to execute

-- 
Adam Litke


From alonbl at redhat.com  Mon Mar  3 22:29:59 2014
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 3 Mar 2014 17:29:59 -0500 (EST)
Subject: [Engine-devel] Schema upgrade failure on master
In-Reply-To: <20140303222628.GE31669@redhat.com>
References: <20140303222628.GE31669@redhat.com>
Message-ID: <461231136.6928235.1393885799883.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Adam Litke" <alitke at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Tuesday, March 4, 2014 12:26:28 AM
> Subject: [Engine-devel] Schema upgrade failure on master
> 
> Hi,
> 
> I've recently rebased to master and it looks like the
> 03_05_0050_event_notification_methods.sql script is failing on schema
> upgrade.  Is this a bug or am I doing something wrong?  To upgrade I
> did the normal proceedure with my development installation:
> 
> make install-dev ...
> ~/ovirt/bin/engine-setup
> 
> Got this result in the log file:
> 
> psql:/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/dbscripts/upgrade/03_05_0050_event_notification_methods.sql:10:
> ERROR:  column "notification_method" contains null values
> FATAL: Cannot execute sql command:
> --file=/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/dbscripts/upgrade/03_05_0050_event_notification_methods.sql
> 
> 2014-03-03 17:20:34 DEBUG otopi.context context._executeMethod:152 method
> exception
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/otopi/context.py", line 142, in
>   _executeMethod
>     method['method']()
>   File
>   "/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/setup/bin/../plugins/ovirt-**FILTERED**-setup/ovirt-**FILTERED**/db/schema.py",
>   line 280, in _misc
>     osetupcons.DBEnv.PGPASS_FILE
>   File "/usr/lib/python2.7/site-packages/otopi/plugin.py", line 451, in
>   execute
>     command=args[0],
> RuntimeError: Command
> '/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/dbscripts/schema.sh'
> failed to execute
> 
> --
> Adam Litke
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From mperina at redhat.com  Tue Mar  4 05:10:21 2014
From: mperina at redhat.com (Martin Perina)
Date: Tue, 4 Mar 2014 00:10:21 -0500 (EST)
Subject: [Engine-devel] Schema upgrade failure on master
In-Reply-To: <20140303222628.GE31669@redhat.com>
References: <20140303222628.GE31669@redhat.com>
Message-ID: <1109246737.12800424.1393909821557.JavaMail.zimbra@redhat.com>

Hi Adam,

I didn't notice any problem with this script. Was the database you tried to upgrade empty?
If not could you please send me contents of your event_subscriber table?

Thanks

Martin Perina

----- Original Message -----
> From: "Adam Litke" <alitke at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Monday, March 3, 2014 11:26:28 PM
> Subject: [Engine-devel] Schema upgrade failure on master
> 
> Hi,
> 
> I've recently rebased to master and it looks like the
> 03_05_0050_event_notification_methods.sql script is failing on schema
> upgrade.  Is this a bug or am I doing something wrong?  To upgrade I
> did the normal proceedure with my development installation:
> 
> make install-dev ...
> ~/ovirt/bin/engine-setup
> 
> Got this result in the log file:
> 
> psql:/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/dbscripts/upgrade/03_05_0050_event_notification_methods.sql:10:
> ERROR:  column "notification_method" contains null values
> FATAL: Cannot execute sql command:
> --file=/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/dbscripts/upgrade/03_05_0050_event_notification_methods.sql
> 
> 2014-03-03 17:20:34 DEBUG otopi.context context._executeMethod:152 method
> exception
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/otopi/context.py", line 142, in
>   _executeMethod
>     method['method']()
>   File
>   "/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/setup/bin/../plugins/ovirt-**FILTERED**-setup/ovirt-**FILTERED**/db/schema.py",
>   line 280, in _misc
>     osetupcons.DBEnv.PGPASS_FILE
>   File "/usr/lib/python2.7/site-packages/otopi/plugin.py", line 451, in
>   execute
>     command=args[0],
> RuntimeError: Command
> '/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/dbscripts/schema.sh'
> failed to execute
> 
> --
> Adam Litke
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From yzaslavs at redhat.com  Tue Mar  4 06:53:59 2014
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Tue, 4 Mar 2014 01:53:59 -0500 (EST)
Subject: [Engine-devel] Tweaking backup/restore of engine
In-Reply-To: <5314ACBF.90305@mittwald.de>
References: <5314ACBF.90305@mittwald.de>
Message-ID: <321031989.25794382.1393916039124.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Sven Kieske" <S.Kieske at mittwald.de>
> To: engine-devel at ovirt.org
> Sent: Monday, March 3, 2014 6:25:39 PM
> Subject: [Engine-devel] Tweaking backup/restore of engine
> 
> Hi,
> 
> currently all events are stored in the table audit_log
> which all gets saved when you use the engine-backup
> shell script.
> 
> 
> the event log is full of these login lines (engine 3.3.2):
> 
> 25652	fdfc627c-d875-11e0-90f0-83df133b58cc	admin at internal
> 00000000-0000-0000-0000-000000000000	\N	\N	\N	\N	\N	2014-01-20
> 06:39:17.222+01	USER_VDC_LOGIN	30	0	User admin at internal
> logged in.	f	\N		\N		00000000-0000-0000-0000-000000000000		\N	\N	\N
> \N	00000000-0000-0000-0000-000000000000	\N	oVirt	-1	30		f	\N
> 
> this makes the log and db grow very large when you use the REST-API
> to query ovirt for various data.
> 
> Is this necessary for a working restore?
> It would be cool if we could tweak the engine-backup
> tool to just dump necessary tables so you don't have
> to restore events from the past no one is interested
> in.
> 
> How does ovirt react, if I do not restore the content of the audit_log
> table?
> 
> If this works (restore without audit_log) I would prefer to have
> this code upstream in ovirt git so I don't have to maintain
> my own backupscript.
> 
> Would it be possible to extend the existing backupscript
> with a switch to not backup logs?
> Currently it's just "all" or "just db".
> 
> I also recall that there shouldn't occur multiple login events any
> more since ovirt 3.3. but it still seems to be the case.

Hi Sven,
This is not entirely accurate -
The solution introduced at commit hash  cb56de8808cec33b7599828ead890f52e32bcaea solves the problem for a specific case in which we have a multiple login in a very short interval of time -
mainly due to attempt to login from webadmin, while UI plugin tries to login as well.
We have an "anti flood" mechanism for events, allowing us to define an interval, in which an event will not be logged twice. In the case of the login event this is set to 5 seconds, which is enough to solve the above described scenario.


> 
> I also do not understand how you would manage a stored authentication
> via REST as REST is stateless.
> 
> I would appreciate any feedback or thoughts on this topic.
> --
> Mit freundlichen Gr??en / Regards
> 
> Sven Kieske
> 
> Systemadministrator
> Mittwald CM Service GmbH & Co. KG
> K?nigsberger Stra?e 6
> 32339 Espelkamp
> T: +49-5772-293-100
> F: +49-5772-293-333
> https://www.mittwald.de
> Gesch?ftsf?hrer: Robert Meyer
> St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
> Komplement?rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>


From S.Kieske at mittwald.de  Tue Mar  4 08:10:31 2014
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Tue, 4 Mar 2014 08:10:31 +0000
Subject: [Engine-devel] Tweaking backup/restore of engine and the table
 'audit_log'
In-Reply-To: <1120227780.11414666.1393879274330.JavaMail.zimbra@redhat.com>
References: <5314ACBF.90305@mittwald.de>
	<1120227780.11414666.1393879274330.JavaMail.zimbra@redhat.com>
Message-ID: <53158A33.3010706@mittwald.de>

Thanks for your answer so far.

Is there anyone around who knows
if the audit_log data is needed for a successful restore?
I'd rather not try this out myself.

The reasoning behind this all is of course to keep backup
space as small as possible.

Am 03.03.2014 21:41, schrieb Yedidyah Bar David:
> I have no idea - I guess the data is not necessary.

-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Gesch?ftsf?hrer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplement?rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

From S.Kieske at mittwald.de  Tue Mar  4 08:25:31 2014
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Tue, 4 Mar 2014 08:25:31 +0000
Subject: [Engine-devel] Tweaking backup/restore of engine
In-Reply-To: <321031989.25794382.1393916039124.JavaMail.zimbra@redhat.com>
References: <5314ACBF.90305@mittwald.de>
	<321031989.25794382.1393916039124.JavaMail.zimbra@redhat.com>
Message-ID: <53158DB6.3070905@mittwald.de>

Thanks for the clarification,

I couldn't find this change any more, but I knew
there was something done.

However this makes me think about an RFE:
It would be cool if ovirt could provide a way
to use the REST-API without always have to login
and logout.

Maybe something like a hook into
some message passing queue like rabbitMQ or zeroMQ
or a similar process for receiving and submitting
messages. So you could register once with an API
consumer and use that.

What do you think?

Am 04.03.2014 07:53, schrieb Yair Zaslavsky:
> Hi Sven,
> This is not entirely accurate -
> The solution introduced at commit hash  cb56de8808cec33b7599828ead890f52e32bcaea solves the problem for a specific case in which we have a multiple login in a very short interval of time -
> mainly due to attempt to login from webadmin, while UI plugin tries to login as well.
> We have an "anti flood" mechanism for events, allowing us to define an interval, in which an event will not be logged twice. In the case of the login event this is set to 5 seconds, which is enough to solve the above described scenario.

-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Gesch?ftsf?hrer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplement?rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

From yzaslavs at redhat.com  Tue Mar  4 08:38:14 2014
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Tue, 4 Mar 2014 03:38:14 -0500 (EST)
Subject: [Engine-devel] Tweaking backup/restore of engine
In-Reply-To: <53158DB6.3070905@mittwald.de>
References: <5314ACBF.90305@mittwald.de>
	<321031989.25794382.1393916039124.JavaMail.zimbra@redhat.com>
	<53158DB6.3070905@mittwald.de>
Message-ID: <1152394439.25821809.1393922294299.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Sven Kieske" <S.Kieske at mittwald.de>
> To: engine-devel at ovirt.org
> Sent: Tuesday, March 4, 2014 10:25:31 AM
> Subject: Re: [Engine-devel] Tweaking backup/restore of engine
> 
> Thanks for the clarification,
> 
> I couldn't find this change any more, but I knew
> there was something done.
> 
> However this makes me think about an RFE:
> It would be cool if ovirt could provide a way
> to use the REST-API without always have to login
> and logout.
> 
> Maybe something like a hook into
> some message passing queue like rabbitMQ or zeroMQ
> or a similar process for receiving and submitting
> messages. So you could register once with an API
> consumer and use that.
> 
> What do you think?

CC'ing Juan - the maintainer of the REST API
> 
> Am 04.03.2014 07:53, schrieb Yair Zaslavsky:
> > Hi Sven,
> > This is not entirely accurate -
> > The solution introduced at commit hash
> > cb56de8808cec33b7599828ead890f52e32bcaea solves the problem for a
> > specific case in which we have a multiple login in a very short interval
> > of time -
> > mainly due to attempt to login from webadmin, while UI plugin tries to
> > login as well.
> > We have an "anti flood" mechanism for events, allowing us to define an
> > interval, in which an event will not be logged twice. In the case of the
> > login event this is set to 5 seconds, which is enough to solve the above
> > described scenario.
> 
> --
> Mit freundlichen Gr??en / Regards
> 
> Sven Kieske
> 
> Systemadministrator
> Mittwald CM Service GmbH & Co. KG
> K?nigsberger Stra?e 6
> 32339 Espelkamp
> T: +49-5772-293-100
> F: +49-5772-293-333
> https://www.mittwald.de
> Gesch?ftsf?hrer: Robert Meyer
> St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
> Komplement?rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From jhernand at redhat.com  Tue Mar  4 08:51:36 2014
From: jhernand at redhat.com (Juan Hernandez)
Date: Tue, 04 Mar 2014 09:51:36 +0100
Subject: [Engine-devel] Tweaking backup/restore of engine
In-Reply-To: <1152394439.25821809.1393922294299.JavaMail.zimbra@redhat.com>
References: <5314ACBF.90305@mittwald.de>
	<321031989.25794382.1393916039124.JavaMail.zimbra@redhat.com>
	<53158DB6.3070905@mittwald.de>
	<1152394439.25821809.1393922294299.JavaMail.zimbra@redhat.com>
Message-ID: <53159418.2060600@redhat.com>

On 03/04/2014 09:38 AM, Yair Zaslavsky wrote:
> 
> 
> ----- Original Message -----
>> From: "Sven Kieske" <S.Kieske at mittwald.de>
>> To: engine-devel at ovirt.org
>> Sent: Tuesday, March 4, 2014 10:25:31 AM
>> Subject: Re: [Engine-devel] Tweaking backup/restore of engine
>>
>> Thanks for the clarification,
>>
>> I couldn't find this change any more, but I knew
>> there was something done.
>>
>> However this makes me think about an RFE:
>> It would be cool if ovirt could provide a way
>> to use the REST-API without always have to login
>> and logout.
>>
>> Maybe something like a hook into
>> some message passing queue like rabbitMQ or zeroMQ
>> or a similar process for receiving and submitting
>> messages. So you could register once with an API
>> consumer and use that.
>>
>> What do you think?
> 
> CC'ing Juan - the maintainer of the REST API

Using the RESTAPI without repeated login/logout is already supported,
and it is what the SDKs do by default. In order to use it you need to
add the "Prefer: persistent-auth" header to the HTTP request, and keep
track of the cookies returned by the engine. For, example, the following
example sends events to the engine, without repeatedly performing the
login process:

#!/bin/sh -x

# The details to connect to the engine:
url="https://whatever/ovirt-engine/api"
user="admin at internal"
password="****"

# The file where we store the cookies, including the
# session id:
cookies="cookies.txt"

curl \
--insecure \
--request POST \
--header "Accept: application/xml" \
--header "Content-Type: application/xml" \
--header "Prefer: persistent-auth" \
--user "${user}:${password}" \
--cookie "${cookies}" \
--cookie-jar "${cookies}" \
--data "
<event>
  <origin>myorigin</origin>
  <severity>normal</severity>
  <description>Something from me</description>
  <custom_id>$(date +%s)</custom_id>
</event>
" \
${url}/events

This will keep a session alive in the server. If you want to explicitly
close it just send an additional request, with the same cookies and
without the "Prefer" header.

It is described in more detail here:

http://www.ovirt.org/Features/RESTSessionManagement

>>
>> Am 04.03.2014 07:53, schrieb Yair Zaslavsky:
>>> Hi Sven,
>>> This is not entirely accurate -
>>> The solution introduced at commit hash
>>> cb56de8808cec33b7599828ead890f52e32bcaea solves the problem for a
>>> specific case in which we have a multiple login in a very short interval
>>> of time -
>>> mainly due to attempt to login from webadmin, while UI plugin tries to
>>> login as well.
>>> We have an "anti flood" mechanism for events, allowing us to define an
>>> interval, in which an event will not be logged twice. In the case of the
>>> login event this is set to 5 seconds, which is enough to solve the above
>>> described scenario.
>>
>> --
>> Mit freundlichen Gr??en / Regards
>>
>> Sven Kieske
>>
>> Systemadministrator
>> Mittwald CM Service GmbH & Co. KG
>> K?nigsberger Stra?e 6
>> 32339 Espelkamp
>> T: +49-5772-293-100
>> F: +49-5772-293-333
>> https://www.mittwald.de
>> Gesch?ftsf?hrer: Robert Meyer
>> St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
>> Komplement?rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>


-- 
Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3?D, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L.


From S.Kieske at mittwald.de  Tue Mar  4 09:06:20 2014
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Tue, 4 Mar 2014 09:06:20 +0000
Subject: [Engine-devel] python docs in wiki up to date?
Message-ID: <53159747.2010904@mittwald.de>

Hi,

is this still state of the art?

http://www.ovirt.org/Testing/PythonApi

If not I could update it myself if you provide
me with the necessary information.

Thanks

-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Gesch?ftsf?hrer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplement?rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

From liran.zelkha at gmail.com  Tue Mar  4 09:15:47 2014
From: liran.zelkha at gmail.com (Liran Zelkha)
Date: Tue, 4 Mar 2014 11:15:47 +0200
Subject: [Engine-devel] Schema upgrade failure on master
In-Reply-To: <1109246737.12800424.1393909821557.JavaMail.zimbra@redhat.com>
References: <20140303222628.GE31669@redhat.com>
	<1109246737.12800424.1393909821557.JavaMail.zimbra@redhat.com>
Message-ID: <CAJ3aYLfLAcR_Hn_SXQehUT593XHEoFW=RyEvK33YPwxKTUYYZw@mail.gmail.com>

Happens to me too, on engine_dao_tests.
DB is not empty, one line:
engine_dao_tests=> select * from event_subscriber;
            subscriber_id             | event_up_name | method_id |
method_address | tag_name | notification_method
--------------------------------------+---------------+-----------+----------------+----------+---------------------
 9bf7c640-b620-456f-a550-0348f366544a | TestRun       |         1 |
       | testrun  |
(1 row)




On Tue, Mar 4, 2014 at 7:10 AM, Martin Perina <mperina at redhat.com> wrote:

> Hi Adam,
>
> I didn't notice any problem with this script. Was the database you tried
> to upgrade empty?
> If not could you please send me contents of your event_subscriber table?
>
> Thanks
>
> Martin Perina
>
> ----- Original Message -----
> > From: "Adam Litke" <alitke at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Monday, March 3, 2014 11:26:28 PM
> > Subject: [Engine-devel] Schema upgrade failure on master
> >
> > Hi,
> >
> > I've recently rebased to master and it looks like the
> > 03_05_0050_event_notification_methods.sql script is failing on schema
> > upgrade.  Is this a bug or am I doing something wrong?  To upgrade I
> > did the normal proceedure with my development installation:
> >
> > make install-dev ...
> > ~/ovirt/bin/engine-setup
> >
> > Got this result in the log file:
> >
> >
> psql:/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/dbscripts/upgrade/03_05_0050_event_notification_methods.sql:10:
> > ERROR:  column "notification_method" contains null values
> > FATAL: Cannot execute sql command:
> >
> --file=/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/dbscripts/upgrade/03_05_0050_event_notification_methods.sql
> >
> > 2014-03-03 17:20:34 DEBUG otopi.context context._executeMethod:152 method
> > exception
> > Traceback (most recent call last):
> >   File "/usr/lib/python2.7/site-packages/otopi/context.py", line 142, in
> >   _executeMethod
> >     method['method']()
> >   File
> >
> "/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/setup/bin/../plugins/ovirt-**FILTERED**-setup/ovirt-**FILTERED**/db/schema.py",
> >   line 280, in _misc
> >     osetupcons.DBEnv.PGPASS_FILE
> >   File "/usr/lib/python2.7/site-packages/otopi/plugin.py", line 451, in
> >   execute
> >     command=args[0],
> > RuntimeError: Command
> >
> '/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/dbscripts/schema.sh'
> > failed to execute
> >
> > --
> > Adam Litke
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140304/14c92956/attachment.html>

From sbonazzo at redhat.com  Tue Mar  4 09:22:07 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Tue, 04 Mar 2014 10:22:07 +0100
Subject: [Engine-devel] oVrit 3.4.0 branch created
Message-ID: <53159B3F.3090403@redhat.com>

Hi,
as announced yesterday the new branch ovirt-engine-3.4.0 branch has been created from 3.4.
Branch commit was:
* 9ab9f01 - (origin/ovirt-engine-3.4) core: Remove error messages from log when adding host <lzelkha at redhat.com>

Only critical fixes will be accepted on ovirt-engine-3.4.0 branch.
Thanks,

-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From mperina at redhat.com  Tue Mar  4 09:50:01 2014
From: mperina at redhat.com (Martin Perina)
Date: Tue, 4 Mar 2014 04:50:01 -0500 (EST)
Subject: [Engine-devel] Schema upgrade failure on master
In-Reply-To: <CAJ3aYLfLAcR_Hn_SXQehUT593XHEoFW=RyEvK33YPwxKTUYYZw@mail.gmail.com>
References: <20140303222628.GE31669@redhat.com>
	<1109246737.12800424.1393909821557.JavaMail.zimbra@redhat.com>
	<CAJ3aYLfLAcR_Hn_SXQehUT593XHEoFW=RyEvK33YPwxKTUYYZw@mail.gmail.com>
Message-ID: <1832002069.12888461.1393926601613.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Liran Zelkha" <liran.zelkha at gmail.com>
> To: "Martin Perina" <mperina at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, March 4, 2014 10:15:47 AM
> Subject: Re: [Engine-devel] Schema upgrade failure on master
> 
> Happens to me too, on engine_dao_tests.
> DB is not empty, one line:
> engine_dao_tests=> select * from event_subscriber;
>             subscriber_id             | event_up_name | method_id |
> method_address | tag_name | notification_method
> --------------------------------------+---------------+-----------+----------------+----------+---------------------
>  9bf7c640-b620-456f-a550-0348f366544a | TestRun       |         1 |
>        | testrun  |
> (1 row)

This row caused the issue, I wonder how it was created when notification_method column is created
during 03_05_0050_event_notification_methods.sql script execution ...

Delete this row and after this run schema upgrade. I tested with master and empty db and dao tests work fine.

> 
> 
> 
> 
> On Tue, Mar 4, 2014 at 7:10 AM, Martin Perina <mperina at redhat.com> wrote:
> 
> > Hi Adam,
> >
> > I didn't notice any problem with this script. Was the database you tried
> > to upgrade empty?
> > If not could you please send me contents of your event_subscriber table?
> >
> > Thanks
> >
> > Martin Perina
> >
> > ----- Original Message -----
> > > From: "Adam Litke" <alitke at redhat.com>
> > > To: engine-devel at ovirt.org
> > > Sent: Monday, March 3, 2014 11:26:28 PM
> > > Subject: [Engine-devel] Schema upgrade failure on master
> > >
> > > Hi,
> > >
> > > I've recently rebased to master and it looks like the
> > > 03_05_0050_event_notification_methods.sql script is failing on schema
> > > upgrade.  Is this a bug or am I doing something wrong?  To upgrade I
> > > did the normal proceedure with my development installation:
> > >
> > > make install-dev ...
> > > ~/ovirt/bin/engine-setup
> > >
> > > Got this result in the log file:
> > >
> > >
> > psql:/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/dbscripts/upgrade/03_05_0050_event_notification_methods.sql:10:
> > > ERROR:  column "notification_method" contains null values
> > > FATAL: Cannot execute sql command:
> > >
> > --file=/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/dbscripts/upgrade/03_05_0050_event_notification_methods.sql
> > >
> > > 2014-03-03 17:20:34 DEBUG otopi.context context._executeMethod:152 method
> > > exception
> > > Traceback (most recent call last):
> > >   File "/usr/lib/python2.7/site-packages/otopi/context.py", line 142, in
> > >   _executeMethod
> > >     method['method']()
> > >   File
> > >
> > "/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/setup/bin/../plugins/ovirt-**FILTERED**-setup/ovirt-**FILTERED**/db/schema.py",
> > >   line 280, in _misc
> > >     osetupcons.DBEnv.PGPASS_FILE
> > >   File "/usr/lib/python2.7/site-packages/otopi/plugin.py", line 451, in
> > >   execute
> > >     command=args[0],
> > > RuntimeError: Command
> > >
> > '/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/dbscripts/schema.sh'
> > > failed to execute
> > >
> > > --
> > > Adam Litke
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 


From S.Kieske at mittwald.de  Tue Mar  4 10:00:13 2014
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Tue, 4 Mar 2014 10:00:13 +0000
Subject: [Engine-devel] Tweaking backup/restore of engine
In-Reply-To: <5314ACBF.90305@mittwald.de>
References: <5314ACBF.90305@mittwald.de>
Message-ID: <5315A3E9.1090007@mittwald.de>

Hi,

I forgot to mention a crucial
point:

How long does the engine store past events, are they
stored forever or is there some kind of rotation?

We mainly use the engine as a REST provider for managing
the virtual machines.

-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Gesch?ftsf?hrer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplement?rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

From sbonazzo at redhat.com  Tue Mar  4 13:02:36 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Tue, 04 Mar 2014 14:02:36 +0100
Subject: [Engine-devel] [ANN] oVirt 3.3.4 release
Message-ID: <5315CEEC.7020401@redhat.com>

The oVirt development team is pleased to announce the general
availability of oVirt 3.3.4 as of March 4th 2014. This release
solidifies oVirt as a leading KVM management application and open
source alternative to VMware vSphere.

oVirt is available now for Fedora 19 and Red Hat Enterprise Linux 6.5
(or similar).

This release of oVirt includes numerous bug fixes.
See the release notes [1] for a list of the new features and bugs fixed.

The existing repository ovirt-stable has been updated for delivering this
release without the need of enabling any other repository.

A new oVirt Node build is also available [2].

[1] http://www.ovirt.org/OVirt_3.3.4_release_notes
[2] http://resources.ovirt.org/releases/3.3.4/iso/ovirt-node-iso-3.0.4-1.0.201401291204.vdsm33.el6.iso

-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From alitke at redhat.com  Tue Mar  4 13:18:21 2014
From: alitke at redhat.com (Adam Litke)
Date: Tue, 4 Mar 2014 08:18:21 -0500
Subject: [Engine-devel] Schema upgrade failure on master
In-Reply-To: <1109246737.12800424.1393909821557.JavaMail.zimbra@redhat.com>
References: <20140303222628.GE31669@redhat.com>
	<1109246737.12800424.1393909821557.JavaMail.zimbra@redhat.com>
Message-ID: <20140304131821.GF31669@redhat.com>

On 04/03/14 00:10 -0500, Martin Perina wrote:
>Hi Adam,
>
>I didn't notice any problem with this script. Was the database you tried to upgrade empty?
>If not could you please send me contents of your event_subscriber table?

engine=> select * from event_subscriber ;
            subscriber_id             |        event_up_name        | method_id 
|      method_address      | tag_name 
--------------------------------------+-----------------------------+-----------
+--------------------------+----------
 fdfc627c-d875-11e0-90f0-83df133b58cc | VM_SET_TICKET               |         0 
| alitke at brewer.alitke.net | 
 fdfc627c-d875-11e0-90f0-83df133b58cc | VM_DOWN_ERROR               |         0 
| alitke at brewer.alitke.net | 
 fdfc627c-d875-11e0-90f0-83df133b58cc | VDS_INITIATED_RUN_VM_FAILED |         0 
| alitke at brewer.alitke.net | 
(3 rows)


>
>Thanks
>
>Martin Perina
>
>----- Original Message -----
>> From: "Adam Litke" <alitke at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Monday, March 3, 2014 11:26:28 PM
>> Subject: [Engine-devel] Schema upgrade failure on master
>>
>> Hi,
>>
>> I've recently rebased to master and it looks like the
>> 03_05_0050_event_notification_methods.sql script is failing on schema
>> upgrade.  Is this a bug or am I doing something wrong?  To upgrade I
>> did the normal proceedure with my development installation:
>>
>> make install-dev ...
>> ~/ovirt/bin/engine-setup
>>
>> Got this result in the log file:
>>
>> psql:/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/dbscripts/upgrade/03_05_0050_event_notification_methods.sql:10:
>> ERROR:  column "notification_method" contains null values
>> FATAL: Cannot execute sql command:
>> --file=/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/dbscripts/upgrade/03_05_0050_event_notification_methods.sql
>>
>> 2014-03-03 17:20:34 DEBUG otopi.context context._executeMethod:152 method
>> exception
>> Traceback (most recent call last):
>>   File "/usr/lib/python2.7/site-packages/otopi/context.py", line 142, in
>>   _executeMethod
>>     method['method']()
>>   File
>>   "/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/setup/bin/../plugins/ovirt-**FILTERED**-setup/ovirt-**FILTERED**/db/schema.py",
>>   line 280, in _misc
>>     osetupcons.DBEnv.PGPASS_FILE
>>   File "/usr/lib/python2.7/site-packages/otopi/plugin.py", line 451, in
>>   execute
>>     command=args[0],
>> RuntimeError: Command
>> '/home/alitke/ovirt-**FILTERED**/share/ovirt-**FILTERED**/dbscripts/schema.sh'
>> failed to execute
>>
>> --
>> Adam Litke
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>

-- 
Adam Litke


From liran.zelkha at gmail.com  Tue Mar  4 13:20:57 2014
From: liran.zelkha at gmail.com (Liran Zelkha)
Date: Tue, 4 Mar 2014 15:20:57 +0200
Subject: [Engine-devel] Schema upgrade failure on master
In-Reply-To: <20140304131821.GF31669@redhat.com>
References: <20140303222628.GE31669@redhat.com>
	<1109246737.12800424.1393909821557.JavaMail.zimbra@redhat.com>
	<20140304131821.GF31669@redhat.com>
Message-ID: <CAJ3aYLfK6trOoP+AQxeL5spbytUdBo0K_cb7KBg3Ep5xs0sApg@mail.gmail.com>

had the same issue. Run from psql:
truncate table event_subscriber;
Then run the script. Note that this will delete all the rows from your
table...


On Tue, Mar 4, 2014 at 3:18 PM, Adam Litke <alitke at redhat.com> wrote:

> On 04/03/14 00:10 -0500, Martin Perina wrote:
>
>> Hi Adam,
>>
>> I didn't notice any problem with this script. Was the database you tried
>> to upgrade empty?
>> If not could you please send me contents of your event_subscriber table?
>>
>
> engine=> select * from event_subscriber ;
>            subscriber_id             |        event_up_name        |
> method_id |      method_address      | tag_name
> --------------------------------------+---------------------
> --------+-----------
> +--------------------------+----------
> fdfc627c-d875-11e0-90f0-83df133b58cc | VM_SET_TICKET               |
>     0 | alitke at brewer.alitke.net | fdfc627c-d875-11e0-90f0-83df133b58cc |
> VM_DOWN_ERROR               |         0 | alitke at brewer.alitke.net |
> fdfc627c-d875-11e0-90f0-83df133b58cc | VDS_INITIATED_RUN_VM_FAILED |
>     0 | alitke at brewer.alitke.net | (3 rows)
>
>
>
>> Thanks
>>
>> Martin Perina
>>
>> ----- Original Message -----
>>
>>> From: "Adam Litke" <alitke at redhat.com>
>>> To: engine-devel at ovirt.org
>>> Sent: Monday, March 3, 2014 11:26:28 PM
>>> Subject: [Engine-devel] Schema upgrade failure on master
>>>
>>> Hi,
>>>
>>> I've recently rebased to master and it looks like the
>>> 03_05_0050_event_notification_methods.sql script is failing on schema
>>> upgrade.  Is this a bug or am I doing something wrong?  To upgrade I
>>> did the normal proceedure with my development installation:
>>>
>>> make install-dev ...
>>> ~/ovirt/bin/engine-setup
>>>
>>> Got this result in the log file:
>>>
>>> psql:/home/alitke/ovirt-**FILTERED**/share/ovirt-**
>>> FILTERED**/dbscripts/upgrade/03_05_0050_event_notification_
>>> methods.sql:10:
>>> ERROR:  column "notification_method" contains null values
>>> FATAL: Cannot execute sql command:
>>> --file=/home/alitke/ovirt-**FILTERED**/share/ovirt-**
>>> FILTERED**/dbscripts/upgrade/03_05_0050_event_notification_methods.sql
>>>
>>> 2014-03-03 17:20:34 DEBUG otopi.context context._executeMethod:152 method
>>> exception
>>> Traceback (most recent call last):
>>>   File "/usr/lib/python2.7/site-packages/otopi/context.py", line 142, in
>>>   _executeMethod
>>>     method['method']()
>>>   File
>>>   "/home/alitke/ovirt-**FILTERED**/share/ovirt-**
>>> FILTERED**/setup/bin/../plugins/ovirt-**FILTERED**-
>>> setup/ovirt-**FILTERED**/db/schema.py",
>>>   line 280, in _misc
>>>     osetupcons.DBEnv.PGPASS_FILE
>>>   File "/usr/lib/python2.7/site-packages/otopi/plugin.py", line 451, in
>>>   execute
>>>     command=args[0],
>>> RuntimeError: Command
>>> '/home/alitke/ovirt-**FILTERED**/share/ovirt-**
>>> FILTERED**/dbscripts/schema.sh'
>>> failed to execute
>>>
>>> --
>>> Adam Litke
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>>
> --
> Adam Litke
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140304/6eb6aecb/attachment.html>

From emesika at redhat.com  Tue Mar  4 15:04:33 2014
From: emesika at redhat.com (Eli Mesika)
Date: Tue, 4 Mar 2014 10:04:33 -0500 (EST)
Subject: [Engine-devel] Schema upgrade failure on master
In-Reply-To: <CAJ3aYLfK6trOoP+AQxeL5spbytUdBo0K_cb7KBg3Ep5xs0sApg@mail.gmail.com>
References: <20140303222628.GE31669@redhat.com>
	<1109246737.12800424.1393909821557.JavaMail.zimbra@redhat.com>
	<20140304131821.GF31669@redhat.com>
	<CAJ3aYLfK6trOoP+AQxeL5spbytUdBo0K_cb7KBg3Ep5xs0sApg@mail.gmail.com>
Message-ID: <144458390.12891044.1393945473963.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Liran Zelkha" <liran.zelkha at gmail.com>
> To: "Adam Litke" <alitke at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, March 4, 2014 3:20:57 PM
> Subject: Re: [Engine-devel] Schema upgrade failure on master
> 
> had the same issue. Run from psql:
> truncate table event_subscriber;
> Then run the script. Note that this will delete all the rows from your
> table...


Sorry for jumping on that late, but if this occurs when  event_subscriber is not empty then this is a bug since it will fail also in customer site.
In that case I think that you should open a bug and since the notification mechanism is heavily used , I think this is a blocker

Can you please open a bug and assign on me 

Thanks
Eli

> 
> 
> On Tue, Mar 4, 2014 at 3:18 PM, Adam Litke < alitke at redhat.com > wrote:
> 
> 
> On 04/03/14 00:10 -0500, Martin Perina wrote:
> 
> 
> Hi Adam,
> 
> I didn't notice any problem with this script. Was the database you tried to
> upgrade empty?
> If not could you please send me contents of your event_subscriber table?
> 
> engine=> select * from event_subscriber ;
> subscriber_id | event_up_name | method_id | method_address | tag_name
> ------------------------------ --------+---------------------
> --------+-----------
> +--------------------------+-- --------
> fdfc627c-d875-11e0-90f0- 83df133b58cc | VM_SET_TICKET | 0 |
> alitke at brewer.alitke.net | fdfc627c-d875-11e0-90f0- 83df133b58cc |
> VM_DOWN_ERROR | 0 | alitke at brewer.alitke.net | fdfc627c-d875-11e0-90f0-
> 83df133b58cc | VDS_INITIATED_RUN_VM_FAILED | 0 | alitke at brewer.alitke.net |
> (3 rows)
> 
> 
> 
> 
> 
> Thanks
> 
> Martin Perina
> 
> ----- Original Message -----
> 
> 
> From: "Adam Litke" < alitke at redhat.com >
> To: engine-devel at ovirt.org
> Sent: Monday, March 3, 2014 11:26:28 PM
> Subject: [Engine-devel] Schema upgrade failure on master
> 
> Hi,
> 
> I've recently rebased to master and it looks like the
> 03_05_0050_event_notification_ methods.sql script is failing on schema
> upgrade. Is this a bug or am I doing something wrong? To upgrade I
> did the normal proceedure with my development installation:
> 
> make install-dev ...
> ~/ovirt/bin/engine-setup
> 
> Got this result in the log file:
> 
> psql:/home/alitke/ovirt-** FILTERED**/share/ovirt-**
> FILTERED**/dbscripts/upgrade/ 03_05_0050_event_notification_ methods.sql:10:
> ERROR: column "notification_method" contains null values
> FATAL: Cannot execute sql command:
> --file=/home/alitke/ovirt-** FILTERED**/share/ovirt-**
> FILTERED**/dbscripts/upgrade/ 03_05_0050_event_notification_ methods.sql
> 
> 2014-03-03 17:20:34 DEBUG otopi.context context._executeMethod:152 method
> exception
> Traceback (most recent call last):
> File "/usr/lib/python2.7/site- packages/otopi/context.py", line 142, in
> _executeMethod
> method['method']()
> File
> "/home/alitke/ovirt-** FILTERED**/share/ovirt-** FILTERED**/setup/bin/../
> plugins/ovirt-**FILTERED**- setup/ovirt-**FILTERED**/db/ schema.py",
> line 280, in _misc
> osetupcons.DBEnv.PGPASS_FILE
> File "/usr/lib/python2.7/site- packages/otopi/plugin.py", line 451, in
> execute
> command=args[0],
> RuntimeError: Command
> '/home/alitke/ovirt-** FILTERED**/share/ovirt-** FILTERED**/dbscripts/schema.
> sh'
> failed to execute
> 
> --
> Adam Litke
> ______________________________ _________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/ mailman/listinfo/engine-devel
> 
> 
> --
> Adam Litke
> ______________________________ _________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/ mailman/listinfo/engine-devel
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From alonbl at redhat.com  Wed Mar  5 08:13:05 2014
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 5 Mar 2014 03:13:05 -0500 (EST)
Subject: [Engine-devel] [ATN][devenv] update for otopi
In-Reply-To: <233617332.7313998.1394006939772.JavaMail.zimbra@redhat.com>
Message-ID: <187261644.7314299.1394007185010.JavaMail.zimbra@redhat.com>

Hello All,

I would like to ask you to update your otopi package on your development machines to at least otopi-1.2.0_0.7. It is much closer to what we are going to release and will avoid many unrelated errors within log file due to a change in engine that soon to be applied.

Please also notice that the nightly repository was modified recently and it is now changed place and was split here[1] and here[2], so it is a good opportunity to modify this as well in your /etc/yum.repo.d and have them both, dropping the old nightly.

Thank you,
Alon

[1] http://resources.ovirt.org/pub/ovirt-snapshot/
[2] http://resources.ovirt.org/pub/ovirt-snapshot-static/


From iheim at redhat.com  Wed Mar  5 09:19:08 2014
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 05 Mar 2014 11:19:08 +0200
Subject: [Engine-devel] Tweaking backup/restore of engine
In-Reply-To: <5315A3E9.1090007@mittwald.de>
References: <5314ACBF.90305@mittwald.de> <5315A3E9.1090007@mittwald.de>
Message-ID: <5316EC0C.6090505@redhat.com>

On 03/04/2014 12:00 PM, Sven Kieske wrote:
> Hi,
>
> I forgot to mention a crucial
> point:
>
> How long does the engine store past events, are they
> stored forever or is there some kind of rotation?
>
> We mainly use the engine as a REST provider for managing
> the virtual machines.
>

audit log gets deleted after 30 days by default. you can change that via 
config:

packaging/dbscripts/upgrade/pre_upgrade/0000_config.sql:select 
fn_db_add_config_value('AuditLogAgingThreshold','30','general');
packaging/etc/engine-config/engine-config.properties:AuditLogAgingThreshold.description="Audit 
Log Aging Threshold (in days)"
p


From mtayer at redhat.com  Wed Mar  5 10:20:12 2014
From: mtayer at redhat.com (Mooli Tayer)
Date: Wed, 5 Mar 2014 05:20:12 -0500 (EST)
Subject: [Engine-devel] Schema upgrade failure on master
In-Reply-To: <144458390.12891044.1393945473963.JavaMail.zimbra@redhat.com>
References: <20140303222628.GE31669@redhat.com>
	<1109246737.12800424.1393909821557.JavaMail.zimbra@redhat.com>
	<20140304131821.GF31669@redhat.com>
	<CAJ3aYLfK6trOoP+AQxeL5spbytUdBo0K_cb7KBg3Ep5xs0sApg@mail.gmail.com>
	<144458390.12891044.1393945473963.JavaMail.zimbra@redhat.com>
Message-ID: <2125773437.14217642.1394014812350.JavaMail.zimbra@redhat.com>

The problem is creating a p_key with null values.
The script will fail on any user that has an event_subscriber record.

bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1072866
patch:
http://gerrit.ovirt.org/#/c/25372/

will need backport to 3.4!

Mooli

----- Original Message -----
> 
> 
> ----- Original Message -----
> > From: "Liran Zelkha" <liran.zelkha at gmail.com>
> > To: "Adam Litke" <alitke at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Tuesday, March 4, 2014 3:20:57 PM
> > Subject: Re: [Engine-devel] Schema upgrade failure on master
> > 
> > had the same issue. Run from psql:
> > truncate table event_subscriber;
> > Then run the script. Note that this will delete all the rows from your
> > table...
> 
> 
> Sorry for jumping on that late, but if this occurs when  event_subscriber is
> not empty then this is a bug since it will fail also in customer site.
> In that case I think that you should open a bug and since the notification
> mechanism is heavily used , I think this is a blocker
> 
> Can you please open a bug and assign on me
> 
> Thanks
> Eli
> 
> > 
> > 
> > On Tue, Mar 4, 2014 at 3:18 PM, Adam Litke < alitke at redhat.com > wrote:
> > 
> > 
> > On 04/03/14 00:10 -0500, Martin Perina wrote:
> > 
> > 
> > Hi Adam,
> > 
> > I didn't notice any problem with this script. Was the database you tried to
> > upgrade empty?
> > If not could you please send me contents of your event_subscriber table?
> > 
> > engine=> select * from event_subscriber ;
> > subscriber_id | event_up_name | method_id | method_address | tag_name
> > ------------------------------ --------+---------------------
> > --------+-----------
> > +--------------------------+-- --------
> > fdfc627c-d875-11e0-90f0- 83df133b58cc | VM_SET_TICKET | 0 |
> > alitke at brewer.alitke.net | fdfc627c-d875-11e0-90f0- 83df133b58cc |
> > VM_DOWN_ERROR | 0 | alitke at brewer.alitke.net | fdfc627c-d875-11e0-90f0-
> > 83df133b58cc | VDS_INITIATED_RUN_VM_FAILED | 0 | alitke at brewer.alitke.net |
> > (3 rows)
> > 
> > 
> > 
> > 
> > 
> > Thanks
> > 
> > Martin Perina
> > 
> > ----- Original Message -----
> > 
> > 
> > From: "Adam Litke" < alitke at redhat.com >
> > To: engine-devel at ovirt.org
> > Sent: Monday, March 3, 2014 11:26:28 PM
> > Subject: [Engine-devel] Schema upgrade failure on master
> > 
> > Hi,
> > 
> > I've recently rebased to master and it looks like the
> > 03_05_0050_event_notification_ methods.sql script is failing on schema
> > upgrade. Is this a bug or am I doing something wrong? To upgrade I
> > did the normal proceedure with my development installation:
> > 
> > make install-dev ...
> > ~/ovirt/bin/engine-setup
> > 
> > Got this result in the log file:
> > 
> > psql:/home/alitke/ovirt-** FILTERED**/share/ovirt-**
> > FILTERED**/dbscripts/upgrade/ 03_05_0050_event_notification_
> > methods.sql:10:
> > ERROR: column "notification_method" contains null values
> > FATAL: Cannot execute sql command:
> > --file=/home/alitke/ovirt-** FILTERED**/share/ovirt-**
> > FILTERED**/dbscripts/upgrade/ 03_05_0050_event_notification_ methods.sql
> > 
> > 2014-03-03 17:20:34 DEBUG otopi.context context._executeMethod:152 method
> > exception
> > Traceback (most recent call last):
> > File "/usr/lib/python2.7/site- packages/otopi/context.py", line 142, in
> > _executeMethod
> > method['method']()
> > File
> > "/home/alitke/ovirt-** FILTERED**/share/ovirt-** FILTERED**/setup/bin/../
> > plugins/ovirt-**FILTERED**- setup/ovirt-**FILTERED**/db/ schema.py",
> > line 280, in _misc
> > osetupcons.DBEnv.PGPASS_FILE
> > File "/usr/lib/python2.7/site- packages/otopi/plugin.py", line 451, in
> > execute
> > command=args[0],
> > RuntimeError: Command
> > '/home/alitke/ovirt-** FILTERED**/share/ovirt-**
> > FILTERED**/dbscripts/schema.
> > sh'
> > failed to execute
> > 
> > --
> > Adam Litke
> > ______________________________ _________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/ mailman/listinfo/engine-devel
> > 
> > 
> > --
> > Adam Litke
> > ______________________________ _________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/ mailman/listinfo/engine-devel
> > 
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From dfediuck at redhat.com  Wed Mar  5 10:55:13 2014
From: dfediuck at redhat.com (Doron Fediuck)
Date: Wed, 5 Mar 2014 05:55:13 -0500 (EST)
Subject: [Engine-devel] oVirt 3.4 RC test day
In-Reply-To: <797153670.21010899.1394016856577.JavaMail.zimbra@redhat.com>
Message-ID: <2115668151.21011474.1394016913571.JavaMail.zimbra@redhat.com>

Hi everyone,
tomorrow we're planning the last test day for 3.4, based on the
RC release. All the needed information can be found in the
3.4 test day wiki[1].

See you all tomorrow,
Doron

[1] http://www.ovirt.org/OVirt_3.4_Test_Day


From S.Kieske at mittwald.de  Wed Mar  5 11:52:20 2014
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Wed, 5 Mar 2014 11:52:20 +0000
Subject: [Engine-devel] Tweaking backup/restore of engine
In-Reply-To: <5316EC0C.6090505@redhat.com>
References: <5314ACBF.90305@mittwald.de> <5315A3E9.1090007@mittwald.de>
	<5316EC0C.6090505@redhat.com>
Message-ID: <53170FAF.9050601@mittwald.de>

Wouldn't engine-config -s AuditLogAgingThreshold=X suffice?

Am 05.03.2014 10:19, schrieb Itamar Heim:
> On 03/04/2014 12:00 PM, Sven Kieske wrote:
>> Hi,
>>
>> I forgot to mention a crucial
>> point:
>>
>> How long does the engine store past events, are they
>> stored forever or is there some kind of rotation?
>>
>> We mainly use the engine as a REST provider for managing
>> the virtual machines.
>>
> 
> audit log gets deleted after 30 days by default. you can change that via
> config:
> 
> packaging/dbscripts/upgrade/pre_upgrade/0000_config.sql:select
> fn_db_add_config_value('AuditLogAgingThreshold','30','general');
> packaging/etc/engine-config/engine-config.properties:AuditLogAgingThreshold.description="Audit
> Log Aging Threshold (in days)"
> p
> 
> 
> 

-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Gesch?ftsf?hrer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplement?rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

From iheim at redhat.com  Wed Mar  5 12:15:08 2014
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 05 Mar 2014 14:15:08 +0200
Subject: [Engine-devel] Tweaking backup/restore of engine
In-Reply-To: <53170FAF.9050601@mittwald.de>
References: <5314ACBF.90305@mittwald.de> <5315A3E9.1090007@mittwald.de>
	<5316EC0C.6090505@redhat.com> <53170FAF.9050601@mittwald.de>
Message-ID: <5317154C.9090107@redhat.com>

On 03/05/2014 01:52 PM, Sven Kieske wrote:
> Wouldn't engine-config -s AuditLogAgingThreshold=X suffice?
>

yes. I just sent the line with current value and the description

> Am 05.03.2014 10:19, schrieb Itamar Heim:
>> On 03/04/2014 12:00 PM, Sven Kieske wrote:
>>> Hi,
>>>
>>> I forgot to mention a crucial
>>> point:
>>>
>>> How long does the engine store past events, are they
>>> stored forever or is there some kind of rotation?
>>>
>>> We mainly use the engine as a REST provider for managing
>>> the virtual machines.
>>>
>>
>> audit log gets deleted after 30 days by default. you can change that via
>> config:
>>
>> packaging/dbscripts/upgrade/pre_upgrade/0000_config.sql:select
>> fn_db_add_config_value('AuditLogAgingThreshold','30','general');
>> packaging/etc/engine-config/engine-config.properties:AuditLogAgingThreshold.description="Audit
>> Log Aging Threshold (in days)"
>> p
>>
>>
>>
>



From emesika at redhat.com  Wed Mar  5 14:50:42 2014
From: emesika at redhat.com (Eli Mesika)
Date: Wed, 5 Mar 2014 09:50:42 -0500 (EST)
Subject: [Engine-devel] Tweaking backup/restore of engine
In-Reply-To: <5314ACBF.90305@mittwald.de>
References: <5314ACBF.90305@mittwald.de>
Message-ID: <1557414399.13494067.1394031042123.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Sven Kieske" <S.Kieske at mittwald.de>
> To: engine-devel at ovirt.org
> Sent: Monday, March 3, 2014 6:25:39 PM
> Subject: [Engine-devel] Tweaking backup/restore of engine
> 
> Hi,
> 
> currently all events are stored in the table audit_log
> which all gets saved when you use the engine-backup
> shell script.
> 
> 
> the event log is full of these login lines (engine 3.3.2):
> 
> 25652	fdfc627c-d875-11e0-90f0-83df133b58cc	admin at internal
> 00000000-0000-0000-0000-000000000000	\N	\N	\N	\N	\N	2014-01-20
> 06:39:17.222+01	USER_VDC_LOGIN	30	0	User admin at internal
> logged in.	f	\N		\N		00000000-0000-0000-0000-000000000000		\N	\N	\N
> \N	00000000-0000-0000-0000-000000000000	\N	oVirt	-1	30		f	\N
> 
> this makes the log and db grow very large when you use the REST-API
> to query ovirt for various data.
> 
> Is this necessary for a working restore?
> It would be cool if we could tweak the engine-backup
> tool to just dump necessary tables so you don't have
> to restore events from the past no one is interested
> in.
> 
> How does ovirt react, if I do not restore the content of the audit_log
> table?
> 
> If this works (restore without audit_log) I would prefer to have
> this code upstream in ovirt git so I don't have to maintain
> my own backupscript.
> 
> Would it be possible to extend the existing backupscript
> with a switch to not backup logs?
> Currently it's just "all" or "just db".

Hi Sven 

engine-backup is calling eventually a postgres utility named pg_dump
this utility supports the following flag :

--exclude-table-data=TABLE   do NOT dump data for the named table(s)


I think that a RFE for adding support for this flag in engine-backup will easily solve your problem

Eli

> 
> I also recall that there shouldn't occur multiple login events any
> more since ovirt 3.3. but it still seems to be the case.
> 
> I also do not understand how you would manage a stored authentication
> via REST as REST is stateless.
> 
> I would appreciate any feedback or thoughts on this topic.
> --
> Mit freundlichen Gr??en / Regards
> 
> Sven Kieske
> 
> Systemadministrator
> Mittwald CM Service GmbH & Co. KG
> K?nigsberger Stra?e 6
> 32339 Espelkamp
> T: +49-5772-293-100
> F: +49-5772-293-333
> https://www.mittwald.de
> Gesch?ftsf?hrer: Robert Meyer
> St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
> Komplement?rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From emesika at redhat.com  Wed Mar  5 14:55:28 2014
From: emesika at redhat.com (Eli Mesika)
Date: Wed, 5 Mar 2014 09:55:28 -0500 (EST)
Subject: [Engine-devel] Tweaking backup/restore of engine and the table
 'audit_log'
In-Reply-To: <53158A33.3010706@mittwald.de>
References: <5314ACBF.90305@mittwald.de>
	<1120227780.11414666.1393879274330.JavaMail.zimbra@redhat.com>
	<53158A33.3010706@mittwald.de>
Message-ID: <1088725251.13504118.1394031328297.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Sven Kieske" <S.Kieske at mittwald.de>
> To: engine-devel at ovirt.org
> Sent: Tuesday, March 4, 2014 10:10:31 AM
> Subject: Re: [Engine-devel] Tweaking backup/restore of engine and the table 'audit_log'
> 
> Thanks for your answer so far.
> 
> Is there anyone around who knows
> if the audit_log data is needed for a successful restore?
> I'd rather not try this out myself.

only the table is needed, the data may be truncated and this not affect the way the engine will work, you will just loose the events/alerts history.


> 
> The reasoning behind this all is of course to keep backup
> space as small as possible.
> 
> Am 03.03.2014 21:41, schrieb Yedidyah Bar David:
> > I have no idea - I guess the data is not necessary.
> 
> --
> Mit freundlichen Gr??en / Regards
> 
> Sven Kieske
> 
> Systemadministrator
> Mittwald CM Service GmbH & Co. KG
> K?nigsberger Stra?e 6
> 32339 Espelkamp
> T: +49-5772-293-100
> F: +49-5772-293-333
> https://www.mittwald.de
> Gesch?ftsf?hrer: Robert Meyer
> St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
> Komplement?rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From didi at redhat.com  Wed Mar  5 15:02:40 2014
From: didi at redhat.com (Yedidyah Bar David)
Date: Wed, 5 Mar 2014 10:02:40 -0500 (EST)
Subject: [Engine-devel] Tweaking backup/restore of engine
In-Reply-To: <1557414399.13494067.1394031042123.JavaMail.zimbra@redhat.com>
References: <5314ACBF.90305@mittwald.de>
	<1557414399.13494067.1394031042123.JavaMail.zimbra@redhat.com>
Message-ID: <1182666342.13349613.1394031760323.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Sven Kieske" <S.Kieske at mittwald.de>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, March 5, 2014 4:50:42 PM
> Subject: Re: [Engine-devel] Tweaking backup/restore of engine
> 
> 
> 
> ----- Original Message -----
> > From: "Sven Kieske" <S.Kieske at mittwald.de>
> > To: engine-devel at ovirt.org
> > Sent: Monday, March 3, 2014 6:25:39 PM
> > Subject: [Engine-devel] Tweaking backup/restore of engine
> > 
> > Hi,
> > 
> > currently all events are stored in the table audit_log
> > which all gets saved when you use the engine-backup
> > shell script.
> > 
> > 
> > the event log is full of these login lines (engine 3.3.2):
> > 
> > 25652	fdfc627c-d875-11e0-90f0-83df133b58cc	admin at internal
> > 00000000-0000-0000-0000-000000000000	\N	\N	\N	\N	\N	2014-01-20
> > 06:39:17.222+01	USER_VDC_LOGIN	30	0	User admin at internal
> > logged in.	f	\N		\N		00000000-0000-0000-0000-000000000000		\N	\N	\N
> > \N	00000000-0000-0000-0000-000000000000	\N	oVirt	-1	30		f	\N
> > 
> > this makes the log and db grow very large when you use the REST-API
> > to query ovirt for various data.
> > 
> > Is this necessary for a working restore?
> > It would be cool if we could tweak the engine-backup
> > tool to just dump necessary tables so you don't have
> > to restore events from the past no one is interested
> > in.
> > 
> > How does ovirt react, if I do not restore the content of the audit_log
> > table?
> > 
> > If this works (restore without audit_log) I would prefer to have
> > this code upstream in ovirt git so I don't have to maintain
> > my own backupscript.
> > 
> > Would it be possible to extend the existing backupscript
> > with a switch to not backup logs?
> > Currently it's just "all" or "just db".
> 
> Hi Sven
> 
> engine-backup is calling eventually a postgres utility named pg_dump
> this utility supports the following flag :
> 
> --exclude-table-data=TABLE   do NOT dump data for the named table(s)

Oh, didn't notice that one. Added in 9.2, so not for el6.

> 
> 
> I think that a RFE for adding support for this flag in engine-backup will
> easily solve your problem

Perhaps better to allow passing arbitrary options to pg_dump. Or something
like that.
-- 
Didi


From emesika at redhat.com  Thu Mar  6 11:17:37 2014
From: emesika at redhat.com (Eli Mesika)
Date: Thu, 6 Mar 2014 06:17:37 -0500 (EST)
Subject: [Engine-devel] Tweaking backup/restore of engine
In-Reply-To: <1182666342.13349613.1394031760323.JavaMail.zimbra@redhat.com>
References: <5314ACBF.90305@mittwald.de>
	<1557414399.13494067.1394031042123.JavaMail.zimbra@redhat.com>
	<1182666342.13349613.1394031760323.JavaMail.zimbra@redhat.com>
Message-ID: <1923409310.14148539.1394104657897.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Yedidyah Bar David" <didi at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "Sven Kieske" <S.Kieske at mittwald.de>, engine-devel at ovirt.org
> Sent: Wednesday, March 5, 2014 5:02:40 PM
> Subject: Re: [Engine-devel] Tweaking backup/restore of engine
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Sven Kieske" <S.Kieske at mittwald.de>
> > Cc: engine-devel at ovirt.org
> > Sent: Wednesday, March 5, 2014 4:50:42 PM
> > Subject: Re: [Engine-devel] Tweaking backup/restore of engine
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Sven Kieske" <S.Kieske at mittwald.de>
> > > To: engine-devel at ovirt.org
> > > Sent: Monday, March 3, 2014 6:25:39 PM
> > > Subject: [Engine-devel] Tweaking backup/restore of engine
> > > 
> > > Hi,
> > > 
> > > currently all events are stored in the table audit_log
> > > which all gets saved when you use the engine-backup
> > > shell script.
> > > 
> > > 
> > > the event log is full of these login lines (engine 3.3.2):
> > > 
> > > 25652	fdfc627c-d875-11e0-90f0-83df133b58cc	admin at internal
> > > 00000000-0000-0000-0000-000000000000	\N	\N	\N	\N	\N	2014-01-20
> > > 06:39:17.222+01	USER_VDC_LOGIN	30	0	User admin at internal
> > > logged in.	f	\N		\N		00000000-0000-0000-0000-000000000000		\N	\N	\N
> > > \N	00000000-0000-0000-0000-000000000000	\N	oVirt	-1	30		f	\N
> > > 
> > > this makes the log and db grow very large when you use the REST-API
> > > to query ovirt for various data.
> > > 
> > > Is this necessary for a working restore?
> > > It would be cool if we could tweak the engine-backup
> > > tool to just dump necessary tables so you don't have
> > > to restore events from the past no one is interested
> > > in.
> > > 
> > > How does ovirt react, if I do not restore the content of the audit_log
> > > table?
> > > 
> > > If this works (restore without audit_log) I would prefer to have
> > > this code upstream in ovirt git so I don't have to maintain
> > > my own backupscript.
> > > 
> > > Would it be possible to extend the existing backupscript
> > > with a switch to not backup logs?
> > > Currently it's just "all" or "just db".
> > 
> > Hi Sven
> > 
> > engine-backup is calling eventually a postgres utility named pg_dump
> > this utility supports the following flag :
> > 
> > --exclude-table-data=TABLE   do NOT dump data for the named table(s)
> 
> Oh, didn't notice that one. Added in 9.2, so not for el6.
> 
> > 
> > 
> > I think that a RFE for adding support for this flag in engine-backup will
> > easily solve your problem
> 
> Perhaps better to allow passing arbitrary options to pg_dump. Or something
> like that.

So backup-engine will pass any additional parameters "as is" to the PG utility, Yes this would be great

> --
> Didi
> 


From S.Kieske at mittwald.de  Thu Mar  6 12:14:48 2014
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Thu, 6 Mar 2014 12:14:48 +0000
Subject: [Engine-devel] Tweaking backup/restore of engine
In-Reply-To: <1182666342.13349613.1394031760323.JavaMail.zimbra@redhat.com>
References: <5314ACBF.90305@mittwald.de>
	<1557414399.13494067.1394031042123.JavaMail.zimbra@redhat.com>
	<1182666342.13349613.1394031760323.JavaMail.zimbra@redhat.com>
Message-ID: <53186674.3050702@mittwald.de>

I was just writing an RFE, when I read that it's not possible
for el6. thats sad :/

Am 05.03.2014 16:02, schrieb Yedidyah Bar David:
> Oh, didn't notice that one. Added in 9.2, so not for el6.

-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Gesch?ftsf?hrer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplement?rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

From S.Kieske at mittwald.de  Thu Mar  6 12:24:33 2014
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Thu, 6 Mar 2014 12:24:33 +0000
Subject: [Engine-devel] Tweaking backup/restore of engine
In-Reply-To: <5314ACBF.90305@mittwald.de>
References: <5314ACBF.90305@mittwald.de>
Message-ID: <531868BD.7050302@mittwald.de>

Here's the RFE:

https://bugzilla.redhat.com/show_bug.cgi?id=1073421

-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Gesch?ftsf?hrer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplement?rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

From agrawalrohit92 at gmail.com  Fri Mar  7 07:53:21 2014
From: agrawalrohit92 at gmail.com (Rohit Agrawal)
Date: Fri, 7 Mar 2014 13:23:21 +0530
Subject: [Engine-devel] unable to create ui plugin
Message-ID: <CAEUeGp4UcjqXT8TaCwSaxy=GPu+XEzSQc817a9xTuBy7=G2ofw@mail.gmail.com>

i am trying to add the sample space shooter plugin and also helloWorld
plugin in webadmin of ovirt engine.
here is what i followed:
1. copied the folder through git to /usr/share/ovirt-engine/uiplugins
2. restart ovirt-engine
Still unable to see the plugin.
Any kind of help is appreciated
-- 
rohit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140307/2af3b858/attachment.html>

From vszocs at redhat.com  Fri Mar  7 14:35:40 2014
From: vszocs at redhat.com (Vojtech Szocs)
Date: Fri, 7 Mar 2014 09:35:40 -0500 (EST)
Subject: [Engine-devel] unable to create ui plugin
In-Reply-To: <CAEUeGp4UcjqXT8TaCwSaxy=GPu+XEzSQc817a9xTuBy7=G2ofw@mail.gmail.com>
References: <CAEUeGp4UcjqXT8TaCwSaxy=GPu+XEzSQc817a9xTuBy7=G2ofw@mail.gmail.com>
Message-ID: <164090257.15699309.1394202940308.JavaMail.zimbra@redhat.com>

Hi Rohit,

which version of Engine are you using? AFAIK, UI plugins were introduced in 3.2.0 release. If you build Engine from source, you can check commit titled "UI plugins, part one" in git log.

The easiest way to test UI plugins is to create a minimal plugin: http://www.ovirt.org/Features/UIPlugins#UI_plugin_cheat_sheet

Make sure the plugin descriptor (i.e. minimal.json) is located at /usr/share/ovirt-engine/ui-plugins and readable by Engine.

There is no need to restart Engine. Just refresh WebAdmin in your browser to reload all plugins, you should see following line in Engine log:

  INFO  [org.ovirt.engine.ui.frontend.server.gwt.plugin.PluginDataManager] (http--0.0.0.0-8080-1) Reading UI plugin descriptor [/home/vszocs/build/ovirt-engine/share/ovirt-engine/ui-plugins/minimal.json]

(Note: in above line, you can see that my Engine is at /home/vszocs/build/ovirt-engine instead of /usr because I'm building Engine from source via development environment.)

If you cloned samples-uiplugins git repository and wish to try Space Shooter plugin, just make symlinks to expose plugin descriptor and resources:

  $ ln -s /path/to/samples-uiplugins/space-shooter-plugin/space-shooter.json /usr/share/ovirt-engine/ui-plugins/space-shooter.json
  $ ln -s /path/to/samples-uiplugins/space-shooter-plugin/space-shooter-resources /usr/share/ovirt-engine/ui-plugins/space-shooter-resources

I've just tested both minimal and Space Shooter plugins, they work with latest Engine (master).

If this still doesn't work for you, please send me the plugin and Engine logs.

Regards,
Vojtech


----- Original Message -----
> From: "Rohit Agrawal" <agrawalrohit92 at gmail.com>
> To: Engine-devel at ovirt.org
> Sent: Friday, March 7, 2014 8:53:21 AM
> Subject: [Engine-devel] unable to create ui plugin
> 
> 
> i am trying to add the sample space shooter plugin and also helloWorld plugin
> in webadmin of ovirt engine.
> here is what i followed:
> 1. copied the folder through git to /usr/share/ovirt-engine/uiplugins
> 2. restart ovirt-engine
> Still unable to see the plugin.
> Any kind of help is appreciated
> --
> rohit
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From vszocs at redhat.com  Fri Mar  7 17:34:16 2014
From: vszocs at redhat.com (Vojtech Szocs)
Date: Fri, 7 Mar 2014 12:34:16 -0500 (EST)
Subject: [Engine-devel] Switched to thread-based GWT worker factory
In-Reply-To: <249785196.15773774.1394212485563.JavaMail.zimbra@redhat.com>
Message-ID: <480626336.15782436.1394213656657.JavaMail.zimbra@redhat.com>

Hi guys,

with patch [1] merged into master, GWT compiler will now use only
thread-based GWT worker factory (ThreadedPermutationWorkerFactory)
when compiling WebAdmin & UserPortal GUI.

[1] http://gerrit.ovirt.org/#/c/25163/

In practice, this means that GWT compiler will spawn up to:

  max_worker_threads = min(localWorkers, 4)

when compiling specific permutations (i.e. browser x locale).

Note that localWorkers value can be controlled through:

  EXTRA_BUILD_FLAGS="-Dgwt.compiler.localWorkers=..."
  DEV_EXTRA_BUILD_FLAGS="-Dgwt.compiler.localWorkers=..."

Before this patch was merged, GWT compiler spawned up to:

  max_external_processes = localWorkers

i.e. using separate Java sub-process (CompilePermsServer) that
communicates with GWT compiler process via socket.

For localWorkers == 1, tests show minimal-to-zero improvement.
However, for localWorkers > 1, tests show a slight improvement
in favor of thread-based approach.

Let me know if you have any questions.

Regards,
Vojtech


From agrawalrohit92 at gmail.com  Fri Mar  7 06:55:29 2014
From: agrawalrohit92 at gmail.com (Rohit Agrawal)
Date: Fri, 7 Mar 2014 12:25:29 +0530
Subject: [Engine-devel] unable to create ui plugin
Message-ID: <CAEUeGp6hpjrwiP1rQGRgZJ04VoxfFMyoX06O-ncfNMmsSfoQUA@mail.gmail.com>

i am trying to add the sample space shooter plugin and also helloWorld
plugin in webadmin of ovirt engine.
here is what i followed:
1. copied the folder through git to /usr/share/ovirt-engine/uiplugins
2. restart ovirt-engine
Still unable to see the plugin.
Any kind of help is appreciated

-- 
rohit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140307/71c95bbc/attachment.html>

From didi at redhat.com  Sun Mar  9 08:53:58 2014
From: didi at redhat.com (Yedidyah Bar David)
Date: Sun, 9 Mar 2014 04:53:58 -0400 (EDT)
Subject: [Engine-devel] [Users] GSoC 14 Idea Discussion - virt-sparsify
	integration
In-Reply-To: <CAARn91jXq_YV2F8cmAsGOYnr3C5ThN3Znb1JAJO8Q8hctJYhJQ@mail.gmail.com>
References: <CAARn91jXq_YV2F8cmAsGOYnr3C5ThN3Znb1JAJO8Q8hctJYhJQ@mail.gmail.com>
Message-ID: <109838948.16259456.1394355238193.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Utkarsh Singh" <utkarshsins at gmail.com>
> To: users at ovirt.org
> Sent: Friday, March 7, 2014 7:23:16 PM
> Subject: [Users] GSoC 14 Idea Discussion - virt-sparsify integration
> 
> Hello,
> 
> I am Utkarsh, a 4th year undergrad from IIT Delhi and a GSoC-14
> aspirant. I have been lately involved in an ongoing project Baadal
> Cloud Computing Platform in my institute, which has got me interested
> in oVirt for a potential GSoC project.
> 
> I was going through the virt-sparsify integration project idea. I have
> gone through the architecture documentation on the oVirt website. As
> far as I understand, the virt-sparsify integration needs to be done on
> the VDSM daemon, and it's control is either going to be completely
> independent of ovirt-engine (for example running it once every 24
> hours), or it's something that is centrally controlled by the
> ovirt-engine through XML/RPC calls. The details are not specified in
> the project ideas page. I would like to ask -
> 
> 1. What would be the proposed ideal implementation? (Central-Control
> or Independent-Control)
> 2. Is virt-sparsify usage going to be automated or
> administrator-triggered, or a combination of both?
> 
> 
> There are some aspects of the idea, which I would like to discuss
> before I start working on a proposal.
> 
> It's not necessary that an automated usage of virt-sparsify is limited
> to any simple idea. Architecture documentation states that
> ovirt-engine has features like Monitoring that would allow
> administrators (and possibly users) to be aware of vm-guest
> performance as well as vm-host performance. I am not very sure about
> how this data is collected, Is it done through MoM, or Is this
> directly done by VDSM, or is someone else doing this (for hosts). It
> would be great if someone can explain that to me. This information
> about vm-guest usage and vm-host health can help in determining how
> virt-sparsify is to be used.
> 
> I am also not very clear about the Shared Storage component in the
> architecture. Does oVirt make any assumptions about the Shared
> Storage. For example, the performance difference between running
> virt-sparsify on NFS as compared to running it (if possible) directly
> on storage hardware. If the Storage solution is necessarily a NAS
> instance, then virt-sparsify on NFS mount is the only option.
> 
> 
> 
> Right now, I am in the process of setting up oVirt on my system, and
> getting more familiar with the architecture. Regarding my experience.
> I am acquainted with both Java and Python. I have little experience
> with JBoss, but I have worked on some other Web Application Servers
> like web2py and Play Framework. My involvement in Baadal Platform has
> got me acquainted with libvirt/QEMU, the details of which I have
> mentioned below (if anyone is interested).
> 
> Please advise me about the things that I am missing about this
> project. If there are some implementation details that I need to know,
> kindly help me with that too.
> 
> 
> 
> Looking forward. Thanks.
> =====================
> Utkarsh
> IIT Delhi
> 
> Ongoing project details -
> 
> Article (Old)
>   http://www.cc.iitd.ernet.in/CSC/index.php?view=article&id=123:baadal-the-iitd-computing-cloud
> 
> Github
>   https://github.com/apoorvemohan/newbaadal
> 
> My contribution - Deployment Scripting and Sandbox Environment Setup for
> Testing
>   https://github.com/apoorvemohan/newbaadal/tree/master/baadaltesting/sandbox
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 

(Adding vdsm-devel and engine-devel)
-- 
Didi


From chuan.liao at hp.com  Mon Mar 10 09:17:13 2014
From: chuan.liao at hp.com (Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC))
Date: Mon, 10 Mar 2014 09:17:13 +0000
Subject: [Engine-devel] Supposed to add per CPU usage related infomation
 into engine core and vdsm
Message-ID: <B63C858E777679458338A30A991BB524015C4A99@G2W2441.americas.hpqcorp.net>

Hi All,

In order to support NUMA and guest NUMA feature in ovirt.
We need per NUMA node CPU usage or per CPU usage related information on engine core.

This information will be used for VM who have NUMA aware information and find the best Host to run it on with best performance.

Approach 1:

1.      Sample data in vdsm for each CPU stats. (sys, usr, iowait, idle)

2.      Calculate the each CPU usage information. (%sys, %usr, %iowait, %idle)

3.      Transport the usage data to engine core.

4.      Engine core merge per NUMA node CPU usage. (%sys, %usr, %iowait, %idle)

Approach 2:

1.      Sample data in vdsm for each CPU stats. (sys, usr, iowait, idle)

2.      Calculate the each CPU usage information. (%sys, %usr, %iowait, %idle)

3.      VDSM merge per NUMA node CPU usage. (%sys, %usr, %iowait, %idle)

4.      Transport the usage data to engine core.

Which one do you prefer, and why, or other solution.

Best Regards,
Jason Liao

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140310/50248a26/attachment.html>

From ofrenkel at redhat.com  Mon Mar 10 10:04:59 2014
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Mon, 10 Mar 2014 06:04:59 -0400 (EDT)
Subject: [Engine-devel] ovirt-engine-3.4.0 is broken
In-Reply-To: <525164036.23938124.1394445686209.JavaMail.zimbra@redhat.com>
Message-ID: <1378425823.23939362.1394445899356.JavaMail.zimbra@redhat.com>

Hi,
looks like both commits:
http://gerrit.ovirt.org/#/c/25436/
http://gerrit.ovirt.org/#/c/25313/

introduced an upgrade script with the same number to the 3.4.0 branch, and now build fails.
can you please fix this?


From mperina at redhat.com  Mon Mar 10 10:11:11 2014
From: mperina at redhat.com (Martin Perina)
Date: Mon, 10 Mar 2014 06:11:11 -0400 (EDT)
Subject: [Engine-devel] ovirt-engine-3.4.0 is broken
In-Reply-To: <1378425823.23939362.1394445899356.JavaMail.zimbra@redhat.com>
References: <1378425823.23939362.1394445899356.JavaMail.zimbra@redhat.com>
Message-ID: <1936847087.1277974.1394446271273.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Omer Frenkel" <ofrenkel at redhat.com>
> To: "Moti Asayag" <masayag at redhat.com>, "Martin Perina" <mperina at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, March 10, 2014 11:04:59 AM
> Subject: ovirt-engine-3.4.0 is broken
> 
> Hi,
> looks like both commits:
> http://gerrit.ovirt.org/#/c/25436/
> http://gerrit.ovirt.org/#/c/25313/
> 
> introduced an upgrade script with the same number to the 3.4.0 branch, and
> now build fails.
> can you please fix this?
> 

Moti answered me on IRC, that he will look at the issue. Hopefully
he will rename 03_04_0650_delete_network_labels_action_groups.sql
to 03_04_0660_delete_network_labels_action_groups.sql so the script names
will be the same as in ovirt-engine-3.4 branch.




From gchaplik at redhat.com  Mon Mar 10 11:36:20 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Mon, 10 Mar 2014 07:36:20 -0400 (EDT)
Subject: [Engine-devel] Supposed to add per CPU usage related infomation
 into engine core and vdsm
In-Reply-To: <B63C858E777679458338A30A991BB524015C4A99@G2W2441.americas.hpqcorp.net>
References: <B63C858E777679458338A30A991BB524015C4A99@G2W2441.americas.hpqcorp.net>
Message-ID: <888059896.16866790.1394451380205.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> To: "arch" <arch at ovirt.org>, "vdsm-devel" <vdsm-devel at lists.fedorahosted.org>, engine-devel at ovirt.org
> Cc: "Gilad Chaplik" <gchaplik at redhat.com>, dfediuck at redhat.com, msivak at redhat.com
> Sent: Monday, March 10, 2014 11:17:13 AM
> Subject: Supposed to add per CPU usage related infomation into engine core and vdsm
> 
> Hi All,
> 
> In order to support NUMA and guest NUMA feature in ovirt.
> We need per NUMA node CPU usage or per CPU usage related information on
> engine core.
> 
> This information will be used for VM who have NUMA aware information and find
> the best Host to run it on with best performance.
> 
> Approach 1:
> 
> 1.      Sample data in vdsm for each CPU stats. (sys, usr, iowait, idle)
> 
> 2.      Calculate the each CPU usage information. (%sys, %usr, %iowait,
> %idle)
> 
> 3.      Transport the usage data to engine core.
> 
> 4.      Engine core merge per NUMA node CPU usage. (%sys, %usr, %iowait,
> %idle)
> 

+1, since this data can be used for hardware other than NUMA

> Approach 2:
> 
> 1.      Sample data in vdsm for each CPU stats. (sys, usr, iowait, idle)
> 
> 2.      Calculate the each CPU usage information. (%sys, %usr, %iowait,
> %idle)
> 
> 3.      VDSM merge per NUMA node CPU usage. (%sys, %usr, %iowait, %idle)
> 
> 4.      Transport the usage data to engine core.
> 
> Which one do you prefer, and why, or other solution.
> 
> Best Regards,
> Jason Liao
> 
> 


From emesika at redhat.com  Mon Mar 10 11:49:55 2014
From: emesika at redhat.com (Eli Mesika)
Date: Mon, 10 Mar 2014 07:49:55 -0400 (EDT)
Subject: [Engine-devel] Supposed to add per CPU usage related infomation
 into engine core and vdsm
In-Reply-To: <888059896.16866790.1394451380205.JavaMail.zimbra@redhat.com>
References: <B63C858E777679458338A30A991BB524015C4A99@G2W2441.americas.hpqcorp.net>
	<888059896.16866790.1394451380205.JavaMail.zimbra@redhat.com>
Message-ID: <867513868.15558046.1394452195743.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Gilad Chaplik" <gchaplik at redhat.com>
> To: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> Cc: engine-devel at ovirt.org, "arch" <arch at ovirt.org>, "vdsm-devel" <vdsm-devel at lists.fedorahosted.org>
> Sent: Monday, March 10, 2014 1:36:20 PM
> Subject: Re: [Engine-devel] Supposed to add per CPU usage related infomation into engine core and vdsm
> 
> ----- Original Message -----
> > From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> > To: "arch" <arch at ovirt.org>, "vdsm-devel"
> > <vdsm-devel at lists.fedorahosted.org>, engine-devel at ovirt.org
> > Cc: "Gilad Chaplik" <gchaplik at redhat.com>, dfediuck at redhat.com,
> > msivak at redhat.com
> > Sent: Monday, March 10, 2014 11:17:13 AM
> > Subject: Supposed to add per CPU usage related infomation into engine core
> > and vdsm
> > 
> > Hi All,
> > 
> > In order to support NUMA and guest NUMA feature in ovirt.
> > We need per NUMA node CPU usage or per CPU usage related information on
> > engine core.
> > 
> > This information will be used for VM who have NUMA aware information and
> > find
> > the best Host to run it on with best performance.
> > 
> > Approach 1:
> > 
> > 1.      Sample data in vdsm for each CPU stats. (sys, usr, iowait, idle)
> > 
> > 2.      Calculate the each CPU usage information. (%sys, %usr, %iowait,
> > %idle)
> > 
> > 3.      Transport the usage data to engine core.
> > 
> > 4.      Engine core merge per NUMA node CPU usage. (%sys, %usr, %iowait,
> > %idle)
> > 
> 
> +1, since this data can be used for hardware other than NUMA

+1 , can be relevant to engine reports as well ....

> 
> > Approach 2:
> > 
> > 1.      Sample data in vdsm for each CPU stats. (sys, usr, iowait, idle)
> > 
> > 2.      Calculate the each CPU usage information. (%sys, %usr, %iowait,
> > %idle)
> > 
> > 3.      VDSM merge per NUMA node CPU usage. (%sys, %usr, %iowait, %idle)
> > 
> > 4.      Transport the usage data to engine core.
> > 
> > Which one do you prefer, and why, or other solution.
> > 
> > Best Regards,
> > Jason Liao
> > 
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From masayag at redhat.com  Mon Mar 10 12:31:53 2014
From: masayag at redhat.com (Moti Asayag)
Date: Mon, 10 Mar 2014 08:31:53 -0400 (EDT)
Subject: [Engine-devel] ovirt-engine-3.4.0 is broken
In-Reply-To: <1936847087.1277974.1394446271273.JavaMail.zimbra@redhat.com>
References: <1378425823.23939362.1394445899356.JavaMail.zimbra@redhat.com>
	<1936847087.1277974.1394446271273.JavaMail.zimbra@redhat.com>
Message-ID: <1835007968.1349626.1394454713226.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Martin Perina" <mperina at redhat.com>
> To: "Omer Frenkel" <ofrenkel at redhat.com>
> Cc: "Moti Asayag" <masayag at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, March 10, 2014 12:11:11 PM
> Subject: Re: ovirt-engine-3.4.0 is broken
> 
> 
> 
> ----- Original Message -----
> > From: "Omer Frenkel" <ofrenkel at redhat.com>
> > To: "Moti Asayag" <masayag at redhat.com>, "Martin Perina"
> > <mperina at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Monday, March 10, 2014 11:04:59 AM
> > Subject: ovirt-engine-3.4.0 is broken
> > 
> > Hi,
> > looks like both commits:
> > http://gerrit.ovirt.org/#/c/25436/
> > http://gerrit.ovirt.org/#/c/25313/
> > 
> > introduced an upgrade script with the same number to the 3.4.0 branch, and
> > now build fails.
> > can you please fix this?
> > 
> 
> Moti answered me on IRC, that he will look at the issue. Hopefully
> he will rename 03_04_0650_delete_network_labels_action_groups.sql
> to 03_04_0660_delete_network_labels_action_groups.sql so the script names
> will be the same as in ovirt-engine-3.4 branch.
> 

The patch is ready to be merged on http://gerrit.ovirt.org/#/c/25564/

> 
> 


From chuan.liao at hp.com  Tue Mar 11 06:02:23 2014
From: chuan.liao at hp.com (Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC))
Date: Tue, 11 Mar 2014 06:02:23 +0000
Subject: [Engine-devel] Consider iowait add into usage CPU percentage
Message-ID: <B63C858E777679458338A30A991BB524015C66EB@G1W3780.americas.hpqcorp.net>

Hi All,

On engine core, The usage CPU percentage is calculated by %sys + %usr

class VdsBrokerObjectsBuilder
function updateVDSStatisticsData
vds.setCpuSys(AssignDoubleValue(xmlRpcStruct, VdsProperties.cpu_sys));
        vds.setCpuUser(AssignDoubleValue(xmlRpcStruct, VdsProperties.cpu_user));
        if (vds.getCpuSys() != null && vds.getCpuUser() != null) {
            vds.setUsageCpuPercent((int) (vds.getCpuSys() + vds.getCpuUser()));
        }

On vdsm, The %sys, %usr and %idle is calculated like below workflow,

class API
function getStats
decStats = self._cif._hostStats.get()
class clientIF
function __init__
                   self._hostStats = sampling.HostStatsThread(log=log)
        self._hostStats.start()
class HostStatsThread
function get
                   hs0, hs1 = self._samples[0], self._samples[-1]
                   ...
                   jiffies = (hs1.totcpu.user - hs0.totcpu.user) % (2 ** 32)
        stats['cpuUser'] = jiffies / interval / self._ncpus
        jiffies = (hs1.totcpu.sys - hs0.totcpu.sys) % (2 ** 32)
        stats['cpuSys'] = jiffies / interval / self._ncpus
        stats['cpuIdle'] = max(0.0, 100.0 - stats['cpuUser'] - stats['cpuSys'])
class HostSample
function __init__
                   self.totcpu = TotalCpuSample()
class TotalCpuSample
function __init__
         self.user, userNice, self.sys, self.idle = \
            map(int, file('/proc/stat').readline().split()[1:5])
        self.user += userNice

Question1: Why stats['cpuIdle'] do not use the sampling data totcpu.idle for calculating?

Question2: There is another data named iowait in /proc/stat, do we need to consider add this into usage CPU percentage for calculating?

Best Regards,
Jason Liao

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140311/f72adce9/attachment.html>

From sbonazzo at redhat.com  Tue Mar 11 07:05:51 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Tue, 11 Mar 2014 08:05:51 +0100
Subject: [Engine-devel] ovirt-engine-3.4.0 is broken
In-Reply-To: <1835007968.1349626.1394454713226.JavaMail.zimbra@redhat.com>
References: <1378425823.23939362.1394445899356.JavaMail.zimbra@redhat.com>	<1936847087.1277974.1394446271273.JavaMail.zimbra@redhat.com>
	<1835007968.1349626.1394454713226.JavaMail.zimbra@redhat.com>
Message-ID: <531EB5CF.5070504@redhat.com>

Il 10/03/2014 13:31, Moti Asayag ha scritto:
> 
> 
> ----- Original Message -----
>> From: "Martin Perina" <mperina at redhat.com>
>> To: "Omer Frenkel" <ofrenkel at redhat.com>
>> Cc: "Moti Asayag" <masayag at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
>> Sent: Monday, March 10, 2014 12:11:11 PM
>> Subject: Re: ovirt-engine-3.4.0 is broken
>>
>>
>>
>> ----- Original Message -----
>>> From: "Omer Frenkel" <ofrenkel at redhat.com>
>>> To: "Moti Asayag" <masayag at redhat.com>, "Martin Perina"
>>> <mperina at redhat.com>
>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>> Sent: Monday, March 10, 2014 11:04:59 AM
>>> Subject: ovirt-engine-3.4.0 is broken
>>>
>>> Hi,
>>> looks like both commits:
>>> http://gerrit.ovirt.org/#/c/25436/
>>> http://gerrit.ovirt.org/#/c/25313/
>>>
>>> introduced an upgrade script with the same number to the 3.4.0 branch, and
>>> now build fails.
>>> can you please fix this?
>>>
>>
>> Moti answered me on IRC, that he will look at the issue. Hopefully
>> he will rename 03_04_0650_delete_network_labels_action_groups.sql
>> to 03_04_0660_delete_network_labels_action_groups.sql so the script names
>> will be the same as in ovirt-engine-3.4 branch.
>>
> 
> The patch is ready to be merged on http://gerrit.ovirt.org/#/c/25564/

Patch merged yesterday.

> 
>>
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From S.Kieske at mittwald.de  Tue Mar 11 08:09:51 2014
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Tue, 11 Mar 2014 08:09:51 +0000
Subject: [Engine-devel] Fwd: [vdsm]  ovirt-guest-agent on debian
In-Reply-To: <531D8746.5070907@mittwald.de>
References: <531D8746.5070907@mittwald.de>
Message-ID: <531EC489.3010809@mittwald.de>

Forwarding to engine devel, because it seems there is no interest in
this feature on vdsm-devel.

Could this get integrated somehow?
I managed to reuse the ubuntu build of ovirt-guest-agent for debian.


-------- Original-Nachricht --------
Betreff: [vdsm]  ovirt-guest-agent on debian
Datum: Mon, 10 Mar 2014 09:36:11 +0000
Von: Sven Kieske <S.Kieske at mittwald.de>
An: VDSM Project Development <vdsm-devel at lists.fedorahosted.org>

Hi,

I just did some additional research, here are my results:

on a clean debian 7 x64 VM inside oVirt:

I did as root:
apt-get install python-software-properties
add-apt-repository -y ppa:zhshzhou/vdsm-ubuntu

vim /etc/apt/sources.list.d/zhshzhou-vdsm-ubuntu-wheezy.list

change the following lines from:

deb http://ppa.launchpad.net/zhshzhou/vdsm-ubuntu/ubuntu wheezy main
deb-src http://ppa.launchpad.net/zhshzhou/vdsm-ubuntu/ubuntu wheezy main

to:

deb http://ppa.launchpad.net/zhshzhou/vdsm-ubuntu/ubuntu precise main
deb-src http://ppa.launchpad.net/zhshzhou/vdsm-ubuntu/ubuntu precise main

then:

apt-get update
apt-get install ovirt-guest-agent

You get an error:

Setting up ovirt-guest-agent (1.0.8.201309301944.gitb7f8f2-1ppa1) ...
chown: cannot access `/var/log/ovirt-guest-agent/ovirt-guest-agent.log':
No such file or directory

but it works:

ls -lashi /var/log/ovirt-guest-agent/ovirt-guest-agent.log
533212 4.0K -rw-r--r-- 1 ovirtagent ovirtagent 208 Mar 10 10:20
/var/log/ovirt-guest-agent/ovirt-guest-agent.log

service ovirt-guest-agent status
[ ok ] ovirt-guest-agent is running.

IP information shows up in ovirt.

it would be cool if the folder "precise" on the ppa could
be cloned to be a folder "wheezy".

So you would not need to change the apt-sources entries.

I don't know why this chown error occurs, but it seems to work!


-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Gesch?ftsf?hrer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplement?rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
_______________________________________________
vdsm-devel mailing list
vdsm-devel at lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel


From iheim at redhat.com  Tue Mar 11 08:23:18 2014
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 11 Mar 2014 10:23:18 +0200
Subject: [Engine-devel] Fwd: [vdsm]  ovirt-guest-agent on debian
In-Reply-To: <531EC489.3010809@mittwald.de>
References: <531D8746.5070907@mittwald.de> <531EC489.3010809@mittwald.de>
Message-ID: <531EC7F6.80803@redhat.com>

On 03/11/2014 10:09 AM, Sven Kieske wrote:
> Forwarding to engine devel, because it seems there is no interest in
> this feature on vdsm-devel.
>
> Could this get integrated somehow?
> I managed to reuse the ubuntu build of ovirt-guest-agent for debian.

vinznenz?

>
>
> -------- Original-Nachricht --------
> Betreff: [vdsm]  ovirt-guest-agent on debian
> Datum: Mon, 10 Mar 2014 09:36:11 +0000
> Von: Sven Kieske <S.Kieske at mittwald.de>
> An: VDSM Project Development <vdsm-devel at lists.fedorahosted.org>
>
> Hi,
>
> I just did some additional research, here are my results:
>
> on a clean debian 7 x64 VM inside oVirt:
>
> I did as root:
> apt-get install python-software-properties
> add-apt-repository -y ppa:zhshzhou/vdsm-ubuntu
>
> vim /etc/apt/sources.list.d/zhshzhou-vdsm-ubuntu-wheezy.list
>
> change the following lines from:
>
> deb http://ppa.launchpad.net/zhshzhou/vdsm-ubuntu/ubuntu wheezy main
> deb-src http://ppa.launchpad.net/zhshzhou/vdsm-ubuntu/ubuntu wheezy main
>
> to:
>
> deb http://ppa.launchpad.net/zhshzhou/vdsm-ubuntu/ubuntu precise main
> deb-src http://ppa.launchpad.net/zhshzhou/vdsm-ubuntu/ubuntu precise main
>
> then:
>
> apt-get update
> apt-get install ovirt-guest-agent
>
> You get an error:
>
> Setting up ovirt-guest-agent (1.0.8.201309301944.gitb7f8f2-1ppa1) ...
> chown: cannot access `/var/log/ovirt-guest-agent/ovirt-guest-agent.log':
> No such file or directory
>
> but it works:
>
> ls -lashi /var/log/ovirt-guest-agent/ovirt-guest-agent.log
> 533212 4.0K -rw-r--r-- 1 ovirtagent ovirtagent 208 Mar 10 10:20
> /var/log/ovirt-guest-agent/ovirt-guest-agent.log
>
> service ovirt-guest-agent status
> [ ok ] ovirt-guest-agent is running.
>
> IP information shows up in ovirt.
>
> it would be cool if the folder "precise" on the ppa could
> be cloned to be a folder "wheezy".
>
> So you would not need to change the apt-sources entries.
>
> I don't know why this chown error occurs, but it seems to work!
>
>




From vfeenstr at redhat.com  Tue Mar 11 08:38:29 2014
From: vfeenstr at redhat.com (Vinzenz Feenstra)
Date: Tue, 11 Mar 2014 09:38:29 +0100
Subject: [Engine-devel] Fwd: [vdsm]  ovirt-guest-agent on debian
In-Reply-To: <531EC7F6.80803@redhat.com>
References: <531D8746.5070907@mittwald.de> <531EC489.3010809@mittwald.de>
	<531EC7F6.80803@redhat.com>
Message-ID: <531ECB85.3060700@redhat.com>

On 03/11/2014 09:23 AM, Itamar Heim wrote:
> On 03/11/2014 10:09 AM, Sven Kieske wrote:
>> Forwarding to engine devel, because it seems there is no interest in
>> this feature on vdsm-devel.
There is definitely an interest, I just haven't seen this email 
yesterday but this morning.
Sorry for that.
>>
>> Could this get integrated somehow?
>> I managed to reuse the ubuntu build of ovirt-guest-agent for debian.
>
> vinznenz?
>
>>
>>
>> -------- Original-Nachricht --------
>> Betreff: [vdsm]  ovirt-guest-agent on debian
>> Datum: Mon, 10 Mar 2014 09:36:11 +0000
>> Von: Sven Kieske <S.Kieske at mittwald.de>
>> An: VDSM Project Development <vdsm-devel at lists.fedorahosted.org>
>>
>> Hi,
>>
>> I just did some additional research, here are my results:
>>
>> on a clean debian 7 x64 VM inside oVirt:
>>
>> I did as root:
>> apt-get install python-software-properties
>> add-apt-repository -y ppa:zhshzhou/vdsm-ubuntu
>>
>> vim /etc/apt/sources.list.d/zhshzhou-vdsm-ubuntu-wheezy.list
>>
>> change the following lines from:
>>
>> deb http://ppa.launchpad.net/zhshzhou/vdsm-ubuntu/ubuntu wheezy main
>> deb-src http://ppa.launchpad.net/zhshzhou/vdsm-ubuntu/ubuntu wheezy main
>>
>> to:
>>
>> deb http://ppa.launchpad.net/zhshzhou/vdsm-ubuntu/ubuntu precise main
>> deb-src http://ppa.launchpad.net/zhshzhou/vdsm-ubuntu/ubuntu precise 
>> main
>>
>> then:
>>
>> apt-get update
>> apt-get install ovirt-guest-agent
>>
>> You get an error:
>>
>> Setting up ovirt-guest-agent (1.0.8.201309301944.gitb7f8f2-1ppa1) ...
>> chown: cannot access `/var/log/ovirt-guest-agent/ovirt-guest-agent.log':
>> No such file or directory
>>
>> but it works:
>>
>> ls -lashi /var/log/ovirt-guest-agent/ovirt-guest-agent.log
>> 533212 4.0K -rw-r--r-- 1 ovirtagent ovirtagent 208 Mar 10 10:20
>> /var/log/ovirt-guest-agent/ovirt-guest-agent.log
>>
>> service ovirt-guest-agent status
>> [ ok ] ovirt-guest-agent is running.
>>
>> IP information shows up in ovirt.
>>
>> it would be cool if the folder "precise" on the ppa could
>> be cloned to be a folder "wheezy".
>>
>> So you would not need to change the apt-sources entries.
>>
>> I don't know why this chown error occurs, but it seems to work!
>>
>>
>
>


-- 
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com



From vikaskokare at gmail.com  Tue Mar 11 10:11:41 2014
From: vikaskokare at gmail.com (Vikas Kokare)
Date: Tue, 11 Mar 2014 15:41:41 +0530
Subject: [Engine-devel] oVirt Engine 3.2 ReST API
Message-ID: <CAKpxQk3iEL0W-amcgogBXJzg5Rb117yXCp_8f9psrXgp+0HK8g@mail.gmail.com>

As per the API documentation, the host cluster element "data_center id=" is
both required at creation(exclamation in a triangle) as well as
non-updatable(lock sign). Is it right to consider that, not only is this a
required element, but it can't be changed and deleting(disassociation) is
out of question?

We have a RHEVM environment, where one such host cluster was created
initially being associated to a data center. Later someone changed
something, that resulted in the specific host cluster having no
"data_center" element on it. Could it be that the association was deleted,
or that the data_center itself was deleted, but the system didn't honor
referential integrity, that it was being referred by other objects?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140311/e7e93a6c/attachment.html>

From ofrenkel at redhat.com  Tue Mar 11 12:26:36 2014
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Tue, 11 Mar 2014 08:26:36 -0400 (EDT)
Subject: [Engine-devel] oVirt Engine 3.2 ReST API
In-Reply-To: <CAKpxQk3iEL0W-amcgogBXJzg5Rb117yXCp_8f9psrXgp+0HK8g@mail.gmail.com>
References: <CAKpxQk3iEL0W-amcgogBXJzg5Rb117yXCp_8f9psrXgp+0HK8g@mail.gmail.com>
Message-ID: <770563300.25027988.1394540796596.JavaMail.zimbra@redhat.com>

----- Original Message -----

> From: "Vikas Kokare" <vikaskokare at gmail.com>
> To: engine-devel at ovirt.org
> Sent: Tuesday, March 11, 2014 12:11:41 PM
> Subject: [Engine-devel] oVirt Engine 3.2 ReST API

> As per the API documentation, the host cluster element "data_center id=" is
> both required at creation(exclamation in a triangle) as well as
> non-updatable(lock sign). Is it right to consider that, not only is this a
> required element, but it can't be changed and deleting(disassociation) is
> out of question?

> We have a RHEVM environment, where one such host cluster was created
> initially being associated to a data center. Later someone changed
> something, that resulted in the specific host cluster having no
> "data_center" element on it. Could it be that the association was deleted,
> or that the data_center itself was deleted, but the system didn't honor
> referential integrity, that it was being referred by other objects?

> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

it is possible to remove a data-center, even if it has clusters, 
as long there is no usage in the storage (vms, templates..) 
this makes the clusters to have no data-center, 
and then the cluster can be joined to a different data center (new/existing) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140311/f5620156/attachment.html>

From sbonazzo at redhat.com  Tue Mar 11 16:17:03 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Tue, 11 Mar 2014 17:17:03 +0100
Subject: [Engine-devel] [ANN] oVirt 3.4.0 Second Release Candidate is now
	available
Message-ID: <531F36FF.6000600@redhat.com>

The oVirt team is pleased to announce that the 3.4.0 Second Release Candidate is now available for testing.

Release notes and information on the changes for this update are still being worked on and will be available soon on the wiki[1].
Please ensure to follow install instruction from release notes if you're going to test it.
The existing repository ovirt-3.4.0-prerelease has been updated for delivering this release candidate and future refreshes until final release.

An oVirt Node iso will also be available soon.

We decided to postpone Final Release by one week in order to properly test the bugs fixed since last Release Candidate.
Help us make this the best release ever, testing it yourself!

[1] http://www.ovirt.org/OVirt_3.4.0_release_notes

-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From vszocs at redhat.com  Tue Mar 11 17:57:11 2014
From: vszocs at redhat.com (Vojtech Szocs)
Date: Tue, 11 Mar 2014 13:57:11 -0400 (EDT)
Subject: [Engine-devel] Small suggestions for engine-log-collector
In-Reply-To: <1504474667.17511317.1394559853264.JavaMail.zimbra@redhat.com>
Message-ID: <800022326.17517459.1394560631804.JavaMail.zimbra@redhat.com>

Hi guys,

based on my testing during last week's oVirt 3.4 RC test day [1],
I have a couple of small suggestions for engine-log-collector:

1, in /etc/ovirt-engine/logcollector.conf - I think there's typo:

      #key-file=/etc/pki/engine/keys/engine_id_rsa

   should be:

      #key-file=/etc/pki/ovirt-engine/keys/engine_id_rsa

2, to force password-based ssh auth, one has to do this:

      engine-log-collector -k ""

   because running this:

      engine-log-collector -k

   returns error message:

      error: -k option requires an argument

   however, help for -k option mentions *supplying* the argument:

      If a identity file is not supplied the program will prompt for a password.

   so either the help text should mention empty string,
   or -k option should allow missing argument (this was
   my initial understanding according to help text)

Since these are just small things, I'm wondering if I should
create RFE or if Keith/others can say if they are relevant.

Thanks,
Vojtech

[1] http://etherpad.ovirt.org/p/3.4-testday-3


From kroberts at redhat.com  Tue Mar 11 18:13:08 2014
From: kroberts at redhat.com (Keith Robertson)
Date: Tue, 11 Mar 2014 14:13:08 -0400 (EDT)
Subject: [Engine-devel] Small suggestions for engine-log-collector
In-Reply-To: <800022326.17517459.1394560631804.JavaMail.zimbra@redhat.com>
References: <800022326.17517459.1394560631804.JavaMail.zimbra@redhat.com>
Message-ID: <651261410.16892578.1394561588396.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Vojtech Szocs" <vszocs at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Cc: "Keith Robertson" <kroberts at redhat.com>, "Einav Cohen" <ecohen at redhat.com>
> Sent: Tuesday, March 11, 2014 1:57:11 PM
> Subject: Small suggestions for engine-log-collector
> 
> Hi guys,
> 
> based on my testing during last week's oVirt 3.4 RC test day [1],
> I have a couple of small suggestions for engine-log-collector:
> 
> 1, in /etc/ovirt-engine/logcollector.conf - I think there's typo:
> 
>       #key-file=/etc/pki/engine/keys/engine_id_rsa
> 
>    should be:
> 
>       #key-file=/etc/pki/ovirt-engine/keys/engine_id_rsa
> 

ACK


> 2, to force password-based ssh auth, one has to do this:
> 

In the normal scenario, the the ovirt user's public key should be installed into each hypervisor.  Unless something has changed as a part of the hypervisor registration process this should be something that we can depend upon.  

Clearly, there are edge cases where you need to collect logs from a hypervisor that isn't properly registered with the RHEV-M.  Was this your situation and how common do you think this scenario is?

>       engine-log-collector -k ""
> 

Yes, you are nulling out the default value which causes the LC to prompt you for a PW.  Perhaps we should document this as opposed to supplying a specific option?  Sandro?

>    because running this:
> 
>       engine-log-collector -k
> 
>    returns error message:
> 
>       error: -k option requires an argument
> 
>    however, help for -k option mentions *supplying* the argument:
> 
>       If a identity file is not supplied the program will prompt for a
>       password.
> 
>    so either the help text should mention empty string,
>    or -k option should allow missing argument (this was
>    my initial understanding according to help text)
> 
> Since these are just small things, I'm wondering if I should
> create RFE or if Keith/others can say if they are relevant.
> 
> Thanks,
> Vojtech
> 
> [1] http://etherpad.ovirt.org/p/3.4-testday-3
> 


From vszocs at redhat.com  Tue Mar 11 18:15:04 2014
From: vszocs at redhat.com (Vojtech Szocs)
Date: Tue, 11 Mar 2014 14:15:04 -0400 (EDT)
Subject: [Engine-devel] REST API - where did bookmarks go?
In-Reply-To: <134681088.17524268.1394561290638.JavaMail.zimbra@redhat.com>
Message-ID: <281801554.17527047.1394561704228.JavaMail.zimbra@redhat.com>

Hi guys,

as part of prototyping new JavaScript binding for oVirt REST API,
we chose a couple of business entities (resources) to experiment
with.

I just realized that requesting /ovirt-engine/api doesn't return
any information about bookmarks. Where did bookmarks go? Is it
possible to manage bookmarks through REST API?

Note: WebAdmin currently gets bookmarks through GWT RPC by calling
GetAllBookmarksQuery. Bookmark seems like proper backend business
entity (with DAO and everything) so it should be exposed also via
REST API.. or am I missing something?

Thanks,
Vojtech


From jhernand at redhat.com  Tue Mar 11 18:22:35 2014
From: jhernand at redhat.com (Juan Hernandez)
Date: Tue, 11 Mar 2014 19:22:35 +0100
Subject: [Engine-devel] REST API - where did bookmarks go?
In-Reply-To: <281801554.17527047.1394561704228.JavaMail.zimbra@redhat.com>
References: <281801554.17527047.1394561704228.JavaMail.zimbra@redhat.com>
Message-ID: <531F546B.8050104@redhat.com>

On 03/11/2014 07:15 PM, Vojtech Szocs wrote:
> Hi guys,
> 
> as part of prototyping new JavaScript binding for oVirt REST API,
> we chose a couple of business entities (resources) to experiment
> with.
> 
> I just realized that requesting /ovirt-engine/api doesn't return
> any information about bookmarks. Where did bookmarks go? Is it
> possible to manage bookmarks through REST API?
> 
> Note: WebAdmin currently gets bookmarks through GWT RPC by calling
> GetAllBookmarksQuery. Bookmark seems like proper backend business
> entity (with DAO and everything) so it should be exposed also via
> REST API.. or am I missing something?
> 
> Thanks,
> Vojtech
> 

The didn't go anywhere, just never existed in the API. Please open a RFE
to add them.

-- 
Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3?D, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L.


From chuan.liao at hp.com  Wed Mar 12 02:09:59 2014
From: chuan.liao at hp.com (Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC))
Date: Wed, 12 Mar 2014 02:09:59 +0000
Subject: [Engine-devel] Consider iowait add into usage CPU percentage
In-Reply-To: <B63C858E777679458338A30A991BB524015C66EB@G1W3780.americas.hpqcorp.net>
References: <B63C858E777679458338A30A991BB524015C66EB@G1W3780.americas.hpqcorp.net>
Message-ID: <B63C858E777679458338A30A991BB524015D1CBE@G1W3780.americas.hpqcorp.net>

Hi All,

Any feedback for this topic?
Add Doron and Martin in the mail list.

Best Regards,
Jason Liao

From: vdsm-devel-bounces at lists.fedorahosted.org [mailto:vdsm-devel-bounces at lists.fedorahosted.org] On Behalf Of Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
Sent: 2014?3?11? 14:02
To: vdsm-devel; engine-devel at ovirt.org
Cc: Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Vinod, Chegu; Gilad Chaplik
Subject: [vdsm] Consider iowait add into usage CPU percentage

Hi All,

On engine core, The usage CPU percentage is calculated by %sys + %usr

class VdsBrokerObjectsBuilder
function updateVDSStatisticsData
vds.setCpuSys(AssignDoubleValue(xmlRpcStruct, VdsProperties.cpu_sys));
        vds.setCpuUser(AssignDoubleValue(xmlRpcStruct, VdsProperties.cpu_user));
        if (vds.getCpuSys() != null && vds.getCpuUser() != null) {
            vds.setUsageCpuPercent((int) (vds.getCpuSys() + vds.getCpuUser()));
        }

On vdsm, The %sys, %usr and %idle is calculated like below workflow,

class API
function getStats
decStats = self._cif._hostStats.get()
class clientIF
function __init__
                   self._hostStats = sampling.HostStatsThread(log=log)
        self._hostStats.start()
class HostStatsThread
function get
                   hs0, hs1 = self._samples[0], self._samples[-1]
                   ?
                   jiffies = (hs1.totcpu.user - hs0.totcpu.user) % (2 ** 32)
        stats['cpuUser'] = jiffies / interval / self._ncpus
        jiffies = (hs1.totcpu.sys - hs0.totcpu.sys) % (2 ** 32)
        stats['cpuSys'] = jiffies / interval / self._ncpus
        stats['cpuIdle'] = max(0.0, 100.0 - stats['cpuUser'] - stats['cpuSys'])
class HostSample
function __init__
                   self.totcpu = TotalCpuSample()
class TotalCpuSample
function __init__
         self.user, userNice, self.sys, self.idle = \
            map(int, file('/proc/stat').readline().split()[1:5])
        self.user += userNice

Question1: Why stats[?cpuIdle?] do not use the sampling data totcpu.idle for calculating?

Question2: There is another data named iowait in /proc/stat, do we need to consider add this into usage CPU percentage for calculating?

Best Regards,
Jason Liao

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140312/6b6441ab/attachment.html>

From dfediuck at redhat.com  Wed Mar 12 02:40:11 2014
From: dfediuck at redhat.com (Doron Fediuck)
Date: Tue, 11 Mar 2014 22:40:11 -0400 (EDT)
Subject: [Engine-devel] Consider iowait add into usage CPU percentage
In-Reply-To: <B63C858E777679458338A30A991BB524015D1CBE@G1W3780.americas.hpqcorp.net>
References: <B63C858E777679458338A30A991BB524015C66EB@G1W3780.americas.hpqcorp.net>
	<B63C858E777679458338A30A991BB524015D1CBE@G1W3780.americas.hpqcorp.net>
Message-ID: <1672560311.25683064.1394592011414.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> To: "vdsm-devel" <vdsm-devel at lists.fedorahosted.org>, engine-devel at ovirt.org
> Cc: "Chegu Vinod" <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> <shangchun.liang at hp.com>
> Sent: Wednesday, March 12, 2014 4:09:59 AM
> Subject: Re: [Engine-devel] Consider iowait add into usage CPU percentage
> 
> 
> 
> Hi All,
> 
> 
> 
> Any feedback for this topic?
> 
> Add Doron and Martin in the mail list.
> 
> 
> 
> 
> Best Regards,
> Jason Liao
> 
> 
> 
> 
> 
> From: vdsm-devel-bounces at lists.fedorahosted.org
> [mailto:vdsm-devel-bounces at lists.fedorahosted.org] On Behalf Of Liao, Chuan
> (Jason Liao, HPservers-Core-OE-PSC)
> Sent: 2014 ? 3 ? 11 ? 14:02
> To: vdsm-devel; engine-devel at ovirt.org
> Cc: Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Vinod, Chegu;
> Gilad Chaplik
> Subject: [vdsm] Consider iowait add into usage CPU percentage
> 
> 
> 
> 
> Hi All,
> 
> 
> 
> On engine core, The usage CPU percentage is calculated by %sys + %usr
> 
> 
> 
> class VdsBrokerObjectsBuilder
> 
> function updateVDSStatisticsData
> 
> vds.setCpuSys(AssignDoubleValue(xmlRpcStruct, VdsProperties.cpu_sys));
> 
> vds.setCpuUser(AssignDoubleValue(xmlRpcStruct, VdsProperties.cpu_user));
> 
> if (vds.getCpuSys() != null && vds.getCpuUser() != null) {
> 
> vds.setUsageCpuPercent((int) (vds.getCpuSys() + vds.getCpuUser()));
> 
> }
> 
> 
> 
> On vdsm, The %sys, %usr and %idle is calculated like below workflow,
> 
> 
> 
> class API
> 
> function getStats
> 
> decStats = self._cif._hostStats.get()
> 
> class clientIF
> 
> function __init__
> 
> self._hostStats = sampling.HostStatsThread(log=log)
> 
> self._hostStats.start()
> 
> class HostStatsThread
> 
> function get
> 
> hs0, hs1 = self._samples[0], self._samples[-1]
> 
> ?
> 
> jiffies = (hs1.totcpu.user - hs0.totcpu.user) % (2 ** 32)
> 
> stats['cpuUser'] = jiffies / interval / self._ncpus
> 
> jiffies = (hs1.totcpu.sys - hs0.totcpu.sys) % (2 ** 32)
> 
> stats['cpuSys'] = jiffies / interval / self._ncpus
> 
> stats['cpuIdle'] = max(0.0, 100.0 - stats['cpuUser'] - stats['cpuSys'])
> 
> class HostSample
> 
> function __init__
> 
> self.totcpu = TotalCpuSample()
> 
> class TotalCpuSample
> 
> function __init__
> 
> self.user, userNice, self.sys, self.idle = \
> 
> map(int, file('/proc/stat').readline().split()[1:5])
> 
> self.user += userNice
> 
> 
> 
> Question1: Why stats[?cpuIdle?] do not use the sampling data totcpu.idle for
> calculating?
> 
I have a vague memory of this calculation which tries to level the numbers. 
ie- the assumption is that user and sys adds up to something which is less than 100.
If this is not the case (multiple core / SMT) idle will be set to 0.
But possibly Dan remembers something else?

> 
> 
> Question2: There is another data named iowait in /proc/stat, do we need to
> consider add this into usage CPU percentage for calculating?
> 
Since the above excludes iowait, I wouldn't add it here. Otherwise
we may have inconsistency with the numbers.

> 
> 
> Best Regards,
> Jason Liao
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From ofrenkel at redhat.com  Wed Mar 12 06:45:17 2014
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Wed, 12 Mar 2014 02:45:17 -0400 (EDT)
Subject: [Engine-devel] oVirt Engine 3.2 ReST API
In-Reply-To: <CAKpxQk28pmqNEPTdq8BYA15XBvCchUVyQziy1afwjNnaArYMPg@mail.gmail.com>
References: <CAKpxQk3iEL0W-amcgogBXJzg5Rb117yXCp_8f9psrXgp+0HK8g@mail.gmail.com>
	<770563300.25027988.1394540796596.JavaMail.zimbra@redhat.com>
	<CAKpxQk28pmqNEPTdq8BYA15XBvCchUVyQziy1afwjNnaArYMPg@mail.gmail.com>
Message-ID: <1187183481.25735699.1394606717688.JavaMail.zimbra@redhat.com>

----- Original Message -----

> From: "Vikas Kokare" <vikaskokare at gmail.com>
> To: "Omer Frenkel" <ofrenkel at redhat.com>
> Sent: Wednesday, March 12, 2014 5:24:11 AM
> Subject: Re: [Engine-devel] oVirt Engine 3.2 ReST API

> The problem is this situation is not obvious from the documentation. The data
> center field on the cluster is defined as required during creation and
> non-updatable. How can that be explained? So its a question not just for
> this example but for other entity associations too.

i guess this is a bug in the documentation, 
this field is editable in this specific case only. 
can you open a bug? 

> On Tue, Mar 11, 2014 at 5:56 PM, Omer Frenkel < ofrenkel at redhat.com > wrote:

> > > From: "Vikas Kokare" < vikaskokare at gmail.com >
> > 
> 
> > > To: engine-devel at ovirt.org
> > 
> 
> > > Sent: Tuesday, March 11, 2014 12:11:41 PM
> > 
> 
> > > Subject: [Engine-devel] oVirt Engine 3.2 ReST API
> > 
> 

> > > As per the API documentation, the host cluster element "data_center id="
> > > is
> > > both required at creation(exclamation in a triangle) as well as
> > > non-updatable(lock sign). Is it right to consider that, not only is this
> > > a
> > > required element, but it can't be changed and deleting(disassociation) is
> > > out of question?
> > 
> 

> > > We have a RHEVM environment, where one such host cluster was created
> > > initially being associated to a data center. Later someone changed
> > > something, that resulted in the specific host cluster having no
> > > "data_center" element on it. Could it be that the association was
> > > deleted,
> > > or that the data_center itself was deleted, but the system didn't honor
> > > referential integrity, that it was being referred by other objects?
> > 
> 

> > > _______________________________________________
> > 
> 
> > > Engine-devel mailing list
> > 
> 
> > > Engine-devel at ovirt.org
> > 
> 
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 

> > it is possible to remove a data-center, even if it has clusters,
> 
> > as long there is no usage in the storage (vms, templates..)
> 
> > this makes the clusters to have no data-center,
> 
> > and then the cluster can be joined to a different data center
> > (new/existing)
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140312/4d02457b/attachment.html>

From iheim at redhat.com  Wed Mar 12 09:59:16 2014
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 12 Mar 2014 11:59:16 +0200
Subject: [Engine-devel] Change in ovirt-engine[master]: core: enable to
	decrease DC compatibility...
In-Reply-To: <201403112226.s2BMQpjX013721@gerrit.ovirt.org>
References: <gerrit.1392716300399.I73284f641b7f80b380b39efbbd7b4566f55119b6@gerrit.ovirt.org>
	<201403112226.s2BMQpjX013721@gerrit.ovirt.org>
Message-ID: <53202FF4.6030004@redhat.com>

On 03/12/2014 12:26 AM, emesika at redhat.com wrote:
> Eli Mesika has submitted this change and it was merged.
>
> Change subject: core: enable to decrease DC compatibility...
> ......................................................................
>
>
> core: enable to decrease DC compatibility...
>
> enable to decrease DC compatibility version if DC has no clusters
>
> This patch enables to decrease the DC compatibility version if DC has no
> clusters.

Eli - just saw this. I'm pretty sure it would be *bad* to downgrade a DC 
version if it has storage domains as well. not sure if this is checked 
already or not.

may also be an issue with some logical network features.

>
> Change-Id: I73284f641b7f80b380b39efbbd7b4566f55119b6
> Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1057029
> Signed-off-by: Eli Mesika <emesika at redhat.com>
> ---
> M backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/storage/UpdateStoragePoolCommand.java
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> Approvals:
>    Eli Mesika: Verified
>    Ravi Nori: Looks good to me, but someone else must approve
>    Yair Zaslavsky: Looks good to me, approved
>
>
>



From fsimonce at redhat.com  Wed Mar 12 10:41:40 2014
From: fsimonce at redhat.com (Federico Simoncelli)
Date: Wed, 12 Mar 2014 06:41:40 -0400 (EDT)
Subject: [Engine-devel] Change in ovirt-engine[master]: core: enable to
 decrease DC compatibility...
In-Reply-To: <53202FF4.6030004@redhat.com>
References: <gerrit.1392716300399.I73284f641b7f80b380b39efbbd7b4566f55119b6@gerrit.ovirt.org>
	<201403112226.s2BMQpjX013721@gerrit.ovirt.org>
	<53202FF4.6030004@redhat.com>
Message-ID: <302554462.17939130.1394620900092.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: engine-devel at ovirt.org
> Cc: "Eli Mesika" <emesika at redhat.com>, "Federico Simoncelli" <fsimonce at redhat.com>, "Allon Mureinik"
> <amureini at redhat.com>, "Livnat Peer" <lpeer at redhat.com>
> Sent: Wednesday, March 12, 2014 11:59:16 AM
> Subject: Re: Change in ovirt-engine[master]: core: enable to decrease DC compatibility...
> 
> On 03/12/2014 12:26 AM, emesika at redhat.com wrote:
> > Eli Mesika has submitted this change and it was merged.
> >
> > Change subject: core: enable to decrease DC compatibility...
> > ......................................................................
> >
> >
> > core: enable to decrease DC compatibility...
> >
> > enable to decrease DC compatibility version if DC has no clusters
> >
> > This patch enables to decrease the DC compatibility version if DC has no
> > clusters.
> 
> Eli - just saw this. I'm pretty sure it would be *bad* to downgrade a DC
> version if it has storage domains as well. not sure if this is checked
> already or not.
> 
> may also be an issue with some logical network features.

Downgrading a DC from storage perspective is problematic (domain version,
storage pool metadata removal, etc). This should be blocked.

-- 
Federico


From lpeer at redhat.com  Wed Mar 12 10:42:44 2014
From: lpeer at redhat.com (Livnat Peer)
Date: Wed, 12 Mar 2014 12:42:44 +0200
Subject: [Engine-devel] Change in ovirt-engine[master]: core: enable to
	decrease DC compatibility...
In-Reply-To: <53202FF4.6030004@redhat.com>
References: <gerrit.1392716300399.I73284f641b7f80b380b39efbbd7b4566f55119b6@gerrit.ovirt.org>
	<201403112226.s2BMQpjX013721@gerrit.ovirt.org>
	<53202FF4.6030004@redhat.com>
Message-ID: <53203A24.4040200@redhat.com>

On 03/12/2014 11:59 AM, Itamar Heim wrote:
> On 03/12/2014 12:26 AM, emesika at redhat.com wrote:
>> Eli Mesika has submitted this change and it was merged.
>>
>> Change subject: core: enable to decrease DC compatibility...
>> ......................................................................
>>
>>
>> core: enable to decrease DC compatibility...
>>
>> enable to decrease DC compatibility version if DC has no clusters
>>
>> This patch enables to decrease the DC compatibility version if DC has no
>> clusters.
> 
> Eli - just saw this. I'm pretty sure it would be *bad* to downgrade a DC
> version if it has storage domains as well. not sure if this is checked
> already or not.
> 
> may also be an issue with some logical network features.
> 

Most of the network features are driven from cluster level, we enable
using the features on all DC level (actually >=3.1) but actually enable
/disable the feature when attaching the network to a cluster.

So from network perspective I think it should be fine to downgrade the
DC level even if there are networks in the DC (at least now this could
change in future versions).

In general I believe the use case for this patch is mostly for empty DCs
so for simplicity we should block it if there are networks or SD in the
DC when downgrading.

Livnat


>>
>> Change-Id: I73284f641b7f80b380b39efbbd7b4566f55119b6
>> Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1057029
>> Signed-off-by: Eli Mesika <emesika at redhat.com>
>> ---
>> M
>> backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/storage/UpdateStoragePoolCommand.java
>>
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> Approvals:
>>    Eli Mesika: Verified
>>    Ravi Nori: Looks good to me, but someone else must approve
>>    Yair Zaslavsky: Looks good to me, approved
>>
>>
>>
> 



From iheim at redhat.com  Wed Mar 12 10:47:31 2014
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 12 Mar 2014 12:47:31 +0200
Subject: [Engine-devel] Change in ovirt-engine[master]: core: enable to
 decrease DC compatibility...
In-Reply-To: <53203A24.4040200@redhat.com>
References: <gerrit.1392716300399.I73284f641b7f80b380b39efbbd7b4566f55119b6@gerrit.ovirt.org>	<201403112226.s2BMQpjX013721@gerrit.ovirt.org>	<53202FF4.6030004@redhat.com>
	<53203A24.4040200@redhat.com>
Message-ID: <53203B43.9000409@redhat.com>

On 03/12/2014 12:42 PM, Livnat Peer wrote:
> In general I believe the use case for this patch is mostly for empty DCs
> so for simplicity we should block it if there are networks or SD in the
> DC when downgrading.

other than ovirt/rhevm one of course.


From vszocs at redhat.com  Wed Mar 12 11:05:48 2014
From: vszocs at redhat.com (Vojtech Szocs)
Date: Wed, 12 Mar 2014 07:05:48 -0400 (EDT)
Subject: [Engine-devel] Small suggestions for engine-log-collector
In-Reply-To: <651261410.16892578.1394561588396.JavaMail.zimbra@redhat.com>
References: <800022326.17517459.1394560631804.JavaMail.zimbra@redhat.com>
	<651261410.16892578.1394561588396.JavaMail.zimbra@redhat.com>
Message-ID: <41806725.17946913.1394622348436.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Keith Robertson" <kroberts at redhat.com>
> To: "Vojtech Szocs" <vszocs at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Einav Cohen" <ecohen at redhat.com>, "Sandro Bonazzola"
> <sbonazzo at redhat.com>
> Sent: Tuesday, March 11, 2014 7:13:08 PM
> Subject: Re: Small suggestions for engine-log-collector
> 
> 
> 
> ----- Original Message -----
> > From: "Vojtech Szocs" <vszocs at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Cc: "Keith Robertson" <kroberts at redhat.com>, "Einav Cohen"
> > <ecohen at redhat.com>
> > Sent: Tuesday, March 11, 2014 1:57:11 PM
> > Subject: Small suggestions for engine-log-collector
> > 
> > Hi guys,
> > 
> > based on my testing during last week's oVirt 3.4 RC test day [1],
> > I have a couple of small suggestions for engine-log-collector:
> > 
> > 1, in /etc/ovirt-engine/logcollector.conf - I think there's typo:
> > 
> >       #key-file=/etc/pki/engine/keys/engine_id_rsa
> > 
> >    should be:
> > 
> >       #key-file=/etc/pki/ovirt-engine/keys/engine_id_rsa
> > 
> 
> ACK

http://gerrit.ovirt.org/#/c/25653/

> 
> 
> > 2, to force password-based ssh auth, one has to do this:
> > 
> 
> In the normal scenario, the the ovirt user's public key should be installed
> into each hypervisor.  Unless something has changed as a part of the
> hypervisor registration process this should be something that we can depend
> upon.

My host was F19 VM added to oVirt Engine via WebAdmin GUI. I thought that
host deploy script should do the public key registration, though.

> 
> Clearly, there are edge cases where you need to collect logs from a
> hypervisor that isn't properly registered with the RHEV-M.  Was this your
> situation and how common do you think this scenario is?

It was either a misconfiguration on my part or that I skipped some step with
regard to public key registration.

> 
> >       engine-log-collector -k ""
> > 
> 
> Yes, you are nulling out the default value which causes the LC to prompt you
> for a PW.  Perhaps we should document this as opposed to supplying a
> specific option?  Sandro?

Well, the doc text says "If a identity file is not supplied..." which I
understood as not supplying option value (i.e. "") at all, but this was
just my understanding.

> 
> >    because running this:
> > 
> >       engine-log-collector -k
> > 
> >    returns error message:
> > 
> >       error: -k option requires an argument
> > 
> >    however, help for -k option mentions *supplying* the argument:
> > 
> >       If a identity file is not supplied the program will prompt for a
> >       password.
> > 
> >    so either the help text should mention empty string,
> >    or -k option should allow missing argument (this was
> >    my initial understanding according to help text)
> > 
> > Since these are just small things, I'm wondering if I should
> > create RFE or if Keith/others can say if they are relevant.
> > 
> > Thanks,
> > Vojtech
> > 
> > [1] http://etherpad.ovirt.org/p/3.4-testday-3
> > 
> 


From vszocs at redhat.com  Wed Mar 12 11:27:19 2014
From: vszocs at redhat.com (Vojtech Szocs)
Date: Wed, 12 Mar 2014 07:27:19 -0400 (EDT)
Subject: [Engine-devel] REST API - where did bookmarks go?
In-Reply-To: <531F546B.8050104@redhat.com>
References: <281801554.17527047.1394561704228.JavaMail.zimbra@redhat.com>
	<531F546B.8050104@redhat.com>
Message-ID: <113223800.17954619.1394623639126.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Juan Hernandez" <jhernand at redhat.com>
> To: "Vojtech Szocs" <vszocs at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Cc: "Einav Cohen" <ecohen at redhat.com>
> Sent: Tuesday, March 11, 2014 7:22:35 PM
> Subject: Re: REST API - where did bookmarks go?
> 
> On 03/11/2014 07:15 PM, Vojtech Szocs wrote:
> > Hi guys,
> > 
> > as part of prototyping new JavaScript binding for oVirt REST API,
> > we chose a couple of business entities (resources) to experiment
> > with.
> > 
> > I just realized that requesting /ovirt-engine/api doesn't return
> > any information about bookmarks. Where did bookmarks go? Is it
> > possible to manage bookmarks through REST API?
> > 
> > Note: WebAdmin currently gets bookmarks through GWT RPC by calling
> > GetAllBookmarksQuery. Bookmark seems like proper backend business
> > entity (with DAO and everything) so it should be exposed also via
> > REST API.. or am I missing something?
> > 
> > Thanks,
> > Vojtech
> > 
> 
> The didn't go anywhere, just never existed in the API. Please open a RFE
> to add them.

Thanks, Juan. The RFE is here:

  https://bugzilla.redhat.com/1075556

> 
> --
> Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> 3?D, 28016 Madrid, Spain
> Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L.
> 


From lpeer at redhat.com  Wed Mar 12 11:32:26 2014
From: lpeer at redhat.com (Livnat Peer)
Date: Wed, 12 Mar 2014 13:32:26 +0200
Subject: [Engine-devel] Change in ovirt-engine[master]: core: enable to
 decrease DC compatibility...
In-Reply-To: <53203B43.9000409@redhat.com>
References: <gerrit.1392716300399.I73284f641b7f80b380b39efbbd7b4566f55119b6@gerrit.ovirt.org>	<201403112226.s2BMQpjX013721@gerrit.ovirt.org>	<53202FF4.6030004@redhat.com>	<53203A24.4040200@redhat.com>
	<53203B43.9000409@redhat.com>
Message-ID: <532045CA.6050601@redhat.com>

On 03/12/2014 12:47 PM, Itamar Heim wrote:
> On 03/12/2014 12:42 PM, Livnat Peer wrote:
>> In general I believe the use case for this patch is mostly for empty DCs
>> so for simplicity we should block it if there are networks or SD in the
>> DC when downgrading.
> 
> other than ovirt/rhevm one of course.

of course, the management network which is automatically created when
creating the DC can be there.

> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 



From kroberts at redhat.com  Wed Mar 12 12:38:13 2014
From: kroberts at redhat.com (Keith Robertson)
Date: Wed, 12 Mar 2014 08:38:13 -0400
Subject: [Engine-devel] Small suggestions for engine-log-collector
In-Reply-To: <41806725.17946913.1394622348436.JavaMail.zimbra@redhat.com>
References: <800022326.17517459.1394560631804.JavaMail.zimbra@redhat.com>
	<651261410.16892578.1394561588396.JavaMail.zimbra@redhat.com>
	<41806725.17946913.1394622348436.JavaMail.zimbra@redhat.com>
Message-ID: <53205535.60800@redhat.com>

On 03/12/2014 07:05 AM, Vojtech Szocs wrote:
>
>
> ----- Original Message -----
>> From: "Keith Robertson" <kroberts at redhat.com>
>> To: "Vojtech Szocs" <vszocs at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>, "Einav Cohen" <ecohen at redhat.com>, "Sandro Bonazzola"
>> <sbonazzo at redhat.com>
>> Sent: Tuesday, March 11, 2014 7:13:08 PM
>> Subject: Re: Small suggestions for engine-log-collector
>>
>>
>>
>> ----- Original Message -----
>>> From: "Vojtech Szocs" <vszocs at redhat.com>
>>> To: "engine-devel" <engine-devel at ovirt.org>
>>> Cc: "Keith Robertson" <kroberts at redhat.com>, "Einav Cohen"
>>> <ecohen at redhat.com>
>>> Sent: Tuesday, March 11, 2014 1:57:11 PM
>>> Subject: Small suggestions for engine-log-collector
>>>
>>> Hi guys,
>>>
>>> based on my testing during last week's oVirt 3.4 RC test day [1],
>>> I have a couple of small suggestions for engine-log-collector:
>>>
>>> 1, in /etc/ovirt-engine/logcollector.conf - I think there's typo:
>>>
>>>        #key-file=/etc/pki/engine/keys/engine_id_rsa
>>>
>>>     should be:
>>>
>>>        #key-file=/etc/pki/ovirt-engine/keys/engine_id_rsa
>>>
>>
>> ACK
>
> http://gerrit.ovirt.org/#/c/25653/
>
>>
>>
>>> 2, to force password-based ssh auth, one has to do this:
>>>
>>
>> In the normal scenario, the the ovirt user's public key should be installed
>> into each hypervisor.  Unless something has changed as a part of the
>> hypervisor registration process this should be something that we can depend
>> upon.
>
> My host was F19 VM added to oVirt Engine via WebAdmin GUI. I thought that
> host deploy script should do the public key registration, though.
>

I'm pretty sure that public key registration used to be part of the 
deploy script.  If this is no longer the case it is a fairly major 
supportability issue.

>>
>> Clearly, there are edge cases where you need to collect logs from a
>> hypervisor that isn't properly registered with the RHEV-M.  Was this your
>> situation and how common do you think this scenario is?
>
> It was either a misconfiguration on my part or that I skipped some step with
> regard to public key registration.
>

Understand.

The reason why we bias the LC towards public key auth and fall back to 
PW auth is that the LC needs to make multiple calls[1] to each 
Hypervisor and, if you're not using public key auth it is definitely a 
sub-optimal usage experience.  Multiply [1] times the N number of 
hyper-visors and the user's annoyance factor will surely reach a boiling 
point. ;)

[1]
- 1 ssh call to launch sos
- 1 sftp call to get the report and remove it from /tmp





>>
>>>        engine-log-collector -k ""
>>>
>>
>> Yes, you are nulling out the default value which causes the LC to prompt you
>> for a PW.  Perhaps we should document this as opposed to supplying a
>> specific option?  Sandro?
>
> Well, the doc text says "If a identity file is not supplied..." which I
> understood as not supplying option value (i.e. "") at all, but this was
> just my understanding.
>

Your understanding is correct and you forced the tool not to find the 
default identity file with a clever null argument.

There's nothing wrong with this usage per-se and maybe we should either 
document it or provide an explicit option to force PW auth.

>>
>>>     because running this:
>>>
>>>        engine-log-collector -k
>>>
>>>     returns error message:
>>>
>>>        error: -k option requires an argument
>>>
>>>     however, help for -k option mentions *supplying* the argument:
>>>
>>>        If a identity file is not supplied the program will prompt for a
>>>        password.
>>>
>>>     so either the help text should mention empty string,
>>>     or -k option should allow missing argument (this was
>>>     my initial understanding according to help text)
>>>
>>> Since these are just small things, I'm wondering if I should
>>> create RFE or if Keith/others can say if they are relevant.
>>>
>>> Thanks,
>>> Vojtech
>>>
>>> [1] http://etherpad.ovirt.org/p/3.4-testday-3
>>>
>>


-- 
Keith Robertson
Supervisor, Software Engineering
Red Hat Subscription Engineering


From agrawalrohit92 at gmail.com  Wed Mar 12 13:49:01 2014
From: agrawalrohit92 at gmail.com (Rohit Agrawal)
Date: Wed, 12 Mar 2014 19:19:01 +0530
Subject: [Engine-devel] Dependency checking tool
Message-ID: <CAEUeGp7ioETv7wRg0h+=S+M3d3zE52R5ygHUMAvOG7aM=PFfpg@mail.gmail.com>

hi,
i am now trying to make some changes in ovirt engine code for which i neede
to see the dependency.
As there are many pom.xml files. Is there any dependency tool to see all
the dependency.

-- 
Regards,
rohit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140312/85878a6b/attachment.html>

From awels at redhat.com  Wed Mar 12 13:53:47 2014
From: awels at redhat.com (Alexander Wels)
Date: Wed, 12 Mar 2014 09:53:47 -0400
Subject: [Engine-devel] Dependency checking tool
In-Reply-To: <CAEUeGp7ioETv7wRg0h+=S+M3d3zE52R5ygHUMAvOG7aM=PFfpg@mail.gmail.com>
References: <CAEUeGp7ioETv7wRg0h+=S+M3d3zE52R5ygHUMAvOG7aM=PFfpg@mail.gmail.com>
Message-ID: <2575735.57VcTU7chS@awels>

Rohit,

You can run 

mvn dependency:tree -Dverbose

To see the entire dependency tree.

On Wednesday, March 12, 2014 07:19:01 PM Rohit Agrawal wrote:
> hi,
> i am now trying to make some changes in ovirt engine code for which i 
neede
> to see the dependency.
> As there are many pom.xml files. Is there any dependency tool to see 
all
> the dependency.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140312/4e55d9f7/attachment.html>

From gshereme at redhat.com  Wed Mar 12 16:35:39 2014
From: gshereme at redhat.com (Greg Sheremeta)
Date: Wed, 12 Mar 2014 12:35:39 -0400 (EDT)
Subject: [Engine-devel] Dependency checking tool
In-Reply-To: <CAEUeGp7ioETv7wRg0h+=S+M3d3zE52R5ygHUMAvOG7aM=PFfpg@mail.gmail.com>
References: <CAEUeGp7ioETv7wRg0h+=S+M3d3zE52R5ygHUMAvOG7aM=PFfpg@mail.gmail.com>
Message-ID: <515377229.9303982.1394642139979.JavaMail.zimbra@redhat.com>

mvn dependency:tree 

Greg 

----- Original Message -----

> From: "Rohit Agrawal" <agrawalrohit92 at gmail.com>
> To: engine-devel at ovirt.org
> Sent: Wednesday, March 12, 2014 9:49:01 AM
> Subject: [Engine-devel] Dependency checking tool

> hi,
> i am now trying to make some changes in ovirt engine code for which i neede
> to see the dependency.
> As there are many pom.xml files. Is there any dependency tool to see all the
> dependency.

> --
> Regards,
> rohit

> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140312/b128f5b2/attachment.html>

From masayag at redhat.com  Wed Mar 12 20:20:52 2014
From: masayag at redhat.com (Moti Asayag)
Date: Wed, 12 Mar 2014 16:20:52 -0400 (EDT)
Subject: [Engine-devel] Change in ovirt-engine[master]: core: enable
	to	decrease DC compatibility...
In-Reply-To: <53203A24.4040200@redhat.com>
References: <gerrit.1392716300399.I73284f641b7f80b380b39efbbd7b4566f55119b6@gerrit.ovirt.org>
	<201403112226.s2BMQpjX013721@gerrit.ovirt.org>
	<53202FF4.6030004@redhat.com> <53203A24.4040200@redhat.com>
Message-ID: <852680674.2850211.1394655652908.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
> Sent: Wednesday, March 12, 2014 12:42:44 PM
> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to	decrease DC compatibility...
> 
> On 03/12/2014 11:59 AM, Itamar Heim wrote:
> > On 03/12/2014 12:26 AM, emesika at redhat.com wrote:
> >> Eli Mesika has submitted this change and it was merged.
> >>
> >> Change subject: core: enable to decrease DC compatibility...
> >> ......................................................................
> >>
> >>
> >> core: enable to decrease DC compatibility...
> >>
> >> enable to decrease DC compatibility version if DC has no clusters
> >>
> >> This patch enables to decrease the DC compatibility version if DC has no
> >> clusters.
> > 
> > Eli - just saw this. I'm pretty sure it would be *bad* to downgrade a DC
> > version if it has storage domains as well. not sure if this is checked
> > already or not.
> > 
> > may also be an issue with some logical network features.
> > 
> 
> Most of the network features are driven from cluster level, we enable
> using the features on all DC level (actually >=3.1) but actually enable
> /disable the feature when attaching the network to a cluster.
> 
> So from network perspective I think it should be fine to downgrade the
> DC level even if there are networks in the DC (at least now this could
> change in future versions).
> 

Actually we block adding or updating networks if the feature is not supported
on the network's DC level, for example: STP, Jumbo frames and non-vm network.

Therefore if the management network was configured with any of those feature,
there is a need to either block the action or to 'initialize' the network to
the default settings (as new network being added).

> In general I believe the use case for this patch is mostly for empty DCs
> so for simplicity we should block it if there are networks or SD in the
> DC when downgrading.
> 
> Livnat
> 
> 
> >>
> >> Change-Id: I73284f641b7f80b380b39efbbd7b4566f55119b6
> >> Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1057029
> >> Signed-off-by: Eli Mesika <emesika at redhat.com>
> >> ---
> >> M
> >> backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/storage/UpdateStoragePoolCommand.java
> >>
> >> 1 file changed, 5 insertions(+), 2 deletions(-)
> >>
> >> Approvals:
> >>    Eli Mesika: Verified
> >>    Ravi Nori: Looks good to me, but someone else must approve
> >>    Yair Zaslavsky: Looks good to me, approved
> >>
> >>
> >>
> > 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From masayag at redhat.com  Wed Mar 12 20:26:01 2014
From: masayag at redhat.com (Moti Asayag)
Date: Wed, 12 Mar 2014 16:26:01 -0400 (EDT)
Subject: [Engine-devel] Dependency checking tool
In-Reply-To: <CAEUeGp7ioETv7wRg0h+=S+M3d3zE52R5ygHUMAvOG7aM=PFfpg@mail.gmail.com>
References: <CAEUeGp7ioETv7wRg0h+=S+M3d3zE52R5ygHUMAvOG7aM=PFfpg@mail.gmail.com>
Message-ID: <604504430.2852784.1394655961197.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Rohit Agrawal" <agrawalrohit92 at gmail.com>
> To: engine-devel at ovirt.org
> Sent: Wednesday, March 12, 2014 3:49:01 PM
> Subject: [Engine-devel] Dependency checking tool
> 
> hi,
> i am now trying to make some changes in ovirt engine code for which i neede
> to see the dependency.
> As there are many pom.xml files. Is there any dependency tool to see all the
> dependency.
> 

If you're using eclipe - with the m2e (maven eclipse integration) plugin, you can click on
the pom.xml and view the specific project dependencies and their hierarchies.

Intellij should have also dependency viewer (haven't tried it though).

> --
> Regards,
> rohit
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From lpeer at redhat.com  Wed Mar 12 20:33:45 2014
From: lpeer at redhat.com (Livnat Peer)
Date: Wed, 12 Mar 2014 22:33:45 +0200
Subject: [Engine-devel] Change in ovirt-engine[master]: core: enable to
 decrease DC compatibility...
In-Reply-To: <852680674.2850211.1394655652908.JavaMail.zimbra@redhat.com>
References: <gerrit.1392716300399.I73284f641b7f80b380b39efbbd7b4566f55119b6@gerrit.ovirt.org>
	<201403112226.s2BMQpjX013721@gerrit.ovirt.org>
	<53202FF4.6030004@redhat.com> <53203A24.4040200@redhat.com>
	<852680674.2850211.1394655652908.JavaMail.zimbra@redhat.com>
Message-ID: <5320C4A9.5010209@redhat.com>

On 03/12/2014 10:20 PM, Moti Asayag wrote:
> 
> 
> ----- Original Message -----
>> From: "Livnat Peer" <lpeer at redhat.com>
>> To: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
>> Sent: Wednesday, March 12, 2014 12:42:44 PM
>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to	decrease DC compatibility...
>>
>> On 03/12/2014 11:59 AM, Itamar Heim wrote:
>>> On 03/12/2014 12:26 AM, emesika at redhat.com wrote:
>>>> Eli Mesika has submitted this change and it was merged.
>>>>
>>>> Change subject: core: enable to decrease DC compatibility...
>>>> ......................................................................
>>>>
>>>>
>>>> core: enable to decrease DC compatibility...
>>>>
>>>> enable to decrease DC compatibility version if DC has no clusters
>>>>
>>>> This patch enables to decrease the DC compatibility version if DC has no
>>>> clusters.
>>>
>>> Eli - just saw this. I'm pretty sure it would be *bad* to downgrade a DC
>>> version if it has storage domains as well. not sure if this is checked
>>> already or not.
>>>
>>> may also be an issue with some logical network features.
>>>
>>
>> Most of the network features are driven from cluster level, we enable
>> using the features on all DC level (actually >=3.1) but actually enable
>> /disable the feature when attaching the network to a cluster.
>>
>> So from network perspective I think it should be fine to downgrade the
>> DC level even if there are networks in the DC (at least now this could
>> change in future versions).
>>
> 
> Actually we block adding or updating networks if the feature is not supported
> on the network's DC level, for example: STP, Jumbo frames and non-vm network.
> 

>From which DC level we support STP?  Jumbo frames? non-vm network? isn't
all of them supported in >=3.1 ?

> Therefore if the management network was configured with any of those feature,
> there is a need to either block the action or to 'initialize' the network to
> the default settings (as new network being added).
> 
>> In general I believe the use case for this patch is mostly for empty DCs
>> so for simplicity we should block it if there are networks or SD in the
>> DC when downgrading.
>>
>> Livnat
>>
>>
>>>>
>>>> Change-Id: I73284f641b7f80b380b39efbbd7b4566f55119b6
>>>> Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1057029
>>>> Signed-off-by: Eli Mesika <emesika at redhat.com>
>>>> ---
>>>> M
>>>> backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/storage/UpdateStoragePoolCommand.java
>>>>
>>>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>>>
>>>> Approvals:
>>>>    Eli Mesika: Verified
>>>>    Ravi Nori: Looks good to me, but someone else must approve
>>>>    Yair Zaslavsky: Looks good to me, approved
>>>>
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>



From masayag at redhat.com  Wed Mar 12 20:44:07 2014
From: masayag at redhat.com (Moti Asayag)
Date: Wed, 12 Mar 2014 16:44:07 -0400 (EDT)
Subject: [Engine-devel] Change in ovirt-engine[master]: core: enable to
 decrease DC compatibility...
In-Reply-To: <5320C4A9.5010209@redhat.com>
References: <gerrit.1392716300399.I73284f641b7f80b380b39efbbd7b4566f55119b6@gerrit.ovirt.org>
	<201403112226.s2BMQpjX013721@gerrit.ovirt.org>
	<53202FF4.6030004@redhat.com> <53203A24.4040200@redhat.com>
	<852680674.2850211.1394655652908.JavaMail.zimbra@redhat.com>
	<5320C4A9.5010209@redhat.com>
Message-ID: <577568761.2861329.1394657047677.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Moti Asayag" <masayag at redhat.com>
> Cc: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
> Sent: Wednesday, March 12, 2014 10:33:45 PM
> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...
> 
> On 03/12/2014 10:20 PM, Moti Asayag wrote:
> > 
> > 
> > ----- Original Message -----
> >> From: "Livnat Peer" <lpeer at redhat.com>
> >> To: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
> >> Sent: Wednesday, March 12, 2014 12:42:44 PM
> >> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable
> >> to	decrease DC compatibility...
> >>
> >> On 03/12/2014 11:59 AM, Itamar Heim wrote:
> >>> On 03/12/2014 12:26 AM, emesika at redhat.com wrote:
> >>>> Eli Mesika has submitted this change and it was merged.
> >>>>
> >>>> Change subject: core: enable to decrease DC compatibility...
> >>>> ......................................................................
> >>>>
> >>>>
> >>>> core: enable to decrease DC compatibility...
> >>>>
> >>>> enable to decrease DC compatibility version if DC has no clusters
> >>>>
> >>>> This patch enables to decrease the DC compatibility version if DC has no
> >>>> clusters.
> >>>
> >>> Eli - just saw this. I'm pretty sure it would be *bad* to downgrade a DC
> >>> version if it has storage domains as well. not sure if this is checked
> >>> already or not.
> >>>
> >>> may also be an issue with some logical network features.
> >>>
> >>
> >> Most of the network features are driven from cluster level, we enable
> >> using the features on all DC level (actually >=3.1) but actually enable
> >> /disable the feature when attaching the network to a cluster.
> >>
> >> So from network perspective I think it should be fine to downgrade the
> >> DC level even if there are networks in the DC (at least now this could
> >> change in future versions).
> >>
> > 
> > Actually we block adding or updating networks if the feature is not
> > supported
> > on the network's DC level, for example: STP, Jumbo frames and non-vm
> > network.
> > 
> 
> From which DC level we support STP?  Jumbo frames? non-vm network? isn't
> all of them supported in >=3.1 ?
> 

Yes, mainly the problem with downgrading a DC to 3.0.

> > Therefore if the management network was configured with any of those
> > feature,
> > there is a need to either block the action or to 'initialize' the network
> > to
> > the default settings (as new network being added).
> > 
> >> In general I believe the use case for this patch is mostly for empty DCs
> >> so for simplicity we should block it if there are networks or SD in the
> >> DC when downgrading.
> >>
> >> Livnat
> >>
> >>
> >>>>
> >>>> Change-Id: I73284f641b7f80b380b39efbbd7b4566f55119b6
> >>>> Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1057029
> >>>> Signed-off-by: Eli Mesika <emesika at redhat.com>
> >>>> ---
> >>>> M
> >>>> backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/storage/UpdateStoragePoolCommand.java
> >>>>
> >>>> 1 file changed, 5 insertions(+), 2 deletions(-)
> >>>>
> >>>> Approvals:
> >>>>    Eli Mesika: Verified
> >>>>    Ravi Nori: Looks good to me, but someone else must approve
> >>>>    Yair Zaslavsky: Looks good to me, approved
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> 
> 


From sbonazzo at redhat.com  Thu Mar 13 12:27:46 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Thu, 13 Mar 2014 13:27:46 +0100
Subject: [Engine-devel] Small suggestions for engine-log-collector
In-Reply-To: <651261410.16892578.1394561588396.JavaMail.zimbra@redhat.com>
References: <800022326.17517459.1394560631804.JavaMail.zimbra@redhat.com>
	<651261410.16892578.1394561588396.JavaMail.zimbra@redhat.com>
Message-ID: <5321A442.1030307@redhat.com>

Il 11/03/2014 19:13, Keith Robertson ha scritto:
> 
> 
> ----- Original Message -----
>> From: "Vojtech Szocs" <vszocs at redhat.com> To: "engine-devel" <engine-devel at ovirt.org> Cc: "Keith Robertson" <kroberts at redhat.com>, "Einav Cohen"
>> <ecohen at redhat.com> Sent: Tuesday, March 11, 2014 1:57:11 PM Subject: Small suggestions for engine-log-collector
>> 
>> Hi guys,
>> 
>> based on my testing during last week's oVirt 3.4 RC test day [1], I have a couple of small suggestions for engine-log-collector:
>> 
>> 1, in /etc/ovirt-engine/logcollector.conf - I think there's typo:
>> 
>> #key-file=/etc/pki/engine/keys/engine_id_rsa
>> 
>> should be:
>> 
>> #key-file=/etc/pki/ovirt-engine/keys/engine_id_rsa
>> 
> 
> ACK

merged.


> 
> 
>> 2, to force password-based ssh auth, one has to do this:
>> 
> 
> In the normal scenario, the the ovirt user's public key should be installed into each hypervisor.  Unless something has changed as a part of the
> hypervisor registration process this should be something that we can depend upon.
> 
> Clearly, there are edge cases where you need to collect logs from a hypervisor that isn't properly registered with the RHEV-M.  Was this your
> situation and how common do you think this scenario is?
> 
>> engine-log-collector -k ""
>> 
> 
> Yes, you are nulling out the default value which causes the LC to prompt you for a PW.  Perhaps we should document this as opposed to supplying a
> specific option?  Sandro?

yes, maybe a better explanation in man page. Vojtech have you opened a bz about that?
Thanks for the report and for the patch you submitted!

> 
>> because running this:
>> 
>> engine-log-collector -k
>> 
>> returns error message:
>> 
>> error: -k option requires an argument
>> 
>> however, help for -k option mentions *supplying* the argument:
>> 
>> If a identity file is not supplied the program will prompt for a password.
>> 
>> so either the help text should mention empty string, or -k option should allow missing argument (this was my initial understanding according to
>> help text)
>> 
>> Since these are just small things, I'm wondering if I should create RFE or if Keith/others can say if they are relevant.
>> 
>> Thanks, Vojtech
>> 
>> [1] http://etherpad.ovirt.org/p/3.4-testday-3
>> 


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From jmoskovc at redhat.com  Thu Mar 13 13:27:11 2014
From: jmoskovc at redhat.com (Jiri Moskovcak)
Date: Thu, 13 Mar 2014 14:27:11 +0100
Subject: [Engine-devel] hosted engine in 3.4
Message-ID: <5321B22F.2000408@redhat.com>

Hi,
I was testing the hosted-engine in 3.4 and ran into some troubles, so 
I'm going to share the results to get some help (or ideas how to fix 
those problems)

Minor:
1. You need to have some MAC address with static ip and FQDN, otherwise 
you have to change /etc/hosts at least for the first part of the setup

- I think the setup wizard should be improved to do this workaround 
automatically

2. When the VM install is complete I would expect the setup wizard to 
install the engine to the VM automatically - which at least in my case - 
doesn't happen

- I found a mallformed fedora-virt-prerelease.repoo file on the 
installed vm, which might be the cause: 
https://bugzilla.redhat.com/show_bug.cgi?id=1075963

Major:
1. once I managed to install the engine to the vm it tried to add the 
host it was running on to the engine and it failed with a message "Host 
compatibility version doesn't match the cluster compatibility version", 
and then it marked the host as non operational which killed the vm with 
the engine, so the engine actually committed suicide...

- the host and the engine were installed from the same repo, so I guess 
the incompatibility was caused by the CPU family, and even if I made the 
mistake I think the engine should be a bit more clever and not kill itself


--Jirka



From didi at redhat.com  Thu Mar 13 13:54:09 2014
From: didi at redhat.com (Yedidyah Bar David)
Date: Thu, 13 Mar 2014 09:54:09 -0400 (EDT)
Subject: [Engine-devel] hosted engine in 3.4
In-Reply-To: <5321B22F.2000408@redhat.com>
References: <5321B22F.2000408@redhat.com>
Message-ID: <1585193153.19831369.1394718849438.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Jiri Moskovcak" <jmoskovc at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, March 13, 2014 3:27:11 PM
> Subject: [Engine-devel] hosted engine in 3.4
> 
> Hi,
> I was testing the hosted-engine in 3.4 and ran into some troubles, so
> I'm going to share the results to get some help (or ideas how to fix
> those problems)
> 
> Minor:
> 1. You need to have some MAC address with static ip and FQDN, otherwise
> you have to change /etc/hosts at least for the first part of the setup
> 
> - I think the setup wizard should be improved to do this workaround
> automatically

Not sure what you refer to - the host? VM? Both?

deploy lets you change the MAC for the VM if you want, and also shows you
the random MAC it have chosen. Both of these should allow you to config
your dhcp/dns server at that point and have the VM automatically get the
right ip/hostname during OS installation.

Not sure what you mean exactly - we never edit /etc/hosts files, and
generally expect a stable dhcp/dns installation. That's true also for a
normal engine installation.

> 
> 2. When the VM install is complete I would expect the setup wizard to
> install the engine to the VM automatically - which at least in my case -
> doesn't happen

We intend to supply some image (iso/ovf) that will include everything
needed. Not sure when this will be ready. For the time being, you do
everything by yourself - install the OS, add repos, install and setup
the engine, etc. Note that you can choose network boot and make everything
automated.

> 
> - I found a mallformed fedora-virt-prerelease.repoo file on the
> installed vm, which might be the cause:
> https://bugzilla.redhat.com/show_bug.cgi?id=1075963
> 
> Major:
> 1. once I managed to install the engine to the vm it tried to add the
> host it was running on to the engine and it failed with a message "Host
> compatibility version doesn't match the cluster compatibility version",
> and then it marked the host as non operational which killed the vm with
> the engine, so the engine actually committed suicide...
> 
> - the host and the engine were installed from the same repo, so I guess
> the incompatibility was caused by the CPU family, and even if I made the

That's probably because you have a problem with the repo (as pointed above)
and install different versions on the host and VM.

> mistake I think the engine should be a bit more clever and not kill itself

I might agree here, but generally this should not happen.

You are of course more than welcome to open bugs where relevant!
-- 
Didi


From sbonazzo at redhat.com  Thu Mar 13 13:56:37 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Thu, 13 Mar 2014 14:56:37 +0100
Subject: [Engine-devel] hosted engine in 3.4
In-Reply-To: <5321B22F.2000408@redhat.com>
References: <5321B22F.2000408@redhat.com>
Message-ID: <5321B915.9070405@redhat.com>

Il 13/03/2014 14:27, Jiri Moskovcak ha scritto:
> Hi,
> I was testing the hosted-engine in 3.4 and ran into some troubles, so I'm going to share the results to get some help (or ideas how to fix those
> problems)

Hi, thanks for testing Hosted Engine

> 
> Minor:
> 1. You need to have some MAC address with static ip and FQDN, otherwise you have to change /etc/hosts at least for the first part of the setup
> 
> - I think the setup wizard should be improved to do this workaround automatically

Well, you can have DHCP and DNS configured before starting the deploy process and assign the MAC address to the VM you're going to create for getting
the right IP and avoid to use /etc/hosts.

But yes, otherwise you need to use static IPs and configure /etc/hosts accordingly.


> 
> 2. When the VM install is complete I would expect the setup wizard to install the engine to the VM automatically - which at least in my case - doesn't
> happen


No, it's a manual step, there's no automation for doing that yet.

> 
> - I found a mallformed fedora-virt-prerelease.repoo file on the installed vm, which might be the cause:
> https://bugzilla.redhat.com/show_bug.cgi?id=1075963

Can't reproduce the issue, closed as works for me, please reopen it if you can provide a sequence for reproducing it.

> 
> Major:
> 1. once I managed to install the engine to the vm it tried to add the host it was running on to the engine and it failed with a message "Host
> compatibility version doesn't match the cluster compatibility version", and then it marked the host as non operational which killed the vm with the
> engine, so the engine actually committed suicide...

this is indeed due to malformed fedora-virt-prerelease.repoo. You had VDSM running in 3.3 compatibility mode because you're missing latest libvirt
while the engine is running a cluster in 3.4 compatibility mode.


> 
> - the host and the engine were installed from the same repo, so I guess the incompatibility was caused by the CPU family, and even if I made the
> mistake I think the engine should be a bit more clever and not kill itself

I think that we can add a check on vdsm compatibility level and create the engine cluster with the same level, not assuming that people are running
latest libvirt.
BTW I'm not sure about implications in running Hosted Engine in 3.3 compatibility mode.
CCing VDSM people.

> 
> 
> --Jirka
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From gshereme at redhat.com  Thu Mar 13 15:02:15 2014
From: gshereme at redhat.com (Greg Sheremeta)
Date: Thu, 13 Mar 2014 11:02:15 -0400 (EDT)
Subject: [Engine-devel] attn ui devs: why do we use inputs for labels?
In-Reply-To: <1106090098.9594351.1394722606183.JavaMail.zimbra@redhat.com>
Message-ID: <1740187465.9597169.1394722935614.JavaMail.zimbra@redhat.com>

Hi fellow UI developers,

Can someone explain why we are using "input type=text" fields to render labels? (see screenshot[1]) This seems like bad practice for a few reasons:
 * it's not semantic HTML
 * inputs do not have variable sizing like text. They cannot shrink down to the size of the text, which makes positioning difficult.
 * common browser extensions such as LastPass can be confused (see screenshot[1] -- lastpass sees these labels for the text fields they are, and attempts to help the user fill them in -- that's what those gray asterisks are. Very confusing.)

I'd like to pursue correcting this, if possible.

Thanks,
Greg

[1] http://i.imgur.com/AweOhJe.png

Greg Sheremeta
Red Hat, Inc.
Sr. Software Engineer, RHEV
Cell: 919-807-1086
gshereme at redhat.com


From jmoskovc at redhat.com  Thu Mar 13 14:10:04 2014
From: jmoskovc at redhat.com (Jiri Moskovcak)
Date: Thu, 13 Mar 2014 15:10:04 +0100
Subject: [Engine-devel] hosted engine in 3.4
In-Reply-To: <1585193153.19831369.1394718849438.JavaMail.zimbra@redhat.com>
References: <5321B22F.2000408@redhat.com>
	<1585193153.19831369.1394718849438.JavaMail.zimbra@redhat.com>
Message-ID: <5321BC3C.5020305@redhat.com>

On 03/13/2014 02:54 PM, Yedidyah Bar David wrote:
> ----- Original Message -----
>> From: "Jiri Moskovcak" <jmoskovc at redhat.com>
>> To: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Thursday, March 13, 2014 3:27:11 PM
>> Subject: [Engine-devel] hosted engine in 3.4
>>
>> Hi,
>> I was testing the hosted-engine in 3.4 and ran into some troubles, so
>> I'm going to share the results to get some help (or ideas how to fix
>> those problems)
>>
>> Minor:
>> 1. You need to have some MAC address with static ip and FQDN, otherwise
>> you have to change /etc/hosts at least for the first part of the setup
>>
>> - I think the setup wizard should be improved to do this workaround
>> automatically
>
> Not sure what you refer to - the host? VM? Both?
>
> deploy lets you change the MAC for the VM if you want, and also shows you
> the random MAC it have chosen. Both of these should allow you to config
> your dhcp/dns server at that point and have the VM automatically get the
> right ip/hostname during OS installation.
>
> Not sure what you mean exactly - we never edit /etc/hosts files, and
> generally expect a stable dhcp/dns installation. That's true also for a
> normal engine installation.
>

- the VM, I was in the situation where I didn't have the chance to 
change the dhcp config at the time when I was installing the VM, so the 
only way for me was to change the /etc/hosts to cheat the setup wizard

>>
>> 2. When the VM install is complete I would expect the setup wizard to
>> install the engine to the VM automatically - which at least in my case -
>> doesn't happen
>
> We intend to supply some image (iso/ovf) that will include everything
> needed. Not sure when this will be ready. For the time being, you do
> everything by yourself - install the OS, add repos, install and setup
> the engine, etc. Note that you can choose network boot and make everything
> automated.
>

- I'm talking about the engine install inside the VM. I have the VM with 
the os, so the hosted-engine-setup can ask for the root password and 
simply install all the packages and configure the engine (I don't 
consider this a bug more like a idea for improvements)

>>
>> - I found a mallformed fedora-virt-prerelease.repoo file on the
>> installed vm, which might be the cause:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1075963
>>
>> Major:
>> 1. once I managed to install the engine to the vm it tried to add the
>> host it was running on to the engine and it failed with a message "Host
>> compatibility version doesn't match the cluster compatibility version",
>> and then it marked the host as non operational which killed the vm with
>> the engine, so the engine actually committed suicide...
>>
>> - the host and the engine were installed from the same repo, so I guess
>> the incompatibility was caused by the CPU family, and even if I made the
>
> That's probably because you have a problem with the repo (as pointed above)
> and install different versions on the host and VM.

- no, when I found the broken repo file I've fixed it to use the same as 
the host and only after that I've installed the engine

>
>> mistake I think the engine should be a bit more clever and not kill itself
>
> I might agree here, but generally this should not happen.
>
> You are of course more than welcome to open bugs where relevant!
>

I will, just want to try that once more, to get more details.

Thanks,
Jirka



From ecohen at redhat.com  Thu Mar 13 16:14:51 2014
From: ecohen at redhat.com (Einav Cohen)
Date: Thu, 13 Mar 2014 12:14:51 -0400 (EDT)
Subject: [Engine-devel] attn ui devs: why do we use inputs for labels?
In-Reply-To: <1740187465.9597169.1394722935614.JavaMail.zimbra@redhat.com>
References: <1740187465.9597169.1394722935614.JavaMail.zimbra@redhat.com>
Message-ID: <1579791205.26836676.1394727291548.JavaMail.zimbra@redhat.com>

I could be wrong, but there is a chance that using "input type=text" 
allows selecting/copying the text, rather than a plain label, which 
doesn't allow that. 

I am not sure if there are any (additional?) advantages to using 
"input type=text" (the other UI maintainers will probably know 
better). 

> I'd like to pursue correcting this, if possible.

if there is a more "correct" way that won't result in losing any 
existing functionality, +1. 

----
Thanks,
Einav

----- Original Message -----
> From: "Greg Sheremeta" <gshereme at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, March 13, 2014 11:02:15 AM
> Subject: [Engine-devel] attn ui devs: why do we use inputs for labels?
> 
> Hi fellow UI developers,
> 
> Can someone explain why we are using "input type=text" fields to render
> labels? (see screenshot[1]) This seems like bad practice for a few reasons:
>  * it's not semantic HTML
>  * inputs do not have variable sizing like text. They cannot shrink down to
>  the size of the text, which makes positioning difficult.
>  * common browser extensions such as LastPass can be confused (see
>  screenshot[1] -- lastpass sees these labels for the text fields they are,
>  and attempts to help the user fill them in -- that's what those gray
>  asterisks are. Very confusing.)
> 
> I'd like to pursue correcting this, if possible.
> 
> Thanks,
> Greg
> 
> [1] http://i.imgur.com/AweOhJe.png
> 
> Greg Sheremeta
> Red Hat, Inc.
> Sr. Software Engineer, RHEV
> Cell: 919-807-1086
> gshereme at redhat.com
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From gshereme at redhat.com  Thu Mar 13 16:24:51 2014
From: gshereme at redhat.com (Greg Sheremeta)
Date: Thu, 13 Mar 2014 12:24:51 -0400 (EDT)
Subject: [Engine-devel] attn ui devs: why do we use inputs for labels?
In-Reply-To: <1579791205.26836676.1394727291548.JavaMail.zimbra@redhat.com>
References: <1740187465.9597169.1394722935614.JavaMail.zimbra@redhat.com>
	<1579791205.26836676.1394727291548.JavaMail.zimbra@redhat.com>
Message-ID: <2025637929.9623264.1394727891708.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "Greg Sheremeta" <gshereme at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, March 13, 2014 12:14:51 PM
> Subject: Re: [Engine-devel] attn ui devs: why do we use inputs for labels?
> 
> I could be wrong, but there is a chance that using "input type=text"
> allows selecting/copying the text, rather than a plain label, which
> doesn't allow that.

If that's the reason, it must be a quirky browser thing. I can select and copy <label>s in Chrome.

> 
> I am not sure if there are any (additional?) advantages to using
> "input type=text" (the other UI maintainers will probably know
> better).
> 
> > I'd like to pursue correcting this, if possible.
> 
> if there is a more "correct" way that won't result in losing any
> existing functionality, +1.
> 
> ----
> Thanks,
> Einav
> 
> ----- Original Message -----
> > From: "Greg Sheremeta" <gshereme at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Thursday, March 13, 2014 11:02:15 AM
> > Subject: [Engine-devel] attn ui devs: why do we use inputs for labels?
> > 
> > Hi fellow UI developers,
> > 
> > Can someone explain why we are using "input type=text" fields to render
> > labels? (see screenshot[1]) This seems like bad practice for a few reasons:
> >  * it's not semantic HTML
> >  * inputs do not have variable sizing like text. They cannot shrink down to
> >  the size of the text, which makes positioning difficult.
> >  * common browser extensions such as LastPass can be confused (see
> >  screenshot[1] -- lastpass sees these labels for the text fields they are,
> >  and attempts to help the user fill them in -- that's what those gray
> >  asterisks are. Very confusing.)
> > 
> > I'd like to pursue correcting this, if possible.
> > 
> > Thanks,
> > Greg
> > 
> > [1] http://i.imgur.com/AweOhJe.png
> > 
> > Greg Sheremeta
> > Red Hat, Inc.
> > Sr. Software Engineer, RHEV
> > Cell: 919-807-1086
> > gshereme at redhat.com
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From ecohen at redhat.com  Thu Mar 13 19:51:52 2014
From: ecohen at redhat.com (Einav Cohen)
Date: Thu, 13 Mar 2014 15:51:52 -0400 (EDT)
Subject: [Engine-devel] [Users] adding scripts
In-Reply-To: <CA+pz52-HBTeR_FAMysdRmaTbg-OkWtk==qY1vC5R8pbXK8=bBw@mail.gmail.com>
References: <CA+pz52-HBTeR_FAMysdRmaTbg-OkWtk==qY1vC5R8pbXK8=bBw@mail.gmail.com>
Message-ID: <1616824011.27085458.1394740312956.JavaMail.zimbra@redhat.com>

if you are trying to hook into UI-specific events, it sounds 
like you will need to write an oVirt UI Plugin [1] in order to 
do that. However, I believe that the oVirt UI Plugins 
infrastructure doesn't support hooking to events such as "tab 
x was selected" and/or "button b was clicked". 
It does allow you to add new (custom) tabs/sub-tabs/buttons of 
your own, and there is a chance that it allows you to hook 
into events such as 'row x was selected in the grid'. 

@Vojtech will know better. Vojtech?

if you are trying to hook into engine events (e.g. you want to 
run a script every time a VM is started in oVirt, no matter if 
the user started it by clicking the 'run' button in the oVirt-
engine webadmin, or invoked a REST API request, or an SDK 
command), then it will require some sort of an "engine-plugin" 
infrastructure that we don't have at the moment AFAIK. 
there is a chance that for some of the events you will be able 
to utilize the VDSM hooks (at the Host level) [2].

----
Thanks,
Einav

[1] http://www.ovirt.org/Features/UIPlugins

[2] http://www.ovirt.org/VDSM-Hooks


----- Original Message -----
> From: "aditya mamidwar" <aditya.mamidwar at gmail.com>
> To: users at ovirt.org, engine-devel at ovirt.org
> Sent: Thursday, March 13, 2014 11:23:35 AM
> Subject: [Users] adding scripts
> 
> 
> I want to commit changes to the engine by adding some bash scripts.
> the scripts should be invoked once a button or tab is selected in the
> webadmin portal by the user.
> 
> can someone guide on achieving this.
> 
> --
> -Aditya Mamidwar
> 
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 


From ecohen at redhat.com  Thu Mar 13 21:01:02 2014
From: ecohen at redhat.com (Einav Cohen)
Date: Thu, 13 Mar 2014 17:01:02 -0400 (EDT)
Subject: [Engine-devel] attn ui devs: why do we use inputs for labels?
In-Reply-To: <2025637929.9623264.1394727891708.JavaMail.zimbra@redhat.com>
References: <1740187465.9597169.1394722935614.JavaMail.zimbra@redhat.com>
	<1579791205.26836676.1394727291548.JavaMail.zimbra@redhat.com>
	<2025637929.9623264.1394727891708.JavaMail.zimbra@redhat.com>
Message-ID: <1481343871.27118035.1394744462354.JavaMail.zimbra@redhat.com>

> ----- Original Message -----
> From: "Greg Sheremeta" <gshereme at redhat.com>
> Sent: Thursday, March 13, 2014 12:24:51 PM
> 
> 
> 
> ----- Original Message -----
> > From: "Einav Cohen" <ecohen at redhat.com>
> > To: "Greg Sheremeta" <gshereme at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Thursday, March 13, 2014 12:14:51 PM
> > Subject: Re: [Engine-devel] attn ui devs: why do we use inputs for labels?
> > 
> > I could be wrong, but there is a chance that using "input type=text"
> > allows selecting/copying the text, rather than a plain label, which
> > doesn't allow that.
> 
> If that's the reason, it must be a quirky browser thing. I can select and
> copy <label>s in Chrome.

there is a good chance that you are right - maybe this used to be the 
behavior in old browsers. Do you happen to know what is the behavior 
in other (modern) browsers (FF, IE)?

ui maintainers: anything else that you know/recall about why we are 
using "input type=text" in our code? any reason to not change it?

> 
> > 
> > I am not sure if there are any (additional?) advantages to using
> > "input type=text" (the other UI maintainers will probably know
> > better).
> > 
> > > I'd like to pursue correcting this, if possible.
> > 
> > if there is a more "correct" way that won't result in losing any
> > existing functionality, +1.
> > 
> > ----
> > Thanks,
> > Einav
> > 
> > ----- Original Message -----
> > > From: "Greg Sheremeta" <gshereme at redhat.com>
> > > To: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Thursday, March 13, 2014 11:02:15 AM
> > > Subject: [Engine-devel] attn ui devs: why do we use inputs for labels?
> > > 
> > > Hi fellow UI developers,
> > > 
> > > Can someone explain why we are using "input type=text" fields to render
> > > labels? (see screenshot[1]) This seems like bad practice for a few
> > > reasons:
> > >  * it's not semantic HTML
> > >  * inputs do not have variable sizing like text. They cannot shrink down
> > >  to
> > >  the size of the text, which makes positioning difficult.
> > >  * common browser extensions such as LastPass can be confused (see
> > >  screenshot[1] -- lastpass sees these labels for the text fields they
> > >  are,
> > >  and attempts to help the user fill them in -- that's what those gray
> > >  asterisks are. Very confusing.)
> > > 
> > > I'd like to pursue correcting this, if possible.
> > > 
> > > Thanks,
> > > Greg
> > > 
> > > [1] http://i.imgur.com/AweOhJe.png
> > > 
> > > Greg Sheremeta
> > > Red Hat, Inc.
> > > Sr. Software Engineer, RHEV
> > > Cell: 919-807-1086
> > > gshereme at redhat.com
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
> 


From msivak at redhat.com  Fri Mar 14 09:13:01 2014
From: msivak at redhat.com (Martin Sivak)
Date: Fri, 14 Mar 2014 05:13:01 -0400 (EDT)
Subject: [Engine-devel] hosted engine in 3.4
In-Reply-To: <5321BC3C.5020305@redhat.com>
References: <5321B22F.2000408@redhat.com>
	<1585193153.19831369.1394718849438.JavaMail.zimbra@redhat.com>
	<5321BC3C.5020305@redhat.com>
Message-ID: <83505232.18075115.1394788381088.JavaMail.zimbra@redhat.com>

Hi,

> >> 1. You need to have some MAC address with static ip and FQDN, otherwise
> >> you have to change /etc/hosts at least for the first part of the setup

I believe you were there when we were discussing this with pstehlik :)

Btw in this case you have to change /etc/hosts on all hosts and inside the
engine VM.

> >> 2. When the VM install is complete I would expect the setup wizard to
> >> install the engine to the VM automatically - which at least in my case -
> >> doesn't happen

I also proposed kickstart based setup to Sandro. You would give a repo to setup
and it would download the kernel/initrd from it [1] and create a kickstart with
the right root password, engine setup and so on..

[1] http://ftp.linux.cz/pub/linux/fedora/linux/releases/20/Fedora/x86_64/os/images/pxeboot/

> >> 1. once I managed to install the engine to the vm it tried to add the
> >> host it was running on to the engine and it failed with a message "Host
> >> compatibility version doesn't match the cluster compatibility version",
> >> and then it marked the host as non operational which killed the vm with
> >> the engine, so the engine actually committed suicide?

Check your VDSM version. Especially the content of /usr/share/vdsm/dsaversion.py
file. There are couple of lists specifying the cluster and engine versions that
the VDSM supports.

If you use 3.4 engine it needs 3.4 VDSM as well.. and the prerelease repo is not
enabled by default.

> >> mistake I think the engine should be a bit more clever and not kill itself
> >

I think it is the VDSM that does the actual killing :)

But overall I agree, the setup is too fragile and I encountered all of the issues
when installing hosted engine for the first time too.

--
Martin Siv?k
msivak at redhat.com
Red Hat Czech
RHEV-M SLA / Brno, CZ



From sbonazzo at redhat.com  Fri Mar 14 09:17:29 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Fri, 14 Mar 2014 10:17:29 +0100
Subject: [Engine-devel] hosted engine in 3.4
In-Reply-To: <83505232.18075115.1394788381088.JavaMail.zimbra@redhat.com>
References: <5321B22F.2000408@redhat.com>	<1585193153.19831369.1394718849438.JavaMail.zimbra@redhat.com>	<5321BC3C.5020305@redhat.com>
	<83505232.18075115.1394788381088.JavaMail.zimbra@redhat.com>
Message-ID: <5322C929.2030200@redhat.com>

Il 14/03/2014 10:13, Martin Sivak ha scritto:
> Hi,
> 
>>>> 1. You need to have some MAC address with static ip and FQDN, otherwise
>>>> you have to change /etc/hosts at least for the first part of the setup
> 
> I believe you were there when we were discussing this with pstehlik :)
> 
> Btw in this case you have to change /etc/hosts on all hosts and inside the
> engine VM.
> 
>>>> 2. When the VM install is complete I would expect the setup wizard to
>>>> install the engine to the VM automatically - which at least in my case -
>>>> doesn't happen
> 
> I also proposed kickstart based setup to Sandro. You would give a repo to setup
> and it would download the kernel/initrd from it [1] and create a kickstart with
> the right root password, engine setup and so on..

Ohad is preparing an OVA for allowing a quick setup.
But feel free to open a RFE for the kickstart solution as well.

> 
> [1] http://ftp.linux.cz/pub/linux/fedora/linux/releases/20/Fedora/x86_64/os/images/pxeboot/
> 
>>>> 1. once I managed to install the engine to the vm it tried to add the
>>>> host it was running on to the engine and it failed with a message "Host
>>>> compatibility version doesn't match the cluster compatibility version",
>>>> and then it marked the host as non operational which killed the vm with
>>>> the engine, so the engine actually committed suicide?
> 
> Check your VDSM version. Especially the content of /usr/share/vdsm/dsaversion.py
> file. There are couple of lists specifying the cluster and engine versions that
> the VDSM supports.
> 
> If you use 3.4 engine it needs 3.4 VDSM as well.. and the prerelease repo is not
> enabled by default.
> 
>>>> mistake I think the engine should be a bit more clever and not kill itself
>>>
> 
> I think it is the VDSM that does the actual killing :)
> 
> But overall I agree, the setup is too fragile and I encountered all of the issues
> when installing hosted engine for the first time too.

Please be sure to have a BZ for each issue you encountered.
We'll try to address them.


> 
> --
> Martin Siv?k
> msivak at redhat.com
> Red Hat Czech
> RHEV-M SLA / Brno, CZ
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From jmoskovc at redhat.com  Fri Mar 14 09:22:19 2014
From: jmoskovc at redhat.com (Jiri Moskovcak)
Date: Fri, 14 Mar 2014 10:22:19 +0100
Subject: [Engine-devel] hosted engine in 3.4
In-Reply-To: <5322C929.2030200@redhat.com>
References: <5321B22F.2000408@redhat.com>	<1585193153.19831369.1394718849438.JavaMail.zimbra@redhat.com>	<5321BC3C.5020305@redhat.com>
	<83505232.18075115.1394788381088.JavaMail.zimbra@redhat.com>
	<5322C929.2030200@redhat.com>
Message-ID: <5322CA4B.9000105@redhat.com>

On 03/14/2014 10:17 AM, Sandro Bonazzola wrote:
> Il 14/03/2014 10:13, Martin Sivak ha scritto:
>> Hi,
>>
>>>>> 1. You need to have some MAC address with static ip and FQDN, otherwise
>>>>> you have to change /etc/hosts at least for the first part of the setup
>>
>> I believe you were there when we were discussing this with pstehlik :)
>>
>> Btw in this case you have to change /etc/hosts on all hosts and inside the
>> engine VM.
>>
>>>>> 2. When the VM install is complete I would expect the setup wizard to
>>>>> install the engine to the VM automatically - which at least in my case -
>>>>> doesn't happen
>>
>> I also proposed kickstart based setup to Sandro. You would give a repo to setup
>> and it would download the kernel/initrd from it [1] and create a kickstart with
>> the right root password, engine setup and so on..
>
> Ohad is preparing an OVA for allowing a quick setup.
> But feel free to open a RFE for the kickstart solution as well.
>
>>
>> [1] http://ftp.linux.cz/pub/linux/fedora/linux/releases/20/Fedora/x86_64/os/images/pxeboot/
>>
>>>>> 1. once I managed to install the engine to the vm it tried to add the
>>>>> host it was running on to the engine and it failed with a message "Host
>>>>> compatibility version doesn't match the cluster compatibility version",
>>>>> and then it marked the host as non operational which killed the vm with
>>>>> the engine, so the engine actually committed suicide?
>>
>> Check your VDSM version. Especially the content of /usr/share/vdsm/dsaversion.py
>> file. There are couple of lists specifying the cluster and engine versions that
>> the VDSM supports.
>>
>> If you use 3.4 engine it needs 3.4 VDSM as well.. and the prerelease repo is not
>> enabled by default.
>>
>>>>> mistake I think the engine should be a bit more clever and not kill itself
>>>>
>>
>> I think it is the VDSM that does the actual killing :)
>>
>> But overall I agree, the setup is too fragile and I encountered all of the issues
>> when installing hosted engine for the first time too.
>
> Please be sure to have a BZ for each issue you encountered.
> We'll try to address them.
>

Sure, I'm about to create them, btw, I'm a new developer assigned to the 
hosted-engine so I'll be probably fixing those issues with you :)

--Jirka

>
>>
>> --
>> Martin Siv?k
>> msivak at redhat.com
>> Red Hat Czech
>> RHEV-M SLA / Brno, CZ
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>
>



From sbonazzo at redhat.com  Fri Mar 14 09:27:55 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Fri, 14 Mar 2014 10:27:55 +0100
Subject: [Engine-devel] hosted engine in 3.4
In-Reply-To: <5322CA4B.9000105@redhat.com>
References: <5321B22F.2000408@redhat.com>	<1585193153.19831369.1394718849438.JavaMail.zimbra@redhat.com>	<5321BC3C.5020305@redhat.com>
	<83505232.18075115.1394788381088.JavaMail.zimbra@redhat.com>
	<5322C929.2030200@redhat.com> <5322CA4B.9000105@redhat.com>
Message-ID: <5322CB9B.30502@redhat.com>

Il 14/03/2014 10:22, Jiri Moskovcak ha scritto:
> On 03/14/2014 10:17 AM, Sandro Bonazzola wrote:
>> Il 14/03/2014 10:13, Martin Sivak ha scritto:
>>> Hi,
>>>
>>>>>> 1. You need to have some MAC address with static ip and FQDN, otherwise
>>>>>> you have to change /etc/hosts at least for the first part of the setup
>>>
>>> I believe you were there when we were discussing this with pstehlik :)
>>>
>>> Btw in this case you have to change /etc/hosts on all hosts and inside the
>>> engine VM.
>>>
>>>>>> 2. When the VM install is complete I would expect the setup wizard to
>>>>>> install the engine to the VM automatically - which at least in my case -
>>>>>> doesn't happen
>>>
>>> I also proposed kickstart based setup to Sandro. You would give a repo to setup
>>> and it would download the kernel/initrd from it [1] and create a kickstart with
>>> the right root password, engine setup and so on..
>>
>> Ohad is preparing an OVA for allowing a quick setup.
>> But feel free to open a RFE for the kickstart solution as well.
>>
>>>
>>> [1] http://ftp.linux.cz/pub/linux/fedora/linux/releases/20/Fedora/x86_64/os/images/pxeboot/
>>>
>>>>>> 1. once I managed to install the engine to the vm it tried to add the
>>>>>> host it was running on to the engine and it failed with a message "Host
>>>>>> compatibility version doesn't match the cluster compatibility version",
>>>>>> and then it marked the host as non operational which killed the vm with
>>>>>> the engine, so the engine actually committed suicide?
>>>
>>> Check your VDSM version. Especially the content of /usr/share/vdsm/dsaversion.py
>>> file. There are couple of lists specifying the cluster and engine versions that
>>> the VDSM supports.
>>>
>>> If you use 3.4 engine it needs 3.4 VDSM as well.. and the prerelease repo is not
>>> enabled by default.
>>>
>>>>>> mistake I think the engine should be a bit more clever and not kill itself
>>>>>
>>>
>>> I think it is the VDSM that does the actual killing :)
>>>
>>> But overall I agree, the setup is too fragile and I encountered all of the issues
>>> when installing hosted engine for the first time too.
>>
>> Please be sure to have a BZ for each issue you encountered.
>> We'll try to address them.
>>
> 
> Sure, I'm about to create them, btw, I'm a new developer assigned to the hosted-engine so I'll be probably fixing those issues with you :)

welcome aboard :-)

> 
> --Jirka
> 
>>
>>>
>>> -- 
>>> Martin Siv?k
>>> msivak at redhat.com
>>> Red Hat Czech
>>> RHEV-M SLA / Brno, CZ
>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>
>>
> 


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From jmoskovc at redhat.com  Fri Mar 14 09:39:31 2014
From: jmoskovc at redhat.com (Jiri Moskovcak)
Date: Fri, 14 Mar 2014 10:39:31 +0100
Subject: [Engine-devel] hosted engine in 3.4
In-Reply-To: <83505232.18075115.1394788381088.JavaMail.zimbra@redhat.com>
References: <5321B22F.2000408@redhat.com>
	<1585193153.19831369.1394718849438.JavaMail.zimbra@redhat.com>
	<5321BC3C.5020305@redhat.com>
	<83505232.18075115.1394788381088.JavaMail.zimbra@redhat.com>
Message-ID: <5322CE53.2060607@redhat.com>

On 03/14/2014 10:13 AM, Martin Sivak wrote:
> Hi,
>
>>>> 1. You need to have some MAC address with static ip and FQDN, otherwise
>>>> you have to change /etc/hosts at least for the first part of the setup
>
> I believe you were there when we were discussing this with pstehlik :)
>
> Btw in this case you have to change /etc/hosts on all hosts and inside the
> engine VM.
>
>>>> 2. When the VM install is complete I would expect the setup wizard to
>>>> install the engine to the VM automatically - which at least in my case -
>>>> doesn't happen
>
> I also proposed kickstart based setup to Sandro. You would give a repo to setup
> and it would download the kernel/initrd from it [1] and create a kickstart with
> the right root password, engine setup and so on..
>
> [1] http://ftp.linux.cz/pub/linux/fedora/linux/releases/20/Fedora/x86_64/os/images/pxeboot/
>
>>>> 1. once I managed to install the engine to the vm it tried to add the
>>>> host it was running on to the engine and it failed with a message "Host
>>>> compatibility version doesn't match the cluster compatibility version",
>>>> and then it marked the host as non operational which killed the vm with
>>>> the engine, so the engine actually committed suicide?
>
> Check your VDSM version. Especially the content of /usr/share/vdsm/dsaversion.py
> file. There are couple of lists specifying the cluster and engine versions that
> the VDSM supports.
>
> If you use 3.4 engine it needs 3.4 VDSM as well.. and the prerelease repo is not
> enabled by default.
>

vdsm version on the host:
vdsm-4.14.5-0.fc19.x86_64 @ovirt-3.4.0-prerelease

ovirt-engine installed in the VM:
ovirt-engine-3.4.0-0.13.rc.fc19.noarch

- and it dies with the error message: "Host hosted_engine_1 is 
compatible with versions (3.0,3.1,3.2,3.3) and cannot join Cluster 
Default which is set to version 3.4"

and commits suicide ...

- I'm going to create the bz now

>>>> mistake I think the engine should be a bit more clever and not kill itself
>>>
>
> I think it is the VDSM that does the actual killing :)
>

- but the engine tells the vdsm to stop the vds, doesn't it?

> But overall I agree, the setup is too fragile and I encountered all of the issues
> when installing hosted engine for the first time too.
>
> --
> Martin Siv?k
> msivak at redhat.com
> Red Hat Czech
> RHEV-M SLA / Brno, CZ
>



From sbonazzo at redhat.com  Fri Mar 14 09:46:00 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Fri, 14 Mar 2014 10:46:00 +0100
Subject: [Engine-devel] hosted engine in 3.4
In-Reply-To: <5322CE53.2060607@redhat.com>
References: <5321B22F.2000408@redhat.com>	<1585193153.19831369.1394718849438.JavaMail.zimbra@redhat.com>	<5321BC3C.5020305@redhat.com>	<83505232.18075115.1394788381088.JavaMail.zimbra@redhat.com>
	<5322CE53.2060607@redhat.com>
Message-ID: <5322CFD8.3020505@redhat.com>

Il 14/03/2014 10:39, Jiri Moskovcak ha scritto:
> On 03/14/2014 10:13 AM, Martin Sivak wrote:
>> Hi,
>>
>>>>> 1. You need to have some MAC address with static ip and FQDN, otherwise
>>>>> you have to change /etc/hosts at least for the first part of the setup
>>
>> I believe you were there when we were discussing this with pstehlik :)
>>
>> Btw in this case you have to change /etc/hosts on all hosts and inside the
>> engine VM.
>>
>>>>> 2. When the VM install is complete I would expect the setup wizard to
>>>>> install the engine to the VM automatically - which at least in my case -
>>>>> doesn't happen
>>
>> I also proposed kickstart based setup to Sandro. You would give a repo to setup
>> and it would download the kernel/initrd from it [1] and create a kickstart with
>> the right root password, engine setup and so on..
>>
>> [1] http://ftp.linux.cz/pub/linux/fedora/linux/releases/20/Fedora/x86_64/os/images/pxeboot/
>>
>>>>> 1. once I managed to install the engine to the vm it tried to add the
>>>>> host it was running on to the engine and it failed with a message "Host
>>>>> compatibility version doesn't match the cluster compatibility version",
>>>>> and then it marked the host as non operational which killed the vm with
>>>>> the engine, so the engine actually committed suicide?
>>
>> Check your VDSM version. Especially the content of /usr/share/vdsm/dsaversion.py
>> file. There are couple of lists specifying the cluster and engine versions that
>> the VDSM supports.
>>
>> If you use 3.4 engine it needs 3.4 VDSM as well.. and the prerelease repo is not
>> enabled by default.
>>
> 
> vdsm version on the host:
> vdsm-4.14.5-0.fc19.x86_64 @ovirt-3.4.0-prerelease
> 
> ovirt-engine installed in the VM:
> ovirt-engine-3.4.0-0.13.rc.fc19.noarch
> 
> - and it dies with the error message: "Host hosted_engine_1 is compatible with versions (3.0,3.1,3.2,3.3) and cannot join Cluster Default which is set
> to version 3.4"

Above is probably due to libvirt not updated to latest from fedora-virt-preview repo.
Dan, Yaniv, any reason for not explicitly requiring the updated version of libvirt in VDSM package?
If it's just because libvirt is not yet in official Fedora repository, maybe we should ship it on ovirt repository until it's in and put some pressure
on libvirt people for having them pushing the newest package into Fedora.
Thoughts?


> 
> and commits suicide ...
> 
> - I'm going to create the bz now
> 
>>>>> mistake I think the engine should be a bit more clever and not kill itself
>>>>
>>
>> I think it is the VDSM that does the actual killing :)
>>
> 
> - but the engine tells the vdsm to stop the vds, doesn't it?
> 
>> But overall I agree, the setup is too fragile and I encountered all of the issues
>> when installing hosted engine for the first time too.
>>
>> -- 
>> Martin Siv?k
>> msivak at redhat.com
>> Red Hat Czech
>> RHEV-M SLA / Brno, CZ
>>
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From jmoskovc at redhat.com  Fri Mar 14 12:35:57 2014
From: jmoskovc at redhat.com (Jiri Moskovcak)
Date: Fri, 14 Mar 2014 13:35:57 +0100
Subject: [Engine-devel] hosted engine in 3.4
In-Reply-To: <5322CFD8.3020505@redhat.com>
References: <5321B22F.2000408@redhat.com>	<1585193153.19831369.1394718849438.JavaMail.zimbra@redhat.com>	<5321BC3C.5020305@redhat.com>	<83505232.18075115.1394788381088.JavaMail.zimbra@redhat.com>
	<5322CE53.2060607@redhat.com> <5322CFD8.3020505@redhat.com>
Message-ID: <5322F7AD.1010109@redhat.com>

On 03/14/2014 10:46 AM, Sandro Bonazzola wrote:
> Il 14/03/2014 10:39, Jiri Moskovcak ha scritto:
>> On 03/14/2014 10:13 AM, Martin Sivak wrote:
>>> Hi,
>>>
>>>>>> 1. You need to have some MAC address with static ip and FQDN, otherwise
>>>>>> you have to change /etc/hosts at least for the first part of the setup
>>>
>>> I believe you were there when we were discussing this with pstehlik :)
>>>
>>> Btw in this case you have to change /etc/hosts on all hosts and inside the
>>> engine VM.
>>>
>>>>>> 2. When the VM install is complete I would expect the setup wizard to
>>>>>> install the engine to the VM automatically - which at least in my case -
>>>>>> doesn't happen
>>>
>>> I also proposed kickstart based setup to Sandro. You would give a repo to setup
>>> and it would download the kernel/initrd from it [1] and create a kickstart with
>>> the right root password, engine setup and so on..
>>>
>>> [1] http://ftp.linux.cz/pub/linux/fedora/linux/releases/20/Fedora/x86_64/os/images/pxeboot/
>>>
>>>>>> 1. once I managed to install the engine to the vm it tried to add the
>>>>>> host it was running on to the engine and it failed with a message "Host
>>>>>> compatibility version doesn't match the cluster compatibility version",
>>>>>> and then it marked the host as non operational which killed the vm with
>>>>>> the engine, so the engine actually committed suicide?
>>>
>>> Check your VDSM version. Especially the content of /usr/share/vdsm/dsaversion.py
>>> file. There are couple of lists specifying the cluster and engine versions that
>>> the VDSM supports.
>>>
>>> If you use 3.4 engine it needs 3.4 VDSM as well.. and the prerelease repo is not
>>> enabled by default.
>>>
>>
>> vdsm version on the host:
>> vdsm-4.14.5-0.fc19.x86_64 @ovirt-3.4.0-prerelease
>>
>> ovirt-engine installed in the VM:
>> ovirt-engine-3.4.0-0.13.rc.fc19.noarch
>>
>> - and it dies with the error message: "Host hosted_engine_1 is compatible with versions (3.0,3.1,3.2,3.3) and cannot join Cluster Default which is set
>> to version 3.4"
>
> Above is probably due to libvirt not updated to latest from fedora-virt-preview repo.
> Dan, Yaniv, any reason for not explicitly requiring the updated version of libvirt in VDSM package?
> If it's just because libvirt is not yet in official Fedora repository, maybe we should ship it on ovirt repository until it's in and put some pressure
> on libvirt people for having them pushing the newest package into Fedora.
> Thoughts?
>

- yes, that might be the case, there is no libvirt in the rc2 repo[1] I 
used to install the host

[1] http://resources.ovirt.org/releases/3.4.0-rc2/rpm/Fedora/19/x86_64/

>
>>
>> and commits suicide ...
>>
>> - I'm going to create the bz now
>>
>>>>>> mistake I think the engine should be a bit more clever and not kill itself
>>>>>
>>>
>>> I think it is the VDSM that does the actual killing :)
>>>
>>
>> - but the engine tells the vdsm to stop the vds, doesn't it?
>>
>>> But overall I agree, the setup is too fragile and I encountered all of the issues
>>> when installing hosted engine for the first time too.
>>>
>>> --
>>> Martin Siv?k
>>> msivak at redhat.com
>>> Red Hat Czech
>>> RHEV-M SLA / Brno, CZ
>>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
>



From fabiand at redhat.com  Fri Mar 14 16:06:56 2014
From: fabiand at redhat.com (Fabian Deutsch)
Date: Fri, 14 Mar 2014 17:06:56 +0100
Subject: [Engine-devel] [ANN] oVirt Node ISO for oVirt 3.4 RC 2
Message-ID: <1394813216.5037.7.camel@fdeutsch-laptop.local>

Hey,

let me announce a respun oVirt Node for oVirt 3.4 RC 2.

After some time this is finally available from where it belongs:
http://resources.ovirt.org/releases/3.4.0_pre/iso/ovirt-node-iso-3.0.4-1.0.201401291204.vdsm34rc2.el6.iso

There are also older releases of oVirt Node, in case that the latest
version has unknown regressions.

http://resources.ovirt.org/releases/3.4.0_pre/iso/

Please let us known about issues you run into. You can also let us know
when Node "Just Works (TM)".

Greetings
fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140314/40e6b583/attachment.sig>

From vszocs at redhat.com  Fri Mar 14 16:33:56 2014
From: vszocs at redhat.com (Vojtech Szocs)
Date: Fri, 14 Mar 2014 12:33:56 -0400 (EDT)
Subject: [Engine-devel] attn ui devs: why do we use inputs for labels?
In-Reply-To: <1481343871.27118035.1394744462354.JavaMail.zimbra@redhat.com>
References: <1740187465.9597169.1394722935614.JavaMail.zimbra@redhat.com>
	<1579791205.26836676.1394727291548.JavaMail.zimbra@redhat.com>
	<2025637929.9623264.1394727891708.JavaMail.zimbra@redhat.com>
	<1481343871.27118035.1394744462354.JavaMail.zimbra@redhat.com>
Message-ID: <1069120112.19511082.1394814836539.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "Greg Sheremeta" <gshereme at redhat.com>, "Vojtech Szocs" <vszocs at redhat.com>, "Gilad Chaplik"
> <gchaplik at redhat.com>, "Daniel Erez" <derez at redhat.com>, "Tomas Jelinek" <tjelinek at redhat.com>, "Lior Vernia"
> <lvernia at redhat.com>, "Kanagaraj" <kmayilsa at redhat.com>, "Alexander Wels" <awels at redhat.com>, "Alona Kaplan"
> <alkaplan at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, March 13, 2014 10:01:02 PM
> Subject: Re: [Engine-devel] attn ui devs: why do we use inputs for labels?
> 
> > ----- Original Message -----
> > From: "Greg Sheremeta" <gshereme at redhat.com>
> > Sent: Thursday, March 13, 2014 12:24:51 PM
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Einav Cohen" <ecohen at redhat.com>
> > > To: "Greg Sheremeta" <gshereme at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Thursday, March 13, 2014 12:14:51 PM
> > > Subject: Re: [Engine-devel] attn ui devs: why do we use inputs for
> > > labels?
> > > 
> > > I could be wrong, but there is a chance that using "input type=text"
> > > allows selecting/copying the text, rather than a plain label, which
> > > doesn't allow that.
> > 
> > If that's the reason, it must be a quirky browser thing. I can select and
> > copy <label>s in Chrome.
> 
> there is a good chance that you are right - maybe this used to be the
> behavior in old browsers. Do you happen to know what is the behavior
> in other (modern) browsers (FF, IE)?
> 
> ui maintainers: anything else that you know/recall about why we are
> using "input type=text" in our code? any reason to not change it?

I've discussed this with Greg yesterday.

The reason for using <input type="text"> to render *value* labels,
as seen on the "General" sub-tab screenshot [1], is because:
* value text might be too long to fit the logical column
* we want to preserve consistent key/value grid layout (no wrapping)
* we want user to be able to easily copy value text in clipboard

In frontend code, TextBoxLabelBase class represents such (input-based)
labels. It attaches "mousedown" handler on <input> so that when you
right-click the <input>, all content (possibly too long to fit) will
be selected so you can conveniently select "Copy" in context-menu.

If we want to replace <input> with some text-only element, we will
need to address same concerns as mentioned above. Greg told me that
Chrome has issues with right-click select-all-text functionality,
so maybe we can file BZ for current implementation.

That being said, I'm all for improvement. For example, we could have
some <span> (or any other text-only element) that doesn't wrap when
its content is too long. However, we still need to deal with "copy
value that's possibly too long into clipboard" scenario, which is
can be quite problematic.

> 
> > 
> > > 
> > > I am not sure if there are any (additional?) advantages to using
> > > "input type=text" (the other UI maintainers will probably know
> > > better).
> > > 
> > > > I'd like to pursue correcting this, if possible.
> > > 
> > > if there is a more "correct" way that won't result in losing any
> > > existing functionality, +1.
> > > 
> > > ----
> > > Thanks,
> > > Einav
> > > 
> > > ----- Original Message -----
> > > > From: "Greg Sheremeta" <gshereme at redhat.com>
> > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Thursday, March 13, 2014 11:02:15 AM
> > > > Subject: [Engine-devel] attn ui devs: why do we use inputs for labels?
> > > > 
> > > > Hi fellow UI developers,
> > > > 
> > > > Can someone explain why we are using "input type=text" fields to render
> > > > labels? (see screenshot[1]) This seems like bad practice for a few
> > > > reasons:
> > > >  * it's not semantic HTML
> > > >  * inputs do not have variable sizing like text. They cannot shrink
> > > >  down
> > > >  to
> > > >  the size of the text, which makes positioning difficult.
> > > >  * common browser extensions such as LastPass can be confused (see
> > > >  screenshot[1] -- lastpass sees these labels for the text fields they
> > > >  are,
> > > >  and attempts to help the user fill them in -- that's what those gray
> > > >  asterisks are. Very confusing.)
> > > > 
> > > > I'd like to pursue correcting this, if possible.
> > > > 
> > > > Thanks,
> > > > Greg
> > > > 
> > > > [1] http://i.imgur.com/AweOhJe.png
> > > > 
> > > > Greg Sheremeta
> > > > Red Hat, Inc.
> > > > Sr. Software Engineer, RHEV
> > > > Cell: 919-807-1086
> > > > gshereme at redhat.com
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > 
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> > 
> > 
> 


From vszocs at redhat.com  Fri Mar 14 16:50:51 2014
From: vszocs at redhat.com (Vojtech Szocs)
Date: Fri, 14 Mar 2014 12:50:51 -0400 (EDT)
Subject: [Engine-devel] [Users] adding scripts
In-Reply-To: <1616824011.27085458.1394740312956.JavaMail.zimbra@redhat.com>
References: <CA+pz52-HBTeR_FAMysdRmaTbg-OkWtk==qY1vC5R8pbXK8=bBw@mail.gmail.com>
	<1616824011.27085458.1394740312956.JavaMail.zimbra@redhat.com>
Message-ID: <2058630384.19518362.1394815851244.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "aditya mamidwar" <aditya.mamidwar at gmail.com>, "Vojtech Szocs" <vszocs at redhat.com>
> Cc: users at ovirt.org, engine-devel at ovirt.org
> Sent: Thursday, March 13, 2014 8:51:52 PM
> Subject: Re: [Users] adding scripts
> 
> if you are trying to hook into UI-specific events, it sounds
> like you will need to write an oVirt UI Plugin [1] in order to
> do that. However, I believe that the oVirt UI Plugins
> infrastructure doesn't support hooking to events such as "tab
> x was selected" and/or "button b was clicked".
> It does allow you to add new (custom) tabs/sub-tabs/buttons of
> your own, and there is a chance that it allows you to hook
> into events such as 'row x was selected in the grid'.
> 
> @Vojtech will know better. Vojtech?

Einav is right; in general, UI plugins can extend existing UI,
i.e. add custom tab, show custom dialog, add custom button to
existing tab, etc. See [1] for details.

UI plugins can also hook into some application-wide events,
such as user login/logout, main tab item selection change, etc.
See [2] for details.

[1] http://www.ovirt.org/Features/UIPlugins#API_function_reference
[2] http://www.ovirt.org/Features/UIPlugins#Application_event_reference

What you can do is add your custom button on some existing
main tab with click handler that makes some HTTP call to
trigger the action you need.

If you need to add click handler for *existing* button on
existing main tab, or you want to be notified when current
(active) main tab changes, this is not supported yet. Please
create RFE for this if it's something you'd like in UI plugins.

> 
> if you are trying to hook into engine events (e.g. you want to
> run a script every time a VM is started in oVirt, no matter if
> the user started it by clicking the 'run' button in the oVirt-
> engine webadmin, or invoked a REST API request, or an SDK
> command), then it will require some sort of an "engine-plugin"
> infrastructure that we don't have at the moment AFAIK.
> there is a chance that for some of the events you will be able
> to utilize the VDSM hooks (at the Host level) [2].
> 
> ----
> Thanks,
> Einav
> 
> [1] http://www.ovirt.org/Features/UIPlugins
> 
> [2] http://www.ovirt.org/VDSM-Hooks
> 
> 
> ----- Original Message -----
> > From: "aditya mamidwar" <aditya.mamidwar at gmail.com>
> > To: users at ovirt.org, engine-devel at ovirt.org
> > Sent: Thursday, March 13, 2014 11:23:35 AM
> > Subject: [Users] adding scripts
> > 
> > 
> > I want to commit changes to the engine by adding some bash scripts.
> > the scripts should be invoked once a button or tab is selected in the
> > webadmin portal by the user.
> > 
> > can someone guide on achieving this.
> > 
> > --
> > -Aditya Mamidwar
> > 
> > _______________________________________________
> > Users mailing list
> > Users at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
> > 
> 


From vszocs at redhat.com  Fri Mar 14 16:58:10 2014
From: vszocs at redhat.com (Vojtech Szocs)
Date: Fri, 14 Mar 2014 12:58:10 -0400 (EDT)
Subject: [Engine-devel] Small suggestions for engine-log-collector
In-Reply-To: <5321A442.1030307@redhat.com>
References: <800022326.17517459.1394560631804.JavaMail.zimbra@redhat.com>
	<651261410.16892578.1394561588396.JavaMail.zimbra@redhat.com>
	<5321A442.1030307@redhat.com>
Message-ID: <2111438961.19521314.1394816290721.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> To: "Keith Robertson" <kroberts at redhat.com>, "Vojtech Szocs" <vszocs at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Einav Cohen" <ecohen at redhat.com>
> Sent: Thursday, March 13, 2014 1:27:46 PM
> Subject: Re: Small suggestions for engine-log-collector
> 
> Il 11/03/2014 19:13, Keith Robertson ha scritto:
> > 
> > 
> > ----- Original Message -----
> >> From: "Vojtech Szocs" <vszocs at redhat.com> To: "engine-devel"
> >> <engine-devel at ovirt.org> Cc: "Keith Robertson" <kroberts at redhat.com>,
> >> "Einav Cohen"
> >> <ecohen at redhat.com> Sent: Tuesday, March 11, 2014 1:57:11 PM Subject:
> >> Small suggestions for engine-log-collector
> >> 
> >> Hi guys,
> >> 
> >> based on my testing during last week's oVirt 3.4 RC test day [1], I have a
> >> couple of small suggestions for engine-log-collector:
> >> 
> >> 1, in /etc/ovirt-engine/logcollector.conf - I think there's typo:
> >> 
> >> #key-file=/etc/pki/engine/keys/engine_id_rsa
> >> 
> >> should be:
> >> 
> >> #key-file=/etc/pki/ovirt-engine/keys/engine_id_rsa
> >> 
> > 
> > ACK
> 
> merged.
> 
> 
> > 
> > 
> >> 2, to force password-based ssh auth, one has to do this:
> >> 
> > 
> > In the normal scenario, the the ovirt user's public key should be installed
> > into each hypervisor.  Unless something has changed as a part of the
> > hypervisor registration process this should be something that we can depend
> > upon.
> > 
> > Clearly, there are edge cases where you need to collect logs from a
> > hypervisor that isn't properly registered with the RHEV-M.  Was this your
> > situation and how common do you think this scenario is?
> > 
> >> engine-log-collector -k ""
> >> 
> > 
> > Yes, you are nulling out the default value which causes the LC to prompt
> > you for a PW.  Perhaps we should document this as opposed to supplying a
> > specific option?  Sandro?
> 
> yes, maybe a better explanation in man page. Vojtech have you opened a bz
> about that?

No, first I wanted to hear your opinions :) I didn't open BZ for this yet.

I think a better explanation in --help text is sufficient. (small thing)

Should I open BZ for this?

> Thanks for the report and for the patch you submitted!
> 
> > 
> >> because running this:
> >> 
> >> engine-log-collector -k
> >> 
> >> returns error message:
> >> 
> >> error: -k option requires an argument
> >> 
> >> however, help for -k option mentions *supplying* the argument:
> >> 
> >> If a identity file is not supplied the program will prompt for a password.
> >> 
> >> so either the help text should mention empty string, or -k option should
> >> allow missing argument (this was my initial understanding according to
> >> help text)
> >> 
> >> Since these are just small things, I'm wondering if I should create RFE or
> >> if Keith/others can say if they are relevant.
> >> 
> >> Thanks, Vojtech
> >> 
> >> [1] http://etherpad.ovirt.org/p/3.4-testday-3
> >> 
> 
> 
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> 


From gshereme at redhat.com  Sat Mar 15 14:15:59 2014
From: gshereme at redhat.com (Greg Sheremeta)
Date: Sat, 15 Mar 2014 10:15:59 -0400 (EDT)
Subject: [Engine-devel] [Users] adding scripts
In-Reply-To: <532447ee.a70e440a.3ce3.ffffd5f5@mx.google.com>
References: <532447ee.a70e440a.3ce3.ffffd5f5@mx.google.com>
Message-ID: <965347974.29441.1394892959318.JavaMail.zimbra@redhat.com>

There's not one html file like that, since we use GWT [1]. However, if you search for *.ui.xml files, you'll find all the GWT UIBinder files. That's the place to start for simple UI tweaks. The application is partitioned into small components, so you'll have to do some digging. For example, each dialog has its own ui.xml file -- so if you want to tweak a specific dialog, you'll need to find the right file. Feel free to post questions about those to engine-devel and we can help you out. 

Greg 

[1] http://www.gwtproject.org/ 

----- Original Message -----

> From: "Aditya Mamidwar" <aditya.mamidwar at gmail.com>
> To: "Einav Cohen" <ecohen at redhat.com>, "Vojtech Szocs" <vszocs at redhat.com>
> Cc: engine-devel at ovirt.org, users at ovirt.org
> Sent: Saturday, March 15, 2014 8:30:21 AM
> Subject: Re: [Users] adding scripts

> Hey thanks on the previous issue.
> Also is there a way i can access WebAdmin.Html to add custom buttons and make
> few tweaks for personal use?
> I just cant find that file after using git.

> Aditya Mamidwar

> From: Einav Cohen
> Sent: ?14-?03-?2014 01:21
> To: aditya mamidwar ; Vojtech Szocs
> Cc: users at ovirt.org ; engine-devel at ovirt.org
> Subject: Re: [Users] adding scripts

> if you are trying to hook into UI-specific events, it sounds
> like you will need to write an oVirt UI Plugin [1] in order to
> do that. However, I believe that the oVirt UI Plugins
> infrastructure doesn't support hooking to events such as "tab
> x was selected" and/or "button b was clicked".
> It does allow you to add new (custom) tabs/sub-tabs/buttons of
> your own, and there is a chance that it allows you to hook
> into events such as 'row x was selected in the grid'.

> @Vojtech will know better. Vojtech?

> if you are trying to hook into engine events (e.g. you want to
> run a script every time a VM is started in oVirt, no matter if
> the user started it by clicking the 'run' button in the oVirt-
> engine webadmin, or invoked a REST API request, or an SDK
> command), then it will require some sort of an "engine-plugin"
> infrastructure that we don't have at the moment AFAIK.
> there is a chance that for some of the events you will be able
> to utilize the VDSM hooks (at the Host level) [2].

> ----
> Thanks,
> Einav

> [1] http://www.ovirt.org/Features/UIPlugins

> [2] http://www.ovirt.org/VDSM-Hooks

> ----- Original Message -----
> > From: "aditya mamidwar" <aditya.mamidwar at gmail.com>
> > To: users at ovirt.org, engine-devel at ovirt.org
> > Sent: Thursday, March 13, 2014 11:23:35 AM
> > Subject: [Users] adding scripts
> >
> >
> > I want to commit changes to the engine by adding some bash scripts.
> > the scripts should be invoked once a button or tab is selected in the
> > webadmin portal by the user.
> >
> > can someone guide on achieving this.
> >
> > --
> > -Aditya Mamidwar
> >
> > _______________________________________________
> > Users mailing list
> > Users at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
> >

> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140315/d58149c6/attachment.html>

From gshereme at redhat.com  Sat Mar 15 14:26:22 2014
From: gshereme at redhat.com (Greg Sheremeta)
Date: Sat, 15 Mar 2014 10:26:22 -0400 (EDT)
Subject: [Engine-devel] [Users] Source code unerstanding
In-Reply-To: <CA+pz5299MakC8q+XWDvJHeE4HD7qNm2CAPY1LdP6p8qsasnHmw@mail.gmail.com>
References: <CA+pz5299MakC8q+XWDvJHeE4HD7qNm2CAPY1LdP6p8qsasnHmw@mail.gmail.com>
Message-ID: <1940190670.29884.1394893582964.JavaMail.zimbra@redhat.com>

I don't know of any high-level code documentation for ovirt-engine, other than the Javadoc. But if you post your questions to engine-devel, we can help you. 

Greg 

----- Original Message -----


From: "aditya mamidwar" <aditya.mamidwar at gmail.com> 
To: users at ovirt.org, engine-devel at ovirt.org 
Sent: Friday, March 14, 2014 11:09:49 AM 
Subject: [Users] Source code unerstanding 


Hey, 

is there a simpler way to know which code is responsible for which module of the engine. 
is there a documentation maintained. or how can identify the files which are important for me. 

-- 
-Aditya Mamidwar 

_______________________________________________ 
Users mailing list 
Users at ovirt.org 
http://lists.ovirt.org/mailman/listinfo/users 




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140315/3e4e8e2e/attachment.html>

From plysab at gmail.com  Sat Mar 15 16:01:15 2014
From: plysab at gmail.com (plysan)
Date: Sun, 16 Mar 2014 00:01:15 +0800
Subject: [Engine-devel] [Users] Source code unerstanding
In-Reply-To: <CA+pz5299MakC8q+XWDvJHeE4HD7qNm2CAPY1LdP6p8qsasnHmw@mail.gmail.com>
References: <CA+pz5299MakC8q+XWDvJHeE4HD7qNm2CAPY1LdP6p8qsasnHmw@mail.gmail.com>
Message-ID: <CANDY9WMEtwjNmmim8K_FM-dUZis4qTo-FErzW6v=O3S01C=wgg@mail.gmail.com>

2014-03-14 23:09 GMT+08:00 aditya mamidwar <aditya.mamidwar at gmail.com>:

>
> Hey,
>
> is there a simpler way to know which code is responsible for which module
> of the engine.
>
If you import the code from eclipse, you can get a good overview of the
engine code by looking at project names.

> is there a documentation maintained. or how can identify the files which
> are important for me.
>
There are some good docs in the wiki if you do some research, but still
many places to be fulfilled.
I think a good starting point of reading the code is the many entry points
inside EJB such as Backend.java
You can search classes marked with @Singleton, @Startup and methods marked
with @PostConstruct, it acts like main functions in regular executable java
programs.

Hope it helps :)

>
>
> --
> -Aditya Mamidwar
>
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140316/9928d2c2/attachment.html>

From aditya.mamidwar at gmail.com  Thu Mar 13 15:23:35 2014
From: aditya.mamidwar at gmail.com (aditya mamidwar)
Date: Thu, 13 Mar 2014 20:53:35 +0530
Subject: [Engine-devel] adding scripts
Message-ID: <CA+pz52-HBTeR_FAMysdRmaTbg-OkWtk==qY1vC5R8pbXK8=bBw@mail.gmail.com>

I want to commit changes to the engine by adding some bash scripts.
the scripts should be invoked once a button or tab is selected in the
webadmin portal by the user.

can someone guide on achieving this.

-- 
-Aditya Mamidwar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140313/151a9672/attachment.html>

From aditya.mamidwar at gmail.com  Fri Mar 14 15:09:49 2014
From: aditya.mamidwar at gmail.com (aditya mamidwar)
Date: Fri, 14 Mar 2014 20:39:49 +0530
Subject: [Engine-devel] Source code unerstanding
Message-ID: <CA+pz5299MakC8q+XWDvJHeE4HD7qNm2CAPY1LdP6p8qsasnHmw@mail.gmail.com>

Hey,

is there a simpler way to know which code is responsible for which module
of the engine.
is there a documentation maintained. or how can identify the files which
are important for me.

-- 
-Aditya Mamidwar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140314/1390999b/attachment.html>

From aditya.mamidwar at gmail.com  Sat Mar 15 12:30:21 2014
From: aditya.mamidwar at gmail.com (Aditya Mamidwar)
Date: Sat, 15 Mar 2014 18:00:21 +0530
Subject: [Engine-devel] [Users] adding scripts
Message-ID: <532447ee.a70e440a.3ce3.ffffd5f5@mx.google.com>

Hey thanks on the previous issue.
Also is there a way i can access WebAdmin.Html to add custom buttons and make few tweaks for personal use?
I just cant find that file after using git.

Aditya Mamidwar

-----Original Message-----
From: "Einav Cohen" <ecohen at redhat.com>
Sent: ?14-?03-?2014 01:21
To: "aditya mamidwar" <aditya.mamidwar at gmail.com>; "Vojtech Szocs" <vszocs at redhat.com>
Cc: "users at ovirt.org" <users at ovirt.org>; "engine-devel at ovirt.org" <engine-devel at ovirt.org>
Subject: Re: [Users] adding scripts

if you are trying to hook into UI-specific events, it sounds 
like you will need to write an oVirt UI Plugin [1] in order to 
do that. However, I believe that the oVirt UI Plugins 
infrastructure doesn't support hooking to events such as "tab 
x was selected" and/or "button b was clicked". 
It does allow you to add new (custom) tabs/sub-tabs/buttons of 
your own, and there is a chance that it allows you to hook 
into events such as 'row x was selected in the grid'. 

@Vojtech will know better. Vojtech?

if you are trying to hook into engine events (e.g. you want to 
run a script every time a VM is started in oVirt, no matter if 
the user started it by clicking the 'run' button in the oVirt-
engine webadmin, or invoked a REST API request, or an SDK 
command), then it will require some sort of an "engine-plugin" 
infrastructure that we don't have at the moment AFAIK. 
there is a chance that for some of the events you will be able 
to utilize the VDSM hooks (at the Host level) [2].

----
Thanks,
Einav

[1] http://www.ovirt.org/Features/UIPlugins

[2] http://www.ovirt.org/VDSM-Hooks


----- Original Message -----
> From: "aditya mamidwar" <aditya.mamidwar at gmail.com>
> To: users at ovirt.org, engine-devel at ovirt.org
> Sent: Thursday, March 13, 2014 11:23:35 AM
> Subject: [Users] adding scripts
> 
> 
> I want to commit changes to the engine by adding some bash scripts.
> the scripts should be invoked once a button or tab is selected in the
> webadmin portal by the user.
> 
> can someone guide on achieving this.
> 
> --
> -Aditya Mamidwar
> 
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140315/c32725c7/attachment.html>

From masayag at redhat.com  Sun Mar 16 07:33:10 2014
From: masayag at redhat.com (Moti Asayag)
Date: Sun, 16 Mar 2014 03:33:10 -0400 (EDT)
Subject: [Engine-devel] [Users] Source code unerstanding
In-Reply-To: <CA+pz5299MakC8q+XWDvJHeE4HD7qNm2CAPY1LdP6p8qsasnHmw@mail.gmail.com>
References: <CA+pz5299MakC8q+XWDvJHeE4HD7qNm2CAPY1LdP6p8qsasnHmw@mail.gmail.com>
Message-ID: <630583734.133790.1394955190936.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "aditya mamidwar" <aditya.mamidwar at gmail.com>
> To: users at ovirt.org, engine-devel at ovirt.org
> Sent: Friday, March 14, 2014 5:09:49 PM
> Subject: [Users] Source code unerstanding
> 
> 
> Hey,
> 
> is there a simpler way to know which code is responsible for which module of
> the engine.
> is there a documentation maintained. or how can identify the files which are
> important for me.
> 

Here is a place to start:
https://www.ovirt.org/Category:Architecture

And specifically for the backend:
https://www.ovirt.org/Backend_modules_bll

> --
> -Aditya Mamidwar
> 
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 


From dfediuck at redhat.com  Sun Mar 16 10:47:43 2014
From: dfediuck at redhat.com (Doron Fediuck)
Date: Sun, 16 Mar 2014 06:47:43 -0400 (EDT)
Subject: [Engine-devel]
 =?utf-8?q?Bug_1076530_=E2=80=93_engine_shouldn=27t?=
 =?utf-8?q?_kill_the_vds_running_the_VM_with_the_hosted_engine?=
In-Reply-To: <1943631935.274687.1394965707628.JavaMail.zimbra@redhat.com>
References: <1868823189.178988.1394964111273.JavaMail.zimbra@redhat.com>
	<1943631935.274687.1394965707628.JavaMail.zimbra@redhat.com>
Message-ID: <639882765.181539.1394966863596.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Yedidyah Bar David" <didi at redhat.com>
> To: "Doron Fediuck" <dfediuck at redhat.com>
> Cc: "Sandro Bonazzola" <sbonazzo at redhat.com>, "Jiri Moskovcak" <jmoskovc at redhat.com>
> Sent: Sunday, March 16, 2014 12:28:27 PM
> Subject: Re: Bug 1076530 ? engine shouldn't kill the vds running the VM with the hosted engine
> 
> Might be better to discuss this on bugzilla.
> 
Bugzilla is not a mailing list. Moving to engine-devel.

> ----- Original Message -----
> > From: "Doron Fediuck" <dfediuck at redhat.com>
> > To: "Sandro Bonazzola" <sbonazzo at redhat.com>
> > Cc: "Yedidyah Bar David" <didi at redhat.com>, "Jiri Moskovcak"
> > <jmoskovc at redhat.com>
> > Sent: Sunday, March 16, 2014 12:01:51 PM
> > Subject: Bug 1076530 ? engine shouldn't kill the vds running the VM with
> > the hosted engine
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1076530
> > 
> > Sandro,
> > I think this would be solved by a better validation during setup /
> > deployment.
> 
> This can't be done during Validation in the otopi sense of the word.
> At that point the engine does not exist yet and so we can't know what
> versions it supports etc.
> 
Why not?
You have the vdsm supported versions in a file (dsaversion IIRC)
and you should be able to get the relevant engine info before or
after deploying the DB.

> It might be possible (didn't check) to check the versions right before
> trying to add the host to the cluster. This means we do not want to
> abort (as we can do during Validation if something does not pass it).
> What can we do? Perhaps offer a few options:
> 1. Do abort (will do mostly what happens today)
> 2. Let the user try to manually fix, probably by trying to change
> the compatibility version of the cluster, and then try adding the
> host again
> 3. Try to fix ourselves (same) and try adding again
> 4. Best would be to someone upgrade libvirt and reconfigure vdsm.
> Not sure that's easy or even possible at this stage, where VM is
> running and we do not want to loose it.
> 
> Thinking about this again, I am not sure the current behavior is that
> bad. "Fixing" by re-installing with the correct versions is probably
> way simpler than fixing after installation is (mostly) complete.
> 
> > 
> > I'm not keen on adding hosted-engine logic into the engine code.
> 
> Not sure about that. Not that it would help much, because the root
> problem will still have to be solved, but in principle it might be
> a good thing if the engine knows that killing some host will kill itself,
> and so try harder to not do that and just leave it in some zombie,
> requires-manual-action state. This is obviously more important during
> normal operation than during installation.
> --
> Didi
>


From didi at redhat.com  Sun Mar 16 10:59:42 2014
From: didi at redhat.com (Yedidyah Bar David)
Date: Sun, 16 Mar 2014 06:59:42 -0400 (EDT)
Subject: [Engine-devel]
 =?utf-8?q?Bug_1076530_=E2=80=93_engine_shouldn=27t?=
 =?utf-8?q?_kill_the_vds_running_the_VM_with_the_hosted_engine?=
In-Reply-To: <639882765.181539.1394966863596.JavaMail.zimbra@redhat.com>
References: <1868823189.178988.1394964111273.JavaMail.zimbra@redhat.com>
	<1943631935.274687.1394965707628.JavaMail.zimbra@redhat.com>
	<639882765.181539.1394966863596.JavaMail.zimbra@redhat.com>
Message-ID: <919919104.275976.1394967582908.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Doron Fediuck" <dfediuck at redhat.com>
> To: "Yedidyah Bar David" <didi at redhat.com>
> Cc: "Sandro Bonazzola" <sbonazzo at redhat.com>, "Jiri Moskovcak" <jmoskovc at redhat.com>, "engine-devel"
> <engine-devel at ovirt.org>
> Sent: Sunday, March 16, 2014 12:47:43 PM
> Subject: Re: Bug 1076530 ? engine shouldn't kill the vds running the VM with the hosted engine
> 
> 
> 
> ----- Original Message -----
> > From: "Yedidyah Bar David" <didi at redhat.com>
> > To: "Doron Fediuck" <dfediuck at redhat.com>
> > Cc: "Sandro Bonazzola" <sbonazzo at redhat.com>, "Jiri Moskovcak"
> > <jmoskovc at redhat.com>
> > Sent: Sunday, March 16, 2014 12:28:27 PM
> > Subject: Re: Bug 1076530 ? engine shouldn't kill the vds running the VM
> > with the hosted engine
> > 
> > Might be better to discuss this on bugzilla.
> > 
> Bugzilla is not a mailing list. Moving to engine-devel.
> 
> > ----- Original Message -----
> > > From: "Doron Fediuck" <dfediuck at redhat.com>
> > > To: "Sandro Bonazzola" <sbonazzo at redhat.com>
> > > Cc: "Yedidyah Bar David" <didi at redhat.com>, "Jiri Moskovcak"
> > > <jmoskovc at redhat.com>
> > > Sent: Sunday, March 16, 2014 12:01:51 PM
> > > Subject: Bug 1076530 ? engine shouldn't kill the vds running the VM with
> > > the hosted engine
> > > 
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1076530
> > > 
> > > Sandro,
> > > I think this would be solved by a better validation during setup /
> > > deployment.
> > 
> > This can't be done during Validation in the otopi sense of the word.
> > At that point the engine does not exist yet and so we can't know what
> > versions it supports etc.
> > 
> Why not?
> You have the vdsm supported versions in a file (dsaversion IIRC)
> and you should be able to get the relevant engine info before or
> after deploying the DB.

The VM does not exist yet at that point. How can you know what the user
will install on it? You can tell them what they *should* install - e.g.
"The highest compatibility version supported by this host is 3.4, you
should install a 3.4 engine inside the engine VM". But we can't know what
the user actually did until after we connect to the installed and working
engine.

> 
> > It might be possible (didn't check) to check the versions right before
> > trying to add the host to the cluster. This means we do not want to
> > abort (as we can do during Validation if something does not pass it).
> > What can we do? Perhaps offer a few options:
> > 1. Do abort (will do mostly what happens today)
> > 2. Let the user try to manually fix, probably by trying to change
> > the compatibility version of the cluster, and then try adding the
> > host again
> > 3. Try to fix ourselves (same) and try adding again
> > 4. Best would be to someone upgrade libvirt and reconfigure vdsm.
> > Not sure that's easy or even possible at this stage, where VM is
> > running and we do not want to loose it.
> > 
> > Thinking about this again, I am not sure the current behavior is that
> > bad. "Fixing" by re-installing with the correct versions is probably
> > way simpler than fixing after installation is (mostly) complete.
> > 
> > > 
> > > I'm not keen on adding hosted-engine logic into the engine code.
> > 
> > Not sure about that. Not that it would help much, because the root
> > problem will still have to be solved, but in principle it might be
> > a good thing if the engine knows that killing some host will kill itself,
> > and so try harder to not do that and just leave it in some zombie,
> > requires-manual-action state. This is obviously more important during
> > normal operation than during installation.
> > --
> > Didi
> >
> 

-- 
Didi


From ecohen at redhat.com  Sun Mar 16 18:04:43 2014
From: ecohen at redhat.com (Einav Cohen)
Date: Sun, 16 Mar 2014 14:04:43 -0400 (EDT)
Subject: [Engine-devel] [Users] adding scripts
In-Reply-To: <965347974.29441.1394892959318.JavaMail.zimbra@redhat.com>
References: <532447ee.a70e440a.3ce3.ffffd5f5@mx.google.com>
	<965347974.29441.1394892959318.JavaMail.zimbra@redhat.com>
Message-ID: <852285915.211656.1394993083434.JavaMail.zimbra@redhat.com>

may I ask what is the general purpose of these buttons that you 
would like to add and where (in the GUI) would you like to add 
them?

if you would like to add buttons to existing main-tab(s) / sub-
tab(s), the way to go is to write a UI Plugin that does that 
(especially if you intend these buttons to do something very 
specific for your needs). 

If you would like to add these buttons elsewhere, you will 
need to follow Greg's instructions and dig into the code for 
the specific needed location. 

> I want to commit changes to the engine... 

note that we can push into the code only things that make sense 
to include in oVirt (i.e. things that will be useful for typical 
oVirt users); again, if these buttons will do something very 
specific for your own needs, you should definitely utilize the 
UI Plugins infrastructure instead. 

> ... and make few tweaks for personal use...

if these tweaks are in the "branding" area (i.e. if you want to 
change main color themes, top-left image on the top banner, etc), 
then writing your own branding [1] is the way to go [you can 
override only part of the branding (depending on what you would 
like to tweak), you don't actually need to come up with a 
complete alternative branding].  

----
Thanks,
Einav

[1] http://www.ovirt.org/Feature/Branding

----- Original Message -----
> From: "Greg Sheremeta" <gshereme at redhat.com>
> To: "Aditya Mamidwar" <aditya.mamidwar at gmail.com>
> Cc: engine-devel at ovirt.org, users at ovirt.org
> Sent: Saturday, March 15, 2014 10:15:59 AM
> Subject: Re: [Users] adding scripts
> 
> There's not one html file like that, since we use GWT [1]. However, if you
> search for *.ui.xml files, you'll find all the GWT UIBinder files. That's
> the place to start for simple UI tweaks. The application is partitioned into
> small components, so you'll have to do some digging. For example, each
> dialog has its own ui.xml file -- so if you want to tweak a specific dialog,
> you'll need to find the right file. Feel free to post questions about those
> to engine-devel and we can help you out.
> 
> Greg
> 
> [1] http://www.gwtproject.org/
> 
> 
> 
> 
> From: "Aditya Mamidwar" <aditya.mamidwar at gmail.com>
> To: "Einav Cohen" <ecohen at redhat.com>, "Vojtech Szocs" <vszocs at redhat.com>
> Cc: engine-devel at ovirt.org, users at ovirt.org
> Sent: Saturday, March 15, 2014 8:30:21 AM
> Subject: Re: [Users] adding scripts
> 
> Hey thanks on the previous issue.
> Also is there a way i can access WebAdmin.Html to add custom buttons and make
> few tweaks for personal use?
> I just cant find that file after using git.
> 
> Aditya Mamidwar
> 
> From: Einav Cohen
> Sent: ?14-?03-?2014 01:21
> To: aditya mamidwar ; Vojtech Szocs
> Cc: users at ovirt.org ; engine-devel at ovirt.org
> Subject: Re: [Users] adding scripts
> 
> if you are trying to hook into UI-specific events, it sounds
> like you will need to write an oVirt UI Plugin [1] in order to
> do that. However, I believe that the oVirt UI Plugins
> infrastructure doesn't support hooking to events such as "tab
> x was selected" and/or "button b was clicked".
> It does allow you to add new (custom) tabs/sub-tabs/buttons of
> your own, and there is a chance that it allows you to hook
> into events such as 'row x was selected in the grid'.
> 
> @Vojtech will know better. Vojtech?
> 
> if you are trying to hook into engine events (e.g. you want to
> run a script every time a VM is started in oVirt, no matter if
> the user started it by clicking the 'run' button in the oVirt-
> engine webadmin, or invoked a REST API request, or an SDK
> command), then it will require some sort of an "engine-plugin"
> infrastructure that we don't have at the moment AFAIK.
> there is a chance that for some of the events you will be able
> to utilize the VDSM hooks (at the Host level) [2].
> 
> ----
> Thanks,
> Einav
> 
> [1] http://www.ovirt.org/Features/UIPlugins
> 
> [2] http://www.ovirt.org/VDSM-Hooks
> 
> 
> ----- Original Message -----
> > From: "aditya mamidwar" <aditya.mamidwar at gmail.com>
> > To: users at ovirt.org, engine-devel at ovirt.org
> > Sent: Thursday, March 13, 2014 11:23:35 AM
> > Subject: [Users] adding scripts
> > 
> > 
> > I want to commit changes to the engine by adding some bash scripts.
> > the scripts should be invoked once a button or tab is selected in the
> > webadmin portal by the user.
> > 
> > can someone guide on achieving this.
> > 
> > --
> > -Aditya Mamidwar
> > 
> > _______________________________________________
> > Users mailing list
> > Users at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
> > 
> 
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 
> 
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>


From aditya.mamidwar at gmail.com  Mon Mar 17 02:59:53 2014
From: aditya.mamidwar at gmail.com (aditya mamidwar)
Date: Mon, 17 Mar 2014 08:29:53 +0530
Subject: [Engine-devel] migration of VM, which protocol actually works?
Message-ID: <CA+pz52-DhrpWKamO-uQHT0N-=vXF=xj9khuSG0FE3i3GzkE60g@mail.gmail.com>

i wanted to learn about the modules so that i could understand how the
engine POSTS and sends data to the backend sql database and other scripts
to perform various options.

for e.g i need to know which code actually collects the storage path for
the ISO s during ISCSI storage domain setup.
also how the hosts, clusters and data centers are made and stored at the
backend.
if i want to add a new UI that bypasses some of these complicated tasks
(again for personal understanding), will I be able to do that.

Also i would like to mention that am working on making a little changes to
how the ISCSI protocol works..


My another doubt is:
when are the NFS/ISCSI/FC protocols actually used in ovirt. like what part
of the VM running state?
are their purpose limited to just copying the ISO from the storage center
to the path required by the Host.

Are the protocols them self responsible for sending and getting data during
VM execution on a node.
The concept of node and migration has left me a little confused.
since each node can run multiple VMs , so during the running/execution of
the VM , do the network protocols actully work, if not , then how is that
achieved.
if yes, again my question arises, which module should i focus on regarding
this issue.

thanks
-- 
-Aditya Mamidwar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140317/22b64588/attachment.html>

From sbonazzo at redhat.com  Mon Mar 17 07:11:20 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Mon, 17 Mar 2014 08:11:20 +0100
Subject: [Engine-devel]
 =?utf-8?q?Bug_1076530_=E2=80=93_engine_shouldn=27t?=
 =?utf-8?q?_kill_the_vds_running_the_VM_with_the_hosted_engine?=
In-Reply-To: <919919104.275976.1394967582908.JavaMail.zimbra@redhat.com>
References: <1868823189.178988.1394964111273.JavaMail.zimbra@redhat.com>
	<1943631935.274687.1394965707628.JavaMail.zimbra@redhat.com>
	<639882765.181539.1394966863596.JavaMail.zimbra@redhat.com>
	<919919104.275976.1394967582908.JavaMail.zimbra@redhat.com>
Message-ID: <5326A018.7030005@redhat.com>

Il 16/03/2014 11:59, Yedidyah Bar David ha scritto:
> 
> 
> ----- Original Message -----
>> From: "Doron Fediuck" <dfediuck at redhat.com>
>> To: "Yedidyah Bar David" <didi at redhat.com>
>> Cc: "Sandro Bonazzola" <sbonazzo at redhat.com>, "Jiri Moskovcak" <jmoskovc at redhat.com>, "engine-devel"
>> <engine-devel at ovirt.org>
>> Sent: Sunday, March 16, 2014 12:47:43 PM
>> Subject: Re: Bug 1076530 ? engine shouldn't kill the vds running the VM with the hosted engine
>>
>>
>>
>> ----- Original Message -----
>>> From: "Yedidyah Bar David" <didi at redhat.com>
>>> To: "Doron Fediuck" <dfediuck at redhat.com>
>>> Cc: "Sandro Bonazzola" <sbonazzo at redhat.com>, "Jiri Moskovcak"
>>> <jmoskovc at redhat.com>
>>> Sent: Sunday, March 16, 2014 12:28:27 PM
>>> Subject: Re: Bug 1076530 ? engine shouldn't kill the vds running the VM
>>> with the hosted engine
>>>
>>> Might be better to discuss this on bugzilla.
>>>
>> Bugzilla is not a mailing list. Moving to engine-devel.
>>
>>> ----- Original Message -----
>>>> From: "Doron Fediuck" <dfediuck at redhat.com>
>>>> To: "Sandro Bonazzola" <sbonazzo at redhat.com>
>>>> Cc: "Yedidyah Bar David" <didi at redhat.com>, "Jiri Moskovcak"
>>>> <jmoskovc at redhat.com>
>>>> Sent: Sunday, March 16, 2014 12:01:51 PM
>>>> Subject: Bug 1076530 ? engine shouldn't kill the vds running the VM with
>>>> the hosted engine
>>>>
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1076530
>>>>
>>>> Sandro,
>>>> I think this would be solved by a better validation during setup /
>>>> deployment.
>>>
>>> This can't be done during Validation in the otopi sense of the word.
>>> At that point the engine does not exist yet and so we can't know what
>>> versions it supports etc.
>>>
>> Why not?
>> You have the vdsm supported versions in a file (dsaversion IIRC)
>> and you should be able to get the relevant engine info before or
>> after deploying the DB.
> 
> The VM does not exist yet at that point. How can you know what the user
> will install on it? You can tell them what they *should* install - e.g.
> "The highest compatibility version supported by this host is 3.4, you
> should install a 3.4 engine inside the engine VM". But we can't know what
> the user actually did until after we connect to the installed and working
> engine.
> 
>>
>>> It might be possible (didn't check) to check the versions right before
>>> trying to add the host to the cluster. This means we do not want to
>>> abort (as we can do during Validation if something does not pass it).
>>> What can we do? Perhaps offer a few options:
>>> 1. Do abort (will do mostly what happens today)
>>> 2. Let the user try to manually fix, probably by trying to change
>>> the compatibility version of the cluster, and then try adding the
>>> host again
>>> 3. Try to fix ourselves (same) and try adding again
>>> 4. Best would be to someone upgrade libvirt and reconfigure vdsm.
>>> Not sure that's easy or even possible at this stage, where VM is
>>> running and we do not want to loose it.

We can check VDSM caps in late setup / customization and abort if cluster compatibility is not 3.4.
I'm not sure that VDSM 3.3 is enough for running hosted engine.

We can warn the user about the minimum version of oVirt engine that must be installed inside the VM and
after that we can check oVirt engine cluster compatibility and refuse to continue until the cluster
have a correct support level. This will require manual changes like upgrading the engine in the VM
or fix cluster compatibility level if we find an invalid value.


>>>
>>> Thinking about this again, I am not sure the current behavior is that
>>> bad. "Fixing" by re-installing with the correct versions is probably
>>> way simpler than fixing after installation is (mostly) complete.
>>>
>>>>
>>>> I'm not keen on adding hosted-engine logic into the engine code.
>>>
>>> Not sure about that. Not that it would help much, because the root
>>> problem will still have to be solved, but in principle it might be
>>> a good thing if the engine knows that killing some host will kill itself,
>>> and so try harder to not do that and just leave it in some zombie,
>>> requires-manual-action state. This is obviously more important during
>>> normal operation than during installation.
>>> --
>>> Didi
>>>
>>
> 


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From sbonazzo at redhat.com  Mon Mar 17 07:14:43 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Mon, 17 Mar 2014 08:14:43 +0100
Subject: [Engine-devel] Small suggestions for engine-log-collector
In-Reply-To: <2111438961.19521314.1394816290721.JavaMail.zimbra@redhat.com>
References: <800022326.17517459.1394560631804.JavaMail.zimbra@redhat.com>
	<651261410.16892578.1394561588396.JavaMail.zimbra@redhat.com>
	<5321A442.1030307@redhat.com>
	<2111438961.19521314.1394816290721.JavaMail.zimbra@redhat.com>
Message-ID: <5326A0E3.6040502@redhat.com>

Il 14/03/2014 17:58, Vojtech Szocs ha scritto:
> 
> 
> ----- Original Message -----
>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
>> To: "Keith Robertson" <kroberts at redhat.com>, "Vojtech Szocs" <vszocs at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>, "Einav Cohen" <ecohen at redhat.com>
>> Sent: Thursday, March 13, 2014 1:27:46 PM
>> Subject: Re: Small suggestions for engine-log-collector
>>
>> Il 11/03/2014 19:13, Keith Robertson ha scritto:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Vojtech Szocs" <vszocs at redhat.com> To: "engine-devel"
>>>> <engine-devel at ovirt.org> Cc: "Keith Robertson" <kroberts at redhat.com>,
>>>> "Einav Cohen"
>>>> <ecohen at redhat.com> Sent: Tuesday, March 11, 2014 1:57:11 PM Subject:
>>>> Small suggestions for engine-log-collector
>>>>
>>>> Hi guys,
>>>>
>>>> based on my testing during last week's oVirt 3.4 RC test day [1], I have a
>>>> couple of small suggestions for engine-log-collector:
>>>>
>>>> 1, in /etc/ovirt-engine/logcollector.conf - I think there's typo:
>>>>
>>>> #key-file=/etc/pki/engine/keys/engine_id_rsa
>>>>
>>>> should be:
>>>>
>>>> #key-file=/etc/pki/ovirt-engine/keys/engine_id_rsa
>>>>
>>>
>>> ACK
>>
>> merged.
>>
>>
>>>
>>>
>>>> 2, to force password-based ssh auth, one has to do this:
>>>>
>>>
>>> In the normal scenario, the the ovirt user's public key should be installed
>>> into each hypervisor.  Unless something has changed as a part of the
>>> hypervisor registration process this should be something that we can depend
>>> upon.
>>>
>>> Clearly, there are edge cases where you need to collect logs from a
>>> hypervisor that isn't properly registered with the RHEV-M.  Was this your
>>> situation and how common do you think this scenario is?
>>>
>>>> engine-log-collector -k ""
>>>>
>>>
>>> Yes, you are nulling out the default value which causes the LC to prompt
>>> you for a PW.  Perhaps we should document this as opposed to supplying a
>>> specific option?  Sandro?
>>
>> yes, maybe a better explanation in man page. Vojtech have you opened a bz
>> about that?
> 
> No, first I wanted to hear your opinions :) I didn't open BZ for this yet.
> 
> I think a better explanation in --help text is sufficient. (small thing)
> 
> Should I open BZ for this?

yes please, I think both --help and man page should be aligned.


> 
>> Thanks for the report and for the patch you submitted!
>>
>>>
>>>> because running this:
>>>>
>>>> engine-log-collector -k
>>>>
>>>> returns error message:
>>>>
>>>> error: -k option requires an argument
>>>>
>>>> however, help for -k option mentions *supplying* the argument:
>>>>
>>>> If a identity file is not supplied the program will prompt for a password.
>>>>
>>>> so either the help text should mention empty string, or -k option should
>>>> allow missing argument (this was my initial understanding according to
>>>> help text)
>>>>
>>>> Since these are just small things, I'm wondering if I should create RFE or
>>>> if Keith/others can say if they are relevant.
>>>>
>>>> Thanks, Vojtech
>>>>
>>>> [1] http://etherpad.ovirt.org/p/3.4-testday-3
>>>>
>>
>>
>> --
>> Sandro Bonazzola
>> Better technology. Faster innovation. Powered by community collaboration.
>> See how it works at redhat.com
>>


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From dfediuck at redhat.com  Mon Mar 17 08:08:31 2014
From: dfediuck at redhat.com (Doron Fediuck)
Date: Mon, 17 Mar 2014 04:08:31 -0400 (EDT)
Subject: [Engine-devel]
 =?utf-8?q?Bug_1076530_=E2=80=93_engine_shouldn=27t?=
 =?utf-8?q?_kill_the_vds_running_the_VM_with_the_hosted_engine?=
In-Reply-To: <5326A018.7030005@redhat.com>
References: <1868823189.178988.1394964111273.JavaMail.zimbra@redhat.com>
	<1943631935.274687.1394965707628.JavaMail.zimbra@redhat.com>
	<639882765.181539.1394966863596.JavaMail.zimbra@redhat.com>
	<919919104.275976.1394967582908.JavaMail.zimbra@redhat.com>
	<5326A018.7030005@redhat.com>
Message-ID: <1222957937.395586.1395043711772.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> To: "Yedidyah Bar David" <didi at redhat.com>, "Doron Fediuck" <dfediuck at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, March 17, 2014 9:11:20 AM
> Subject: Re: [Engine-devel] Bug 1076530 ? engine shouldn't kill the vds running the VM with the hosted engine
> 
> Il 16/03/2014 11:59, Yedidyah Bar David ha scritto:
> > 
> > 
> > ----- Original Message -----
> >> From: "Doron Fediuck" <dfediuck at redhat.com>
> >> To: "Yedidyah Bar David" <didi at redhat.com>
> >> Cc: "Sandro Bonazzola" <sbonazzo at redhat.com>, "Jiri Moskovcak"
> >> <jmoskovc at redhat.com>, "engine-devel"
> >> <engine-devel at ovirt.org>
> >> Sent: Sunday, March 16, 2014 12:47:43 PM
> >> Subject: Re: Bug 1076530 ? engine shouldn't kill the vds running the VM
> >> with the hosted engine
> >>
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Yedidyah Bar David" <didi at redhat.com>
> >>> To: "Doron Fediuck" <dfediuck at redhat.com>
> >>> Cc: "Sandro Bonazzola" <sbonazzo at redhat.com>, "Jiri Moskovcak"
> >>> <jmoskovc at redhat.com>
> >>> Sent: Sunday, March 16, 2014 12:28:27 PM
> >>> Subject: Re: Bug 1076530 ? engine shouldn't kill the vds running the VM
> >>> with the hosted engine
> >>>
> >>> Might be better to discuss this on bugzilla.
> >>>
> >> Bugzilla is not a mailing list. Moving to engine-devel.
> >>
> >>> ----- Original Message -----
> >>>> From: "Doron Fediuck" <dfediuck at redhat.com>
> >>>> To: "Sandro Bonazzola" <sbonazzo at redhat.com>
> >>>> Cc: "Yedidyah Bar David" <didi at redhat.com>, "Jiri Moskovcak"
> >>>> <jmoskovc at redhat.com>
> >>>> Sent: Sunday, March 16, 2014 12:01:51 PM
> >>>> Subject: Bug 1076530 ? engine shouldn't kill the vds running the VM with
> >>>> the hosted engine
> >>>>
> >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1076530
> >>>>
> >>>> Sandro,
> >>>> I think this would be solved by a better validation during setup /
> >>>> deployment.
> >>>
> >>> This can't be done during Validation in the otopi sense of the word.
> >>> At that point the engine does not exist yet and so we can't know what
> >>> versions it supports etc.
> >>>
> >> Why not?
> >> You have the vdsm supported versions in a file (dsaversion IIRC)
> >> and you should be able to get the relevant engine info before or
> >> after deploying the DB.
> > 
> > The VM does not exist yet at that point. How can you know what the user
> > will install on it? You can tell them what they *should* install - e.g.
> > "The highest compatibility version supported by this host is 3.4, you
> > should install a 3.4 engine inside the engine VM". But we can't know what
> > the user actually did until after we connect to the installed and working
> > engine.
> > 
> >>
> >>> It might be possible (didn't check) to check the versions right before
> >>> trying to add the host to the cluster. This means we do not want to
> >>> abort (as we can do during Validation if something does not pass it).
> >>> What can we do? Perhaps offer a few options:
> >>> 1. Do abort (will do mostly what happens today)
> >>> 2. Let the user try to manually fix, probably by trying to change
> >>> the compatibility version of the cluster, and then try adding the
> >>> host again
> >>> 3. Try to fix ourselves (same) and try adding again
> >>> 4. Best would be to someone upgrade libvirt and reconfigure vdsm.
> >>> Not sure that's easy or even possible at this stage, where VM is
> >>> running and we do not want to loose it.
> 
> We can check VDSM caps in late setup / customization and abort if cluster
> compatibility is not 3.4.
> I'm not sure that VDSM 3.3 is enough for running hosted engine.
> 
> We can warn the user about the minimum version of oVirt engine that must be
> installed inside the VM and
> after that we can check oVirt engine cluster compatibility and refuse to
> continue until the cluster
> have a correct support level. This will require manual changes like upgrading
> the engine in the VM
> or fix cluster compatibility level if we find an invalid value.
> 
If we can assist the user with fixing cluster compatibility level to avoid
a malformed end result this is the solution I'd go with. In this way the
user will always get a working setup, with the relevant information.
ie- something like:

Current engine settings does not support your vdsm version please select how you wish to proceed:
(1) Manually upgrade vdsm
(2) Lower cluster compatibility to support your installed vdsm
(3) Abort

Option (2) should do a simple db update to make sure the user has a running
setup.

Thoughts?

> 
> >>>
> >>> Thinking about this again, I am not sure the current behavior is that
> >>> bad. "Fixing" by re-installing with the correct versions is probably
> >>> way simpler than fixing after installation is (mostly) complete.
> >>>
> >>>>
> >>>> I'm not keen on adding hosted-engine logic into the engine code.
> >>>
> >>> Not sure about that. Not that it would help much, because the root
> >>> problem will still have to be solved, but in principle it might be
> >>> a good thing if the engine knows that killing some host will kill itself,
> >>> and so try harder to not do that and just leave it in some zombie,
> >>> requires-manual-action state. This is obviously more important during
> >>> normal operation than during installation.
> >>> --
> >>> Didi
> >>>
> >>
> > 
> 
> 
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>


From didi at redhat.com  Mon Mar 17 08:13:24 2014
From: didi at redhat.com (Yedidyah Bar David)
Date: Mon, 17 Mar 2014 04:13:24 -0400 (EDT)
Subject: [Engine-devel]
 =?utf-8?q?Bug_1076530_=E2=80=93_engine_shouldn=27t?=
 =?utf-8?q?_kill_the_vds_running_the_VM_with_the_hosted_engine?=
In-Reply-To: <1222957937.395586.1395043711772.JavaMail.zimbra@redhat.com>
References: <1868823189.178988.1394964111273.JavaMail.zimbra@redhat.com>
	<1943631935.274687.1394965707628.JavaMail.zimbra@redhat.com>
	<639882765.181539.1394966863596.JavaMail.zimbra@redhat.com>
	<919919104.275976.1394967582908.JavaMail.zimbra@redhat.com>
	<5326A018.7030005@redhat.com>
	<1222957937.395586.1395043711772.JavaMail.zimbra@redhat.com>
Message-ID: <711570052.667963.1395044004961.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Doron Fediuck" <dfediuck at redhat.com>
> To: "Sandro Bonazzola" <sbonazzo at redhat.com>
> Cc: "Yedidyah Bar David" <didi at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, March 17, 2014 10:08:31 AM
> Subject: Re: [Engine-devel] Bug 1076530 ? engine shouldn't kill the vds running the VM with the hosted engine
> 
> 
> 
> ----- Original Message -----
> > From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> > To: "Yedidyah Bar David" <didi at redhat.com>, "Doron Fediuck"
> > <dfediuck at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Monday, March 17, 2014 9:11:20 AM
> > Subject: Re: [Engine-devel] Bug 1076530 ? engine shouldn't kill the vds
> > running the VM with the hosted engine
> > 
> > Il 16/03/2014 11:59, Yedidyah Bar David ha scritto:
> > > 
> > > 
> > > ----- Original Message -----
> > >> From: "Doron Fediuck" <dfediuck at redhat.com>
> > >> To: "Yedidyah Bar David" <didi at redhat.com>
> > >> Cc: "Sandro Bonazzola" <sbonazzo at redhat.com>, "Jiri Moskovcak"
> > >> <jmoskovc at redhat.com>, "engine-devel"
> > >> <engine-devel at ovirt.org>
> > >> Sent: Sunday, March 16, 2014 12:47:43 PM
> > >> Subject: Re: Bug 1076530 ? engine shouldn't kill the vds running the VM
> > >> with the hosted engine
> > >>
> > >>
> > >>
> > >> ----- Original Message -----
> > >>> From: "Yedidyah Bar David" <didi at redhat.com>
> > >>> To: "Doron Fediuck" <dfediuck at redhat.com>
> > >>> Cc: "Sandro Bonazzola" <sbonazzo at redhat.com>, "Jiri Moskovcak"
> > >>> <jmoskovc at redhat.com>
> > >>> Sent: Sunday, March 16, 2014 12:28:27 PM
> > >>> Subject: Re: Bug 1076530 ? engine shouldn't kill the vds running the VM
> > >>> with the hosted engine
> > >>>
> > >>> Might be better to discuss this on bugzilla.
> > >>>
> > >> Bugzilla is not a mailing list. Moving to engine-devel.
> > >>
> > >>> ----- Original Message -----
> > >>>> From: "Doron Fediuck" <dfediuck at redhat.com>
> > >>>> To: "Sandro Bonazzola" <sbonazzo at redhat.com>
> > >>>> Cc: "Yedidyah Bar David" <didi at redhat.com>, "Jiri Moskovcak"
> > >>>> <jmoskovc at redhat.com>
> > >>>> Sent: Sunday, March 16, 2014 12:01:51 PM
> > >>>> Subject: Bug 1076530 ? engine shouldn't kill the vds running the VM
> > >>>> with
> > >>>> the hosted engine
> > >>>>
> > >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1076530
> > >>>>
> > >>>> Sandro,
> > >>>> I think this would be solved by a better validation during setup /
> > >>>> deployment.
> > >>>
> > >>> This can't be done during Validation in the otopi sense of the word.
> > >>> At that point the engine does not exist yet and so we can't know what
> > >>> versions it supports etc.
> > >>>
> > >> Why not?
> > >> You have the vdsm supported versions in a file (dsaversion IIRC)
> > >> and you should be able to get the relevant engine info before or
> > >> after deploying the DB.
> > > 
> > > The VM does not exist yet at that point. How can you know what the user
> > > will install on it? You can tell them what they *should* install - e.g.
> > > "The highest compatibility version supported by this host is 3.4, you
> > > should install a 3.4 engine inside the engine VM". But we can't know what
> > > the user actually did until after we connect to the installed and working
> > > engine.
> > > 
> > >>
> > >>> It might be possible (didn't check) to check the versions right before
> > >>> trying to add the host to the cluster. This means we do not want to
> > >>> abort (as we can do during Validation if something does not pass it).
> > >>> What can we do? Perhaps offer a few options:
> > >>> 1. Do abort (will do mostly what happens today)
> > >>> 2. Let the user try to manually fix, probably by trying to change
> > >>> the compatibility version of the cluster, and then try adding the
> > >>> host again
> > >>> 3. Try to fix ourselves (same) and try adding again
> > >>> 4. Best would be to someone upgrade libvirt and reconfigure vdsm.
> > >>> Not sure that's easy or even possible at this stage, where VM is
> > >>> running and we do not want to loose it.
> > 
> > We can check VDSM caps in late setup / customization and abort if cluster
> > compatibility is not 3.4.
> > I'm not sure that VDSM 3.3 is enough for running hosted engine.
> > 
> > We can warn the user about the minimum version of oVirt engine that must be
> > installed inside the VM and
> > after that we can check oVirt engine cluster compatibility and refuse to
> > continue until the cluster
> > have a correct support level. This will require manual changes like
> > upgrading
> > the engine in the VM
> > or fix cluster compatibility level if we find an invalid value.
> > 
> If we can assist the user with fixing cluster compatibility level to avoid
> a malformed end result this is the solution I'd go with. In this way the
> user will always get a working setup, with the relevant information.
> ie- something like:

I think there are two different issues here.

> 
> Current engine settings does not support your vdsm version please select how
> you wish to proceed:
> (1) Manually upgrade vdsm

This (at least >= some minimum) can be checked quite early, and we can decide
to simply abort if not met. Then user can upgrade and run deploy again.

> (2) Lower cluster compatibility to support your installed vdsm
> (3) Abort
> 
> Option (2) should do a simple db update to make sure the user has a running
> setup.

Indeed.

There is also the option Sandro suggested: Increase cluster compatibility level.
This will have to be done by the user, at least if it requires upgrading the
engine inside the VM.
-- 
Didi


From sbonazzo at redhat.com  Mon Mar 17 08:15:19 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Mon, 17 Mar 2014 09:15:19 +0100
Subject: [Engine-devel]
 =?utf-8?q?Bug_1076530_=E2=80=93_engine_shouldn=27t?=
 =?utf-8?q?_kill_the_vds_running_the_VM_with_the_hosted_engine?=
In-Reply-To: <1222957937.395586.1395043711772.JavaMail.zimbra@redhat.com>
References: <1868823189.178988.1394964111273.JavaMail.zimbra@redhat.com>
	<1943631935.274687.1394965707628.JavaMail.zimbra@redhat.com>
	<639882765.181539.1394966863596.JavaMail.zimbra@redhat.com>
	<919919104.275976.1394967582908.JavaMail.zimbra@redhat.com>
	<5326A018.7030005@redhat.com>
	<1222957937.395586.1395043711772.JavaMail.zimbra@redhat.com>
Message-ID: <5326AF17.8020700@redhat.com>

Il 17/03/2014 09:08, Doron Fediuck ha scritto:
> 
> 
> ----- Original Message -----
>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
>> To: "Yedidyah Bar David" <didi at redhat.com>, "Doron Fediuck" <dfediuck at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Monday, March 17, 2014 9:11:20 AM
>> Subject: Re: [Engine-devel] Bug 1076530 ? engine shouldn't kill the vds running the VM with the hosted engine
>>
>> Il 16/03/2014 11:59, Yedidyah Bar David ha scritto:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Doron Fediuck" <dfediuck at redhat.com>
>>>> To: "Yedidyah Bar David" <didi at redhat.com>
>>>> Cc: "Sandro Bonazzola" <sbonazzo at redhat.com>, "Jiri Moskovcak"
>>>> <jmoskovc at redhat.com>, "engine-devel"
>>>> <engine-devel at ovirt.org>
>>>> Sent: Sunday, March 16, 2014 12:47:43 PM
>>>> Subject: Re: Bug 1076530 ? engine shouldn't kill the vds running the VM
>>>> with the hosted engine
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Yedidyah Bar David" <didi at redhat.com>
>>>>> To: "Doron Fediuck" <dfediuck at redhat.com>
>>>>> Cc: "Sandro Bonazzola" <sbonazzo at redhat.com>, "Jiri Moskovcak"
>>>>> <jmoskovc at redhat.com>
>>>>> Sent: Sunday, March 16, 2014 12:28:27 PM
>>>>> Subject: Re: Bug 1076530 ? engine shouldn't kill the vds running the VM
>>>>> with the hosted engine
>>>>>
>>>>> Might be better to discuss this on bugzilla.
>>>>>
>>>> Bugzilla is not a mailing list. Moving to engine-devel.
>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Doron Fediuck" <dfediuck at redhat.com>
>>>>>> To: "Sandro Bonazzola" <sbonazzo at redhat.com>
>>>>>> Cc: "Yedidyah Bar David" <didi at redhat.com>, "Jiri Moskovcak"
>>>>>> <jmoskovc at redhat.com>
>>>>>> Sent: Sunday, March 16, 2014 12:01:51 PM
>>>>>> Subject: Bug 1076530 ? engine shouldn't kill the vds running the VM with
>>>>>> the hosted engine
>>>>>>
>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1076530
>>>>>>
>>>>>> Sandro,
>>>>>> I think this would be solved by a better validation during setup /
>>>>>> deployment.
>>>>>
>>>>> This can't be done during Validation in the otopi sense of the word.
>>>>> At that point the engine does not exist yet and so we can't know what
>>>>> versions it supports etc.
>>>>>
>>>> Why not?
>>>> You have the vdsm supported versions in a file (dsaversion IIRC)
>>>> and you should be able to get the relevant engine info before or
>>>> after deploying the DB.
>>>
>>> The VM does not exist yet at that point. How can you know what the user
>>> will install on it? You can tell them what they *should* install - e.g.
>>> "The highest compatibility version supported by this host is 3.4, you
>>> should install a 3.4 engine inside the engine VM". But we can't know what
>>> the user actually did until after we connect to the installed and working
>>> engine.
>>>
>>>>
>>>>> It might be possible (didn't check) to check the versions right before
>>>>> trying to add the host to the cluster. This means we do not want to
>>>>> abort (as we can do during Validation if something does not pass it).
>>>>> What can we do? Perhaps offer a few options:
>>>>> 1. Do abort (will do mostly what happens today)
>>>>> 2. Let the user try to manually fix, probably by trying to change
>>>>> the compatibility version of the cluster, and then try adding the
>>>>> host again
>>>>> 3. Try to fix ourselves (same) and try adding again
>>>>> 4. Best would be to someone upgrade libvirt and reconfigure vdsm.
>>>>> Not sure that's easy or even possible at this stage, where VM is
>>>>> running and we do not want to loose it.
>>
>> We can check VDSM caps in late setup / customization and abort if cluster
>> compatibility is not 3.4.
>> I'm not sure that VDSM 3.3 is enough for running hosted engine.
>>
>> We can warn the user about the minimum version of oVirt engine that must be
>> installed inside the VM and
>> after that we can check oVirt engine cluster compatibility and refuse to
>> continue until the cluster
>> have a correct support level. This will require manual changes like upgrading
>> the engine in the VM
>> or fix cluster compatibility level if we find an invalid value.
>>
> If we can assist the user with fixing cluster compatibility level to avoid
> a malformed end result this is the solution I'd go with. In this way the
> user will always get a working setup, with the relevant information.
> ie- something like:
> 
> Current engine settings does not support your vdsm version please select how you wish to proceed:
> (1) Manually upgrade vdsm
> (2) Lower cluster compatibility to support your installed vdsm
> (3) Abort
> 
> Option (2) should do a simple db update to make sure the user has a running
> setup.
> 
> Thoughts?

We should also consider the case with VDSM having 3.4 compatibility and engine missing it (wrong version installed)

(1) Manually upgrade ovirt-engine

as alternative to

(1) Manually upgrade vdsm


> 
>>
>>>>>
>>>>> Thinking about this again, I am not sure the current behavior is that
>>>>> bad. "Fixing" by re-installing with the correct versions is probably
>>>>> way simpler than fixing after installation is (mostly) complete.
>>>>>
>>>>>>
>>>>>> I'm not keen on adding hosted-engine logic into the engine code.
>>>>>
>>>>> Not sure about that. Not that it would help much, because the root
>>>>> problem will still have to be solved, but in principle it might be
>>>>> a good thing if the engine knows that killing some host will kill itself,
>>>>> and so try harder to not do that and just leave it in some zombie,
>>>>> requires-manual-action state. This is obviously more important during
>>>>> normal operation than during installation.
>>>>> --
>>>>> Didi
>>>>>
>>>>
>>>
>>
>>
>> --
>> Sandro Bonazzola
>> Better technology. Faster innovation. Powered by community collaboration.
>> See how it works at redhat.com
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From didi at redhat.com  Mon Mar 17 08:21:39 2014
From: didi at redhat.com (Yedidyah Bar David)
Date: Mon, 17 Mar 2014 04:21:39 -0400 (EDT)
Subject: [Engine-devel]
 =?utf-8?q?Bug_1076530_=E2=80=93_engine_shouldn=27t?=
 =?utf-8?q?_kill_the_vds_running_the_VM_with_the_hosted_engine?=
In-Reply-To: <5326AF17.8020700@redhat.com>
References: <1868823189.178988.1394964111273.JavaMail.zimbra@redhat.com>
	<1943631935.274687.1394965707628.JavaMail.zimbra@redhat.com>
	<639882765.181539.1394966863596.JavaMail.zimbra@redhat.com>
	<919919104.275976.1394967582908.JavaMail.zimbra@redhat.com>
	<5326A018.7030005@redhat.com>
	<1222957937.395586.1395043711772.JavaMail.zimbra@redhat.com>
	<5326AF17.8020700@redhat.com>
Message-ID: <1937890974.669975.1395044499950.JavaMail.zimbra@redhat.com>

> >>>>>> I'm not keen on adding hosted-engine logic into the engine code.
> >>>>>
> >>>>> Not sure about that. Not that it would help much, because the root
> >>>>> problem will still have to be solved, but in principle it might be
> >>>>> a good thing if the engine knows that killing some host will kill
> >>>>> itself,
> >>>>> and so try harder to not do that and just leave it in some zombie,
> >>>>> requires-manual-action state. This is obviously more important during
> >>>>> normal operation than during installation.

BTW, no-one addressed the original point in the bug.

We might solve the specific compatibility level issue, but the general
question still remains: Should the engine treat differently the VM and host
that are running itself? Knowing that killing them means committing suicide
(or, in other words, probably require manual cli action from the user)?
-- 
Didi


From dfediuck at redhat.com  Mon Mar 17 08:37:04 2014
From: dfediuck at redhat.com (Doron Fediuck)
Date: Mon, 17 Mar 2014 04:37:04 -0400 (EDT)
Subject: [Engine-devel]
 =?utf-8?q?Bug_1076530_=E2=80=93_engine_shouldn=27t?=
 =?utf-8?q?_kill_the_vds_running_the_VM_with_the_hosted_engine?=
In-Reply-To: <1937890974.669975.1395044499950.JavaMail.zimbra@redhat.com>
References: <1868823189.178988.1394964111273.JavaMail.zimbra@redhat.com>
	<1943631935.274687.1394965707628.JavaMail.zimbra@redhat.com>
	<639882765.181539.1394966863596.JavaMail.zimbra@redhat.com>
	<919919104.275976.1394967582908.JavaMail.zimbra@redhat.com>
	<5326A018.7030005@redhat.com>
	<1222957937.395586.1395043711772.JavaMail.zimbra@redhat.com>
	<5326AF17.8020700@redhat.com>
	<1937890974.669975.1395044499950.JavaMail.zimbra@redhat.com>
Message-ID: <226290297.416135.1395045424363.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Yedidyah Bar David" <didi at redhat.com>
> To: "Sandro Bonazzola" <sbonazzo at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, March 17, 2014 10:21:39 AM
> Subject: Re: [Engine-devel] Bug 1076530 ? engine shouldn't kill the vds running the VM with the hosted engine
> 
> > >>>>>> I'm not keen on adding hosted-engine logic into the engine code.
> > >>>>>
> > >>>>> Not sure about that. Not that it would help much, because the root
> > >>>>> problem will still have to be solved, but in principle it might be
> > >>>>> a good thing if the engine knows that killing some host will kill
> > >>>>> itself,
> > >>>>> and so try harder to not do that and just leave it in some zombie,
> > >>>>> requires-manual-action state. This is obviously more important during
> > >>>>> normal operation than during installation.
> 
> BTW, no-one addressed the original point in the bug.
> 
> We might solve the specific compatibility level issue, but the general
> question still remains: Should the engine treat differently the VM and host
> that are running itself? Knowing that killing them means committing suicide
> (or, in other words, probably require manual cli action from the user)?

This is what I'm trying to avoid. It is possible but will add special logic
we should try to avoid. If the setup makes sure you have a running deployment
you can leave it as is. the user will always be able to do bad things in the
system and we should not nanny them, as long as they are aware of what they do.

> --
> Didi



From awels at redhat.com  Mon Mar 17 12:22:48 2014
From: awels at redhat.com (Alexander Wels)
Date: Mon, 17 Mar 2014 08:22:48 -0400
Subject: [Engine-devel] [Users] adding scripts
In-Reply-To: <532447ee.a70e440a.3ce3.ffffd5f5@mx.google.com>
References: <532447ee.a70e440a.3ce3.ffffd5f5@mx.google.com>
Message-ID: <2582932.ip0y7S9grx@awels>

Aditya,

That is because that file doesn't exist. We map that name to a servlet in 
web.xml. If you want to modify the GWT host page take a look at 
GwtDynamicHostPageServlet.java and its sub classes (for user portal and 
webadmin). As well as GwtHostPage.jsp. You will find there is almost nothing in 
that page as all the HTML is being generated at runtime using GWT.

Since you are not really explaining what you are trying to do we can't help 
you better on the best strategy to achieve what you want.

Alexander

On Saturday, March 15, 2014 06:00:21 PM Aditya Mamidwar wrote:
> Hey thanks on the previous issue.
> Also is there a way i can access WebAdmin.Html to add custom buttons and
> make few tweaks for personal use? I just cant find that file after using
> git.
> 
> Aditya Mamidwar
> 
> -----Original Message-----
> From: "Einav Cohen" <ecohen at redhat.com>
> Sent: ?14-?03-?2014 01:21
> To: "aditya mamidwar" <aditya.mamidwar at gmail.com>; "Vojtech Szocs"
> <vszocs at redhat.com> Cc: "users at ovirt.org" <users at ovirt.org>;
> "engine-devel at ovirt.org" <engine-devel at ovirt.org> Subject: Re: [Users]
> adding scripts
> 
> if you are trying to hook into UI-specific events, it sounds
> like you will need to write an oVirt UI Plugin [1] in order to
> do that. However, I believe that the oVirt UI Plugins
> infrastructure doesn't support hooking to events such as "tab
> x was selected" and/or "button b was clicked".
> It does allow you to add new (custom) tabs/sub-tabs/buttons of
> your own, and there is a chance that it allows you to hook
> into events such as 'row x was selected in the grid'.
> 
> @Vojtech will know better. Vojtech?
> 
> if you are trying to hook into engine events (e.g. you want to
> run a script every time a VM is started in oVirt, no matter if
> the user started it by clicking the 'run' button in the oVirt-
> engine webadmin, or invoked a REST API request, or an SDK
> command), then it will require some sort of an "engine-plugin"
> infrastructure that we don't have at the moment AFAIK.
> there is a chance that for some of the events you will be able
> to utilize the VDSM hooks (at the Host level) [2].
> 
> ----
> Thanks,
> Einav
> 
> [1] http://www.ovirt.org/Features/UIPlugins
> 
> [2] http://www.ovirt.org/VDSM-Hooks
> 
> 
> ----- Original Message -----
> 
> > From: "aditya mamidwar" <aditya.mamidwar at gmail.com>
> > To: users at ovirt.org, engine-devel at ovirt.org
> > Sent: Thursday, March 13, 2014 11:23:35 AM
> > Subject: [Users] adding scripts
> > 
> > 
> > I want to commit changes to the engine by adding some bash scripts.
> > the scripts should be invoked once a button or tab is selected in the
> > webadmin portal by the user.
> > 
> > can someone guide on achieving this.
> > 
> > --
> > -Aditya Mamidwar
> > 
> > _______________________________________________
> > Users mailing list
> > Users at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users



From gshereme at redhat.com  Mon Mar 17 15:16:13 2014
From: gshereme at redhat.com (Greg Sheremeta)
Date: Mon, 17 Mar 2014 11:16:13 -0400 (EDT)
Subject: [Engine-devel] migration of VM, which protocol actually works?
In-Reply-To: <CA+pz52-DhrpWKamO-uQHT0N-=vXF=xj9khuSG0FE3i3GzkE60g@mail.gmail.com>
References: <CA+pz52-DhrpWKamO-uQHT0N-=vXF=xj9khuSG0FE3i3GzkE60g@mail.gmail.com>
Message-ID: <462446830.266415.1395069373512.JavaMail.zimbra@redhat.com>

----- Original Message ----- 

> From: "aditya mamidwar" <aditya.mamidwar at gmail.com>
> To: users at ovirt.org, engine-devel at ovirt.org
> Sent: Sunday, March 16, 2014 10:59:53 PM
> Subject: [Engine-devel] migration of VM, which protocol actually works?

> i wanted to learn about the modules so that i could understand how the engine
> POSTS and sends data to the backend sql database and other scripts to
> perform various options.

oVirt is a gigantic application. The web interface is written in GWT, so the "post" part happens in GWT. The database operations happen in the dal (data access layer) module, primarily using the DAO pattern. http://en.wikipedia.org/wiki/Data_access_object

> for e.g i need to know which code actually collects the storage path for the
> ISO s during ISCSI storage domain setup.
> also how the hosts, clusters and data centers are made and stored at the
> backend.

Hosts, Clusters, and Data Centers are all "model" objects. They live in UICommonweb. For example, see ClusterModel.java. And they are ultimately persisted to the database using the DAO pattern I mentioned.

> if i want to add a new UI that bypasses some of these complicated tasks
> (again for personal understanding), will I be able to do that.

This sounds very difficult to achieve. Honestly, if you don't need these "complicated tasks," perhaps oVirt is not the right tool for your use case. You might want to look at virt-manager or Kimchi. http://en.wikipedia.org/wiki/KIMCHI

> Also i would like to mention that am working on making a little changes to
> how the ISCSI protocol works..

> My another doubt is:
> when are the NFS/ISCSI/FC protocols actually used in ovirt. like what part of
> the VM running state?
> are their purpose limited to just copying the ISO from the storage center to
> the path required by the Host.

The VMs *live* on these storage types. They are integral to how oVirt works. See http://www.ovirt.org/Architecture

> Are the protocols them self responsible for sending and getting data during
> VM execution on a node.
> The concept of node and migration has left me a little confused.
> since each node can run multiple VMs , so during the running/execution of the
> VM , do the network protocols actully work, if not , then how is that
> achieved.

I don't understand your question, sorry.

> if yes, again my question arises, which module should i focus on regarding
> this issue.

> thanks
> --
> -Aditya Mamidwar

> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel


From masayag at redhat.com  Tue Mar 18 08:35:38 2014
From: masayag at redhat.com (Moti Asayag)
Date: Tue, 18 Mar 2014 04:35:38 -0400 (EDT)
Subject: [Engine-devel] Vms search issue
In-Reply-To: <753807468.870173.1395131108971.JavaMail.zimbra@redhat.com>
Message-ID: <43843125.878305.1395131738461.JavaMail.zimbra@redhat.com>

Hi,

As a result of patch "core : Search VMs based on MAC address" [1]
The same vm is returned by the search query as the number of its nics.

I'd suggest to revert this patch and not introduce a join between
vnics to vm_static vms: first, it won't return the expected result when
a vm has more than a signle nic, second due to adding great impact on that view.

As an alternative, I'd suggest utilizing the join in the search-engine
with vm_interface_view. See SearchObjectAutoCompleter:

// vms - vm network interface
addJoin(SearchObjects.VM_OBJ_NAME, "vm_guid", SearchObjects.VM_NETWORK_INTERFACE_OBJ_NAME, "vm_guid");

So the query will look like: "vms: vnic.MAC = 'xx:xx:xx:xx:xx:xx'"

[1] http://gerrit.ovirt.org/#/c/25805

Regards,
Moti


From rnori at redhat.com  Tue Mar 18 15:03:11 2014
From: rnori at redhat.com (Ravi Nori)
Date: Tue, 18 Mar 2014 11:03:11 -0400
Subject: [Engine-devel] Vms search issue
In-Reply-To: <43843125.878305.1395131738461.JavaMail.zimbra@redhat.com>
References: <43843125.878305.1395131738461.JavaMail.zimbra@redhat.com>
Message-ID: <5328602F.6050501@redhat.com>

On 03/18/2014 04:35 AM, Moti Asayag wrote:
> Hi,
>
> As a result of patch "core : Search VMs based on MAC address" [1]
> The same vm is returned by the search query as the number of its nics.
>
> I'd suggest to revert this patch and not introduce a join between
> vnics to vm_static vms: first, it won't return the expected result when
> a vm has more than a signle nic, second due to adding great impact on that view.
>
> As an alternative, I'd suggest utilizing the join in the search-engine
> with vm_interface_view. See SearchObjectAutoCompleter:
>
> // vms - vm network interface
> addJoin(SearchObjects.VM_OBJ_NAME, "vm_guid", SearchObjects.VM_NETWORK_INTERFACE_OBJ_NAME, "vm_guid");
>
> So the query will look like: "vms: vnic.MAC = 'xx:xx:xx:xx:xx:xx'"
>
> [1] http://gerrit.ovirt.org/#/c/25805
>
> Regards,
> Moti

Hi Moti,

Fixed in patch http://gerrit.ovirt.org/#/c/25848

Thanks

Ravi


From dfediuck at redhat.com  Wed Mar 19 15:52:29 2014
From: dfediuck at redhat.com (Doron Fediuck)
Date: Wed, 19 Mar 2014 11:52:29 -0400 (EDT)
Subject: [Engine-devel] [ANN] oVirt 3.4.0 GA postponed to Monday, March 24
In-Reply-To: <531F36FF.6000600@redhat.com>
Message-ID: <1251687102.2186519.1395244349609.JavaMail.zimbra@redhat.com>

Hi,
due to 2 blocker bugs we found, the GA is pushed to Monday, March 24.

This should provide sufficient time for us to properly fix and test
oVirt 3.4, in order to make sure we have no critical issues in the
3.4.0 version we're all waiting for.

Thanks for understanding,
Doron


From S.Kieske at mittwald.de  Thu Mar 20 10:26:37 2014
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Thu, 20 Mar 2014 10:26:37 +0000
Subject: [Engine-devel] [Users] centralized Logging engine and hypervisor
In-Reply-To: <1526297378.3068379.1395309861768.JavaMail.zimbra@redhat.com>
References: <5329C1AB.1000909@mittwald.de> <532AAF63.2030601@axonpro.sk>
	<532AB12E.3030101@mittwald.de>
	<1526297378.3068379.1395309861768.JavaMail.zimbra@redhat.com>
Message-ID: <532AC202.6000206@mittwald.de>



Am 20.03.2014 11:04, schrieb Martin Perina:
> 
> 
> 
> I didn't try it, but some info can be found in this thread:
> 
> http://stackoverflow.com/questions/10400263/jboss-as-7-configure-logging-to-syslog-appender


Thanks for the link, for documentation purposes, I'll post my findings
here to, so if someone needs this in the future, feel free to use it:

Here is a custom implemented syslog handler for jboss 7.1:

http://randomtekkstuff.blogspot.de/2013/03/jboss-as-7-syslog-handler.html

I will test this out, once I found the jboss module directory..

In the meantime:

Would ovirt-devs consider it save to "sideload" my own
jboss module?

I know this will get painful to maintain once I want to upgrade
so I'm already asking:

Is there a chance as a first step to include a custom
syslog handler jboss module into ovirt (for jboss < 7.2) ?

Later this could get expanded to easily allow to use syslog..

-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Gesch?ftsf?hrer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplement?rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

From danken at redhat.com  Thu Mar 20 11:00:46 2014
From: danken at redhat.com (Dan Kenigsberg)
Date: Thu, 20 Mar 2014 11:00:46 +0000
Subject: [Engine-devel] hosted engine in 3.4
In-Reply-To: <5322CFD8.3020505@redhat.com>
References: <5321B22F.2000408@redhat.com>
	<1585193153.19831369.1394718849438.JavaMail.zimbra@redhat.com>
	<5321BC3C.5020305@redhat.com>
	<83505232.18075115.1394788381088.JavaMail.zimbra@redhat.com>
	<5322CE53.2060607@redhat.com> <5322CFD8.3020505@redhat.com>
Message-ID: <20140320110046.GF31135@redhat.com>

On Fri, Mar 14, 2014 at 10:46:00AM +0100, Sandro Bonazzola wrote:
> Il 14/03/2014 10:39, Jiri Moskovcak ha scritto:
> > On 03/14/2014 10:13 AM, Martin Sivak wrote:
> >> Hi,
> >>
> >>>>> 1. You need to have some MAC address with static ip and FQDN, otherwise
> >>>>> you have to change /etc/hosts at least for the first part of the setup
> >>
> >> I believe you were there when we were discussing this with pstehlik :)
> >>
> >> Btw in this case you have to change /etc/hosts on all hosts and inside the
> >> engine VM.
> >>
> >>>>> 2. When the VM install is complete I would expect the setup wizard to
> >>>>> install the engine to the VM automatically - which at least in my case -
> >>>>> doesn't happen
> >>
> >> I also proposed kickstart based setup to Sandro. You would give a repo to setup
> >> and it would download the kernel/initrd from it [1] and create a kickstart with
> >> the right root password, engine setup and so on..
> >>
> >> [1] http://ftp.linux.cz/pub/linux/fedora/linux/releases/20/Fedora/x86_64/os/images/pxeboot/
> >>
> >>>>> 1. once I managed to install the engine to the vm it tried to add the
> >>>>> host it was running on to the engine and it failed with a message "Host
> >>>>> compatibility version doesn't match the cluster compatibility version",
> >>>>> and then it marked the host as non operational which killed the vm with
> >>>>> the engine, so the engine actually committed suicide?
> >>
> >> Check your VDSM version. Especially the content of /usr/share/vdsm/dsaversion.py
> >> file. There are couple of lists specifying the cluster and engine versions that
> >> the VDSM supports.
> >>
> >> If you use 3.4 engine it needs 3.4 VDSM as well.. and the prerelease repo is not
> >> enabled by default.
> >>
> > 
> > vdsm version on the host:
> > vdsm-4.14.5-0.fc19.x86_64 @ovirt-3.4.0-prerelease
> > 
> > ovirt-engine installed in the VM:
> > ovirt-engine-3.4.0-0.13.rc.fc19.noarch
> > 
> > - and it dies with the error message: "Host hosted_engine_1 is compatible with versions (3.0,3.1,3.2,3.3) and cannot join Cluster Default which is set
> > to version 3.4"
> 
> Above is probably due to libvirt not updated to latest from fedora-virt-preview repo.
> Dan, Yaniv, any reason for not explicitly requiring the updated version of libvirt in VDSM package?
> If it's just because libvirt is not yet in official Fedora repository, maybe we should ship it on ovirt repository until it's in and put some pressure
> on libvirt people for having them pushing the newest package into Fedora.
> Thoughts?

The problem is that F19's libvirt lacks VIR_MIGRATE_ABORT_ON_ERROR
(http://gerrit.ovirt.org/#/c/23273/) which is required by clusterLevel
3.4.

We found it quite rude for a vdsm upgrade in Fedora 19 to require a
version of libvirt that is not on that platform, particularly since the
existing version is perfectly usable for clusterLevel 3.3.

I do not believe we should ship libvirt within oVirt. It is a pain to
mainatain (and issue bugfixes, and worry about security hotfixes). A
prefereable approach would be to have ovirt-release.f19.rpm link to the
relevant virt-preview repository.





From sbonazzo at redhat.com  Thu Mar 20 11:08:38 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Thu, 20 Mar 2014 12:08:38 +0100
Subject: [Engine-devel] hosted engine in 3.4
In-Reply-To: <20140320110046.GF31135@redhat.com>
References: <5321B22F.2000408@redhat.com>
	<1585193153.19831369.1394718849438.JavaMail.zimbra@redhat.com>
	<5321BC3C.5020305@redhat.com>
	<83505232.18075115.1394788381088.JavaMail.zimbra@redhat.com>
	<5322CE53.2060607@redhat.com> <5322CFD8.3020505@redhat.com>
	<20140320110046.GF31135@redhat.com>
Message-ID: <532ACC36.4000509@redhat.com>

Il 20/03/2014 12:00, Dan Kenigsberg ha scritto:
> On Fri, Mar 14, 2014 at 10:46:00AM +0100, Sandro Bonazzola wrote:
>> Il 14/03/2014 10:39, Jiri Moskovcak ha scritto:
>>> On 03/14/2014 10:13 AM, Martin Sivak wrote:
>>>> Hi,
>>>>
>>>>>>> 1. You need to have some MAC address with static ip and FQDN, otherwise
>>>>>>> you have to change /etc/hosts at least for the first part of the setup
>>>>
>>>> I believe you were there when we were discussing this with pstehlik :)
>>>>
>>>> Btw in this case you have to change /etc/hosts on all hosts and inside the
>>>> engine VM.
>>>>
>>>>>>> 2. When the VM install is complete I would expect the setup wizard to
>>>>>>> install the engine to the VM automatically - which at least in my case -
>>>>>>> doesn't happen
>>>>
>>>> I also proposed kickstart based setup to Sandro. You would give a repo to setup
>>>> and it would download the kernel/initrd from it [1] and create a kickstart with
>>>> the right root password, engine setup and so on..
>>>>
>>>> [1] http://ftp.linux.cz/pub/linux/fedora/linux/releases/20/Fedora/x86_64/os/images/pxeboot/
>>>>
>>>>>>> 1. once I managed to install the engine to the vm it tried to add the
>>>>>>> host it was running on to the engine and it failed with a message "Host
>>>>>>> compatibility version doesn't match the cluster compatibility version",
>>>>>>> and then it marked the host as non operational which killed the vm with
>>>>>>> the engine, so the engine actually committed suicide?
>>>>
>>>> Check your VDSM version. Especially the content of /usr/share/vdsm/dsaversion.py
>>>> file. There are couple of lists specifying the cluster and engine versions that
>>>> the VDSM supports.
>>>>
>>>> If you use 3.4 engine it needs 3.4 VDSM as well.. and the prerelease repo is not
>>>> enabled by default.
>>>>
>>>
>>> vdsm version on the host:
>>> vdsm-4.14.5-0.fc19.x86_64 @ovirt-3.4.0-prerelease
>>>
>>> ovirt-engine installed in the VM:
>>> ovirt-engine-3.4.0-0.13.rc.fc19.noarch
>>>
>>> - and it dies with the error message: "Host hosted_engine_1 is compatible with versions (3.0,3.1,3.2,3.3) and cannot join Cluster Default which is set
>>> to version 3.4"
>>
>> Above is probably due to libvirt not updated to latest from fedora-virt-preview repo.
>> Dan, Yaniv, any reason for not explicitly requiring the updated version of libvirt in VDSM package?
>> If it's just because libvirt is not yet in official Fedora repository, maybe we should ship it on ovirt repository until it's in and put some pressure
>> on libvirt people for having them pushing the newest package into Fedora.
>> Thoughts?
> 
> The problem is that F19's libvirt lacks VIR_MIGRATE_ABORT_ON_ERROR
> (http://gerrit.ovirt.org/#/c/23273/) which is required by clusterLevel
> 3.4.
> 
> We found it quite rude for a vdsm upgrade in Fedora 19 to require a
> version of libvirt that is not on that platform, particularly since the
> existing version is perfectly usable for clusterLevel 3.3.
> 
> I do not believe we should ship libvirt within oVirt. It is a pain to
> mainatain (and issue bugfixes, and worry about security hotfixes). A
> prefereable approach would be to have ovirt-release.f19.rpm link to the
> relevant virt-preview repository.

Any chance of having new libvirt ported to f19 main repository?

> 
> 
> 


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From plysab at gmail.com  Thu Mar 20 11:14:18 2014
From: plysab at gmail.com (plysan)
Date: Thu, 20 Mar 2014 19:14:18 +0800
Subject: [Engine-devel] [Users] centralized Logging engine and hypervisor
In-Reply-To: <532AC202.6000206@mittwald.de>
References: <5329C1AB.1000909@mittwald.de> <532AAF63.2030601@axonpro.sk>
	<532AB12E.3030101@mittwald.de>
	<1526297378.3068379.1395309861768.JavaMail.zimbra@redhat.com>
	<532AC202.6000206@mittwald.de>
Message-ID: <CANDY9WMoM42UiuSsFFPXPcWynA-BPxcrtSfrwCg6OPZkabRb9Q@mail.gmail.com>

2014-03-20 18:26 GMT+08:00 Sven Kieske <S.Kieske at mittwald.de>:

>
>
> Am 20.03.2014 11:04, schrieb Martin Perina:
> >
> >
> >
> > I didn't try it, but some info can be found in this thread:
> >
> >
> http://stackoverflow.com/questions/10400263/jboss-as-7-configure-logging-to-syslog-appender
>
>
> Thanks for the link, for documentation purposes, I'll post my findings
> here to, so if someone needs this in the future, feel free to use it:
>
> Here is a custom implemented syslog handler for jboss 7.1:
>
> http://randomtekkstuff.blogspot.de/2013/03/jboss-as-7-syslog-handler.html
>
> I will test this out, once I found the jboss module directory..
>
I think the runtime directory is in /usr/share/ovirt-engine/modules, after
ps aux |grep ovirt

>
> In the meantime:
>
> Would ovirt-devs consider it save to "sideload" my own
> jboss module?


> I know this will get painful to maintain once I want to upgrade
> so I'm already asking:
>
> Is there a chance as a first step to include a custom
> syslog handler jboss module into ovirt (for jboss < 7.2) ?
>
I think oVirt uses jboss-modules-maven-plugin to create a module,
If you want to create one, the syslog handler in your case,
you may create a subproject containing the java code and
tweak some of the pom.xml adding the jboss-modules-maven-plugin config,
as the other modules do.

>
> Later this could get expanded to easily allow to use syslog..
>
> --
> Mit freundlichen Gr??en / Regards
>
> Sven Kieske
>
> Systemadministrator
> Mittwald CM Service GmbH & Co. KG
> K?nigsberger Stra?e 6
> 32339 Espelkamp
> T: +49-5772-293-100
> F: +49-5772-293-333
> https://www.mittwald.de
> Gesch?ftsf?hrer: Robert Meyer
> St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
> Komplement?rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140320/7733f485/attachment.html>

From S.Kieske at mittwald.de  Thu Mar 20 12:16:22 2014
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Thu, 20 Mar 2014 12:16:22 +0000
Subject: [Engine-devel] [Users] centralized Logging engine and hypervisor
In-Reply-To: <CANDY9WMoM42UiuSsFFPXPcWynA-BPxcrtSfrwCg6OPZkabRb9Q@mail.gmail.com>
References: <5329C1AB.1000909@mittwald.de>
	<CANDY9WMoM42UiuSsFFPXPcWynA-BPxcrtSfrwCg6OPZkabRb9Q@mail.gmail.com>
Message-ID: <532ADBBB.2060305@mittwald.de>

First: Thanks for the fast answer!

Second: I decided that this is a much too painful
hack into ovirt regarding maintainability, thus
I will let ovirt log into files like it does already
and pipe those into syslog.

But it would be cool if you could work towards
integrating this feature into ovirt in the future, maybe
for 3.5 or 4.0.

So I created an RFE at:

https://bugzilla.redhat.com/show_bug.cgi?id=1078738

I think many large data centers could use this feature
as most people tend to have centralized logging already.

Am 20.03.2014 12:14, schrieb plysan:
> 2014-03-20 18:26 GMT+08:00 Sven Kieske <S.Kieske at mittwald.de>:
> 
>>
>>
>> Am 20.03.2014 11:04, schrieb Martin Perina:
>>>
>>>
>>>
>>> I didn't try it, but some info can be found in this thread:
>>>
>>>
>> http://stackoverflow.com/questions/10400263/jboss-as-7-configure-logging-to-syslog-appender
>>
>>
>> Thanks for the link, for documentation purposes, I'll post my findings
>> here to, so if someone needs this in the future, feel free to use it:
>>
>> Here is a custom implemented syslog handler for jboss 7.1:
>>
>> http://randomtekkstuff.blogspot.de/2013/03/jboss-as-7-syslog-handler.html
>>
>> I will test this out, once I found the jboss module directory..
>>
> I think the runtime directory is in /usr/share/ovirt-engine/modules, after
> ps aux |grep ovirt
> 
>>
>> In the meantime:
>>
>> Would ovirt-devs consider it save to "sideload" my own
>> jboss module?
> 
> 
>> I know this will get painful to maintain once I want to upgrade
>> so I'm already asking:
>>
>> Is there a chance as a first step to include a custom
>> syslog handler jboss module into ovirt (for jboss < 7.2) ?
>>
> I think oVirt uses jboss-modules-maven-plugin to create a module,
> If you want to create one, the syslog handler in your case,
> you may create a subproject containing the java code and
> tweak some of the pom.xml adding the jboss-modules-maven-plugin config,
> as the other modules do.
> 
>>
>> Later this could get expanded to easily allow to use syslog..


-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Gesch?ftsf?hrer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplement?rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

From plysab at gmail.com  Thu Mar 20 14:30:49 2014
From: plysab at gmail.com (plysan)
Date: Thu, 20 Mar 2014 22:30:49 +0800
Subject: [Engine-devel] [Users] centralized Logging engine and hypervisor
In-Reply-To: <532ADBBB.2060305@mittwald.de>
References: <5329C1AB.1000909@mittwald.de>
	<CANDY9WMoM42UiuSsFFPXPcWynA-BPxcrtSfrwCg6OPZkabRb9Q@mail.gmail.com>
	<532ADBBB.2060305@mittwald.de>
Message-ID: <CANDY9WO1D1QLGsT+DBkV7H4zOMu--aZ-AKZq5d=B-tAAdSygEA@mail.gmail.com>

yeah, I'll try :)


2014-03-20 20:16 GMT+08:00 Sven Kieske <S.Kieske at mittwald.de>:

> First: Thanks for the fast answer!
>
> Second: I decided that this is a much too painful
> hack into ovirt regarding maintainability, thus
> I will let ovirt log into files like it does already
> and pipe those into syslog.
>
> But it would be cool if you could work towards
> integrating this feature into ovirt in the future, maybe
> for 3.5 or 4.0.
>
> So I created an RFE at:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1078738
>
> I think many large data centers could use this feature
> as most people tend to have centralized logging already.
>
> Am 20.03.2014 12:14, schrieb plysan:
> > 2014-03-20 18:26 GMT+08:00 Sven Kieske <S.Kieske at mittwald.de>:
> >
> >>
> >>
> >> Am 20.03.2014 11:04, schrieb Martin Perina:
> >>>
> >>>
> >>>
> >>> I didn't try it, but some info can be found in this thread:
> >>>
> >>>
> >>
> http://stackoverflow.com/questions/10400263/jboss-as-7-configure-logging-to-syslog-appender
> >>
> >>
> >> Thanks for the link, for documentation purposes, I'll post my findings
> >> here to, so if someone needs this in the future, feel free to use it:
> >>
> >> Here is a custom implemented syslog handler for jboss 7.1:
> >>
> >>
> http://randomtekkstuff.blogspot.de/2013/03/jboss-as-7-syslog-handler.html
> >>
> >> I will test this out, once I found the jboss module directory..
> >>
> > I think the runtime directory is in /usr/share/ovirt-engine/modules,
> after
> > ps aux |grep ovirt
> >
> >>
> >> In the meantime:
> >>
> >> Would ovirt-devs consider it save to "sideload" my own
> >> jboss module?
> >
> >
> >> I know this will get painful to maintain once I want to upgrade
> >> so I'm already asking:
> >>
> >> Is there a chance as a first step to include a custom
> >> syslog handler jboss module into ovirt (for jboss < 7.2) ?
> >>
> > I think oVirt uses jboss-modules-maven-plugin to create a module,
> > If you want to create one, the syslog handler in your case,
> > you may create a subproject containing the java code and
> > tweak some of the pom.xml adding the jboss-modules-maven-plugin config,
> > as the other modules do.
> >
> >>
> >> Later this could get expanded to easily allow to use syslog..
>
>
> --
> Mit freundlichen Gr??en / Regards
>
> Sven Kieske
>
> Systemadministrator
> Mittwald CM Service GmbH & Co. KG
> K?nigsberger Stra?e 6
> 32339 Espelkamp
> T: +49-5772-293-100
> F: +49-5772-293-333
> https://www.mittwald.de
> Gesch?ftsf?hrer: Robert Meyer
> St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
> Komplement?rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140320/650fcc63/attachment.html>

From masayag at redhat.com  Thu Mar 20 19:20:05 2014
From: masayag at redhat.com (Moti Asayag)
Date: Thu, 20 Mar 2014 15:20:05 -0400 (EDT)
Subject: [Engine-devel] Change in ovirt-engine[master]: core: enable to
 decrease DC compatibility...
In-Reply-To: <577568761.2861329.1394657047677.JavaMail.zimbra@redhat.com>
References: <gerrit.1392716300399.I73284f641b7f80b380b39efbbd7b4566f55119b6@gerrit.ovirt.org>
	<201403112226.s2BMQpjX013721@gerrit.ovirt.org>
	<53202FF4.6030004@redhat.com> <53203A24.4040200@redhat.com>
	<852680674.2850211.1394655652908.JavaMail.zimbra@redhat.com>
	<5320C4A9.5010209@redhat.com>
	<577568761.2861329.1394657047677.JavaMail.zimbra@redhat.com>
Message-ID: <1789679933.641640.1395343205633.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Moti Asayag" <masayag at redhat.com>
> To: "Livnat Peer" <lpeer at redhat.com>
> Cc: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
> Sent: Wednesday, March 12, 2014 10:44:07 PM
> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...
> 
> 
> 
> ----- Original Message -----
> > From: "Livnat Peer" <lpeer at redhat.com>
> > To: "Moti Asayag" <masayag at redhat.com>
> > Cc: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
> > Sent: Wednesday, March 12, 2014 10:33:45 PM
> > Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to
> > decrease DC compatibility...
> > 
> > On 03/12/2014 10:20 PM, Moti Asayag wrote:
> > > 
> > > 
> > > ----- Original Message -----
> > >> From: "Livnat Peer" <lpeer at redhat.com>
> > >> To: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
> > >> Sent: Wednesday, March 12, 2014 12:42:44 PM
> > >> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable
> > >> to	decrease DC compatibility...
> > >>
> > >> On 03/12/2014 11:59 AM, Itamar Heim wrote:
> > >>> On 03/12/2014 12:26 AM, emesika at redhat.com wrote:
> > >>>> Eli Mesika has submitted this change and it was merged.
> > >>>>
> > >>>> Change subject: core: enable to decrease DC compatibility...
> > >>>> ......................................................................
> > >>>>
> > >>>>
> > >>>> core: enable to decrease DC compatibility...
> > >>>>
> > >>>> enable to decrease DC compatibility version if DC has no clusters
> > >>>>
> > >>>> This patch enables to decrease the DC compatibility version if DC has
> > >>>> no
> > >>>> clusters.
> > >>>
> > >>> Eli - just saw this. I'm pretty sure it would be *bad* to downgrade a
> > >>> DC
> > >>> version if it has storage domains as well. not sure if this is checked
> > >>> already or not.
> > >>>
> > >>> may also be an issue with some logical network features.
> > >>>
> > >>
> > >> Most of the network features are driven from cluster level, we enable
> > >> using the features on all DC level (actually >=3.1) but actually enable
> > >> /disable the feature when attaching the network to a cluster.
> > >>
> > >> So from network perspective I think it should be fine to downgrade the
> > >> DC level even if there are networks in the DC (at least now this could
> > >> change in future versions).
> > >>
> > > 
> > > Actually we block adding or updating networks if the feature is not
> > > supported
> > > on the network's DC level, for example: STP, Jumbo frames and non-vm
> > > network.
> > > 
> > 
> > From which DC level we support STP?  Jumbo frames? non-vm network? isn't
> > all of them supported in >=3.1 ?
> > 
> 
> Yes, mainly the problem with downgrading a DC to 3.0.
>

I had a discussion with Mike (cc'ed) about several possible solutions
for the networks compatibility within the data-center.

The first proposed solution would utilize the NetworkUpdateValidator,
a validation utility that verifies the compatibility of a network
to the data-center. This solution preserves the same behaviour as today,
that the features of network-level are dictated by the DC version. No
need to reimplement any logic in the decrease DC version flow, just use
an existing one to be applied for any network within the DC.

The second solution suggests we allow any settings of a network, and 
compatibility enforcement is done on attaching the network to the clusters.
This modifies the existing behaviour and expands the capabilities of the
engine to support advanced network feature in advanced cluster within an
old data center (i.e. cluster 3.4 in 3.0 data-center could and probably
should use non-vm network, jumbo-frames and more).
This option requires more work in add/update network and attach network to cluster
flows, both on the backend and UI. Specifically since by default a new network
created in a DC is being attached to all of the clusters.
Perhaps the second option deserves to be treated as RFE and not as a bug fix.

Thoughts ?

Moti
 
> > > Therefore if the management network was configured with any of those
> > > feature,
> > > there is a need to either block the action or to 'initialize' the network
> > > to
> > > the default settings (as new network being added).
> > > 
> > >> In general I believe the use case for this patch is mostly for empty DCs
> > >> so for simplicity we should block it if there are networks or SD in the
> > >> DC when downgrading.
> > >>
> > >> Livnat
> > >>
> > >>
> > >>>>
> > >>>> Change-Id: I73284f641b7f80b380b39efbbd7b4566f55119b6
> > >>>> Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1057029
> > >>>> Signed-off-by: Eli Mesika <emesika at redhat.com>
> > >>>> ---
> > >>>> M
> > >>>> backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/storage/UpdateStoragePoolCommand.java
> > >>>>
> > >>>> 1 file changed, 5 insertions(+), 2 deletions(-)
> > >>>>
> > >>>> Approvals:
> > >>>>    Eli Mesika: Verified
> > >>>>    Ravi Nori: Looks good to me, but someone else must approve
> > >>>>    Yair Zaslavsky: Looks good to me, approved
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>
> > >> _______________________________________________
> > >> Engine-devel mailing list
> > >> Engine-devel at ovirt.org
> > >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >>
> > 
> > 
> 


From gshereme at redhat.com  Fri Mar 21 00:32:54 2014
From: gshereme at redhat.com (Greg Sheremeta)
Date: Thu, 20 Mar 2014 20:32:54 -0400 (EDT)
Subject: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
In-Reply-To: <1313494537.5573093.1393511200703.JavaMail.zimbra@redhat.com>
References: <127908115.1936906.1392393046744.JavaMail.zimbra@redhat.com>
	<5304CD77.1010407@redhat.com>
	<1944239316.3104044.1392825066732.JavaMail.zimbra@redhat.com>
	<3018426.h1T2jmR5QI@awels>
	<1313494537.5573093.1393511200703.JavaMail.zimbra@redhat.com>
Message-ID: <1286350009.1771204.1395361974830.JavaMail.zimbra@redhat.com>

I'm afraid I need to resurrect this. I'm again seeing unbearable slowness with GWT Dev Mode in webadmin on master. The first load is tolerable, and one or two refreshes are ok, but after that it bogs down and is unusable.

Anyone else?

Greg


----- Original Message -----
> From: "Greg Sheremeta" <gshereme at redhat.com>
> To: awels at redhat.com
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, February 27, 2014 9:26:40 AM
> Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> 
> Thanks, and great work figuring it out :)
> 
> Greg
> 
> ----- Original Message -----
> > From: "Alexander Wels" <awels at redhat.com>
> > To: "Greg Sheremeta" <gshereme at redhat.com>
> > Cc: "Lior Vernia" <lvernia at redhat.com>, "Martin Betak" <mbetak at redhat.com>,
> > "engine-devel" <engine-devel at ovirt.org>,
> > "Vojtech Szocs" <vszocs at redhat.com>
> > Sent: Thursday, February 27, 2014 8:32:00 AM
> > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> > 
> > Master is back to its normal zippy self in GWT dev mode as of 8:25 EST Feb
> > 27th 2014. With relative values for zippy. If you are annoyed by the slow
> > GTW
> > dev mode be sure to fetch and rebase.
> > 
> > On Wednesday, February 19, 2014 10:51:06 AM Greg Sheremeta wrote:
> > > I agree with Lior. Alexander (cc'd) has a patch that will hopefully
> > > address
> > > it.
> > > 
> > > Greg
> > > 
> > > ----- Original Message -----
> > > 
> > > > From: "Lior Vernia" <lvernia at redhat.com>
> > > > To: "Martin Betak" <mbetak at redhat.com>
> > > > Cc: "Greg Sheremeta" <gshereme at redhat.com>, "engine-devel"
> > > > <engine-devel at ovirt.org>, "Vojtech Szocs" <vszocs at redhat.com>
> > > > Sent: Wednesday, February 19, 2014 10:27:51 AM
> > > > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> > > > 
> > > > Hi guys,
> > > > 
> > > > On 17/02/14 13:15, Martin Betak wrote:
> > > > > Yes, this has been my developer experience since I joined the
> > > > > project.
> > > > 
> > > > To my eyes, it hasn't always been this slow. Something aggravated the
> > > > situation sometime in the past 3 weeks. I'm not knowledgeable enough to
> > > > say what went wrong, but this is not simply a gradual degradation of
> > > > more code being compiled, etc.
> > > > 
> > > > Lior.
> > > > 
> > > > > The 5-6 minute page-loads are a standard but the GWT Dev Mode gets
> > > > > progressively
> > > > > slower after each "refresh" that involves frontend recompilation.
> > > > > Also
> > > > > the
> > > > > memory
> > > > > consumption increases and after 5-th "refresh" or so I have to kill
> > > > > it
> > > > > and
> > > > > recompile the whole engine.
> > > > > 
> > > > > Any improvement to current status would be much appreciated.
> > > > > 
> > > > > Martin
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > 
> > > > >> From: "Greg Sheremeta" <gshereme at redhat.com>
> > > > >> To: "engine-devel" <engine-devel at ovirt.org>
> > > > >> Sent: Friday, February 14, 2014 4:50:46 PM
> > > > >> Subject: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> > > > >> 
> > > > >> Has anyone else noticed that GWT Dev Mode is unbearably slow for
> > > > >> WebAdmin?
> > > > >> On
> > > > >> my machine, it's to the point where I might as well rebuild the
> > > > >> entire
> > > > >> application for every change and not bother with Dev Mode. Pages
> > > > >> take
> > > > >> 4
> > > > >> or
> > > > >> 5
> > > > >> minutes to render. Sometimes after 5 minutes, I just give up, close
> > > > >> everything, and rebuild the app.
> > > > >> 
> > > > >> For now, I want to see if others have this issue. If we confirm that
> > > > >> it's
> > > > >> widespread, we can discuss ways to mitigate.
> > > > >> 
> > > > >> Greg Sheremeta
> > > > >> Red Hat, Inc.
> > > > >> Sr. Software Engineer, RHEV
> > > > >> Cell: 919-807-1086
> > > > >> gshereme at redhat.com
> > > > >> _______________________________________________
> > > > >> Engine-devel mailing list
> > > > >> Engine-devel at ovirt.org
> > > > >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > 
> > > > > _______________________________________________
> > > > > Engine-devel mailing list
> > > > > Engine-devel at ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From lpeer at redhat.com  Fri Mar 21 06:33:59 2014
From: lpeer at redhat.com (Livnat Peer)
Date: Fri, 21 Mar 2014 08:33:59 +0200
Subject: [Engine-devel] Change in ovirt-engine[master]: core: enable to
 decrease DC compatibility...
In-Reply-To: <1789679933.641640.1395343205633.JavaMail.zimbra@redhat.com>
References: <gerrit.1392716300399.I73284f641b7f80b380b39efbbd7b4566f55119b6@gerrit.ovirt.org>	<201403112226.s2BMQpjX013721@gerrit.ovirt.org>	<53202FF4.6030004@redhat.com>
	<53203A24.4040200@redhat.com>	<852680674.2850211.1394655652908.JavaMail.zimbra@redhat.com>	<5320C4A9.5010209@redhat.com>	<577568761.2861329.1394657047677.JavaMail.zimbra@redhat.com>
	<1789679933.641640.1395343205633.JavaMail.zimbra@redhat.com>
Message-ID: <532BDD57.1090604@redhat.com>

On 03/20/2014 09:20 PM, Moti Asayag wrote:
> ----- Original Message -----
>> From: "Moti Asayag" <masayag at redhat.com>
>> To: "Livnat Peer" <lpeer at redhat.com>
>> Cc: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
>> Sent: Wednesday, March 12, 2014 10:44:07 PM
>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...
>>
>>
>>
>> ----- Original Message -----
>>> From: "Livnat Peer" <lpeer at redhat.com>
>>> To: "Moti Asayag" <masayag at redhat.com>
>>> Cc: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
>>> Sent: Wednesday, March 12, 2014 10:33:45 PM
>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to
>>> decrease DC compatibility...
>>>
>>> On 03/12/2014 10:20 PM, Moti Asayag wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Livnat Peer" <lpeer at redhat.com>
>>>>> To: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
>>>>> Sent: Wednesday, March 12, 2014 12:42:44 PM
>>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable
>>>>> to	decrease DC compatibility...
>>>>>
>>>>> On 03/12/2014 11:59 AM, Itamar Heim wrote:
>>>>>> On 03/12/2014 12:26 AM, emesika at redhat.com wrote:
>>>>>>> Eli Mesika has submitted this change and it was merged.
>>>>>>>
>>>>>>> Change subject: core: enable to decrease DC compatibility...
>>>>>>> ......................................................................
>>>>>>>
>>>>>>>
>>>>>>> core: enable to decrease DC compatibility...
>>>>>>>
>>>>>>> enable to decrease DC compatibility version if DC has no clusters
>>>>>>>
>>>>>>> This patch enables to decrease the DC compatibility version if DC has
>>>>>>> no
>>>>>>> clusters.
>>>>>>
>>>>>> Eli - just saw this. I'm pretty sure it would be *bad* to downgrade a
>>>>>> DC
>>>>>> version if it has storage domains as well. not sure if this is checked
>>>>>> already or not.
>>>>>>
>>>>>> may also be an issue with some logical network features.
>>>>>>
>>>>>
>>>>> Most of the network features are driven from cluster level, we enable
>>>>> using the features on all DC level (actually >=3.1) but actually enable
>>>>> /disable the feature when attaching the network to a cluster.
>>>>>
>>>>> So from network perspective I think it should be fine to downgrade the
>>>>> DC level even if there are networks in the DC (at least now this could
>>>>> change in future versions).
>>>>>
>>>>
>>>> Actually we block adding or updating networks if the feature is not
>>>> supported
>>>> on the network's DC level, for example: STP, Jumbo frames and non-vm
>>>> network.
>>>>
>>>
>>> From which DC level we support STP?  Jumbo frames? non-vm network? isn't
>>> all of them supported in >=3.1 ?
>>>
>>
>> Yes, mainly the problem with downgrading a DC to 3.0.
>>
> 
> I had a discussion with Mike (cc'ed) about several possible solutions
> for the networks compatibility within the data-center.
> 
> The first proposed solution would utilize the NetworkUpdateValidator,
> a validation utility that verifies the compatibility of a network
> to the data-center. This solution preserves the same behaviour as today,
> that the features of network-level are dictated by the DC version. No
> need to reimplement any logic in the decrease DC version flow, just use
> an existing one to be applied for any network within the DC.
> 
> The second solution suggests we allow any settings of a network, and 
> compatibility enforcement is done on attaching the network to the clusters.
> This modifies the existing behaviour and expands the capabilities of the
> engine to support advanced network feature in advanced cluster within an
> old data center (i.e. cluster 3.4 in 3.0 data-center could and probably
> should use non-vm network, jumbo-frames and more).
> This option requires more work in add/update network and attach network to cluster
> flows, both on the backend and UI. Specifically since by default a new network
> created in a DC is being attached to all of the clusters.
> Perhaps the second option deserves to be treated as RFE and not as a bug fix.
> 
> Thoughts ?
> 

The second approach you suggested is equivalent to creating networks in
cluster level vs. DC level, which is used today.

We should consider that for 4.0 and think on the pros and cons of doing so.

In general for this specific discussion I think a simple block on DC
downgrade should be enough.

> Moti
>  
>>>> Therefore if the management network was configured with any of those
>>>> feature,
>>>> there is a need to either block the action or to 'initialize' the network
>>>> to
>>>> the default settings (as new network being added).
>>>>
>>>>> In general I believe the use case for this patch is mostly for empty DCs
>>>>> so for simplicity we should block it if there are networks or SD in the
>>>>> DC when downgrading.
>>>>>
>>>>> Livnat
>>>>>
>>>>>
>>>>>>>
>>>>>>> Change-Id: I73284f641b7f80b380b39efbbd7b4566f55119b6
>>>>>>> Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1057029
>>>>>>> Signed-off-by: Eli Mesika <emesika at redhat.com>
>>>>>>> ---
>>>>>>> M
>>>>>>> backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/storage/UpdateStoragePoolCommand.java
>>>>>>>
>>>>>>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>>>>>>
>>>>>>> Approvals:
>>>>>>>    Eli Mesika: Verified
>>>>>>>    Ravi Nori: Looks good to me, but someone else must approve
>>>>>>>    Yair Zaslavsky: Looks good to me, approved
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>
>>>
>>>
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 



From aditya.mamidwar at gmail.com  Fri Mar 21 10:14:01 2014
From: aditya.mamidwar at gmail.com (aditya mamidwar)
Date: Fri, 21 Mar 2014 15:44:01 +0530
Subject: [Engine-devel] [Users] adding scripts
In-Reply-To: <2582932.ip0y7S9grx@awels>
References: <532447ee.a70e440a.3ce3.ffffd5f5@mx.google.com>
	<2582932.ip0y7S9grx@awels>
Message-ID: <CA+pz52__SFAV7_6pom_L4HNwpG6b-YUbOk92f04PF0HtOp9keg@mail.gmail.com>

Hey,
my team is working on adding AoE protocol support to ovirt.

am thus facing following difficulties:
1 : i wrote the required code using in bash scripting, which i wish to
invoke after a click of button in the ovirt-portal. (which does not seem to
be possible). can you help on that? which programming language should i
use, and how that file should be invoked.

2. for ISOs to be available, i need to enable hosts configured in clusters
and storage domains of ATA type. (currently NFS, iSCSI and FC are done).
which files should i focus on changing for above functionality.

3. How do i change the custom layout of the engine? (like adding a few
extra buttons.) please specify the files responsible.

4. the above questions stress that am facing difficulty in identifying
files responsible for a particular module. is there a better way to do that
instead of digging up the entire source code. ( a documentation if
available.)



On Mon, Mar 17, 2014 at 5:52 PM, Alexander Wels <awels at redhat.com> wrote:

> Aditya,
>
> That is because that file doesn't exist. We map that name to a servlet in
> web.xml. If you want to modify the GWT host page take a look at
> GwtDynamicHostPageServlet.java and its sub classes (for user portal and
> webadmin). As well as GwtHostPage.jsp. You will find there is almost
> nothing in
> that page as all the HTML is being generated at runtime using GWT.
>
> Since you are not really explaining what you are trying to do we can't help
> you better on the best strategy to achieve what you want.
>
> Alexander
>
> On Saturday, March 15, 2014 06:00:21 PM Aditya Mamidwar wrote:
> > Hey thanks on the previous issue.
> > Also is there a way i can access WebAdmin.Html to add custom buttons and
> > make few tweaks for personal use? I just cant find that file after using
> > git.
> >
> > Aditya Mamidwar
> >
> > -----Original Message-----
> > From: "Einav Cohen" <ecohen at redhat.com>
> > Sent: 14-03-2014 01:21
> > To: "aditya mamidwar" <aditya.mamidwar at gmail.com>; "Vojtech Szocs"
> > <vszocs at redhat.com> Cc: "users at ovirt.org" <users at ovirt.org>;
> > "engine-devel at ovirt.org" <engine-devel at ovirt.org> Subject: Re: [Users]
> > adding scripts
> >
> > if you are trying to hook into UI-specific events, it sounds
> > like you will need to write an oVirt UI Plugin [1] in order to
> > do that. However, I believe that the oVirt UI Plugins
> > infrastructure doesn't support hooking to events such as "tab
> > x was selected" and/or "button b was clicked".
> > It does allow you to add new (custom) tabs/sub-tabs/buttons of
> > your own, and there is a chance that it allows you to hook
> > into events such as 'row x was selected in the grid'.
> >
> > @Vojtech will know better. Vojtech?
> >
> > if you are trying to hook into engine events (e.g. you want to
> > run a script every time a VM is started in oVirt, no matter if
> > the user started it by clicking the 'run' button in the oVirt-
> > engine webadmin, or invoked a REST API request, or an SDK
> > command), then it will require some sort of an "engine-plugin"
> > infrastructure that we don't have at the moment AFAIK.
> > there is a chance that for some of the events you will be able
> > to utilize the VDSM hooks (at the Host level) [2].
> >
> > ----
> > Thanks,
> > Einav
> >
> > [1] http://www.ovirt.org/Features/UIPlugins
> >
> > [2] http://www.ovirt.org/VDSM-Hooks
> >
> >
> > ----- Original Message -----
> >
> > > From: "aditya mamidwar" <aditya.mamidwar at gmail.com>
> > > To: users at ovirt.org, engine-devel at ovirt.org
> > > Sent: Thursday, March 13, 2014 11:23:35 AM
> > > Subject: [Users] adding scripts
> > >
> > >
> > > I want to commit changes to the engine by adding some bash scripts.
> > > the scripts should be invoked once a button or tab is selected in the
> > > webadmin portal by the user.
> > >
> > > can someone guide on achieving this.
> > >
> > > --
> > > -Aditya Mamidwar
> > >
> > > _______________________________________________
> > > Users mailing list
> > > Users at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/users
>
>


-- 
-Aditya Mamidwar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140321/aeaa317f/attachment.html>

From gshereme at redhat.com  Fri Mar 21 12:33:04 2014
From: gshereme at redhat.com (Greg Sheremeta)
Date: Fri, 21 Mar 2014 08:33:04 -0400 (EDT)
Subject: [Engine-devel] [Users]   adding scripts
In-Reply-To: <CA+pz52__SFAV7_6pom_L4HNwpG6b-YUbOk92f04PF0HtOp9keg@mail.gmail.com>
References: <532447ee.a70e440a.3ce3.ffffd5f5@mx.google.com>
	<2582932.ip0y7S9grx@awels>
	<CA+pz52__SFAV7_6pom_L4HNwpG6b-YUbOk92f04PF0HtOp9keg@mail.gmail.com>
Message-ID: <2142144483.1855116.1395405184865.JavaMail.zimbra@redhat.com>


----- Original Message -----


From: "aditya mamidwar" <aditya.mamidwar at gmail.com> 
To: awels at redhat.com, engine-devel at ovirt.org, users at ovirt.org 
Sent: Friday, March 21, 2014 6:14:01 AM 
Subject: Re: [Users] [Engine-devel] adding scripts 


Hey, 
my team is working on adding AoE protocol support to ovirt. 

am thus facing following difficulties: 
1 : i wrote the required code using in bash scripting, which i wish to invoke after a click of button in the ovirt-portal. (which does not seem to be possible). can you help on that? which programming language should i use, and how that file should be invoked. 



This needs to be done in Java. You'll need to read up on oVirt's UI Plugin infrastructure, which Einav and others mentioned below. No, you cannot write a bash script and have a button click in oVirt invoke that. 

<blockquote>


2. for ISOs to be available, i need to enable hosts configured in clusters and storage domains of ATA type. (currently NFS, iSCSI and FC are done). which files should i focus on changing for above functionality. 

</blockquote>

I've never heard of ATA network storage. Are you referring to ATA hardware technology, i.e. SATA? 

At any rate, adding a custom storage domain technology will difficult. Hopefully someone else on list can direct you. 

<blockquote>


3. How do i change the custom layout of the engine? (like adding a few extra buttons.) please specify the files responsible. 

</blockquote>

Again, you'll need to read up on oVirt's UI Plugin infrastructure. http://www.ovirt.org/Features/UIPlugins 

<blockquote>


4. the above questions stress that am facing difficulty in identifying files responsible for a particular module. is there a better way to do that instead of digging up the entire source code. ( a documentation if available.) 

</blockquote>

Other than what we've already mentioned (JavaDoc, architecture docs on the wiki), no. 

Greg 


<blockquote>





On Mon, Mar 17, 2014 at 5:52 PM, Alexander Wels < awels at redhat.com > wrote: 

<blockquote>
Aditya, 

That is because that file doesn't exist. We map that name to a servlet in 
web.xml. If you want to modify the GWT host page take a look at 
GwtDynamicHostPageServlet.java and its sub classes (for user portal and 
webadmin). As well as GwtHostPage.jsp. You will find there is almost nothing in 
that page as all the HTML is being generated at runtime using GWT. 

Since you are not really explaining what you are trying to do we can't help 
you better on the best strategy to achieve what you want. 

Alexander 

On Saturday, March 15, 2014 06:00:21 PM Aditya Mamidwar wrote: 
> Hey thanks on the previous issue. 
> Also is there a way i can access WebAdmin.Html to add custom buttons and 
> make few tweaks for personal use? I just cant find that file after using 
> git. 
> 
> Aditya Mamidwar 
> 
> -----Original Message----- 
> From: "Einav Cohen" < ecohen at redhat.com > 
> Sent: 14-03-2014 01:21 
> To: "aditya mamidwar" < aditya.mamidwar at gmail.com >; "Vojtech Szocs" 
> < vszocs at redhat.com > Cc: " users at ovirt.org " < users at ovirt.org >; 
> " engine-devel at ovirt.org " < engine-devel at ovirt.org > Subject: Re: [Users] 
> adding scripts 
> 
> if you are trying to hook into UI-specific events, it sounds 
> like you will need to write an oVirt UI Plugin [1] in order to 
> do that. However, I believe that the oVirt UI Plugins 
> infrastructure doesn't support hooking to events such as "tab 
> x was selected" and/or "button b was clicked". 
> It does allow you to add new (custom) tabs/sub-tabs/buttons of 
> your own, and there is a chance that it allows you to hook 
> into events such as 'row x was selected in the grid'. 
> 
> @Vojtech will know better. Vojtech? 
> 
> if you are trying to hook into engine events (e.g. you want to 
> run a script every time a VM is started in oVirt, no matter if 
> the user started it by clicking the 'run' button in the oVirt- 
> engine webadmin, or invoked a REST API request, or an SDK 
> command), then it will require some sort of an "engine-plugin" 
> infrastructure that we don't have at the moment AFAIK. 
> there is a chance that for some of the events you will be able 
> to utilize the VDSM hooks (at the Host level) [2]. 
> 
> ---- 
> Thanks, 
> Einav 
> 
> [1] http://www.ovirt.org/Features/UIPlugins 
> 
> [2] http://www.ovirt.org/VDSM-Hooks 
> 
> 
> ----- Original Message ----- 
> 
> > From: "aditya mamidwar" < aditya.mamidwar at gmail.com > 
> > To: users at ovirt.org , engine-devel at ovirt.org 
> > Sent: Thursday, March 13, 2014 11:23:35 AM 
> > Subject: [Users] adding scripts 
> > 
> > 
> > I want to commit changes to the engine by adding some bash scripts. 
> > the scripts should be invoked once a button or tab is selected in the 
> > webadmin portal by the user. 
> > 
> > can someone guide on achieving this. 
> > 
> > -- 
> > -Aditya Mamidwar 
> > 
> > _______________________________________________ 
> > Users mailing list 
> > Users at ovirt.org 
> > http://lists.ovirt.org/mailman/listinfo/users 


</blockquote>




-- 
-Aditya Mamidwar 

_______________________________________________ 
Users mailing list 
Users at ovirt.org 
http://lists.ovirt.org/mailman/listinfo/users 

</blockquote>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140321/84c1a1d7/attachment.html>

From awels at redhat.com  Fri Mar 21 12:49:22 2014
From: awels at redhat.com (Alexander Wels)
Date: Fri, 21 Mar 2014 08:49:22 -0400
Subject: [Engine-devel] [Users] adding scripts
In-Reply-To: <CA+pz52__SFAV7_6pom_L4HNwpG6b-YUbOk92f04PF0HtOp9keg@mail.gmail.com>
References: <532447ee.a70e440a.3ce3.ffffd5f5@mx.google.com>
	<2582932.ip0y7S9grx@awels>
	<CA+pz52__SFAV7_6pom_L4HNwpG6b-YUbOk92f04PF0HtOp9keg@mail.gmail.com>
Message-ID: <3252812.0fU9BrnEQL@awels>

On Friday, March 21, 2014 03:44:01 PM aditya mamidwar wrote:
> Hey,
> my team is working on adding AoE protocol support to ovirt.
> 
> am thus facing following difficulties:
> 1 : i wrote the required code using in bash scripting, which i wish to
> invoke after a click of button in the ovirt-portal. (which does not seem to
> be possible). can you help on that? which programming language should i
> use, and how that file should be invoked.

When you say ovirt portal I am assuming you mean the web admin as giving users 
access to low level stuff like that in the user portal would probably be a bad 
thing.

As said in a couple of other responses the best way to do that in webadmin is 
probably writing a UI plugin. A full explanation of what you can do with a UI 
plugin is available here: http://www.ovirt.org/Features/UIPlugins

In short a UI plugin is a mini application written in Javascript that hooks 
into the main web admin UI. The UI infrastructure makes certain element of the 
UI available to the plugin. One of the things it can do is to allow you to add 
buttons to the UI. When those buttons are clicked whatever javascript handler 
you assigned to it will execute.

This gives you a couple of options:
1. Write your own web application that can take commands from buttons inside 
the web admin interface. Since the ovirt engine runs on JBOSS I would suggest 
you write your own web application in Java that executes the appropriate bash 
commands based on which button is pressed using the UI plugin.
2. Write a minimal plugin that makes use of the REST API and add code to call 
your bash scripts from the REST api.

> 
> 2. for ISOs to be available, i need to enable hosts configured in clusters
> and storage domains of ATA type. (currently NFS, iSCSI and FC are done).
> which files should i focus on changing for above functionality.
> 

Honestly I don't know enough about the storage infrastructure to give you a 
good answer to that. Maybe someone else can fill this in.

> 3. How do i change the custom layout of the engine? (like adding a few
> extra buttons.) please specify the files responsible.
> 

Look at the UI plugins, the page linked above explains their usage in great 
detail as well as give a bunch of examples on how to achieve this.

> 4. the above questions stress that am facing difficulty in identifying
> files responsible for a particular module. is there a better way to do that
> instead of digging up the entire source code. ( a documentation if
> available.)
> 

This gives a nice overview of the architecture of oVirt: 
http://www.ovirt.org/Architecture

The source code associated with that is basically split out into two GIT 
repositories.
1. For the frontend and the engine, which is all java code.
2. For VDSM which is all python.

The user portal and web admin communicate with the engine using GWT-RPC and 
soon the REST api. Then the engine communicates with VDSM using XML-RPC.

The engine runs on one machine (either dedicated or as its own VM on one of 
your hosts). Then VDSM runs on the hosts. The hosts are the ones that 
communicate with the storage. So I am guessing your bash code will run on a 
host?

So in short, I think this is what you want?
1. Write UI plugin to add the buttons/etc to the webadmin.
2. Write your own web app, or hook into the REST API and add the commands to 
execute whatever it is you are doing.
3. (Maybe?) Modify VDSM to accept the commands from the REST API or your web 
application, and execute your scripts using VDSM based on the commands.

Alexander

> On Mon, Mar 17, 2014 at 5:52 PM, Alexander Wels <awels at redhat.com> wrote:
> > Aditya,
> > 
> > That is because that file doesn't exist. We map that name to a servlet in
> > web.xml. If you want to modify the GWT host page take a look at
> > GwtDynamicHostPageServlet.java and its sub classes (for user portal and
> > webadmin). As well as GwtHostPage.jsp. You will find there is almost
> > nothing in
> > that page as all the HTML is being generated at runtime using GWT.
> > 
> > Since you are not really explaining what you are trying to do we can't
> > help
> > you better on the best strategy to achieve what you want.
> > 
> > Alexander
> > 
> > On Saturday, March 15, 2014 06:00:21 PM Aditya Mamidwar wrote:
> > > Hey thanks on the previous issue.
> > > Also is there a way i can access WebAdmin.Html to add custom buttons and
> > > make few tweaks for personal use? I just cant find that file after using
> > > git.
> > > 
> > > Aditya Mamidwar
> > > 
> > > -----Original Message-----
> > > From: "Einav Cohen" <ecohen at redhat.com>
> > > Sent: 14-03-2014 01:21
> > > To: "aditya mamidwar" <aditya.mamidwar at gmail.com>; "Vojtech Szocs"
> > > <vszocs at redhat.com> Cc: "users at ovirt.org" <users at ovirt.org>;
> > > "engine-devel at ovirt.org" <engine-devel at ovirt.org> Subject: Re: [Users]
> > > adding scripts
> > > 
> > > if you are trying to hook into UI-specific events, it sounds
> > > like you will need to write an oVirt UI Plugin [1] in order to
> > > do that. However, I believe that the oVirt UI Plugins
> > > infrastructure doesn't support hooking to events such as "tab
> > > x was selected" and/or "button b was clicked".
> > > It does allow you to add new (custom) tabs/sub-tabs/buttons of
> > > your own, and there is a chance that it allows you to hook
> > > into events such as 'row x was selected in the grid'.
> > > 
> > > @Vojtech will know better. Vojtech?
> > > 
> > > if you are trying to hook into engine events (e.g. you want to
> > > run a script every time a VM is started in oVirt, no matter if
> > > the user started it by clicking the 'run' button in the oVirt-
> > > engine webadmin, or invoked a REST API request, or an SDK
> > > command), then it will require some sort of an "engine-plugin"
> > > infrastructure that we don't have at the moment AFAIK.
> > > there is a chance that for some of the events you will be able
> > > to utilize the VDSM hooks (at the Host level) [2].
> > > 
> > > ----
> > > Thanks,
> > > Einav
> > > 
> > > [1] http://www.ovirt.org/Features/UIPlugins
> > > 
> > > [2] http://www.ovirt.org/VDSM-Hooks
> > > 
> > > 
> > > ----- Original Message -----
> > > 
> > > > From: "aditya mamidwar" <aditya.mamidwar at gmail.com>
> > > > To: users at ovirt.org, engine-devel at ovirt.org
> > > > Sent: Thursday, March 13, 2014 11:23:35 AM
> > > > Subject: [Users] adding scripts
> > > > 
> > > > 
> > > > I want to commit changes to the engine by adding some bash scripts.
> > > > the scripts should be invoked once a button or tab is selected in the
> > > > webadmin portal by the user.
> > > > 
> > > > can someone guide on achieving this.
> > > > 
> > > > --
> > > > -Aditya Mamidwar
> > > > 
> > > > _______________________________________________
> > > > Users mailing list
> > > > Users at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/users



From vszocs at redhat.com  Fri Mar 21 13:57:00 2014
From: vszocs at redhat.com (Vojtech Szocs)
Date: Fri, 21 Mar 2014 09:57:00 -0400 (EDT)
Subject: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
In-Reply-To: <1286350009.1771204.1395361974830.JavaMail.zimbra@redhat.com>
References: <127908115.1936906.1392393046744.JavaMail.zimbra@redhat.com>
	<5304CD77.1010407@redhat.com>
	<1944239316.3104044.1392825066732.JavaMail.zimbra@redhat.com>
	<3018426.h1T2jmR5QI@awels>
	<1313494537.5573093.1393511200703.JavaMail.zimbra@redhat.com>
	<1286350009.1771204.1395361974830.JavaMail.zimbra@redhat.com>
Message-ID: <2013128246.3531438.1395410220717.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Greg Sheremeta" <gshereme at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Friday, March 21, 2014 1:32:54 AM
> Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> 
> I'm afraid I need to resurrect this. I'm again seeing unbearable slowness
> with GWT Dev Mode in webadmin on master. The first load is tolerable, and
> one or two refreshes are ok, but after that it bogs down and is unusable.

Some suggestions (that have been already mentioned in this thread a while ago):

1, use gwt-maven-plugin 2.5.1 instead of 2.4.0
   in root pom.xml change
   <gwt-maven-plugin.workingRefresh.version>2.4.0</gwt-maven-plugin.workingRefresh.version>
   to
   <gwt-maven-plugin.workingRefresh.version>${gwt.version}</gwt-maven-plugin.workingRefresh.version>

2, disable GWT persistent unit cache
   in frontend/webadmin/modules/pom.xml find <artifactId>gwt-maven-plugin</artifactId>
   add <persistentunitcache>false</persistentunitcache> to <configuration>
   -or-
   make gwt-debug [usual options] DEV_EXTRA_BUILD_FLAGS="-Dgwt.persistentunitcache=false"

3, try out GWT Super Dev Mode

Vojtech

> 
> Anyone else?
> 
> Greg
> 
> 
> ----- Original Message -----
> > From: "Greg Sheremeta" <gshereme at redhat.com>
> > To: awels at redhat.com
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Thursday, February 27, 2014 9:26:40 AM
> > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> > 
> > Thanks, and great work figuring it out :)
> > 
> > Greg
> > 
> > ----- Original Message -----
> > > From: "Alexander Wels" <awels at redhat.com>
> > > To: "Greg Sheremeta" <gshereme at redhat.com>
> > > Cc: "Lior Vernia" <lvernia at redhat.com>, "Martin Betak"
> > > <mbetak at redhat.com>,
> > > "engine-devel" <engine-devel at ovirt.org>,
> > > "Vojtech Szocs" <vszocs at redhat.com>
> > > Sent: Thursday, February 27, 2014 8:32:00 AM
> > > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> > > 
> > > Master is back to its normal zippy self in GWT dev mode as of 8:25 EST
> > > Feb
> > > 27th 2014. With relative values for zippy. If you are annoyed by the slow
> > > GTW
> > > dev mode be sure to fetch and rebase.
> > > 
> > > On Wednesday, February 19, 2014 10:51:06 AM Greg Sheremeta wrote:
> > > > I agree with Lior. Alexander (cc'd) has a patch that will hopefully
> > > > address
> > > > it.
> > > > 
> > > > Greg
> > > > 
> > > > ----- Original Message -----
> > > > 
> > > > > From: "Lior Vernia" <lvernia at redhat.com>
> > > > > To: "Martin Betak" <mbetak at redhat.com>
> > > > > Cc: "Greg Sheremeta" <gshereme at redhat.com>, "engine-devel"
> > > > > <engine-devel at ovirt.org>, "Vojtech Szocs" <vszocs at redhat.com>
> > > > > Sent: Wednesday, February 19, 2014 10:27:51 AM
> > > > > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> > > > > 
> > > > > Hi guys,
> > > > > 
> > > > > On 17/02/14 13:15, Martin Betak wrote:
> > > > > > Yes, this has been my developer experience since I joined the
> > > > > > project.
> > > > > 
> > > > > To my eyes, it hasn't always been this slow. Something aggravated the
> > > > > situation sometime in the past 3 weeks. I'm not knowledgeable enough
> > > > > to
> > > > > say what went wrong, but this is not simply a gradual degradation of
> > > > > more code being compiled, etc.
> > > > > 
> > > > > Lior.
> > > > > 
> > > > > > The 5-6 minute page-loads are a standard but the GWT Dev Mode gets
> > > > > > progressively
> > > > > > slower after each "refresh" that involves frontend recompilation.
> > > > > > Also
> > > > > > the
> > > > > > memory
> > > > > > consumption increases and after 5-th "refresh" or so I have to kill
> > > > > > it
> > > > > > and
> > > > > > recompile the whole engine.
> > > > > > 
> > > > > > Any improvement to current status would be much appreciated.
> > > > > > 
> > > > > > Martin
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > 
> > > > > >> From: "Greg Sheremeta" <gshereme at redhat.com>
> > > > > >> To: "engine-devel" <engine-devel at ovirt.org>
> > > > > >> Sent: Friday, February 14, 2014 4:50:46 PM
> > > > > >> Subject: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> > > > > >> 
> > > > > >> Has anyone else noticed that GWT Dev Mode is unbearably slow for
> > > > > >> WebAdmin?
> > > > > >> On
> > > > > >> my machine, it's to the point where I might as well rebuild the
> > > > > >> entire
> > > > > >> application for every change and not bother with Dev Mode. Pages
> > > > > >> take
> > > > > >> 4
> > > > > >> or
> > > > > >> 5
> > > > > >> minutes to render. Sometimes after 5 minutes, I just give up,
> > > > > >> close
> > > > > >> everything, and rebuild the app.
> > > > > >> 
> > > > > >> For now, I want to see if others have this issue. If we confirm
> > > > > >> that
> > > > > >> it's
> > > > > >> widespread, we can discuss ways to mitigate.
> > > > > >> 
> > > > > >> Greg Sheremeta
> > > > > >> Red Hat, Inc.
> > > > > >> Sr. Software Engineer, RHEV
> > > > > >> Cell: 919-807-1086
> > > > > >> gshereme at redhat.com
> > > > > >> _______________________________________________
> > > > > >> Engine-devel mailing list
> > > > > >> Engine-devel at ovirt.org
> > > > > >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > 
> > > > > > _______________________________________________
> > > > > > Engine-devel mailing list
> > > > > > Engine-devel at ovirt.org
> > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From gshereme at redhat.com  Fri Mar 21 14:04:17 2014
From: gshereme at redhat.com (Greg Sheremeta)
Date: Fri, 21 Mar 2014 10:04:17 -0400 (EDT)
Subject: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
In-Reply-To: <2013128246.3531438.1395410220717.JavaMail.zimbra@redhat.com>
References: <127908115.1936906.1392393046744.JavaMail.zimbra@redhat.com>
	<5304CD77.1010407@redhat.com>
	<1944239316.3104044.1392825066732.JavaMail.zimbra@redhat.com>
	<3018426.h1T2jmR5QI@awels>
	<1313494537.5573093.1393511200703.JavaMail.zimbra@redhat.com>
	<1286350009.1771204.1395361974830.JavaMail.zimbra@redhat.com>
	<2013128246.3531438.1395410220717.JavaMail.zimbra@redhat.com>
Message-ID: <1298926513.1883174.1395410657143.JavaMail.zimbra@redhat.com>


----- Original Message -----
> From: "Vojtech Szocs" <vszocs at redhat.com>
> To: "Greg Sheremeta" <gshereme at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Friday, March 21, 2014 9:57:00 AM
> Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> 
> 
> 
> ----- Original Message -----
> > From: "Greg Sheremeta" <gshereme at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Friday, March 21, 2014 1:32:54 AM
> > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> > 
> > I'm afraid I need to resurrect this. I'm again seeing unbearable slowness
> > with GWT Dev Mode in webadmin on master. The first load is tolerable, and
> > one or two refreshes are ok, but after that it bogs down and is unusable.
> 
> Some suggestions (that have been already mentioned in this thread a while
> ago):
> 
> 1, use gwt-maven-plugin 2.5.1 instead of 2.4.0
>    in root pom.xml change
>    <gwt-maven-plugin.workingRefresh.version>2.4.0</gwt-maven-plugin.workingRefresh.version>
>    to
>    <gwt-maven-plugin.workingRefresh.version>${gwt.version}</gwt-maven-plugin.workingRefresh.version>
> 
> 2, disable GWT persistent unit cache
>    in frontend/webadmin/modules/pom.xml find
>    <artifactId>gwt-maven-plugin</artifactId>
>    add <persistentunitcache>false</persistentunitcache> to <configuration>
>    -or-
>    make gwt-debug [usual options]
>    DEV_EXTRA_BUILD_FLAGS="-Dgwt.persistentunitcache=false"
> 
> 3, try out GWT Super Dev Mode
> 
> Vojtech

Vojtech, you're not experiencing this slowness?


> 
> > 
> > Anyone else?
> > 
> > Greg
> > 
> > 
> > ----- Original Message -----
> > > From: "Greg Sheremeta" <gshereme at redhat.com>
> > > To: awels at redhat.com
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Thursday, February 27, 2014 9:26:40 AM
> > > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> > > 
> > > Thanks, and great work figuring it out :)
> > > 
> > > Greg
> > > 
> > > ----- Original Message -----
> > > > From: "Alexander Wels" <awels at redhat.com>
> > > > To: "Greg Sheremeta" <gshereme at redhat.com>
> > > > Cc: "Lior Vernia" <lvernia at redhat.com>, "Martin Betak"
> > > > <mbetak at redhat.com>,
> > > > "engine-devel" <engine-devel at ovirt.org>,
> > > > "Vojtech Szocs" <vszocs at redhat.com>
> > > > Sent: Thursday, February 27, 2014 8:32:00 AM
> > > > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> > > > 
> > > > Master is back to its normal zippy self in GWT dev mode as of 8:25 EST
> > > > Feb
> > > > 27th 2014. With relative values for zippy. If you are annoyed by the
> > > > slow
> > > > GTW
> > > > dev mode be sure to fetch and rebase.
> > > > 
> > > > On Wednesday, February 19, 2014 10:51:06 AM Greg Sheremeta wrote:
> > > > > I agree with Lior. Alexander (cc'd) has a patch that will hopefully
> > > > > address
> > > > > it.
> > > > > 
> > > > > Greg
> > > > > 
> > > > > ----- Original Message -----
> > > > > 
> > > > > > From: "Lior Vernia" <lvernia at redhat.com>
> > > > > > To: "Martin Betak" <mbetak at redhat.com>
> > > > > > Cc: "Greg Sheremeta" <gshereme at redhat.com>, "engine-devel"
> > > > > > <engine-devel at ovirt.org>, "Vojtech Szocs" <vszocs at redhat.com>
> > > > > > Sent: Wednesday, February 19, 2014 10:27:51 AM
> > > > > > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in
> > > > > > WebAdmin
> > > > > > 
> > > > > > Hi guys,
> > > > > > 
> > > > > > On 17/02/14 13:15, Martin Betak wrote:
> > > > > > > Yes, this has been my developer experience since I joined the
> > > > > > > project.
> > > > > > 
> > > > > > To my eyes, it hasn't always been this slow. Something aggravated
> > > > > > the
> > > > > > situation sometime in the past 3 weeks. I'm not knowledgeable
> > > > > > enough
> > > > > > to
> > > > > > say what went wrong, but this is not simply a gradual degradation
> > > > > > of
> > > > > > more code being compiled, etc.
> > > > > > 
> > > > > > Lior.
> > > > > > 
> > > > > > > The 5-6 minute page-loads are a standard but the GWT Dev Mode
> > > > > > > gets
> > > > > > > progressively
> > > > > > > slower after each "refresh" that involves frontend recompilation.
> > > > > > > Also
> > > > > > > the
> > > > > > > memory
> > > > > > > consumption increases and after 5-th "refresh" or so I have to
> > > > > > > kill
> > > > > > > it
> > > > > > > and
> > > > > > > recompile the whole engine.
> > > > > > > 
> > > > > > > Any improvement to current status would be much appreciated.
> > > > > > > 
> > > > > > > Martin
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > 
> > > > > > >> From: "Greg Sheremeta" <gshereme at redhat.com>
> > > > > > >> To: "engine-devel" <engine-devel at ovirt.org>
> > > > > > >> Sent: Friday, February 14, 2014 4:50:46 PM
> > > > > > >> Subject: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> > > > > > >> 
> > > > > > >> Has anyone else noticed that GWT Dev Mode is unbearably slow for
> > > > > > >> WebAdmin?
> > > > > > >> On
> > > > > > >> my machine, it's to the point where I might as well rebuild the
> > > > > > >> entire
> > > > > > >> application for every change and not bother with Dev Mode. Pages
> > > > > > >> take
> > > > > > >> 4
> > > > > > >> or
> > > > > > >> 5
> > > > > > >> minutes to render. Sometimes after 5 minutes, I just give up,
> > > > > > >> close
> > > > > > >> everything, and rebuild the app.
> > > > > > >> 
> > > > > > >> For now, I want to see if others have this issue. If we confirm
> > > > > > >> that
> > > > > > >> it's
> > > > > > >> widespread, we can discuss ways to mitigate.
> > > > > > >> 
> > > > > > >> Greg Sheremeta
> > > > > > >> Red Hat, Inc.
> > > > > > >> Sr. Software Engineer, RHEV
> > > > > > >> Cell: 919-807-1086
> > > > > > >> gshereme at redhat.com
> > > > > > >> _______________________________________________
> > > > > > >> Engine-devel mailing list
> > > > > > >> Engine-devel at ovirt.org
> > > > > > >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > Engine-devel mailing list
> > > > > > > Engine-devel at ovirt.org
> > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > 
> > > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From vszocs at redhat.com  Fri Mar 21 14:11:38 2014
From: vszocs at redhat.com (Vojtech Szocs)
Date: Fri, 21 Mar 2014 10:11:38 -0400 (EDT)
Subject: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
In-Reply-To: <1298926513.1883174.1395410657143.JavaMail.zimbra@redhat.com>
References: <127908115.1936906.1392393046744.JavaMail.zimbra@redhat.com>
	<5304CD77.1010407@redhat.com>
	<1944239316.3104044.1392825066732.JavaMail.zimbra@redhat.com>
	<3018426.h1T2jmR5QI@awels>
	<1313494537.5573093.1393511200703.JavaMail.zimbra@redhat.com>
	<1286350009.1771204.1395361974830.JavaMail.zimbra@redhat.com>
	<2013128246.3531438.1395410220717.JavaMail.zimbra@redhat.com>
	<1298926513.1883174.1395410657143.JavaMail.zimbra@redhat.com>
Message-ID: <833890240.3573908.1395411098229.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Greg Sheremeta" <gshereme at redhat.com>
> To: "Vojtech Szocs" <vszocs at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Friday, March 21, 2014 3:04:17 PM
> Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> 
> 
> ----- Original Message -----
> > From: "Vojtech Szocs" <vszocs at redhat.com>
> > To: "Greg Sheremeta" <gshereme at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Friday, March 21, 2014 9:57:00 AM
> > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Greg Sheremeta" <gshereme at redhat.com>
> > > To: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Friday, March 21, 2014 1:32:54 AM
> > > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> > > 
> > > I'm afraid I need to resurrect this. I'm again seeing unbearable slowness
> > > with GWT Dev Mode in webadmin on master. The first load is tolerable, and
> > > one or two refreshes are ok, but after that it bogs down and is unusable.
> > 
> > Some suggestions (that have been already mentioned in this thread a while
> > ago):
> > 
> > 1, use gwt-maven-plugin 2.5.1 instead of 2.4.0
> >    in root pom.xml change
> >    <gwt-maven-plugin.workingRefresh.version>2.4.0</gwt-maven-plugin.workingRefresh.version>
> >    to
> >    <gwt-maven-plugin.workingRefresh.version>${gwt.version}</gwt-maven-plugin.workingRefresh.version>
> > 
> > 2, disable GWT persistent unit cache
> >    in frontend/webadmin/modules/pom.xml find
> >    <artifactId>gwt-maven-plugin</artifactId>
> >    add <persistentunitcache>false</persistentunitcache> to <configuration>
> >    -or-
> >    make gwt-debug [usual options]
> >    DEV_EXTRA_BUILD_FLAGS="-Dgwt.persistentunitcache=false"
> > 
> > 3, try out GWT Super Dev Mode
> > 
> > Vojtech
> 
> Vojtech, you're not experiencing this slowness?

In fact, I am .. (and I have quite powerful laptop)

The slowness is a combination of two factors, lots of UI code (for GWT compiler to process) + on-the-fly recompilation of GWT Dev Mode. The "lots of code" factor should be improved when we transition to REST API and introduce other UI improvements (like alternative/dynamic i18n implementation, possibly UiCommon code refactoring, etc).

I've seen that people tend to use Super Dev Mode for basic debugging, falling back to Classic (slow) Dev Mode for deeper debugging. (So far, I didn't have time to try out Super Dev Mode myself.)

> 
> 
> > 
> > > 
> > > Anyone else?
> > > 
> > > Greg
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Greg Sheremeta" <gshereme at redhat.com>
> > > > To: awels at redhat.com
> > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Thursday, February 27, 2014 9:26:40 AM
> > > > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> > > > 
> > > > Thanks, and great work figuring it out :)
> > > > 
> > > > Greg
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Alexander Wels" <awels at redhat.com>
> > > > > To: "Greg Sheremeta" <gshereme at redhat.com>
> > > > > Cc: "Lior Vernia" <lvernia at redhat.com>, "Martin Betak"
> > > > > <mbetak at redhat.com>,
> > > > > "engine-devel" <engine-devel at ovirt.org>,
> > > > > "Vojtech Szocs" <vszocs at redhat.com>
> > > > > Sent: Thursday, February 27, 2014 8:32:00 AM
> > > > > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> > > > > 
> > > > > Master is back to its normal zippy self in GWT dev mode as of 8:25
> > > > > EST
> > > > > Feb
> > > > > 27th 2014. With relative values for zippy. If you are annoyed by the
> > > > > slow
> > > > > GTW
> > > > > dev mode be sure to fetch and rebase.
> > > > > 
> > > > > On Wednesday, February 19, 2014 10:51:06 AM Greg Sheremeta wrote:
> > > > > > I agree with Lior. Alexander (cc'd) has a patch that will hopefully
> > > > > > address
> > > > > > it.
> > > > > > 
> > > > > > Greg
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > 
> > > > > > > From: "Lior Vernia" <lvernia at redhat.com>
> > > > > > > To: "Martin Betak" <mbetak at redhat.com>
> > > > > > > Cc: "Greg Sheremeta" <gshereme at redhat.com>, "engine-devel"
> > > > > > > <engine-devel at ovirt.org>, "Vojtech Szocs" <vszocs at redhat.com>
> > > > > > > Sent: Wednesday, February 19, 2014 10:27:51 AM
> > > > > > > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in
> > > > > > > WebAdmin
> > > > > > > 
> > > > > > > Hi guys,
> > > > > > > 
> > > > > > > On 17/02/14 13:15, Martin Betak wrote:
> > > > > > > > Yes, this has been my developer experience since I joined the
> > > > > > > > project.
> > > > > > > 
> > > > > > > To my eyes, it hasn't always been this slow. Something aggravated
> > > > > > > the
> > > > > > > situation sometime in the past 3 weeks. I'm not knowledgeable
> > > > > > > enough
> > > > > > > to
> > > > > > > say what went wrong, but this is not simply a gradual degradation
> > > > > > > of
> > > > > > > more code being compiled, etc.
> > > > > > > 
> > > > > > > Lior.
> > > > > > > 
> > > > > > > > The 5-6 minute page-loads are a standard but the GWT Dev Mode
> > > > > > > > gets
> > > > > > > > progressively
> > > > > > > > slower after each "refresh" that involves frontend
> > > > > > > > recompilation.
> > > > > > > > Also
> > > > > > > > the
> > > > > > > > memory
> > > > > > > > consumption increases and after 5-th "refresh" or so I have to
> > > > > > > > kill
> > > > > > > > it
> > > > > > > > and
> > > > > > > > recompile the whole engine.
> > > > > > > > 
> > > > > > > > Any improvement to current status would be much appreciated.
> > > > > > > > 
> > > > > > > > Martin
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > 
> > > > > > > >> From: "Greg Sheremeta" <gshereme at redhat.com>
> > > > > > > >> To: "engine-devel" <engine-devel at ovirt.org>
> > > > > > > >> Sent: Friday, February 14, 2014 4:50:46 PM
> > > > > > > >> Subject: [Engine-devel] GWT Dev Mode unbearably slow in
> > > > > > > >> WebAdmin
> > > > > > > >> 
> > > > > > > >> Has anyone else noticed that GWT Dev Mode is unbearably slow
> > > > > > > >> for
> > > > > > > >> WebAdmin?
> > > > > > > >> On
> > > > > > > >> my machine, it's to the point where I might as well rebuild
> > > > > > > >> the
> > > > > > > >> entire
> > > > > > > >> application for every change and not bother with Dev Mode.
> > > > > > > >> Pages
> > > > > > > >> take
> > > > > > > >> 4
> > > > > > > >> or
> > > > > > > >> 5
> > > > > > > >> minutes to render. Sometimes after 5 minutes, I just give up,
> > > > > > > >> close
> > > > > > > >> everything, and rebuild the app.
> > > > > > > >> 
> > > > > > > >> For now, I want to see if others have this issue. If we
> > > > > > > >> confirm
> > > > > > > >> that
> > > > > > > >> it's
> > > > > > > >> widespread, we can discuss ways to mitigate.
> > > > > > > >> 
> > > > > > > >> Greg Sheremeta
> > > > > > > >> Red Hat, Inc.
> > > > > > > >> Sr. Software Engineer, RHEV
> > > > > > > >> Cell: 919-807-1086
> > > > > > > >> gshereme at redhat.com
> > > > > > > >> _______________________________________________
> > > > > > > >> Engine-devel mailing list
> > > > > > > >> Engine-devel at ovirt.org
> > > > > > > >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > 
> > > > > > > > _______________________________________________
> > > > > > > > Engine-devel mailing list
> > > > > > > > Engine-devel at ovirt.org
> > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > 
> > > > > 
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
> 


From gshereme at redhat.com  Fri Mar 21 14:15:03 2014
From: gshereme at redhat.com (Greg Sheremeta)
Date: Fri, 21 Mar 2014 10:15:03 -0400 (EDT)
Subject: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
In-Reply-To: <833890240.3573908.1395411098229.JavaMail.zimbra@redhat.com>
References: <127908115.1936906.1392393046744.JavaMail.zimbra@redhat.com>
	<1944239316.3104044.1392825066732.JavaMail.zimbra@redhat.com>
	<3018426.h1T2jmR5QI@awels>
	<1313494537.5573093.1393511200703.JavaMail.zimbra@redhat.com>
	<1286350009.1771204.1395361974830.JavaMail.zimbra@redhat.com>
	<2013128246.3531438.1395410220717.JavaMail.zimbra@redhat.com>
	<1298926513.1883174.1395410657143.JavaMail.zimbra@redhat.com>
	<833890240.3573908.1395411098229.JavaMail.zimbra@redhat.com>
Message-ID: <46124369.1899130.1395411303162.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Vojtech Szocs" <vszocs at redhat.com>
> To: "Greg Sheremeta" <gshereme at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Friday, March 21, 2014 10:11:38 AM
> Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> 
> 
> 
> ----- Original Message -----
> > From: "Greg Sheremeta" <gshereme at redhat.com>
> > To: "Vojtech Szocs" <vszocs at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Friday, March 21, 2014 3:04:17 PM
> > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> > 
> > 
> > ----- Original Message -----
> > > From: "Vojtech Szocs" <vszocs at redhat.com>
> > > To: "Greg Sheremeta" <gshereme at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Friday, March 21, 2014 9:57:00 AM
> > > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Greg Sheremeta" <gshereme at redhat.com>
> > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Friday, March 21, 2014 1:32:54 AM
> > > > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> > > > 
> > > > I'm afraid I need to resurrect this. I'm again seeing unbearable
> > > > slowness
> > > > with GWT Dev Mode in webadmin on master. The first load is tolerable,
> > > > and
> > > > one or two refreshes are ok, but after that it bogs down and is
> > > > unusable.
> > > 
> > > Some suggestions (that have been already mentioned in this thread a while
> > > ago):
> > > 
> > > 1, use gwt-maven-plugin 2.5.1 instead of 2.4.0
> > >    in root pom.xml change
> > >    <gwt-maven-plugin.workingRefresh.version>2.4.0</gwt-maven-plugin.workingRefresh.version>
> > >    to
> > >    <gwt-maven-plugin.workingRefresh.version>${gwt.version}</gwt-maven-plugin.workingRefresh.version>
> > > 
> > > 2, disable GWT persistent unit cache
> > >    in frontend/webadmin/modules/pom.xml find
> > >    <artifactId>gwt-maven-plugin</artifactId>
> > >    add <persistentunitcache>false</persistentunitcache> to
> > >    <configuration>
> > >    -or-
> > >    make gwt-debug [usual options]
> > >    DEV_EXTRA_BUILD_FLAGS="-Dgwt.persistentunitcache=false"
> > > 
> > > 3, try out GWT Super Dev Mode
> > > 
> > > Vojtech
> > 
> > Vojtech, you're not experiencing this slowness?
> 
> In fact, I am .. (and I have quite powerful laptop)
> 
> The slowness is a combination of two factors, lots of UI code (for GWT
> compiler to process) + on-the-fly recompilation of GWT Dev Mode. The "lots
> of code" factor should be improved when we transition to REST API and
> introduce other UI improvements (like alternative/dynamic i18n
> implementation, possibly UiCommon code refactoring, etc).
> 
> I've seen that people tend to use Super Dev Mode for basic debugging, falling
> back to Classic (slow) Dev Mode for deeper debugging. (So far, I didn't have
> time to try out Super Dev Mode myself.)

Alright. I'm trying out Super Dev Mode right now.


> 
> > 
> > 
> > > 
> > > > 
> > > > Anyone else?
> > > > 
> > > > Greg
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Greg Sheremeta" <gshereme at redhat.com>
> > > > > To: awels at redhat.com
> > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > Sent: Thursday, February 27, 2014 9:26:40 AM
> > > > > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> > > > > 
> > > > > Thanks, and great work figuring it out :)
> > > > > 
> > > > > Greg
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Alexander Wels" <awels at redhat.com>
> > > > > > To: "Greg Sheremeta" <gshereme at redhat.com>
> > > > > > Cc: "Lior Vernia" <lvernia at redhat.com>, "Martin Betak"
> > > > > > <mbetak at redhat.com>,
> > > > > > "engine-devel" <engine-devel at ovirt.org>,
> > > > > > "Vojtech Szocs" <vszocs at redhat.com>
> > > > > > Sent: Thursday, February 27, 2014 8:32:00 AM
> > > > > > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in
> > > > > > WebAdmin
> > > > > > 
> > > > > > Master is back to its normal zippy self in GWT dev mode as of 8:25
> > > > > > EST
> > > > > > Feb
> > > > > > 27th 2014. With relative values for zippy. If you are annoyed by
> > > > > > the
> > > > > > slow
> > > > > > GTW
> > > > > > dev mode be sure to fetch and rebase.
> > > > > > 
> > > > > > On Wednesday, February 19, 2014 10:51:06 AM Greg Sheremeta wrote:
> > > > > > > I agree with Lior. Alexander (cc'd) has a patch that will
> > > > > > > hopefully
> > > > > > > address
> > > > > > > it.
> > > > > > > 
> > > > > > > Greg
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > 
> > > > > > > > From: "Lior Vernia" <lvernia at redhat.com>
> > > > > > > > To: "Martin Betak" <mbetak at redhat.com>
> > > > > > > > Cc: "Greg Sheremeta" <gshereme at redhat.com>, "engine-devel"
> > > > > > > > <engine-devel at ovirt.org>, "Vojtech Szocs" <vszocs at redhat.com>
> > > > > > > > Sent: Wednesday, February 19, 2014 10:27:51 AM
> > > > > > > > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in
> > > > > > > > WebAdmin
> > > > > > > > 
> > > > > > > > Hi guys,
> > > > > > > > 
> > > > > > > > On 17/02/14 13:15, Martin Betak wrote:
> > > > > > > > > Yes, this has been my developer experience since I joined the
> > > > > > > > > project.
> > > > > > > > 
> > > > > > > > To my eyes, it hasn't always been this slow. Something
> > > > > > > > aggravated
> > > > > > > > the
> > > > > > > > situation sometime in the past 3 weeks. I'm not knowledgeable
> > > > > > > > enough
> > > > > > > > to
> > > > > > > > say what went wrong, but this is not simply a gradual
> > > > > > > > degradation
> > > > > > > > of
> > > > > > > > more code being compiled, etc.
> > > > > > > > 
> > > > > > > > Lior.
> > > > > > > > 
> > > > > > > > > The 5-6 minute page-loads are a standard but the GWT Dev Mode
> > > > > > > > > gets
> > > > > > > > > progressively
> > > > > > > > > slower after each "refresh" that involves frontend
> > > > > > > > > recompilation.
> > > > > > > > > Also
> > > > > > > > > the
> > > > > > > > > memory
> > > > > > > > > consumption increases and after 5-th "refresh" or so I have
> > > > > > > > > to
> > > > > > > > > kill
> > > > > > > > > it
> > > > > > > > > and
> > > > > > > > > recompile the whole engine.
> > > > > > > > > 
> > > > > > > > > Any improvement to current status would be much appreciated.
> > > > > > > > > 
> > > > > > > > > Martin
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > 
> > > > > > > > >> From: "Greg Sheremeta" <gshereme at redhat.com>
> > > > > > > > >> To: "engine-devel" <engine-devel at ovirt.org>
> > > > > > > > >> Sent: Friday, February 14, 2014 4:50:46 PM
> > > > > > > > >> Subject: [Engine-devel] GWT Dev Mode unbearably slow in
> > > > > > > > >> WebAdmin
> > > > > > > > >> 
> > > > > > > > >> Has anyone else noticed that GWT Dev Mode is unbearably slow
> > > > > > > > >> for
> > > > > > > > >> WebAdmin?
> > > > > > > > >> On
> > > > > > > > >> my machine, it's to the point where I might as well rebuild
> > > > > > > > >> the
> > > > > > > > >> entire
> > > > > > > > >> application for every change and not bother with Dev Mode.
> > > > > > > > >> Pages
> > > > > > > > >> take
> > > > > > > > >> 4
> > > > > > > > >> or
> > > > > > > > >> 5
> > > > > > > > >> minutes to render. Sometimes after 5 minutes, I just give
> > > > > > > > >> up,
> > > > > > > > >> close
> > > > > > > > >> everything, and rebuild the app.
> > > > > > > > >> 
> > > > > > > > >> For now, I want to see if others have this issue. If we
> > > > > > > > >> confirm
> > > > > > > > >> that
> > > > > > > > >> it's
> > > > > > > > >> widespread, we can discuss ways to mitigate.
> > > > > > > > >> 
> > > > > > > > >> Greg Sheremeta
> > > > > > > > >> Red Hat, Inc.
> > > > > > > > >> Sr. Software Engineer, RHEV
> > > > > > > > >> Cell: 919-807-1086
> > > > > > > > >> gshereme at redhat.com
> > > > > > > > >> _______________________________________________
> > > > > > > > >> Engine-devel mailing list
> > > > > > > > >> Engine-devel at ovirt.org
> > > > > > > > >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > 
> > > > > > > > > _______________________________________________
> > > > > > > > > Engine-devel mailing list
> > > > > > > > > Engine-devel at ovirt.org
> > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > 
> > > > > > 
> > > > > _______________________________________________
> > > > > Engine-devel mailing list
> > > > > Engine-devel at ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > 
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > 
> > > 
> > 
> 


From vszocs at redhat.com  Fri Mar 21 14:22:30 2014
From: vszocs at redhat.com (Vojtech Szocs)
Date: Fri, 21 Mar 2014 10:22:30 -0400 (EDT)
Subject: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
In-Reply-To: <46124369.1899130.1395411303162.JavaMail.zimbra@redhat.com>
References: <127908115.1936906.1392393046744.JavaMail.zimbra@redhat.com>
	<3018426.h1T2jmR5QI@awels>
	<1313494537.5573093.1393511200703.JavaMail.zimbra@redhat.com>
	<1286350009.1771204.1395361974830.JavaMail.zimbra@redhat.com>
	<2013128246.3531438.1395410220717.JavaMail.zimbra@redhat.com>
	<1298926513.1883174.1395410657143.JavaMail.zimbra@redhat.com>
	<833890240.3573908.1395411098229.JavaMail.zimbra@redhat.com>
	<46124369.1899130.1395411303162.JavaMail.zimbra@redhat.com>
Message-ID: <379892130.3578249.1395411750210.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Greg Sheremeta" <gshereme at redhat.com>
> To: "Vojtech Szocs" <vszocs at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Friday, March 21, 2014 3:15:03 PM
> Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> 
> 
> 
> ----- Original Message -----
> > From: "Vojtech Szocs" <vszocs at redhat.com>
> > To: "Greg Sheremeta" <gshereme at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Friday, March 21, 2014 10:11:38 AM
> > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Greg Sheremeta" <gshereme at redhat.com>
> > > To: "Vojtech Szocs" <vszocs at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Friday, March 21, 2014 3:04:17 PM
> > > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Vojtech Szocs" <vszocs at redhat.com>
> > > > To: "Greg Sheremeta" <gshereme at redhat.com>
> > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Friday, March 21, 2014 9:57:00 AM
> > > > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Greg Sheremeta" <gshereme at redhat.com>
> > > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > > Sent: Friday, March 21, 2014 1:32:54 AM
> > > > > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> > > > > 
> > > > > I'm afraid I need to resurrect this. I'm again seeing unbearable
> > > > > slowness
> > > > > with GWT Dev Mode in webadmin on master. The first load is tolerable,
> > > > > and
> > > > > one or two refreshes are ok, but after that it bogs down and is
> > > > > unusable.
> > > > 
> > > > Some suggestions (that have been already mentioned in this thread a
> > > > while
> > > > ago):
> > > > 
> > > > 1, use gwt-maven-plugin 2.5.1 instead of 2.4.0
> > > >    in root pom.xml change
> > > >    <gwt-maven-plugin.workingRefresh.version>2.4.0</gwt-maven-plugin.workingRefresh.version>
> > > >    to
> > > >    <gwt-maven-plugin.workingRefresh.version>${gwt.version}</gwt-maven-plugin.workingRefresh.version>
> > > > 
> > > > 2, disable GWT persistent unit cache
> > > >    in frontend/webadmin/modules/pom.xml find
> > > >    <artifactId>gwt-maven-plugin</artifactId>
> > > >    add <persistentunitcache>false</persistentunitcache> to
> > > >    <configuration>
> > > >    -or-
> > > >    make gwt-debug [usual options]
> > > >    DEV_EXTRA_BUILD_FLAGS="-Dgwt.persistentunitcache=false"
> > > > 
> > > > 3, try out GWT Super Dev Mode
> > > > 
> > > > Vojtech
> > > 
> > > Vojtech, you're not experiencing this slowness?
> > 
> > In fact, I am .. (and I have quite powerful laptop)
> > 
> > The slowness is a combination of two factors, lots of UI code (for GWT
> > compiler to process) + on-the-fly recompilation of GWT Dev Mode. The "lots
> > of code" factor should be improved when we transition to REST API and
> > introduce other UI improvements (like alternative/dynamic i18n
> > implementation, possibly UiCommon code refactoring, etc).
> > 
> > I've seen that people tend to use Super Dev Mode for basic debugging,
> > falling
> > back to Classic (slow) Dev Mode for deeper debugging. (So far, I didn't
> > have
> > time to try out Super Dev Mode myself.)
> 
> Alright. I'm trying out Super Dev Mode right now.

Cool, thanks!

> 
> 
> > 
> > > 
> > > 
> > > > 
> > > > > 
> > > > > Anyone else?
> > > > > 
> > > > > Greg
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Greg Sheremeta" <gshereme at redhat.com>
> > > > > > To: awels at redhat.com
> > > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > Sent: Thursday, February 27, 2014 9:26:40 AM
> > > > > > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in
> > > > > > WebAdmin
> > > > > > 
> > > > > > Thanks, and great work figuring it out :)
> > > > > > 
> > > > > > Greg
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Alexander Wels" <awels at redhat.com>
> > > > > > > To: "Greg Sheremeta" <gshereme at redhat.com>
> > > > > > > Cc: "Lior Vernia" <lvernia at redhat.com>, "Martin Betak"
> > > > > > > <mbetak at redhat.com>,
> > > > > > > "engine-devel" <engine-devel at ovirt.org>,
> > > > > > > "Vojtech Szocs" <vszocs at redhat.com>
> > > > > > > Sent: Thursday, February 27, 2014 8:32:00 AM
> > > > > > > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in
> > > > > > > WebAdmin
> > > > > > > 
> > > > > > > Master is back to its normal zippy self in GWT dev mode as of
> > > > > > > 8:25
> > > > > > > EST
> > > > > > > Feb
> > > > > > > 27th 2014. With relative values for zippy. If you are annoyed by
> > > > > > > the
> > > > > > > slow
> > > > > > > GTW
> > > > > > > dev mode be sure to fetch and rebase.
> > > > > > > 
> > > > > > > On Wednesday, February 19, 2014 10:51:06 AM Greg Sheremeta wrote:
> > > > > > > > I agree with Lior. Alexander (cc'd) has a patch that will
> > > > > > > > hopefully
> > > > > > > > address
> > > > > > > > it.
> > > > > > > > 
> > > > > > > > Greg
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > 
> > > > > > > > > From: "Lior Vernia" <lvernia at redhat.com>
> > > > > > > > > To: "Martin Betak" <mbetak at redhat.com>
> > > > > > > > > Cc: "Greg Sheremeta" <gshereme at redhat.com>, "engine-devel"
> > > > > > > > > <engine-devel at ovirt.org>, "Vojtech Szocs" <vszocs at redhat.com>
> > > > > > > > > Sent: Wednesday, February 19, 2014 10:27:51 AM
> > > > > > > > > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in
> > > > > > > > > WebAdmin
> > > > > > > > > 
> > > > > > > > > Hi guys,
> > > > > > > > > 
> > > > > > > > > On 17/02/14 13:15, Martin Betak wrote:
> > > > > > > > > > Yes, this has been my developer experience since I joined
> > > > > > > > > > the
> > > > > > > > > > project.
> > > > > > > > > 
> > > > > > > > > To my eyes, it hasn't always been this slow. Something
> > > > > > > > > aggravated
> > > > > > > > > the
> > > > > > > > > situation sometime in the past 3 weeks. I'm not knowledgeable
> > > > > > > > > enough
> > > > > > > > > to
> > > > > > > > > say what went wrong, but this is not simply a gradual
> > > > > > > > > degradation
> > > > > > > > > of
> > > > > > > > > more code being compiled, etc.
> > > > > > > > > 
> > > > > > > > > Lior.
> > > > > > > > > 
> > > > > > > > > > The 5-6 minute page-loads are a standard but the GWT Dev
> > > > > > > > > > Mode
> > > > > > > > > > gets
> > > > > > > > > > progressively
> > > > > > > > > > slower after each "refresh" that involves frontend
> > > > > > > > > > recompilation.
> > > > > > > > > > Also
> > > > > > > > > > the
> > > > > > > > > > memory
> > > > > > > > > > consumption increases and after 5-th "refresh" or so I have
> > > > > > > > > > to
> > > > > > > > > > kill
> > > > > > > > > > it
> > > > > > > > > > and
> > > > > > > > > > recompile the whole engine.
> > > > > > > > > > 
> > > > > > > > > > Any improvement to current status would be much
> > > > > > > > > > appreciated.
> > > > > > > > > > 
> > > > > > > > > > Martin
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > 
> > > > > > > > > >> From: "Greg Sheremeta" <gshereme at redhat.com>
> > > > > > > > > >> To: "engine-devel" <engine-devel at ovirt.org>
> > > > > > > > > >> Sent: Friday, February 14, 2014 4:50:46 PM
> > > > > > > > > >> Subject: [Engine-devel] GWT Dev Mode unbearably slow in
> > > > > > > > > >> WebAdmin
> > > > > > > > > >> 
> > > > > > > > > >> Has anyone else noticed that GWT Dev Mode is unbearably
> > > > > > > > > >> slow
> > > > > > > > > >> for
> > > > > > > > > >> WebAdmin?
> > > > > > > > > >> On
> > > > > > > > > >> my machine, it's to the point where I might as well
> > > > > > > > > >> rebuild
> > > > > > > > > >> the
> > > > > > > > > >> entire
> > > > > > > > > >> application for every change and not bother with Dev Mode.
> > > > > > > > > >> Pages
> > > > > > > > > >> take
> > > > > > > > > >> 4
> > > > > > > > > >> or
> > > > > > > > > >> 5
> > > > > > > > > >> minutes to render. Sometimes after 5 minutes, I just give
> > > > > > > > > >> up,
> > > > > > > > > >> close
> > > > > > > > > >> everything, and rebuild the app.
> > > > > > > > > >> 
> > > > > > > > > >> For now, I want to see if others have this issue. If we
> > > > > > > > > >> confirm
> > > > > > > > > >> that
> > > > > > > > > >> it's
> > > > > > > > > >> widespread, we can discuss ways to mitigate.
> > > > > > > > > >> 
> > > > > > > > > >> Greg Sheremeta
> > > > > > > > > >> Red Hat, Inc.
> > > > > > > > > >> Sr. Software Engineer, RHEV
> > > > > > > > > >> Cell: 919-807-1086
> > > > > > > > > >> gshereme at redhat.com
> > > > > > > > > >> _______________________________________________
> > > > > > > > > >> Engine-devel mailing list
> > > > > > > > > >> Engine-devel at ovirt.org
> > > > > > > > > >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > > 
> > > > > > > > > > _______________________________________________
> > > > > > > > > > Engine-devel mailing list
> > > > > > > > > > Engine-devel at ovirt.org
> > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > 
> > > > > > > 
> > > > > > _______________________________________________
> > > > > > Engine-devel mailing list
> > > > > > Engine-devel at ovirt.org
> > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > 
> > > > > _______________________________________________
> > > > > Engine-devel mailing list
> > > > > Engine-devel at ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > 
> > > > 
> > > 
> > 
> 


From vszocs at redhat.com  Fri Mar 21 15:43:35 2014
From: vszocs at redhat.com (Vojtech Szocs)
Date: Fri, 21 Mar 2014 11:43:35 -0400 (EDT)
Subject: [Engine-devel] [Users]   adding scripts
In-Reply-To: <3252812.0fU9BrnEQL@awels>
References: <532447ee.a70e440a.3ce3.ffffd5f5@mx.google.com>
	<2582932.ip0y7S9grx@awels>
	<CA+pz52__SFAV7_6pom_L4HNwpG6b-YUbOk92f04PF0HtOp9keg@mail.gmail.com>
	<3252812.0fU9BrnEQL@awels>
Message-ID: <791759069.3630935.1395416615666.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Alexander Wels" <awels at redhat.com>
> To: "aditya mamidwar" <aditya.mamidwar at gmail.com>
> Cc: engine-devel at ovirt.org, users at ovirt.org
> Sent: Friday, March 21, 2014 1:49:22 PM
> Subject: Re: [Users] [Engine-devel]  adding scripts
> 
> On Friday, March 21, 2014 03:44:01 PM aditya mamidwar wrote:
> > Hey,
> > my team is working on adding AoE protocol support to ovirt.
> > 
> > am thus facing following difficulties:
> > 1 : i wrote the required code using in bash scripting, which i wish to
> > invoke after a click of button in the ovirt-portal. (which does not seem to
> > be possible). can you help on that? which programming language should i
> > use, and how that file should be invoked.
> 
> When you say ovirt portal I am assuming you mean the web admin as giving
> users
> access to low level stuff like that in the user portal would probably be a
> bad
> thing.
> 
> As said in a couple of other responses the best way to do that in webadmin is
> probably writing a UI plugin. A full explanation of what you can do with a UI
> plugin is available here: http://www.ovirt.org/Features/UIPlugins
> 
> In short a UI plugin is a mini application written in Javascript that hooks
> into the main web admin UI. The UI infrastructure makes certain element of
> the
> UI available to the plugin. One of the things it can do is to allow you to
> add
> buttons to the UI. When those buttons are clicked whatever javascript handler
> you assigned to it will execute.
> 
> This gives you a couple of options:
> 1. Write your own web application that can take commands from buttons inside
> the web admin interface. Since the ovirt engine runs on JBOSS I would suggest
> you write your own web application in Java that executes the appropriate bash
> commands based on which button is pressed using the UI plugin.
> 2. Write a minimal plugin that makes use of the REST API and add code to call
> your bash scripts from the REST api.

Some more options (already mentioned on users list):

3. UI plugin requesting URL mapped to Apache CGI/Bash script (assuming WebAdmin is accessed through Apache which forwards request to Engine JBoss server)

4. run your own HTTP server, enable Cross-Origin Resource Sharing for requests coming from Engine origin, have UI plugin call this custom server via HTTP

It is entirely up to UI plugin developers if/how the plugin should communicate with servers.

> 
> > 
> > 2. for ISOs to be available, i need to enable hosts configured in clusters
> > and storage domains of ATA type. (currently NFS, iSCSI and FC are done).
> > which files should i focus on changing for above functionality.
> > 
> 
> Honestly I don't know enough about the storage infrastructure to give you a
> good answer to that. Maybe someone else can fill this in.
> 
> > 3. How do i change the custom layout of the engine? (like adding a few
> > extra buttons.) please specify the files responsible.
> > 
> 
> Look at the UI plugins, the page linked above explains their usage in great
> detail as well as give a bunch of examples on how to achieve this.
> 
> > 4. the above questions stress that am facing difficulty in identifying
> > files responsible for a particular module. is there a better way to do that
> > instead of digging up the entire source code. ( a documentation if
> > available.)
> > 
> 
> This gives a nice overview of the architecture of oVirt:
> http://www.ovirt.org/Architecture
> 
> The source code associated with that is basically split out into two GIT
> repositories.
> 1. For the frontend and the engine, which is all java code.
> 2. For VDSM which is all python.
> 
> The user portal and web admin communicate with the engine using GWT-RPC and
> soon the REST api. Then the engine communicates with VDSM using XML-RPC.

Right, REST API in UI is coming soon. We're planning to provide JavaScript SDK to work with Engine REST API, so UI plugins (or any other web applications) can integrate easily with oVirt Engine.

> 
> The engine runs on one machine (either dedicated or as its own VM on one of
> your hosts). Then VDSM runs on the hosts. The hosts are the ones that
> communicate with the storage. So I am guessing your bash code will run on a
> host?
> 
> So in short, I think this is what you want?
> 1. Write UI plugin to add the buttons/etc to the webadmin.
> 2. Write your own web app, or hook into the REST API and add the commands to
> execute whatever it is you are doing.
> 3. (Maybe?) Modify VDSM to accept the commands from the REST API or your web
> application, and execute your scripts using VDSM based on the commands.
> 
> Alexander
> 
> > On Mon, Mar 17, 2014 at 5:52 PM, Alexander Wels <awels at redhat.com> wrote:
> > > Aditya,
> > > 
> > > That is because that file doesn't exist. We map that name to a servlet in
> > > web.xml. If you want to modify the GWT host page take a look at
> > > GwtDynamicHostPageServlet.java and its sub classes (for user portal and
> > > webadmin). As well as GwtHostPage.jsp. You will find there is almost
> > > nothing in
> > > that page as all the HTML is being generated at runtime using GWT.
> > > 
> > > Since you are not really explaining what you are trying to do we can't
> > > help
> > > you better on the best strategy to achieve what you want.
> > > 
> > > Alexander
> > > 
> > > On Saturday, March 15, 2014 06:00:21 PM Aditya Mamidwar wrote:
> > > > Hey thanks on the previous issue.
> > > > Also is there a way i can access WebAdmin.Html to add custom buttons
> > > > and
> > > > make few tweaks for personal use? I just cant find that file after
> > > > using
> > > > git.
> > > > 
> > > > Aditya Mamidwar
> > > > 
> > > > -----Original Message-----
> > > > From: "Einav Cohen" <ecohen at redhat.com>
> > > > Sent: 14-03-2014 01:21
> > > > To: "aditya mamidwar" <aditya.mamidwar at gmail.com>; "Vojtech Szocs"
> > > > <vszocs at redhat.com> Cc: "users at ovirt.org" <users at ovirt.org>;
> > > > "engine-devel at ovirt.org" <engine-devel at ovirt.org> Subject: Re: [Users]
> > > > adding scripts
> > > > 
> > > > if you are trying to hook into UI-specific events, it sounds
> > > > like you will need to write an oVirt UI Plugin [1] in order to
> > > > do that. However, I believe that the oVirt UI Plugins
> > > > infrastructure doesn't support hooking to events such as "tab
> > > > x was selected" and/or "button b was clicked".
> > > > It does allow you to add new (custom) tabs/sub-tabs/buttons of
> > > > your own, and there is a chance that it allows you to hook
> > > > into events such as 'row x was selected in the grid'.
> > > > 
> > > > @Vojtech will know better. Vojtech?
> > > > 
> > > > if you are trying to hook into engine events (e.g. you want to
> > > > run a script every time a VM is started in oVirt, no matter if
> > > > the user started it by clicking the 'run' button in the oVirt-
> > > > engine webadmin, or invoked a REST API request, or an SDK
> > > > command), then it will require some sort of an "engine-plugin"
> > > > infrastructure that we don't have at the moment AFAIK.
> > > > there is a chance that for some of the events you will be able
> > > > to utilize the VDSM hooks (at the Host level) [2].
> > > > 
> > > > ----
> > > > Thanks,
> > > > Einav
> > > > 
> > > > [1] http://www.ovirt.org/Features/UIPlugins
> > > > 
> > > > [2] http://www.ovirt.org/VDSM-Hooks
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > 
> > > > > From: "aditya mamidwar" <aditya.mamidwar at gmail.com>
> > > > > To: users at ovirt.org, engine-devel at ovirt.org
> > > > > Sent: Thursday, March 13, 2014 11:23:35 AM
> > > > > Subject: [Users] adding scripts
> > > > > 
> > > > > 
> > > > > I want to commit changes to the engine by adding some bash scripts.
> > > > > the scripts should be invoked once a button or tab is selected in the
> > > > > webadmin portal by the user.
> > > > > 
> > > > > can someone guide on achieving this.
> > > > > 
> > > > > --
> > > > > -Aditya Mamidwar
> > > > > 
> > > > > _______________________________________________
> > > > > Users mailing list
> > > > > Users at ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/users
> 
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 


From vszocs at redhat.com  Fri Mar 21 18:27:05 2014
From: vszocs at redhat.com (Vojtech Szocs)
Date: Fri, 21 Mar 2014 14:27:05 -0400 (EDT)
Subject: [Engine-devel] Small suggestions for engine-log-collector
In-Reply-To: <5326A0E3.6040502@redhat.com>
References: <800022326.17517459.1394560631804.JavaMail.zimbra@redhat.com>
	<651261410.16892578.1394561588396.JavaMail.zimbra@redhat.com>
	<5321A442.1030307@redhat.com>
	<2111438961.19521314.1394816290721.JavaMail.zimbra@redhat.com>
	<5326A0E3.6040502@redhat.com>
Message-ID: <1471780897.3710690.1395426425693.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> To: "Vojtech Szocs" <vszocs at redhat.com>
> Cc: "Keith Robertson" <kroberts at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "Einav Cohen"
> <ecohen at redhat.com>
> Sent: Monday, March 17, 2014 8:14:43 AM
> Subject: Re: Small suggestions for engine-log-collector
> 
> Il 14/03/2014 17:58, Vojtech Szocs ha scritto:
> > 
> > 
> > ----- Original Message -----
> >> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> >> To: "Keith Robertson" <kroberts at redhat.com>, "Vojtech Szocs"
> >> <vszocs at redhat.com>
> >> Cc: "engine-devel" <engine-devel at ovirt.org>, "Einav Cohen"
> >> <ecohen at redhat.com>
> >> Sent: Thursday, March 13, 2014 1:27:46 PM
> >> Subject: Re: Small suggestions for engine-log-collector
> >>
> >> Il 11/03/2014 19:13, Keith Robertson ha scritto:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Vojtech Szocs" <vszocs at redhat.com> To: "engine-devel"
> >>>> <engine-devel at ovirt.org> Cc: "Keith Robertson" <kroberts at redhat.com>,
> >>>> "Einav Cohen"
> >>>> <ecohen at redhat.com> Sent: Tuesday, March 11, 2014 1:57:11 PM Subject:
> >>>> Small suggestions for engine-log-collector
> >>>>
> >>>> Hi guys,
> >>>>
> >>>> based on my testing during last week's oVirt 3.4 RC test day [1], I have
> >>>> a
> >>>> couple of small suggestions for engine-log-collector:
> >>>>
> >>>> 1, in /etc/ovirt-engine/logcollector.conf - I think there's typo:
> >>>>
> >>>> #key-file=/etc/pki/engine/keys/engine_id_rsa
> >>>>
> >>>> should be:
> >>>>
> >>>> #key-file=/etc/pki/ovirt-engine/keys/engine_id_rsa
> >>>>
> >>>
> >>> ACK
> >>
> >> merged.
> >>
> >>
> >>>
> >>>
> >>>> 2, to force password-based ssh auth, one has to do this:
> >>>>
> >>>
> >>> In the normal scenario, the the ovirt user's public key should be
> >>> installed
> >>> into each hypervisor.  Unless something has changed as a part of the
> >>> hypervisor registration process this should be something that we can
> >>> depend
> >>> upon.
> >>>
> >>> Clearly, there are edge cases where you need to collect logs from a
> >>> hypervisor that isn't properly registered with the RHEV-M.  Was this your
> >>> situation and how common do you think this scenario is?
> >>>
> >>>> engine-log-collector -k ""
> >>>>
> >>>
> >>> Yes, you are nulling out the default value which causes the LC to prompt
> >>> you for a PW.  Perhaps we should document this as opposed to supplying a
> >>> specific option?  Sandro?
> >>
> >> yes, maybe a better explanation in man page. Vojtech have you opened a bz
> >> about that?
> > 
> > No, first I wanted to hear your opinions :) I didn't open BZ for this yet.
> > 
> > I think a better explanation in --help text is sufficient. (small thing)
> > 
> > Should I open BZ for this?
> 
> yes please, I think both --help and man page should be aligned.

Hi, sorry for my late response.

Created BZ with low severity: https://bugzilla.redhat.com/show_bug.cgi?id=1079522

Thanks!

> 
> 
> > 
> >> Thanks for the report and for the patch you submitted!
> >>
> >>>
> >>>> because running this:
> >>>>
> >>>> engine-log-collector -k
> >>>>
> >>>> returns error message:
> >>>>
> >>>> error: -k option requires an argument
> >>>>
> >>>> however, help for -k option mentions *supplying* the argument:
> >>>>
> >>>> If a identity file is not supplied the program will prompt for a
> >>>> password.
> >>>>
> >>>> so either the help text should mention empty string, or -k option should
> >>>> allow missing argument (this was my initial understanding according to
> >>>> help text)
> >>>>
> >>>> Since these are just small things, I'm wondering if I should create RFE
> >>>> or
> >>>> if Keith/others can say if they are relevant.
> >>>>
> >>>> Thanks, Vojtech
> >>>>
> >>>> [1] http://etherpad.ovirt.org/p/3.4-testday-3
> >>>>
> >>
> >>
> >> --
> >> Sandro Bonazzola
> >> Better technology. Faster innovation. Powered by community collaboration.
> >> See how it works at redhat.com
> >>
> 
> 
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> 


From vszocs at redhat.com  Fri Mar 21 21:51:11 2014
From: vszocs at redhat.com (Vojtech Szocs)
Date: Fri, 21 Mar 2014 17:51:11 -0400 (EDT)
Subject: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
In-Reply-To: <379892130.3578249.1395411750210.JavaMail.zimbra@redhat.com>
References: <127908115.1936906.1392393046744.JavaMail.zimbra@redhat.com>
	<1313494537.5573093.1393511200703.JavaMail.zimbra@redhat.com>
	<1286350009.1771204.1395361974830.JavaMail.zimbra@redhat.com>
	<2013128246.3531438.1395410220717.JavaMail.zimbra@redhat.com>
	<1298926513.1883174.1395410657143.JavaMail.zimbra@redhat.com>
	<833890240.3573908.1395411098229.JavaMail.zimbra@redhat.com>
	<46124369.1899130.1395411303162.JavaMail.zimbra@redhat.com>
	<379892130.3578249.1395411750210.JavaMail.zimbra@redhat.com>
Message-ID: <138917117.3835215.1395438671247.JavaMail.zimbra@redhat.com>

Hello,

it took me some time but I've managed to get GWT Super Dev Mode (codeserver) running.

Based on instructions at [1] + [2], I wrote a patch (attached) that works like this:

a, build Engine with WebAdmin GUI for Firefox & Chrome
     engine_buildDir=/path/to/engine/build
     engine_userAgent='gecko1_8,safari'
     make install-dev PREFIX=$engine_buildDir DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.userAgent=$engine_userAgent" BUILD_GWT_WEBADMIN=1

b, setup and start Engine
     $engine_buildDir/bin/engine-setup
     $engine_buildDir/share/ovirt-engine/services/ovirt-engine/ovirt-engine.py start

c, start GWT Super Dev Mode (codeserver)
     make gwt-debug DEBUG_MODULE=webadmin DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.userAgent=$engine_userAgent" DEV_GWT_SUPER_DEV_MODE=1

Notice that I've added new Makefile option -> DEV_GWT_SUPER_DEV_MODE (default is 0 which means classic Dev Mode)

During its startup, Super Dev Mode compiles WebAdmin (with source maps enabled) and prints this:

  [INFO] The code server is ready.
  [INFO] Next, visit: http://vszocs.laptop:9876/

If your browser supports source maps, it means you'll be able to inspect Java source code right inside the browser.

To enable source maps in Firefox:
  http://www.codeproject.com/Articles/649271/How-to-Enable-Source-Maps-in-Firefox

To enable source maps in Chrome:
  https://developers.google.com/chrome-developer-tools/docs/javascript-debugging#source-maps

Now you can open http://127.0.0.1:9876/ and add "Dev Mode On" + "Dev Mode Off" bookmarklets to your browser's bookmark bar.

After this, open http://127.0.0.1:8080/ovirt-engine/webadmin/WebAdmin.html --> must be *without* "?gwt.codesvr=127.0.0.1:9997" stuff!

You now have compiled WebAdmin running in your browser, click "Dev Mode On" bookmark in your browser's bookmark bar.

However, after clicking "Dev Mode On", WebAdmin is greyed-out, with title saying "This module doesn't have Super Dev Mode enabled".

So apparently I'm missing some final piece of the puzzle here, maybe Greg can look into this :)

EDIT: I think the solution is to pass "-Dgwt.devModeEnabled=true" during GWT compilation in step a, mentioned above.

Because it's too late for me to think properly, I'll continue next week.

[1] http://stackoverflow.com/questions/11356714/getting-started-with-the-superdevmode
[2] http://stackoverflow.com/questions/22115078/can-not-reflect-changes-using-gwt-maven-plugin-superdev

Regards,
Vojtech


----- Original Message -----
> From: "Vojtech Szocs" <vszocs at redhat.com>
> To: "Greg Sheremeta" <gshereme at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Friday, March 21, 2014 3:22:30 PM
> Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> 
> 
> 
> ----- Original Message -----
> > From: "Greg Sheremeta" <gshereme at redhat.com>
> > To: "Vojtech Szocs" <vszocs at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Friday, March 21, 2014 3:15:03 PM
> > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Vojtech Szocs" <vszocs at redhat.com>
> > > To: "Greg Sheremeta" <gshereme at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Friday, March 21, 2014 10:11:38 AM
> > > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Greg Sheremeta" <gshereme at redhat.com>
> > > > To: "Vojtech Szocs" <vszocs at redhat.com>
> > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Friday, March 21, 2014 3:04:17 PM
> > > > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Vojtech Szocs" <vszocs at redhat.com>
> > > > > To: "Greg Sheremeta" <gshereme at redhat.com>
> > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > Sent: Friday, March 21, 2014 9:57:00 AM
> > > > > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Greg Sheremeta" <gshereme at redhat.com>
> > > > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > > > Sent: Friday, March 21, 2014 1:32:54 AM
> > > > > > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in
> > > > > > WebAdmin
> > > > > > 
> > > > > > I'm afraid I need to resurrect this. I'm again seeing unbearable
> > > > > > slowness
> > > > > > with GWT Dev Mode in webadmin on master. The first load is
> > > > > > tolerable,
> > > > > > and
> > > > > > one or two refreshes are ok, but after that it bogs down and is
> > > > > > unusable.
> > > > > 
> > > > > Some suggestions (that have been already mentioned in this thread a
> > > > > while
> > > > > ago):
> > > > > 
> > > > > 1, use gwt-maven-plugin 2.5.1 instead of 2.4.0
> > > > >    in root pom.xml change
> > > > >    <gwt-maven-plugin.workingRefresh.version>2.4.0</gwt-maven-plugin.workingRefresh.version>
> > > > >    to
> > > > >    <gwt-maven-plugin.workingRefresh.version>${gwt.version}</gwt-maven-plugin.workingRefresh.version>
> > > > > 
> > > > > 2, disable GWT persistent unit cache
> > > > >    in frontend/webadmin/modules/pom.xml find
> > > > >    <artifactId>gwt-maven-plugin</artifactId>
> > > > >    add <persistentunitcache>false</persistentunitcache> to
> > > > >    <configuration>
> > > > >    -or-
> > > > >    make gwt-debug [usual options]
> > > > >    DEV_EXTRA_BUILD_FLAGS="-Dgwt.persistentunitcache=false"
> > > > > 
> > > > > 3, try out GWT Super Dev Mode
> > > > > 
> > > > > Vojtech
> > > > 
> > > > Vojtech, you're not experiencing this slowness?
> > > 
> > > In fact, I am .. (and I have quite powerful laptop)
> > > 
> > > The slowness is a combination of two factors, lots of UI code (for GWT
> > > compiler to process) + on-the-fly recompilation of GWT Dev Mode. The
> > > "lots
> > > of code" factor should be improved when we transition to REST API and
> > > introduce other UI improvements (like alternative/dynamic i18n
> > > implementation, possibly UiCommon code refactoring, etc).
> > > 
> > > I've seen that people tend to use Super Dev Mode for basic debugging,
> > > falling
> > > back to Classic (slow) Dev Mode for deeper debugging. (So far, I didn't
> > > have
> > > time to try out Super Dev Mode myself.)
> > 
> > Alright. I'm trying out Super Dev Mode right now.
> 
> Cool, thanks!
> 
> > 
> > 
> > > 
> > > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > Anyone else?
> > > > > > 
> > > > > > Greg
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Greg Sheremeta" <gshereme at redhat.com>
> > > > > > > To: awels at redhat.com
> > > > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > > Sent: Thursday, February 27, 2014 9:26:40 AM
> > > > > > > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in
> > > > > > > WebAdmin
> > > > > > > 
> > > > > > > Thanks, and great work figuring it out :)
> > > > > > > 
> > > > > > > Greg
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Alexander Wels" <awels at redhat.com>
> > > > > > > > To: "Greg Sheremeta" <gshereme at redhat.com>
> > > > > > > > Cc: "Lior Vernia" <lvernia at redhat.com>, "Martin Betak"
> > > > > > > > <mbetak at redhat.com>,
> > > > > > > > "engine-devel" <engine-devel at ovirt.org>,
> > > > > > > > "Vojtech Szocs" <vszocs at redhat.com>
> > > > > > > > Sent: Thursday, February 27, 2014 8:32:00 AM
> > > > > > > > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in
> > > > > > > > WebAdmin
> > > > > > > > 
> > > > > > > > Master is back to its normal zippy self in GWT dev mode as of
> > > > > > > > 8:25
> > > > > > > > EST
> > > > > > > > Feb
> > > > > > > > 27th 2014. With relative values for zippy. If you are annoyed
> > > > > > > > by
> > > > > > > > the
> > > > > > > > slow
> > > > > > > > GTW
> > > > > > > > dev mode be sure to fetch and rebase.
> > > > > > > > 
> > > > > > > > On Wednesday, February 19, 2014 10:51:06 AM Greg Sheremeta
> > > > > > > > wrote:
> > > > > > > > > I agree with Lior. Alexander (cc'd) has a patch that will
> > > > > > > > > hopefully
> > > > > > > > > address
> > > > > > > > > it.
> > > > > > > > > 
> > > > > > > > > Greg
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > 
> > > > > > > > > > From: "Lior Vernia" <lvernia at redhat.com>
> > > > > > > > > > To: "Martin Betak" <mbetak at redhat.com>
> > > > > > > > > > Cc: "Greg Sheremeta" <gshereme at redhat.com>, "engine-devel"
> > > > > > > > > > <engine-devel at ovirt.org>, "Vojtech Szocs"
> > > > > > > > > > <vszocs at redhat.com>
> > > > > > > > > > Sent: Wednesday, February 19, 2014 10:27:51 AM
> > > > > > > > > > Subject: Re: [Engine-devel] GWT Dev Mode unbearably slow in
> > > > > > > > > > WebAdmin
> > > > > > > > > > 
> > > > > > > > > > Hi guys,
> > > > > > > > > > 
> > > > > > > > > > On 17/02/14 13:15, Martin Betak wrote:
> > > > > > > > > > > Yes, this has been my developer experience since I joined
> > > > > > > > > > > the
> > > > > > > > > > > project.
> > > > > > > > > > 
> > > > > > > > > > To my eyes, it hasn't always been this slow. Something
> > > > > > > > > > aggravated
> > > > > > > > > > the
> > > > > > > > > > situation sometime in the past 3 weeks. I'm not
> > > > > > > > > > knowledgeable
> > > > > > > > > > enough
> > > > > > > > > > to
> > > > > > > > > > say what went wrong, but this is not simply a gradual
> > > > > > > > > > degradation
> > > > > > > > > > of
> > > > > > > > > > more code being compiled, etc.
> > > > > > > > > > 
> > > > > > > > > > Lior.
> > > > > > > > > > 
> > > > > > > > > > > The 5-6 minute page-loads are a standard but the GWT Dev
> > > > > > > > > > > Mode
> > > > > > > > > > > gets
> > > > > > > > > > > progressively
> > > > > > > > > > > slower after each "refresh" that involves frontend
> > > > > > > > > > > recompilation.
> > > > > > > > > > > Also
> > > > > > > > > > > the
> > > > > > > > > > > memory
> > > > > > > > > > > consumption increases and after 5-th "refresh" or so I
> > > > > > > > > > > have
> > > > > > > > > > > to
> > > > > > > > > > > kill
> > > > > > > > > > > it
> > > > > > > > > > > and
> > > > > > > > > > > recompile the whole engine.
> > > > > > > > > > > 
> > > > > > > > > > > Any improvement to current status would be much
> > > > > > > > > > > appreciated.
> > > > > > > > > > > 
> > > > > > > > > > > Martin
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > 
> > > > > > > > > > >> From: "Greg Sheremeta" <gshereme at redhat.com>
> > > > > > > > > > >> To: "engine-devel" <engine-devel at ovirt.org>
> > > > > > > > > > >> Sent: Friday, February 14, 2014 4:50:46 PM
> > > > > > > > > > >> Subject: [Engine-devel] GWT Dev Mode unbearably slow in
> > > > > > > > > > >> WebAdmin
> > > > > > > > > > >> 
> > > > > > > > > > >> Has anyone else noticed that GWT Dev Mode is unbearably
> > > > > > > > > > >> slow
> > > > > > > > > > >> for
> > > > > > > > > > >> WebAdmin?
> > > > > > > > > > >> On
> > > > > > > > > > >> my machine, it's to the point where I might as well
> > > > > > > > > > >> rebuild
> > > > > > > > > > >> the
> > > > > > > > > > >> entire
> > > > > > > > > > >> application for every change and not bother with Dev
> > > > > > > > > > >> Mode.
> > > > > > > > > > >> Pages
> > > > > > > > > > >> take
> > > > > > > > > > >> 4
> > > > > > > > > > >> or
> > > > > > > > > > >> 5
> > > > > > > > > > >> minutes to render. Sometimes after 5 minutes, I just
> > > > > > > > > > >> give
> > > > > > > > > > >> up,
> > > > > > > > > > >> close
> > > > > > > > > > >> everything, and rebuild the app.
> > > > > > > > > > >> 
> > > > > > > > > > >> For now, I want to see if others have this issue. If we
> > > > > > > > > > >> confirm
> > > > > > > > > > >> that
> > > > > > > > > > >> it's
> > > > > > > > > > >> widespread, we can discuss ways to mitigate.
> > > > > > > > > > >> 
> > > > > > > > > > >> Greg Sheremeta
> > > > > > > > > > >> Red Hat, Inc.
> > > > > > > > > > >> Sr. Software Engineer, RHEV
> > > > > > > > > > >> Cell: 919-807-1086
> > > > > > > > > > >> gshereme at redhat.com
> > > > > > > > > > >> _______________________________________________
> > > > > > > > > > >> Engine-devel mailing list
> > > > > > > > > > >> Engine-devel at ovirt.org
> > > > > > > > > > >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > > > 
> > > > > > > > > > > _______________________________________________
> > > > > > > > > > > Engine-devel mailing list
> > > > > > > > > > > Engine-devel at ovirt.org
> > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > 
> > > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > Engine-devel mailing list
> > > > > > > Engine-devel at ovirt.org
> > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > 
> > > > > > _______________________________________________
> > > > > > Engine-devel mailing list
> > > > > > Engine-devel at ovirt.org
> > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Playing-with-GWT-Super-Dev-Mode.patch
Type: text/x-patch
Size: 4219 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140321/92547d7d/attachment.bin>

From iheim at redhat.com  Sat Mar 22 19:17:43 2014
From: iheim at redhat.com (Itamar Heim)
Date: Sat, 22 Mar 2014 21:17:43 +0200
Subject: [Engine-devel] [Users] adding scripts
In-Reply-To: <CA+pz52__SFAV7_6pom_L4HNwpG6b-YUbOk92f04PF0HtOp9keg@mail.gmail.com>
References: <532447ee.a70e440a.3ce3.ffffd5f5@mx.google.com>	<2582932.ip0y7S9grx@awels>
	<CA+pz52__SFAV7_6pom_L4HNwpG6b-YUbOk92f04PF0HtOp9keg@mail.gmail.com>
Message-ID: <532DE1D7.2090401@redhat.com>

On 03/21/2014 12:14 PM, aditya mamidwar wrote:
>
> Hey,
> my team is working on adding AoE protocol support to ovirt.

Hi Aditya,

I suggest you try to reach allon mureinik or federico simoncelli over 
irc to discuss what you are trying to do (I assume this is ATA over 
Ethernet).
This will first require code at the vdsm side (custom hook or full blown 
feature), only then can engine/gui code to match.



>
> am thus facing following difficulties:
> 1 : i wrote the required code using in bash scripting, which i wish to
> invoke after a click of button in the ovirt-portal. (which does not seem
> to be possible). can you help on that? which programming language should
> i use, and how that file should be invoked.
>
> 2. for ISOs to be available, i need to enable hosts configured in
> clusters and storage domains of ATA type. (currently NFS, iSCSI and FC
> are done). which files should i focus on changing for above functionality.
>
> 3. How do i change the custom layout of the engine? (like adding a few
> extra buttons.) please specify the files responsible.
>
> 4. the above questions stress that am facing difficulty in identifying
> files responsible for a particular module. is there a better way to do
> that instead of digging up the entire source code. ( a documentation if
> available.)
>
>
>
> On Mon, Mar 17, 2014 at 5:52 PM, Alexander Wels <awels at redhat.com
> <mailto:awels at redhat.com>> wrote:
>
>     Aditya,
>
>     That is because that file doesn't exist. We map that name to a
>     servlet in
>     web.xml. If you want to modify the GWT host page take a look at
>     GwtDynamicHostPageServlet.java and its sub classes (for user portal and
>     webadmin). As well as GwtHostPage.jsp. You will find there is almost
>     nothing in
>     that page as all the HTML is being generated at runtime using GWT.
>
>     Since you are not really explaining what you are trying to do we
>     can't help
>     you better on the best strategy to achieve what you want.
>
>     Alexander
>
>     On Saturday, March 15, 2014 06:00:21 PM Aditya Mamidwar wrote:
>      > Hey thanks on the previous issue.
>      > Also is there a way i can access WebAdmin.Html to add custom
>     buttons and
>      > make few tweaks for personal use? I just cant find that file
>     after using
>      > git.
>      >
>      > Aditya Mamidwar
>      >
>      > -----Original Message-----
>      > From: "Einav Cohen" <ecohen at redhat.com <mailto:ecohen at redhat.com>>
>      > Sent: 14-03-2014 01:21
>      > To: "aditya mamidwar" <aditya.mamidwar at gmail.com
>     <mailto:aditya.mamidwar at gmail.com>>; "Vojtech Szocs"
>      > <vszocs at redhat.com <mailto:vszocs at redhat.com>> Cc:
>     "users at ovirt.org <mailto:users at ovirt.org>" <users at ovirt.org
>     <mailto:users at ovirt.org>>;
>      > "engine-devel at ovirt.org <mailto:engine-devel at ovirt.org>"
>     <engine-devel at ovirt.org <mailto:engine-devel at ovirt.org>> Subject:
>     Re: [Users]
>      > adding scripts
>      >
>      > if you are trying to hook into UI-specific events, it sounds
>      > like you will need to write an oVirt UI Plugin [1] in order to
>      > do that. However, I believe that the oVirt UI Plugins
>      > infrastructure doesn't support hooking to events such as "tab
>      > x was selected" and/or "button b was clicked".
>      > It does allow you to add new (custom) tabs/sub-tabs/buttons of
>      > your own, and there is a chance that it allows you to hook
>      > into events such as 'row x was selected in the grid'.
>      >
>      > @Vojtech will know better. Vojtech?
>      >
>      > if you are trying to hook into engine events (e.g. you want to
>      > run a script every time a VM is started in oVirt, no matter if
>      > the user started it by clicking the 'run' button in the oVirt-
>      > engine webadmin, or invoked a REST API request, or an SDK
>      > command), then it will require some sort of an "engine-plugin"
>      > infrastructure that we don't have at the moment AFAIK.
>      > there is a chance that for some of the events you will be able
>      > to utilize the VDSM hooks (at the Host level) [2].
>      >
>      > ----
>      > Thanks,
>      > Einav
>      >
>      > [1] http://www.ovirt.org/Features/UIPlugins
>      >
>      > [2] http://www.ovirt.org/VDSM-Hooks
>      >
>      >
>      > ----- Original Message -----
>      >
>      > > From: "aditya mamidwar" <aditya.mamidwar at gmail.com
>     <mailto:aditya.mamidwar at gmail.com>>
>      > > To: users at ovirt.org <mailto:users at ovirt.org>,
>     engine-devel at ovirt.org <mailto:engine-devel at ovirt.org>
>      > > Sent: Thursday, March 13, 2014 11:23:35 AM
>      > > Subject: [Users] adding scripts
>      > >
>      > >
>      > > I want to commit changes to the engine by adding some bash scripts.
>      > > the scripts should be invoked once a button or tab is selected
>     in the
>      > > webadmin portal by the user.
>      > >
>      > > can someone guide on achieving this.
>      > >
>      > > --
>      > > -Aditya Mamidwar
>      > >
>      > > _______________________________________________
>      > > Users mailing list
>      > > Users at ovirt.org <mailto:Users at ovirt.org>
>      > > http://lists.ovirt.org/mailman/listinfo/users
>
>
>
>
> --
> -Aditya Mamidwar
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>



From emesika at redhat.com  Sun Mar 23 10:13:26 2014
From: emesika at redhat.com (Eli Mesika)
Date: Sun, 23 Mar 2014 06:13:26 -0400 (EDT)
Subject: [Engine-devel] Change in ovirt-engine[master]: core: enable to
 decrease DC compatibility...
In-Reply-To: <532BDD57.1090604@redhat.com>
References: <gerrit.1392716300399.I73284f641b7f80b380b39efbbd7b4566f55119b6@gerrit.ovirt.org>
	<53202FF4.6030004@redhat.com> <53203A24.4040200@redhat.com>
	<852680674.2850211.1394655652908.JavaMail.zimbra@redhat.com>
	<5320C4A9.5010209@redhat.com>
	<577568761.2861329.1394657047677.JavaMail.zimbra@redhat.com>
	<1789679933.641640.1395343205633.JavaMail.zimbra@redhat.com>
	<532BDD57.1090604@redhat.com>
Message-ID: <1810385690.186069.1395569606128.JavaMail.zimbra@redhat.com>


So, as far a I understand for resolving this bug the following is OK :

Block downgrading if there are Hosts or Networks (other than the default management network) or SD in the DC when downgrading.
 

----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Moti Asayag" <masayag at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Friday, March 21, 2014 8:33:59 AM
> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...
> 
> On 03/20/2014 09:20 PM, Moti Asayag wrote:
> > ----- Original Message -----
> >> From: "Moti Asayag" <masayag at redhat.com>
> >> To: "Livnat Peer" <lpeer at redhat.com>
> >> Cc: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
> >> Sent: Wednesday, March 12, 2014 10:44:07 PM
> >> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable
> >> to decrease DC compatibility...
> >>
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Livnat Peer" <lpeer at redhat.com>
> >>> To: "Moti Asayag" <masayag at redhat.com>
> >>> Cc: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
> >>> Sent: Wednesday, March 12, 2014 10:33:45 PM
> >>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable
> >>> to
> >>> decrease DC compatibility...
> >>>
> >>> On 03/12/2014 10:20 PM, Moti Asayag wrote:
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Livnat Peer" <lpeer at redhat.com>
> >>>>> To: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
> >>>>> Sent: Wednesday, March 12, 2014 12:42:44 PM
> >>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core:
> >>>>> enable
> >>>>> to	decrease DC compatibility...
> >>>>>
> >>>>> On 03/12/2014 11:59 AM, Itamar Heim wrote:
> >>>>>> On 03/12/2014 12:26 AM, emesika at redhat.com wrote:
> >>>>>>> Eli Mesika has submitted this change and it was merged.
> >>>>>>>
> >>>>>>> Change subject: core: enable to decrease DC compatibility...
> >>>>>>> ......................................................................
> >>>>>>>
> >>>>>>>
> >>>>>>> core: enable to decrease DC compatibility...
> >>>>>>>
> >>>>>>> enable to decrease DC compatibility version if DC has no clusters
> >>>>>>>
> >>>>>>> This patch enables to decrease the DC compatibility version if DC has
> >>>>>>> no
> >>>>>>> clusters.
> >>>>>>
> >>>>>> Eli - just saw this. I'm pretty sure it would be *bad* to downgrade a
> >>>>>> DC
> >>>>>> version if it has storage domains as well. not sure if this is checked
> >>>>>> already or not.
> >>>>>>
> >>>>>> may also be an issue with some logical network features.
> >>>>>>
> >>>>>
> >>>>> Most of the network features are driven from cluster level, we enable
> >>>>> using the features on all DC level (actually >=3.1) but actually enable
> >>>>> /disable the feature when attaching the network to a cluster.
> >>>>>
> >>>>> So from network perspective I think it should be fine to downgrade the
> >>>>> DC level even if there are networks in the DC (at least now this could
> >>>>> change in future versions).
> >>>>>
> >>>>
> >>>> Actually we block adding or updating networks if the feature is not
> >>>> supported
> >>>> on the network's DC level, for example: STP, Jumbo frames and non-vm
> >>>> network.
> >>>>
> >>>
> >>> From which DC level we support STP?  Jumbo frames? non-vm network? isn't
> >>> all of them supported in >=3.1 ?
> >>>
> >>
> >> Yes, mainly the problem with downgrading a DC to 3.0.
> >>
> > 
> > I had a discussion with Mike (cc'ed) about several possible solutions
> > for the networks compatibility within the data-center.
> > 
> > The first proposed solution would utilize the NetworkUpdateValidator,
> > a validation utility that verifies the compatibility of a network
> > to the data-center. This solution preserves the same behaviour as today,
> > that the features of network-level are dictated by the DC version. No
> > need to reimplement any logic in the decrease DC version flow, just use
> > an existing one to be applied for any network within the DC.
> > 
> > The second solution suggests we allow any settings of a network, and
> > compatibility enforcement is done on attaching the network to the clusters.
> > This modifies the existing behaviour and expands the capabilities of the
> > engine to support advanced network feature in advanced cluster within an
> > old data center (i.e. cluster 3.4 in 3.0 data-center could and probably
> > should use non-vm network, jumbo-frames and more).
> > This option requires more work in add/update network and attach network to
> > cluster
> > flows, both on the backend and UI. Specifically since by default a new
> > network
> > created in a DC is being attached to all of the clusters.
> > Perhaps the second option deserves to be treated as RFE and not as a bug
> > fix.
> > 
> > Thoughts ?
> > 
> 
> The second approach you suggested is equivalent to creating networks in
> cluster level vs. DC level, which is used today.
> 
> We should consider that for 4.0 and think on the pros and cons of doing so.
> 
> In general for this specific discussion I think a simple block on DC
> downgrade should be enough.
> 
> > Moti
> >  
> >>>> Therefore if the management network was configured with any of those
> >>>> feature,
> >>>> there is a need to either block the action or to 'initialize' the
> >>>> network
> >>>> to
> >>>> the default settings (as new network being added).
> >>>>
> >>>>> In general I believe the use case for this patch is mostly for empty
> >>>>> DCs
> >>>>> so for simplicity we should block it if there are networks or SD in the
> >>>>> DC when downgrading.
> >>>>>
> >>>>> Livnat
> >>>>>
> >>>>>
> >>>>>>>
> >>>>>>> Change-Id: I73284f641b7f80b380b39efbbd7b4566f55119b6
> >>>>>>> Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1057029
> >>>>>>> Signed-off-by: Eli Mesika <emesika at redhat.com>
> >>>>>>> ---
> >>>>>>> M
> >>>>>>> backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/storage/UpdateStoragePoolCommand.java
> >>>>>>>
> >>>>>>> 1 file changed, 5 insertions(+), 2 deletions(-)
> >>>>>>>
> >>>>>>> Approvals:
> >>>>>>>    Eli Mesika: Verified
> >>>>>>>    Ravi Nori: Looks good to me, but someone else must approve
> >>>>>>>    Yair Zaslavsky: Looks good to me, approved
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Engine-devel mailing list
> >>>>> Engine-devel at ovirt.org
> >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>
> >>>
> >>>
> >>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> > 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From iheim at redhat.com  Sun Mar 23 10:14:37 2014
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 23 Mar 2014 12:14:37 +0200
Subject: [Engine-devel] Change in ovirt-engine[master]: core: enable to
 decrease DC compatibility...
In-Reply-To: <1810385690.186069.1395569606128.JavaMail.zimbra@redhat.com>
References: <gerrit.1392716300399.I73284f641b7f80b380b39efbbd7b4566f55119b6@gerrit.ovirt.org>	<53202FF4.6030004@redhat.com>
	<53203A24.4040200@redhat.com>	<852680674.2850211.1394655652908.JavaMail.zimbra@redhat.com>	<5320C4A9.5010209@redhat.com>	<577568761.2861329.1394657047677.JavaMail.zimbra@redhat.com>	<1789679933.641640.1395343205633.JavaMail.zimbra@redhat.com>	<532BDD57.1090604@redhat.com>
	<1810385690.186069.1395569606128.JavaMail.zimbra@redhat.com>
Message-ID: <532EB40D.5050202@redhat.com>

On 03/23/2014 12:13 PM, Eli Mesika wrote:
>
> So, as far a I understand for resolving this bug the following is OK :
>
> Block downgrading if there are Hosts or Networks (other than the default management network) or SD in the DC when downgrading.

yes

>
>
> ----- Original Message -----
>> From: "Livnat Peer" <lpeer at redhat.com>
>> To: "Moti Asayag" <masayag at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Friday, March 21, 2014 8:33:59 AM
>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...
>>
>> On 03/20/2014 09:20 PM, Moti Asayag wrote:
>>> ----- Original Message -----
>>>> From: "Moti Asayag" <masayag at redhat.com>
>>>> To: "Livnat Peer" <lpeer at redhat.com>
>>>> Cc: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
>>>> Sent: Wednesday, March 12, 2014 10:44:07 PM
>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable
>>>> to decrease DC compatibility...
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Livnat Peer" <lpeer at redhat.com>
>>>>> To: "Moti Asayag" <masayag at redhat.com>
>>>>> Cc: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
>>>>> Sent: Wednesday, March 12, 2014 10:33:45 PM
>>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable
>>>>> to
>>>>> decrease DC compatibility...
>>>>>
>>>>> On 03/12/2014 10:20 PM, Moti Asayag wrote:
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Livnat Peer" <lpeer at redhat.com>
>>>>>>> To: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
>>>>>>> Sent: Wednesday, March 12, 2014 12:42:44 PM
>>>>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core:
>>>>>>> enable
>>>>>>> to	decrease DC compatibility...
>>>>>>>
>>>>>>> On 03/12/2014 11:59 AM, Itamar Heim wrote:
>>>>>>>> On 03/12/2014 12:26 AM, emesika at redhat.com wrote:
>>>>>>>>> Eli Mesika has submitted this change and it was merged.
>>>>>>>>>
>>>>>>>>> Change subject: core: enable to decrease DC compatibility...
>>>>>>>>> ......................................................................
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> core: enable to decrease DC compatibility...
>>>>>>>>>
>>>>>>>>> enable to decrease DC compatibility version if DC has no clusters
>>>>>>>>>
>>>>>>>>> This patch enables to decrease the DC compatibility version if DC has
>>>>>>>>> no
>>>>>>>>> clusters.
>>>>>>>>
>>>>>>>> Eli - just saw this. I'm pretty sure it would be *bad* to downgrade a
>>>>>>>> DC
>>>>>>>> version if it has storage domains as well. not sure if this is checked
>>>>>>>> already or not.
>>>>>>>>
>>>>>>>> may also be an issue with some logical network features.
>>>>>>>>
>>>>>>>
>>>>>>> Most of the network features are driven from cluster level, we enable
>>>>>>> using the features on all DC level (actually >=3.1) but actually enable
>>>>>>> /disable the feature when attaching the network to a cluster.
>>>>>>>
>>>>>>> So from network perspective I think it should be fine to downgrade the
>>>>>>> DC level even if there are networks in the DC (at least now this could
>>>>>>> change in future versions).
>>>>>>>
>>>>>>
>>>>>> Actually we block adding or updating networks if the feature is not
>>>>>> supported
>>>>>> on the network's DC level, for example: STP, Jumbo frames and non-vm
>>>>>> network.
>>>>>>
>>>>>
>>>>>  From which DC level we support STP?  Jumbo frames? non-vm network? isn't
>>>>> all of them supported in >=3.1 ?
>>>>>
>>>>
>>>> Yes, mainly the problem with downgrading a DC to 3.0.
>>>>
>>>
>>> I had a discussion with Mike (cc'ed) about several possible solutions
>>> for the networks compatibility within the data-center.
>>>
>>> The first proposed solution would utilize the NetworkUpdateValidator,
>>> a validation utility that verifies the compatibility of a network
>>> to the data-center. This solution preserves the same behaviour as today,
>>> that the features of network-level are dictated by the DC version. No
>>> need to reimplement any logic in the decrease DC version flow, just use
>>> an existing one to be applied for any network within the DC.
>>>
>>> The second solution suggests we allow any settings of a network, and
>>> compatibility enforcement is done on attaching the network to the clusters.
>>> This modifies the existing behaviour and expands the capabilities of the
>>> engine to support advanced network feature in advanced cluster within an
>>> old data center (i.e. cluster 3.4 in 3.0 data-center could and probably
>>> should use non-vm network, jumbo-frames and more).
>>> This option requires more work in add/update network and attach network to
>>> cluster
>>> flows, both on the backend and UI. Specifically since by default a new
>>> network
>>> created in a DC is being attached to all of the clusters.
>>> Perhaps the second option deserves to be treated as RFE and not as a bug
>>> fix.
>>>
>>> Thoughts ?
>>>
>>
>> The second approach you suggested is equivalent to creating networks in
>> cluster level vs. DC level, which is used today.
>>
>> We should consider that for 4.0 and think on the pros and cons of doing so.
>>
>> In general for this specific discussion I think a simple block on DC
>> downgrade should be enough.
>>
>>> Moti
>>>
>>>>>> Therefore if the management network was configured with any of those
>>>>>> feature,
>>>>>> there is a need to either block the action or to 'initialize' the
>>>>>> network
>>>>>> to
>>>>>> the default settings (as new network being added).
>>>>>>
>>>>>>> In general I believe the use case for this patch is mostly for empty
>>>>>>> DCs
>>>>>>> so for simplicity we should block it if there are networks or SD in the
>>>>>>> DC when downgrading.
>>>>>>>
>>>>>>> Livnat
>>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>> Change-Id: I73284f641b7f80b380b39efbbd7b4566f55119b6
>>>>>>>>> Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1057029
>>>>>>>>> Signed-off-by: Eli Mesika <emesika at redhat.com>
>>>>>>>>> ---
>>>>>>>>> M
>>>>>>>>> backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/storage/UpdateStoragePoolCommand.java
>>>>>>>>>
>>>>>>>>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>>>>>>>>
>>>>>>>>> Approvals:
>>>>>>>>>     Eli Mesika: Verified
>>>>>>>>>     Ravi Nori: Looks good to me, but someone else must approve
>>>>>>>>>     Yair Zaslavsky: Looks good to me, approved
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Engine-devel mailing list
>>>>>>> Engine-devel at ovirt.org
>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>
>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>



From lpeer at redhat.com  Sun Mar 23 10:25:48 2014
From: lpeer at redhat.com (Livnat Peer)
Date: Sun, 23 Mar 2014 12:25:48 +0200
Subject: [Engine-devel] Change in ovirt-engine[master]: core: enable to
 decrease DC compatibility...
In-Reply-To: <1810385690.186069.1395569606128.JavaMail.zimbra@redhat.com>
References: <gerrit.1392716300399.I73284f641b7f80b380b39efbbd7b4566f55119b6@gerrit.ovirt.org>	<53202FF4.6030004@redhat.com>
	<53203A24.4040200@redhat.com>	<852680674.2850211.1394655652908.JavaMail.zimbra@redhat.com>	<5320C4A9.5010209@redhat.com>	<577568761.2861329.1394657047677.JavaMail.zimbra@redhat.com>	<1789679933.641640.1395343205633.JavaMail.zimbra@redhat.com>	<532BDD57.1090604@redhat.com>
	<1810385690.186069.1395569606128.JavaMail.zimbra@redhat.com>
Message-ID: <532EB6AC.3000104@redhat.com>

On 03/23/2014 12:13 PM, Eli Mesika wrote:
> 
> So, as far a I understand for resolving this bug the following is OK :
> 
> Block downgrading if there are Hosts or Networks (other than the default management network) or SD in the DC when downgrading.
>  


Why does having hosts should prevent us from downgrading the DC level?

> 
> ----- Original Message -----
>> From: "Livnat Peer" <lpeer at redhat.com>
>> To: "Moti Asayag" <masayag at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Friday, March 21, 2014 8:33:59 AM
>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...
>>
>> On 03/20/2014 09:20 PM, Moti Asayag wrote:
>>> ----- Original Message -----
>>>> From: "Moti Asayag" <masayag at redhat.com>
>>>> To: "Livnat Peer" <lpeer at redhat.com>
>>>> Cc: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
>>>> Sent: Wednesday, March 12, 2014 10:44:07 PM
>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable
>>>> to decrease DC compatibility...
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Livnat Peer" <lpeer at redhat.com>
>>>>> To: "Moti Asayag" <masayag at redhat.com>
>>>>> Cc: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
>>>>> Sent: Wednesday, March 12, 2014 10:33:45 PM
>>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable
>>>>> to
>>>>> decrease DC compatibility...
>>>>>
>>>>> On 03/12/2014 10:20 PM, Moti Asayag wrote:
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Livnat Peer" <lpeer at redhat.com>
>>>>>>> To: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
>>>>>>> Sent: Wednesday, March 12, 2014 12:42:44 PM
>>>>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core:
>>>>>>> enable
>>>>>>> to	decrease DC compatibility...
>>>>>>>
>>>>>>> On 03/12/2014 11:59 AM, Itamar Heim wrote:
>>>>>>>> On 03/12/2014 12:26 AM, emesika at redhat.com wrote:
>>>>>>>>> Eli Mesika has submitted this change and it was merged.
>>>>>>>>>
>>>>>>>>> Change subject: core: enable to decrease DC compatibility...
>>>>>>>>> ......................................................................
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> core: enable to decrease DC compatibility...
>>>>>>>>>
>>>>>>>>> enable to decrease DC compatibility version if DC has no clusters
>>>>>>>>>
>>>>>>>>> This patch enables to decrease the DC compatibility version if DC has
>>>>>>>>> no
>>>>>>>>> clusters.
>>>>>>>>
>>>>>>>> Eli - just saw this. I'm pretty sure it would be *bad* to downgrade a
>>>>>>>> DC
>>>>>>>> version if it has storage domains as well. not sure if this is checked
>>>>>>>> already or not.
>>>>>>>>
>>>>>>>> may also be an issue with some logical network features.
>>>>>>>>
>>>>>>>
>>>>>>> Most of the network features are driven from cluster level, we enable
>>>>>>> using the features on all DC level (actually >=3.1) but actually enable
>>>>>>> /disable the feature when attaching the network to a cluster.
>>>>>>>
>>>>>>> So from network perspective I think it should be fine to downgrade the
>>>>>>> DC level even if there are networks in the DC (at least now this could
>>>>>>> change in future versions).
>>>>>>>
>>>>>>
>>>>>> Actually we block adding or updating networks if the feature is not
>>>>>> supported
>>>>>> on the network's DC level, for example: STP, Jumbo frames and non-vm
>>>>>> network.
>>>>>>
>>>>>
>>>>> From which DC level we support STP?  Jumbo frames? non-vm network? isn't
>>>>> all of them supported in >=3.1 ?
>>>>>
>>>>
>>>> Yes, mainly the problem with downgrading a DC to 3.0.
>>>>
>>>
>>> I had a discussion with Mike (cc'ed) about several possible solutions
>>> for the networks compatibility within the data-center.
>>>
>>> The first proposed solution would utilize the NetworkUpdateValidator,
>>> a validation utility that verifies the compatibility of a network
>>> to the data-center. This solution preserves the same behaviour as today,
>>> that the features of network-level are dictated by the DC version. No
>>> need to reimplement any logic in the decrease DC version flow, just use
>>> an existing one to be applied for any network within the DC.
>>>
>>> The second solution suggests we allow any settings of a network, and
>>> compatibility enforcement is done on attaching the network to the clusters.
>>> This modifies the existing behaviour and expands the capabilities of the
>>> engine to support advanced network feature in advanced cluster within an
>>> old data center (i.e. cluster 3.4 in 3.0 data-center could and probably
>>> should use non-vm network, jumbo-frames and more).
>>> This option requires more work in add/update network and attach network to
>>> cluster
>>> flows, both on the backend and UI. Specifically since by default a new
>>> network
>>> created in a DC is being attached to all of the clusters.
>>> Perhaps the second option deserves to be treated as RFE and not as a bug
>>> fix.
>>>
>>> Thoughts ?
>>>
>>
>> The second approach you suggested is equivalent to creating networks in
>> cluster level vs. DC level, which is used today.
>>
>> We should consider that for 4.0 and think on the pros and cons of doing so.
>>
>> In general for this specific discussion I think a simple block on DC
>> downgrade should be enough.
>>
>>> Moti
>>>  
>>>>>> Therefore if the management network was configured with any of those
>>>>>> feature,
>>>>>> there is a need to either block the action or to 'initialize' the
>>>>>> network
>>>>>> to
>>>>>> the default settings (as new network being added).
>>>>>>
>>>>>>> In general I believe the use case for this patch is mostly for empty
>>>>>>> DCs
>>>>>>> so for simplicity we should block it if there are networks or SD in the
>>>>>>> DC when downgrading.
>>>>>>>
>>>>>>> Livnat
>>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>> Change-Id: I73284f641b7f80b380b39efbbd7b4566f55119b6
>>>>>>>>> Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1057029
>>>>>>>>> Signed-off-by: Eli Mesika <emesika at redhat.com>
>>>>>>>>> ---
>>>>>>>>> M
>>>>>>>>> backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/storage/UpdateStoragePoolCommand.java
>>>>>>>>>
>>>>>>>>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>>>>>>>>
>>>>>>>>> Approvals:
>>>>>>>>>    Eli Mesika: Verified
>>>>>>>>>    Ravi Nori: Looks good to me, but someone else must approve
>>>>>>>>>    Yair Zaslavsky: Looks good to me, approved
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Engine-devel mailing list
>>>>>>> Engine-devel at ovirt.org
>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>
>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 



From emesika at redhat.com  Sun Mar 23 10:49:41 2014
From: emesika at redhat.com (Eli Mesika)
Date: Sun, 23 Mar 2014 06:49:41 -0400 (EDT)
Subject: [Engine-devel] Change in ovirt-engine[master]: core: enable to
 decrease DC compatibility...
In-Reply-To: <532EB40D.5050202@redhat.com>
References: <gerrit.1392716300399.I73284f641b7f80b380b39efbbd7b4566f55119b6@gerrit.ovirt.org>
	<852680674.2850211.1394655652908.JavaMail.zimbra@redhat.com>
	<5320C4A9.5010209@redhat.com>
	<577568761.2861329.1394657047677.JavaMail.zimbra@redhat.com>
	<1789679933.641640.1395343205633.JavaMail.zimbra@redhat.com>
	<532BDD57.1090604@redhat.com>
	<1810385690.186069.1395569606128.JavaMail.zimbra@redhat.com>
	<532EB40D.5050202@redhat.com>
Message-ID: <869684778.188084.1395571781777.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>, engine-devel at ovirt.org
> Sent: Sunday, March 23, 2014 12:14:37 PM
> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...
> 
> On 03/23/2014 12:13 PM, Eli Mesika wrote:
> >
> > So, as far a I understand for resolving this bug the following is OK :
> >
> > Block downgrading if there are Hosts or Networks (other than the default
> > management network) or SD in the DC when downgrading.
> 
> yes

BTW there is another BZ for decreasing the default cluster version (BZ 1076555)
Should we apply the same here as well ?

> 
> >
> >
> > ----- Original Message -----
> >> From: "Livnat Peer" <lpeer at redhat.com>
> >> To: "Moti Asayag" <masayag at redhat.com>
> >> Cc: engine-devel at ovirt.org
> >> Sent: Friday, March 21, 2014 8:33:59 AM
> >> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable
> >> to decrease DC compatibility...
> >>
> >> On 03/20/2014 09:20 PM, Moti Asayag wrote:
> >>> ----- Original Message -----
> >>>> From: "Moti Asayag" <masayag at redhat.com>
> >>>> To: "Livnat Peer" <lpeer at redhat.com>
> >>>> Cc: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
> >>>> Sent: Wednesday, March 12, 2014 10:44:07 PM
> >>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable
> >>>> to decrease DC compatibility...
> >>>>
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Livnat Peer" <lpeer at redhat.com>
> >>>>> To: "Moti Asayag" <masayag at redhat.com>
> >>>>> Cc: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
> >>>>> Sent: Wednesday, March 12, 2014 10:33:45 PM
> >>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core:
> >>>>> enable
> >>>>> to
> >>>>> decrease DC compatibility...
> >>>>>
> >>>>> On 03/12/2014 10:20 PM, Moti Asayag wrote:
> >>>>>>
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>>> From: "Livnat Peer" <lpeer at redhat.com>
> >>>>>>> To: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
> >>>>>>> Sent: Wednesday, March 12, 2014 12:42:44 PM
> >>>>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core:
> >>>>>>> enable
> >>>>>>> to	decrease DC compatibility...
> >>>>>>>
> >>>>>>> On 03/12/2014 11:59 AM, Itamar Heim wrote:
> >>>>>>>> On 03/12/2014 12:26 AM, emesika at redhat.com wrote:
> >>>>>>>>> Eli Mesika has submitted this change and it was merged.
> >>>>>>>>>
> >>>>>>>>> Change subject: core: enable to decrease DC compatibility...
> >>>>>>>>> ......................................................................
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> core: enable to decrease DC compatibility...
> >>>>>>>>>
> >>>>>>>>> enable to decrease DC compatibility version if DC has no clusters
> >>>>>>>>>
> >>>>>>>>> This patch enables to decrease the DC compatibility version if DC
> >>>>>>>>> has
> >>>>>>>>> no
> >>>>>>>>> clusters.
> >>>>>>>>
> >>>>>>>> Eli - just saw this. I'm pretty sure it would be *bad* to downgrade
> >>>>>>>> a
> >>>>>>>> DC
> >>>>>>>> version if it has storage domains as well. not sure if this is
> >>>>>>>> checked
> >>>>>>>> already or not.
> >>>>>>>>
> >>>>>>>> may also be an issue with some logical network features.
> >>>>>>>>
> >>>>>>>
> >>>>>>> Most of the network features are driven from cluster level, we enable
> >>>>>>> using the features on all DC level (actually >=3.1) but actually
> >>>>>>> enable
> >>>>>>> /disable the feature when attaching the network to a cluster.
> >>>>>>>
> >>>>>>> So from network perspective I think it should be fine to downgrade
> >>>>>>> the
> >>>>>>> DC level even if there are networks in the DC (at least now this
> >>>>>>> could
> >>>>>>> change in future versions).
> >>>>>>>
> >>>>>>
> >>>>>> Actually we block adding or updating networks if the feature is not
> >>>>>> supported
> >>>>>> on the network's DC level, for example: STP, Jumbo frames and non-vm
> >>>>>> network.
> >>>>>>
> >>>>>
> >>>>>  From which DC level we support STP?  Jumbo frames? non-vm network?
> >>>>>  isn't
> >>>>> all of them supported in >=3.1 ?
> >>>>>
> >>>>
> >>>> Yes, mainly the problem with downgrading a DC to 3.0.
> >>>>
> >>>
> >>> I had a discussion with Mike (cc'ed) about several possible solutions
> >>> for the networks compatibility within the data-center.
> >>>
> >>> The first proposed solution would utilize the NetworkUpdateValidator,
> >>> a validation utility that verifies the compatibility of a network
> >>> to the data-center. This solution preserves the same behaviour as today,
> >>> that the features of network-level are dictated by the DC version. No
> >>> need to reimplement any logic in the decrease DC version flow, just use
> >>> an existing one to be applied for any network within the DC.
> >>>
> >>> The second solution suggests we allow any settings of a network, and
> >>> compatibility enforcement is done on attaching the network to the
> >>> clusters.
> >>> This modifies the existing behaviour and expands the capabilities of the
> >>> engine to support advanced network feature in advanced cluster within an
> >>> old data center (i.e. cluster 3.4 in 3.0 data-center could and probably
> >>> should use non-vm network, jumbo-frames and more).
> >>> This option requires more work in add/update network and attach network
> >>> to
> >>> cluster
> >>> flows, both on the backend and UI. Specifically since by default a new
> >>> network
> >>> created in a DC is being attached to all of the clusters.
> >>> Perhaps the second option deserves to be treated as RFE and not as a bug
> >>> fix.
> >>>
> >>> Thoughts ?
> >>>
> >>
> >> The second approach you suggested is equivalent to creating networks in
> >> cluster level vs. DC level, which is used today.
> >>
> >> We should consider that for 4.0 and think on the pros and cons of doing
> >> so.
> >>
> >> In general for this specific discussion I think a simple block on DC
> >> downgrade should be enough.
> >>
> >>> Moti
> >>>
> >>>>>> Therefore if the management network was configured with any of those
> >>>>>> feature,
> >>>>>> there is a need to either block the action or to 'initialize' the
> >>>>>> network
> >>>>>> to
> >>>>>> the default settings (as new network being added).
> >>>>>>
> >>>>>>> In general I believe the use case for this patch is mostly for empty
> >>>>>>> DCs
> >>>>>>> so for simplicity we should block it if there are networks or SD in
> >>>>>>> the
> >>>>>>> DC when downgrading.
> >>>>>>>
> >>>>>>> Livnat
> >>>>>>>
> >>>>>>>
> >>>>>>>>>
> >>>>>>>>> Change-Id: I73284f641b7f80b380b39efbbd7b4566f55119b6
> >>>>>>>>> Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1057029
> >>>>>>>>> Signed-off-by: Eli Mesika <emesika at redhat.com>
> >>>>>>>>> ---
> >>>>>>>>> M
> >>>>>>>>> backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/storage/UpdateStoragePoolCommand.java
> >>>>>>>>>
> >>>>>>>>> 1 file changed, 5 insertions(+), 2 deletions(-)
> >>>>>>>>>
> >>>>>>>>> Approvals:
> >>>>>>>>>     Eli Mesika: Verified
> >>>>>>>>>     Ravi Nori: Looks good to me, but someone else must approve
> >>>>>>>>>     Yair Zaslavsky: Looks good to me, approved
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Engine-devel mailing list
> >>>>>>> Engine-devel at ovirt.org
> >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>> _______________________________________________
> >>> Engine-devel mailing list
> >>> Engine-devel at ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>
> >>>
> >>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
> 


From iheim at redhat.com  Sun Mar 23 11:10:21 2014
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 23 Mar 2014 13:10:21 +0200
Subject: [Engine-devel] Change in ovirt-engine[master]: core: enable to
 decrease DC compatibility...
In-Reply-To: <532EB6AC.3000104@redhat.com>
References: <gerrit.1392716300399.I73284f641b7f80b380b39efbbd7b4566f55119b6@gerrit.ovirt.org>	<53202FF4.6030004@redhat.com>	<53203A24.4040200@redhat.com>	<852680674.2850211.1394655652908.JavaMail.zimbra@redhat.com>	<5320C4A9.5010209@redhat.com>	<577568761.2861329.1394657047677.JavaMail.zimbra@redhat.com>	<1789679933.641640.1395343205633.JavaMail.zimbra@redhat.com>	<532BDD57.1090604@redhat.com>	<1810385690.186069.1395569606128.JavaMail.zimbra@redhat.com>
	<532EB6AC.3000104@redhat.com>
Message-ID: <532EC11D.5090201@redhat.com>

On 03/23/2014 12:25 PM, Livnat Peer wrote:
> On 03/23/2014 12:13 PM, Eli Mesika wrote:
>>
>> So, as far a I understand for resolving this bug the following is OK :
>>
>> Block downgrading if there are Hosts or Networks (other than the default management network) or SD in the DC when downgrading.
>>
>
>
> Why does having hosts should prevent us from downgrading the DC level?

tomorrow you may have hosts which won't support an older cluster.


From iheim at redhat.com  Sun Mar 23 11:10:46 2014
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 23 Mar 2014 13:10:46 +0200
Subject: [Engine-devel] Change in ovirt-engine[master]: core: enable to
 decrease DC compatibility...
In-Reply-To: <869684778.188084.1395571781777.JavaMail.zimbra@redhat.com>
References: <gerrit.1392716300399.I73284f641b7f80b380b39efbbd7b4566f55119b6@gerrit.ovirt.org>
	<852680674.2850211.1394655652908.JavaMail.zimbra@redhat.com>
	<5320C4A9.5010209@redhat.com>
	<577568761.2861329.1394657047677.JavaMail.zimbra@redhat.com>
	<1789679933.641640.1395343205633.JavaMail.zimbra@redhat.com>
	<532BDD57.1090604@redhat.com>
	<1810385690.186069.1395569606128.JavaMail.zimbra@redhat.com>
	<532EB40D.5050202@redhat.com>
	<869684778.188084.1395571781777.JavaMail.zimbra@redhat.com>
Message-ID: <532EC136.9070304@redhat.com>

On 03/23/2014 12:49 PM, Eli Mesika wrote:
>
>
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Eli Mesika" <emesika at redhat.com>, engine-devel at ovirt.org
>> Sent: Sunday, March 23, 2014 12:14:37 PM
>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...
>>
>> On 03/23/2014 12:13 PM, Eli Mesika wrote:
>>>
>>> So, as far a I understand for resolving this bug the following is OK :
>>>
>>> Block downgrading if there are Hosts or Networks (other than the default
>>> management network) or SD in the DC when downgrading.
>>
>> yes
>
> BTW there is another BZ for decreasing the default cluster version (BZ 1076555)
> Should we apply the same here as well ?

yes.
as for hosts, could be limited to hosts supporting the cluster level

>
>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Livnat Peer" <lpeer at redhat.com>
>>>> To: "Moti Asayag" <masayag at redhat.com>
>>>> Cc: engine-devel at ovirt.org
>>>> Sent: Friday, March 21, 2014 8:33:59 AM
>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable
>>>> to decrease DC compatibility...
>>>>
>>>> On 03/20/2014 09:20 PM, Moti Asayag wrote:
>>>>> ----- Original Message -----
>>>>>> From: "Moti Asayag" <masayag at redhat.com>
>>>>>> To: "Livnat Peer" <lpeer at redhat.com>
>>>>>> Cc: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
>>>>>> Sent: Wednesday, March 12, 2014 10:44:07 PM
>>>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable
>>>>>> to decrease DC compatibility...
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Livnat Peer" <lpeer at redhat.com>
>>>>>>> To: "Moti Asayag" <masayag at redhat.com>
>>>>>>> Cc: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
>>>>>>> Sent: Wednesday, March 12, 2014 10:33:45 PM
>>>>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core:
>>>>>>> enable
>>>>>>> to
>>>>>>> decrease DC compatibility...
>>>>>>>
>>>>>>> On 03/12/2014 10:20 PM, Moti Asayag wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Livnat Peer" <lpeer at redhat.com>
>>>>>>>>> To: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
>>>>>>>>> Sent: Wednesday, March 12, 2014 12:42:44 PM
>>>>>>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core:
>>>>>>>>> enable
>>>>>>>>> to	decrease DC compatibility...
>>>>>>>>>
>>>>>>>>> On 03/12/2014 11:59 AM, Itamar Heim wrote:
>>>>>>>>>> On 03/12/2014 12:26 AM, emesika at redhat.com wrote:
>>>>>>>>>>> Eli Mesika has submitted this change and it was merged.
>>>>>>>>>>>
>>>>>>>>>>> Change subject: core: enable to decrease DC compatibility...
>>>>>>>>>>> ......................................................................
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> core: enable to decrease DC compatibility...
>>>>>>>>>>>
>>>>>>>>>>> enable to decrease DC compatibility version if DC has no clusters
>>>>>>>>>>>
>>>>>>>>>>> This patch enables to decrease the DC compatibility version if DC
>>>>>>>>>>> has
>>>>>>>>>>> no
>>>>>>>>>>> clusters.
>>>>>>>>>>
>>>>>>>>>> Eli - just saw this. I'm pretty sure it would be *bad* to downgrade
>>>>>>>>>> a
>>>>>>>>>> DC
>>>>>>>>>> version if it has storage domains as well. not sure if this is
>>>>>>>>>> checked
>>>>>>>>>> already or not.
>>>>>>>>>>
>>>>>>>>>> may also be an issue with some logical network features.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Most of the network features are driven from cluster level, we enable
>>>>>>>>> using the features on all DC level (actually >=3.1) but actually
>>>>>>>>> enable
>>>>>>>>> /disable the feature when attaching the network to a cluster.
>>>>>>>>>
>>>>>>>>> So from network perspective I think it should be fine to downgrade
>>>>>>>>> the
>>>>>>>>> DC level even if there are networks in the DC (at least now this
>>>>>>>>> could
>>>>>>>>> change in future versions).
>>>>>>>>>
>>>>>>>>
>>>>>>>> Actually we block adding or updating networks if the feature is not
>>>>>>>> supported
>>>>>>>> on the network's DC level, for example: STP, Jumbo frames and non-vm
>>>>>>>> network.
>>>>>>>>
>>>>>>>
>>>>>>>   From which DC level we support STP?  Jumbo frames? non-vm network?
>>>>>>>   isn't
>>>>>>> all of them supported in >=3.1 ?
>>>>>>>
>>>>>>
>>>>>> Yes, mainly the problem with downgrading a DC to 3.0.
>>>>>>
>>>>>
>>>>> I had a discussion with Mike (cc'ed) about several possible solutions
>>>>> for the networks compatibility within the data-center.
>>>>>
>>>>> The first proposed solution would utilize the NetworkUpdateValidator,
>>>>> a validation utility that verifies the compatibility of a network
>>>>> to the data-center. This solution preserves the same behaviour as today,
>>>>> that the features of network-level are dictated by the DC version. No
>>>>> need to reimplement any logic in the decrease DC version flow, just use
>>>>> an existing one to be applied for any network within the DC.
>>>>>
>>>>> The second solution suggests we allow any settings of a network, and
>>>>> compatibility enforcement is done on attaching the network to the
>>>>> clusters.
>>>>> This modifies the existing behaviour and expands the capabilities of the
>>>>> engine to support advanced network feature in advanced cluster within an
>>>>> old data center (i.e. cluster 3.4 in 3.0 data-center could and probably
>>>>> should use non-vm network, jumbo-frames and more).
>>>>> This option requires more work in add/update network and attach network
>>>>> to
>>>>> cluster
>>>>> flows, both on the backend and UI. Specifically since by default a new
>>>>> network
>>>>> created in a DC is being attached to all of the clusters.
>>>>> Perhaps the second option deserves to be treated as RFE and not as a bug
>>>>> fix.
>>>>>
>>>>> Thoughts ?
>>>>>
>>>>
>>>> The second approach you suggested is equivalent to creating networks in
>>>> cluster level vs. DC level, which is used today.
>>>>
>>>> We should consider that for 4.0 and think on the pros and cons of doing
>>>> so.
>>>>
>>>> In general for this specific discussion I think a simple block on DC
>>>> downgrade should be enough.
>>>>
>>>>> Moti
>>>>>
>>>>>>>> Therefore if the management network was configured with any of those
>>>>>>>> feature,
>>>>>>>> there is a need to either block the action or to 'initialize' the
>>>>>>>> network
>>>>>>>> to
>>>>>>>> the default settings (as new network being added).
>>>>>>>>
>>>>>>>>> In general I believe the use case for this patch is mostly for empty
>>>>>>>>> DCs
>>>>>>>>> so for simplicity we should block it if there are networks or SD in
>>>>>>>>> the
>>>>>>>>> DC when downgrading.
>>>>>>>>>
>>>>>>>>> Livnat
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Change-Id: I73284f641b7f80b380b39efbbd7b4566f55119b6
>>>>>>>>>>> Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1057029
>>>>>>>>>>> Signed-off-by: Eli Mesika <emesika at redhat.com>
>>>>>>>>>>> ---
>>>>>>>>>>> M
>>>>>>>>>>> backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/storage/UpdateStoragePoolCommand.java
>>>>>>>>>>>
>>>>>>>>>>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>>>>>>>>>>
>>>>>>>>>>> Approvals:
>>>>>>>>>>>      Eli Mesika: Verified
>>>>>>>>>>>      Ravi Nori: Looks good to me, but someone else must approve
>>>>>>>>>>>      Yair Zaslavsky: Looks good to me, approved
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Engine-devel mailing list
>>>>>>>>> Engine-devel at ovirt.org
>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>
>>



From lpeer at redhat.com  Sun Mar 23 11:13:11 2014
From: lpeer at redhat.com (Livnat Peer)
Date: Sun, 23 Mar 2014 13:13:11 +0200
Subject: [Engine-devel] Change in ovirt-engine[master]: core: enable to
 decrease DC compatibility...
In-Reply-To: <532EC11D.5090201@redhat.com>
References: <gerrit.1392716300399.I73284f641b7f80b380b39efbbd7b4566f55119b6@gerrit.ovirt.org>	<53202FF4.6030004@redhat.com>	<53203A24.4040200@redhat.com>	<852680674.2850211.1394655652908.JavaMail.zimbra@redhat.com>	<5320C4A9.5010209@redhat.com>	<577568761.2861329.1394657047677.JavaMail.zimbra@redhat.com>	<1789679933.641640.1395343205633.JavaMail.zimbra@redhat.com>	<532BDD57.1090604@redhat.com>	<1810385690.186069.1395569606128.JavaMail.zimbra@redhat.com>
	<532EB6AC.3000104@redhat.com> <532EC11D.5090201@redhat.com>
Message-ID: <532EC1C7.6080503@redhat.com>

On 03/23/2014 01:10 PM, Itamar Heim wrote:
> On 03/23/2014 12:25 PM, Livnat Peer wrote:
>> On 03/23/2014 12:13 PM, Eli Mesika wrote:
>>>
>>> So, as far a I understand for resolving this bug the following is OK :
>>>
>>> Block downgrading if there are Hosts or Networks (other than the
>>> default management network) or SD in the DC when downgrading.
>>>
>>
>>
>> Why does having hosts should prevent us from downgrading the DC level?
> 
> tomorrow you may have hosts which won't support an older cluster.

Host are associated with a cluster, how can downgrading of DC level
impact the existing hosts? DC downgrade does not downgrade the clusters
level.


From iheim at redhat.com  Sun Mar 23 11:39:16 2014
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 23 Mar 2014 13:39:16 +0200
Subject: [Engine-devel] Change in ovirt-engine[master]: core: enable to
 decrease DC compatibility...
In-Reply-To: <532EC1C7.6080503@redhat.com>
References: <gerrit.1392716300399.I73284f641b7f80b380b39efbbd7b4566f55119b6@gerrit.ovirt.org>	<53202FF4.6030004@redhat.com>	<53203A24.4040200@redhat.com>	<852680674.2850211.1394655652908.JavaMail.zimbra@redhat.com>	<5320C4A9.5010209@redhat.com>	<577568761.2861329.1394657047677.JavaMail.zimbra@redhat.com>	<1789679933.641640.1395343205633.JavaMail.zimbra@redhat.com>	<532BDD57.1090604@redhat.com>	<1810385690.186069.1395569606128.JavaMail.zimbra@redhat.com>
	<532EB6AC.3000104@redhat.com> <532EC11D.5090201@redhat.com>
	<532EC1C7.6080503@redhat.com>
Message-ID: <532EC7E4.2030205@redhat.com>

On 03/23/2014 01:13 PM, Livnat Peer wrote:
> On 03/23/2014 01:10 PM, Itamar Heim wrote:
>> On 03/23/2014 12:25 PM, Livnat Peer wrote:
>>> On 03/23/2014 12:13 PM, Eli Mesika wrote:
>>>>
>>>> So, as far a I understand for resolving this bug the following is OK :
>>>>
>>>> Block downgrading if there are Hosts or Networks (other than the
>>>> default management network) or SD in the DC when downgrading.
>>>>
>>>
>>>
>>> Why does having hosts should prevent us from downgrading the DC level?
>>
>> tomorrow you may have hosts which won't support an older cluster.
>
> Host are associated with a cluster, how can downgrading of DC level
> impact the existing hosts? DC downgrade does not downgrade the clusters
> level.
>

well, you are kind of explaining why this can't happen...
a DC can only be upgraded if all Clusters have already been upgraded.
hence a DC can only be downgraded if it has no clusters, hence no hosts.
(because to downgrade the DC, the clusters would have to be downgraded 
first, and you can't have a cluster lower than the DC...)


From gchaplik at redhat.com  Sun Mar 23 12:06:01 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Sun, 23 Mar 2014 08:06:01 -0400 (EDT)
Subject: [Engine-devel] Share Your Thoughts
In-Reply-To: <51762277.5795281.1395575561916.JavaMail.zimbra@redhat.com>
Message-ID: <399982494.5798586.1395576361223.JavaMail.zimbra@redhat.com>

Dear Devel Community Members,

We are having a small discussion on patch: http://gerrit.ovirt.org/#/c/25633/,
bug 1065753 - "Maintenance operations on a VM would ask for an optional reason" (adding a note to stop/shutdown VM, that will be cleared when the VM go up).

The proposed solution is to add a free text field in the VM entity, and to update it in command's parameters (StopVmParmas.. etc.).

I think slightly different, my alternative is to enhance the current free text (comment field) into XML, and allow to add multiple comments that include types.
You are welcome to read more about it in the patch's comments.

Thoughts?

Thanks, 
Gilad.


From emesika at redhat.com  Sun Mar 23 12:36:17 2014
From: emesika at redhat.com (Eli Mesika)
Date: Sun, 23 Mar 2014 08:36:17 -0400 (EDT)
Subject: [Engine-devel] Share Your Thoughts
In-Reply-To: <399982494.5798586.1395576361223.JavaMail.zimbra@redhat.com>
References: <399982494.5798586.1395576361223.JavaMail.zimbra@redhat.com>
Message-ID: <97397536.195664.1395578177826.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Gilad Chaplik" <gchaplik at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, March 23, 2014 2:06:01 PM
> Subject: [Engine-devel] Share Your Thoughts
> 
> Dear Devel Community Members,
> 
> We are having a small discussion on patch:
> http://gerrit.ovirt.org/#/c/25633/,
> bug 1065753 - "Maintenance operations on a VM would ask for an optional
> reason" (adding a note to stop/shutdown VM, that will be cleared when the VM
> go up).
> 
> The proposed solution is to add a free text field in the VM entity, and to
> update it in command's parameters (StopVmParmas.. etc.).
> 
> I think slightly different, my alternative is to enhance the current free
> text (comment field) into XML, and allow to add multiple comments that
> include types.
> You are welcome to read more about it in the patch's comments.
> 
> Thoughts?

I suggest a third approach
We are logging here a reason for a user/admin operation
The natural place for such information is the audit log and not the VM tables.
I think that the audit log messages related for the stop/shutdown commands should be enhanced to include a {REASON} field then the command itself will replace this value in the message with the one given by the user and we are done.
Again, the required information is a pure logging issue, therefor I suggest to put this information in the correct place for it, there is no point in saving any logging messages in any entity table.

Technically:
1) The option for giving a reason should be configurable (per Cluster if I look at Arthur comment in the BZ)
2) If the option is on than any stop/shutdown will ask for reason and sent it in the command parameters
3) If the command succeed and got a non-empty reason , it will set the reason in the command audit log message  


Eli

> 
> Thanks,
> Gilad.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From emesika at redhat.com  Sun Mar 23 12:41:15 2014
From: emesika at redhat.com (Eli Mesika)
Date: Sun, 23 Mar 2014 08:41:15 -0400 (EDT)
Subject: [Engine-devel] Share Your Thoughts
In-Reply-To: <97397536.195664.1395578177826.JavaMail.zimbra@redhat.com>
References: <399982494.5798586.1395576361223.JavaMail.zimbra@redhat.com>
	<97397536.195664.1395578177826.JavaMail.zimbra@redhat.com>
Message-ID: <88455682.196005.1395578475613.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, March 23, 2014 2:36:17 PM
> Subject: Re: [Engine-devel] Share Your Thoughts
> 
> 
> 
> ----- Original Message -----
> > From: "Gilad Chaplik" <gchaplik at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Sunday, March 23, 2014 2:06:01 PM
> > Subject: [Engine-devel] Share Your Thoughts
> > 
> > Dear Devel Community Members,
> > 
> > We are having a small discussion on patch:
> > http://gerrit.ovirt.org/#/c/25633/,
> > bug 1065753 - "Maintenance operations on a VM would ask for an optional
> > reason" (adding a note to stop/shutdown VM, that will be cleared when the
> > VM
> > go up).
> > 
> > The proposed solution is to add a free text field in the VM entity, and to
> > update it in command's parameters (StopVmParmas.. etc.).
> > 
> > I think slightly different, my alternative is to enhance the current free
> > text (comment field) into XML, and allow to add multiple comments that
> > include types.
> > You are welcome to read more about it in the patch's comments.
> > 
> > Thoughts?
> 
> I suggest a third approach
> We are logging here a reason for a user/admin operation
> The natural place for such information is the audit log and not the VM
> tables.
> I think that the audit log messages related for the stop/shutdown commands
> should be enhanced to include a {REASON} field then the command itself will
> replace this value in the message with the one given by the user and we are
> done.
> Again, the required information is a pure logging issue, therefor I suggest
> to put this information in the correct place for it, there is no point in
> saving any logging messages in any entity table.
> 
> Technically:
> 1) The option for giving a reason should be configurable (per Cluster if I
> look at Arthur comment in the BZ)
> 2) If the option is on than any stop/shutdown will ask for reason and sent it
> in the command parameters
than=>then
> 3) If the command succeed and got a non-empty reason , it will set the reason
> in the command audit log message
> 

4) We gain here additional advantage since we can : 
   a) search for the reason using the search engine 
   b) get the reason in the message text sent to us if we are subscribed for the VM stop/shotdown event ans using engine-notifier 

> 
> Eli
> 
> > 
> > Thanks,
> > Gilad.
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From masayag at redhat.com  Sun Mar 23 12:47:53 2014
From: masayag at redhat.com (Moti Asayag)
Date: Sun, 23 Mar 2014 08:47:53 -0400 (EDT)
Subject: [Engine-devel] Change in ovirt-engine[master]: core: enable to
 decrease DC compatibility...
In-Reply-To: <532EB40D.5050202@redhat.com>
References: <gerrit.1392716300399.I73284f641b7f80b380b39efbbd7b4566f55119b6@gerrit.ovirt.org>
	<852680674.2850211.1394655652908.JavaMail.zimbra@redhat.com>
	<5320C4A9.5010209@redhat.com>
	<577568761.2861329.1394657047677.JavaMail.zimbra@redhat.com>
	<1789679933.641640.1395343205633.JavaMail.zimbra@redhat.com>
	<532BDD57.1090604@redhat.com>
	<1810385690.186069.1395569606128.JavaMail.zimbra@redhat.com>
	<532EB40D.5050202@redhat.com>
Message-ID: <1761608621.98742.1395578873460.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>, engine-devel at ovirt.org
> Sent: Sunday, March 23, 2014 12:14:37 PM
> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...
> 
> On 03/23/2014 12:13 PM, Eli Mesika wrote:
> >
> > So, as far a I understand for resolving this bug the following is OK :
> >
> > Block downgrading if there are Hosts or Networks (other than the default
> > management network) or SD in the DC when downgrading.
> 
> yes
> 

I don't think it is enough. There is a need to verify the management network
wasn't modified to use unsupported features in the new data-center.

On the same matter, we can allow downgrading if all of the networks in the
data center are using only features that are supported on the target DC version
and not to restrict it only to the management network.

> >
> >
> > ----- Original Message -----
> >> From: "Livnat Peer" <lpeer at redhat.com>
> >> To: "Moti Asayag" <masayag at redhat.com>
> >> Cc: engine-devel at ovirt.org
> >> Sent: Friday, March 21, 2014 8:33:59 AM
> >> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable
> >> to decrease DC compatibility...
> >>
> >> On 03/20/2014 09:20 PM, Moti Asayag wrote:
> >>> ----- Original Message -----
> >>>> From: "Moti Asayag" <masayag at redhat.com>
> >>>> To: "Livnat Peer" <lpeer at redhat.com>
> >>>> Cc: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
> >>>> Sent: Wednesday, March 12, 2014 10:44:07 PM
> >>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable
> >>>> to decrease DC compatibility...
> >>>>
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Livnat Peer" <lpeer at redhat.com>
> >>>>> To: "Moti Asayag" <masayag at redhat.com>
> >>>>> Cc: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
> >>>>> Sent: Wednesday, March 12, 2014 10:33:45 PM
> >>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core:
> >>>>> enable
> >>>>> to
> >>>>> decrease DC compatibility...
> >>>>>
> >>>>> On 03/12/2014 10:20 PM, Moti Asayag wrote:
> >>>>>>
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>>> From: "Livnat Peer" <lpeer at redhat.com>
> >>>>>>> To: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
> >>>>>>> Sent: Wednesday, March 12, 2014 12:42:44 PM
> >>>>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core:
> >>>>>>> enable
> >>>>>>> to	decrease DC compatibility...
> >>>>>>>
> >>>>>>> On 03/12/2014 11:59 AM, Itamar Heim wrote:
> >>>>>>>> On 03/12/2014 12:26 AM, emesika at redhat.com wrote:
> >>>>>>>>> Eli Mesika has submitted this change and it was merged.
> >>>>>>>>>
> >>>>>>>>> Change subject: core: enable to decrease DC compatibility...
> >>>>>>>>> ......................................................................
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> core: enable to decrease DC compatibility...
> >>>>>>>>>
> >>>>>>>>> enable to decrease DC compatibility version if DC has no clusters
> >>>>>>>>>
> >>>>>>>>> This patch enables to decrease the DC compatibility version if DC
> >>>>>>>>> has
> >>>>>>>>> no
> >>>>>>>>> clusters.
> >>>>>>>>
> >>>>>>>> Eli - just saw this. I'm pretty sure it would be *bad* to downgrade
> >>>>>>>> a
> >>>>>>>> DC
> >>>>>>>> version if it has storage domains as well. not sure if this is
> >>>>>>>> checked
> >>>>>>>> already or not.
> >>>>>>>>
> >>>>>>>> may also be an issue with some logical network features.
> >>>>>>>>
> >>>>>>>
> >>>>>>> Most of the network features are driven from cluster level, we enable
> >>>>>>> using the features on all DC level (actually >=3.1) but actually
> >>>>>>> enable
> >>>>>>> /disable the feature when attaching the network to a cluster.
> >>>>>>>
> >>>>>>> So from network perspective I think it should be fine to downgrade
> >>>>>>> the
> >>>>>>> DC level even if there are networks in the DC (at least now this
> >>>>>>> could
> >>>>>>> change in future versions).
> >>>>>>>
> >>>>>>
> >>>>>> Actually we block adding or updating networks if the feature is not
> >>>>>> supported
> >>>>>> on the network's DC level, for example: STP, Jumbo frames and non-vm
> >>>>>> network.
> >>>>>>
> >>>>>
> >>>>>  From which DC level we support STP?  Jumbo frames? non-vm network?
> >>>>>  isn't
> >>>>> all of them supported in >=3.1 ?
> >>>>>
> >>>>
> >>>> Yes, mainly the problem with downgrading a DC to 3.0.
> >>>>
> >>>
> >>> I had a discussion with Mike (cc'ed) about several possible solutions
> >>> for the networks compatibility within the data-center.
> >>>
> >>> The first proposed solution would utilize the NetworkUpdateValidator,
> >>> a validation utility that verifies the compatibility of a network
> >>> to the data-center. This solution preserves the same behaviour as today,
> >>> that the features of network-level are dictated by the DC version. No
> >>> need to reimplement any logic in the decrease DC version flow, just use
> >>> an existing one to be applied for any network within the DC.
> >>>
> >>> The second solution suggests we allow any settings of a network, and
> >>> compatibility enforcement is done on attaching the network to the
> >>> clusters.
> >>> This modifies the existing behaviour and expands the capabilities of the
> >>> engine to support advanced network feature in advanced cluster within an
> >>> old data center (i.e. cluster 3.4 in 3.0 data-center could and probably
> >>> should use non-vm network, jumbo-frames and more).
> >>> This option requires more work in add/update network and attach network
> >>> to
> >>> cluster
> >>> flows, both on the backend and UI. Specifically since by default a new
> >>> network
> >>> created in a DC is being attached to all of the clusters.
> >>> Perhaps the second option deserves to be treated as RFE and not as a bug
> >>> fix.
> >>>
> >>> Thoughts ?
> >>>
> >>
> >> The second approach you suggested is equivalent to creating networks in
> >> cluster level vs. DC level, which is used today.
> >>
> >> We should consider that for 4.0 and think on the pros and cons of doing
> >> so.
> >>
> >> In general for this specific discussion I think a simple block on DC
> >> downgrade should be enough.
> >>
> >>> Moti
> >>>
> >>>>>> Therefore if the management network was configured with any of those
> >>>>>> feature,
> >>>>>> there is a need to either block the action or to 'initialize' the
> >>>>>> network
> >>>>>> to
> >>>>>> the default settings (as new network being added).
> >>>>>>
> >>>>>>> In general I believe the use case for this patch is mostly for empty
> >>>>>>> DCs
> >>>>>>> so for simplicity we should block it if there are networks or SD in
> >>>>>>> the
> >>>>>>> DC when downgrading.
> >>>>>>>
> >>>>>>> Livnat
> >>>>>>>
> >>>>>>>
> >>>>>>>>>
> >>>>>>>>> Change-Id: I73284f641b7f80b380b39efbbd7b4566f55119b6
> >>>>>>>>> Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1057029
> >>>>>>>>> Signed-off-by: Eli Mesika <emesika at redhat.com>
> >>>>>>>>> ---
> >>>>>>>>> M
> >>>>>>>>> backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/storage/UpdateStoragePoolCommand.java
> >>>>>>>>>
> >>>>>>>>> 1 file changed, 5 insertions(+), 2 deletions(-)
> >>>>>>>>>
> >>>>>>>>> Approvals:
> >>>>>>>>>     Eli Mesika: Verified
> >>>>>>>>>     Ravi Nori: Looks good to me, but someone else must approve
> >>>>>>>>>     Yair Zaslavsky: Looks good to me, approved
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Engine-devel mailing list
> >>>>>>> Engine-devel at ovirt.org
> >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>> _______________________________________________
> >>> Engine-devel mailing list
> >>> Engine-devel at ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>
> >>>
> >>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From lpeer at redhat.com  Sun Mar 23 13:07:14 2014
From: lpeer at redhat.com (Livnat Peer)
Date: Sun, 23 Mar 2014 15:07:14 +0200
Subject: [Engine-devel] Change in ovirt-engine[master]: core: enable to
 decrease DC compatibility...
In-Reply-To: <532EC7E4.2030205@redhat.com>
References: <gerrit.1392716300399.I73284f641b7f80b380b39efbbd7b4566f55119b6@gerrit.ovirt.org>	<53202FF4.6030004@redhat.com>	<53203A24.4040200@redhat.com>	<852680674.2850211.1394655652908.JavaMail.zimbra@redhat.com>	<5320C4A9.5010209@redhat.com>	<577568761.2861329.1394657047677.JavaMail.zimbra@redhat.com>	<1789679933.641640.1395343205633.JavaMail.zimbra@redhat.com>	<532BDD57.1090604@redhat.com>	<1810385690.186069.1395569606128.JavaMail.zimbra@redhat.com>	<532EB6AC.3000104@redhat.com>
	<532EC11D.5090201@redhat.com>	<532EC1C7.6080503@redhat.com>
	<532EC7E4.2030205@redhat.com>
Message-ID: <532EDC82.2010901@redhat.com>

On 03/23/2014 01:39 PM, Itamar Heim wrote:
> On 03/23/2014 01:13 PM, Livnat Peer wrote:
>> On 03/23/2014 01:10 PM, Itamar Heim wrote:
>>> On 03/23/2014 12:25 PM, Livnat Peer wrote:
>>>> On 03/23/2014 12:13 PM, Eli Mesika wrote:
>>>>>
>>>>> So, as far a I understand for resolving this bug the following is OK :
>>>>>
>>>>> Block downgrading if there are Hosts or Networks (other than the
>>>>> default management network) or SD in the DC when downgrading.
>>>>>
>>>>
>>>>
>>>> Why does having hosts should prevent us from downgrading the DC level?
>>>
>>> tomorrow you may have hosts which won't support an older cluster.
>>
>> Host are associated with a cluster, how can downgrading of DC level
>> impact the existing hosts? DC downgrade does not downgrade the clusters
>> level.
>>
> 
> well, you are kind of explaining why this can't happen...
> a DC can only be upgraded if all Clusters have already been upgraded.
> hence a DC can only be downgraded if it has no clusters, hence no hosts.
> (because to downgrade the DC, the clusters would have to be downgraded
> first, and you can't have a cluster lower than the DC...)

The only rule we enforce today is -

DC level <= Cluster level : for all clusters in the DC

Thus you can downgrade the DC with clusters in it with no effect on the
clusters or the hosts.
The clusters do not need to be downgraded.


> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 



From ofrenkel at redhat.com  Sun Mar 23 13:35:28 2014
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Sun, 23 Mar 2014 09:35:28 -0400 (EDT)
Subject: [Engine-devel] Share Your Thoughts
In-Reply-To: <88455682.196005.1395578475613.JavaMail.zimbra@redhat.com>
References: <399982494.5798586.1395576361223.JavaMail.zimbra@redhat.com>
	<97397536.195664.1395578177826.JavaMail.zimbra@redhat.com>
	<88455682.196005.1395578475613.JavaMail.zimbra@redhat.com>
Message-ID: <1273090446.4104448.1395581728349.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, March 23, 2014 2:41:15 PM
> Subject: Re: [Engine-devel] Share Your Thoughts
> 
> 
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Gilad Chaplik" <gchaplik at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Sunday, March 23, 2014 2:36:17 PM
> > Subject: Re: [Engine-devel] Share Your Thoughts
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Gilad Chaplik" <gchaplik at redhat.com>
> > > To: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Sunday, March 23, 2014 2:06:01 PM
> > > Subject: [Engine-devel] Share Your Thoughts
> > > 
> > > Dear Devel Community Members,
> > > 
> > > We are having a small discussion on patch:
> > > http://gerrit.ovirt.org/#/c/25633/,
> > > bug 1065753 - "Maintenance operations on a VM would ask for an optional
> > > reason" (adding a note to stop/shutdown VM, that will be cleared when the
> > > VM
> > > go up).
> > > 
> > > The proposed solution is to add a free text field in the VM entity, and
> > > to
> > > update it in command's parameters (StopVmParmas.. etc.).
> > > 
> > > I think slightly different, my alternative is to enhance the current free
> > > text (comment field) into XML, and allow to add multiple comments that
> > > include types.
> > > You are welcome to read more about it in the patch's comments.
> > > 
> > > Thoughts?
> > 
> > I suggest a third approach
> > We are logging here a reason for a user/admin operation
> > The natural place for such information is the audit log and not the VM
> > tables.
> > I think that the audit log messages related for the stop/shutdown commands
> > should be enhanced to include a {REASON} field then the command itself will
> > replace this value in the message with the one given by the user and we are
> > done.
> > Again, the required information is a pure logging issue, therefor I suggest
> > to put this information in the correct place for it, there is no point in
> > saving any logging messages in any entity table.
> > 
> > Technically:
> > 1) The option for giving a reason should be configurable (per Cluster if I
> > look at Arthur comment in the BZ)
> > 2) If the option is on than any stop/shutdown will ask for reason and sent
> > it
> > in the command parameters
> than=>then
> > 3) If the command succeed and got a non-empty reason , it will set the
> > reason
> > in the command audit log message
> > 
> 
> 4) We gain here additional advantage since we can :
>    a) search for the reason using the search engine
>    b) get the reason in the message text sent to us if we are subscribed for
>    the VM stop/shotdown event ans using engine-notifier
> 
> > 
> > Eli
> > 

+1 
sounds like a good and simple idea

> > > 
> > > Thanks,
> > > Gilad.
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From gchaplik at redhat.com  Sun Mar 23 14:01:37 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Sun, 23 Mar 2014 10:01:37 -0400 (EDT)
Subject: [Engine-devel] Share Your Thoughts
In-Reply-To: <1273090446.4104448.1395581728349.JavaMail.zimbra@redhat.com>
References: <399982494.5798586.1395576361223.JavaMail.zimbra@redhat.com>
	<97397536.195664.1395578177826.JavaMail.zimbra@redhat.com>
	<88455682.196005.1395578475613.JavaMail.zimbra@redhat.com>
	<1273090446.4104448.1395581728349.JavaMail.zimbra@redhat.com>
Message-ID: <1574832625.5835647.1395583297184.JavaMail.zimbra@redhat.com>



Thanks, 
Gilad.

----- Original Message -----
> From: "Omer Frenkel" <ofrenkel at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, March 23, 2014 3:35:28 PM
> Subject: Re: [Engine-devel] Share Your Thoughts
> 
> 
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Gilad Chaplik" <gchaplik at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Sunday, March 23, 2014 2:41:15 PM
> > Subject: Re: [Engine-devel] Share Your Thoughts
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Eli Mesika" <emesika at redhat.com>
> > > To: "Gilad Chaplik" <gchaplik at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Sunday, March 23, 2014 2:36:17 PM
> > > Subject: Re: [Engine-devel] Share Your Thoughts
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Gilad Chaplik" <gchaplik at redhat.com>
> > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Sunday, March 23, 2014 2:06:01 PM
> > > > Subject: [Engine-devel] Share Your Thoughts
> > > > 
> > > > Dear Devel Community Members,
> > > > 
> > > > We are having a small discussion on patch:
> > > > http://gerrit.ovirt.org/#/c/25633/,
> > > > bug 1065753 - "Maintenance operations on a VM would ask for an optional
> > > > reason" (adding a note to stop/shutdown VM, that will be cleared when
> > > > the
> > > > VM
> > > > go up).
> > > > 
> > > > The proposed solution is to add a free text field in the VM entity, and
> > > > to
> > > > update it in command's parameters (StopVmParmas.. etc.).
> > > > 
> > > > I think slightly different, my alternative is to enhance the current
> > > > free
> > > > text (comment field) into XML, and allow to add multiple comments that
> > > > include types.
> > > > You are welcome to read more about it in the patch's comments.
> > > > 
> > > > Thoughts?
> > > 
> > > I suggest a third approach
> > > We are logging here a reason for a user/admin operation
> > > The natural place for such information is the audit log and not the VM
> > > tables.
> > > I think that the audit log messages related for the stop/shutdown
> > > commands
> > > should be enhanced to include a {REASON} field then the command itself
> > > will
> > > replace this value in the message with the one given by the user and we
> > > are
> > > done.
> > > Again, the required information is a pure logging issue, therefor I
> > > suggest
> > > to put this information in the correct place for it, there is no point in
> > > saving any logging messages in any entity table.
> > > 
> > > Technically:
> > > 1) The option for giving a reason should be configurable (per Cluster if
> > > I
> > > look at Arthur comment in the BZ)
> > > 2) If the option is on than any stop/shutdown will ask for reason and
> > > sent
> > > it
> > > in the command parameters
> > than=>then
> > > 3) If the command succeed and got a non-empty reason , it will set the
> > > reason
> > > in the command audit log message
> > > 
> > 
> > 4) We gain here additional advantage since we can :
> >    a) search for the reason using the search engine
> >    b) get the reason in the message text sent to us if we are subscribed
> >    for
> >    the VM stop/shotdown event ans using engine-notifier
> > 
> > > 
> > > Eli
> > > 
> 
> +1
> sounds like a good and simple idea

+1, BUT this is completely a different feature, and more difficult (MUCH more, if I may add).
IMHO we need both, lets start with the no-brainer.

> 
> > > > 
> > > > Thanks,
> > > > Gilad.
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > 
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From iheim at redhat.com  Sun Mar 23 14:13:41 2014
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 23 Mar 2014 16:13:41 +0200
Subject: [Engine-devel] Share Your Thoughts
In-Reply-To: <1574832625.5835647.1395583297184.JavaMail.zimbra@redhat.com>
References: <399982494.5798586.1395576361223.JavaMail.zimbra@redhat.com>	<97397536.195664.1395578177826.JavaMail.zimbra@redhat.com>	<88455682.196005.1395578475613.JavaMail.zimbra@redhat.com>	<1273090446.4104448.1395581728349.JavaMail.zimbra@redhat.com>
	<1574832625.5835647.1395583297184.JavaMail.zimbra@redhat.com>
Message-ID: <532EEC15.40200@redhat.com>

On 03/23/2014 04:01 PM, Gilad Chaplik wrote:
>
>
> Thanks,
> Gilad.
>
> ----- Original Message -----
>> From: "Omer Frenkel" <ofrenkel at redhat.com>
>> To: "Eli Mesika" <emesika at redhat.com>
>> Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
>> Sent: Sunday, March 23, 2014 3:35:28 PM
>> Subject: Re: [Engine-devel] Share Your Thoughts
>>
>>
>>
>> ----- Original Message -----
>>> From: "Eli Mesika" <emesika at redhat.com>
>>> To: "Gilad Chaplik" <gchaplik at redhat.com>
>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>> Sent: Sunday, March 23, 2014 2:41:15 PM
>>> Subject: Re: [Engine-devel] Share Your Thoughts
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Eli Mesika" <emesika at redhat.com>
>>>> To: "Gilad Chaplik" <gchaplik at redhat.com>
>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>> Sent: Sunday, March 23, 2014 2:36:17 PM
>>>> Subject: Re: [Engine-devel] Share Your Thoughts
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Gilad Chaplik" <gchaplik at redhat.com>
>>>>> To: "engine-devel" <engine-devel at ovirt.org>
>>>>> Sent: Sunday, March 23, 2014 2:06:01 PM
>>>>> Subject: [Engine-devel] Share Your Thoughts
>>>>>
>>>>> Dear Devel Community Members,
>>>>>
>>>>> We are having a small discussion on patch:
>>>>> http://gerrit.ovirt.org/#/c/25633/,
>>>>> bug 1065753 - "Maintenance operations on a VM would ask for an optional
>>>>> reason" (adding a note to stop/shutdown VM, that will be cleared when
>>>>> the
>>>>> VM
>>>>> go up).
>>>>>
>>>>> The proposed solution is to add a free text field in the VM entity, and
>>>>> to
>>>>> update it in command's parameters (StopVmParmas.. etc.).
>>>>>
>>>>> I think slightly different, my alternative is to enhance the current
>>>>> free
>>>>> text (comment field) into XML, and allow to add multiple comments that
>>>>> include types.
>>>>> You are welcome to read more about it in the patch's comments.
>>>>>
>>>>> Thoughts?
>>>>
>>>> I suggest a third approach
>>>> We are logging here a reason for a user/admin operation
>>>> The natural place for such information is the audit log and not the VM
>>>> tables.
>>>> I think that the audit log messages related for the stop/shutdown
>>>> commands
>>>> should be enhanced to include a {REASON} field then the command itself
>>>> will
>>>> replace this value in the message with the one given by the user and we
>>>> are
>>>> done.
>>>> Again, the required information is a pure logging issue, therefor I
>>>> suggest
>>>> to put this information in the correct place for it, there is no point in
>>>> saving any logging messages in any entity table.
>>>>
>>>> Technically:
>>>> 1) The option for giving a reason should be configurable (per Cluster if
>>>> I
>>>> look at Arthur comment in the BZ)
>>>> 2) If the option is on than any stop/shutdown will ask for reason and
>>>> sent
>>>> it
>>>> in the command parameters
>>> than=>then
>>>> 3) If the command succeed and got a non-empty reason , it will set the
>>>> reason
>>>> in the command audit log message
>>>>
>>>
>>> 4) We gain here additional advantage since we can :
>>>     a) search for the reason using the search engine
>>>     b) get the reason in the message text sent to us if we are subscribed
>>>     for
>>>     the VM stop/shotdown event ans using engine-notifier
>>>
>>>>
>>>> Eli
>>>>
>>
>> +1
>> sounds like a good and simple idea
>
> +1, BUT this is completely a different feature, and more difficult (MUCH more, if I may add).
> IMHO we need both, lets start with the no-brainer.

AuditLog gets recycled after 30 days. the reason i stopped my VM may 
still be relevant.
I would not make fields complex/composite. they need to be easily 
useable via the CLI for example.

>
>>
>>>>>
>>>>> Thanks,
>>>>> Gilad.
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>
>>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>



From gchaplik at redhat.com  Sun Mar 23 14:36:07 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Sun, 23 Mar 2014 10:36:07 -0400 (EDT)
Subject: [Engine-devel] Share Your Thoughts
In-Reply-To: <532EEC15.40200@redhat.com>
References: <399982494.5798586.1395576361223.JavaMail.zimbra@redhat.com>
	<97397536.195664.1395578177826.JavaMail.zimbra@redhat.com>
	<88455682.196005.1395578475613.JavaMail.zimbra@redhat.com>
	<1273090446.4104448.1395581728349.JavaMail.zimbra@redhat.com>
	<1574832625.5835647.1395583297184.JavaMail.zimbra@redhat.com>
	<532EEC15.40200@redhat.com>
Message-ID: <264602714.5845955.1395585367886.JavaMail.zimbra@redhat.com>



Thanks, 
Gilad.

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>, "Eli Mesika" <emesika at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, March 23, 2014 4:13:41 PM
> Subject: Re: [Engine-devel] Share Your Thoughts
> 
> On 03/23/2014 04:01 PM, Gilad Chaplik wrote:
> >
> >
> > Thanks,
> > Gilad.
> >
> > ----- Original Message -----
> >> From: "Omer Frenkel" <ofrenkel at redhat.com>
> >> To: "Eli Mesika" <emesika at redhat.com>
> >> Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "engine-devel"
> >> <engine-devel at ovirt.org>
> >> Sent: Sunday, March 23, 2014 3:35:28 PM
> >> Subject: Re: [Engine-devel] Share Your Thoughts
> >>
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Eli Mesika" <emesika at redhat.com>
> >>> To: "Gilad Chaplik" <gchaplik at redhat.com>
> >>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>> Sent: Sunday, March 23, 2014 2:41:15 PM
> >>> Subject: Re: [Engine-devel] Share Your Thoughts
> >>>
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Eli Mesika" <emesika at redhat.com>
> >>>> To: "Gilad Chaplik" <gchaplik at redhat.com>
> >>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>> Sent: Sunday, March 23, 2014 2:36:17 PM
> >>>> Subject: Re: [Engine-devel] Share Your Thoughts
> >>>>
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Gilad Chaplik" <gchaplik at redhat.com>
> >>>>> To: "engine-devel" <engine-devel at ovirt.org>
> >>>>> Sent: Sunday, March 23, 2014 2:06:01 PM
> >>>>> Subject: [Engine-devel] Share Your Thoughts
> >>>>>
> >>>>> Dear Devel Community Members,
> >>>>>
> >>>>> We are having a small discussion on patch:
> >>>>> http://gerrit.ovirt.org/#/c/25633/,
> >>>>> bug 1065753 - "Maintenance operations on a VM would ask for an optional
> >>>>> reason" (adding a note to stop/shutdown VM, that will be cleared when
> >>>>> the
> >>>>> VM
> >>>>> go up).
> >>>>>
> >>>>> The proposed solution is to add a free text field in the VM entity, and
> >>>>> to
> >>>>> update it in command's parameters (StopVmParmas.. etc.).
> >>>>>
> >>>>> I think slightly different, my alternative is to enhance the current
> >>>>> free
> >>>>> text (comment field) into XML, and allow to add multiple comments that
> >>>>> include types.
> >>>>> You are welcome to read more about it in the patch's comments.
> >>>>>
> >>>>> Thoughts?
> >>>>
> >>>> I suggest a third approach
> >>>> We are logging here a reason for a user/admin operation
> >>>> The natural place for such information is the audit log and not the VM
> >>>> tables.
> >>>> I think that the audit log messages related for the stop/shutdown
> >>>> commands
> >>>> should be enhanced to include a {REASON} field then the command itself
> >>>> will
> >>>> replace this value in the message with the one given by the user and we
> >>>> are
> >>>> done.
> >>>> Again, the required information is a pure logging issue, therefor I
> >>>> suggest
> >>>> to put this information in the correct place for it, there is no point
> >>>> in
> >>>> saving any logging messages in any entity table.
> >>>>
> >>>> Technically:
> >>>> 1) The option for giving a reason should be configurable (per Cluster if
> >>>> I
> >>>> look at Arthur comment in the BZ)
> >>>> 2) If the option is on than any stop/shutdown will ask for reason and
> >>>> sent
> >>>> it
> >>>> in the command parameters
> >>> than=>then
> >>>> 3) If the command succeed and got a non-empty reason , it will set the
> >>>> reason
> >>>> in the command audit log message
> >>>>
> >>>
> >>> 4) We gain here additional advantage since we can :
> >>>     a) search for the reason using the search engine
> >>>     b) get the reason in the message text sent to us if we are subscribed
> >>>     for
> >>>     the VM stop/shotdown event ans using engine-notifier
> >>>
> >>>>
> >>>> Eli
> >>>>
> >>
> >> +1
> >> sounds like a good and simple idea
> >
> > +1, BUT this is completely a different feature, and more difficult (MUCH
> > more, if I may add).
> > IMHO we need both, lets start with the no-brainer.
> 
> AuditLog gets recycled after 30 days. the reason i stopped my VM may
> still be relevant.
> I would not make fields complex/composite. they need to be easily
> useable via the CLI for example.

I think we need multiple comments, so we need to think about the RESTful api anyhow.
I guess that next feature will be a reason for 'wipe after stop'/any other BE that needs reasoning.

> 
> >
> >>
> >>>>>
> >>>>> Thanks,
> >>>>> Gilad.
> >>>>> _______________________________________________
> >>>>> Engine-devel mailing list
> >>>>> Engine-devel at ovirt.org
> >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>
> >>>>
> >>> _______________________________________________
> >>> Engine-devel mailing list
> >>> Engine-devel at ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>
> >>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
> 


From rgolan at redhat.com  Sun Mar 23 14:42:39 2014
From: rgolan at redhat.com (Roy Golan)
Date: Sun, 23 Mar 2014 16:42:39 +0200
Subject: [Engine-devel] Share Your Thoughts
In-Reply-To: <532EEC15.40200@redhat.com>
References: <399982494.5798586.1395576361223.JavaMail.zimbra@redhat.com>
	<97397536.195664.1395578177826.JavaMail.zimbra@redhat.com>
	<88455682.196005.1395578475613.JavaMail.zimbra@redhat.com>
	<1273090446.4104448.1395581728349.JavaMail.zimbra@redhat.com>
	<1574832625.5835647.1395583297184.JavaMail.zimbra@redhat.com>
	<532EEC15.40200@redhat.com>
Message-ID: <532EF2DF.8040201@redhat.com>

On Sun 23 Mar 2014 04:13:41 PM IST, Itamar Heim wrote:
> On 03/23/2014 04:01 PM, Gilad Chaplik wrote:
>>
>>
>> Thanks,
>> Gilad.
>>
>> ----- Original Message -----
>>> From: "Omer Frenkel" <ofrenkel at redhat.com>
>>> To: "Eli Mesika" <emesika at redhat.com>
>>> Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "engine-devel"
>>> <engine-devel at ovirt.org>
>>> Sent: Sunday, March 23, 2014 3:35:28 PM
>>> Subject: Re: [Engine-devel] Share Your Thoughts
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Eli Mesika" <emesika at redhat.com>
>>>> To: "Gilad Chaplik" <gchaplik at redhat.com>
>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>> Sent: Sunday, March 23, 2014 2:41:15 PM
>>>> Subject: Re: [Engine-devel] Share Your Thoughts
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Eli Mesika" <emesika at redhat.com>
>>>>> To: "Gilad Chaplik" <gchaplik at redhat.com>
>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>>> Sent: Sunday, March 23, 2014 2:36:17 PM
>>>>> Subject: Re: [Engine-devel] Share Your Thoughts
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Gilad Chaplik" <gchaplik at redhat.com>
>>>>>> To: "engine-devel" <engine-devel at ovirt.org>
>>>>>> Sent: Sunday, March 23, 2014 2:06:01 PM
>>>>>> Subject: [Engine-devel] Share Your Thoughts
>>>>>>
>>>>>> Dear Devel Community Members,
>>>>>>
>>>>>> We are having a small discussion on patch:
>>>>>> http://gerrit.ovirt.org/#/c/25633/,
>>>>>> bug 1065753 - "Maintenance operations on a VM would ask for an
>>>>>> optional
>>>>>> reason" (adding a note to stop/shutdown VM, that will be cleared
>>>>>> when
>>>>>> the
>>>>>> VM
>>>>>> go up).
>>>>>>
>>>>>> The proposed solution is to add a free text field in the VM
>>>>>> entity, and
>>>>>> to
>>>>>> update it in command's parameters (StopVmParmas.. etc.).
>>>>>>
>>>>>> I think slightly different, my alternative is to enhance the current
>>>>>> free
>>>>>> text (comment field) into XML, and allow to add multiple comments
>>>>>> that
>>>>>> include types.
>>>>>> You are welcome to read more about it in the patch's comments.
>>>>>>
>>>>>> Thoughts?
>>>>>
>>>>> I suggest a third approach
>>>>> We are logging here a reason for a user/admin operation
>>>>> The natural place for such information is the audit log and not
>>>>> the VM
>>>>> tables.
>>>>> I think that the audit log messages related for the stop/shutdown
>>>>> commands
>>>>> should be enhanced to include a {REASON} field then the command
>>>>> itself
>>>>> will
>>>>> replace this value in the message with the one given by the user
>>>>> and we
>>>>> are
>>>>> done.
>>>>> Again, the required information is a pure logging issue, therefor I
>>>>> suggest
>>>>> to put this information in the correct place for it, there is no
>>>>> point in
>>>>> saving any logging messages in any entity table.
>>>>>
>>>>> Technically:
>>>>> 1) The option for giving a reason should be configurable (per
>>>>> Cluster if
>>>>> I
>>>>> look at Arthur comment in the BZ)
>>>>> 2) If the option is on than any stop/shutdown will ask for reason and
>>>>> sent
>>>>> it
>>>>> in the command parameters
>>>> than=>then
>>>>> 3) If the command succeed and got a non-empty reason , it will set
>>>>> the
>>>>> reason
>>>>> in the command audit log message
>>>>>
>>>>
>>>> 4) We gain here additional advantage since we can :
>>>>     a) search for the reason using the search engine
>>>>     b) get the reason in the message text sent to us if we are
>>>> subscribed
>>>>     for
>>>>     the VM stop/shotdown event ans using engine-notifier
>>>>
>>>>>
>>>>> Eli
>>>>>
>>>
>>> +1
>>> sounds like a good and simple idea
>>

+1 another reason is we should keep Vm dynamic as compact as possible. 
using dynamic to hold a shutdown reason is an abuse.

>> +1, BUT this is completely a different feature, and more difficult
>> (MUCH more, if I may add).
>> IMHO we need both, lets start with the no-brainer.
>
> AuditLog gets recycled after 30 days. the reason i stopped my VM may
> still be relevant.
> I would not make fields complex/composite. they need to be easily
> useable via the CLI for example.
>


>>
>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Gilad.
>>>>>> _______________________________________________
>>>>>> Engine-devel mailing list
>>>>>> Engine-devel at ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>
>>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel




From jenkins at ovirt.org  Sun Mar 23 18:26:37 2014
From: jenkins at ovirt.org (Jenkins ci oVirt Server)
Date: Sun, 23 Mar 2014 18:26:37 +0000 (GMT)
Subject: [Engine-devel] [oVirt jenkins] Weekly report on open tasks for
	ovirt-engine
Message-ID: <1111083779.1243.1395599204202.JavaMail.jenkins@jenkins.ovirt.org>

An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140323/6024047c/attachment.html>

From aditya.mamidwar at gmail.com  Mon Mar 24 12:11:01 2014
From: aditya.mamidwar at gmail.com (aditya mamidwar)
Date: Mon, 24 Mar 2014 17:41:01 +0530
Subject: [Engine-devel] php on jboss
Message-ID: <CA+pz52_sxqCc5EG19dsRK+qndvb4ftgXWShkBXHvMJsXr6iE7A@mail.gmail.com>

i need a php file to execute some bash scripts on the server, but when i
integrate the ui-plugin ot the ovirt portal, it does not find path to my
.php file.

I have the HTML where as .PHP residing in the same location, can someone
guide on uploading PHP files on JBOSS server, since ovirt runs on it..

if i want to run a PHP file, where should i save it?

-- 
-Aditya Mamidwar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140324/9b3a143f/attachment.html>

From gshereme at redhat.com  Mon Mar 24 12:19:05 2014
From: gshereme at redhat.com (Greg Sheremeta)
Date: Mon, 24 Mar 2014 08:19:05 -0400 (EDT)
Subject: [Engine-devel] [Users] php on jboss
In-Reply-To: <CA+pz52_sxqCc5EG19dsRK+qndvb4ftgXWShkBXHvMJsXr6iE7A@mail.gmail.com>
References: <CA+pz52_sxqCc5EG19dsRK+qndvb4ftgXWShkBXHvMJsXr6iE7A@mail.gmail.com>
Message-ID: <2079293891.2328461.1395663545655.JavaMail.zimbra@redhat.com>

JBoss doesn't execute PHP. 

You'll need to setup an alternate server to do this -- perhaps an Apache instance. 

Greg 

----- Original Message -----

> From: "aditya mamidwar" <aditya.mamidwar at gmail.com>
> To: engine-devel at ovirt.org, users at ovirt.org
> Sent: Monday, March 24, 2014 8:11:01 AM
> Subject: [Users] php on jboss

> i need a php file to execute some bash scripts on the server, but when i
> integrate the ui-plugin ot the ovirt portal, it does not find path to my
> .php file.

> I have the HTML where as .PHP residing in the same location, can someone
> guide on uploading PHP files on JBOSS server, since ovirt runs on it..

> if i want to run a PHP file, where should i save it?

> --
> -Aditya Mamidwar

> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140324/a301f231/attachment.html>

From gshereme at redhat.com  Mon Mar 24 12:39:20 2014
From: gshereme at redhat.com (Greg Sheremeta)
Date: Mon, 24 Mar 2014 08:39:20 -0400 (EDT)
Subject: [Engine-devel] [Users] php on jboss
In-Reply-To: <2079293891.2328461.1395663545655.JavaMail.zimbra@redhat.com>
References: <CA+pz52_sxqCc5EG19dsRK+qndvb4ftgXWShkBXHvMJsXr6iE7A@mail.gmail.com>
	<2079293891.2328461.1395663545655.JavaMail.zimbra@redhat.com>
Message-ID: <1595953605.2333352.1395664760813.JavaMail.zimbra@redhat.com>

I stand corrected: http://www.jboss.org/jbossweb/modules/php.html 

----- Original Message -----

> From: "Greg Sheremeta" <gshereme at redhat.com>
> To: "aditya mamidwar" <aditya.mamidwar at gmail.com>
> Cc: engine-devel at ovirt.org, users at ovirt.org
> Sent: Monday, March 24, 2014 8:19:05 AM
> Subject: Re: [Users] php on jboss

> JBoss doesn't execute PHP.

> You'll need to setup an alternate server to do this -- perhaps an Apache
> instance.

> Greg

> ----- Original Message -----

> > From: "aditya mamidwar" <aditya.mamidwar at gmail.com>
> 
> > To: engine-devel at ovirt.org, users at ovirt.org
> 
> > Sent: Monday, March 24, 2014 8:11:01 AM
> 
> > Subject: [Users] php on jboss
> 

> > i need a php file to execute some bash scripts on the server, but when i
> > integrate the ui-plugin ot the ovirt portal, it does not find path to my
> > .php file.
> 

> > I have the HTML where as .PHP residing in the same location, can someone
> > guide on uploading PHP files on JBOSS server, since ovirt runs on it..
> 

> > if i want to run a PHP file, where should i save it?
> 

> > --
> 
> > -Aditya Mamidwar
> 

> > _______________________________________________
> 
> > Users mailing list
> 
> > Users at ovirt.org
> 
> > http://lists.ovirt.org/mailman/listinfo/users
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140324/1da8e3e3/attachment.html>

From alitke at redhat.com  Mon Mar 24 12:43:26 2014
From: alitke at redhat.com (Adam Litke)
Date: Mon, 24 Mar 2014 08:43:26 -0400
Subject: [Engine-devel] Share Your Thoughts
In-Reply-To: <264602714.5845955.1395585367886.JavaMail.zimbra@redhat.com>
References: <399982494.5798586.1395576361223.JavaMail.zimbra@redhat.com>
	<97397536.195664.1395578177826.JavaMail.zimbra@redhat.com>
	<88455682.196005.1395578475613.JavaMail.zimbra@redhat.com>
	<1273090446.4104448.1395581728349.JavaMail.zimbra@redhat.com>
	<1574832625.5835647.1395583297184.JavaMail.zimbra@redhat.com>
	<532EEC15.40200@redhat.com>
	<264602714.5845955.1395585367886.JavaMail.zimbra@redhat.com>
Message-ID: <20140324124326.GB2769@redhat.com>

On 23/03/14 10:36 -0400, Gilad Chaplik wrote:
>> AuditLog gets recycled after 30 days. the reason i stopped my VM may
>> still be relevant.
>> I would not make fields complex/composite. they need to be easily
>> useable via the CLI for example.
>
>I think we need multiple comments, so we need to think about the RESTful api anyhow.
>I guess that next feature will be a reason for 'wipe after stop'/any other BE that needs reasoning.

What about a new DB table (maybe called Annotations) that takes a
business entity type, UUID, action type, timestamp, and reason string.
Then the shutdown reason could be entered as a new row in the DB.  It
can be kept as long as we want it and views can be adjusted to make
these fields searchable.

-- 
Adam Litke


From alitke at redhat.com  Mon Mar 24 13:00:20 2014
From: alitke at redhat.com (Adam Litke)
Date: Mon, 24 Mar 2014 09:00:20 -0400
Subject: [Engine-devel] Share Your Thoughts
In-Reply-To: <20140324124326.GB2769@redhat.com>
References: <399982494.5798586.1395576361223.JavaMail.zimbra@redhat.com>
	<97397536.195664.1395578177826.JavaMail.zimbra@redhat.com>
	<88455682.196005.1395578475613.JavaMail.zimbra@redhat.com>
	<1273090446.4104448.1395581728349.JavaMail.zimbra@redhat.com>
	<1574832625.5835647.1395583297184.JavaMail.zimbra@redhat.com>
	<532EEC15.40200@redhat.com>
	<264602714.5845955.1395585367886.JavaMail.zimbra@redhat.com>
	<20140324124326.GB2769@redhat.com>
Message-ID: <20140324130020.GC2769@redhat.com>

On 24/03/14 08:43 -0400, Adam Litke wrote:
>On 23/03/14 10:36 -0400, Gilad Chaplik wrote:
>>>AuditLog gets recycled after 30 days. the reason i stopped my VM may
>>>still be relevant.
>>>I would not make fields complex/composite. they need to be easily
>>>useable via the CLI for example.
>>
>>I think we need multiple comments, so we need to think about the RESTful api anyhow.
>>I guess that next feature will be a reason for 'wipe after stop'/any other BE that needs reasoning.
>
>What about a new DB table (maybe called Annotations) that takes a
>business entity type, UUID, action type, timestamp, and reason string.
>Then the shutdown reason could be entered as a new row in the DB.  It
>can be kept as long as we want it and views can be adjusted to make
>these fields searchable.

I forgot to mention that this idea would make it simple to annotate
the reason for moving a host into maintenance mode as well (or any
other state change annotations we would want to make in the future).

-- 
Adam Litke


From alonbl at redhat.com  Mon Mar 24 13:23:39 2014
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 24 Mar 2014 09:23:39 -0400 (EDT)
Subject: [Engine-devel] [Users] php on jboss
In-Reply-To: <20140324131857.BA87C124F@mail.linuxland.de>
References: <CA+pz52_sxqCc5EG19dsRK+qndvb4ftgXWShkBXHvMJsXr6iE7A@mail.gmail.com>
	<20140324131857.BA87C124F@mail.linuxland.de>
Message-ID: <668513031.2350470.1395667419532.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Ren? Koch" <rkoch at linuxland.at>
> To: "aditya mamidwar" <aditya.mamidwar at gmail.com>
> Cc: engine-devel at ovirt.org, users at ovirt.org
> Sent: Monday, March 24, 2014 3:18:56 PM
> Subject: Re: [Users] php on jboss
> 
> Hi,
> 
> On 03/24/2014 01:11 PM, aditya mamidwar wrote:
> >
> > i need a php file to execute some bash scripts on the server, but when i
> > integrate the ui-plugin ot the ovirt portal, it does not find path to my
> > .php file.
> >
> > I have the HTML where as .PHP residing in the same location, can someone
> > guide on uploading PHP files on JBOSS server, since ovirt runs on it..
> 
> oVirt uses both - JBoss and Apache. You should place your PHP file in
> html dir of Apache, not JBoss.
> 
> >
> > if i want to run a PHP file, where should i save it?
> 
> Just save it to /var/www/html, which is the default location for your
> Apache webserver and install PHP module.

I missed this thread.

You can put custom files under /usr/share/ovirt-engine/files it will be available for you at: http://<>/ovirt-engine/files

Of course we do not support cgi-bin but plain files... but it may address your needs.

Please make sure you have your own subdirectory under files, so no conflicts.

> 
> You should be able to browse to http://ovirt/myfile.php. If not, you
> exclude the path in Apache vhost configuration file ovirt-engine.conf:
> ProxyPass /myfile.php !
> 
> Hope this helps,
> Rene
> 
> 
> >
> > --
> > -Aditya Mamidwar
> >
> >
> > _______________________________________________
> > Users mailing list
> > Users at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
> >
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 


From jbelka at redhat.com  Mon Mar 24 13:32:40 2014
From: jbelka at redhat.com (Jiri Belka)
Date: Mon, 24 Mar 2014 14:32:40 +0100
Subject: [Engine-devel] [Users] php on jboss
In-Reply-To: <668513031.2350470.1395667419532.JavaMail.zimbra@redhat.com>
References: <CA+pz52_sxqCc5EG19dsRK+qndvb4ftgXWShkBXHvMJsXr6iE7A@mail.gmail.com>
	<20140324131857.BA87C124F@mail.linuxland.de>
	<668513031.2350470.1395667419532.JavaMail.zimbra@redhat.com>
Message-ID: <20140324143240.066c1080.jbelka@redhat.com>

On Mon, 24 Mar 2014 09:23:39 -0400 (EDT)
Alon Bar-Lev <alonbl at redhat.com> wrote:

> You can put custom files under /usr/share/ovirt-engine/files it will be available for you at: http://<>/ovirt-engine/files

unix-style nitpicking...

hier(7):

       /usr   This  directory is usually mounted from a separate
       partition.  It should hold only sharable, read-only data, so
       that it can be mounted by various machines running Linux.

> Of course we do not support cgi-bin but plain files... but it may address your needs.
> 
> Please make sure you have your own subdirectory under files, so no conflicts.

j.


From alonbl at redhat.com  Mon Mar 24 13:34:58 2014
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 24 Mar 2014 09:34:58 -0400 (EDT)
Subject: [Engine-devel] [Users] php on jboss
In-Reply-To: <20140324143240.066c1080.jbelka@redhat.com>
References: <CA+pz52_sxqCc5EG19dsRK+qndvb4ftgXWShkBXHvMJsXr6iE7A@mail.gmail.com>
	<20140324131857.BA87C124F@mail.linuxland.de>
	<668513031.2350470.1395667419532.JavaMail.zimbra@redhat.com>
	<20140324143240.066c1080.jbelka@redhat.com>
Message-ID: <560274359.2356624.1395668098605.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Jiri Belka" <jbelka at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Ren? Koch" <rkoch at linuxland.at>, engine-devel at ovirt.org, "aditya mamidwar" <aditya.mamidwar at gmail.com>,
> users at ovirt.org
> Sent: Monday, March 24, 2014 3:32:40 PM
> Subject: Re: [Users] php on jboss
> 
> On Mon, 24 Mar 2014 09:23:39 -0400 (EDT)
> Alon Bar-Lev <alonbl at redhat.com> wrote:
> 
> > You can put custom files under /usr/share/ovirt-engine/files it will be
> > available for you at: http://<>/ovirt-engine/files
> 
> unix-style nitpicking...
> 
> hier(7):
> 
>        /usr   This  directory is usually mounted from a separate
>        partition.  It should hold only sharable, read-only data, so
>        that it can be mounted by various machines running Linux.
> 

So?
Why can't html, images and such be placed there?

> > Of course we do not support cgi-bin but plain files... but it may address
> > your needs.
> > 
> > Please make sure you have your own subdirectory under files, so no
> > conflicts.
> 
> j.
> 


From gchaplik at redhat.com  Mon Mar 24 13:41:46 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Mon, 24 Mar 2014 09:41:46 -0400 (EDT)
Subject: [Engine-devel] Share Your Thoughts
In-Reply-To: <20140324130020.GC2769@redhat.com>
References: <399982494.5798586.1395576361223.JavaMail.zimbra@redhat.com>
	<88455682.196005.1395578475613.JavaMail.zimbra@redhat.com>
	<1273090446.4104448.1395581728349.JavaMail.zimbra@redhat.com>
	<1574832625.5835647.1395583297184.JavaMail.zimbra@redhat.com>
	<532EEC15.40200@redhat.com>
	<264602714.5845955.1395585367886.JavaMail.zimbra@redhat.com>
	<20140324124326.GB2769@redhat.com>
	<20140324130020.GC2769@redhat.com>
Message-ID: <1031778470.6464682.1395668506924.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Adam Litke" <alitke at redhat.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, March 24, 2014 3:00:20 PM
> Subject: Re: [Engine-devel] Share Your Thoughts
> 
> On 24/03/14 08:43 -0400, Adam Litke wrote:
> >On 23/03/14 10:36 -0400, Gilad Chaplik wrote:
> >>>AuditLog gets recycled after 30 days. the reason i stopped my VM may
> >>>still be relevant.
> >>>I would not make fields complex/composite. they need to be easily
> >>>useable via the CLI for example.
> >>
> >>I think we need multiple comments, so we need to think about the RESTful
> >>api anyhow.
> >>I guess that next feature will be a reason for 'wipe after stop'/any other
> >>BE that needs reasoning.
> >
> >What about a new DB table (maybe called Annotations) that takes a
> >business entity type, UUID, action type, timestamp, and reason string.
> >Then the shutdown reason could be entered as a new row in the DB.  It
> >can be kept as long as we want it and views can be adjusted to make
> >these fields searchable.
> 
> I forgot to mention that this idea would make it simple to annotate
> the reason for moving a host into maintenance mode as well (or any
> other state change annotations we would want to make in the future).
> 

Hi Adam,

Sorry for not being clear enough, the change of the comment free-text field should be an infra one, 
and can be applied for all other comment fields, we will start with VM because it's required for now, and reuse the same code for other entities when needed.
I've discusses with Eli off-line and he came up with the same idea as yours (great minds think alike ;) - it's not just in advertising).
Personally, I think it's an overhead for now, there no problem adding it later, and it's quite simple actually.

3 comments:
* I think Eli's solution is nice to have but not complete. gave +1 because I thought it's a bigger feature that what he wants (a simple write to log), because in order to meet the RFE/bug 's requirements with logging, we need to pin the audit log into the entity itself (flag the entity according to audit log), IMHO logging isn't good enough UX-wise.
* Regarding Itamar's comment:
   1) Is this field is a tech preview? if not, we can still support strings in that field as well.
   2) Saving XML will allow us to get the RESTful API out of the box (just need to format it according to requested user's presentation).
   3) We can add the types as part of the API.
   4) Did someone say custom properties sheet in REST? :-)
* Regarding the cluster level config (requested in the bug, and implemented in the patch), if we are going on it, we need a separate thread on it (and I'm -1 on it, btw), a simple checkbox 'do not show this textbox/message again' in browser's local-data will do the trick.

Thanks, 
Gilad.

> --
> Adam Litke
> 



From rnori at redhat.com  Mon Mar 24 14:11:32 2014
From: rnori at redhat.com (Ravi Nori)
Date: Mon, 24 Mar 2014 10:11:32 -0400
Subject: [Engine-devel] Share Your Thoughts
In-Reply-To: <88455682.196005.1395578475613.JavaMail.zimbra@redhat.com>
References: <399982494.5798586.1395576361223.JavaMail.zimbra@redhat.com>
	<97397536.195664.1395578177826.JavaMail.zimbra@redhat.com>
	<88455682.196005.1395578475613.JavaMail.zimbra@redhat.com>
Message-ID: <53303D14.8050405@redhat.com>

On 03/23/2014 08:41 AM, Eli Mesika wrote:
>
> ----- Original Message -----
>> From: "Eli Mesika" <emesika at redhat.com>
>> To: "Gilad Chaplik" <gchaplik at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Sunday, March 23, 2014 2:36:17 PM
>> Subject: Re: [Engine-devel] Share Your Thoughts
>>
>>
>>
>> ----- Original Message -----
>>> From: "Gilad Chaplik" <gchaplik at redhat.com>
>>> To: "engine-devel" <engine-devel at ovirt.org>
>>> Sent: Sunday, March 23, 2014 2:06:01 PM
>>> Subject: [Engine-devel] Share Your Thoughts
>>>
>>> Dear Devel Community Members,
>>>
>>> We are having a small discussion on patch:
>>> http://gerrit.ovirt.org/#/c/25633/,
>>> bug 1065753 - "Maintenance operations on a VM would ask for an optional
>>> reason" (adding a note to stop/shutdown VM, that will be cleared when the
>>> VM
>>> go up).
>>>
>>> The proposed solution is to add a free text field in the VM entity, and to
>>> update it in command's parameters (StopVmParmas.. etc.).
>>>
>>> I think slightly different, my alternative is to enhance the current free
>>> text (comment field) into XML, and allow to add multiple comments that
>>> include types.
>>> You are welcome to read more about it in the patch's comments.
>>>
>>> Thoughts?
>> I suggest a third approach
>> We are logging here a reason for a user/admin operation
>> The natural place for such information is the audit log and not the VM
>> tables.
>> I think that the audit log messages related for the stop/shutdown commands
>> should be enhanced to include a {REASON} field then the command itself will
>> replace this value in the message with the one given by the user and we are
>> done.
>> Again, the required information is a pure logging issue, therefor I suggest
>> to put this information in the correct place for it, there is no point in
>> saving any logging messages in any entity table.
>>
>> Technically:
>> 1) The option for giving a reason should be configurable (per Cluster if I
>> look at Arthur comment in the BZ)
>> 2) If the option is on than any stop/shutdown will ask for reason and sent it
>> in the command parameters
> than=>then
>> 3) If the command succeed and got a non-empty reason , it will set the reason
>> in the command audit log message
>>
> 4) We gain here additional advantage since we can :
>     a) search for the reason using the search engine
>     b) get the reason in the message text sent to us if we are subscribed for the VM stop/shotdown event ans using engine-notifier

#1 thru #4 have already been implemented in the current patch.

>> Eli
>>
>>> Thanks,
>>> Gilad.
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From gchaplik at redhat.com  Mon Mar 24 15:28:02 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Mon, 24 Mar 2014 11:28:02 -0400 (EDT)
Subject: [Engine-devel] REST API - where did bookmarks go?
In-Reply-To: <113223800.17954619.1394623639126.JavaMail.zimbra@redhat.com>
References: <281801554.17527047.1394561704228.JavaMail.zimbra@redhat.com>
	<531F546B.8050104@redhat.com>
	<113223800.17954619.1394623639126.JavaMail.zimbra@redhat.com>
Message-ID: <1326606294.6546859.1395674882071.JavaMail.zimbra@redhat.com>

Hi Guys,

Why we need bookmarks in API? a single liner that points out to another single liner?
I know that we need it for 'UI over REST' migration, but...
IMHO bookmarks should be saved in client side, maybe inject the search string in the url, and get 'real' bookmarks/favorites... I don't know :-)

Thanks, 
Gilad.

----- Original Message -----
> From: "Vojtech Szocs" <vszocs at redhat.com>
> To: "Juan Hernandez" <jhernand at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, March 12, 2014 1:27:19 PM
> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> 
> 
> 
> ----- Original Message -----
> > From: "Juan Hernandez" <jhernand at redhat.com>
> > To: "Vojtech Szocs" <vszocs at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>
> > Cc: "Einav Cohen" <ecohen at redhat.com>
> > Sent: Tuesday, March 11, 2014 7:22:35 PM
> > Subject: Re: REST API - where did bookmarks go?
> > 
> > On 03/11/2014 07:15 PM, Vojtech Szocs wrote:
> > > Hi guys,
> > > 
> > > as part of prototyping new JavaScript binding for oVirt REST API,
> > > we chose a couple of business entities (resources) to experiment
> > > with.
> > > 
> > > I just realized that requesting /ovirt-engine/api doesn't return
> > > any information about bookmarks. Where did bookmarks go? Is it
> > > possible to manage bookmarks through REST API?
> > > 
> > > Note: WebAdmin currently gets bookmarks through GWT RPC by calling
> > > GetAllBookmarksQuery. Bookmark seems like proper backend business
> > > entity (with DAO and everything) so it should be exposed also via
> > > REST API.. or am I missing something?
> > > 
> > > Thanks,
> > > Vojtech
> > > 
> > 
> > The didn't go anywhere, just never existed in the API. Please open a RFE
> > to add them.
> 
> Thanks, Juan. The RFE is here:
> 
>   https://bugzilla.redhat.com/1075556
> 
> > 
> > --
> > Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> > 3?D, 28016 Madrid, Spain
> > Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L.
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>


From ecohen at redhat.com  Mon Mar 24 15:38:33 2014
From: ecohen at redhat.com (Einav Cohen)
Date: Mon, 24 Mar 2014 11:38:33 -0400 (EDT)
Subject: [Engine-devel] REST API - where did bookmarks go?
In-Reply-To: <1326606294.6546859.1395674882071.JavaMail.zimbra@redhat.com>
References: <281801554.17527047.1394561704228.JavaMail.zimbra@redhat.com>
	<531F546B.8050104@redhat.com>
	<113223800.17954619.1394623639126.JavaMail.zimbra@redhat.com>
	<1326606294.6546859.1395674882071.JavaMail.zimbra@redhat.com>
Message-ID: <331384667.4697967.1395675513966.JavaMail.zimbra@redhat.com>

Hi Gilad, "client-side Bookmarks" is a great suggestion, however it 
is a (non-related) RFE, which may be implemented instead of, or in 
addition to, the already-existing server-side Bookmarks.

[keep in mind that server-side bookmarks allow you to add bookmarks 
that may be used by other users; it is also a feature that exists 
for a long time in oVirt, so need to think a little bit before 
removing it]

As long as we have server-side Bookmarks (i.e. as long as Bookmark 
is an engine-managed business entity), they need to be exposed via 
the REST API. 

----
Thanks,
Einav

----- Original Message -----
> From: "Gilad Chaplik" <gchaplik at redhat.com>
> To: "Vojtech Szocs" <vszocs at redhat.com>
> Cc: "Juan Hernandez" <jhernand at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, March 24, 2014 11:28:02 AM
> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> 
> Hi Guys,
> 
> Why we need bookmarks in API? a single liner that points out to another
> single liner?
> I know that we need it for 'UI over REST' migration, but...
> IMHO bookmarks should be saved in client side, maybe inject the search string
> in the url, and get 'real' bookmarks/favorites... I don't know :-)
> 
> Thanks,
> Gilad.
> 
> ----- Original Message -----
> > From: "Vojtech Szocs" <vszocs at redhat.com>
> > To: "Juan Hernandez" <jhernand at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Wednesday, March 12, 2014 1:27:19 PM
> > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Juan Hernandez" <jhernand at redhat.com>
> > > To: "Vojtech Szocs" <vszocs at redhat.com>, "engine-devel"
> > > <engine-devel at ovirt.org>
> > > Cc: "Einav Cohen" <ecohen at redhat.com>
> > > Sent: Tuesday, March 11, 2014 7:22:35 PM
> > > Subject: Re: REST API - where did bookmarks go?
> > > 
> > > On 03/11/2014 07:15 PM, Vojtech Szocs wrote:
> > > > Hi guys,
> > > > 
> > > > as part of prototyping new JavaScript binding for oVirt REST API,
> > > > we chose a couple of business entities (resources) to experiment
> > > > with.
> > > > 
> > > > I just realized that requesting /ovirt-engine/api doesn't return
> > > > any information about bookmarks. Where did bookmarks go? Is it
> > > > possible to manage bookmarks through REST API?
> > > > 
> > > > Note: WebAdmin currently gets bookmarks through GWT RPC by calling
> > > > GetAllBookmarksQuery. Bookmark seems like proper backend business
> > > > entity (with DAO and everything) so it should be exposed also via
> > > > REST API.. or am I missing something?
> > > > 
> > > > Thanks,
> > > > Vojtech
> > > > 
> > > 
> > > The didn't go anywhere, just never existed in the API. Please open a RFE
> > > to add them.
> > 
> > Thanks, Juan. The RFE is here:
> > 
> >   https://bugzilla.redhat.com/1075556
> > 
> > > 
> > > --
> > > Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> > > 3?D, 28016 Madrid, Spain
> > > Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L.
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>


From gchaplik at redhat.com  Mon Mar 24 15:46:04 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Mon, 24 Mar 2014 11:46:04 -0400 (EDT)
Subject: [Engine-devel] REST API - where did bookmarks go?
In-Reply-To: <331384667.4697967.1395675513966.JavaMail.zimbra@redhat.com>
References: <281801554.17527047.1394561704228.JavaMail.zimbra@redhat.com>
	<531F546B.8050104@redhat.com>
	<113223800.17954619.1394623639126.JavaMail.zimbra@redhat.com>
	<1326606294.6546859.1395674882071.JavaMail.zimbra@redhat.com>
	<331384667.4697967.1395675513966.JavaMail.zimbra@redhat.com>
Message-ID: <2057224886.6564344.1395675964488.JavaMail.zimbra@redhat.com>

Hi Einav,

I agree with every word. also thought about it, that's why I wrote a possible solution.
Not sure we need to design the RESTful API according to UI's needs (add features in this case).



Thanks, 
Gilad.


----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>
> Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Juan Hernandez" <jhernand at redhat.com>, "engine-devel"
> <engine-devel at ovirt.org>
> Sent: Monday, March 24, 2014 5:38:33 PM
> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> 
> Hi Gilad, "client-side Bookmarks" is a great suggestion, however it
> is a (non-related) RFE, which may be implemented instead of, or in
> addition to, the already-existing server-side Bookmarks.
> 
> [keep in mind that server-side bookmarks allow you to add bookmarks
> that may be used by other users; it is also a feature that exists
> for a long time in oVirt, so need to think a little bit before
> removing it]
> 
> As long as we have server-side Bookmarks (i.e. as long as Bookmark
> is an engine-managed business entity), they need to be exposed via
> the REST API.
> 
> ----
> Thanks,
> Einav
> 
> ----- Original Message -----
> > From: "Gilad Chaplik" <gchaplik at redhat.com>
> > To: "Vojtech Szocs" <vszocs at redhat.com>
> > Cc: "Juan Hernandez" <jhernand at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>
> > Sent: Monday, March 24, 2014 11:28:02 AM
> > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > 
> > Hi Guys,
> > 
> > Why we need bookmarks in API? a single liner that points out to another
> > single liner?
> > I know that we need it for 'UI over REST' migration, but...
> > IMHO bookmarks should be saved in client side, maybe inject the search
> > string
> > in the url, and get 'real' bookmarks/favorites... I don't know :-)
> > 
> > Thanks,
> > Gilad.
> > 
> > ----- Original Message -----
> > > From: "Vojtech Szocs" <vszocs at redhat.com>
> > > To: "Juan Hernandez" <jhernand at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Wednesday, March 12, 2014 1:27:19 PM
> > > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Juan Hernandez" <jhernand at redhat.com>
> > > > To: "Vojtech Szocs" <vszocs at redhat.com>, "engine-devel"
> > > > <engine-devel at ovirt.org>
> > > > Cc: "Einav Cohen" <ecohen at redhat.com>
> > > > Sent: Tuesday, March 11, 2014 7:22:35 PM
> > > > Subject: Re: REST API - where did bookmarks go?
> > > > 
> > > > On 03/11/2014 07:15 PM, Vojtech Szocs wrote:
> > > > > Hi guys,
> > > > > 
> > > > > as part of prototyping new JavaScript binding for oVirt REST API,
> > > > > we chose a couple of business entities (resources) to experiment
> > > > > with.
> > > > > 
> > > > > I just realized that requesting /ovirt-engine/api doesn't return
> > > > > any information about bookmarks. Where did bookmarks go? Is it
> > > > > possible to manage bookmarks through REST API?
> > > > > 
> > > > > Note: WebAdmin currently gets bookmarks through GWT RPC by calling
> > > > > GetAllBookmarksQuery. Bookmark seems like proper backend business
> > > > > entity (with DAO and everything) so it should be exposed also via
> > > > > REST API.. or am I missing something?
> > > > > 
> > > > > Thanks,
> > > > > Vojtech
> > > > > 
> > > > 
> > > > The didn't go anywhere, just never existed in the API. Please open a
> > > > RFE
> > > > to add them.
> > > 
> > > Thanks, Juan. The RFE is here:
> > > 
> > >   https://bugzilla.redhat.com/1075556
> > > 
> > > > 
> > > > --
> > > > Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> > > > 3?D, 28016 Madrid, Spain
> > > > Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat
> > > > S.L.
> > > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 


From ecohen at redhat.com  Mon Mar 24 15:55:20 2014
From: ecohen at redhat.com (Einav Cohen)
Date: Mon, 24 Mar 2014 11:55:20 -0400 (EDT)
Subject: [Engine-devel] REST API - where did bookmarks go?
In-Reply-To: <2057224886.6564344.1395675964488.JavaMail.zimbra@redhat.com>
References: <281801554.17527047.1394561704228.JavaMail.zimbra@redhat.com>
	<531F546B.8050104@redhat.com>
	<113223800.17954619.1394623639126.JavaMail.zimbra@redhat.com>
	<1326606294.6546859.1395674882071.JavaMail.zimbra@redhat.com>
	<331384667.4697967.1395675513966.JavaMail.zimbra@redhat.com>
	<2057224886.6564344.1395675964488.JavaMail.zimbra@redhat.com>
Message-ID: <909577589.4712957.1395676520667.JavaMail.zimbra@redhat.com>

> ----- Original Message -----
> From: "Gilad Chaplik" <gchaplik at redhat.com>
> Sent: Monday, March 24, 2014 11:46:04 AM
> 
> Hi Einav,
> 
> I agree with every word. also thought about it, that's why I wrote a possible
> solution.
> Not sure we need to design the RESTful API according to UI's needs (add
> features in this case).

the REST API should not be designed according to UI's needs - but the REST API 
should allow to retrieve all engine-managed business entities. Bookmarks is one 
of them. 
There is a chance that creating Bookmarks as an engine-managed business-entity 
in the first place was a bad design decision, but they are there now, as managed 
business-entities, and as such - should be exposed via the REST API. 

> 
> 
> 
> Thanks,
> Gilad.
> 
> 
> ----- Original Message -----
> > From: "Einav Cohen" <ecohen at redhat.com>
> > To: "Gilad Chaplik" <gchaplik at redhat.com>
> > Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Juan Hernandez"
> > <jhernand at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>
> > Sent: Monday, March 24, 2014 5:38:33 PM
> > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > 
> > Hi Gilad, "client-side Bookmarks" is a great suggestion, however it
> > is a (non-related) RFE, which may be implemented instead of, or in
> > addition to, the already-existing server-side Bookmarks.
> > 
> > [keep in mind that server-side bookmarks allow you to add bookmarks
> > that may be used by other users; it is also a feature that exists
> > for a long time in oVirt, so need to think a little bit before
> > removing it]
> > 
> > As long as we have server-side Bookmarks (i.e. as long as Bookmark
> > is an engine-managed business entity), they need to be exposed via
> > the REST API.
> > 
> > ----
> > Thanks,
> > Einav
> > 
> > ----- Original Message -----
> > > From: "Gilad Chaplik" <gchaplik at redhat.com>
> > > To: "Vojtech Szocs" <vszocs at redhat.com>
> > > Cc: "Juan Hernandez" <jhernand at redhat.com>, "engine-devel"
> > > <engine-devel at ovirt.org>
> > > Sent: Monday, March 24, 2014 11:28:02 AM
> > > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > > 
> > > Hi Guys,
> > > 
> > > Why we need bookmarks in API? a single liner that points out to another
> > > single liner?
> > > I know that we need it for 'UI over REST' migration, but...
> > > IMHO bookmarks should be saved in client side, maybe inject the search
> > > string
> > > in the url, and get 'real' bookmarks/favorites... I don't know :-)
> > > 
> > > Thanks,
> > > Gilad.
> > > 
> > > ----- Original Message -----
> > > > From: "Vojtech Szocs" <vszocs at redhat.com>
> > > > To: "Juan Hernandez" <jhernand at redhat.com>
> > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Wednesday, March 12, 2014 1:27:19 PM
> > > > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Juan Hernandez" <jhernand at redhat.com>
> > > > > To: "Vojtech Szocs" <vszocs at redhat.com>, "engine-devel"
> > > > > <engine-devel at ovirt.org>
> > > > > Cc: "Einav Cohen" <ecohen at redhat.com>
> > > > > Sent: Tuesday, March 11, 2014 7:22:35 PM
> > > > > Subject: Re: REST API - where did bookmarks go?
> > > > > 
> > > > > On 03/11/2014 07:15 PM, Vojtech Szocs wrote:
> > > > > > Hi guys,
> > > > > > 
> > > > > > as part of prototyping new JavaScript binding for oVirt REST API,
> > > > > > we chose a couple of business entities (resources) to experiment
> > > > > > with.
> > > > > > 
> > > > > > I just realized that requesting /ovirt-engine/api doesn't return
> > > > > > any information about bookmarks. Where did bookmarks go? Is it
> > > > > > possible to manage bookmarks through REST API?
> > > > > > 
> > > > > > Note: WebAdmin currently gets bookmarks through GWT RPC by calling
> > > > > > GetAllBookmarksQuery. Bookmark seems like proper backend business
> > > > > > entity (with DAO and everything) so it should be exposed also via
> > > > > > REST API.. or am I missing something?
> > > > > > 
> > > > > > Thanks,
> > > > > > Vojtech
> > > > > > 
> > > > > 
> > > > > The didn't go anywhere, just never existed in the API. Please open a
> > > > > RFE
> > > > > to add them.
> > > > 
> > > > Thanks, Juan. The RFE is here:
> > > > 
> > > >   https://bugzilla.redhat.com/1075556
> > > > 
> > > > > 
> > > > > --
> > > > > Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> > > > > 3?D, 28016 Madrid, Spain
> > > > > Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat
> > > > > S.L.
> > > > > 
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
> 


From gchaplik at redhat.com  Mon Mar 24 15:58:01 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Mon, 24 Mar 2014 11:58:01 -0400 (EDT)
Subject: [Engine-devel] REST API - where did bookmarks go?
In-Reply-To: <909577589.4712957.1395676520667.JavaMail.zimbra@redhat.com>
References: <281801554.17527047.1394561704228.JavaMail.zimbra@redhat.com>
	<531F546B.8050104@redhat.com>
	<113223800.17954619.1394623639126.JavaMail.zimbra@redhat.com>
	<1326606294.6546859.1395674882071.JavaMail.zimbra@redhat.com>
	<331384667.4697967.1395675513966.JavaMail.zimbra@redhat.com>
	<2057224886.6564344.1395675964488.JavaMail.zimbra@redhat.com>
	<909577589.4712957.1395676520667.JavaMail.zimbra@redhat.com>
Message-ID: <1644238559.6571028.1395676681349.JavaMail.zimbra@redhat.com>

So iiuc, we are going to develop a known obsolete feature :-) ?
Can we break it in 4.0?

Thanks, 
Gilad.


----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>
> Cc: "Juan Hernandez" <jhernand at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, March 24, 2014 5:55:20 PM
> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> 
> > ----- Original Message -----
> > From: "Gilad Chaplik" <gchaplik at redhat.com>
> > Sent: Monday, March 24, 2014 11:46:04 AM
> > 
> > Hi Einav,
> > 
> > I agree with every word. also thought about it, that's why I wrote a
> > possible
> > solution.
> > Not sure we need to design the RESTful API according to UI's needs (add
> > features in this case).
> 
> the REST API should not be designed according to UI's needs - but the REST
> API
> should allow to retrieve all engine-managed business entities. Bookmarks is
> one
> of them.
> There is a chance that creating Bookmarks as an engine-managed
> business-entity
> in the first place was a bad design decision, but they are there now, as
> managed
> business-entities, and as such - should be exposed via the REST API.
> 
> > 
> > 
> > 
> > Thanks,
> > Gilad.
> > 
> > 
> > ----- Original Message -----
> > > From: "Einav Cohen" <ecohen at redhat.com>
> > > To: "Gilad Chaplik" <gchaplik at redhat.com>
> > > Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Juan Hernandez"
> > > <jhernand at redhat.com>, "engine-devel"
> > > <engine-devel at ovirt.org>
> > > Sent: Monday, March 24, 2014 5:38:33 PM
> > > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > > 
> > > Hi Gilad, "client-side Bookmarks" is a great suggestion, however it
> > > is a (non-related) RFE, which may be implemented instead of, or in
> > > addition to, the already-existing server-side Bookmarks.
> > > 
> > > [keep in mind that server-side bookmarks allow you to add bookmarks
> > > that may be used by other users; it is also a feature that exists
> > > for a long time in oVirt, so need to think a little bit before
> > > removing it]
> > > 
> > > As long as we have server-side Bookmarks (i.e. as long as Bookmark
> > > is an engine-managed business entity), they need to be exposed via
> > > the REST API.
> > > 
> > > ----
> > > Thanks,
> > > Einav
> > > 
> > > ----- Original Message -----
> > > > From: "Gilad Chaplik" <gchaplik at redhat.com>
> > > > To: "Vojtech Szocs" <vszocs at redhat.com>
> > > > Cc: "Juan Hernandez" <jhernand at redhat.com>, "engine-devel"
> > > > <engine-devel at ovirt.org>
> > > > Sent: Monday, March 24, 2014 11:28:02 AM
> > > > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > > > 
> > > > Hi Guys,
> > > > 
> > > > Why we need bookmarks in API? a single liner that points out to another
> > > > single liner?
> > > > I know that we need it for 'UI over REST' migration, but...
> > > > IMHO bookmarks should be saved in client side, maybe inject the search
> > > > string
> > > > in the url, and get 'real' bookmarks/favorites... I don't know :-)
> > > > 
> > > > Thanks,
> > > > Gilad.
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Vojtech Szocs" <vszocs at redhat.com>
> > > > > To: "Juan Hernandez" <jhernand at redhat.com>
> > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > Sent: Wednesday, March 12, 2014 1:27:19 PM
> > > > > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Juan Hernandez" <jhernand at redhat.com>
> > > > > > To: "Vojtech Szocs" <vszocs at redhat.com>, "engine-devel"
> > > > > > <engine-devel at ovirt.org>
> > > > > > Cc: "Einav Cohen" <ecohen at redhat.com>
> > > > > > Sent: Tuesday, March 11, 2014 7:22:35 PM
> > > > > > Subject: Re: REST API - where did bookmarks go?
> > > > > > 
> > > > > > On 03/11/2014 07:15 PM, Vojtech Szocs wrote:
> > > > > > > Hi guys,
> > > > > > > 
> > > > > > > as part of prototyping new JavaScript binding for oVirt REST API,
> > > > > > > we chose a couple of business entities (resources) to experiment
> > > > > > > with.
> > > > > > > 
> > > > > > > I just realized that requesting /ovirt-engine/api doesn't return
> > > > > > > any information about bookmarks. Where did bookmarks go? Is it
> > > > > > > possible to manage bookmarks through REST API?
> > > > > > > 
> > > > > > > Note: WebAdmin currently gets bookmarks through GWT RPC by
> > > > > > > calling
> > > > > > > GetAllBookmarksQuery. Bookmark seems like proper backend business
> > > > > > > entity (with DAO and everything) so it should be exposed also via
> > > > > > > REST API.. or am I missing something?
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > Vojtech
> > > > > > > 
> > > > > > 
> > > > > > The didn't go anywhere, just never existed in the API. Please open
> > > > > > a
> > > > > > RFE
> > > > > > to add them.
> > > > > 
> > > > > Thanks, Juan. The RFE is here:
> > > > > 
> > > > >   https://bugzilla.redhat.com/1075556
> > > > > 
> > > > > > 
> > > > > > --
> > > > > > Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3,
> > > > > > planta
> > > > > > 3?D, 28016 Madrid, Spain
> > > > > > Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red
> > > > > > Hat
> > > > > > S.L.
> > > > > > 
> > > > > _______________________________________________
> > > > > Engine-devel mailing list
> > > > > Engine-devel at ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > >
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> > 
> > 
> 


From vszocs at redhat.com  Mon Mar 24 16:12:55 2014
From: vszocs at redhat.com (Vojtech Szocs)
Date: Mon, 24 Mar 2014 12:12:55 -0400 (EDT)
Subject: [Engine-devel] REST API - where did bookmarks go?
In-Reply-To: <331384667.4697967.1395675513966.JavaMail.zimbra@redhat.com>
References: <281801554.17527047.1394561704228.JavaMail.zimbra@redhat.com>
	<531F546B.8050104@redhat.com>
	<113223800.17954619.1394623639126.JavaMail.zimbra@redhat.com>
	<1326606294.6546859.1395674882071.JavaMail.zimbra@redhat.com>
	<331384667.4697967.1395675513966.JavaMail.zimbra@redhat.com>
Message-ID: <153805865.4616427.1395677575464.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>
> Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Juan Hernandez" <jhernand at redhat.com>, "engine-devel"
> <engine-devel at ovirt.org>
> Sent: Monday, March 24, 2014 4:38:33 PM
> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> 
> Hi Gilad, "client-side Bookmarks" is a great suggestion

+1

My understanding is that bookmarks are just named search queries, whose main advantage is the ability to put (potentially complex) search query behind a friendly-named bookmark.

Bookmarks exist in WebAdmin GUI (as it provides the search panel) and as far as I can tell, there are no permissions involved when dealing with bookmarks via BookmarkDAO.

So it seems that bookmark data could be persisted locally (in browser) via HTML local storage. However, the disadvantage (as mentioned by Einav below) is per-browser persistence, instead of today's per-Engine persistence. If we are OK with per-browser persistence of bookmarks, I'm for it.

> however it is a (non-related) RFE, which may be implemented instead of, or in
> addition to, the already-existing server-side Bookmarks.
> 
> [keep in mind that server-side bookmarks allow you to add bookmarks
> that may be used by other users; it is also a feature that exists
> for a long time in oVirt, so need to think a little bit before
> removing it]
> 
> As long as we have server-side Bookmarks (i.e. as long as Bookmark
> is an engine-managed business entity), they need to be exposed via
> the REST API.

Indeed, this was the reason behind RFE https://bugzilla.redhat.com/1075556 - even after migrating to REST API, bookmark functionality should be preserved. (But we can also decide if we want to change that, if necessary.)

> 
> ----
> Thanks,
> Einav
> 
> ----- Original Message -----
> > From: "Gilad Chaplik" <gchaplik at redhat.com>
> > To: "Vojtech Szocs" <vszocs at redhat.com>
> > Cc: "Juan Hernandez" <jhernand at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>
> > Sent: Monday, March 24, 2014 11:28:02 AM
> > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > 
> > Hi Guys,
> > 
> > Why we need bookmarks in API? a single liner that points out to another
> > single liner?
> > I know that we need it for 'UI over REST' migration, but...
> > IMHO bookmarks should be saved in client side, maybe inject the search
> > string
> > in the url, and get 'real' bookmarks/favorites... I don't know :-)

Actually, the ability to put search string in WebAdmin URL is a *VERY* interesting idea!

For example:
- assume you login and land on WebAdmin.html#vms
- you change URL to WebAdmin.html#search;q=Host%3A%20name%20%3D%20asdasd [*]
- WebAdmin applies requested search string, performs place change to WebAdmin.html#hosts

[*] encodeURIComponent('Host: name = asdasd')

Not only would users be able to navigate WebAdmin through search string in URL, but UI plugins could do this too via some plugin API function.

Gilad, could you please create RFE for this? (it's a very good idea, IMHO)

> > 
> > Thanks,
> > Gilad.
> > 
> > ----- Original Message -----
> > > From: "Vojtech Szocs" <vszocs at redhat.com>
> > > To: "Juan Hernandez" <jhernand at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Wednesday, March 12, 2014 1:27:19 PM
> > > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Juan Hernandez" <jhernand at redhat.com>
> > > > To: "Vojtech Szocs" <vszocs at redhat.com>, "engine-devel"
> > > > <engine-devel at ovirt.org>
> > > > Cc: "Einav Cohen" <ecohen at redhat.com>
> > > > Sent: Tuesday, March 11, 2014 7:22:35 PM
> > > > Subject: Re: REST API - where did bookmarks go?
> > > > 
> > > > On 03/11/2014 07:15 PM, Vojtech Szocs wrote:
> > > > > Hi guys,
> > > > > 
> > > > > as part of prototyping new JavaScript binding for oVirt REST API,
> > > > > we chose a couple of business entities (resources) to experiment
> > > > > with.
> > > > > 
> > > > > I just realized that requesting /ovirt-engine/api doesn't return
> > > > > any information about bookmarks. Where did bookmarks go? Is it
> > > > > possible to manage bookmarks through REST API?
> > > > > 
> > > > > Note: WebAdmin currently gets bookmarks through GWT RPC by calling
> > > > > GetAllBookmarksQuery. Bookmark seems like proper backend business
> > > > > entity (with DAO and everything) so it should be exposed also via
> > > > > REST API.. or am I missing something?
> > > > > 
> > > > > Thanks,
> > > > > Vojtech
> > > > > 
> > > > 
> > > > The didn't go anywhere, just never existed in the API. Please open a
> > > > RFE
> > > > to add them.
> > > 
> > > Thanks, Juan. The RFE is here:
> > > 
> > >   https://bugzilla.redhat.com/1075556
> > > 
> > > > 
> > > > --
> > > > Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> > > > 3?D, 28016 Madrid, Spain
> > > > Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat
> > > > S.L.
> > > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 


From ecohen at redhat.com  Mon Mar 24 16:17:36 2014
From: ecohen at redhat.com (Einav Cohen)
Date: Mon, 24 Mar 2014 12:17:36 -0400 (EDT)
Subject: [Engine-devel] REST API - where did bookmarks go?
In-Reply-To: <1644238559.6571028.1395676681349.JavaMail.zimbra@redhat.com>
References: <281801554.17527047.1394561704228.JavaMail.zimbra@redhat.com>
	<531F546B.8050104@redhat.com>
	<113223800.17954619.1394623639126.JavaMail.zimbra@redhat.com>
	<1326606294.6546859.1395674882071.JavaMail.zimbra@redhat.com>
	<331384667.4697967.1395675513966.JavaMail.zimbra@redhat.com>
	<2057224886.6564344.1395675964488.JavaMail.zimbra@redhat.com>
	<909577589.4712957.1395676520667.JavaMail.zimbra@redhat.com>
	<1644238559.6571028.1395676681349.JavaMail.zimbra@redhat.com>
Message-ID: <1150637523.4733046.1395677856862.JavaMail.zimbra@redhat.com>

> ----- Original Message -----
> From: "Gilad Chaplik" <gchaplik at redhat.com>
> Sent: Monday, March 24, 2014 11:58:01 AM
> 
> So iiuc, we are going to develop a known obsolete feature :-) ?
> Can we break it in 4.0?

well, since they were never exposed, we can also decide that we are 
not implementing them at all, but this means that we are losing the 
server-side bookmarks once we move the GUI to work with the REST-API. 
question is if everyone are OK with that...

to be on the safe side and to not lose any functionality/data, I 
suggest to add them to the REST API, and for 4.0 - discuss whether 
they should be removed (and possibly replaced with client-side 
bookmarks in the GUI)

> 
> Thanks,
> Gilad.
> 
> 
> ----- Original Message -----
> > From: "Einav Cohen" <ecohen at redhat.com>
> > To: "Gilad Chaplik" <gchaplik at redhat.com>
> > Cc: "Juan Hernandez" <jhernand at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>
> > Sent: Monday, March 24, 2014 5:55:20 PM
> > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > 
> > > ----- Original Message -----
> > > From: "Gilad Chaplik" <gchaplik at redhat.com>
> > > Sent: Monday, March 24, 2014 11:46:04 AM
> > > 
> > > Hi Einav,
> > > 
> > > I agree with every word. also thought about it, that's why I wrote a
> > > possible
> > > solution.
> > > Not sure we need to design the RESTful API according to UI's needs (add
> > > features in this case).
> > 
> > the REST API should not be designed according to UI's needs - but the REST
> > API
> > should allow to retrieve all engine-managed business entities. Bookmarks is
> > one
> > of them.
> > There is a chance that creating Bookmarks as an engine-managed
> > business-entity
> > in the first place was a bad design decision, but they are there now, as
> > managed
> > business-entities, and as such - should be exposed via the REST API.
> > 
> > > 
> > > 
> > > 
> > > Thanks,
> > > Gilad.
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Einav Cohen" <ecohen at redhat.com>
> > > > To: "Gilad Chaplik" <gchaplik at redhat.com>
> > > > Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Juan Hernandez"
> > > > <jhernand at redhat.com>, "engine-devel"
> > > > <engine-devel at ovirt.org>
> > > > Sent: Monday, March 24, 2014 5:38:33 PM
> > > > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > > > 
> > > > Hi Gilad, "client-side Bookmarks" is a great suggestion, however it
> > > > is a (non-related) RFE, which may be implemented instead of, or in
> > > > addition to, the already-existing server-side Bookmarks.
> > > > 
> > > > [keep in mind that server-side bookmarks allow you to add bookmarks
> > > > that may be used by other users; it is also a feature that exists
> > > > for a long time in oVirt, so need to think a little bit before
> > > > removing it]
> > > > 
> > > > As long as we have server-side Bookmarks (i.e. as long as Bookmark
> > > > is an engine-managed business entity), they need to be exposed via
> > > > the REST API.
> > > > 
> > > > ----
> > > > Thanks,
> > > > Einav
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Gilad Chaplik" <gchaplik at redhat.com>
> > > > > To: "Vojtech Szocs" <vszocs at redhat.com>
> > > > > Cc: "Juan Hernandez" <jhernand at redhat.com>, "engine-devel"
> > > > > <engine-devel at ovirt.org>
> > > > > Sent: Monday, March 24, 2014 11:28:02 AM
> > > > > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > > > > 
> > > > > Hi Guys,
> > > > > 
> > > > > Why we need bookmarks in API? a single liner that points out to
> > > > > another
> > > > > single liner?
> > > > > I know that we need it for 'UI over REST' migration, but...
> > > > > IMHO bookmarks should be saved in client side, maybe inject the
> > > > > search
> > > > > string
> > > > > in the url, and get 'real' bookmarks/favorites... I don't know :-)
> > > > > 
> > > > > Thanks,
> > > > > Gilad.
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Vojtech Szocs" <vszocs at redhat.com>
> > > > > > To: "Juan Hernandez" <jhernand at redhat.com>
> > > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > Sent: Wednesday, March 12, 2014 1:27:19 PM
> > > > > > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Juan Hernandez" <jhernand at redhat.com>
> > > > > > > To: "Vojtech Szocs" <vszocs at redhat.com>, "engine-devel"
> > > > > > > <engine-devel at ovirt.org>
> > > > > > > Cc: "Einav Cohen" <ecohen at redhat.com>
> > > > > > > Sent: Tuesday, March 11, 2014 7:22:35 PM
> > > > > > > Subject: Re: REST API - where did bookmarks go?
> > > > > > > 
> > > > > > > On 03/11/2014 07:15 PM, Vojtech Szocs wrote:
> > > > > > > > Hi guys,
> > > > > > > > 
> > > > > > > > as part of prototyping new JavaScript binding for oVirt REST
> > > > > > > > API,
> > > > > > > > we chose a couple of business entities (resources) to
> > > > > > > > experiment
> > > > > > > > with.
> > > > > > > > 
> > > > > > > > I just realized that requesting /ovirt-engine/api doesn't
> > > > > > > > return
> > > > > > > > any information about bookmarks. Where did bookmarks go? Is it
> > > > > > > > possible to manage bookmarks through REST API?
> > > > > > > > 
> > > > > > > > Note: WebAdmin currently gets bookmarks through GWT RPC by
> > > > > > > > calling
> > > > > > > > GetAllBookmarksQuery. Bookmark seems like proper backend
> > > > > > > > business
> > > > > > > > entity (with DAO and everything) so it should be exposed also
> > > > > > > > via
> > > > > > > > REST API.. or am I missing something?
> > > > > > > > 
> > > > > > > > Thanks,
> > > > > > > > Vojtech
> > > > > > > > 
> > > > > > > 
> > > > > > > The didn't go anywhere, just never existed in the API. Please
> > > > > > > open
> > > > > > > a
> > > > > > > RFE
> > > > > > > to add them.
> > > > > > 
> > > > > > Thanks, Juan. The RFE is here:
> > > > > > 
> > > > > >   https://bugzilla.redhat.com/1075556
> > > > > > 
> > > > > > > 
> > > > > > > --
> > > > > > > Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3,
> > > > > > > planta
> > > > > > > 3?D, 28016 Madrid, Spain
> > > > > > > Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red
> > > > > > > Hat
> > > > > > > S.L.
> > > > > > > 
> > > > > > _______________________________________________
> > > > > > Engine-devel mailing list
> > > > > > Engine-devel at ovirt.org
> > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > >
> > > > > _______________________________________________
> > > > > Engine-devel mailing list
> > > > > Engine-devel at ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > >
> > > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > > 
> > > 
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
> 


From vszocs at redhat.com  Mon Mar 24 16:32:25 2014
From: vszocs at redhat.com (Vojtech Szocs)
Date: Mon, 24 Mar 2014 12:32:25 -0400 (EDT)
Subject: [Engine-devel] REST API - where did bookmarks go?
In-Reply-To: <1644238559.6571028.1395676681349.JavaMail.zimbra@redhat.com>
References: <281801554.17527047.1394561704228.JavaMail.zimbra@redhat.com>
	<531F546B.8050104@redhat.com>
	<113223800.17954619.1394623639126.JavaMail.zimbra@redhat.com>
	<1326606294.6546859.1395674882071.JavaMail.zimbra@redhat.com>
	<331384667.4697967.1395675513966.JavaMail.zimbra@redhat.com>
	<2057224886.6564344.1395675964488.JavaMail.zimbra@redhat.com>
	<909577589.4712957.1395676520667.JavaMail.zimbra@redhat.com>
	<1644238559.6571028.1395676681349.JavaMail.zimbra@redhat.com>
Message-ID: <1272249036.4625589.1395678745733.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Gilad Chaplik" <gchaplik at redhat.com>
> To: "Einav Cohen" <ecohen at redhat.com>
> Cc: "Juan Hernandez" <jhernand at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, March 24, 2014 4:58:01 PM
> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> 
> So iiuc, we are going to develop a known obsolete feature :-) ?
> Can we break it in 4.0?

We should consider whether bookmarks should be persisted/managed through Engine, or whether they should be handled by clients instead (and Engine wouldn't care about them). Sounds more like design decision to me.

> 
> Thanks,
> Gilad.
> 
> 
> ----- Original Message -----
> > From: "Einav Cohen" <ecohen at redhat.com>
> > To: "Gilad Chaplik" <gchaplik at redhat.com>
> > Cc: "Juan Hernandez" <jhernand at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>
> > Sent: Monday, March 24, 2014 5:55:20 PM
> > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > 
> > > ----- Original Message -----
> > > From: "Gilad Chaplik" <gchaplik at redhat.com>
> > > Sent: Monday, March 24, 2014 11:46:04 AM
> > > 
> > > Hi Einav,
> > > 
> > > I agree with every word. also thought about it, that's why I wrote a
> > > possible
> > > solution.
> > > Not sure we need to design the RESTful API according to UI's needs (add
> > > features in this case).
> > 
> > the REST API should not be designed according to UI's needs - but the REST
> > API
> > should allow to retrieve all engine-managed business entities. Bookmarks is
> > one
> > of them.
> > There is a chance that creating Bookmarks as an engine-managed
> > business-entity
> > in the first place was a bad design decision, but they are there now, as
> > managed
> > business-entities, and as such - should be exposed via the REST API.
> > 
> > > 
> > > 
> > > 
> > > Thanks,
> > > Gilad.
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Einav Cohen" <ecohen at redhat.com>
> > > > To: "Gilad Chaplik" <gchaplik at redhat.com>
> > > > Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Juan Hernandez"
> > > > <jhernand at redhat.com>, "engine-devel"
> > > > <engine-devel at ovirt.org>
> > > > Sent: Monday, March 24, 2014 5:38:33 PM
> > > > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > > > 
> > > > Hi Gilad, "client-side Bookmarks" is a great suggestion, however it
> > > > is a (non-related) RFE, which may be implemented instead of, or in
> > > > addition to, the already-existing server-side Bookmarks.
> > > > 
> > > > [keep in mind that server-side bookmarks allow you to add bookmarks
> > > > that may be used by other users; it is also a feature that exists
> > > > for a long time in oVirt, so need to think a little bit before
> > > > removing it]
> > > > 
> > > > As long as we have server-side Bookmarks (i.e. as long as Bookmark
> > > > is an engine-managed business entity), they need to be exposed via
> > > > the REST API.
> > > > 
> > > > ----
> > > > Thanks,
> > > > Einav
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Gilad Chaplik" <gchaplik at redhat.com>
> > > > > To: "Vojtech Szocs" <vszocs at redhat.com>
> > > > > Cc: "Juan Hernandez" <jhernand at redhat.com>, "engine-devel"
> > > > > <engine-devel at ovirt.org>
> > > > > Sent: Monday, March 24, 2014 11:28:02 AM
> > > > > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > > > > 
> > > > > Hi Guys,
> > > > > 
> > > > > Why we need bookmarks in API? a single liner that points out to
> > > > > another
> > > > > single liner?
> > > > > I know that we need it for 'UI over REST' migration, but...
> > > > > IMHO bookmarks should be saved in client side, maybe inject the
> > > > > search
> > > > > string
> > > > > in the url, and get 'real' bookmarks/favorites... I don't know :-)
> > > > > 
> > > > > Thanks,
> > > > > Gilad.
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Vojtech Szocs" <vszocs at redhat.com>
> > > > > > To: "Juan Hernandez" <jhernand at redhat.com>
> > > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > Sent: Wednesday, March 12, 2014 1:27:19 PM
> > > > > > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Juan Hernandez" <jhernand at redhat.com>
> > > > > > > To: "Vojtech Szocs" <vszocs at redhat.com>, "engine-devel"
> > > > > > > <engine-devel at ovirt.org>
> > > > > > > Cc: "Einav Cohen" <ecohen at redhat.com>
> > > > > > > Sent: Tuesday, March 11, 2014 7:22:35 PM
> > > > > > > Subject: Re: REST API - where did bookmarks go?
> > > > > > > 
> > > > > > > On 03/11/2014 07:15 PM, Vojtech Szocs wrote:
> > > > > > > > Hi guys,
> > > > > > > > 
> > > > > > > > as part of prototyping new JavaScript binding for oVirt REST
> > > > > > > > API,
> > > > > > > > we chose a couple of business entities (resources) to
> > > > > > > > experiment
> > > > > > > > with.
> > > > > > > > 
> > > > > > > > I just realized that requesting /ovirt-engine/api doesn't
> > > > > > > > return
> > > > > > > > any information about bookmarks. Where did bookmarks go? Is it
> > > > > > > > possible to manage bookmarks through REST API?
> > > > > > > > 
> > > > > > > > Note: WebAdmin currently gets bookmarks through GWT RPC by
> > > > > > > > calling
> > > > > > > > GetAllBookmarksQuery. Bookmark seems like proper backend
> > > > > > > > business
> > > > > > > > entity (with DAO and everything) so it should be exposed also
> > > > > > > > via
> > > > > > > > REST API.. or am I missing something?
> > > > > > > > 
> > > > > > > > Thanks,
> > > > > > > > Vojtech
> > > > > > > > 
> > > > > > > 
> > > > > > > The didn't go anywhere, just never existed in the API. Please
> > > > > > > open
> > > > > > > a
> > > > > > > RFE
> > > > > > > to add them.
> > > > > > 
> > > > > > Thanks, Juan. The RFE is here:
> > > > > > 
> > > > > >   https://bugzilla.redhat.com/1075556
> > > > > > 
> > > > > > > 
> > > > > > > --
> > > > > > > Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3,
> > > > > > > planta
> > > > > > > 3?D, 28016 Madrid, Spain
> > > > > > > Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red
> > > > > > > Hat
> > > > > > > S.L.
> > > > > > > 
> > > > > > _______________________________________________
> > > > > > Engine-devel mailing list
> > > > > > Engine-devel at ovirt.org
> > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > >
> > > > > _______________________________________________
> > > > > Engine-devel mailing list
> > > > > Engine-devel at ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > >
> > > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > > 
> > > 
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From jhernand at redhat.com  Mon Mar 24 16:33:49 2014
From: jhernand at redhat.com (Juan Hernandez)
Date: Mon, 24 Mar 2014 17:33:49 +0100
Subject: [Engine-devel] REST API - where did bookmarks go?
In-Reply-To: <1150637523.4733046.1395677856862.JavaMail.zimbra@redhat.com>
References: <281801554.17527047.1394561704228.JavaMail.zimbra@redhat.com>
	<531F546B.8050104@redhat.com>
	<113223800.17954619.1394623639126.JavaMail.zimbra@redhat.com>
	<1326606294.6546859.1395674882071.JavaMail.zimbra@redhat.com>
	<331384667.4697967.1395675513966.JavaMail.zimbra@redhat.com>
	<2057224886.6564344.1395675964488.JavaMail.zimbra@redhat.com>
	<909577589.4712957.1395676520667.JavaMail.zimbra@redhat.com>
	<1644238559.6571028.1395676681349.JavaMail.zimbra@redhat.com>
	<1150637523.4733046.1395677856862.JavaMail.zimbra@redhat.com>
Message-ID: <53305E6D.7010207@redhat.com>

On 03/24/2014 05:17 PM, Einav Cohen wrote:
>> ----- Original Message -----
>> From: "Gilad Chaplik" <gchaplik at redhat.com>
>> Sent: Monday, March 24, 2014 11:58:01 AM
>>
>> So iiuc, we are going to develop a known obsolete feature :-) ?
>> Can we break it in 4.0?
> 
> well, since they were never exposed, we can also decide that we are 
> not implementing them at all, but this means that we are losing the 
> server-side bookmarks once we move the GUI to work with the REST-API. 
> question is if everyone are OK with that...
> 
> to be on the safe side and to not lose any functionality/data, I 
> suggest to add them to the REST API, and for 4.0 - discuss whether 
> they should be removed (and possibly replaced with client-side 
> bookmarks in the GUI)
> 

Actually adding support for bookmarks has been targeted for 4.0, and
work is about to start (if not started yet).

Martin, please, don't start working on this till it is decided if we
will have or not the bookmarks in 4.0.

>>
>> Thanks,
>> Gilad.
>>
>>
>> ----- Original Message -----
>>> From: "Einav Cohen" <ecohen at redhat.com>
>>> To: "Gilad Chaplik" <gchaplik at redhat.com>
>>> Cc: "Juan Hernandez" <jhernand at redhat.com>, "engine-devel"
>>> <engine-devel at ovirt.org>
>>> Sent: Monday, March 24, 2014 5:55:20 PM
>>> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
>>>
>>>> ----- Original Message -----
>>>> From: "Gilad Chaplik" <gchaplik at redhat.com>
>>>> Sent: Monday, March 24, 2014 11:46:04 AM
>>>>
>>>> Hi Einav,
>>>>
>>>> I agree with every word. also thought about it, that's why I wrote a
>>>> possible
>>>> solution.
>>>> Not sure we need to design the RESTful API according to UI's needs (add
>>>> features in this case).
>>>
>>> the REST API should not be designed according to UI's needs - but the REST
>>> API
>>> should allow to retrieve all engine-managed business entities. Bookmarks is
>>> one
>>> of them.
>>> There is a chance that creating Bookmarks as an engine-managed
>>> business-entity
>>> in the first place was a bad design decision, but they are there now, as
>>> managed
>>> business-entities, and as such - should be exposed via the REST API.
>>>
>>>>
>>>>
>>>>
>>>> Thanks,
>>>> Gilad.
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Einav Cohen" <ecohen at redhat.com>
>>>>> To: "Gilad Chaplik" <gchaplik at redhat.com>
>>>>> Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Juan Hernandez"
>>>>> <jhernand at redhat.com>, "engine-devel"
>>>>> <engine-devel at ovirt.org>
>>>>> Sent: Monday, March 24, 2014 5:38:33 PM
>>>>> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
>>>>>
>>>>> Hi Gilad, "client-side Bookmarks" is a great suggestion, however it
>>>>> is a (non-related) RFE, which may be implemented instead of, or in
>>>>> addition to, the already-existing server-side Bookmarks.
>>>>>
>>>>> [keep in mind that server-side bookmarks allow you to add bookmarks
>>>>> that may be used by other users; it is also a feature that exists
>>>>> for a long time in oVirt, so need to think a little bit before
>>>>> removing it]
>>>>>
>>>>> As long as we have server-side Bookmarks (i.e. as long as Bookmark
>>>>> is an engine-managed business entity), they need to be exposed via
>>>>> the REST API.
>>>>>
>>>>> ----
>>>>> Thanks,
>>>>> Einav
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Gilad Chaplik" <gchaplik at redhat.com>
>>>>>> To: "Vojtech Szocs" <vszocs at redhat.com>
>>>>>> Cc: "Juan Hernandez" <jhernand at redhat.com>, "engine-devel"
>>>>>> <engine-devel at ovirt.org>
>>>>>> Sent: Monday, March 24, 2014 11:28:02 AM
>>>>>> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
>>>>>>
>>>>>> Hi Guys,
>>>>>>
>>>>>> Why we need bookmarks in API? a single liner that points out to
>>>>>> another
>>>>>> single liner?
>>>>>> I know that we need it for 'UI over REST' migration, but...
>>>>>> IMHO bookmarks should be saved in client side, maybe inject the
>>>>>> search
>>>>>> string
>>>>>> in the url, and get 'real' bookmarks/favorites... I don't know :-)
>>>>>>
>>>>>> Thanks,
>>>>>> Gilad.
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Vojtech Szocs" <vszocs at redhat.com>
>>>>>>> To: "Juan Hernandez" <jhernand at redhat.com>
>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>>>>> Sent: Wednesday, March 12, 2014 1:27:19 PM
>>>>>>> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Juan Hernandez" <jhernand at redhat.com>
>>>>>>>> To: "Vojtech Szocs" <vszocs at redhat.com>, "engine-devel"
>>>>>>>> <engine-devel at ovirt.org>
>>>>>>>> Cc: "Einav Cohen" <ecohen at redhat.com>
>>>>>>>> Sent: Tuesday, March 11, 2014 7:22:35 PM
>>>>>>>> Subject: Re: REST API - where did bookmarks go?
>>>>>>>>
>>>>>>>> On 03/11/2014 07:15 PM, Vojtech Szocs wrote:
>>>>>>>>> Hi guys,
>>>>>>>>>
>>>>>>>>> as part of prototyping new JavaScript binding for oVirt REST
>>>>>>>>> API,
>>>>>>>>> we chose a couple of business entities (resources) to
>>>>>>>>> experiment
>>>>>>>>> with.
>>>>>>>>>
>>>>>>>>> I just realized that requesting /ovirt-engine/api doesn't
>>>>>>>>> return
>>>>>>>>> any information about bookmarks. Where did bookmarks go? Is it
>>>>>>>>> possible to manage bookmarks through REST API?
>>>>>>>>>
>>>>>>>>> Note: WebAdmin currently gets bookmarks through GWT RPC by
>>>>>>>>> calling
>>>>>>>>> GetAllBookmarksQuery. Bookmark seems like proper backend
>>>>>>>>> business
>>>>>>>>> entity (with DAO and everything) so it should be exposed also
>>>>>>>>> via
>>>>>>>>> REST API.. or am I missing something?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Vojtech
>>>>>>>>>
>>>>>>>>
>>>>>>>> The didn't go anywhere, just never existed in the API. Please
>>>>>>>> open
>>>>>>>> a
>>>>>>>> RFE
>>>>>>>> to add them.
>>>>>>>
>>>>>>> Thanks, Juan. The RFE is here:
>>>>>>>
>>>>>>>   https://bugzilla.redhat.com/1075556
>>>>>>>


-- 
Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3?D, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L.


From mperina at redhat.com  Mon Mar 24 16:39:44 2014
From: mperina at redhat.com (Martin Perina)
Date: Mon, 24 Mar 2014 12:39:44 -0400 (EDT)
Subject: [Engine-devel] REST API - where did bookmarks go?
In-Reply-To: <53305E6D.7010207@redhat.com>
References: <281801554.17527047.1394561704228.JavaMail.zimbra@redhat.com>
	<1326606294.6546859.1395674882071.JavaMail.zimbra@redhat.com>
	<331384667.4697967.1395675513966.JavaMail.zimbra@redhat.com>
	<2057224886.6564344.1395675964488.JavaMail.zimbra@redhat.com>
	<909577589.4712957.1395676520667.JavaMail.zimbra@redhat.com>
	<1644238559.6571028.1395676681349.JavaMail.zimbra@redhat.com>
	<1150637523.4733046.1395677856862.JavaMail.zimbra@redhat.com>
	<53305E6D.7010207@redhat.com>
Message-ID: <1566149474.722782.1395679184226.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Juan Hernandez" <jhernand at redhat.com>
> To: "Einav Cohen" <ecohen at redhat.com>, "Gilad Chaplik" <gchaplik at redhat.com>, "Martin Perina" <mperina at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, March 24, 2014 5:33:49 PM
> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> 
> On 03/24/2014 05:17 PM, Einav Cohen wrote:
> >> ----- Original Message -----
> >> From: "Gilad Chaplik" <gchaplik at redhat.com>
> >> Sent: Monday, March 24, 2014 11:58:01 AM
> >>
> >> So iiuc, we are going to develop a known obsolete feature :-) ?
> >> Can we break it in 4.0?
> > 
> > well, since they were never exposed, we can also decide that we are
> > not implementing them at all, but this means that we are losing the
> > server-side bookmarks once we move the GUI to work with the REST-API.
> > question is if everyone are OK with that...
> > 
> > to be on the safe side and to not lose any functionality/data, I
> > suggest to add them to the REST API, and for 4.0 - discuss whether
> > they should be removed (and possibly replaced with client-side
> > bookmarks in the GUI)
> > 
> 
> Actually adding support for bookmarks has been targeted for 4.0, and
> work is about to start (if not started yet).
> 
> Martin, please, don't start working on this till it is decided if we
> will have or not the bookmarks in 4.0.

Ok, I will wait until decision is made.

> 
> >>
> >> Thanks,
> >> Gilad.
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Einav Cohen" <ecohen at redhat.com>
> >>> To: "Gilad Chaplik" <gchaplik at redhat.com>
> >>> Cc: "Juan Hernandez" <jhernand at redhat.com>, "engine-devel"
> >>> <engine-devel at ovirt.org>
> >>> Sent: Monday, March 24, 2014 5:55:20 PM
> >>> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> >>>
> >>>> ----- Original Message -----
> >>>> From: "Gilad Chaplik" <gchaplik at redhat.com>
> >>>> Sent: Monday, March 24, 2014 11:46:04 AM
> >>>>
> >>>> Hi Einav,
> >>>>
> >>>> I agree with every word. also thought about it, that's why I wrote a
> >>>> possible
> >>>> solution.
> >>>> Not sure we need to design the RESTful API according to UI's needs (add
> >>>> features in this case).
> >>>
> >>> the REST API should not be designed according to UI's needs - but the
> >>> REST
> >>> API
> >>> should allow to retrieve all engine-managed business entities. Bookmarks
> >>> is
> >>> one
> >>> of them.
> >>> There is a chance that creating Bookmarks as an engine-managed
> >>> business-entity
> >>> in the first place was a bad design decision, but they are there now, as
> >>> managed
> >>> business-entities, and as such - should be exposed via the REST API.
> >>>
> >>>>
> >>>>
> >>>>
> >>>> Thanks,
> >>>> Gilad.
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Einav Cohen" <ecohen at redhat.com>
> >>>>> To: "Gilad Chaplik" <gchaplik at redhat.com>
> >>>>> Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Juan Hernandez"
> >>>>> <jhernand at redhat.com>, "engine-devel"
> >>>>> <engine-devel at ovirt.org>
> >>>>> Sent: Monday, March 24, 2014 5:38:33 PM
> >>>>> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> >>>>>
> >>>>> Hi Gilad, "client-side Bookmarks" is a great suggestion, however it
> >>>>> is a (non-related) RFE, which may be implemented instead of, or in
> >>>>> addition to, the already-existing server-side Bookmarks.
> >>>>>
> >>>>> [keep in mind that server-side bookmarks allow you to add bookmarks
> >>>>> that may be used by other users; it is also a feature that exists
> >>>>> for a long time in oVirt, so need to think a little bit before
> >>>>> removing it]
> >>>>>
> >>>>> As long as we have server-side Bookmarks (i.e. as long as Bookmark
> >>>>> is an engine-managed business entity), they need to be exposed via
> >>>>> the REST API.
> >>>>>
> >>>>> ----
> >>>>> Thanks,
> >>>>> Einav
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Gilad Chaplik" <gchaplik at redhat.com>
> >>>>>> To: "Vojtech Szocs" <vszocs at redhat.com>
> >>>>>> Cc: "Juan Hernandez" <jhernand at redhat.com>, "engine-devel"
> >>>>>> <engine-devel at ovirt.org>
> >>>>>> Sent: Monday, March 24, 2014 11:28:02 AM
> >>>>>> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> >>>>>>
> >>>>>> Hi Guys,
> >>>>>>
> >>>>>> Why we need bookmarks in API? a single liner that points out to
> >>>>>> another
> >>>>>> single liner?
> >>>>>> I know that we need it for 'UI over REST' migration, but...
> >>>>>> IMHO bookmarks should be saved in client side, maybe inject the
> >>>>>> search
> >>>>>> string
> >>>>>> in the url, and get 'real' bookmarks/favorites... I don't know :-)
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Gilad.
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>>> From: "Vojtech Szocs" <vszocs at redhat.com>
> >>>>>>> To: "Juan Hernandez" <jhernand at redhat.com>
> >>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>>>>> Sent: Wednesday, March 12, 2014 1:27:19 PM
> >>>>>>> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> ----- Original Message -----
> >>>>>>>> From: "Juan Hernandez" <jhernand at redhat.com>
> >>>>>>>> To: "Vojtech Szocs" <vszocs at redhat.com>, "engine-devel"
> >>>>>>>> <engine-devel at ovirt.org>
> >>>>>>>> Cc: "Einav Cohen" <ecohen at redhat.com>
> >>>>>>>> Sent: Tuesday, March 11, 2014 7:22:35 PM
> >>>>>>>> Subject: Re: REST API - where did bookmarks go?
> >>>>>>>>
> >>>>>>>> On 03/11/2014 07:15 PM, Vojtech Szocs wrote:
> >>>>>>>>> Hi guys,
> >>>>>>>>>
> >>>>>>>>> as part of prototyping new JavaScript binding for oVirt REST
> >>>>>>>>> API,
> >>>>>>>>> we chose a couple of business entities (resources) to
> >>>>>>>>> experiment
> >>>>>>>>> with.
> >>>>>>>>>
> >>>>>>>>> I just realized that requesting /ovirt-engine/api doesn't
> >>>>>>>>> return
> >>>>>>>>> any information about bookmarks. Where did bookmarks go? Is it
> >>>>>>>>> possible to manage bookmarks through REST API?
> >>>>>>>>>
> >>>>>>>>> Note: WebAdmin currently gets bookmarks through GWT RPC by
> >>>>>>>>> calling
> >>>>>>>>> GetAllBookmarksQuery. Bookmark seems like proper backend
> >>>>>>>>> business
> >>>>>>>>> entity (with DAO and everything) so it should be exposed also
> >>>>>>>>> via
> >>>>>>>>> REST API.. or am I missing something?
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> Vojtech
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> The didn't go anywhere, just never existed in the API. Please
> >>>>>>>> open
> >>>>>>>> a
> >>>>>>>> RFE
> >>>>>>>> to add them.
> >>>>>>>
> >>>>>>> Thanks, Juan. The RFE is here:
> >>>>>>>
> >>>>>>>   https://bugzilla.redhat.com/1075556
> >>>>>>>
> 
> 
> --
> Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> 3?D, 28016 Madrid, Spain
> Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L.
> 


From vszocs at redhat.com  Mon Mar 24 16:40:37 2014
From: vszocs at redhat.com (Vojtech Szocs)
Date: Mon, 24 Mar 2014 12:40:37 -0400 (EDT)
Subject: [Engine-devel] REST API - where did bookmarks go?
In-Reply-To: <2057224886.6564344.1395675964488.JavaMail.zimbra@redhat.com>
References: <281801554.17527047.1394561704228.JavaMail.zimbra@redhat.com>
	<531F546B.8050104@redhat.com>
	<113223800.17954619.1394623639126.JavaMail.zimbra@redhat.com>
	<1326606294.6546859.1395674882071.JavaMail.zimbra@redhat.com>
	<331384667.4697967.1395675513966.JavaMail.zimbra@redhat.com>
	<2057224886.6564344.1395675964488.JavaMail.zimbra@redhat.com>
Message-ID: <1071197349.4627740.1395679237487.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Gilad Chaplik" <gchaplik at redhat.com>
> To: "Einav Cohen" <ecohen at redhat.com>
> Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Juan Hernandez" <jhernand at redhat.com>, "engine-devel"
> <engine-devel at ovirt.org>
> Sent: Monday, March 24, 2014 4:46:04 PM
> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> 
> Hi Einav,
> 
> I agree with every word. also thought about it, that's why I wrote a possible
> solution.
> Not sure we need to design the RESTful API according to UI's needs (add
> features in this case).

I think that API should accomodate general/common needs of its clients. After all, the usefulness of API can be measured by its usability from client's perspective.

At one extreme, API adapts to each specific client, which in turn bloats the API. At another extreme, API lives in isolated bubble and doesn't care for its clients. Each of these extremes is dangerous :)

> 
> 
> 
> Thanks,
> Gilad.
> 
> 
> ----- Original Message -----
> > From: "Einav Cohen" <ecohen at redhat.com>
> > To: "Gilad Chaplik" <gchaplik at redhat.com>
> > Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Juan Hernandez"
> > <jhernand at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>
> > Sent: Monday, March 24, 2014 5:38:33 PM
> > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > 
> > Hi Gilad, "client-side Bookmarks" is a great suggestion, however it
> > is a (non-related) RFE, which may be implemented instead of, or in
> > addition to, the already-existing server-side Bookmarks.
> > 
> > [keep in mind that server-side bookmarks allow you to add bookmarks
> > that may be used by other users; it is also a feature that exists
> > for a long time in oVirt, so need to think a little bit before
> > removing it]
> > 
> > As long as we have server-side Bookmarks (i.e. as long as Bookmark
> > is an engine-managed business entity), they need to be exposed via
> > the REST API.
> > 
> > ----
> > Thanks,
> > Einav
> > 
> > ----- Original Message -----
> > > From: "Gilad Chaplik" <gchaplik at redhat.com>
> > > To: "Vojtech Szocs" <vszocs at redhat.com>
> > > Cc: "Juan Hernandez" <jhernand at redhat.com>, "engine-devel"
> > > <engine-devel at ovirt.org>
> > > Sent: Monday, March 24, 2014 11:28:02 AM
> > > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > > 
> > > Hi Guys,
> > > 
> > > Why we need bookmarks in API? a single liner that points out to another
> > > single liner?
> > > I know that we need it for 'UI over REST' migration, but...
> > > IMHO bookmarks should be saved in client side, maybe inject the search
> > > string
> > > in the url, and get 'real' bookmarks/favorites... I don't know :-)
> > > 
> > > Thanks,
> > > Gilad.
> > > 
> > > ----- Original Message -----
> > > > From: "Vojtech Szocs" <vszocs at redhat.com>
> > > > To: "Juan Hernandez" <jhernand at redhat.com>
> > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Wednesday, March 12, 2014 1:27:19 PM
> > > > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Juan Hernandez" <jhernand at redhat.com>
> > > > > To: "Vojtech Szocs" <vszocs at redhat.com>, "engine-devel"
> > > > > <engine-devel at ovirt.org>
> > > > > Cc: "Einav Cohen" <ecohen at redhat.com>
> > > > > Sent: Tuesday, March 11, 2014 7:22:35 PM
> > > > > Subject: Re: REST API - where did bookmarks go?
> > > > > 
> > > > > On 03/11/2014 07:15 PM, Vojtech Szocs wrote:
> > > > > > Hi guys,
> > > > > > 
> > > > > > as part of prototyping new JavaScript binding for oVirt REST API,
> > > > > > we chose a couple of business entities (resources) to experiment
> > > > > > with.
> > > > > > 
> > > > > > I just realized that requesting /ovirt-engine/api doesn't return
> > > > > > any information about bookmarks. Where did bookmarks go? Is it
> > > > > > possible to manage bookmarks through REST API?
> > > > > > 
> > > > > > Note: WebAdmin currently gets bookmarks through GWT RPC by calling
> > > > > > GetAllBookmarksQuery. Bookmark seems like proper backend business
> > > > > > entity (with DAO and everything) so it should be exposed also via
> > > > > > REST API.. or am I missing something?
> > > > > > 
> > > > > > Thanks,
> > > > > > Vojtech
> > > > > > 
> > > > > 
> > > > > The didn't go anywhere, just never existed in the API. Please open a
> > > > > RFE
> > > > > to add them.
> > > > 
> > > > Thanks, Juan. The RFE is here:
> > > > 
> > > >   https://bugzilla.redhat.com/1075556
> > > > 
> > > > > 
> > > > > --
> > > > > Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> > > > > 3?D, 28016 Madrid, Spain
> > > > > Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat
> > > > > S.L.
> > > > > 
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > 
> 


From iheim at redhat.com  Mon Mar 24 22:17:48 2014
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 24 Mar 2014 18:17:48 -0400
Subject: [Engine-devel] REST API - where did bookmarks go?
In-Reply-To: <1071197349.4627740.1395679237487.JavaMail.zimbra@redhat.com>
References: <281801554.17527047.1394561704228.JavaMail.zimbra@redhat.com>	<531F546B.8050104@redhat.com>	<113223800.17954619.1394623639126.JavaMail.zimbra@redhat.com>	<1326606294.6546859.1395674882071.JavaMail.zimbra@redhat.com>	<331384667.4697967.1395675513966.JavaMail.zimbra@redhat.com>	<2057224886.6564344.1395675964488.JavaMail.zimbra@redhat.com>
	<1071197349.4627740.1395679237487.JavaMail.zimbra@redhat.com>
Message-ID: <5330AF0C.6010601@redhat.com>

On 03/24/2014 12:40 PM, Vojtech Szocs wrote:
>
>
> ----- Original Message -----
>> From: "Gilad Chaplik" <gchaplik at redhat.com>
>> To: "Einav Cohen" <ecohen at redhat.com>
>> Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Juan Hernandez" <jhernand at redhat.com>, "engine-devel"
>> <engine-devel at ovirt.org>
>> Sent: Monday, March 24, 2014 4:46:04 PM
>> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
>>
>> Hi Einav,
>>
>> I agree with every word. also thought about it, that's why I wrote a possible
>> solution.
>> Not sure we need to design the RESTful API according to UI's needs (add
>> features in this case).
>
> I think that API should accomodate general/common needs of its clients. After all, the usefulness of API can be measured by its usability from client's perspective.
>
> At one extreme, API adapts to each specific client, which in turn bloats the API. At another extreme, API lives in isolated bubble and doesn't care for its clients. Each of these extremes is dangerous :)

I find shared bookmarks useful.
i do actually think they should have had permissions:
- who can see my bookmarks
- who can share their bookmarks with others

>
>>
>>
>>
>> Thanks,
>> Gilad.
>>
>>
>> ----- Original Message -----
>>> From: "Einav Cohen" <ecohen at redhat.com>
>>> To: "Gilad Chaplik" <gchaplik at redhat.com>
>>> Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Juan Hernandez"
>>> <jhernand at redhat.com>, "engine-devel"
>>> <engine-devel at ovirt.org>
>>> Sent: Monday, March 24, 2014 5:38:33 PM
>>> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
>>>
>>> Hi Gilad, "client-side Bookmarks" is a great suggestion, however it
>>> is a (non-related) RFE, which may be implemented instead of, or in
>>> addition to, the already-existing server-side Bookmarks.
>>>
>>> [keep in mind that server-side bookmarks allow you to add bookmarks
>>> that may be used by other users; it is also a feature that exists
>>> for a long time in oVirt, so need to think a little bit before
>>> removing it]
>>>
>>> As long as we have server-side Bookmarks (i.e. as long as Bookmark
>>> is an engine-managed business entity), they need to be exposed via
>>> the REST API.
>>>
>>> ----
>>> Thanks,
>>> Einav
>>>
>>> ----- Original Message -----
>>>> From: "Gilad Chaplik" <gchaplik at redhat.com>
>>>> To: "Vojtech Szocs" <vszocs at redhat.com>
>>>> Cc: "Juan Hernandez" <jhernand at redhat.com>, "engine-devel"
>>>> <engine-devel at ovirt.org>
>>>> Sent: Monday, March 24, 2014 11:28:02 AM
>>>> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
>>>>
>>>> Hi Guys,
>>>>
>>>> Why we need bookmarks in API? a single liner that points out to another
>>>> single liner?
>>>> I know that we need it for 'UI over REST' migration, but...
>>>> IMHO bookmarks should be saved in client side, maybe inject the search
>>>> string
>>>> in the url, and get 'real' bookmarks/favorites... I don't know :-)
>>>>
>>>> Thanks,
>>>> Gilad.
>>>>
>>>> ----- Original Message -----
>>>>> From: "Vojtech Szocs" <vszocs at redhat.com>
>>>>> To: "Juan Hernandez" <jhernand at redhat.com>
>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>>> Sent: Wednesday, March 12, 2014 1:27:19 PM
>>>>> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Juan Hernandez" <jhernand at redhat.com>
>>>>>> To: "Vojtech Szocs" <vszocs at redhat.com>, "engine-devel"
>>>>>> <engine-devel at ovirt.org>
>>>>>> Cc: "Einav Cohen" <ecohen at redhat.com>
>>>>>> Sent: Tuesday, March 11, 2014 7:22:35 PM
>>>>>> Subject: Re: REST API - where did bookmarks go?
>>>>>>
>>>>>> On 03/11/2014 07:15 PM, Vojtech Szocs wrote:
>>>>>>> Hi guys,
>>>>>>>
>>>>>>> as part of prototyping new JavaScript binding for oVirt REST API,
>>>>>>> we chose a couple of business entities (resources) to experiment
>>>>>>> with.
>>>>>>>
>>>>>>> I just realized that requesting /ovirt-engine/api doesn't return
>>>>>>> any information about bookmarks. Where did bookmarks go? Is it
>>>>>>> possible to manage bookmarks through REST API?
>>>>>>>
>>>>>>> Note: WebAdmin currently gets bookmarks through GWT RPC by calling
>>>>>>> GetAllBookmarksQuery. Bookmark seems like proper backend business
>>>>>>> entity (with DAO and everything) so it should be exposed also via
>>>>>>> REST API.. or am I missing something?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Vojtech
>>>>>>>
>>>>>>
>>>>>> The didn't go anywhere, just never existed in the API. Please open a
>>>>>> RFE
>>>>>> to add them.
>>>>>
>>>>> Thanks, Juan. The RFE is here:
>>>>>
>>>>>    https://bugzilla.redhat.com/1075556
>>>>>
>>>>>>
>>>>>> --
>>>>>> Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
>>>>>> 3?D, 28016 Madrid, Spain
>>>>>> Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat
>>>>>> S.L.
>>>>>>
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>
>>>
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>



From chuan.liao at hp.com  Tue Mar 25 07:43:05 2014
From: chuan.liao at hp.com (Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC))
Date: Tue, 25 Mar 2014 07:43:05 +0000
Subject: [Engine-devel] Help to review the design of NUMA feature for oVirt
Message-ID: <B63C858E777679458338A30A991BB524015ED524@G1W3780.americas.hpqcorp.net>

Hi All,

Please help us to review the design of NUMA feature for oVirt,

Here are two design on wiki page
General Feature Design
http://www.ovirt.org/Features/NUMA_and_Virtual_NUMA

Detailed Design
http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA

Please feel free to have any comments, and we will reply as quickly as we could.


And we are in a tight schedule - we want it in to ovirt 3.5 release

Best Regards,
Jason Liao

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140325/85a6a12c/attachment.html>

From gchaplik at redhat.com  Tue Mar 25 14:52:35 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Tue, 25 Mar 2014 10:52:35 -0400 (EDT)
Subject: [Engine-devel] REST API - where did bookmarks go?
In-Reply-To: <5330AF0C.6010601@redhat.com>
References: <281801554.17527047.1394561704228.JavaMail.zimbra@redhat.com>
	<531F546B.8050104@redhat.com>
	<113223800.17954619.1394623639126.JavaMail.zimbra@redhat.com>
	<1326606294.6546859.1395674882071.JavaMail.zimbra@redhat.com>
	<331384667.4697967.1395675513966.JavaMail.zimbra@redhat.com>
	<2057224886.6564344.1395675964488.JavaMail.zimbra@redhat.com>
	<1071197349.4627740.1395679237487.JavaMail.zimbra@redhat.com>
	<5330AF0C.6010601@redhat.com>
Message-ID: <1044794478.7501097.1395759155656.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Vojtech Szocs" <vszocs at redhat.com>, "Gilad Chaplik" <gchaplik at redhat.com>
> Cc: "Juan Hernandez" <jhernand at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, March 25, 2014 12:17:48 AM
> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> 
> On 03/24/2014 12:40 PM, Vojtech Szocs wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Gilad Chaplik" <gchaplik at redhat.com>
> >> To: "Einav Cohen" <ecohen at redhat.com>
> >> Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Juan Hernandez"
> >> <jhernand at redhat.com>, "engine-devel"
> >> <engine-devel at ovirt.org>
> >> Sent: Monday, March 24, 2014 4:46:04 PM
> >> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> >>
> >> Hi Einav,
> >>
> >> I agree with every word. also thought about it, that's why I wrote a
> >> possible
> >> solution.
> >> Not sure we need to design the RESTful API according to UI's needs (add
> >> features in this case).
> >
> > I think that API should accomodate general/common needs of its clients.
> > After all, the usefulness of API can be measured by its usability from
> > client's perspective.
> >
> > At one extreme, API adapts to each specific client, which in turn bloats
> > the API. At another extreme, API lives in isolated bubble and doesn't care
> > for its clients. Each of these extremes is dangerous :)
> 
> I find shared bookmarks useful.
> i do actually think they should have had permissions:
> - who can see my bookmarks
> - who can share their bookmarks with others

I think that nowadays bookmarks are a client side feature only.
You can add bookmarks in your browser, and it will exist everywhere (mobile/smartphone/etc) - I use it on a daily basis on 4 different devices.
so you are getting these features for free.

In 'UI over REST' migration process I suggest to leave bookmarks to last, and reassess then.

> 
> >
> >>
> >>
> >>
> >> Thanks,
> >> Gilad.
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Einav Cohen" <ecohen at redhat.com>
> >>> To: "Gilad Chaplik" <gchaplik at redhat.com>
> >>> Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Juan Hernandez"
> >>> <jhernand at redhat.com>, "engine-devel"
> >>> <engine-devel at ovirt.org>
> >>> Sent: Monday, March 24, 2014 5:38:33 PM
> >>> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> >>>
> >>> Hi Gilad, "client-side Bookmarks" is a great suggestion, however it
> >>> is a (non-related) RFE, which may be implemented instead of, or in
> >>> addition to, the already-existing server-side Bookmarks.
> >>>
> >>> [keep in mind that server-side bookmarks allow you to add bookmarks
> >>> that may be used by other users; it is also a feature that exists
> >>> for a long time in oVirt, so need to think a little bit before
> >>> removing it]
> >>>
> >>> As long as we have server-side Bookmarks (i.e. as long as Bookmark
> >>> is an engine-managed business entity), they need to be exposed via
> >>> the REST API.
> >>>
> >>> ----
> >>> Thanks,
> >>> Einav
> >>>
> >>> ----- Original Message -----
> >>>> From: "Gilad Chaplik" <gchaplik at redhat.com>
> >>>> To: "Vojtech Szocs" <vszocs at redhat.com>
> >>>> Cc: "Juan Hernandez" <jhernand at redhat.com>, "engine-devel"
> >>>> <engine-devel at ovirt.org>
> >>>> Sent: Monday, March 24, 2014 11:28:02 AM
> >>>> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> >>>>
> >>>> Hi Guys,
> >>>>
> >>>> Why we need bookmarks in API? a single liner that points out to another
> >>>> single liner?
> >>>> I know that we need it for 'UI over REST' migration, but...
> >>>> IMHO bookmarks should be saved in client side, maybe inject the search
> >>>> string
> >>>> in the url, and get 'real' bookmarks/favorites... I don't know :-)
> >>>>
> >>>> Thanks,
> >>>> Gilad.
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Vojtech Szocs" <vszocs at redhat.com>
> >>>>> To: "Juan Hernandez" <jhernand at redhat.com>
> >>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>>> Sent: Wednesday, March 12, 2014 1:27:19 PM
> >>>>> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> >>>>>
> >>>>>
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Juan Hernandez" <jhernand at redhat.com>
> >>>>>> To: "Vojtech Szocs" <vszocs at redhat.com>, "engine-devel"
> >>>>>> <engine-devel at ovirt.org>
> >>>>>> Cc: "Einav Cohen" <ecohen at redhat.com>
> >>>>>> Sent: Tuesday, March 11, 2014 7:22:35 PM
> >>>>>> Subject: Re: REST API - where did bookmarks go?
> >>>>>>
> >>>>>> On 03/11/2014 07:15 PM, Vojtech Szocs wrote:
> >>>>>>> Hi guys,
> >>>>>>>
> >>>>>>> as part of prototyping new JavaScript binding for oVirt REST API,
> >>>>>>> we chose a couple of business entities (resources) to experiment
> >>>>>>> with.
> >>>>>>>
> >>>>>>> I just realized that requesting /ovirt-engine/api doesn't return
> >>>>>>> any information about bookmarks. Where did bookmarks go? Is it
> >>>>>>> possible to manage bookmarks through REST API?
> >>>>>>>
> >>>>>>> Note: WebAdmin currently gets bookmarks through GWT RPC by calling
> >>>>>>> GetAllBookmarksQuery. Bookmark seems like proper backend business
> >>>>>>> entity (with DAO and everything) so it should be exposed also via
> >>>>>>> REST API.. or am I missing something?
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Vojtech
> >>>>>>>
> >>>>>>
> >>>>>> The didn't go anywhere, just never existed in the API. Please open a
> >>>>>> RFE
> >>>>>> to add them.
> >>>>>
> >>>>> Thanks, Juan. The RFE is here:
> >>>>>
> >>>>>    https://bugzilla.redhat.com/1075556
> >>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> >>>>>> 3?D, 28016 Madrid, Spain
> >>>>>> Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat
> >>>>>> S.L.
> >>>>>>
> >>>>> _______________________________________________
> >>>>> Engine-devel mailing list
> >>>>> Engine-devel at ovirt.org
> >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>
> >>>> _______________________________________________
> >>>> Engine-devel mailing list
> >>>> Engine-devel at ovirt.org
> >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>
> >>>
> >>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
>


From gchaplik at redhat.com  Tue Mar 25 15:03:33 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Tue, 25 Mar 2014 11:03:33 -0400 (EDT)
Subject: [Engine-devel] REST API - where did bookmarks go?
In-Reply-To: <533198E1.50106@redhat.com>
References: <281801554.17527047.1394561704228.JavaMail.zimbra@redhat.com>
	<1326606294.6546859.1395674882071.JavaMail.zimbra@redhat.com>
	<331384667.4697967.1395675513966.JavaMail.zimbra@redhat.com>
	<2057224886.6564344.1395675964488.JavaMail.zimbra@redhat.com>
	<1071197349.4627740.1395679237487.JavaMail.zimbra@redhat.com>
	<5330AF0C.6010601@redhat.com>
	<1044794478.7501097.1395759155656.JavaMail.zimbra@redhat.com>
	<533198E1.50106@redhat.com>
Message-ID: <1786763534.7516290.1395759813657.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>
> Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Juan Hernandez" <jhernand at redhat.com>, "engine-devel"
> <engine-devel at ovirt.org>, "Einav Cohen" <ecohen at redhat.com>
> Sent: Tuesday, March 25, 2014 4:55:29 PM
> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> 
> On 03/25/2014 10:52 AM, Gilad Chaplik wrote:
> > ----- Original Message -----
> >> From: "Itamar Heim" <iheim at redhat.com>
> >> To: "Vojtech Szocs" <vszocs at redhat.com>, "Gilad Chaplik"
> >> <gchaplik at redhat.com>
> >> Cc: "Juan Hernandez" <jhernand at redhat.com>, "engine-devel"
> >> <engine-devel at ovirt.org>
> >> Sent: Tuesday, March 25, 2014 12:17:48 AM
> >> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> >>
> >> On 03/24/2014 12:40 PM, Vojtech Szocs wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Gilad Chaplik" <gchaplik at redhat.com>
> >>>> To: "Einav Cohen" <ecohen at redhat.com>
> >>>> Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Juan Hernandez"
> >>>> <jhernand at redhat.com>, "engine-devel"
> >>>> <engine-devel at ovirt.org>
> >>>> Sent: Monday, March 24, 2014 4:46:04 PM
> >>>> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> >>>>
> >>>> Hi Einav,
> >>>>
> >>>> I agree with every word. also thought about it, that's why I wrote a
> >>>> possible
> >>>> solution.
> >>>> Not sure we need to design the RESTful API according to UI's needs (add
> >>>> features in this case).
> >>>
> >>> I think that API should accomodate general/common needs of its clients.
> >>> After all, the usefulness of API can be measured by its usability from
> >>> client's perspective.
> >>>
> >>> At one extreme, API adapts to each specific client, which in turn bloats
> >>> the API. At another extreme, API lives in isolated bubble and doesn't
> >>> care
> >>> for its clients. Each of these extremes is dangerous :)
> >>
> >> I find shared bookmarks useful.
> >> i do actually think they should have had permissions:
> >> - who can see my bookmarks
> >> - who can share their bookmarks with others
> >
> > I think that nowadays bookmarks are a client side feature only.
> > You can add bookmarks in your browser, and it will exist everywhere
> > (mobile/smartphone/etc) - I use it on a daily basis on 4 different
> > devices.
> > so you are getting these features for free.
> 
> that's multiple devices, not multiple users.

* Have you heard of a user who wants it? I think it's a rare use case, but maybe(/usually) I'm wrong.
* Google search: share browser bookmarks, About 12,700,000 results

> 
> >
> > In 'UI over REST' migration process I suggest to leave bookmarks to last,
> > and reassess then.
> >
> >>
> >>>
> >>>>
> >>>>
> >>>>
> >>>> Thanks,
> >>>> Gilad.
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Einav Cohen" <ecohen at redhat.com>
> >>>>> To: "Gilad Chaplik" <gchaplik at redhat.com>
> >>>>> Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Juan Hernandez"
> >>>>> <jhernand at redhat.com>, "engine-devel"
> >>>>> <engine-devel at ovirt.org>
> >>>>> Sent: Monday, March 24, 2014 5:38:33 PM
> >>>>> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> >>>>>
> >>>>> Hi Gilad, "client-side Bookmarks" is a great suggestion, however it
> >>>>> is a (non-related) RFE, which may be implemented instead of, or in
> >>>>> addition to, the already-existing server-side Bookmarks.
> >>>>>
> >>>>> [keep in mind that server-side bookmarks allow you to add bookmarks
> >>>>> that may be used by other users; it is also a feature that exists
> >>>>> for a long time in oVirt, so need to think a little bit before
> >>>>> removing it]
> >>>>>
> >>>>> As long as we have server-side Bookmarks (i.e. as long as Bookmark
> >>>>> is an engine-managed business entity), they need to be exposed via
> >>>>> the REST API.
> >>>>>
> >>>>> ----
> >>>>> Thanks,
> >>>>> Einav
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Gilad Chaplik" <gchaplik at redhat.com>
> >>>>>> To: "Vojtech Szocs" <vszocs at redhat.com>
> >>>>>> Cc: "Juan Hernandez" <jhernand at redhat.com>, "engine-devel"
> >>>>>> <engine-devel at ovirt.org>
> >>>>>> Sent: Monday, March 24, 2014 11:28:02 AM
> >>>>>> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> >>>>>>
> >>>>>> Hi Guys,
> >>>>>>
> >>>>>> Why we need bookmarks in API? a single liner that points out to
> >>>>>> another
> >>>>>> single liner?
> >>>>>> I know that we need it for 'UI over REST' migration, but...
> >>>>>> IMHO bookmarks should be saved in client side, maybe inject the search
> >>>>>> string
> >>>>>> in the url, and get 'real' bookmarks/favorites... I don't know :-)
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Gilad.
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>>> From: "Vojtech Szocs" <vszocs at redhat.com>
> >>>>>>> To: "Juan Hernandez" <jhernand at redhat.com>
> >>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>>>>> Sent: Wednesday, March 12, 2014 1:27:19 PM
> >>>>>>> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> ----- Original Message -----
> >>>>>>>> From: "Juan Hernandez" <jhernand at redhat.com>
> >>>>>>>> To: "Vojtech Szocs" <vszocs at redhat.com>, "engine-devel"
> >>>>>>>> <engine-devel at ovirt.org>
> >>>>>>>> Cc: "Einav Cohen" <ecohen at redhat.com>
> >>>>>>>> Sent: Tuesday, March 11, 2014 7:22:35 PM
> >>>>>>>> Subject: Re: REST API - where did bookmarks go?
> >>>>>>>>
> >>>>>>>> On 03/11/2014 07:15 PM, Vojtech Szocs wrote:
> >>>>>>>>> Hi guys,
> >>>>>>>>>
> >>>>>>>>> as part of prototyping new JavaScript binding for oVirt REST API,
> >>>>>>>>> we chose a couple of business entities (resources) to experiment
> >>>>>>>>> with.
> >>>>>>>>>
> >>>>>>>>> I just realized that requesting /ovirt-engine/api doesn't return
> >>>>>>>>> any information about bookmarks. Where did bookmarks go? Is it
> >>>>>>>>> possible to manage bookmarks through REST API?
> >>>>>>>>>
> >>>>>>>>> Note: WebAdmin currently gets bookmarks through GWT RPC by calling
> >>>>>>>>> GetAllBookmarksQuery. Bookmark seems like proper backend business
> >>>>>>>>> entity (with DAO and everything) so it should be exposed also via
> >>>>>>>>> REST API.. or am I missing something?
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> Vojtech
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> The didn't go anywhere, just never existed in the API. Please open a
> >>>>>>>> RFE
> >>>>>>>> to add them.
> >>>>>>>
> >>>>>>> Thanks, Juan. The RFE is here:
> >>>>>>>
> >>>>>>>     https://bugzilla.redhat.com/1075556
> >>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3,
> >>>>>>>> planta
> >>>>>>>> 3?D, 28016 Madrid, Spain
> >>>>>>>> Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat
> >>>>>>>> S.L.
> >>>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Engine-devel mailing list
> >>>>>>> Engine-devel at ovirt.org
> >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>>>
> >>>>>> _______________________________________________
> >>>>>> Engine-devel mailing list
> >>>>>> Engine-devel at ovirt.org
> >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>>
> >>>>>
> >>>>
> >>> _______________________________________________
> >>> Engine-devel mailing list
> >>> Engine-devel at ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>
> >>
> >>
> 
>


From iheim at redhat.com  Tue Mar 25 14:55:29 2014
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 25 Mar 2014 10:55:29 -0400
Subject: [Engine-devel] REST API - where did bookmarks go?
In-Reply-To: <1044794478.7501097.1395759155656.JavaMail.zimbra@redhat.com>
References: <281801554.17527047.1394561704228.JavaMail.zimbra@redhat.com>
	<531F546B.8050104@redhat.com>
	<113223800.17954619.1394623639126.JavaMail.zimbra@redhat.com>
	<1326606294.6546859.1395674882071.JavaMail.zimbra@redhat.com>
	<331384667.4697967.1395675513966.JavaMail.zimbra@redhat.com>
	<2057224886.6564344.1395675964488.JavaMail.zimbra@redhat.com>
	<1071197349.4627740.1395679237487.JavaMail.zimbra@redhat.com>
	<5330AF0C.6010601@redhat.com>
	<1044794478.7501097.1395759155656.JavaMail.zimbra@redhat.com>
Message-ID: <533198E1.50106@redhat.com>

On 03/25/2014 10:52 AM, Gilad Chaplik wrote:
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Vojtech Szocs" <vszocs at redhat.com>, "Gilad Chaplik" <gchaplik at redhat.com>
>> Cc: "Juan Hernandez" <jhernand at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
>> Sent: Tuesday, March 25, 2014 12:17:48 AM
>> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
>>
>> On 03/24/2014 12:40 PM, Vojtech Szocs wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Gilad Chaplik" <gchaplik at redhat.com>
>>>> To: "Einav Cohen" <ecohen at redhat.com>
>>>> Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Juan Hernandez"
>>>> <jhernand at redhat.com>, "engine-devel"
>>>> <engine-devel at ovirt.org>
>>>> Sent: Monday, March 24, 2014 4:46:04 PM
>>>> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
>>>>
>>>> Hi Einav,
>>>>
>>>> I agree with every word. also thought about it, that's why I wrote a
>>>> possible
>>>> solution.
>>>> Not sure we need to design the RESTful API according to UI's needs (add
>>>> features in this case).
>>>
>>> I think that API should accomodate general/common needs of its clients.
>>> After all, the usefulness of API can be measured by its usability from
>>> client's perspective.
>>>
>>> At one extreme, API adapts to each specific client, which in turn bloats
>>> the API. At another extreme, API lives in isolated bubble and doesn't care
>>> for its clients. Each of these extremes is dangerous :)
>>
>> I find shared bookmarks useful.
>> i do actually think they should have had permissions:
>> - who can see my bookmarks
>> - who can share their bookmarks with others
>
> I think that nowadays bookmarks are a client side feature only.
> You can add bookmarks in your browser, and it will exist everywhere (mobile/smartphone/etc) - I use it on a daily basis on 4 different devices.
> so you are getting these features for free.

that's multiple devices, not multiple users.

>
> In 'UI over REST' migration process I suggest to leave bookmarks to last, and reassess then.
>
>>
>>>
>>>>
>>>>
>>>>
>>>> Thanks,
>>>> Gilad.
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Einav Cohen" <ecohen at redhat.com>
>>>>> To: "Gilad Chaplik" <gchaplik at redhat.com>
>>>>> Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Juan Hernandez"
>>>>> <jhernand at redhat.com>, "engine-devel"
>>>>> <engine-devel at ovirt.org>
>>>>> Sent: Monday, March 24, 2014 5:38:33 PM
>>>>> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
>>>>>
>>>>> Hi Gilad, "client-side Bookmarks" is a great suggestion, however it
>>>>> is a (non-related) RFE, which may be implemented instead of, or in
>>>>> addition to, the already-existing server-side Bookmarks.
>>>>>
>>>>> [keep in mind that server-side bookmarks allow you to add bookmarks
>>>>> that may be used by other users; it is also a feature that exists
>>>>> for a long time in oVirt, so need to think a little bit before
>>>>> removing it]
>>>>>
>>>>> As long as we have server-side Bookmarks (i.e. as long as Bookmark
>>>>> is an engine-managed business entity), they need to be exposed via
>>>>> the REST API.
>>>>>
>>>>> ----
>>>>> Thanks,
>>>>> Einav
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Gilad Chaplik" <gchaplik at redhat.com>
>>>>>> To: "Vojtech Szocs" <vszocs at redhat.com>
>>>>>> Cc: "Juan Hernandez" <jhernand at redhat.com>, "engine-devel"
>>>>>> <engine-devel at ovirt.org>
>>>>>> Sent: Monday, March 24, 2014 11:28:02 AM
>>>>>> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
>>>>>>
>>>>>> Hi Guys,
>>>>>>
>>>>>> Why we need bookmarks in API? a single liner that points out to another
>>>>>> single liner?
>>>>>> I know that we need it for 'UI over REST' migration, but...
>>>>>> IMHO bookmarks should be saved in client side, maybe inject the search
>>>>>> string
>>>>>> in the url, and get 'real' bookmarks/favorites... I don't know :-)
>>>>>>
>>>>>> Thanks,
>>>>>> Gilad.
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Vojtech Szocs" <vszocs at redhat.com>
>>>>>>> To: "Juan Hernandez" <jhernand at redhat.com>
>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>>>>> Sent: Wednesday, March 12, 2014 1:27:19 PM
>>>>>>> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Juan Hernandez" <jhernand at redhat.com>
>>>>>>>> To: "Vojtech Szocs" <vszocs at redhat.com>, "engine-devel"
>>>>>>>> <engine-devel at ovirt.org>
>>>>>>>> Cc: "Einav Cohen" <ecohen at redhat.com>
>>>>>>>> Sent: Tuesday, March 11, 2014 7:22:35 PM
>>>>>>>> Subject: Re: REST API - where did bookmarks go?
>>>>>>>>
>>>>>>>> On 03/11/2014 07:15 PM, Vojtech Szocs wrote:
>>>>>>>>> Hi guys,
>>>>>>>>>
>>>>>>>>> as part of prototyping new JavaScript binding for oVirt REST API,
>>>>>>>>> we chose a couple of business entities (resources) to experiment
>>>>>>>>> with.
>>>>>>>>>
>>>>>>>>> I just realized that requesting /ovirt-engine/api doesn't return
>>>>>>>>> any information about bookmarks. Where did bookmarks go? Is it
>>>>>>>>> possible to manage bookmarks through REST API?
>>>>>>>>>
>>>>>>>>> Note: WebAdmin currently gets bookmarks through GWT RPC by calling
>>>>>>>>> GetAllBookmarksQuery. Bookmark seems like proper backend business
>>>>>>>>> entity (with DAO and everything) so it should be exposed also via
>>>>>>>>> REST API.. or am I missing something?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Vojtech
>>>>>>>>>
>>>>>>>>
>>>>>>>> The didn't go anywhere, just never existed in the API. Please open a
>>>>>>>> RFE
>>>>>>>> to add them.
>>>>>>>
>>>>>>> Thanks, Juan. The RFE is here:
>>>>>>>
>>>>>>>     https://bugzilla.redhat.com/1075556
>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
>>>>>>>> 3?D, 28016 Madrid, Spain
>>>>>>>> Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat
>>>>>>>> S.L.
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Engine-devel mailing list
>>>>>>> Engine-devel at ovirt.org
>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Engine-devel mailing list
>>>>>> Engine-devel at ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>
>>



From pengchunhong at gmail.com  Wed Mar 26 08:13:05 2014
From: pengchunhong at gmail.com (=?GB2312?B?xe20urrp?=)
Date: Wed, 26 Mar 2014 16:13:05 +0800
Subject: [Engine-devel] debug ovirt-engine
Message-ID: <CABHYRTmZe6DQUDbrLDsArA5zQh1rHG2VYmfFVE8g2gXOHAD1Aw@mail.gmail.com>

Hello,everybody.when I develop with ovirt-engine,I have meet some obstacles
because of without the debug environment. So I really want to know how to
debug the frontend and backend of ovirt-engine by break points or by step .
Thank you for help!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140326/c8b06214/attachment.html>

From tjelinek at redhat.com  Wed Mar 26 08:32:42 2014
From: tjelinek at redhat.com (Tomas Jelinek)
Date: Wed, 26 Mar 2014 04:32:42 -0400 (EDT)
Subject: [Engine-devel] debug ovirt-engine
In-Reply-To: <CABHYRTmZe6DQUDbrLDsArA5zQh1rHG2VYmfFVE8g2gXOHAD1Aw@mail.gmail.com>
References: <CABHYRTmZe6DQUDbrLDsArA5zQh1rHG2VYmfFVE8g2gXOHAD1Aw@mail.gmail.com>
Message-ID: <654164960.5831104.1395822762721.JavaMail.zimbra@redhat.com>

Hi,

For frontend debugging please follow the instructions here: http://www.ovirt.org/DebugFrontend

For backend it is simpler. If you are using the development environment [1] than just connect your IDE to localhost:8787

Tomas

[1]: http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.developer;hb=HEAD

----- Original Message -----
> From: "???" <pengchunhong at gmail.com>
> To: engine-devel at ovirt.org
> Sent: Wednesday, March 26, 2014 9:13:05 AM
> Subject: [Engine-devel] debug ovirt-engine
> 
> Hello,everybody.when I develop with ovirt-engine,I have meet some obstacles
> because of without the debug environment. So I really want to know how to
> debug the frontend and backend of ovirt-engine by break points or by step .
> Thank you for help!
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>


From chuan.liao at hp.com  Wed Mar 26 08:43:13 2014
From: chuan.liao at hp.com (Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC))
Date: Wed, 26 Mar 2014 08:43:13 +0000
Subject: [Engine-devel] debug ovirt-engine
In-Reply-To: <CABHYRTmZe6DQUDbrLDsArA5zQh1rHG2VYmfFVE8g2gXOHAD1Aw@mail.gmail.com>
References: <CABHYRTmZe6DQUDbrLDsArA5zQh1rHG2VYmfFVE8g2gXOHAD1Aw@mail.gmail.com>
Message-ID: <B63C858E777679458338A30A991BB524015EF127@G1W3780.americas.hpqcorp.net>

Hi,

Do you go through the wiki page OVirt Engine Development Environment
http://www.ovirt.org/OVirt_Engine_Development_Environment

you can debug with
Debug port is available via port 8787, to be used by Eclipse or any other debugger.

Best Regards,
Jason Liao

From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at ovirt.org] On Behalf Of ???
Sent: 2014?3?26? 16:13
To: engine-devel at ovirt.org
Subject: [Engine-devel] debug ovirt-engine

Hello,everybody.when I develop with ovirt-engine,I have meet some obstacles because of without the debug environment. So I really want to know how to debug the frontend and backend of ovirt-engine by break points or by step . Thank you for help!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140326/94a4028a/attachment.html>

From gchaplik at redhat.com  Wed Mar 26 10:45:25 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Wed, 26 Mar 2014 06:45:25 -0400 (EDT)
Subject: [Engine-devel] debug ovirt-engine
In-Reply-To: <B63C858E777679458338A30A991BB524015EF127@G1W3780.americas.hpqcorp.net>
References: <CABHYRTmZe6DQUDbrLDsArA5zQh1rHG2VYmfFVE8g2gXOHAD1Aw@mail.gmail.com>
	<B63C858E777679458338A30A991BB524015EF127@G1W3780.americas.hpqcorp.net>
Message-ID: <610755809.8371008.1395830725931.JavaMail.zimbra@redhat.com>

btw, at least with eclipse you can debug both client and server together (two debug instances, port 8787 and 8000)
note that debugging the client takes time!! don't be intimidated 8-) 

Thanks, 
Gilad.

----- Original Message -----
> From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> To: "???" <pengchunhong at gmail.com>, engine-devel at ovirt.org
> Sent: Wednesday, March 26, 2014 10:43:13 AM
> Subject: Re: [Engine-devel] debug ovirt-engine
> 
> 
> 
> Hi,
> 
> 
> 
> Do you go through the wiki page OVirt Engine Development Environment
> 
> http://www.ovirt.org/OVirt_Engine_Development_Environment
> 
> 
> 
> you can debug with
> 
> Debug port is available via port 8787, to be used by Eclipse or any other
> debugger.
> 
> 
> 
> Best Regards,
> Jason Liao
> 
> 
> 
> From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at ovirt.org]
> On Behalf Of ???
> Sent: 2014 ? 3 ? 26 ? 16:13
> To: engine-devel at ovirt.org
> Subject: [Engine-devel] debug ovirt-engine
> 
> 
> 
> 
> Hello,everybody.when I develop with ovirt-engine,I have meet some obstacles
> because of without the debug environment. So I really want to know how to
> debug the frontend and backend of ovirt-engine by break points or by step .
> Thank you for help!
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From djasa at redhat.com  Wed Mar 26 11:59:46 2014
From: djasa at redhat.com (David =?UTF-8?Q?Ja=C5=A1a?=)
Date: Wed, 26 Mar 2014 12:59:46 +0100
Subject: [Engine-devel] REST API - where did bookmarks go?
In-Reply-To: <1326606294.6546859.1395674882071.JavaMail.zimbra@redhat.com>
References: <281801554.17527047.1394561704228.JavaMail.zimbra@redhat.com>
	<531F546B.8050104@redhat.com>
	<113223800.17954619.1394623639126.JavaMail.zimbra@redhat.com>
	<1326606294.6546859.1395674882071.JavaMail.zimbra@redhat.com>
Message-ID: <1395835186.30336.9.camel@cihla>

I don't use bookmarks in RHEV-M but if I did, I wouldn't be pleased if I
had to use another computer when things go wrong and in addition, engine
wouldn't give me my bookmarks... IMO if bookmarks are to stay, they
should be server-side.

David

On Po, 2014-03-24 at 11:28 -0400, Gilad Chaplik wrote:
> Hi Guys,
> 
> Why we need bookmarks in API? a single liner that points out to another single liner?
> I know that we need it for 'UI over REST' migration, but...
> IMHO bookmarks should be saved in client side, maybe inject the search string in the url, and get 'real' bookmarks/favorites... I don't know :-)
> 
> Thanks, 
> Gilad.
> 
> ----- Original Message -----
> > From: "Vojtech Szocs" <vszocs at redhat.com>
> > To: "Juan Hernandez" <jhernand at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Wednesday, March 12, 2014 1:27:19 PM
> > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Juan Hernandez" <jhernand at redhat.com>
> > > To: "Vojtech Szocs" <vszocs at redhat.com>, "engine-devel"
> > > <engine-devel at ovirt.org>
> > > Cc: "Einav Cohen" <ecohen at redhat.com>
> > > Sent: Tuesday, March 11, 2014 7:22:35 PM
> > > Subject: Re: REST API - where did bookmarks go?
> > > 
> > > On 03/11/2014 07:15 PM, Vojtech Szocs wrote:
> > > > Hi guys,
> > > > 
> > > > as part of prototyping new JavaScript binding for oVirt REST API,
> > > > we chose a couple of business entities (resources) to experiment
> > > > with.
> > > > 
> > > > I just realized that requesting /ovirt-engine/api doesn't return
> > > > any information about bookmarks. Where did bookmarks go? Is it
> > > > possible to manage bookmarks through REST API?
> > > > 
> > > > Note: WebAdmin currently gets bookmarks through GWT RPC by calling
> > > > GetAllBookmarksQuery. Bookmark seems like proper backend business
> > > > entity (with DAO and everything) so it should be exposed also via
> > > > REST API.. or am I missing something?
> > > > 
> > > > Thanks,
> > > > Vojtech
> > > > 
> > > 
> > > The didn't go anywhere, just never existed in the API. Please open a RFE
> > > to add them.
> > 
> > Thanks, Juan. The RFE is here:
> > 
> >   https://bugzilla.redhat.com/1075556
> > 
> > > 
> > > --
> > > Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> > > 3?D, 28016 Madrid, Spain
> > > Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L.
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel




From gchaplik at redhat.com  Wed Mar 26 13:27:41 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Wed, 26 Mar 2014 09:27:41 -0400 (EDT)
Subject: [Engine-devel] REST API - where did bookmarks go?
In-Reply-To: <1395835186.30336.9.camel@cihla>
References: <281801554.17527047.1394561704228.JavaMail.zimbra@redhat.com>
	<531F546B.8050104@redhat.com>
	<113223800.17954619.1394623639126.JavaMail.zimbra@redhat.com>
	<1326606294.6546859.1395674882071.JavaMail.zimbra@redhat.com>
	<1395835186.30336.9.camel@cihla>
Message-ID: <697764909.8511552.1395840461262.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "David Ja?a" <djasa at redhat.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>
> Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen" <ecohen at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, March 26, 2014 1:59:46 PM
> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> 
> I don't use bookmarks in RHEV-M but if I did, I wouldn't be pleased if I
> had to use another computer when things go wrong and in addition, engine
> wouldn't give me my bookmarks... IMO if bookmarks are to stay, they
> should be server-side.

I think that browser's bookmarks are much more advanced, sophisticated and native;
i.e. I'd rather have in my browser a bookmark to down HA VMs search, instead of:
- opening the application
- open the bookmarks tab
- searching the bookmark
* and that's after I know how to use it (I've read the manual[??]/wasted time in playing with it), and remember how to use it from time to time. 

> 
> David
> 
> On Po, 2014-03-24 at 11:28 -0400, Gilad Chaplik wrote:
> > Hi Guys,
> > 
> > Why we need bookmarks in API? a single liner that points out to another
> > single liner?
> > I know that we need it for 'UI over REST' migration, but...
> > IMHO bookmarks should be saved in client side, maybe inject the search
> > string in the url, and get 'real' bookmarks/favorites... I don't know :-)
> > 
> > Thanks,
> > Gilad.
> > 
> > ----- Original Message -----
> > > From: "Vojtech Szocs" <vszocs at redhat.com>
> > > To: "Juan Hernandez" <jhernand at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Wednesday, March 12, 2014 1:27:19 PM
> > > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Juan Hernandez" <jhernand at redhat.com>
> > > > To: "Vojtech Szocs" <vszocs at redhat.com>, "engine-devel"
> > > > <engine-devel at ovirt.org>
> > > > Cc: "Einav Cohen" <ecohen at redhat.com>
> > > > Sent: Tuesday, March 11, 2014 7:22:35 PM
> > > > Subject: Re: REST API - where did bookmarks go?
> > > > 
> > > > On 03/11/2014 07:15 PM, Vojtech Szocs wrote:
> > > > > Hi guys,
> > > > > 
> > > > > as part of prototyping new JavaScript binding for oVirt REST API,
> > > > > we chose a couple of business entities (resources) to experiment
> > > > > with.
> > > > > 
> > > > > I just realized that requesting /ovirt-engine/api doesn't return
> > > > > any information about bookmarks. Where did bookmarks go? Is it
> > > > > possible to manage bookmarks through REST API?
> > > > > 
> > > > > Note: WebAdmin currently gets bookmarks through GWT RPC by calling
> > > > > GetAllBookmarksQuery. Bookmark seems like proper backend business
> > > > > entity (with DAO and everything) so it should be exposed also via
> > > > > REST API.. or am I missing something?
> > > > > 
> > > > > Thanks,
> > > > > Vojtech
> > > > > 
> > > > 
> > > > The didn't go anywhere, just never existed in the API. Please open a
> > > > RFE
> > > > to add them.
> > > 
> > > Thanks, Juan. The RFE is here:
> > > 
> > >   https://bugzilla.redhat.com/1075556
> > > 
> > > > 
> > > > --
> > > > Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> > > > 3?D, 28016 Madrid, Spain
> > > > Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat
> > > > S.L.
> > > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
> 


From vszocs at redhat.com  Wed Mar 26 13:30:53 2014
From: vszocs at redhat.com (Vojtech Szocs)
Date: Wed, 26 Mar 2014 09:30:53 -0400 (EDT)
Subject: [Engine-devel] debug ovirt-engine
In-Reply-To: <610755809.8371008.1395830725931.JavaMail.zimbra@redhat.com>
References: <CABHYRTmZe6DQUDbrLDsArA5zQh1rHG2VYmfFVE8g2gXOHAD1Aw@mail.gmail.com>
	<B63C858E777679458338A30A991BB524015EF127@G1W3780.americas.hpqcorp.net>
	<610755809.8371008.1395830725931.JavaMail.zimbra@redhat.com>
Message-ID: <1976955800.5963287.1395840653594.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Gilad Chaplik" <gchaplik at redhat.com>
> To: "???" <pengchunhong at gmail.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, March 26, 2014 11:45:25 AM
> Subject: Re: [Engine-devel] debug ovirt-engine
> 
> btw, at least with eclipse you can debug both client and server together (two
> debug instances, port 8787 and 8000)
> note that debugging the client takes time!! don't be intimidated 8-)

Right, GWT debugging might be slower than expected, here are some tips:
- avoid compiling both WebAdmin & UserPortal when you debug only one of them
- specify target browser(s) via -Dgwt.userAgent=... (avoid compiling for all browsers)
- GWT Developer Plugin doesn't work with recent Firefox, use Chrome instead

In future, we'll upgrade GWT SDK version which should bring some improvements to the compile/debug process.

> 
> Thanks,
> Gilad.
> 
> ----- Original Message -----
> > From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> > To: "???" <pengchunhong at gmail.com>, engine-devel at ovirt.org
> > Sent: Wednesday, March 26, 2014 10:43:13 AM
> > Subject: Re: [Engine-devel] debug ovirt-engine
> > 
> > 
> > 
> > Hi,
> > 
> > 
> > 
> > Do you go through the wiki page OVirt Engine Development Environment
> > 
> > http://www.ovirt.org/OVirt_Engine_Development_Environment
> > 
> > 
> > 
> > you can debug with
> > 
> > Debug port is available via port 8787, to be used by Eclipse or any other
> > debugger.
> > 
> > 
> > 
> > Best Regards,
> > Jason Liao
> > 
> > 
> > 
> > From: engine-devel-bounces at ovirt.org
> > [mailto:engine-devel-bounces at ovirt.org]
> > On Behalf Of ???
> > Sent: 2014 ? 3 ? 26 ? 16:13
> > To: engine-devel at ovirt.org
> > Subject: [Engine-devel] debug ovirt-engine
> > 
> > 
> > 
> > 
> > Hello,everybody.when I develop with ovirt-engine,I have meet some obstacles
> > because of without the debug environment. So I really want to know how to
> > debug the frontend and backend of ovirt-engine by break points or by step .
> > Thank you for help!
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From vszocs at redhat.com  Wed Mar 26 13:36:35 2014
From: vszocs at redhat.com (Vojtech Szocs)
Date: Wed, 26 Mar 2014 09:36:35 -0400 (EDT)
Subject: [Engine-devel] REST API - where did bookmarks go?
In-Reply-To: <697764909.8511552.1395840461262.JavaMail.zimbra@redhat.com>
References: <281801554.17527047.1394561704228.JavaMail.zimbra@redhat.com>
	<531F546B.8050104@redhat.com>
	<113223800.17954619.1394623639126.JavaMail.zimbra@redhat.com>
	<1326606294.6546859.1395674882071.JavaMail.zimbra@redhat.com>
	<1395835186.30336.9.camel@cihla>
	<697764909.8511552.1395840461262.JavaMail.zimbra@redhat.com>
Message-ID: <1646021950.5966399.1395840995127.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Gilad Chaplik" <gchaplik at redhat.com>
> To: djasa at redhat.com
> Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen" <ecohen at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, March 26, 2014 2:27:41 PM
> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> 
> ----- Original Message -----
> > From: "David Ja?a" <djasa at redhat.com>
> > To: "Gilad Chaplik" <gchaplik at redhat.com>
> > Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen" <ecohen at redhat.com>,
> > "engine-devel" <engine-devel at ovirt.org>
> > Sent: Wednesday, March 26, 2014 1:59:46 PM
> > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > 
> > I don't use bookmarks in RHEV-M but if I did, I wouldn't be pleased if I
> > had to use another computer when things go wrong and in addition, engine
> > wouldn't give me my bookmarks... IMO if bookmarks are to stay, they
> > should be server-side.
> 
> I think that browser's bookmarks are much more advanced, sophisticated and
> native;
> i.e. I'd rather have in my browser a bookmark to down HA VMs search, instead
> of:
> - opening the application
> - open the bookmarks tab
> - searching the bookmark
> * and that's after I know how to use it (I've read the manual[??]/wasted time
> in playing with it), and remember how to use it from time to time.

If this means embedding search string in WebAdmin's URL like [1], I'm for it.

[1] WebAdmin.html#search;q={uri-encoded-search-string}

This could be done as RFE on top of (existing) bookmark functionality, giving people more choice.

> 
> > 
> > David
> > 
> > On Po, 2014-03-24 at 11:28 -0400, Gilad Chaplik wrote:
> > > Hi Guys,
> > > 
> > > Why we need bookmarks in API? a single liner that points out to another
> > > single liner?
> > > I know that we need it for 'UI over REST' migration, but...
> > > IMHO bookmarks should be saved in client side, maybe inject the search
> > > string in the url, and get 'real' bookmarks/favorites... I don't know :-)
> > > 
> > > Thanks,
> > > Gilad.
> > > 
> > > ----- Original Message -----
> > > > From: "Vojtech Szocs" <vszocs at redhat.com>
> > > > To: "Juan Hernandez" <jhernand at redhat.com>
> > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Wednesday, March 12, 2014 1:27:19 PM
> > > > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Juan Hernandez" <jhernand at redhat.com>
> > > > > To: "Vojtech Szocs" <vszocs at redhat.com>, "engine-devel"
> > > > > <engine-devel at ovirt.org>
> > > > > Cc: "Einav Cohen" <ecohen at redhat.com>
> > > > > Sent: Tuesday, March 11, 2014 7:22:35 PM
> > > > > Subject: Re: REST API - where did bookmarks go?
> > > > > 
> > > > > On 03/11/2014 07:15 PM, Vojtech Szocs wrote:
> > > > > > Hi guys,
> > > > > > 
> > > > > > as part of prototyping new JavaScript binding for oVirt REST API,
> > > > > > we chose a couple of business entities (resources) to experiment
> > > > > > with.
> > > > > > 
> > > > > > I just realized that requesting /ovirt-engine/api doesn't return
> > > > > > any information about bookmarks. Where did bookmarks go? Is it
> > > > > > possible to manage bookmarks through REST API?
> > > > > > 
> > > > > > Note: WebAdmin currently gets bookmarks through GWT RPC by calling
> > > > > > GetAllBookmarksQuery. Bookmark seems like proper backend business
> > > > > > entity (with DAO and everything) so it should be exposed also via
> > > > > > REST API.. or am I missing something?
> > > > > > 
> > > > > > Thanks,
> > > > > > Vojtech
> > > > > > 
> > > > > 
> > > > > The didn't go anywhere, just never existed in the API. Please open a
> > > > > RFE
> > > > > to add them.
> > > > 
> > > > Thanks, Juan. The RFE is here:
> > > > 
> > > >   https://bugzilla.redhat.com/1075556
> > > > 
> > > > > 
> > > > > --
> > > > > Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> > > > > 3?D, 28016 Madrid, Spain
> > > > > Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat
> > > > > S.L.
> > > > > 
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> > 
> > 
> 


From gchaplik at redhat.com  Wed Mar 26 13:51:01 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Wed, 26 Mar 2014 09:51:01 -0400 (EDT)
Subject: [Engine-devel] REST API - where did bookmarks go?
In-Reply-To: <1646021950.5966399.1395840995127.JavaMail.zimbra@redhat.com>
References: <281801554.17527047.1394561704228.JavaMail.zimbra@redhat.com>
	<531F546B.8050104@redhat.com>
	<113223800.17954619.1394623639126.JavaMail.zimbra@redhat.com>
	<1326606294.6546859.1395674882071.JavaMail.zimbra@redhat.com>
	<1395835186.30336.9.camel@cihla>
	<697764909.8511552.1395840461262.JavaMail.zimbra@redhat.com>
	<1646021950.5966399.1395840995127.JavaMail.zimbra@redhat.com>
Message-ID: <1317932540.8533776.1395841861590.JavaMail.zimbra@redhat.com>

thank you Vojtech!

fyi, if we hadn't have the 3.X compatibility issues, I'm for removing current bookmarks.

Thanks, 
Gilad.


----- Original Message -----
> From: "Vojtech Szocs" <vszocs at redhat.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>
> Cc: djasa at redhat.com, "Einav Cohen" <ecohen at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, March 26, 2014 3:36:35 PM
> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> 
> 
> 
> ----- Original Message -----
> > From: "Gilad Chaplik" <gchaplik at redhat.com>
> > To: djasa at redhat.com
> > Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen" <ecohen at redhat.com>,
> > "engine-devel" <engine-devel at ovirt.org>
> > Sent: Wednesday, March 26, 2014 2:27:41 PM
> > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > 
> > ----- Original Message -----
> > > From: "David Ja?a" <djasa at redhat.com>
> > > To: "Gilad Chaplik" <gchaplik at redhat.com>
> > > Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen"
> > > <ecohen at redhat.com>,
> > > "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Wednesday, March 26, 2014 1:59:46 PM
> > > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > > 
> > > I don't use bookmarks in RHEV-M but if I did, I wouldn't be pleased if I
> > > had to use another computer when things go wrong and in addition, engine
> > > wouldn't give me my bookmarks... IMO if bookmarks are to stay, they
> > > should be server-side.
> > 
> > I think that browser's bookmarks are much more advanced, sophisticated and
> > native;
> > i.e. I'd rather have in my browser a bookmark to down HA VMs search,
> > instead
> > of:
> > - opening the application
> > - open the bookmarks tab
> > - searching the bookmark
> > * and that's after I know how to use it (I've read the manual[??]/wasted
> > time
> > in playing with it), and remember how to use it from time to time.
> 
> If this means embedding search string in WebAdmin's URL like [1], I'm for it.
> 
> [1] WebAdmin.html#search;q={uri-encoded-search-string}
> 
> This could be done as RFE on top of (existing) bookmark functionality, giving
> people more choice.
> 
> > 
> > > 
> > > David
> > > 
> > > On Po, 2014-03-24 at 11:28 -0400, Gilad Chaplik wrote:
> > > > Hi Guys,
> > > > 
> > > > Why we need bookmarks in API? a single liner that points out to another
> > > > single liner?
> > > > I know that we need it for 'UI over REST' migration, but...
> > > > IMHO bookmarks should be saved in client side, maybe inject the search
> > > > string in the url, and get 'real' bookmarks/favorites... I don't know
> > > > :-)
> > > > 
> > > > Thanks,
> > > > Gilad.
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Vojtech Szocs" <vszocs at redhat.com>
> > > > > To: "Juan Hernandez" <jhernand at redhat.com>
> > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > Sent: Wednesday, March 12, 2014 1:27:19 PM
> > > > > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Juan Hernandez" <jhernand at redhat.com>
> > > > > > To: "Vojtech Szocs" <vszocs at redhat.com>, "engine-devel"
> > > > > > <engine-devel at ovirt.org>
> > > > > > Cc: "Einav Cohen" <ecohen at redhat.com>
> > > > > > Sent: Tuesday, March 11, 2014 7:22:35 PM
> > > > > > Subject: Re: REST API - where did bookmarks go?
> > > > > > 
> > > > > > On 03/11/2014 07:15 PM, Vojtech Szocs wrote:
> > > > > > > Hi guys,
> > > > > > > 
> > > > > > > as part of prototyping new JavaScript binding for oVirt REST API,
> > > > > > > we chose a couple of business entities (resources) to experiment
> > > > > > > with.
> > > > > > > 
> > > > > > > I just realized that requesting /ovirt-engine/api doesn't return
> > > > > > > any information about bookmarks. Where did bookmarks go? Is it
> > > > > > > possible to manage bookmarks through REST API?
> > > > > > > 
> > > > > > > Note: WebAdmin currently gets bookmarks through GWT RPC by
> > > > > > > calling
> > > > > > > GetAllBookmarksQuery. Bookmark seems like proper backend business
> > > > > > > entity (with DAO and everything) so it should be exposed also via
> > > > > > > REST API.. or am I missing something?
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > Vojtech
> > > > > > > 
> > > > > > 
> > > > > > The didn't go anywhere, just never existed in the API. Please open
> > > > > > a
> > > > > > RFE
> > > > > > to add them.
> > > > > 
> > > > > Thanks, Juan. The RFE is here:
> > > > > 
> > > > >   https://bugzilla.redhat.com/1075556
> > > > > 
> > > > > > 
> > > > > > --
> > > > > > Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3,
> > > > > > planta
> > > > > > 3?D, 28016 Madrid, Spain
> > > > > > Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red
> > > > > > Hat
> > > > > > S.L.
> > > > > > 
> > > > > _______________________________________________
> > > > > Engine-devel mailing list
> > > > > Engine-devel at ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > >
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > > 
> > > 
> > 
> 


From vszocs at redhat.com  Wed Mar 26 14:06:23 2014
From: vszocs at redhat.com (Vojtech Szocs)
Date: Wed, 26 Mar 2014 10:06:23 -0400 (EDT)
Subject: [Engine-devel] REST API - where did bookmarks go?
In-Reply-To: <1317932540.8533776.1395841861590.JavaMail.zimbra@redhat.com>
References: <281801554.17527047.1394561704228.JavaMail.zimbra@redhat.com>
	<531F546B.8050104@redhat.com>
	<113223800.17954619.1394623639126.JavaMail.zimbra@redhat.com>
	<1326606294.6546859.1395674882071.JavaMail.zimbra@redhat.com>
	<1395835186.30336.9.camel@cihla>
	<697764909.8511552.1395840461262.JavaMail.zimbra@redhat.com>
	<1646021950.5966399.1395840995127.JavaMail.zimbra@redhat.com>
	<1317932540.8533776.1395841861590.JavaMail.zimbra@redhat.com>
Message-ID: <1366441104.5983895.1395842783373.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Gilad Chaplik" <gchaplik at redhat.com>
> To: "Vojtech Szocs" <vszocs at redhat.com>
> Cc: djasa at redhat.com, "Einav Cohen" <ecohen at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, March 26, 2014 2:51:01 PM
> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> 
> thank you Vojtech!
> 
> fyi, if we hadn't have the 3.X compatibility issues, I'm for removing current
> bookmarks.

I've created RFE for this: https://bugzilla.redhat.com/show_bug.cgi?id=1081028

This could be a complement of (but not necessarily a replacement of) server-side bookmarks.

> 
> Thanks,
> Gilad.
> 
> 
> ----- Original Message -----
> > From: "Vojtech Szocs" <vszocs at redhat.com>
> > To: "Gilad Chaplik" <gchaplik at redhat.com>
> > Cc: djasa at redhat.com, "Einav Cohen" <ecohen at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>
> > Sent: Wednesday, March 26, 2014 3:36:35 PM
> > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Gilad Chaplik" <gchaplik at redhat.com>
> > > To: djasa at redhat.com
> > > Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen"
> > > <ecohen at redhat.com>,
> > > "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Wednesday, March 26, 2014 2:27:41 PM
> > > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > > 
> > > ----- Original Message -----
> > > > From: "David Ja?a" <djasa at redhat.com>
> > > > To: "Gilad Chaplik" <gchaplik at redhat.com>
> > > > Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen"
> > > > <ecohen at redhat.com>,
> > > > "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Wednesday, March 26, 2014 1:59:46 PM
> > > > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > > > 
> > > > I don't use bookmarks in RHEV-M but if I did, I wouldn't be pleased if
> > > > I
> > > > had to use another computer when things go wrong and in addition,
> > > > engine
> > > > wouldn't give me my bookmarks... IMO if bookmarks are to stay, they
> > > > should be server-side.
> > > 
> > > I think that browser's bookmarks are much more advanced, sophisticated
> > > and
> > > native;
> > > i.e. I'd rather have in my browser a bookmark to down HA VMs search,
> > > instead
> > > of:
> > > - opening the application
> > > - open the bookmarks tab
> > > - searching the bookmark
> > > * and that's after I know how to use it (I've read the manual[??]/wasted
> > > time
> > > in playing with it), and remember how to use it from time to time.
> > 
> > If this means embedding search string in WebAdmin's URL like [1], I'm for
> > it.
> > 
> > [1] WebAdmin.html#search;q={uri-encoded-search-string}
> > 
> > This could be done as RFE on top of (existing) bookmark functionality,
> > giving
> > people more choice.
> > 
> > > 
> > > > 
> > > > David
> > > > 
> > > > On Po, 2014-03-24 at 11:28 -0400, Gilad Chaplik wrote:
> > > > > Hi Guys,
> > > > > 
> > > > > Why we need bookmarks in API? a single liner that points out to
> > > > > another
> > > > > single liner?
> > > > > I know that we need it for 'UI over REST' migration, but...
> > > > > IMHO bookmarks should be saved in client side, maybe inject the
> > > > > search
> > > > > string in the url, and get 'real' bookmarks/favorites... I don't know
> > > > > :-)
> > > > > 
> > > > > Thanks,
> > > > > Gilad.
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Vojtech Szocs" <vszocs at redhat.com>
> > > > > > To: "Juan Hernandez" <jhernand at redhat.com>
> > > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > Sent: Wednesday, March 12, 2014 1:27:19 PM
> > > > > > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Juan Hernandez" <jhernand at redhat.com>
> > > > > > > To: "Vojtech Szocs" <vszocs at redhat.com>, "engine-devel"
> > > > > > > <engine-devel at ovirt.org>
> > > > > > > Cc: "Einav Cohen" <ecohen at redhat.com>
> > > > > > > Sent: Tuesday, March 11, 2014 7:22:35 PM
> > > > > > > Subject: Re: REST API - where did bookmarks go?
> > > > > > > 
> > > > > > > On 03/11/2014 07:15 PM, Vojtech Szocs wrote:
> > > > > > > > Hi guys,
> > > > > > > > 
> > > > > > > > as part of prototyping new JavaScript binding for oVirt REST
> > > > > > > > API,
> > > > > > > > we chose a couple of business entities (resources) to
> > > > > > > > experiment
> > > > > > > > with.
> > > > > > > > 
> > > > > > > > I just realized that requesting /ovirt-engine/api doesn't
> > > > > > > > return
> > > > > > > > any information about bookmarks. Where did bookmarks go? Is it
> > > > > > > > possible to manage bookmarks through REST API?
> > > > > > > > 
> > > > > > > > Note: WebAdmin currently gets bookmarks through GWT RPC by
> > > > > > > > calling
> > > > > > > > GetAllBookmarksQuery. Bookmark seems like proper backend
> > > > > > > > business
> > > > > > > > entity (with DAO and everything) so it should be exposed also
> > > > > > > > via
> > > > > > > > REST API.. or am I missing something?
> > > > > > > > 
> > > > > > > > Thanks,
> > > > > > > > Vojtech
> > > > > > > > 
> > > > > > > 
> > > > > > > The didn't go anywhere, just never existed in the API. Please
> > > > > > > open
> > > > > > > a
> > > > > > > RFE
> > > > > > > to add them.
> > > > > > 
> > > > > > Thanks, Juan. The RFE is here:
> > > > > > 
> > > > > >   https://bugzilla.redhat.com/1075556
> > > > > > 
> > > > > > > 
> > > > > > > --
> > > > > > > Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3,
> > > > > > > planta
> > > > > > > 3?D, 28016 Madrid, Spain
> > > > > > > Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red
> > > > > > > Hat
> > > > > > > S.L.
> > > > > > > 
> > > > > > _______________________________________________
> > > > > > Engine-devel mailing list
> > > > > > Engine-devel at ovirt.org
> > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > >
> > > > > _______________________________________________
> > > > > Engine-devel mailing list
> > > > > Engine-devel at ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > 
> > > > 
> > > > 
> > > 
> > 
> 


From vszocs at redhat.com  Wed Mar 26 14:23:58 2014
From: vszocs at redhat.com (Vojtech Szocs)
Date: Wed, 26 Mar 2014 10:23:58 -0400 (EDT)
Subject: [Engine-devel] Playing with GWT Super Dev Mode
In-Reply-To: <316745573.5986937.1395842981236.JavaMail.zimbra@redhat.com>
Message-ID: <1623816774.5998712.1395843838793.JavaMail.zimbra@redhat.com>

Hi guys,

I wrote a patch [1] that adds the ability to debug WebAdmin using
GWT Super Dev Mode, an alternative to current (Classic) Dev Mode.

[1] http://gerrit.ovirt.org/#/c/26093/

I've encountered some issues, for some reason calls to GWT RPC
server endpoint /ovirt-engine/webadmin/GenericApiGWTService fail
with HTTP 500 (internal server error).

The way Super Dev Mode works is selector script (webadmin.nocache.js)
loads actual permutation files from Super Dev Mode's "code" server at
localhost:9876 - JS inside makes GWT RPC calls which fails, not sure
if this is due to "experimental" stage of Super Dev Mode in GWT 2.5.1
or if its related to direct-eval RPC implementation in use.

You can take the patch above and play with it, in the worst case
I will abandon it and revisit when we upgrade to newer GWT version
(which will fully support Super Dev Mode).

As you might already know, GWT team is focusing on Super Dev Mode
in the long term, as maintaining different browser plugins for GWT
debugging (used with Classic Dev Mode) is problematic; for example,
recent Firefox versions have issues with GWT Developer Plugin.

Regards,
Vojtech


From bproffit at redhat.com  Wed Mar 26 18:42:23 2014
From: bproffit at redhat.com (Brian Proffitt)
Date: Wed, 26 Mar 2014 14:42:23 -0400 (EDT)
Subject: [Engine-devel] Attention: Mailing list change
Message-ID: <344443692.4099776.1395859343788.JavaMail.zimbra@redhat.com>

All:

One of the long-standing requests in the oVirt community is the merging of the [arch] and [engine-devel] mailing lists. This note is an announcement that on Monday, March 31, this will get done.

What will happen:

1) Subscribers from [arch] and [engine-devel] will be migrated to a new [devel] list.
2) Archives from [arch] will be left as is, and available for searching on the list.ovirt.org/mailman site.
3) Archived from [engine-devel] (this list) will be renamed to [devel]

If you have any comments or concerns, let me know.

Thank you for your patience in this matter,
Brian

-- 
Brian Proffitt - oVirt Community Manager
Open Source and Standards, Red Hat - http://community.redhat.com
Phone: +1 574 383 9BKP
IRC: bkp @ OFTC


From tjelinek at redhat.com  Thu Mar 27 09:13:45 2014
From: tjelinek at redhat.com (Tomas Jelinek)
Date: Thu, 27 Mar 2014 05:13:45 -0400 (EDT)
Subject: [Engine-devel] debug ovirt-engine
In-Reply-To: <CABHYRTmMzy-BFtUTx3QPaXXNQTrOxMd2awhRk_m8f_CWoRtiHQ@mail.gmail.com>
References: <CABHYRTmZe6DQUDbrLDsArA5zQh1rHG2VYmfFVE8g2gXOHAD1Aw@mail.gmail.com>
	<B63C858E777679458338A30A991BB524015EF127@G1W3780.americas.hpqcorp.net>
	<610755809.8371008.1395830725931.JavaMail.zimbra@redhat.com>
	<CABHYRT=fy5z7G=urFMcuDRmCZ-ajy6p4pDOh8MwvO9ywRc5Ygg@mail.gmail.com>
	<819540785.8516411.1395840723020.JavaMail.zimbra@redhat.com>
	<CABHYRTkvs73EMgjU-5Xr6f8QHUivVp1t6WyCNZVPZt=goSr0rA@mail.gmail.com>
	<CABHYRTmMzy-BFtUTx3QPaXXNQTrOxMd2awhRk_m8f_CWoRtiHQ@mail.gmail.com>
Message-ID: <388117085.6673182.1395911625804.JavaMail.zimbra@redhat.com>

Hey,

well, that errors are due to some aspectj magic we are doing related to the fact that we are using
the same entities on FE and BE and need to hack the GWT optimization to make this work. 
Long story short, please feel free to ignore that errors, that are not errors in fact but debug messages and are
presented as error due to an unrelated bug :) So, if the "GWT Development Mode" window shows up you are free to continue.

Tomas

PS: please always attach also the engine-devel list because others may benefit from this discussion as well...

----- Original Message -----
> From: "???" <pengchunhong at gmail.com>
> To: "Tomas Jelinek" <tjelinek at redhat.com>
> Sent: Thursday, March 27, 2014 9:04:19 AM
> Subject: Re: [Engine-devel] debug ovirt-engine
> 
> Hi,Tomas Jelinek.
> Thank for your help,I follow the instructs but get some errors.My detail
> steps are these:
> 1.make clean install-dev PREFIX="$HOME/ovirt-engine"
> DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.userAgent=gecko1_8,safari"
> BUILD_GWT_WEBADMIN="1" BUILD_GWT_USERPORTAL="0"
> 2.make gwt-debug DEBUG_MODULE="webadmin"
> DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.userAgent=safari"
> 
>     after this step,the terminal print messages:
>     [debug] execute contextualize
>     [INFO] Using 'UTF-8' encoding to copy filtered resources.
>     [INFO] Copying 208 resources to
> /home/lerroy/ovirt-engine-debug/frontend/webadmin/modules/webadmin/target/generated-sources/gwt
>     [INFO] Copying 685 resources
>     [INFO] Copying 136 resources to resources
>     [INFO]
>     [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @
> webadmin ---
>     [INFO] Compiling 45 source files to
> /home/lerroy/ovirt-engine-debug/frontend/webadmin/modules/webadmin/target/webadmin-3.4.0-SNAPSHOT/WEB-INF/classes
>     [INFO]
>     [INFO] <<< gwt-maven-plugin:2.4.0:debug (default-cli) @ webadmin <<<
>     [INFO]
>     [INFO] --- gwt-maven-plugin:2.4.0:debug (default-cli) @ webadmin ---
>     [INFO] starting debugger on port 8000 in suspend mode
>     [WARNING] Don't declare gwt-dev as a project dependency. This may
> introduce complex dependency conflicts
>     [INFO] noServer is set! Skipping exploding war file...
>     [INFO] Listening for transport dt_socket at address: 8000
> 3.import ovirt into eclipse as "existing maven projects".
> 4.In Eclipse:
>     4.1."Run | Debug Configurations"
>     4.2.Select "Remote Java Application" and click "New launch
> configuration"
>     4.3.On Connect tab, set Host="localhost" and Port="8000"
>     4.4.On Source tab, click "Add | Java Project" and choose related
> frontend projects
> After set these infomations,click the "debug" button,the terminal shows
> some errors as these:
> [ERROR] [AppClassLoader at 11a40fff] info AspectJ Weaver Version 1.6.11 built
> on Tuesday Mar 15, 2011 at 15:31:04 GMT
> [ERROR] [AppClassLoader at 11a40fff] info register classloader
> sun.misc.Launcher$AppClassLoader at 11a40fff
> [ERROR] [AppClassLoader at 11a40fff] info using configuration
> file:/home/lerroy/.m2/repository/org/ovirt/engine/ui/gwt-extension/3.4.0-SNAPSHOT/gwt-extension-3.4.0-SNAPSHOT.jar!/META-INF/aop.xml
> [ERROR] [AppClassLoader at 11a40fff] info using configuration
> file:/home/lerroy/.m2/repository/org/ovirt/engine/ui/gwt-extension/3.4.0-SNAPSHOT/gwt-extension-3.4.0-SNAPSHOT-sources.jar!/META-INF/aop.xml
> [ERROR] [AppClassLoader at 11a40fff] info register aspect
> org.ovirt.engine.ui.gwtextension.DontPrune
> [ERROR] [AppClassLoader at 11a40fff] info register aspect
> org.ovirt.engine.ui.gwtextension.DontPrune
> [ERROR] [MethodUtil at 3d2bde69] info AspectJ Weaver Version 1.6.11 built on
> Tuesday Mar 15, 2011 at 15:31:04 GMT
> [ERROR] [MethodUtil at 3d2bde69] info register classloader
> sun.reflect.misc.MethodUtil at 3d2bde69
> [ERROR] [MethodUtil at 3d2bde69] info using configuration
> file:/home/lerroy/.m2/repository/org/ovirt/engine/ui/gwt-extension/3.4.0-SNAPSHOT/gwt-extension-3.4.0-SNAPSHOT.jar!/META-INF/aop.xml
> [ERROR] [MethodUtil at 3d2bde69] info using configuration
> file:/home/lerroy/.m2/repository/org/ovirt/engine/ui/gwt-extension/3.4.0-SNAPSHOT/gwt-extension-3.4.0-SNAPSHOT-sources.jar!/META-INF/aop.xml
> [ERROR] [MethodUtil at 3d2bde69] info register aspect
> org.ovirt.engine.ui.gwtextension.DontPrune
> [ERROR] [MethodUtil at 3d2bde69] info register aspect
> org.ovirt.engine.ui.gwtextension.DontPrune
> 
> when  compile the ovirt-engine with command "make clean install-dev
> PREFIX=$HOME/ovirt-engine", I get the same error "[ERROR]
> [MethodUtil at 3d2bde69] info register aspect
> org.ovirt.engine.ui.gwtextension.DontPrune",but it still can be install
> successfully and run stably.
> So,my problem is how to resolve this error inorder to debug the
> ovirt-frontend and backend.Thank you very much!
> 
> 
> 2014-03-27 16:01 GMT+08:00 ??? <pengchunhong at gmail.com>:
> 
> > Hi,Gilad Chaplik.
> > Thank for your help,I follow the instructs but get some errors.My detail
> > steps are these:
> > 1.make clean install-dev PREFIX="$HOME/ovirt-engine"
> > DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.userAgent=gecko1_8,safari"
> > BUILD_GWT_WEBADMIN="1" BUILD_GWT_USERPORTAL="0"
> > 2.make gwt-debug DEBUG_MODULE="webadmin"
> > DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.userAgent=safari"
> >
> >     after this step,the terminal print messages:
> >     [debug] execute contextualize
> >     [INFO] Using 'UTF-8' encoding to copy filtered resources.
> >     [INFO] Copying 208 resources to
> > /home/lerroy/ovirt-engine-debug/frontend/webadmin/modules/webadmin/target/generated-sources/gwt
> >     [INFO] Copying 685 resources
> >     [INFO] Copying 136 resources to resources
> >     [INFO]
> >     [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @
> > webadmin ---
> >     [INFO] Compiling 45 source files to
> > /home/lerroy/ovirt-engine-debug/frontend/webadmin/modules/webadmin/target/webadmin-3.4.0-SNAPSHOT/WEB-INF/classes
> >     [INFO]
> >     [INFO] <<< gwt-maven-plugin:2.4.0:debug (default-cli) @ webadmin <<<
> >     [INFO]
> >     [INFO] --- gwt-maven-plugin:2.4.0:debug (default-cli) @ webadmin ---
> >     [INFO] starting debugger on port 8000 in suspend mode
> >     [WARNING] Don't declare gwt-dev as a project dependency. This may
> > introduce complex dependency conflicts
> >     [INFO] noServer is set! Skipping exploding war file...
> >     [INFO] Listening for transport dt_socket at address: 8000
> > 3.import ovirt into eclipse as "existing maven projects".
> > 4.In Eclipse:
> >     4.1."Run | Debug Configurations"
> >     4.2.Select "Remote Java Application" and click "New launch
> > configuration"
> >     4.3.On Connect tab, set Host="localhost" and Port="8000"
> >     4.4.On Source tab, click "Add | Java Project" and choose related
> > frontend projects
> > After set these infomations,click the "debug" button,the terminal shows
> > some errors as these:
> > [ERROR] [AppClassLoader at 11a40fff] info AspectJ Weaver Version 1.6.11
> > built on Tuesday Mar 15, 2011 at 15:31:04 GMT
> > [ERROR] [AppClassLoader at 11a40fff] info register classloader
> > sun.misc.Launcher$AppClassLoader at 11a40fff
> > [ERROR] [AppClassLoader at 11a40fff] info using configuration
> > file:/home/lerroy/.m2/repository/org/ovirt/engine/ui/gwt-extension/3.4.0-SNAPSHOT/gwt-extension-3.4.0-SNAPSHOT.jar!/META-INF/aop.xml
> > [ERROR] [AppClassLoader at 11a40fff] info using configuration
> > file:/home/lerroy/.m2/repository/org/ovirt/engine/ui/gwt-extension/3.4.0-SNAPSHOT/gwt-extension-3.4.0-SNAPSHOT-sources.jar!/META-INF/aop.xml
> >
> > [ERROR] [AppClassLoader at 11a40fff] info register aspect
> > org.ovirt.engine.ui.gwtextension.DontPrune
> > [ERROR] [AppClassLoader at 11a40fff] info register aspect
> > org.ovirt.engine.ui.gwtextension.DontPrune
> > [ERROR] [MethodUtil at 3d2bde69] info AspectJ Weaver Version 1.6.11 built on
> > Tuesday Mar 15, 2011 at 15:31:04 GMT
> > [ERROR] [MethodUtil at 3d2bde69] info register classloader
> > sun.reflect.misc.MethodUtil at 3d2bde69
> > [ERROR] [MethodUtil at 3d2bde69] info using configuration
> > file:/home/lerroy/.m2/repository/org/ovirt/engine/ui/gwt-extension/3.4.0-SNAPSHOT/gwt-extension-3.4.0-SNAPSHOT.jar!/META-INF/aop.xml
> > [ERROR] [MethodUtil at 3d2bde69] info using configuration
> > file:/home/lerroy/.m2/repository/org/ovirt/engine/ui/gwt-extension/3.4.0-SNAPSHOT/gwt-extension-3.4.0-SNAPSHOT-sources.jar!/META-INF/aop.xml
> > [ERROR] [MethodUtil at 3d2bde69] info register aspect
> > org.ovirt.engine.ui.gwtextension.DontPrune
> > [ERROR] [MethodUtil at 3d2bde69] info register aspect
> > org.ovirt.engine.ui.gwtextension.DontPrune
> >
> > when  compile the ovirt-engine with command "make clean install-dev
> > PREFIX=$HOME/ovirt-engine", I get the same error "[ERROR]
> > [MethodUtil at 3d2bde69] info register aspect
> > org.ovirt.engine.ui.gwtextension.DontPrune",but it still can be install
> > successfully and run stably.
> > So,my problem is how to resolve this error inorder to debug the
> > ovirt-frontend and backend.Thank you very much!
> >
> >
> > 2014-03-26 21:32 GMT+08:00 Gilad Chaplik <gchaplik at redhat.com>:
> >
> > np :-)
> >>
> >> Thanks,
> >> Gilad.
> >>
> >>
> >> ----- Original Message -----
> >> > From: "???" <pengchunhong at gmail.com>
> >> > To: "Gilad Chaplik" <gchaplik at redhat.com>
> >> > Sent: Wednesday, March 26, 2014 1:29:18 PM
> >> > Subject: Re: [Engine-devel] debug ovirt-engine
> >> >
> >> > OK,thank for your instructs,I will try them.
> >> >
> >> >
> >> > 2014-03-26 18:45 GMT+08:00 Gilad Chaplik <gchaplik at redhat.com>:
> >> >
> >> > > btw, at least with eclipse you can debug both client and server
> >> together
> >> > > (two debug instances, port 8787 and 8000)
> >> > > note that debugging the client takes time!! don't be intimidated 8-)
> >> > >
> >> > > Thanks,
> >> > > Gilad.
> >> > >
> >> > > ----- Original Message -----
> >> > > > From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <
> >> > > chuan.liao at hp.com>
> >> > > > To: "???" <pengchunhong at gmail.com>, engine-devel at ovirt.org
> >> > > > Sent: Wednesday, March 26, 2014 10:43:13 AM
> >> > > > Subject: Re: [Engine-devel] debug ovirt-engine
> >> > > >
> >> > > >
> >> > > >
> >> > > > Hi,
> >> > > >
> >> > > >
> >> > > >
> >> > > > Do you go through the wiki page OVirt Engine Development Environment
> >> > > >
> >> > > > http://www.ovirt.org/OVirt_Engine_Development_Environment
> >> > > >
> >> > > >
> >> > > >
> >> > > > you can debug with
> >> > > >
> >> > > > Debug port is available via port 8787, to be used by Eclipse or any
> >> other
> >> > > > debugger.
> >> > > >
> >> > > >
> >> > > >
> >> > > > Best Regards,
> >> > > > Jason Liao
> >> > > >
> >> > > >
> >> > > >
> >> > > > From: engine-devel-bounces at ovirt.org [mailto:
> >> > > engine-devel-bounces at ovirt.org]
> >> > > > On Behalf Of ???
> >> > > > Sent: 2014 ? 3 ? 26 ? 16:13
> >> > > > To: engine-devel at ovirt.org
> >> > > > Subject: [Engine-devel] debug ovirt-engine
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > Hello,everybody.when I develop with ovirt-engine,I have meet some
> >> > > obstacles
> >> > > > because of without the debug environment. So I really want to know
> >> how to
> >> > > > debug the frontend and backend of ovirt-engine by break points or by
> >> > > step .
> >> > > > Thank you for help!
> >> > > >
> >> > > > _______________________________________________
> >> > > > Engine-devel mailing list
> >> > > > Engine-devel at ovirt.org
> >> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>


From emesika at redhat.com  Thu Mar 27 11:43:22 2014
From: emesika at redhat.com (Eli Mesika)
Date: Thu, 27 Mar 2014 07:43:22 -0400 (EDT)
Subject: [Engine-devel] Change in ovirt-engine[master]: core: enable to
 decrease DC compatibility...
In-Reply-To: <1761608621.98742.1395578873460.JavaMail.zimbra@redhat.com>
References: <gerrit.1392716300399.I73284f641b7f80b380b39efbbd7b4566f55119b6@gerrit.ovirt.org>
	<5320C4A9.5010209@redhat.com>
	<577568761.2861329.1394657047677.JavaMail.zimbra@redhat.com>
	<1789679933.641640.1395343205633.JavaMail.zimbra@redhat.com>
	<532BDD57.1090604@redhat.com>
	<1810385690.186069.1395569606128.JavaMail.zimbra@redhat.com>
	<532EB40D.5050202@redhat.com>
	<1761608621.98742.1395578873460.JavaMail.zimbra@redhat.com>
Message-ID: <756890458.3439238.1395920602583.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Moti Asayag" <masayag at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: "Eli Mesika" <emesika at redhat.com>, engine-devel at ovirt.org
> Sent: Sunday, March 23, 2014 2:47:53 PM
> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...
> 
> 
> 
> ----- Original Message -----
> > From: "Itamar Heim" <iheim at redhat.com>
> > To: "Eli Mesika" <emesika at redhat.com>, engine-devel at ovirt.org
> > Sent: Sunday, March 23, 2014 12:14:37 PM
> > Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to
> > decrease DC compatibility...
> > 
> > On 03/23/2014 12:13 PM, Eli Mesika wrote:
> > >
> > > So, as far a I understand for resolving this bug the following is OK :
> > >
> > > Block downgrading if there are Hosts or Networks (other than the default
> > > management network) or SD in the DC when downgrading.
> > 
> > yes
> > 
> 
> I don't think it is enough. There is a need to verify the management network
> wasn't modified to use unsupported features in the new data-center.
> 
> On the same matter, we can allow downgrading if all of the networks in the
> data center are using only features that are supported on the target DC
> version
> and not to restrict it only to the management network.

Since Moti is in PTO, talked with Mike K to get advanced with that , we came to the following conclusion:

when DC is downgraded :
 Block downgrading if there are Hosts or Networks (other than the default management network) or SD in the DC.
 In case that only default management network exists we should check that all network features are still supported (This can be done by adding a method to the NetworkValidator that will check for support of all relevant features)

when Cluster is downgraded :
 Same as above , but we don't need to check for features validation since we can not downgrade below the DC version and therefor the cluster network is supposed to be valid already

Mike, please let me know If I miss something from our discussion (and thanks for your kind help :-) )

> 
> > >
> > >
> > > ----- Original Message -----
> > >> From: "Livnat Peer" <lpeer at redhat.com>
> > >> To: "Moti Asayag" <masayag at redhat.com>
> > >> Cc: engine-devel at ovirt.org
> > >> Sent: Friday, March 21, 2014 8:33:59 AM
> > >> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable
> > >> to decrease DC compatibility...
> > >>
> > >> On 03/20/2014 09:20 PM, Moti Asayag wrote:
> > >>> ----- Original Message -----
> > >>>> From: "Moti Asayag" <masayag at redhat.com>
> > >>>> To: "Livnat Peer" <lpeer at redhat.com>
> > >>>> Cc: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
> > >>>> Sent: Wednesday, March 12, 2014 10:44:07 PM
> > >>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core:
> > >>>> enable
> > >>>> to decrease DC compatibility...
> > >>>>
> > >>>>
> > >>>>
> > >>>> ----- Original Message -----
> > >>>>> From: "Livnat Peer" <lpeer at redhat.com>
> > >>>>> To: "Moti Asayag" <masayag at redhat.com>
> > >>>>> Cc: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
> > >>>>> Sent: Wednesday, March 12, 2014 10:33:45 PM
> > >>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core:
> > >>>>> enable
> > >>>>> to
> > >>>>> decrease DC compatibility...
> > >>>>>
> > >>>>> On 03/12/2014 10:20 PM, Moti Asayag wrote:
> > >>>>>>
> > >>>>>>
> > >>>>>> ----- Original Message -----
> > >>>>>>> From: "Livnat Peer" <lpeer at redhat.com>
> > >>>>>>> To: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
> > >>>>>>> Sent: Wednesday, March 12, 2014 12:42:44 PM
> > >>>>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core:
> > >>>>>>> enable
> > >>>>>>> to	decrease DC compatibility...
> > >>>>>>>
> > >>>>>>> On 03/12/2014 11:59 AM, Itamar Heim wrote:
> > >>>>>>>> On 03/12/2014 12:26 AM, emesika at redhat.com wrote:
> > >>>>>>>>> Eli Mesika has submitted this change and it was merged.
> > >>>>>>>>>
> > >>>>>>>>> Change subject: core: enable to decrease DC compatibility...
> > >>>>>>>>> ......................................................................
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> core: enable to decrease DC compatibility...
> > >>>>>>>>>
> > >>>>>>>>> enable to decrease DC compatibility version if DC has no clusters
> > >>>>>>>>>
> > >>>>>>>>> This patch enables to decrease the DC compatibility version if DC
> > >>>>>>>>> has
> > >>>>>>>>> no
> > >>>>>>>>> clusters.
> > >>>>>>>>
> > >>>>>>>> Eli - just saw this. I'm pretty sure it would be *bad* to
> > >>>>>>>> downgrade
> > >>>>>>>> a
> > >>>>>>>> DC
> > >>>>>>>> version if it has storage domains as well. not sure if this is
> > >>>>>>>> checked
> > >>>>>>>> already or not.
> > >>>>>>>>
> > >>>>>>>> may also be an issue with some logical network features.
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>> Most of the network features are driven from cluster level, we
> > >>>>>>> enable
> > >>>>>>> using the features on all DC level (actually >=3.1) but actually
> > >>>>>>> enable
> > >>>>>>> /disable the feature when attaching the network to a cluster.
> > >>>>>>>
> > >>>>>>> So from network perspective I think it should be fine to downgrade
> > >>>>>>> the
> > >>>>>>> DC level even if there are networks in the DC (at least now this
> > >>>>>>> could
> > >>>>>>> change in future versions).
> > >>>>>>>
> > >>>>>>
> > >>>>>> Actually we block adding or updating networks if the feature is not
> > >>>>>> supported
> > >>>>>> on the network's DC level, for example: STP, Jumbo frames and non-vm
> > >>>>>> network.
> > >>>>>>
> > >>>>>
> > >>>>>  From which DC level we support STP?  Jumbo frames? non-vm network?
> > >>>>>  isn't
> > >>>>> all of them supported in >=3.1 ?
> > >>>>>
> > >>>>
> > >>>> Yes, mainly the problem with downgrading a DC to 3.0.
> > >>>>
> > >>>
> > >>> I had a discussion with Mike (cc'ed) about several possible solutions
> > >>> for the networks compatibility within the data-center.
> > >>>
> > >>> The first proposed solution would utilize the NetworkUpdateValidator,
> > >>> a validation utility that verifies the compatibility of a network
> > >>> to the data-center. This solution preserves the same behaviour as
> > >>> today,
> > >>> that the features of network-level are dictated by the DC version. No
> > >>> need to reimplement any logic in the decrease DC version flow, just use
> > >>> an existing one to be applied for any network within the DC.
> > >>>
> > >>> The second solution suggests we allow any settings of a network, and
> > >>> compatibility enforcement is done on attaching the network to the
> > >>> clusters.
> > >>> This modifies the existing behaviour and expands the capabilities of
> > >>> the
> > >>> engine to support advanced network feature in advanced cluster within
> > >>> an
> > >>> old data center (i.e. cluster 3.4 in 3.0 data-center could and probably
> > >>> should use non-vm network, jumbo-frames and more).
> > >>> This option requires more work in add/update network and attach network
> > >>> to
> > >>> cluster
> > >>> flows, both on the backend and UI. Specifically since by default a new
> > >>> network
> > >>> created in a DC is being attached to all of the clusters.
> > >>> Perhaps the second option deserves to be treated as RFE and not as a
> > >>> bug
> > >>> fix.
> > >>>
> > >>> Thoughts ?
> > >>>
> > >>
> > >> The second approach you suggested is equivalent to creating networks in
> > >> cluster level vs. DC level, which is used today.
> > >>
> > >> We should consider that for 4.0 and think on the pros and cons of doing
> > >> so.
> > >>
> > >> In general for this specific discussion I think a simple block on DC
> > >> downgrade should be enough.
> > >>
> > >>> Moti
> > >>>
> > >>>>>> Therefore if the management network was configured with any of those
> > >>>>>> feature,
> > >>>>>> there is a need to either block the action or to 'initialize' the
> > >>>>>> network
> > >>>>>> to
> > >>>>>> the default settings (as new network being added).
> > >>>>>>
> > >>>>>>> In general I believe the use case for this patch is mostly for
> > >>>>>>> empty
> > >>>>>>> DCs
> > >>>>>>> so for simplicity we should block it if there are networks or SD in
> > >>>>>>> the
> > >>>>>>> DC when downgrading.
> > >>>>>>>
> > >>>>>>> Livnat
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> Change-Id: I73284f641b7f80b380b39efbbd7b4566f55119b6
> > >>>>>>>>> Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1057029
> > >>>>>>>>> Signed-off-by: Eli Mesika <emesika at redhat.com>
> > >>>>>>>>> ---
> > >>>>>>>>> M
> > >>>>>>>>> backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/storage/UpdateStoragePoolCommand.java
> > >>>>>>>>>
> > >>>>>>>>> 1 file changed, 5 insertions(+), 2 deletions(-)
> > >>>>>>>>>
> > >>>>>>>>> Approvals:
> > >>>>>>>>>     Eli Mesika: Verified
> > >>>>>>>>>     Ravi Nori: Looks good to me, but someone else must approve
> > >>>>>>>>>     Yair Zaslavsky: Looks good to me, approved
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>> _______________________________________________
> > >>>>>>> Engine-devel mailing list
> > >>>>>>> Engine-devel at ovirt.org
> > >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >>>>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>> _______________________________________________
> > >>> Engine-devel mailing list
> > >>> Engine-devel at ovirt.org
> > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >>>
> > >>>
> > >>
> > >> _______________________________________________
> > >> Engine-devel mailing list
> > >> Engine-devel at ovirt.org
> > >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >>
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From djasa at redhat.com  Thu Mar 27 11:55:36 2014
From: djasa at redhat.com (David =?UTF-8?Q?Ja=C5=A1a?=)
Date: Thu, 27 Mar 2014 12:55:36 +0100
Subject: [Engine-devel] REST API - where did bookmarks go?
In-Reply-To: <697764909.8511552.1395840461262.JavaMail.zimbra@redhat.com>
References: <281801554.17527047.1394561704228.JavaMail.zimbra@redhat.com>
	<531F546B.8050104@redhat.com>
	<113223800.17954619.1394623639126.JavaMail.zimbra@redhat.com>
	<1326606294.6546859.1395674882071.JavaMail.zimbra@redhat.com>
	<1395835186.30336.9.camel@cihla>
	<697764909.8511552.1395840461262.JavaMail.zimbra@redhat.com>
Message-ID: <1395921336.20135.5.camel@cihla>

On St, 2014-03-26 at 09:27 -0400, Gilad Chaplik wrote:
> ----- Original Message -----
> > From: "David Ja?a" <djasa at redhat.com>
> > To: "Gilad Chaplik" <gchaplik at redhat.com>
> > Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen" <ecohen at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> > Sent: Wednesday, March 26, 2014 1:59:46 PM
> > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > 
> > I don't use bookmarks in RHEV-M but if I did, I wouldn't be pleased if I
> > had to use another computer when things go wrong and in addition, engine
> > wouldn't give me my bookmarks... IMO if bookmarks are to stay, they
> > should be server-side.
> 
> I think that browser's bookmarks are much more advanced, sophisticated and native;
> i.e. I'd rather have in my browser a bookmark to down HA VMs search, instead of:
> - opening the application
> - open the bookmarks tab
> - searching the bookmark
> * and that's after I know how to use it (I've read the manual[??]/wasted time in playing with it), and remember how to use it from time to time. 

OK, that's an argument for no bookmarks in webadmin. My point was for
client-side vs. server-side webadmin bookmarks.

Actually, my point is also valid for webadmin bookmarks vs. browser
bookmarks - imagine you have to do something urgent and the only thing
is say private browser tab of your colleaugues machine. With webadmin
bookmarks, you have everything at hand. With browser-based bookmarks,
you essentially lose them till you come to some sync'd browser.

David

> 
> > 
> > David
> > 
> > On Po, 2014-03-24 at 11:28 -0400, Gilad Chaplik wrote:
> > > Hi Guys,
> > > 
> > > Why we need bookmarks in API? a single liner that points out to another
> > > single liner?
> > > I know that we need it for 'UI over REST' migration, but...
> > > IMHO bookmarks should be saved in client side, maybe inject the search
> > > string in the url, and get 'real' bookmarks/favorites... I don't know :-)
> > > 
> > > Thanks,
> > > Gilad.
> > > 
> > > ----- Original Message -----
> > > > From: "Vojtech Szocs" <vszocs at redhat.com>
> > > > To: "Juan Hernandez" <jhernand at redhat.com>
> > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Wednesday, March 12, 2014 1:27:19 PM
> > > > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Juan Hernandez" <jhernand at redhat.com>
> > > > > To: "Vojtech Szocs" <vszocs at redhat.com>, "engine-devel"
> > > > > <engine-devel at ovirt.org>
> > > > > Cc: "Einav Cohen" <ecohen at redhat.com>
> > > > > Sent: Tuesday, March 11, 2014 7:22:35 PM
> > > > > Subject: Re: REST API - where did bookmarks go?
> > > > > 
> > > > > On 03/11/2014 07:15 PM, Vojtech Szocs wrote:
> > > > > > Hi guys,
> > > > > > 
> > > > > > as part of prototyping new JavaScript binding for oVirt REST API,
> > > > > > we chose a couple of business entities (resources) to experiment
> > > > > > with.
> > > > > > 
> > > > > > I just realized that requesting /ovirt-engine/api doesn't return
> > > > > > any information about bookmarks. Where did bookmarks go? Is it
> > > > > > possible to manage bookmarks through REST API?
> > > > > > 
> > > > > > Note: WebAdmin currently gets bookmarks through GWT RPC by calling
> > > > > > GetAllBookmarksQuery. Bookmark seems like proper backend business
> > > > > > entity (with DAO and everything) so it should be exposed also via
> > > > > > REST API.. or am I missing something?
> > > > > > 
> > > > > > Thanks,
> > > > > > Vojtech
> > > > > > 
> > > > > 
> > > > > The didn't go anywhere, just never existed in the API. Please open a
> > > > > RFE
> > > > > to add them.
> > > > 
> > > > Thanks, Juan. The RFE is here:
> > > > 
> > > >   https://bugzilla.redhat.com/1075556
> > > > 
> > > > > 
> > > > > --
> > > > > Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> > > > > 3?D, 28016 Madrid, Spain
> > > > > Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat
> > > > > S.L.
> > > > > 
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> > 
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel




From gchaplik at redhat.com  Thu Mar 27 13:09:58 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Thu, 27 Mar 2014 09:09:58 -0400 (EDT)
Subject: [Engine-devel] REST API - where did bookmarks go?
In-Reply-To: <1395921336.20135.5.camel@cihla>
References: <281801554.17527047.1394561704228.JavaMail.zimbra@redhat.com>
	<531F546B.8050104@redhat.com>
	<113223800.17954619.1394623639126.JavaMail.zimbra@redhat.com>
	<1326606294.6546859.1395674882071.JavaMail.zimbra@redhat.com>
	<1395835186.30336.9.camel@cihla>
	<697764909.8511552.1395840461262.JavaMail.zimbra@redhat.com>
	<1395921336.20135.5.camel@cihla>
Message-ID: <2059414477.9345671.1395925798428.JavaMail.zimbra@redhat.com>



Thanks, 
Gilad.

----- Original Message -----
> From: "David Ja?a" <djasa at redhat.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, March 27, 2014 1:55:36 PM
> Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> 
> On St, 2014-03-26 at 09:27 -0400, Gilad Chaplik wrote:
> > ----- Original Message -----
> > > From: "David Ja?a" <djasa at redhat.com>
> > > To: "Gilad Chaplik" <gchaplik at redhat.com>
> > > Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen"
> > > <ecohen at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Wednesday, March 26, 2014 1:59:46 PM
> > > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > > 
> > > I don't use bookmarks in RHEV-M but if I did, I wouldn't be pleased if I
> > > had to use another computer when things go wrong and in addition, engine
> > > wouldn't give me my bookmarks... IMO if bookmarks are to stay, they
> > > should be server-side.
> > 
> > I think that browser's bookmarks are much more advanced, sophisticated and
> > native;
> > i.e. I'd rather have in my browser a bookmark to down HA VMs search,
> > instead of:
> > - opening the application
> > - open the bookmarks tab
> > - searching the bookmark
> > * and that's after I know how to use it (I've read the manual[??]/wasted
> > time in playing with it), and remember how to use it from time to time.
> 
> OK, that's an argument for no bookmarks in webadmin. My point was for
> client-side vs. server-side webadmin bookmarks.
> 
> Actually, my point is also valid for webadmin bookmarks vs. browser
> bookmarks - imagine you have to do something urgent and the only thing
> is say private browser tab of your colleaugues machine. With webadmin
> bookmarks, you have everything at hand. With browser-based bookmarks,
> you essentially lose them till you come to some sync'd browser.
> 
> David

Again I think it's a really rare use-case, we shouldn't base our UI on that.

> 
> > 
> > > 
> > > David
> > > 
> > > On Po, 2014-03-24 at 11:28 -0400, Gilad Chaplik wrote:
> > > > Hi Guys,
> > > > 
> > > > Why we need bookmarks in API? a single liner that points out to another
> > > > single liner?
> > > > I know that we need it for 'UI over REST' migration, but...
> > > > IMHO bookmarks should be saved in client side, maybe inject the search
> > > > string in the url, and get 'real' bookmarks/favorites... I don't know
> > > > :-)
> > > > 
> > > > Thanks,
> > > > Gilad.
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Vojtech Szocs" <vszocs at redhat.com>
> > > > > To: "Juan Hernandez" <jhernand at redhat.com>
> > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > Sent: Wednesday, March 12, 2014 1:27:19 PM
> > > > > Subject: Re: [Engine-devel] REST API - where did bookmarks go?
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Juan Hernandez" <jhernand at redhat.com>
> > > > > > To: "Vojtech Szocs" <vszocs at redhat.com>, "engine-devel"
> > > > > > <engine-devel at ovirt.org>
> > > > > > Cc: "Einav Cohen" <ecohen at redhat.com>
> > > > > > Sent: Tuesday, March 11, 2014 7:22:35 PM
> > > > > > Subject: Re: REST API - where did bookmarks go?
> > > > > > 
> > > > > > On 03/11/2014 07:15 PM, Vojtech Szocs wrote:
> > > > > > > Hi guys,
> > > > > > > 
> > > > > > > as part of prototyping new JavaScript binding for oVirt REST API,
> > > > > > > we chose a couple of business entities (resources) to experiment
> > > > > > > with.
> > > > > > > 
> > > > > > > I just realized that requesting /ovirt-engine/api doesn't return
> > > > > > > any information about bookmarks. Where did bookmarks go? Is it
> > > > > > > possible to manage bookmarks through REST API?
> > > > > > > 
> > > > > > > Note: WebAdmin currently gets bookmarks through GWT RPC by
> > > > > > > calling
> > > > > > > GetAllBookmarksQuery. Bookmark seems like proper backend business
> > > > > > > entity (with DAO and everything) so it should be exposed also via
> > > > > > > REST API.. or am I missing something?
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > Vojtech
> > > > > > > 
> > > > > > 
> > > > > > The didn't go anywhere, just never existed in the API. Please open
> > > > > > a
> > > > > > RFE
> > > > > > to add them.
> > > > > 
> > > > > Thanks, Juan. The RFE is here:
> > > > > 
> > > > >   https://bugzilla.redhat.com/1075556
> > > > > 
> > > > > > 
> > > > > > --
> > > > > > Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3,
> > > > > > planta
> > > > > > 3?D, 28016 Madrid, Spain
> > > > > > Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red
> > > > > > Hat
> > > > > > S.L.
> > > > > > 
> > > > > _______________________________________________
> > > > > Engine-devel mailing list
> > > > > Engine-devel at ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > >
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > > 
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
> 


From gchaplik at redhat.com  Thu Mar 27 14:17:59 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Thu, 27 Mar 2014 10:17:59 -0400 (EDT)
Subject: [Engine-devel] NUMA Support - GUI Technical Session
Message-ID: <1179159926.9393033.1395929878732.JavaMail.zimbra@redhat.com>

The following is a new meeting request:

Subject: NUMA Support - GUI Technical Session 
Organizer: "Gilad Chaplik" <gchaplik at redhat.com> 

Time: Monday, March 31, 2014, 5:30:00 PM - 6:30:00 PM GMT +02:00 Jerusalem
 
Required: ecohen at redhat.com; awels at redhat.com 
Optional: dfediuck at redhat.com; lvernia at redhat.com; engine-devel at ovirt.org; msivak at redhat.com; chuan.liao at hp.com; xiao-lei.shi at hp.com; chegu_vinod at hp.com; da-huai.tang at hp.com 

*~*~*~*~*~*~*~*~*~*

We will discuss on how to implement NUMA support GUI in oVirt for version 3.5 (see attached sketches).

Agenda:
1) Brainstorming
2) Resolution
3) Split work/tasks among volunteers :)

GUI maintainers please join-in.

Bluejeans (video conference) session to follow [maybe], currently dial in:

https://www.intercallonline.com/listNumbersByCode.action?confCode=7128867405

conf id: 712 886 7405#
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 2866 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140327/3381cbaa/attachment.ics>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: numa-support-sketches.zip
Type: application/zip
Size: 1754115 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140327/3381cbaa/attachment.zip>

From lxfwill1988 at gmail.com  Fri Mar 28 06:36:48 2014
From: lxfwill1988 at gmail.com (marco lin)
Date: Fri, 28 Mar 2014 14:36:48 +0800
Subject: [Engine-devel] ovirtengine connect node
Message-ID: <CALknHWkBHez-W=iTJ4X055kFtMOjtgQBHNiMrkcnVthAxmvs8w@mail.gmail.com>

st node1 is compatible with versions (3.0,3.1,3.2,3.3) and cannot join
Cluster Default which is set to version 3.4.  How to solve?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140328/8afc3152/attachment.html>

From lxfwill1988 at gmail.com  Fri Mar 28 06:42:13 2014
From: lxfwill1988 at gmail.com (marco lin)
Date: Fri, 28 Mar 2014 14:42:13 +0800
Subject: [Engine-devel] versions (3.0, 3.1, 3.2,
 3.3) and cannot join Cluster Default which is set to version 3.4.
Message-ID: <CALknHWnfG8D7WAqw9y4bbxZ3_jV+h5OR4_JN2Gd=CnorvGUA=A@mail.gmail.com>

st yyy is compatible with versions (3.0,3.1,3.2,3.3) and cannot join
Cluster Default which is set to version 3.4.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140328/30b32fe9/attachment.html>

From sbonazzo at redhat.com  Fri Mar 28 09:25:20 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Fri, 28 Mar 2014 10:25:20 +0100
Subject: [Engine-devel] [QE] oVirt 3.3.5 RC status
Message-ID: <53354000.8010807@redhat.com>

Hi,
  we're going to start composing 3.3.5 RC yum repository on 2014-04-02 09:00 UTC
following the published timeline [1]

A bug tracker is available at [2] and it shows no bugs blocking the release

The following is a list of the non-blocking bugs still open with target 3.3.5:
Whiteboard	Bug ID 	Status	Summary
gluster		1078200	NEW	Unable to create a volume with bricks in the root partiti...
infra		1072819	NEW	Accept old payload file syntax for backwards compatibility


Maintainers / Assignee:
Please build packages to be included in this RC *BEFORE* 2014-04-02 09:00 UTC. If not ready, latest nightly build will be used.
Please add the bugs to the tracker if you think that 3.3.5 should not be released without them fixed.
Please re-target all bugs you don't think that should block 3.3.5.
Bugs still targeted to 3.3.5 after RC announce will be re-targeted to 3.4.1.

For those who want to help testing the release, I suggest to add yourself to the testing page [3].
Nightly builds are available as described in [1]

Maintainers are welcomed to start filling release notes, the page has been created here [4]

[1] http://www.ovirt.org/OVirt_3.3.z_release-management
[2] http://bugzilla.redhat.com/1071867
[3] http://www.ovirt.org/Testing/Ovirt_3.3.5_testing
[4] http://www.ovirt.org/OVirt_3.3.5_release_notes

Thanks,

-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From emesika at redhat.com  Sat Mar 29 20:07:54 2014
From: emesika at redhat.com (Eli Mesika)
Date: Sat, 29 Mar 2014 16:07:54 -0400 (EDT)
Subject: [Engine-devel] versions (3.0, 3.1, 3.2,
 3.3) and cannot join Cluster Default which is set to version 3.4.
In-Reply-To: <CALknHWnfG8D7WAqw9y4bbxZ3_jV+h5OR4_JN2Gd=CnorvGUA=A@mail.gmail.com>
References: <CALknHWnfG8D7WAqw9y4bbxZ3_jV+h5OR4_JN2Gd=CnorvGUA=A@mail.gmail.com>
Message-ID: <1292354402.4639599.1396123673995.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "marco lin" <lxfwill1988 at gmail.com>
> To: engine-devel at ovirt.org
> Sent: Friday, March 28, 2014 9:42:13 AM
> Subject: [Engine-devel] versions (3.0, 3.1, 3.2, 3.3) and cannot join Cluster Default which is set to version 3.4.
> 
> st yyy is compatible with versions (3.0,3.1,3.2,3.3) and cannot join Cluster
> Default which is set to version 3.4.

Seems related to https://bugzilla.redhat.com/show_bug.cgi?id=1077110

> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From gchaplik at redhat.com  Sat Mar 29 23:06:59 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Sat, 29 Mar 2014 19:06:59 -0400 (EDT)
Subject: [Engine-devel] NUMA Support - GUI Technical Session
Message-ID: <1959694781.11106446.1396134419108.JavaMail.zimbra@redhat.com>

The following meeting has been modified:

Subject: NUMA Support - GUI Technical Session [MODIFIED]
Organizer: "Gilad Chaplik" <gchaplik at redhat.com> 

Time: Tuesday, April 1, 2014, 5:00:00 PM - 6:00:00 PM GMT +02:00 Jerusalem [MODIFIED]
 
Required: ecohen at redhat.com; awels at redhat.com; eedri at redhat.com; sgordon at redhat.com; emesika at redhat.com; otavio.ferranti at eldorado.org.br; sbonazzo at redhat.com; gshereme at redhat.com 
Optional: dfediuck at redhat.com; lvernia at redhat.com; engine-devel at ovirt.org; msivak at redhat.com; chuan.liao at hp.com; xiao-lei.shi at hp.com; chegu_vinod at hp.com; da-huai.tang at hp.com 

*~*~*~*~*~*~*~*~*~*

We will discuss on how to implement NUMA support GUI in oVirt for version 3.5 (see attached sketches). 

Agenda: 
1) Brainstorming 
2) Resolution 
3) Split work/tasks among volunteers :) 

GUI maintainers please join-in. 

Bluejeans (video conference) session to follow [maybe], currently dial in: 

https://www.intercallonline.com/listNumbersByCode.action?confCode=7128867405 

conf id: 712 886 7405# 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 3663 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140329/476efe76/attachment.ics>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: numa-support-sketches.zip
Type: application/zip
Size: 1754115 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140329/476efe76/attachment.zip>

From iheim at redhat.com  Sun Mar 30 11:14:09 2014
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 30 Mar 2014 14:14:09 +0300
Subject: [Engine-devel] versions (3.0, 3.1, 3.2,
 3.3) and cannot join Cluster Default which is set to version 3.4.
In-Reply-To: <1292354402.4639599.1396123673995.JavaMail.zimbra@redhat.com>
References: <CALknHWnfG8D7WAqw9y4bbxZ3_jV+h5OR4_JN2Gd=CnorvGUA=A@mail.gmail.com>
	<1292354402.4639599.1396123673995.JavaMail.zimbra@redhat.com>
Message-ID: <5337FC81.5090407@redhat.com>

On 03/29/2014 11:07 PM, Eli Mesika wrote:
>
>
> ----- Original Message -----
>> From: "marco lin" <lxfwill1988 at gmail.com>
>> To: engine-devel at ovirt.org
>> Sent: Friday, March 28, 2014 9:42:13 AM
>> Subject: [Engine-devel] versions (3.0, 3.1, 3.2, 3.3) and cannot join Cluster Default which is set to version 3.4.
>>
>> st yyy is compatible with versions (3.0,3.1,3.2,3.3) and cannot join Cluster
>> Default which is set to version 3.4.
>
> Seems related to https://bugzilla.redhat.com/show_bug.cgi?id=1077110
>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>

Eli - could we go with an approach similar to other fields of null 
compat version for default host/dc, and set it on first host which joins?


From aditya.mamidwar at gmail.com  Sun Mar 30 12:14:41 2014
From: aditya.mamidwar at gmail.com (aditya mamidwar)
Date: Sun, 30 Mar 2014 17:44:41 +0530
Subject: [Engine-devel] ui plugin problems, cannot read from a file.
Message-ID: <CA+pz529qjx3QA0kh5eHqAR4T2dftZ+LzKNj6hX6R3edp=vrqWg@mail.gmail.com>

hey, am trying to display the contents of a text file in a java applet as a
ui plugin in ovirt.

The same applet performs successfully when run as a standalone, but fails
to deliver when the it is run through ovirt.

any plausible explanation?
PFA the screenshot of both cases

-- 
-Aditya Mamidwar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140330/55c211a8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot-4.png
Type: image/png
Size: 171433 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140330/55c211a8/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot-5.png
Type: image/png
Size: 343590 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140330/55c211a8/attachment-0001.png>

From gshereme at redhat.com  Sun Mar 30 15:33:21 2014
From: gshereme at redhat.com (Greg Sheremeta)
Date: Sun, 30 Mar 2014 11:33:21 -0400 (EDT)
Subject: [Engine-devel] ui plugin problems, cannot read from a file.
In-Reply-To: <CA+pz529qjx3QA0kh5eHqAR4T2dftZ+LzKNj6hX6R3edp=vrqWg@mail.gmail.com>
References: <CA+pz529qjx3QA0kh5eHqAR4T2dftZ+LzKNj6hX6R3edp=vrqWg@mail.gmail.com>
Message-ID: <1650073732.4111784.1396193601291.JavaMail.zimbra@redhat.com>

I don't have any ideas. But: 

You really should use GWT to do this instead of an applet. I can't speak for everyone, and I'm not a maintainer, but I would not accept an applet into the ovirt-engine source code. It adds a very unnecessary dependency for the user (to have Java installed in the browser). 

Greg 

----- Original Message -----

> From: "aditya mamidwar" <aditya.mamidwar at gmail.com>
> To: users at ovirt.org, engine-devel at ovirt.org, awels at redhat.com, "Einav Cohen"
> <ecohen at redhat.com>, "Greg Sheremeta" <gshereme at redhat.com>
> Sent: Sunday, March 30, 2014 8:14:41 AM
> Subject: ui plugin problems, cannot read from a file.

> hey, am trying to display the contents of a text file in a java applet as a
> ui plugin in ovirt.

> The same applet performs successfully when run as a standalone, but fails to
> deliver when the it is run through ovirt.

> any plausible explanation?
> PFA the screenshot of both cases

> --
> -Aditya Mamidwar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140330/24e5be50/attachment.html>

From iheim at redhat.com  Mon Mar 31 04:58:33 2014
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 31 Mar 2014 07:58:33 +0300
Subject: [Engine-devel] ui plugin problems, cannot read from a file.
In-Reply-To: <1650073732.4111784.1396193601291.JavaMail.zimbra@redhat.com>
References: <CA+pz529qjx3QA0kh5eHqAR4T2dftZ+LzKNj6hX6R3edp=vrqWg@mail.gmail.com>
	<1650073732.4111784.1396193601291.JavaMail.zimbra@redhat.com>
Message-ID: <5338F5F9.8060904@redhat.com>

On 03/30/2014 06:33 PM, Greg Sheremeta wrote:
> I don't have any ideas. But:
>
> You really should use GWT to do this instead of an applet. I can't speak
> for everyone, and I'm not a maintainer, but I would not accept an applet
> into the ovirt-engine source code. It adds a very unnecessary dependency
> for the user (to have Java installed in the browser).
>

isn't one of the points of a uiplugin it doesn't have to be GWT based 
(as its not going to be part of the codebase)?

> Greg
>
>
> ------------------------------------------------------------------------
>
>     *From: *"aditya mamidwar" <aditya.mamidwar at gmail.com>
>     *To: *users at ovirt.org, engine-devel at ovirt.org, awels at redhat.com,
>     "Einav Cohen" <ecohen at redhat.com>, "Greg Sheremeta"
>     <gshereme at redhat.com>
>     *Sent: *Sunday, March 30, 2014 8:14:41 AM
>     *Subject: *ui plugin problems, cannot read from a file.
>
>
>
>     hey, am trying to display the contents of a text file in a java
>     applet as a ui plugin in ovirt.
>
>     The same applet performs successfully when run as a standalone, but
>     fails to deliver when the it is run through ovirt.
>
>     any plausible explanation?
>     PFA the screenshot of both cases
>
>     --
>     -Aditya Mamidwar
>
>
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>



From xiao-lei.shi at hp.com  Mon Mar 31 05:56:20 2014
From: xiao-lei.shi at hp.com (Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ))
Date: Mon, 31 Mar 2014 05:56:20 +0000
Subject: [Engine-devel] Please help us to review our database schema
 design with NUMA feature on ovirt
References: <B63C858E777679458338A30A991BB524015EB9D9@G1W3780.americas.hpqcorp.net>
	<780322931.181632.1395564237381.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DB5E2@G5W2743.americas.hpqcorp.net>
	<1290280076.419927.1395656626000.JavaMail.zimbra@redhat.com> 
Message-ID: <08AA403C8399104A89AF710307FA78AE243DD026@G5W2743.americas.hpqcorp.net>

Include the devel group.
Thanks Eli for the quick responses for our first design and sorry for the nag.
We appreciate any of the comments for our database design and will follow the design to do the implementation if no more comments.
 http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA

Thanks & Best Regards
Shi, Xiao-Lei (Bruce)

Hewlett-Packard Co., Ltd.
HP Servers Core Platform Software China 
Telephone +86 23 65683093
Mobile +86 18696583447
Email xiao-lei.shi at hp.com

-----Original Message-----
From: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) 
Sent: Friday, March 28, 2014 1:30 PM
To: 'Eli Mesika'
Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv Dary
Subject: RE: Please help us to review our database schema design with NUMA feature on ovirt

Hi Eli,

After the UX design meeting, we did some modification for the database schema, and merged some update according to your last review comments.
Now the document has been posted on ovirt wikipage, could you help to review the database design again:
http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA


Thanks & Best Regards
Shi, Xiao-Lei (Bruce)

Hewlett-Packard Co., Ltd.
HP Servers Core Platform Software China Telephone +86 23 65683093 Mobile +86 18696583447 Email xiao-lei.shi at hp.com


-----Original Message-----
From: Eli Mesika [mailto:emesika at redhat.com] 
Sent: Monday, March 24, 2014 6:24 PM
To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv Dary
Subject: Re: Please help us to review our database schema design with NUMA feature on ovirt



----- Original Message -----
> From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> To: "Eli Mesika" <emesika at redhat.com>, "Chuan Liao (Jason Liao, 
> HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik" 
> <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>, "Shang-Chun 
> Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>
> Sent: Monday, March 24, 2014 11:23:39 AM
> Subject: RE: Please help us to review our database schema design with 
> NUMA feature on ovirt
> 
> Hi Eli,
> 
> Thanks for your comments.
> I have updated the document according to your comments except the below one:
> Missing from here are 2 issues:
> 
> 1) Impact on the search engine, which new columns are search-able and 
> which changes are planned in the search engine code to enable that
> 
> 2) Impact on engine-reports, are those changed planned to be exposed 
> to the engine data warehouse and required new/modified reports?
> 
> Could you tell us more detailed information about the modules you 
> mentioned above? I mean "search engine" and "engine-reports". I think 
> we missed these two parts in our previous investigation.
> I just find org.ovirt.engine.core.bll.SearchQuery, is that the right 
> object for search engine?

Yes, actually when you are opening the admin UI, there are TABs for each entity , i.e. Data Center, Cluster, Host etc.
In each, you can see a text-box in which you can search for by writing a search expression My question is 
   1) What is the impact of your work on the search on the Fost and VM TABs 
      a) Are there any fields that are supported now in the search expression and should pop-up when you write the expression by the auto-completion mechanism ?
      b) Are there any added columns displayed in the result of such a search in the grid ?

> How about the engine-reports, could you give us some hints, like the 
> code location and any more detailed information that we can start more 
> investigation?

CCing Yaniv D who is in charge of the reports/dwh module Yaniv, any planned work for adding Numa features to Host/VM in the reports side ?

Thanks 

> 
> Thanks & Best Regards
> Shi, Xiao-Lei (Bruce)
> 
> Hewlett-Packard Co., Ltd.
> HP Servers Core Platform Software China Telephone +86 23 65683093 
> Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> 
> -----Original Message-----
> From: Eli Mesika [mailto:emesika at redhat.com]
> Sent: Sunday, March 23, 2014 4:44 PM
> To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
> Cc: Doron Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun 
> (David Liang, HPservers-Core-OE-PSC); Shi, Xiao-Lei (Bruce, HP 
> Servers-PSC-CQ)
> Subject: Re: Please help us to review our database schema design with 
> NUMA feature on ovirt
> 
> 
> 
> ----- Original Message -----
> > From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > <chuan.liao at hp.com>
> > To: emesika at redhat.com
> > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>, 
> > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" 
> > <shangchun.liang at hp.com>, "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" 
> > <xiao-lei.shi at hp.com>
> > Sent: Friday, March 21, 2014 10:42:33 AM
> > Subject: Please help us to review our database schema design with 
> > NUMA feature on ovirt
> > 
> > Hi Eli,
> > 
> > Please help us to review our database schema design with NUMA 
> > feature on ovirt
> > https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcmbGWAcyQo_IST
> > Y8
> > ykDr0I6VY/edit?usp=sharing
> > 
> > Feel free to take comments on document at anywhere
> 
> Done, had commented on the document.
> Eli
> 
> > 
> > Especially, 5.4 The used interface between engine core and
> > database(schema)
> > 
> > Your approve and your comments with this section will be much more 
> > appreciate for us.
> > 
> > Best Regards,
> > Jason Liao
> > 
> > 
> 

From emesika at redhat.com  Mon Mar 31 09:12:50 2014
From: emesika at redhat.com (Eli Mesika)
Date: Mon, 31 Mar 2014 05:12:50 -0400 (EDT)
Subject: [Engine-devel] Please help us to review our database schema
 design with NUMA feature on ovirt
In-Reply-To: <08AA403C8399104A89AF710307FA78AE243DD026@G5W2743.americas.hpqcorp.net>
References: <B63C858E777679458338A30A991BB524015EB9D9@G1W3780.americas.hpqcorp.net>
	<780322931.181632.1395564237381.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DB5E2@G5W2743.americas.hpqcorp.net>
	<1290280076.419927.1395656626000.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD026@G5W2743.americas.hpqcorp.net>
Message-ID: <1718882238.5076978.1396257170731.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>,
> "Gilad Chaplik" <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
> HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>, engine-devel at ovirt.org
> Sent: Monday, March 31, 2014 8:56:20 AM
> Subject: RE: Please help us to review our database schema design with NUMA feature on ovirt
> 
> Include the devel group.
> Thanks Eli for the quick responses for our first design and sorry for the
> nag.
> We appreciate any of the comments for our database design and will follow the
> design to do the implementation if no more comments.
>  http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA

Seems OK for me except an unanswered question I had asked in my first review :

Why in the Host level NUMA fields are added to vds_dynamic while in the VM level it is added to vm_static ???
I would expect it to be in both on static or dynamic , can you please explain ? Thanks 

> 
> Thanks & Best Regards
> Shi, Xiao-Lei (Bruce)
> 
> Hewlett-Packard Co., Ltd.
> HP Servers Core Platform Software China
> Telephone +86 23 65683093
> Mobile +86 18696583447
> Email xiao-lei.shi at hp.com
> 
> -----Original Message-----
> From: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> Sent: Friday, March 28, 2014 1:30 PM
> To: 'Eli Mesika'
> Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck; Gilad
> Chaplik; Vinod, Chegu; Liang, Shang-Chun (David Liang,
> HPservers-Core-OE-PSC); Yaniv Dary
> Subject: RE: Please help us to review our database schema design with NUMA
> feature on ovirt
> 
> Hi Eli,
> 
> After the UX design meeting, we did some modification for the database
> schema, and merged some update according to your last review comments.
> Now the document has been posted on ovirt wikipage, could you help to review
> the database design again:
> http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> 
> 
> Thanks & Best Regards
> Shi, Xiao-Lei (Bruce)
> 
> Hewlett-Packard Co., Ltd.
> HP Servers Core Platform Software China Telephone +86 23 65683093 Mobile +86
> 18696583447 Email xiao-lei.shi at hp.com
> 
> 
> -----Original Message-----
> From: Eli Mesika [mailto:emesika at redhat.com]
> Sent: Monday, March 24, 2014 6:24 PM
> To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck; Gilad
> Chaplik; Vinod, Chegu; Liang, Shang-Chun (David Liang,
> HPservers-Core-OE-PSC); Yaniv Dary
> Subject: Re: Please help us to review our database schema design with NUMA
> feature on ovirt
> 
> 
> 
> ----- Original Message -----
> > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > To: "Eli Mesika" <emesika at redhat.com>, "Chuan Liao (Jason Liao,
> > HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>, "Shang-Chun
> > Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>
> > Sent: Monday, March 24, 2014 11:23:39 AM
> > Subject: RE: Please help us to review our database schema design with
> > NUMA feature on ovirt
> > 
> > Hi Eli,
> > 
> > Thanks for your comments.
> > I have updated the document according to your comments except the below
> > one:
> > Missing from here are 2 issues:
> > 
> > 1) Impact on the search engine, which new columns are search-able and
> > which changes are planned in the search engine code to enable that
> > 
> > 2) Impact on engine-reports, are those changed planned to be exposed
> > to the engine data warehouse and required new/modified reports?
> > 
> > Could you tell us more detailed information about the modules you
> > mentioned above? I mean "search engine" and "engine-reports". I think
> > we missed these two parts in our previous investigation.
> > I just find org.ovirt.engine.core.bll.SearchQuery, is that the right
> > object for search engine?
> 
> Yes, actually when you are opening the admin UI, there are TABs for each
> entity , i.e. Data Center, Cluster, Host etc.
> In each, you can see a text-box in which you can search for by writing a
> search expression My question is
>    1) What is the impact of your work on the search on the Fost and VM TABs
>       a) Are there any fields that are supported now in the search expression
>       and should pop-up when you write the expression by the auto-completion
>       mechanism ?
>       b) Are there any added columns displayed in the result of such a search
>       in the grid ?
> 
> > How about the engine-reports, could you give us some hints, like the
> > code location and any more detailed information that we can start more
> > investigation?
> 
> CCing Yaniv D who is in charge of the reports/dwh module Yaniv, any planned
> work for adding Numa features to Host/VM in the reports side ?
> 
> Thanks
> 
> > 
> > Thanks & Best Regards
> > Shi, Xiao-Lei (Bruce)
> > 
> > Hewlett-Packard Co., Ltd.
> > HP Servers Core Platform Software China Telephone +86 23 65683093
> > Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > 
> > -----Original Message-----
> > From: Eli Mesika [mailto:emesika at redhat.com]
> > Sent: Sunday, March 23, 2014 4:44 PM
> > To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
> > Cc: Doron Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun
> > (David Liang, HPservers-Core-OE-PSC); Shi, Xiao-Lei (Bruce, HP
> > Servers-PSC-CQ)
> > Subject: Re: Please help us to review our database schema design with
> > NUMA feature on ovirt
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > <chuan.liao at hp.com>
> > > To: emesika at redhat.com
> > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
> > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > <shangchun.liang at hp.com>, "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > <xiao-lei.shi at hp.com>
> > > Sent: Friday, March 21, 2014 10:42:33 AM
> > > Subject: Please help us to review our database schema design with
> > > NUMA feature on ovirt
> > > 
> > > Hi Eli,
> > > 
> > > Please help us to review our database schema design with NUMA
> > > feature on ovirt
> > > https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcmbGWAcyQo_IST
> > > Y8
> > > ykDr0I6VY/edit?usp=sharing
> > > 
> > > Feel free to take comments on document at anywhere
> > 
> > Done, had commented on the document.
> > Eli
> > 
> > > 
> > > Especially, 5.4 The used interface between engine core and
> > > database(schema)
> > > 
> > > Your approve and your comments with this section will be much more
> > > appreciate for us.
> > > 
> > > Best Regards,
> > > Jason Liao
> > > 
> > > 
> > 
> 


From gchaplik at redhat.com  Mon Mar 31 09:21:44 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Mon, 31 Mar 2014 05:21:44 -0400 (EDT)
Subject: [Engine-devel] Please help us to review our database schema
 design with NUMA feature on ovirt
In-Reply-To: <1718882238.5076978.1396257170731.JavaMail.zimbra@redhat.com>
References: <B63C858E777679458338A30A991BB524015EB9D9@G1W3780.americas.hpqcorp.net>
	<780322931.181632.1395564237381.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DB5E2@G5W2743.americas.hpqcorp.net>
	<1290280076.419927.1395656626000.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD026@G5W2743.americas.hpqcorp.net>
	<1718882238.5076978.1396257170731.JavaMail.zimbra@redhat.com>
Message-ID: <182238414.11560689.1396257704986.JavaMail.zimbra@redhat.com>

+1

IMO: vds data should reside in static
VM need to think about it.

Roy?

Thanks, 
Gilad.


----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>,
> "Gilad Chaplik" <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
> HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>, engine-devel at ovirt.org
> Sent: Monday, March 31, 2014 12:12:50 PM
> Subject: Re: Please help us to review our database schema design with NUMA feature on ovirt
> 
> 
> 
> ----- Original Message -----
> > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > To: "Eli Mesika" <emesika at redhat.com>
> > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>,
> > "Doron Fediuck" <dfediuck at redhat.com>,
> > "Gilad Chaplik" <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
> > "Shang-Chun Liang (David Liang,
> > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > <ydary at redhat.com>, engine-devel at ovirt.org
> > Sent: Monday, March 31, 2014 8:56:20 AM
> > Subject: RE: Please help us to review our database schema design with NUMA
> > feature on ovirt
> > 
> > Include the devel group.
> > Thanks Eli for the quick responses for our first design and sorry for the
> > nag.
> > We appreciate any of the comments for our database design and will follow
> > the
> > design to do the implementation if no more comments.
> >  http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> 
> Seems OK for me except an unanswered question I had asked in my first review
> :
> 
> Why in the Host level NUMA fields are added to vds_dynamic while in the VM
> level it is added to vm_static ???
> I would expect it to be in both on static or dynamic , can you please explain
> ? Thanks
> 
> > 
> > Thanks & Best Regards
> > Shi, Xiao-Lei (Bruce)
> > 
> > Hewlett-Packard Co., Ltd.
> > HP Servers Core Platform Software China
> > Telephone +86 23 65683093
> > Mobile +86 18696583447
> > Email xiao-lei.shi at hp.com
> > 
> > -----Original Message-----
> > From: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > Sent: Friday, March 28, 2014 1:30 PM
> > To: 'Eli Mesika'
> > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck; Gilad
> > Chaplik; Vinod, Chegu; Liang, Shang-Chun (David Liang,
> > HPservers-Core-OE-PSC); Yaniv Dary
> > Subject: RE: Please help us to review our database schema design with NUMA
> > feature on ovirt
> > 
> > Hi Eli,
> > 
> > After the UX design meeting, we did some modification for the database
> > schema, and merged some update according to your last review comments.
> > Now the document has been posted on ovirt wikipage, could you help to
> > review
> > the database design again:
> > http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > 
> > 
> > Thanks & Best Regards
> > Shi, Xiao-Lei (Bruce)
> > 
> > Hewlett-Packard Co., Ltd.
> > HP Servers Core Platform Software China Telephone +86 23 65683093 Mobile
> > +86
> > 18696583447 Email xiao-lei.shi at hp.com
> > 
> > 
> > -----Original Message-----
> > From: Eli Mesika [mailto:emesika at redhat.com]
> > Sent: Monday, March 24, 2014 6:24 PM
> > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck; Gilad
> > Chaplik; Vinod, Chegu; Liang, Shang-Chun (David Liang,
> > HPservers-Core-OE-PSC); Yaniv Dary
> > Subject: Re: Please help us to review our database schema design with NUMA
> > feature on ovirt
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > > To: "Eli Mesika" <emesika at redhat.com>, "Chuan Liao (Jason Liao,
> > > HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>, "Shang-Chun
> > > Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>
> > > Sent: Monday, March 24, 2014 11:23:39 AM
> > > Subject: RE: Please help us to review our database schema design with
> > > NUMA feature on ovirt
> > > 
> > > Hi Eli,
> > > 
> > > Thanks for your comments.
> > > I have updated the document according to your comments except the below
> > > one:
> > > Missing from here are 2 issues:
> > > 
> > > 1) Impact on the search engine, which new columns are search-able and
> > > which changes are planned in the search engine code to enable that
> > > 
> > > 2) Impact on engine-reports, are those changed planned to be exposed
> > > to the engine data warehouse and required new/modified reports?
> > > 
> > > Could you tell us more detailed information about the modules you
> > > mentioned above? I mean "search engine" and "engine-reports". I think
> > > we missed these two parts in our previous investigation.
> > > I just find org.ovirt.engine.core.bll.SearchQuery, is that the right
> > > object for search engine?
> > 
> > Yes, actually when you are opening the admin UI, there are TABs for each
> > entity , i.e. Data Center, Cluster, Host etc.
> > In each, you can see a text-box in which you can search for by writing a
> > search expression My question is
> >    1) What is the impact of your work on the search on the Fost and VM TABs
> >       a) Are there any fields that are supported now in the search
> >       expression
> >       and should pop-up when you write the expression by the
> >       auto-completion
> >       mechanism ?
> >       b) Are there any added columns displayed in the result of such a
> >       search
> >       in the grid ?
> > 
> > > How about the engine-reports, could you give us some hints, like the
> > > code location and any more detailed information that we can start more
> > > investigation?
> > 
> > CCing Yaniv D who is in charge of the reports/dwh module Yaniv, any planned
> > work for adding Numa features to Host/VM in the reports side ?
> > 
> > Thanks
> > 
> > > 
> > > Thanks & Best Regards
> > > Shi, Xiao-Lei (Bruce)
> > > 
> > > Hewlett-Packard Co., Ltd.
> > > HP Servers Core Platform Software China Telephone +86 23 65683093
> > > Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > 
> > > -----Original Message-----
> > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > Sent: Sunday, March 23, 2014 4:44 PM
> > > To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
> > > Cc: Doron Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun
> > > (David Liang, HPservers-Core-OE-PSC); Shi, Xiao-Lei (Bruce, HP
> > > Servers-PSC-CQ)
> > > Subject: Re: Please help us to review our database schema design with
> > > NUMA feature on ovirt
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > <chuan.liao at hp.com>
> > > > To: emesika at redhat.com
> > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
> > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > <shangchun.liang at hp.com>, "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > <xiao-lei.shi at hp.com>
> > > > Sent: Friday, March 21, 2014 10:42:33 AM
> > > > Subject: Please help us to review our database schema design with
> > > > NUMA feature on ovirt
> > > > 
> > > > Hi Eli,
> > > > 
> > > > Please help us to review our database schema design with NUMA
> > > > feature on ovirt
> > > > https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcmbGWAcyQo_IST
> > > > Y8
> > > > ykDr0I6VY/edit?usp=sharing
> > > > 
> > > > Feel free to take comments on document at anywhere
> > > 
> > > Done, had commented on the document.
> > > Eli
> > > 
> > > > 
> > > > Especially, 5.4 The used interface between engine core and
> > > > database(schema)
> > > > 
> > > > Your approve and your comments with this section will be much more
> > > > appreciate for us.
> > > > 
> > > > Best Regards,
> > > > Jason Liao
> > > > 
> > > > 
> > > 
> > 
> 


From xiao-lei.shi at hp.com  Mon Mar 31 09:38:04 2014
From: xiao-lei.shi at hp.com (Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ))
Date: Mon, 31 Mar 2014 09:38:04 +0000
Subject: [Engine-devel] Please help us to review our database schema
 design with NUMA feature on ovirt
In-Reply-To: <182238414.11560689.1396257704986.JavaMail.zimbra@redhat.com>
References: <B63C858E777679458338A30A991BB524015EB9D9@G1W3780.americas.hpqcorp.net>
	<780322931.181632.1395564237381.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DB5E2@G5W2743.americas.hpqcorp.net>
	<1290280076.419927.1395656626000.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD026@G5W2743.americas.hpqcorp.net>
	<1718882238.5076978.1396257170731.JavaMail.zimbra@redhat.com>
	<182238414.11560689.1396257704986.JavaMail.zimbra@redhat.com>
Message-ID: <08AA403C8399104A89AF710307FA78AE243DD11A@G5W2743.americas.hpqcorp.net>

We put host level NUMA fields in vds_dynamic because these information are from host itself, and NUMA topology may be changed if the host's hardware make a change. NUMA information are similar to the host's cpu topology information like cpu_cores and cpu_sockets which are in vds_dynamic, we refer to this.
VM level NUMA fields are configured by user, and actually we originally think they should be in vm_dynamic. But we found that the field of another feature cpuPin which is similar as NUMA feature is in vm_static, so we put vm NUMA fields in vm_static. 
Do you think we need to put VM level NUMA fields in vm_dynamic?

Thanks & Best Regards
Shi, Xiao-Lei (Bruce)

Hewlett-Packard Co., Ltd.
HP Servers Core Platform Software China 
Telephone +86 23 65683093
Mobile +86 18696583447
Email xiao-lei.shi at hp.com


-----Original Message-----
From: Gilad Chaplik [mailto:gchaplik at redhat.com] 
Sent: Monday, March 31, 2014 5:22 PM
To: Eli Mesika; Roy Golan
Cc: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv Dary; engine-devel at ovirt.org
Subject: Re: Please help us to review our database schema design with NUMA feature on ovirt

+1

IMO: vds data should reside in static
VM need to think about it.

Roy?

Thanks, 
Gilad.


----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>,
> "Gilad Chaplik" <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
> HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>, engine-devel at ovirt.org
> Sent: Monday, March 31, 2014 12:12:50 PM
> Subject: Re: Please help us to review our database schema design with NUMA feature on ovirt
> 
> 
> 
> ----- Original Message -----
> > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > To: "Eli Mesika" <emesika at redhat.com>
> > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>,
> > "Doron Fediuck" <dfediuck at redhat.com>,
> > "Gilad Chaplik" <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
> > "Shang-Chun Liang (David Liang,
> > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > <ydary at redhat.com>, engine-devel at ovirt.org
> > Sent: Monday, March 31, 2014 8:56:20 AM
> > Subject: RE: Please help us to review our database schema design with NUMA
> > feature on ovirt
> > 
> > Include the devel group.
> > Thanks Eli for the quick responses for our first design and sorry for the
> > nag.
> > We appreciate any of the comments for our database design and will follow
> > the
> > design to do the implementation if no more comments.
> >  http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> 
> Seems OK for me except an unanswered question I had asked in my first review
> :
> 
> Why in the Host level NUMA fields are added to vds_dynamic while in the VM
> level it is added to vm_static ???
> I would expect it to be in both on static or dynamic , can you please explain
> ? Thanks
> 
> > 
> > Thanks & Best Regards
> > Shi, Xiao-Lei (Bruce)
> > 
> > Hewlett-Packard Co., Ltd.
> > HP Servers Core Platform Software China
> > Telephone +86 23 65683093
> > Mobile +86 18696583447
> > Email xiao-lei.shi at hp.com
> > 
> > -----Original Message-----
> > From: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > Sent: Friday, March 28, 2014 1:30 PM
> > To: 'Eli Mesika'
> > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck; Gilad
> > Chaplik; Vinod, Chegu; Liang, Shang-Chun (David Liang,
> > HPservers-Core-OE-PSC); Yaniv Dary
> > Subject: RE: Please help us to review our database schema design with NUMA
> > feature on ovirt
> > 
> > Hi Eli,
> > 
> > After the UX design meeting, we did some modification for the database
> > schema, and merged some update according to your last review comments.
> > Now the document has been posted on ovirt wikipage, could you help to
> > review
> > the database design again:
> > http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > 
> > 
> > Thanks & Best Regards
> > Shi, Xiao-Lei (Bruce)
> > 
> > Hewlett-Packard Co., Ltd.
> > HP Servers Core Platform Software China Telephone +86 23 65683093 Mobile
> > +86
> > 18696583447 Email xiao-lei.shi at hp.com
> > 
> > 
> > -----Original Message-----
> > From: Eli Mesika [mailto:emesika at redhat.com]
> > Sent: Monday, March 24, 2014 6:24 PM
> > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck; Gilad
> > Chaplik; Vinod, Chegu; Liang, Shang-Chun (David Liang,
> > HPservers-Core-OE-PSC); Yaniv Dary
> > Subject: Re: Please help us to review our database schema design with NUMA
> > feature on ovirt
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > > To: "Eli Mesika" <emesika at redhat.com>, "Chuan Liao (Jason Liao,
> > > HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>, "Shang-Chun
> > > Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>
> > > Sent: Monday, March 24, 2014 11:23:39 AM
> > > Subject: RE: Please help us to review our database schema design with
> > > NUMA feature on ovirt
> > > 
> > > Hi Eli,
> > > 
> > > Thanks for your comments.
> > > I have updated the document according to your comments except the below
> > > one:
> > > Missing from here are 2 issues:
> > > 
> > > 1) Impact on the search engine, which new columns are search-able and
> > > which changes are planned in the search engine code to enable that
> > > 
> > > 2) Impact on engine-reports, are those changed planned to be exposed
> > > to the engine data warehouse and required new/modified reports?
> > > 
> > > Could you tell us more detailed information about the modules you
> > > mentioned above? I mean "search engine" and "engine-reports". I think
> > > we missed these two parts in our previous investigation.
> > > I just find org.ovirt.engine.core.bll.SearchQuery, is that the right
> > > object for search engine?
> > 
> > Yes, actually when you are opening the admin UI, there are TABs for each
> > entity , i.e. Data Center, Cluster, Host etc.
> > In each, you can see a text-box in which you can search for by writing a
> > search expression My question is
> >    1) What is the impact of your work on the search on the Fost and VM TABs
> >       a) Are there any fields that are supported now in the search
> >       expression
> >       and should pop-up when you write the expression by the
> >       auto-completion
> >       mechanism ?
> >       b) Are there any added columns displayed in the result of such a
> >       search
> >       in the grid ?
> > 
> > > How about the engine-reports, could you give us some hints, like the
> > > code location and any more detailed information that we can start more
> > > investigation?
> > 
> > CCing Yaniv D who is in charge of the reports/dwh module Yaniv, any planned
> > work for adding Numa features to Host/VM in the reports side ?
> > 
> > Thanks
> > 
> > > 
> > > Thanks & Best Regards
> > > Shi, Xiao-Lei (Bruce)
> > > 
> > > Hewlett-Packard Co., Ltd.
> > > HP Servers Core Platform Software China Telephone +86 23 65683093
> > > Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > 
> > > -----Original Message-----
> > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > Sent: Sunday, March 23, 2014 4:44 PM
> > > To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
> > > Cc: Doron Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun
> > > (David Liang, HPservers-Core-OE-PSC); Shi, Xiao-Lei (Bruce, HP
> > > Servers-PSC-CQ)
> > > Subject: Re: Please help us to review our database schema design with
> > > NUMA feature on ovirt
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > <chuan.liao at hp.com>
> > > > To: emesika at redhat.com
> > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
> > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > <shangchun.liang at hp.com>, "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > <xiao-lei.shi at hp.com>
> > > > Sent: Friday, March 21, 2014 10:42:33 AM
> > > > Subject: Please help us to review our database schema design with
> > > > NUMA feature on ovirt
> > > > 
> > > > Hi Eli,
> > > > 
> > > > Please help us to review our database schema design with NUMA
> > > > feature on ovirt
> > > > https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcmbGWAcyQo_IST
> > > > Y8
> > > > ykDr0I6VY/edit?usp=sharing
> > > > 
> > > > Feel free to take comments on document at anywhere
> > > 
> > > Done, had commented on the document.
> > > Eli
> > > 
> > > > 
> > > > Especially, 5.4 The used interface between engine core and
> > > > database(schema)
> > > > 
> > > > Your approve and your comments with this section will be much more
> > > > appreciate for us.
> > > > 
> > > > Best Regards,
> > > > Jason Liao
> > > > 
> > > > 
> > > 
> > 
> 

From emesika at redhat.com  Mon Mar 31 09:48:52 2014
From: emesika at redhat.com (Eli Mesika)
Date: Mon, 31 Mar 2014 05:48:52 -0400 (EDT)
Subject: [Engine-devel] Please help us to review our database schema
 design with NUMA feature on ovirt
In-Reply-To: <08AA403C8399104A89AF710307FA78AE243DD11A@G5W2743.americas.hpqcorp.net>
References: <B63C858E777679458338A30A991BB524015EB9D9@G1W3780.americas.hpqcorp.net>
	<780322931.181632.1395564237381.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DB5E2@G5W2743.americas.hpqcorp.net>
	<1290280076.419927.1395656626000.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD026@G5W2743.americas.hpqcorp.net>
	<1718882238.5076978.1396257170731.JavaMail.zimbra@redhat.com>
	<182238414.11560689.1396257704986.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD11A@G5W2743.americas.hpqcorp.net>
Message-ID: <1087291412.5091657.1396259332718.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>, "Eli Mesika" <emesika at redhat.com>, "Roy Golan" <rgolan at redhat.com>
> Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>,
> "Chegu Vinod" <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>, engine-devel at ovirt.org
> Sent: Monday, March 31, 2014 12:38:04 PM
> Subject: RE: Please help us to review our database schema design with NUMA feature on ovirt
> 
> We put host level NUMA fields in vds_dynamic because these information are
> from host itself, and NUMA topology may be changed if the host's hardware
> make a change. NUMA information are similar to the host's cpu topology
> information like cpu_cores and cpu_sockets which are in vds_dynamic, we
> refer to this.
> VM level NUMA fields are configured by user, and actually we originally think
> they should be in vm_dynamic. But we found that the field of another feature
> cpuPin which is similar as NUMA feature is in vm_static, so we put vm NUMA
> fields in vm_static.
> Do you think we need to put VM level NUMA fields in vm_dynamic?

I think that in this case we should fix cpuPin to be in vm_dynamic and put after that the other NUMA fields in vm_dynamic as well 

> 
> Thanks & Best Regards
> Shi, Xiao-Lei (Bruce)
> 
> Hewlett-Packard Co., Ltd.
> HP Servers Core Platform Software China
> Telephone +86 23 65683093
> Mobile +86 18696583447
> Email xiao-lei.shi at hp.com
> 
> 
> -----Original Message-----
> From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> Sent: Monday, March 31, 2014 5:22 PM
> To: Eli Mesika; Roy Golan
> Cc: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Liao, Chuan (Jason Liao,
> HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang, Shang-Chun
> (David Liang, HPservers-Core-OE-PSC); Yaniv Dary; engine-devel at ovirt.org
> Subject: Re: Please help us to review our database schema design with NUMA
> feature on ovirt
> 
> +1
> 
> IMO: vds data should reside in static
> VM need to think about it.
> 
> Roy?
> 
> Thanks,
> Gilad.
> 
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>,
> > "Doron Fediuck" <dfediuck at redhat.com>,
> > "Gilad Chaplik" <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
> > "Shang-Chun Liang (David Liang,
> > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > <ydary at redhat.com>, engine-devel at ovirt.org
> > Sent: Monday, March 31, 2014 12:12:50 PM
> > Subject: Re: Please help us to review our database schema design with NUMA
> > feature on ovirt
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > > To: "Eli Mesika" <emesika at redhat.com>
> > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>,
> > > "Doron Fediuck" <dfediuck at redhat.com>,
> > > "Gilad Chaplik" <gchaplik at redhat.com>, "Chegu Vinod"
> > > <chegu_vinod at hp.com>,
> > > "Shang-Chun Liang (David Liang,
> > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > Sent: Monday, March 31, 2014 8:56:20 AM
> > > Subject: RE: Please help us to review our database schema design with
> > > NUMA
> > > feature on ovirt
> > > 
> > > Include the devel group.
> > > Thanks Eli for the quick responses for our first design and sorry for the
> > > nag.
> > > We appreciate any of the comments for our database design and will follow
> > > the
> > > design to do the implementation if no more comments.
> > >  http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > 
> > Seems OK for me except an unanswered question I had asked in my first
> > review
> > :
> > 
> > Why in the Host level NUMA fields are added to vds_dynamic while in the VM
> > level it is added to vm_static ???
> > I would expect it to be in both on static or dynamic , can you please
> > explain
> > ? Thanks
> > 
> > > 
> > > Thanks & Best Regards
> > > Shi, Xiao-Lei (Bruce)
> > > 
> > > Hewlett-Packard Co., Ltd.
> > > HP Servers Core Platform Software China
> > > Telephone +86 23 65683093
> > > Mobile +86 18696583447
> > > Email xiao-lei.shi at hp.com
> > > 
> > > -----Original Message-----
> > > From: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > Sent: Friday, March 28, 2014 1:30 PM
> > > To: 'Eli Mesika'
> > > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck; Gilad
> > > Chaplik; Vinod, Chegu; Liang, Shang-Chun (David Liang,
> > > HPservers-Core-OE-PSC); Yaniv Dary
> > > Subject: RE: Please help us to review our database schema design with
> > > NUMA
> > > feature on ovirt
> > > 
> > > Hi Eli,
> > > 
> > > After the UX design meeting, we did some modification for the database
> > > schema, and merged some update according to your last review comments.
> > > Now the document has been posted on ovirt wikipage, could you help to
> > > review
> > > the database design again:
> > > http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > > 
> > > 
> > > Thanks & Best Regards
> > > Shi, Xiao-Lei (Bruce)
> > > 
> > > Hewlett-Packard Co., Ltd.
> > > HP Servers Core Platform Software China Telephone +86 23 65683093 Mobile
> > > +86
> > > 18696583447 Email xiao-lei.shi at hp.com
> > > 
> > > 
> > > -----Original Message-----
> > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > Sent: Monday, March 24, 2014 6:24 PM
> > > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck; Gilad
> > > Chaplik; Vinod, Chegu; Liang, Shang-Chun (David Liang,
> > > HPservers-Core-OE-PSC); Yaniv Dary
> > > Subject: Re: Please help us to review our database schema design with
> > > NUMA
> > > feature on ovirt
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > > > To: "Eli Mesika" <emesika at redhat.com>, "Chuan Liao (Jason Liao,
> > > > HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>, "Shang-Chun
> > > > Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>
> > > > Sent: Monday, March 24, 2014 11:23:39 AM
> > > > Subject: RE: Please help us to review our database schema design with
> > > > NUMA feature on ovirt
> > > > 
> > > > Hi Eli,
> > > > 
> > > > Thanks for your comments.
> > > > I have updated the document according to your comments except the below
> > > > one:
> > > > Missing from here are 2 issues:
> > > > 
> > > > 1) Impact on the search engine, which new columns are search-able and
> > > > which changes are planned in the search engine code to enable that
> > > > 
> > > > 2) Impact on engine-reports, are those changed planned to be exposed
> > > > to the engine data warehouse and required new/modified reports?
> > > > 
> > > > Could you tell us more detailed information about the modules you
> > > > mentioned above? I mean "search engine" and "engine-reports". I think
> > > > we missed these two parts in our previous investigation.
> > > > I just find org.ovirt.engine.core.bll.SearchQuery, is that the right
> > > > object for search engine?
> > > 
> > > Yes, actually when you are opening the admin UI, there are TABs for each
> > > entity , i.e. Data Center, Cluster, Host etc.
> > > In each, you can see a text-box in which you can search for by writing a
> > > search expression My question is
> > >    1) What is the impact of your work on the search on the Fost and VM
> > >    TABs
> > >       a) Are there any fields that are supported now in the search
> > >       expression
> > >       and should pop-up when you write the expression by the
> > >       auto-completion
> > >       mechanism ?
> > >       b) Are there any added columns displayed in the result of such a
> > >       search
> > >       in the grid ?
> > > 
> > > > How about the engine-reports, could you give us some hints, like the
> > > > code location and any more detailed information that we can start more
> > > > investigation?
> > > 
> > > CCing Yaniv D who is in charge of the reports/dwh module Yaniv, any
> > > planned
> > > work for adding Numa features to Host/VM in the reports side ?
> > > 
> > > Thanks
> > > 
> > > > 
> > > > Thanks & Best Regards
> > > > Shi, Xiao-Lei (Bruce)
> > > > 
> > > > Hewlett-Packard Co., Ltd.
> > > > HP Servers Core Platform Software China Telephone +86 23 65683093
> > > > Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > 
> > > > -----Original Message-----
> > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > Sent: Sunday, March 23, 2014 4:44 PM
> > > > To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
> > > > Cc: Doron Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun
> > > > (David Liang, HPservers-Core-OE-PSC); Shi, Xiao-Lei (Bruce, HP
> > > > Servers-PSC-CQ)
> > > > Subject: Re: Please help us to review our database schema design with
> > > > NUMA feature on ovirt
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > <chuan.liao at hp.com>
> > > > > To: emesika at redhat.com
> > > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
> > > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > > <shangchun.liang at hp.com>, "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > <xiao-lei.shi at hp.com>
> > > > > Sent: Friday, March 21, 2014 10:42:33 AM
> > > > > Subject: Please help us to review our database schema design with
> > > > > NUMA feature on ovirt
> > > > > 
> > > > > Hi Eli,
> > > > > 
> > > > > Please help us to review our database schema design with NUMA
> > > > > feature on ovirt
> > > > > https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcmbGWAcyQo_IST
> > > > > Y8
> > > > > ykDr0I6VY/edit?usp=sharing
> > > > > 
> > > > > Feel free to take comments on document at anywhere
> > > > 
> > > > Done, had commented on the document.
> > > > Eli
> > > > 
> > > > > 
> > > > > Especially, 5.4 The used interface between engine core and
> > > > > database(schema)
> > > > > 
> > > > > Your approve and your comments with this section will be much more
> > > > > appreciate for us.
> > > > > 
> > > > > Best Regards,
> > > > > Jason Liao
> > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 


From xiao-lei.shi at hp.com  Mon Mar 31 12:20:33 2014
From: xiao-lei.shi at hp.com (Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ))
Date: Mon, 31 Mar 2014 12:20:33 +0000
Subject: [Engine-devel] Please help us to review our database schema
 design with NUMA feature on ovirt
In-Reply-To: <1087291412.5091657.1396259332718.JavaMail.zimbra@redhat.com>
References: <B63C858E777679458338A30A991BB524015EB9D9@G1W3780.americas.hpqcorp.net>
	<780322931.181632.1395564237381.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DB5E2@G5W2743.americas.hpqcorp.net>
	<1290280076.419927.1395656626000.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD026@G5W2743.americas.hpqcorp.net>
	<1718882238.5076978.1396257170731.JavaMail.zimbra@redhat.com>
	<182238414.11560689.1396257704986.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD11A@G5W2743.americas.hpqcorp.net>
	<1087291412.5091657.1396259332718.JavaMail.zimbra@redhat.com>
Message-ID: <08AA403C8399104A89AF710307FA78AE243DD16D@G5W2743.americas.hpqcorp.net>

Thanks Eli.
I will move the vm level NUMA fields to vm_dynamic, and the related database schema will be updated accordingly.

Thanks & Best Regards
Shi, Xiao-Lei (Bruce)

Hewlett-Packard Co., Ltd.
HP Servers Core Platform Software China 
Telephone +86 23 65683093
Mobile +86 18696583447
Email xiao-lei.shi at hp.com

-----Original Message-----
From: Eli Mesika [mailto:emesika at redhat.com] 
Sent: Monday, March 31, 2014 5:49 PM
To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
Cc: Gilad Chaplik; Roy Golan; Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv Dary; engine-devel at ovirt.org
Subject: Re: Please help us to review our database schema design with NUMA feature on ovirt



----- Original Message -----
> From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>, "Eli Mesika" 
> <emesika at redhat.com>, "Roy Golan" <rgolan at redhat.com>
> Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" 
> <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>, 
> engine-devel at ovirt.org
> Sent: Monday, March 31, 2014 12:38:04 PM
> Subject: RE: Please help us to review our database schema design with 
> NUMA feature on ovirt
> 
> We put host level NUMA fields in vds_dynamic because these information 
> are from host itself, and NUMA topology may be changed if the host's 
> hardware make a change. NUMA information are similar to the host's cpu 
> topology information like cpu_cores and cpu_sockets which are in 
> vds_dynamic, we refer to this.
> VM level NUMA fields are configured by user, and actually we 
> originally think they should be in vm_dynamic. But we found that the 
> field of another feature cpuPin which is similar as NUMA feature is in 
> vm_static, so we put vm NUMA fields in vm_static.
> Do you think we need to put VM level NUMA fields in vm_dynamic?

I think that in this case we should fix cpuPin to be in vm_dynamic and put after that the other NUMA fields in vm_dynamic as well 

> 
> Thanks & Best Regards
> Shi, Xiao-Lei (Bruce)
> 
> Hewlett-Packard Co., Ltd.
> HP Servers Core Platform Software China Telephone +86 23 65683093 
> Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> 
> 
> -----Original Message-----
> From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> Sent: Monday, March 31, 2014 5:22 PM
> To: Eli Mesika; Roy Golan
> Cc: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Liao, Chuan (Jason Liao,
> HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang, Shang-Chun
> (David Liang, HPservers-Core-OE-PSC); Yaniv Dary; engine-devel at ovirt.org
> Subject: Re: Please help us to review our database schema design with NUMA
> feature on ovirt
> 
> +1
> 
> IMO: vds data should reside in static
> VM need to think about it.
> 
> Roy?
> 
> Thanks,
> Gilad.
> 
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>,
> > "Doron Fediuck" <dfediuck at redhat.com>,
> > "Gilad Chaplik" <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
> > "Shang-Chun Liang (David Liang,
> > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > <ydary at redhat.com>, engine-devel at ovirt.org
> > Sent: Monday, March 31, 2014 12:12:50 PM
> > Subject: Re: Please help us to review our database schema design with NUMA
> > feature on ovirt
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > > To: "Eli Mesika" <emesika at redhat.com>
> > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>,
> > > "Doron Fediuck" <dfediuck at redhat.com>,
> > > "Gilad Chaplik" <gchaplik at redhat.com>, "Chegu Vinod"
> > > <chegu_vinod at hp.com>,
> > > "Shang-Chun Liang (David Liang,
> > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > Sent: Monday, March 31, 2014 8:56:20 AM
> > > Subject: RE: Please help us to review our database schema design with
> > > NUMA
> > > feature on ovirt
> > > 
> > > Include the devel group.
> > > Thanks Eli for the quick responses for our first design and sorry for the
> > > nag.
> > > We appreciate any of the comments for our database design and will follow
> > > the
> > > design to do the implementation if no more comments.
> > >  http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > 
> > Seems OK for me except an unanswered question I had asked in my first
> > review
> > :
> > 
> > Why in the Host level NUMA fields are added to vds_dynamic while in the VM
> > level it is added to vm_static ???
> > I would expect it to be in both on static or dynamic , can you please
> > explain
> > ? Thanks
> > 
> > > 
> > > Thanks & Best Regards
> > > Shi, Xiao-Lei (Bruce)
> > > 
> > > Hewlett-Packard Co., Ltd.
> > > HP Servers Core Platform Software China
> > > Telephone +86 23 65683093
> > > Mobile +86 18696583447
> > > Email xiao-lei.shi at hp.com
> > > 
> > > -----Original Message-----
> > > From: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > Sent: Friday, March 28, 2014 1:30 PM
> > > To: 'Eli Mesika'
> > > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck; Gilad
> > > Chaplik; Vinod, Chegu; Liang, Shang-Chun (David Liang,
> > > HPservers-Core-OE-PSC); Yaniv Dary
> > > Subject: RE: Please help us to review our database schema design with
> > > NUMA
> > > feature on ovirt
> > > 
> > > Hi Eli,
> > > 
> > > After the UX design meeting, we did some modification for the database
> > > schema, and merged some update according to your last review comments.
> > > Now the document has been posted on ovirt wikipage, could you help to
> > > review
> > > the database design again:
> > > http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > > 
> > > 
> > > Thanks & Best Regards
> > > Shi, Xiao-Lei (Bruce)
> > > 
> > > Hewlett-Packard Co., Ltd.
> > > HP Servers Core Platform Software China Telephone +86 23 65683093 Mobile
> > > +86
> > > 18696583447 Email xiao-lei.shi at hp.com
> > > 
> > > 
> > > -----Original Message-----
> > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > Sent: Monday, March 24, 2014 6:24 PM
> > > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck; Gilad
> > > Chaplik; Vinod, Chegu; Liang, Shang-Chun (David Liang,
> > > HPservers-Core-OE-PSC); Yaniv Dary
> > > Subject: Re: Please help us to review our database schema design with
> > > NUMA
> > > feature on ovirt
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > > > To: "Eli Mesika" <emesika at redhat.com>, "Chuan Liao (Jason Liao,
> > > > HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>, "Shang-Chun
> > > > Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>
> > > > Sent: Monday, March 24, 2014 11:23:39 AM
> > > > Subject: RE: Please help us to review our database schema design with
> > > > NUMA feature on ovirt
> > > > 
> > > > Hi Eli,
> > > > 
> > > > Thanks for your comments.
> > > > I have updated the document according to your comments except the below
> > > > one:
> > > > Missing from here are 2 issues:
> > > > 
> > > > 1) Impact on the search engine, which new columns are search-able and
> > > > which changes are planned in the search engine code to enable that
> > > > 
> > > > 2) Impact on engine-reports, are those changed planned to be exposed
> > > > to the engine data warehouse and required new/modified reports?
> > > > 
> > > > Could you tell us more detailed information about the modules you
> > > > mentioned above? I mean "search engine" and "engine-reports". I think
> > > > we missed these two parts in our previous investigation.
> > > > I just find org.ovirt.engine.core.bll.SearchQuery, is that the right
> > > > object for search engine?
> > > 
> > > Yes, actually when you are opening the admin UI, there are TABs for each
> > > entity , i.e. Data Center, Cluster, Host etc.
> > > In each, you can see a text-box in which you can search for by writing a
> > > search expression My question is
> > >    1) What is the impact of your work on the search on the Fost and VM
> > >    TABs
> > >       a) Are there any fields that are supported now in the search
> > >       expression
> > >       and should pop-up when you write the expression by the
> > >       auto-completion
> > >       mechanism ?
> > >       b) Are there any added columns displayed in the result of such a
> > >       search
> > >       in the grid ?
> > > 
> > > > How about the engine-reports, could you give us some hints, like the
> > > > code location and any more detailed information that we can start more
> > > > investigation?
> > > 
> > > CCing Yaniv D who is in charge of the reports/dwh module Yaniv, any
> > > planned
> > > work for adding Numa features to Host/VM in the reports side ?
> > > 
> > > Thanks
> > > 
> > > > 
> > > > Thanks & Best Regards
> > > > Shi, Xiao-Lei (Bruce)
> > > > 
> > > > Hewlett-Packard Co., Ltd.
> > > > HP Servers Core Platform Software China Telephone +86 23 65683093
> > > > Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > 
> > > > -----Original Message-----
> > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > Sent: Sunday, March 23, 2014 4:44 PM
> > > > To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
> > > > Cc: Doron Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun
> > > > (David Liang, HPservers-Core-OE-PSC); Shi, Xiao-Lei (Bruce, HP
> > > > Servers-PSC-CQ)
> > > > Subject: Re: Please help us to review our database schema design with
> > > > NUMA feature on ovirt
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > <chuan.liao at hp.com>
> > > > > To: emesika at redhat.com
> > > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
> > > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > > <shangchun.liang at hp.com>, "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > <xiao-lei.shi at hp.com>
> > > > > Sent: Friday, March 21, 2014 10:42:33 AM
> > > > > Subject: Please help us to review our database schema design with
> > > > > NUMA feature on ovirt
> > > > > 
> > > > > Hi Eli,
> > > > > 
> > > > > Please help us to review our database schema design with NUMA
> > > > > feature on ovirt
> > > > > https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcmbGWAcyQo_IST
> > > > > Y8
> > > > > ykDr0I6VY/edit?usp=sharing
> > > > > 
> > > > > Feel free to take comments on document at anywhere
> > > > 
> > > > Done, had commented on the document.
> > > > Eli
> > > > 
> > > > > 
> > > > > Especially, 5.4 The used interface between engine core and
> > > > > database(schema)
> > > > > 
> > > > > Your approve and your comments with this section will be much more
> > > > > appreciate for us.
> > > > > 
> > > > > Best Regards,
> > > > > Jason Liao
> > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 

From gshereme at redhat.com  Mon Mar 31 12:44:40 2014
From: gshereme at redhat.com (Greg Sheremeta)
Date: Mon, 31 Mar 2014 08:44:40 -0400 (EDT)
Subject: [Engine-devel] ui plugin problems, cannot read from a file.
In-Reply-To: <5338F5F9.8060904@redhat.com>
References: <CA+pz529qjx3QA0kh5eHqAR4T2dftZ+LzKNj6hX6R3edp=vrqWg@mail.gmail.com>
	<1650073732.4111784.1396193601291.JavaMail.zimbra@redhat.com>
	<5338F5F9.8060904@redhat.com>
Message-ID: <120474364.4263441.1396269880213.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Greg Sheremeta" <gshereme at redhat.com>, "aditya mamidwar" <aditya.mamidwar at gmail.com>
> Cc: engine-devel at ovirt.org, users at ovirt.org
> Sent: Monday, March 31, 2014 12:58:33 AM
> Subject: Re: [Engine-devel] ui plugin problems, cannot read from a file.
> 
> On 03/30/2014 06:33 PM, Greg Sheremeta wrote:
> > I don't have any ideas. But:
> >
> > You really should use GWT to do this instead of an applet. I can't speak
> > for everyone, and I'm not a maintainer, but I would not accept an applet
> > into the ovirt-engine source code. It adds a very unnecessary dependency
> > for the user (to have Java installed in the browser).
> >
> 
> isn't one of the points of a uiplugin it doesn't have to be GWT based
> (as its not going to be part of the codebase)?
> 
Ah, yes, of course :)
So please disregard my comment.
/me and his bruised ego steps away from engine-devel

Greg

> > Greg
> >
> >
> > ------------------------------------------------------------------------
> >
> >     *From: *"aditya mamidwar" <aditya.mamidwar at gmail.com>
> >     *To: *users at ovirt.org, engine-devel at ovirt.org, awels at redhat.com,
> >     "Einav Cohen" <ecohen at redhat.com>, "Greg Sheremeta"
> >     <gshereme at redhat.com>
> >     *Sent: *Sunday, March 30, 2014 8:14:41 AM
> >     *Subject: *ui plugin problems, cannot read from a file.
> >
> >
> >
> >     hey, am trying to display the contents of a text file in a java
> >     applet as a ui plugin in ovirt.
> >
> >     The same applet performs successfully when run as a standalone, but
> >     fails to deliver when the it is run through ovirt.
> >
> >     any plausible explanation?
> >     PFA the screenshot of both cases
> >
> >     --
> >     -Aditya Mamidwar
> >
> >
> >
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
> 


From gchaplik at redhat.com  Mon Mar 31 13:31:17 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Mon, 31 Mar 2014 09:31:17 -0400 (EDT)
Subject: [Engine-devel] Please help us to review our database schema
 design with NUMA feature on ovirt
In-Reply-To: <08AA403C8399104A89AF710307FA78AE243DD16D@G5W2743.americas.hpqcorp.net>
References: <B63C858E777679458338A30A991BB524015EB9D9@G1W3780.americas.hpqcorp.net>
	<1290280076.419927.1395656626000.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD026@G5W2743.americas.hpqcorp.net>
	<1718882238.5076978.1396257170731.JavaMail.zimbra@redhat.com>
	<182238414.11560689.1396257704986.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD11A@G5W2743.americas.hpqcorp.net>
	<1087291412.5091657.1396259332718.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD16D@G5W2743.americas.hpqcorp.net>
Message-ID: <1690885238.11367.1396272677929.JavaMail.zimbra@redhat.com>

adding Roy & Omer.

why CPU topology is in dynamic?

Thanks, 
Gilad.

----- Original Message -----
> From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan" <rgolan at redhat.com>, "Chuan Liao (Jason Liao,
> HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Chegu Vinod"
> <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> <ydary at redhat.com>, engine-devel at ovirt.org
> Sent: Monday, March 31, 2014 3:20:33 PM
> Subject: RE: Please help us to review our database schema design with NUMA feature on ovirt
> 
> Thanks Eli.
> I will move the vm level NUMA fields to vm_dynamic, and the related database
> schema will be updated accordingly.
> 
> Thanks & Best Regards
> Shi, Xiao-Lei (Bruce)
> 
> Hewlett-Packard Co., Ltd.
> HP Servers Core Platform Software China
> Telephone +86 23 65683093
> Mobile +86 18696583447
> Email xiao-lei.shi at hp.com
> 
> -----Original Message-----
> From: Eli Mesika [mailto:emesika at redhat.com]
> Sent: Monday, March 31, 2014 5:49 PM
> To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> Cc: Gilad Chaplik; Roy Golan; Liao, Chuan (Jason Liao,
> HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang, Shang-Chun
> (David Liang, HPservers-Core-OE-PSC); Yaniv Dary; engine-devel at ovirt.org
> Subject: Re: Please help us to review our database schema design with NUMA
> feature on ovirt
> 
> 
> 
> ----- Original Message -----
> > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > To: "Gilad Chaplik" <gchaplik at redhat.com>, "Eli Mesika"
> > <emesika at redhat.com>, "Roy Golan" <rgolan at redhat.com>
> > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Chegu Vinod"
> > <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
> > HPservers-Core-OE-PSC)"
> > <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>,
> > engine-devel at ovirt.org
> > Sent: Monday, March 31, 2014 12:38:04 PM
> > Subject: RE: Please help us to review our database schema design with
> > NUMA feature on ovirt
> > 
> > We put host level NUMA fields in vds_dynamic because these information
> > are from host itself, and NUMA topology may be changed if the host's
> > hardware make a change. NUMA information are similar to the host's cpu
> > topology information like cpu_cores and cpu_sockets which are in
> > vds_dynamic, we refer to this.
> > VM level NUMA fields are configured by user, and actually we
> > originally think they should be in vm_dynamic. But we found that the
> > field of another feature cpuPin which is similar as NUMA feature is in
> > vm_static, so we put vm NUMA fields in vm_static.
> > Do you think we need to put VM level NUMA fields in vm_dynamic?
> 
> I think that in this case we should fix cpuPin to be in vm_dynamic and put
> after that the other NUMA fields in vm_dynamic as well
> 
> > 
> > Thanks & Best Regards
> > Shi, Xiao-Lei (Bruce)
> > 
> > Hewlett-Packard Co., Ltd.
> > HP Servers Core Platform Software China Telephone +86 23 65683093
> > Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > 
> > 
> > -----Original Message-----
> > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > Sent: Monday, March 31, 2014 5:22 PM
> > To: Eli Mesika; Roy Golan
> > Cc: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Liao, Chuan (Jason Liao,
> > HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang, Shang-Chun
> > (David Liang, HPservers-Core-OE-PSC); Yaniv Dary; engine-devel at ovirt.org
> > Subject: Re: Please help us to review our database schema design with NUMA
> > feature on ovirt
> > 
> > +1
> > 
> > IMO: vds data should reside in static
> > VM need to think about it.
> > 
> > Roy?
> > 
> > Thanks,
> > Gilad.
> > 
> > 
> > ----- Original Message -----
> > > From: "Eli Mesika" <emesika at redhat.com>
> > > To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>,
> > > "Doron Fediuck" <dfediuck at redhat.com>,
> > > "Gilad Chaplik" <gchaplik at redhat.com>, "Chegu Vinod"
> > > <chegu_vinod at hp.com>,
> > > "Shang-Chun Liang (David Liang,
> > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > Sent: Monday, March 31, 2014 12:12:50 PM
> > > Subject: Re: Please help us to review our database schema design with
> > > NUMA
> > > feature on ovirt
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > <chuan.liao at hp.com>,
> > > > "Doron Fediuck" <dfediuck at redhat.com>,
> > > > "Gilad Chaplik" <gchaplik at redhat.com>, "Chegu Vinod"
> > > > <chegu_vinod at hp.com>,
> > > > "Shang-Chun Liang (David Liang,
> > > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > > Sent: Monday, March 31, 2014 8:56:20 AM
> > > > Subject: RE: Please help us to review our database schema design with
> > > > NUMA
> > > > feature on ovirt
> > > > 
> > > > Include the devel group.
> > > > Thanks Eli for the quick responses for our first design and sorry for
> > > > the
> > > > nag.
> > > > We appreciate any of the comments for our database design and will
> > > > follow
> > > > the
> > > > design to do the implementation if no more comments.
> > > >  http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > > 
> > > Seems OK for me except an unanswered question I had asked in my first
> > > review
> > > :
> > > 
> > > Why in the Host level NUMA fields are added to vds_dynamic while in the
> > > VM
> > > level it is added to vm_static ???
> > > I would expect it to be in both on static or dynamic , can you please
> > > explain
> > > ? Thanks
> > > 
> > > > 
> > > > Thanks & Best Regards
> > > > Shi, Xiao-Lei (Bruce)
> > > > 
> > > > Hewlett-Packard Co., Ltd.
> > > > HP Servers Core Platform Software China
> > > > Telephone +86 23 65683093
> > > > Mobile +86 18696583447
> > > > Email xiao-lei.shi at hp.com
> > > > 
> > > > -----Original Message-----
> > > > From: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > Sent: Friday, March 28, 2014 1:30 PM
> > > > To: 'Eli Mesika'
> > > > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck;
> > > > Gilad
> > > > Chaplik; Vinod, Chegu; Liang, Shang-Chun (David Liang,
> > > > HPservers-Core-OE-PSC); Yaniv Dary
> > > > Subject: RE: Please help us to review our database schema design with
> > > > NUMA
> > > > feature on ovirt
> > > > 
> > > > Hi Eli,
> > > > 
> > > > After the UX design meeting, we did some modification for the database
> > > > schema, and merged some update according to your last review comments.
> > > > Now the document has been posted on ovirt wikipage, could you help to
> > > > review
> > > > the database design again:
> > > > http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > > > 
> > > > 
> > > > Thanks & Best Regards
> > > > Shi, Xiao-Lei (Bruce)
> > > > 
> > > > Hewlett-Packard Co., Ltd.
> > > > HP Servers Core Platform Software China Telephone +86 23 65683093
> > > > Mobile
> > > > +86
> > > > 18696583447 Email xiao-lei.shi at hp.com
> > > > 
> > > > 
> > > > -----Original Message-----
> > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > Sent: Monday, March 24, 2014 6:24 PM
> > > > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck;
> > > > Gilad
> > > > Chaplik; Vinod, Chegu; Liang, Shang-Chun (David Liang,
> > > > HPservers-Core-OE-PSC); Yaniv Dary
> > > > Subject: Re: Please help us to review our database schema design with
> > > > NUMA
> > > > feature on ovirt
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > > > > To: "Eli Mesika" <emesika at redhat.com>, "Chuan Liao (Jason Liao,
> > > > > HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> > > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
> > > > > "Shang-Chun
> > > > > Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>
> > > > > Sent: Monday, March 24, 2014 11:23:39 AM
> > > > > Subject: RE: Please help us to review our database schema design with
> > > > > NUMA feature on ovirt
> > > > > 
> > > > > Hi Eli,
> > > > > 
> > > > > Thanks for your comments.
> > > > > I have updated the document according to your comments except the
> > > > > below
> > > > > one:
> > > > > Missing from here are 2 issues:
> > > > > 
> > > > > 1) Impact on the search engine, which new columns are search-able and
> > > > > which changes are planned in the search engine code to enable that
> > > > > 
> > > > > 2) Impact on engine-reports, are those changed planned to be exposed
> > > > > to the engine data warehouse and required new/modified reports?
> > > > > 
> > > > > Could you tell us more detailed information about the modules you
> > > > > mentioned above? I mean "search engine" and "engine-reports". I think
> > > > > we missed these two parts in our previous investigation.
> > > > > I just find org.ovirt.engine.core.bll.SearchQuery, is that the right
> > > > > object for search engine?
> > > > 
> > > > Yes, actually when you are opening the admin UI, there are TABs for
> > > > each
> > > > entity , i.e. Data Center, Cluster, Host etc.
> > > > In each, you can see a text-box in which you can search for by writing
> > > > a
> > > > search expression My question is
> > > >    1) What is the impact of your work on the search on the Fost and VM
> > > >    TABs
> > > >       a) Are there any fields that are supported now in the search
> > > >       expression
> > > >       and should pop-up when you write the expression by the
> > > >       auto-completion
> > > >       mechanism ?
> > > >       b) Are there any added columns displayed in the result of such a
> > > >       search
> > > >       in the grid ?
> > > > 
> > > > > How about the engine-reports, could you give us some hints, like the
> > > > > code location and any more detailed information that we can start
> > > > > more
> > > > > investigation?
> > > > 
> > > > CCing Yaniv D who is in charge of the reports/dwh module Yaniv, any
> > > > planned
> > > > work for adding Numa features to Host/VM in the reports side ?
> > > > 
> > > > Thanks
> > > > 
> > > > > 
> > > > > Thanks & Best Regards
> > > > > Shi, Xiao-Lei (Bruce)
> > > > > 
> > > > > Hewlett-Packard Co., Ltd.
> > > > > HP Servers Core Platform Software China Telephone +86 23 65683093
> > > > > Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > > 
> > > > > -----Original Message-----
> > > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > > Sent: Sunday, March 23, 2014 4:44 PM
> > > > > To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
> > > > > Cc: Doron Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun
> > > > > (David Liang, HPservers-Core-OE-PSC); Shi, Xiao-Lei (Bruce, HP
> > > > > Servers-PSC-CQ)
> > > > > Subject: Re: Please help us to review our database schema design with
> > > > > NUMA feature on ovirt
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > > <chuan.liao at hp.com>
> > > > > > To: emesika at redhat.com
> > > > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
> > > > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > > > <shangchun.liang at hp.com>, "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > > <xiao-lei.shi at hp.com>
> > > > > > Sent: Friday, March 21, 2014 10:42:33 AM
> > > > > > Subject: Please help us to review our database schema design with
> > > > > > NUMA feature on ovirt
> > > > > > 
> > > > > > Hi Eli,
> > > > > > 
> > > > > > Please help us to review our database schema design with NUMA
> > > > > > feature on ovirt
> > > > > > https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcmbGWAcyQo_IST
> > > > > > Y8
> > > > > > ykDr0I6VY/edit?usp=sharing
> > > > > > 
> > > > > > Feel free to take comments on document at anywhere
> > > > > 
> > > > > Done, had commented on the document.
> > > > > Eli
> > > > > 
> > > > > > 
> > > > > > Especially, 5.4 The used interface between engine core and
> > > > > > database(schema)
> > > > > > 
> > > > > > Your approve and your comments with this section will be much more
> > > > > > appreciate for us.
> > > > > > 
> > > > > > Best Regards,
> > > > > > Jason Liao
> > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 


From chuan.liao at hp.com  Mon Mar 31 16:48:28 2014
From: chuan.liao at hp.com (Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC))
Date: Mon, 31 Mar 2014 16:48:28 +0000
Subject: [Engine-devel] Numa feature entities patch
In-Reply-To: <1145870835.11188144.1396190554145.JavaMail.zimbra@redhat.com>
References: <B63C858E777679458338A30A991BB524015ED524@G1W3780.americas.hpqcorp.net>
	<4168C988EBDF2141B4E0B6475B6A73D11F543DEA@G6W2504.americas.hpqcorp.net>
	<B63C858E777679458338A30A991BB524015EECD1@G1W3780.americas.hpqcorp.net>
	<4168C988EBDF2141B4E0B6475B6A73D11F54449E@G6W2504.americas.hpqcorp.net>
	<1094413948.8556753.1395843620830.JavaMail.zimbra@redhat.com>
	<1145870835.11188144.1396190554145.JavaMail.zimbra@redhat.com>
Message-ID: <B63C858E777679458338A30A991BB524015F1D03@G1W3780.americas.hpqcorp.net>

Hi Gilad,

I have update the wiki page design of BE patch
1. add VdcQueryType and VdcActionType with parameters.
2. merge some of your comments and Eli's feedback.

Please take a look at the section 
http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA#Interface_and_data_structure_in_engine_core

We appreciate any of the comments from community, and sorry for the nag.

Best Regards,
Jason Liao

-----Original Message-----
From: Gilad Chaplik [mailto:gchaplik at redhat.com] 
Sent: 2014?3?30? 22:43
To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC)
Cc: Doron Fediuck; Vinod, Chegu; Martin Sivak
Subject: Numa feature entities patch

Hi all, 

I had some comments :-) IMO this patch [1] has maximum priority.
let's try to merge it ASAP, I will be very responsive to every new upload.

Thanks, 
Gilad.

[1] http://gerrit.ovirt.org/#/c/23702/

From gchaplik at redhat.com  Mon Mar 31 17:05:28 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Mon, 31 Mar 2014 13:05:28 -0400 (EDT)
Subject: [Engine-devel] Numa feature entities patch
In-Reply-To: <B63C858E777679458338A30A991BB524015F1D03@G1W3780.americas.hpqcorp.net>
References: <B63C858E777679458338A30A991BB524015ED524@G1W3780.americas.hpqcorp.net>
	<4168C988EBDF2141B4E0B6475B6A73D11F543DEA@G6W2504.americas.hpqcorp.net>
	<B63C858E777679458338A30A991BB524015EECD1@G1W3780.americas.hpqcorp.net>
	<4168C988EBDF2141B4E0B6475B6A73D11F54449E@G6W2504.americas.hpqcorp.net>
	<1094413948.8556753.1395843620830.JavaMail.zimbra@redhat.com>
	<1145870835.11188144.1396190554145.JavaMail.zimbra@redhat.com>
	<B63C858E777679458338A30A991BB524015F1D03@G1W3780.americas.hpqcorp.net>
Message-ID: <675947328.740114.1396285528566.JavaMail.zimbra@redhat.com>

Hi Jason,

Please reply on the comments in the patch.
Once the code is written I think it's better not to context switch back to the design.
we will reach an agreement in gerrit/review and then update the design respectively.


Thanks, 
Gilad.

----- Original Message -----
> From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>
> Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>, "Martin Sivak" <msivak at redhat.com>,
> "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>, "Shang-Chun Liang (David Liang,
> HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, engine-devel at ovirt.org
> Sent: Monday, March 31, 2014 7:48:28 PM
> Subject: RE: Numa feature entities patch
> 
> Hi Gilad,
> 
> I have update the wiki page design of BE patch
> 1. add VdcQueryType and VdcActionType with parameters.
> 2. merge some of your comments and Eli's feedback.
> 
> Please take a look at the section
> http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA#Interface_and_data_structure_in_engine_core
> 
> We appreciate any of the comments from community, and sorry for the nag.
> 
> Best Regards,
> Jason Liao
> 
> -----Original Message-----
> From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> Sent: 2014?3?30? 22:43
> To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Shi, Xiao-Lei (Bruce, HP
> Servers-PSC-CQ); Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC)
> Cc: Doron Fediuck; Vinod, Chegu; Martin Sivak
> Subject: Numa feature entities patch
> 
> Hi all,
> 
> I had some comments :-) IMO this patch [1] has maximum priority.
> let's try to merge it ASAP, I will be very responsive to every new upload.
> 
> Thanks,
> Gilad.
> 
> [1] http://gerrit.ovirt.org/#/c/23702/
>


From chegu_vinod at hp.com  Mon Mar 31 14:51:39 2014
From: chegu_vinod at hp.com (Chegu Vinod)
Date: Mon, 31 Mar 2014 07:51:39 -0700
Subject: [Engine-devel] Please help us to review our database schema
 design with NUMA feature on ovirt
In-Reply-To: <08AA403C8399104A89AF710307FA78AE243DD11A@G5W2743.americas.hpqcorp.net>
References: <B63C858E777679458338A30A991BB524015EB9D9@G1W3780.americas.hpqcorp.net>
	<780322931.181632.1395564237381.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DB5E2@G5W2743.americas.hpqcorp.net>
	<1290280076.419927.1395656626000.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD026@G5W2743.americas.hpqcorp.net>
	<1718882238.5076978.1396257170731.JavaMail.zimbra@redhat.com>
	<182238414.11560689.1396257704986.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD11A@G5W2743.americas.hpqcorp.net>
Message-ID: <533980FB.4090905@hp.com>

On 3/31/2014 2:38 AM, Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) wrote:
> We put host level NUMA fields in vds_dynamic because these information are from host itself, and NUMA topology may be changed if the host's hardware make a change.
Can you please elaborate ? Are you thinking about resource (cpu and/or 
memory) hot plug on the host ?

Vinod

>   NUMA information are similar to the host's cpu topology information like cpu_cores and cpu_sockets which are in vds_dynamic, we refer to this.
> VM level NUMA fields are configured by user, and actually we originally think they should be in vm_dynamic. But we found that the field of another feature cpuPin which is similar as NUMA feature is in vm_static, so we put vm NUMA fields in vm_static.
> Do you think we need to put VM level NUMA fields in vm_dynamic?
>
> Thanks & Best Regards
> Shi, Xiao-Lei (Bruce)
>
> Hewlett-Packard Co., Ltd.
> HP Servers Core Platform Software China
> Telephone +86 23 65683093
> Mobile +86 18696583447
> Email xiao-lei.shi at hp.com
>
>
> -----Original Message-----
> From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> Sent: Monday, March 31, 2014 5:22 PM
> To: Eli Mesika; Roy Golan
> Cc: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv Dary; engine-devel at ovirt.org
> Subject: Re: Please help us to review our database schema design with NUMA feature on ovirt
>
> +1
>
> IMO: vds data should reside in static
> VM need to think about it.
>
> Roy?
>
> Thanks,
> Gilad.
>
>
> ----- Original Message -----
>> From: "Eli Mesika" <emesika at redhat.com>
>> To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
>> Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>,
>> "Gilad Chaplik" <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
>> HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>, engine-devel at ovirt.org
>> Sent: Monday, March 31, 2014 12:12:50 PM
>> Subject: Re: Please help us to review our database schema design with NUMA feature on ovirt
>>
>>
>>
>> ----- Original Message -----
>>> From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
>>> To: "Eli Mesika" <emesika at redhat.com>
>>> Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>,
>>> "Doron Fediuck" <dfediuck at redhat.com>,
>>> "Gilad Chaplik" <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
>>> "Shang-Chun Liang (David Liang,
>>> HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
>>> <ydary at redhat.com>, engine-devel at ovirt.org
>>> Sent: Monday, March 31, 2014 8:56:20 AM
>>> Subject: RE: Please help us to review our database schema design with NUMA
>>> feature on ovirt
>>>
>>> Include the devel group.
>>> Thanks Eli for the quick responses for our first design and sorry for the
>>> nag.
>>> We appreciate any of the comments for our database design and will follow
>>> the
>>> design to do the implementation if no more comments.
>>>   http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
>> Seems OK for me except an unanswered question I had asked in my first review
>> :
>>
>> Why in the Host level NUMA fields are added to vds_dynamic while in the VM
>> level it is added to vm_static ???
>> I would expect it to be in both on static or dynamic , can you please explain
>> ? Thanks
>>
>>> Thanks & Best Regards
>>> Shi, Xiao-Lei (Bruce)
>>>
>>> Hewlett-Packard Co., Ltd.
>>> HP Servers Core Platform Software China
>>> Telephone +86 23 65683093
>>> Mobile +86 18696583447
>>> Email xiao-lei.shi at hp.com
>>>
>>> -----Original Message-----
>>> From: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
>>> Sent: Friday, March 28, 2014 1:30 PM
>>> To: 'Eli Mesika'
>>> Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck; Gilad
>>> Chaplik; Vinod, Chegu; Liang, Shang-Chun (David Liang,
>>> HPservers-Core-OE-PSC); Yaniv Dary
>>> Subject: RE: Please help us to review our database schema design with NUMA
>>> feature on ovirt
>>>
>>> Hi Eli,
>>>
>>> After the UX design meeting, we did some modification for the database
>>> schema, and merged some update according to your last review comments.
>>> Now the document has been posted on ovirt wikipage, could you help to
>>> review
>>> the database design again:
>>> http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
>>>
>>>
>>> Thanks & Best Regards
>>> Shi, Xiao-Lei (Bruce)
>>>
>>> Hewlett-Packard Co., Ltd.
>>> HP Servers Core Platform Software China Telephone +86 23 65683093 Mobile
>>> +86
>>> 18696583447 Email xiao-lei.shi at hp.com
>>>
>>>
>>> -----Original Message-----
>>> From: Eli Mesika [mailto:emesika at redhat.com]
>>> Sent: Monday, March 24, 2014 6:24 PM
>>> To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
>>> Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck; Gilad
>>> Chaplik; Vinod, Chegu; Liang, Shang-Chun (David Liang,
>>> HPservers-Core-OE-PSC); Yaniv Dary
>>> Subject: Re: Please help us to review our database schema design with NUMA
>>> feature on ovirt
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
>>>> To: "Eli Mesika" <emesika at redhat.com>, "Chuan Liao (Jason Liao,
>>>> HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
>>>> Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
>>>> <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>, "Shang-Chun
>>>> Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>
>>>> Sent: Monday, March 24, 2014 11:23:39 AM
>>>> Subject: RE: Please help us to review our database schema design with
>>>> NUMA feature on ovirt
>>>>
>>>> Hi Eli,
>>>>
>>>> Thanks for your comments.
>>>> I have updated the document according to your comments except the below
>>>> one:
>>>> Missing from here are 2 issues:
>>>>
>>>> 1) Impact on the search engine, which new columns are search-able and
>>>> which changes are planned in the search engine code to enable that
>>>>
>>>> 2) Impact on engine-reports, are those changed planned to be exposed
>>>> to the engine data warehouse and required new/modified reports?
>>>>
>>>> Could you tell us more detailed information about the modules you
>>>> mentioned above? I mean "search engine" and "engine-reports". I think
>>>> we missed these two parts in our previous investigation.
>>>> I just find org.ovirt.engine.core.bll.SearchQuery, is that the right
>>>> object for search engine?
>>> Yes, actually when you are opening the admin UI, there are TABs for each
>>> entity , i.e. Data Center, Cluster, Host etc.
>>> In each, you can see a text-box in which you can search for by writing a
>>> search expression My question is
>>>     1) What is the impact of your work on the search on the Fost and VM TABs
>>>        a) Are there any fields that are supported now in the search
>>>        expression
>>>        and should pop-up when you write the expression by the
>>>        auto-completion
>>>        mechanism ?
>>>        b) Are there any added columns displayed in the result of such a
>>>        search
>>>        in the grid ?
>>>
>>>> How about the engine-reports, could you give us some hints, like the
>>>> code location and any more detailed information that we can start more
>>>> investigation?
>>> CCing Yaniv D who is in charge of the reports/dwh module Yaniv, any planned
>>> work for adding Numa features to Host/VM in the reports side ?
>>>
>>> Thanks
>>>
>>>> Thanks & Best Regards
>>>> Shi, Xiao-Lei (Bruce)
>>>>
>>>> Hewlett-Packard Co., Ltd.
>>>> HP Servers Core Platform Software China Telephone +86 23 65683093
>>>> Mobile +86 18696583447 Email xiao-lei.shi at hp.com
>>>>
>>>> -----Original Message-----
>>>> From: Eli Mesika [mailto:emesika at redhat.com]
>>>> Sent: Sunday, March 23, 2014 4:44 PM
>>>> To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
>>>> Cc: Doron Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun
>>>> (David Liang, HPservers-Core-OE-PSC); Shi, Xiao-Lei (Bruce, HP
>>>> Servers-PSC-CQ)
>>>> Subject: Re: Please help us to review our database schema design with
>>>> NUMA feature on ovirt
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
>>>>> <chuan.liao at hp.com>
>>>>> To: emesika at redhat.com
>>>>> Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
>>>>> <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
>>>>> "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
>>>>> <shangchun.liang at hp.com>, "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
>>>>> <xiao-lei.shi at hp.com>
>>>>> Sent: Friday, March 21, 2014 10:42:33 AM
>>>>> Subject: Please help us to review our database schema design with
>>>>> NUMA feature on ovirt
>>>>>
>>>>> Hi Eli,
>>>>>
>>>>> Please help us to review our database schema design with NUMA
>>>>> feature on ovirt
>>>>> https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcmbGWAcyQo_IST
>>>>> Y8
>>>>> ykDr0I6VY/edit?usp=sharing
>>>>>
>>>>> Feel free to take comments on document at anywhere
>>>> Done, had commented on the document.
>>>> Eli
>>>>
>>>>> Especially, 5.4 The used interface between engine core and
>>>>> database(schema)
>>>>>
>>>>> Your approve and your comments with this section will be much more
>>>>> appreciate for us.
>>>>>
>>>>> Best Regards,
>>>>> Jason Liao
>>>>>
>>>>>