[ovirt-devel] Controlling UI table column visibility and position

[Vojtech Szocs]

Dear developers and users,

it's now possible to tweak table column visibility and position
through header context menu in WebAdmin's main & sub tabs [1,2].

  [1] https://gerrit.ovirt.org/#/c/43401/
  [2] https://gerrit.ovirt.org/#/c/47542/

This allows you to turn "unwanted" columns off and re-arrange
those which are visible to match your personal preference.

Screenshot of customizing VM main tab:

  https://imgur.com/5dfh8QA

There's also RFE [3] to persist (remember) such column settings
in the browser, similar to persisting other client-side options.

  [3] https://bugzilla.redhat.com/1285456

Regards,
Vojtech
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Push notifications in 4.0 backend

[Martin Betak]

- Original Message -
> From: "Marek Libra" 
> To: "Martin Perina" 
> Cc: "Piotr Kliczewski" , "Michal Skrivanek" 
> , "engine-de...@ovirt.org"
> 
> Sent: Wednesday, November 25, 2015 5:19:31 PM
> Subject: Re: [ovirt-devel] Push notifications in 4.0 backend
> 
> 
> 
> - Original Message -
> > From: "Martin Perina" 
> > To: "Eli Mesika" 
> > Cc: "Piotr Kliczewski" , "engine-de...@ovirt.org"
> > , "Michal Skrivanek"
> > 
> > Sent: Wednesday, 25 November, 2015 11:20:49 AM
> > Subject: Re: [ovirt-devel] Push notifications in 4.0 backend
> > 
> > 
> > 
> > - Original Message -
> > > From: "Eli Mesika" 
> > > To: "Vojtech Szocs" 
> > > Cc: "Piotr Kliczewski" , "Michal Skrivanek"
> > > , "engine-de...@ovirt.org"
> > > 
> > > Sent: Wednesday, November 25, 2015 10:42:35 AM
> > > Subject: Re: [ovirt-devel] Push notifications in 4.0 backend
> > > 
> > > 
> > > 
> > > - Original Message -
> > > > From: "Vojtech Szocs" 
> > > > To: "Martin Betak" 
> > > > Cc: "engine-de...@ovirt.org" , "Piotr Kliczewski"
> > > > , "Michal Skrivanek"
> > > > 
> > > > Sent: Monday, November 23, 2015 6:22:45 PM
> > > > Subject: Re: [ovirt-devel] Push notifications in 4.0 backend
> > > > 
> > > > 
> > > > 
> > > > - Original Message -
> > > > > From: "Martin Betak" 
> > > > > To: "Vojtech Szocs" 
> > > > > Cc: "Einav Cohen" , "engine-de...@ovirt.org"
> > > > > , "Roy Golan" ,
> > > > > "Roman Mohr" , "Michal Skrivanek"
> > > > > ,
> > > > > "Piotr Kliczewski" ,
> > > > > "Tomas Jelinek" , "Alexander Wels"
> > > > > ,
> > > > > "Greg Sheremeta" ,
> > > > > "Scott Dickerson" , "Arik Hadas"
> > > > > ,
> > > > > "Allon Mureinik" ,
> > > > > "Shmuel Melamud" , "Jakub Niedermertl"
> > > > > , "Marek Libra"
> > > > > , "Martin Perina" , "Alona
> > > > > Kaplan"
> > > > > , "Martin Mucha"
> > > > > 
> > > > > Sent: Thursday, November 19, 2015 1:53:07 PM
> > > > > Subject: Re: Push notifications in 4.0 backend
> > > > > 
> > > > > Hi All,
> > > > > 
> > > > > I have created a PoC patch [1] demonstrating the idea of annotating
> > > > > basic CRUD commands to publish CDI events. It is not meant as 100%
> > > > > solution, but as a simplification of the common use cases when
> > > > > one would inject CDI event with given qualifier and fire it after
> > > > > successful completion of transaction.
> > > > 
> > > > The patches (mentioned below) look interesting.
> > > > 
> > > > At this point, it would be great if backend core maintainers
> > > > voiced their opinions on the general idea of firing CDI events
> > > > in response to important actions happening on Engine, such as
> > > > backend commands being executed. So, what do you think guys?
> > > 
> > > +1
> > > 
> > > I am for it, I think it may reduce load from our DB
> > 
> > +1
> > 
> The load reduction can be achieved and seems like not a big deal to implement
> it.
> +1

Yes, the DB load reduction is perhaps the bigest boon of this effort :-).

My first patch makes very convenient to fire notification from basic CRUD 
management
operations that manipulate main business entities. The next (and probably more
complicated) step will be a refactoring of the monitoring code to support CDI 
(injections and events) and have it fire events of VmDynamic payload. Then on
the event we can have listening scheduler (balancing), HA, ... and other parts
that not only won't have to issue expensive DB queries (e.g. GetVmsRunningOnVds)
but also can be more decoupled from monitoring (e.g. VdsEventListener).

But this will be a little bit more involved than just annotating all CRUD 
commands
with one annotation :-)

> 
> > > 
> > > > 
> > > > > 
> > > > > The usage of this annotations is demonstrated on several basic CRUD
> > > > > commands in [2] on StoragePool, VDS, VDSGroup, .etc
> > > > > 
> > > > > As always, comments and suggestions are very welcome!
> > > > > 
> > > > > Thank you and best regards,
> > > > > 
> > > > > Martin
> > > > > 
> > > > > [1] infra: https://gerrit.ovirt.org/#/c/48696/
> > > > > [2] usage: https://gerrit.ovirt.org/#/c/48697/
> > > > > 
> > > > > 
> > > > > 
> > > > > - Original Message -
> > > > > > From: "Vojtech Szocs" 
> > > > > > To: 

Re: [ovirt-devel] Controlling UI table column visibility and position

[Oved Ourfali]

That's awesome!
Looking forward to playing around with it!

Thanks,
Oved
On Nov 25, 2015 6:42 PM, "Vojtech Szocs"  wrote:

> Dear developers and users,
>
> it's now possible to tweak table column visibility and position
> through header context menu in WebAdmin's main & sub tabs [1,2].
>
>   [1] https://gerrit.ovirt.org/#/c/43401/
>   [2] https://gerrit.ovirt.org/#/c/47542/
>
> This allows you to turn "unwanted" columns off and re-arrange
> those which are visible to match your personal preference.
>
> Screenshot of customizing VM main tab:
>
>   https://imgur.com/5dfh8QA
>
> There's also RFE [3] to persist (remember) such column settings
> in the browser, similar to persisting other client-side options.
>
>   [3] https://bugzilla.redhat.com/1285456
>
> Regards,
> Vojtech
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Push notifications in 4.0 backend

[Marek Libra]

- Original Message -
> From: "Martin Perina" 
> To: "Eli Mesika" 
> Cc: "Piotr Kliczewski" , "engine-de...@ovirt.org" 
> , "Michal Skrivanek"
> 
> Sent: Wednesday, 25 November, 2015 11:20:49 AM
> Subject: Re: [ovirt-devel] Push notifications in 4.0 backend
> 
> 
> 
> - Original Message -
> > From: "Eli Mesika" 
> > To: "Vojtech Szocs" 
> > Cc: "Piotr Kliczewski" , "Michal Skrivanek"
> > , "engine-de...@ovirt.org"
> > 
> > Sent: Wednesday, November 25, 2015 10:42:35 AM
> > Subject: Re: [ovirt-devel] Push notifications in 4.0 backend
> > 
> > 
> > 
> > - Original Message -
> > > From: "Vojtech Szocs" 
> > > To: "Martin Betak" 
> > > Cc: "engine-de...@ovirt.org" , "Piotr Kliczewski"
> > > , "Michal Skrivanek"
> > > 
> > > Sent: Monday, November 23, 2015 6:22:45 PM
> > > Subject: Re: [ovirt-devel] Push notifications in 4.0 backend
> > > 
> > > 
> > > 
> > > - Original Message -
> > > > From: "Martin Betak" 
> > > > To: "Vojtech Szocs" 
> > > > Cc: "Einav Cohen" , "engine-de...@ovirt.org"
> > > > , "Roy Golan" ,
> > > > "Roman Mohr" , "Michal Skrivanek"
> > > > ,
> > > > "Piotr Kliczewski" ,
> > > > "Tomas Jelinek" , "Alexander Wels"
> > > > ,
> > > > "Greg Sheremeta" ,
> > > > "Scott Dickerson" , "Arik Hadas"
> > > > ,
> > > > "Allon Mureinik" ,
> > > > "Shmuel Melamud" , "Jakub Niedermertl"
> > > > , "Marek Libra"
> > > > , "Martin Perina" , "Alona
> > > > Kaplan"
> > > > , "Martin Mucha"
> > > > 
> > > > Sent: Thursday, November 19, 2015 1:53:07 PM
> > > > Subject: Re: Push notifications in 4.0 backend
> > > > 
> > > > Hi All,
> > > > 
> > > > I have created a PoC patch [1] demonstrating the idea of annotating
> > > > basic CRUD commands to publish CDI events. It is not meant as 100%
> > > > solution, but as a simplification of the common use cases when
> > > > one would inject CDI event with given qualifier and fire it after
> > > > successful completion of transaction.
> > > 
> > > The patches (mentioned below) look interesting.
> > > 
> > > At this point, it would be great if backend core maintainers
> > > voiced their opinions on the general idea of firing CDI events
> > > in response to important actions happening on Engine, such as
> > > backend commands being executed. So, what do you think guys?
> > 
> > +1
> > 
> > I am for it, I think it may reduce load from our DB
> 
> +1
> 
The load reduction can be achieved and seems like not a big deal to implement 
it.
+1

> > 
> > > 
> > > > 
> > > > The usage of this annotations is demonstrated on several basic CRUD
> > > > commands in [2] on StoragePool, VDS, VDSGroup, .etc
> > > > 
> > > > As always, comments and suggestions are very welcome!
> > > > 
> > > > Thank you and best regards,
> > > > 
> > > > Martin
> > > > 
> > > > [1] infra: https://gerrit.ovirt.org/#/c/48696/
> > > > [2] usage: https://gerrit.ovirt.org/#/c/48697/
> > > > 
> > > > 
> > > > 
> > > > - Original Message -
> > > > > From: "Vojtech Szocs" 
> > > > > To: "Martin Betak" , "Einav Cohen"
> > > > > 
> > > > > Cc: "engine-de...@ovirt.org" , "Roy Golan"
> > > > > , "Roman Mohr" ,
> > > > > "Michal Skrivanek" , "Piotr Kliczewski"
> > > > > , "Tomas Jelinek"
> > > > > , "Alexander Wels" , "Greg
> > > > > Sheremeta" , "Scott
> > > > > Dickerson" 
> > > > > Sent: Friday, November 13, 2015 9:31:45 PM
> > > > > Subject: Re: Push notifications in 4.0 backend
> > > > > 
> > > > > Hi everyone,
> > > > > 
> > > > > assuming that 4.0 UI will be based on the existing GWT technology,
> > > > > I'd like to improve two things which I believe are very important:
> > > > > 
> > > > > #1 goal: improve GWT compilation times
> > > > >- don't use standard GWT i18n mechanism which yields separate
> > > > >  permutation vector, but use our own i18n mechanism instead
> > > > >- in practice, compiling for X browsers and Y languages should
> > > > >  result in GWT compiler processing X permutations (not X * Y)
> > > > >- this will also directly impact GWT debug performance, making
> > > > >  GWT debugging experience less painful for developers

Re: [ovirt-devel] [oVirt 3.6 Localization Question #39] "prefixMsg, "

[Yuko Katabami]

Hello Eliraz,

Sorry to bother you.
Could you please provide us an answer to this question, so that we can
complete our translation.

Thank you,

Yuko

On Tue, Nov 24, 2015 at 11:44 PM, Einav Cohen  wrote:

> > - Original Message -
> > From: "Yuko Katabami" 
> > Sent: Tuesday, November 24, 2015 6:51:11 AM
> >
> > Hello all,
> >
> > Here is another question:
> >
> > File: UIMessages
> > Resource IDs:
> > numberValidationNumberBetweenInvalidReason
> > numberValidationNumberGreaterInvalidReason
> > numberValidationNumberLessInvalidReason
> > Strings:
> > {0} between {1} and {2}.
> > {0} greater than or equal to {1}.
> > {0} less than or equal to {1}.
> > Question: Could you please provide some example of those messages?
> Comment
> > section in each of those strings states "0=prefixMsg" but I would like to
> > know what will actually replace {0}, so that I can translate them
> properly.
>
> @Eliraz?
> [again - these belong to NumberRangeValidation which doesn't seem to be
> used
> anywhere in the code?]
>
> >
> > Kind regards,
> >
> > Yuko
> >
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [oVirt 3.6 Localization Question #40] "This field must contain an {0} number"

[Yuko Katabami]

Hello Eliraz,

This question also requires your help.
Thanks in advance,

Yuko

On Tue, Nov 24, 2015 at 11:40 PM, Einav Cohen  wrote:

> > - Original Message -
> > From: "Yuko Katabami" 
> > Sent: Tuesday, November 24, 2015 7:04:03 AM
> >
> > Hello once again,
> >
> > I would like to ask you another question.
> >
> > File: UIMessages
> > Resource ID: thisFieldMustContainTypeNumberInvalidReason
> > String: This field must contain an {0} number
> > Question: I can see from the source comment 0=type but could you please
> give
> > me an example of what will replace {0}?
>
> @Eliraz?
> [I actually don't see NumberRangeValidation being used anywhere in the
> code..]
>
> >
> > Kind regards,
> >
> > Yuko
> >
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] ovirt-engine-sdk-python too slow

[Juan Hernández]

On 11/25/2015 06:45 PM, Nir Soffer wrote:
> $ ./profile-stats -c myscript.prof
> 
> Wed Nov 25 10:40:11 2015myscript.prof
> 
>  7892315 function calls (7891054 primitive calls) in 7.940 seconds
> 
>Ordered by: internal time
>List reduced from 1518 to 20 due to restriction <20>
> 
>ncalls  tottime  percall  cumtime  percall filename:lineno(function)
>  90862.6930.0006.7060.001 inspect.py:247(getmembers)
>   19524941.3940.0001.8800.000 inspect.py:59(isclass)
>  90921.0300.0001.0300.000 {dir}
>   19526420.6000.0000.6000.000 {getattr}
>   19727650.5040.0000.5040.000 {isinstance}
> 30.3340.1110.3340.111 {method 'perform' of
> 'pycurl.Curl' objects}
>   18839180.2840.0000.2840.000 {method 'append' of 'list'
> objects}
>  90870.2210.0000.2210.000 {method 'sort' of 'list'
> objects}
>  90510.1720.0006.9110.001
> reflectionhelper.py:51(isModuleMember)
> 10.1240.1240.3540.354 errors.py:17()
> 10.0880.0880.2300.230 params.py:8()
>  88790.0700.0006.9980.001 params.py:367(__setattr__)
> 10.0470.0475.1825.182 api.py:23()
> 10.0250.0254.7434.743 brokers.py:22()
> 10.0230.0230.0300.030
> connectionspool.py:17()
> 10.0220.0220.0530.053
> lxml.etree.pyx:1(PyMODINIT_FUNC PyInit_etree(void))
>   1180.0190.0004.6840.040 params.py:45277(__init__)
> 50.0150.0030.0240.005 {built-in method strptime}
> 10.0120.0120.0130.013 socket.py:45()
>100.0110.0010.0150.002 collections.py:288(namedtuple)
> 
> So it is not the classes, it is the code inspecting them on import.
> 

The script doesn't contain only the imports, it is also calling the
server, and we know parsing the result is slow, due to the excesive use
of "inspect", as I mentioned before:

  [RFE][performance] - generate large scale list running to slow.
  https://bugzilla.redhat.com/show_bug.cgi?id=1221238#c2

In the profiling information seems to corresponds to the script before
commenting out the part that lists all the VMs, as it looks like the
constructor of the VM class was called 21 times (you probably have 21 VMs):

  21 0.004 1.308
build/bdist.linux-x86_64/egg/ovirtsdk/infrastructure/brokers.py:29139(VM)

> Nir
> 
> On Wed, Nov 25, 2015 at 7:49 AM, John Hunter  > wrote:
> 
> Hi Nir,
> 
> Attachment is my script and its profile.
> Thanks a lot about your help!
> 
> On Wed, Nov 25, 2015 at 5:49 AM, Nir Soffer  > wrote:
> 
> On Tue, Nov 24, 2015 at 3:49 PM, John Hunter  > wrote:
> 
> 
> 
> On Tue, Nov 24, 2015 at 9:15 PM, Juan Hernández
> > wrote:
> 
> On 11/24/2015 01:40 PM, John Hunter wrote:
> > Hi,
> >
> > On Tue, Nov 24, 2015 at 5:18 PM, Oved Ourfali 
> 
> > >> 
> wrote:
> >
> > Hi
> >
> > I discussed it with Juan (cc-ed).
> >
> > There used to be a bug in the JDBC authenticion 
> extension that
> > artificially delayed RESTAPI responses by 5 seconds:
> >
> >   brute force prevention login delay should not be 
> applied to successful
> > login requests
> >   https://bugzilla.redhat.com/1255814
> >
> > That matches the description of the issue, but in 
> theory it has been
> > fixed. I would suggest him to check that he is using 
> the right version
> > of the extension.
> >
> > I did not use the extension 
> ovirt-engine-extension-aaa-jdbc, and I don't
> > think this bug matches my problem, because even there is 
> only one line
> > in the python script, it still cost like 3 seconds, I don't 
> think this is a
> > reasonable time as when I import other package, it cost 
> almost no time.
> >
> > Can you explain why this import line costs so much time?
> >
> 
> If you are using 3.6 then you are using
> ovirt-engine-extension-aaa-jdbc,
> as it is enabled by default, but looks like it isn't
> related to your
> problem.
> 
>

Re: [ovirt-devel] Controlling UI table column visibility and position

[Eli Mesika]

- Original Message -
> From: "Oved Ourfali" 
> To: "Vojtech Szocs" 
> Cc: "users" , "devel" 
> Sent: Wednesday, November 25, 2015 7:32:33 PM
> Subject: Re: [ovirt-devel] Controlling UI table column visibility and position
> 
> 
> 
> That's awesome!
> Looking forward to playing around with it!
> 
> Thanks,
> Oved
> On Nov 25, 2015 6:42 PM, "Vojtech Szocs" < vsz...@redhat.com > wrote:
> 
> 
> Dear developers and users,
> 
> it's now possible to tweak table column visibility and position
> through header context menu in WebAdmin's main & sub tabs [1,2].
> 
> [1] https://gerrit.ovirt.org/#/c/43401/
> [2] https://gerrit.ovirt.org/#/c/47542/
> 
> This allows you to turn "unwanted" columns off and re-arrange
> those which are visible to match your personal preference.
> 
> Screenshot of customizing VM main tab:
> 
> https://imgur.com/5dfh8QA

Really useful 
However, I would filter out status columns since this column does not have a 
title and also  I can not see a use-case of removing this column from the view 

> 
> There's also RFE [3] to persist (remember) such column settings
> in the browser, similar to persisting other client-side options.
> 
> [3] https://bugzilla.redhat.com/1285456
> 
> Regards,
> Vojtech
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> 
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] ovirt-engine-sdk-python too slow

[Nir Soffer]

$ ./profile-stats -c myscript.prof

Wed Nov 25 10:40:11 2015myscript.prof

 7892315 function calls (7891054 primitive calls) in 7.940 seconds

   Ordered by: internal time
   List reduced from 1518 to 20 due to restriction <20>

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
 90862.6930.0006.7060.001 inspect.py:247(getmembers)
  19524941.3940.0001.8800.000 inspect.py:59(isclass)
 90921.0300.0001.0300.000 {dir}
  19526420.6000.0000.6000.000 {getattr}
  19727650.5040.0000.5040.000 {isinstance}
30.3340.1110.3340.111 {method 'perform' of
'pycurl.Curl' objects}
  18839180.2840.0000.2840.000 {method 'append' of 'list'
objects}
 90870.2210.0000.2210.000 {method 'sort' of 'list'
objects}
 90510.1720.0006.9110.001
reflectionhelper.py:51(isModuleMember)
10.1240.1240.3540.354 errors.py:17()
10.0880.0880.2300.230 params.py:8()
 88790.0700.0006.9980.001 params.py:367(__setattr__)
10.0470.0475.1825.182 api.py:23()
10.0250.0254.7434.743 brokers.py:22()
10.0230.0230.0300.030
connectionspool.py:17()
10.0220.0220.0530.053
lxml.etree.pyx:1(PyMODINIT_FUNC PyInit_etree(void))
  1180.0190.0004.6840.040 params.py:45277(__init__)
50.0150.0030.0240.005 {built-in method strptime}
10.0120.0120.0130.013 socket.py:45()
   100.0110.0010.0150.002 collections.py:288(namedtuple)

So it is not the classes, it is the code inspecting them on import.

Nir

On Wed, Nov 25, 2015 at 7:49 AM, John Hunter  wrote:

> Hi Nir,
>
> Attachment is my script and its profile.
> Thanks a lot about your help!
>
> On Wed, Nov 25, 2015 at 5:49 AM, Nir Soffer  wrote:
>
>> On Tue, Nov 24, 2015 at 3:49 PM, John Hunter  wrote:
>>
>>>
>>>
>>> On Tue, Nov 24, 2015 at 9:15 PM, Juan Hernández 
>>> wrote:
>>>
 On 11/24/2015 01:40 PM, John Hunter wrote:
 > Hi,
 >
 > On Tue, Nov 24, 2015 at 5:18 PM, Oved Ourfali  > wrote:
 >
 > Hi
 >
 > I discussed it with Juan (cc-ed).
 >
 > There used to be a bug in the JDBC authenticion extension that
 > artificially delayed RESTAPI responses by 5 seconds:
 >
 >   brute force prevention login delay should not be applied to
 successful
 > login requests
 >   https://bugzilla.redhat.com/1255814
 >
 > That matches the description of the issue, but in theory it has
 been
 > fixed. I would suggest him to check that he is using the right
 version
 > of the extension.
 >
 > I did not use the extension ovirt-engine-extension-aaa-jdbc, and I
 don't
 > think this bug matches my problem, because even there is only one line
 > in the python script, it still cost like 3 seconds, I don't think
 this is a
 > reasonable time as when I import other package, it cost almost no
 time.
 >
 > Can you explain why this import line costs so much time?
 >

 If you are using 3.6 then you are using ovirt-engine-extension-aaa-jdbc,
 as it is enabled by default, but looks like it isn't related to your
 problem.

 That line takes a long time to execute because it has to process two
 large Python modules: the "params" module that contains a class per each
 type used by the API (393 classes) and the "brokers" module that
 contains a class per each resource used by the API (358 classes). That
 makes a total of 751 classes. In my environment it takes 0.9 seconds,
 approx. You may want to use the python profile in your environment and
 share the results:

 $ cat > profile.py <<.
 import cProfile
 cProfile.run("from ovirtsdk.api import API")
 .

 $ python profile.py

 I won't be surprised to see this taking those 3 seconds in a slower
 environment.

 But even if this takes those 3 seconds it shouldn't be a big problem,
 because you shouldn't be running that "from ... import ..." line
 frequently. Your program should do this once only, when it starts.

 Assume that I have two functions to implement, one is to list all the
>>> vms belong
>>> to the user, and the other is to retrieve one vm's virt-viewer
>>> connection file, as
>>> far as I can see, I have to write two python scripts and import the
>>> ovirtsdk.api in both
>>> scripts, each script has to take the 3 seconds :(
>>>
>>
>> No, you have two functions, which can be in the same module, or in
>> different modules, depending on how you want to organize 

Re: [ovirt-devel] Push notifications in 4.0 backend

[Yaniv Kaul]

On Wed, Nov 25, 2015 at 6:32 PM, Martin Betak  wrote:

>
>
>
>
> - Original Message -
> > From: "Marek Libra" 
> > To: "Martin Perina" 
> > Cc: "Piotr Kliczewski" , "Michal Skrivanek" <
> mskri...@redhat.com>, "engine-de...@ovirt.org"
> > 
> > Sent: Wednesday, November 25, 2015 5:19:31 PM
> > Subject: Re: [ovirt-devel] Push notifications in 4.0 backend
> >
> >
> >
> > - Original Message -
> > > From: "Martin Perina" 
> > > To: "Eli Mesika" 
> > > Cc: "Piotr Kliczewski" , "engine-de...@ovirt.org"
> > > , "Michal Skrivanek"
> > > 
> > > Sent: Wednesday, 25 November, 2015 11:20:49 AM
> > > Subject: Re: [ovirt-devel] Push notifications in 4.0 backend
> > >
> > >
> > >
> > > - Original Message -
> > > > From: "Eli Mesika" 
> > > > To: "Vojtech Szocs" 
> > > > Cc: "Piotr Kliczewski" , "Michal Skrivanek"
> > > > , "engine-de...@ovirt.org"
> > > > 
> > > > Sent: Wednesday, November 25, 2015 10:42:35 AM
> > > > Subject: Re: [ovirt-devel] Push notifications in 4.0 backend
> > > >
> > > >
> > > >
> > > > - Original Message -
> > > > > From: "Vojtech Szocs" 
> > > > > To: "Martin Betak" 
> > > > > Cc: "engine-de...@ovirt.org" , "Piotr Kliczewski"
> > > > > , "Michal Skrivanek"
> > > > > 
> > > > > Sent: Monday, November 23, 2015 6:22:45 PM
> > > > > Subject: Re: [ovirt-devel] Push notifications in 4.0 backend
> > > > >
> > > > >
> > > > >
> > > > > - Original Message -
> > > > > > From: "Martin Betak" 
> > > > > > To: "Vojtech Szocs" 
> > > > > > Cc: "Einav Cohen" , "engine-de...@ovirt.org"
> > > > > > , "Roy Golan" ,
> > > > > > "Roman Mohr" , "Michal Skrivanek"
> > > > > > ,
> > > > > > "Piotr Kliczewski" ,
> > > > > > "Tomas Jelinek" , "Alexander Wels"
> > > > > > ,
> > > > > > "Greg Sheremeta" ,
> > > > > > "Scott Dickerson" , "Arik Hadas"
> > > > > > ,
> > > > > > "Allon Mureinik" ,
> > > > > > "Shmuel Melamud" , "Jakub Niedermertl"
> > > > > > , "Marek Libra"
> > > > > > , "Martin Perina" ,
> "Alona
> > > > > > Kaplan"
> > > > > > , "Martin Mucha"
> > > > > > 
> > > > > > Sent: Thursday, November 19, 2015 1:53:07 PM
> > > > > > Subject: Re: Push notifications in 4.0 backend
> > > > > >
> > > > > > Hi All,
> > > > > >
> > > > > > I have created a PoC patch [1] demonstrating the idea of
> annotating
> > > > > > basic CRUD commands to publish CDI events. It is not meant as
> 100%
> > > > > > solution, but as a simplification of the common use cases when
> > > > > > one would inject CDI event with given qualifier and fire it after
> > > > > > successful completion of transaction.
> > > > >
> > > > > The patches (mentioned below) look interesting.
> > > > >
> > > > > At this point, it would be great if backend core maintainers
> > > > > voiced their opinions on the general idea of firing CDI events
> > > > > in response to important actions happening on Engine, such as
> > > > > backend commands being executed. So, what do you think guys?
> > > >
> > > > +1
> > > >
> > > > I am for it, I think it may reduce load from our DB
> > >
> > > +1
> > >
> > The load reduction can be achieved and seems like not a big deal to
> implement
> > it.
> > +1
>
> Yes, the DB load reduction is perhaps the bigest boon of this effort :-).
>

This needs to be quantified.

As always, we need a cost-risk-benefit evaluation of a change, especially
for infra changes, since:
1. Infra changes are more likely to affect cross-teams, multiple features,
so the potential 'damage' to existing flows is not limited as in specific
feature changes.
2. If they are beneficial, we'll want/need more flows to be modified -
which adds more cost and risk (and hopefully, benefit!). If few flows
aren't changed, there's usually little value in making the change in the
first place. If only few flows are changed, unless they are critical, no
point in pushing the infra change too soon.

The events mechanism in VDSM<->engine is an example of a change that meets
this - and we haven't yet executed on item #2 above for it - not many flows
use it.
Mainly for risk and cost factors, as we do believe there is benefit in it.

Of course, such an effort has to be coordinated with the Infra team.
Y.



>
> My first patch makes very convenient to fire notification from 

Re: [ovirt-devel] Push notifications in 4.0 backend

[Eli Mesika]

- Original Message -
> From: "Vojtech Szocs" 
> To: "Martin Betak" 
> Cc: "engine-de...@ovirt.org" , "Piotr Kliczewski" 
> , "Michal Skrivanek"
> 
> Sent: Monday, November 23, 2015 6:22:45 PM
> Subject: Re: [ovirt-devel] Push notifications in 4.0 backend
> 
> 
> 
> - Original Message -
> > From: "Martin Betak" 
> > To: "Vojtech Szocs" 
> > Cc: "Einav Cohen" , "engine-de...@ovirt.org"
> > , "Roy Golan" ,
> > "Roman Mohr" , "Michal Skrivanek" ,
> > "Piotr Kliczewski" ,
> > "Tomas Jelinek" , "Alexander Wels" ,
> > "Greg Sheremeta" ,
> > "Scott Dickerson" , "Arik Hadas" ,
> > "Allon Mureinik" ,
> > "Shmuel Melamud" , "Jakub Niedermertl"
> > , "Marek Libra"
> > , "Martin Perina" , "Alona Kaplan"
> > , "Martin Mucha"
> > 
> > Sent: Thursday, November 19, 2015 1:53:07 PM
> > Subject: Re: Push notifications in 4.0 backend
> > 
> > Hi All,
> > 
> > I have created a PoC patch [1] demonstrating the idea of annotating
> > basic CRUD commands to publish CDI events. It is not meant as 100%
> > solution, but as a simplification of the common use cases when
> > one would inject CDI event with given qualifier and fire it after
> > successful completion of transaction.
> 
> The patches (mentioned below) look interesting.
> 
> At this point, it would be great if backend core maintainers
> voiced their opinions on the general idea of firing CDI events
> in response to important actions happening on Engine, such as
> backend commands being executed. So, what do you think guys?

+1

I am for it, I think it may reduce load from our DB 

> 
> > 
> > The usage of this annotations is demonstrated on several basic CRUD
> > commands in [2] on StoragePool, VDS, VDSGroup, .etc
> > 
> > As always, comments and suggestions are very welcome!
> > 
> > Thank you and best regards,
> > 
> > Martin
> > 
> > [1] infra: https://gerrit.ovirt.org/#/c/48696/
> > [2] usage: https://gerrit.ovirt.org/#/c/48697/
> > 
> > 
> > 
> > - Original Message -
> > > From: "Vojtech Szocs" 
> > > To: "Martin Betak" , "Einav Cohen" 
> > > Cc: "engine-de...@ovirt.org" , "Roy Golan"
> > > , "Roman Mohr" ,
> > > "Michal Skrivanek" , "Piotr Kliczewski"
> > > , "Tomas Jelinek"
> > > , "Alexander Wels" , "Greg
> > > Sheremeta" , "Scott
> > > Dickerson" 
> > > Sent: Friday, November 13, 2015 9:31:45 PM
> > > Subject: Re: Push notifications in 4.0 backend
> > > 
> > > Hi everyone,
> > > 
> > > assuming that 4.0 UI will be based on the existing GWT technology,
> > > I'd like to improve two things which I believe are very important:
> > > 
> > > #1 goal: improve GWT compilation times
> > >- don't use standard GWT i18n mechanism which yields separate
> > >  permutation vector, but use our own i18n mechanism instead
> > >- in practice, compiling for X browsers and Y languages should
> > >  result in GWT compiler processing X permutations (not X * Y)
> > >- this will also directly impact GWT debug performance, making
> > >  GWT debugging experience less painful for developers
> > > 
> > > #2 goal: improve UX related to backend operations
> > >- replace periodic polling with push notifications that inform
> > >  UI of changes in oVirt "system" as they happen
> > >- in practice, UI becomes reactive instead of proactive, which
> > >  has several benefits (reduced HTTP load on Engine being the
> > >  most obvious one)
> > > 
> > > So what Martin wrote in email below directly relates to #2 goal.
> > > 
> > > Push notifications improve user experience regardless of specific
> > > UI technology, regardless of whether we improve existing REST API
> > > (e.g. introduce data aggregations) or not.
> > > 
> > > For me, it's a big +1.
> > > 
> > > Having BLL commands firing CDI events upon execution makes sense.
> > > That said, I'd suggest to start with a simple implementation and
> > > proceed from there.
> > > 
> > > What Martin suggested:
> > > 
> > >   void onVmChanged(@Observes @Updated VM vm)
> > > 
> > > could be even simplified into:
> > > 
> > >   void onCommandExecuted(@Observes @CommandExecuted UpdateVmCommand cmd)
> > > 
> > > and still it would bring value to the general idea, which is the
> > > ability to detect changes in oVirt "system" as they happen along
> > > with the ability to react 

Re: [ovirt-devel] Push notifications in 4.0 backend

[Martin Perina]

- Original Message -
> From: "Eli Mesika" 
> To: "Vojtech Szocs" 
> Cc: "Piotr Kliczewski" , "Michal Skrivanek" 
> , "engine-de...@ovirt.org"
> 
> Sent: Wednesday, November 25, 2015 10:42:35 AM
> Subject: Re: [ovirt-devel] Push notifications in 4.0 backend
> 
> 
> 
> - Original Message -
> > From: "Vojtech Szocs" 
> > To: "Martin Betak" 
> > Cc: "engine-de...@ovirt.org" , "Piotr Kliczewski"
> > , "Michal Skrivanek"
> > 
> > Sent: Monday, November 23, 2015 6:22:45 PM
> > Subject: Re: [ovirt-devel] Push notifications in 4.0 backend
> > 
> > 
> > 
> > - Original Message -
> > > From: "Martin Betak" 
> > > To: "Vojtech Szocs" 
> > > Cc: "Einav Cohen" , "engine-de...@ovirt.org"
> > > , "Roy Golan" ,
> > > "Roman Mohr" , "Michal Skrivanek"
> > > ,
> > > "Piotr Kliczewski" ,
> > > "Tomas Jelinek" , "Alexander Wels"
> > > ,
> > > "Greg Sheremeta" ,
> > > "Scott Dickerson" , "Arik Hadas"
> > > ,
> > > "Allon Mureinik" ,
> > > "Shmuel Melamud" , "Jakub Niedermertl"
> > > , "Marek Libra"
> > > , "Martin Perina" , "Alona Kaplan"
> > > , "Martin Mucha"
> > > 
> > > Sent: Thursday, November 19, 2015 1:53:07 PM
> > > Subject: Re: Push notifications in 4.0 backend
> > > 
> > > Hi All,
> > > 
> > > I have created a PoC patch [1] demonstrating the idea of annotating
> > > basic CRUD commands to publish CDI events. It is not meant as 100%
> > > solution, but as a simplification of the common use cases when
> > > one would inject CDI event with given qualifier and fire it after
> > > successful completion of transaction.
> > 
> > The patches (mentioned below) look interesting.
> > 
> > At this point, it would be great if backend core maintainers
> > voiced their opinions on the general idea of firing CDI events
> > in response to important actions happening on Engine, such as
> > backend commands being executed. So, what do you think guys?
> 
> +1
> 
> I am for it, I think it may reduce load from our DB

+1

> 
> > 
> > > 
> > > The usage of this annotations is demonstrated on several basic CRUD
> > > commands in [2] on StoragePool, VDS, VDSGroup, .etc
> > > 
> > > As always, comments and suggestions are very welcome!
> > > 
> > > Thank you and best regards,
> > > 
> > > Martin
> > > 
> > > [1] infra: https://gerrit.ovirt.org/#/c/48696/
> > > [2] usage: https://gerrit.ovirt.org/#/c/48697/
> > > 
> > > 
> > > 
> > > - Original Message -
> > > > From: "Vojtech Szocs" 
> > > > To: "Martin Betak" , "Einav Cohen"
> > > > 
> > > > Cc: "engine-de...@ovirt.org" , "Roy Golan"
> > > > , "Roman Mohr" ,
> > > > "Michal Skrivanek" , "Piotr Kliczewski"
> > > > , "Tomas Jelinek"
> > > > , "Alexander Wels" , "Greg
> > > > Sheremeta" , "Scott
> > > > Dickerson" 
> > > > Sent: Friday, November 13, 2015 9:31:45 PM
> > > > Subject: Re: Push notifications in 4.0 backend
> > > > 
> > > > Hi everyone,
> > > > 
> > > > assuming that 4.0 UI will be based on the existing GWT technology,
> > > > I'd like to improve two things which I believe are very important:
> > > > 
> > > > #1 goal: improve GWT compilation times
> > > >- don't use standard GWT i18n mechanism which yields separate
> > > >  permutation vector, but use our own i18n mechanism instead
> > > >- in practice, compiling for X browsers and Y languages should
> > > >  result in GWT compiler processing X permutations (not X * Y)
> > > >- this will also directly impact GWT debug performance, making
> > > >  GWT debugging experience less painful for developers
> > > > 
> > > > #2 goal: improve UX related to backend operations
> > > >- replace periodic polling with push notifications that inform
> > > >  UI of changes in oVirt "system" as they happen
> > > >- in practice, UI becomes reactive instead of proactive, which
> > > >  has several benefits (reduced HTTP load on Engine being the
> > > >  most obvious one)
> > > > 
> > > > So what Martin wrote in email below directly relates to #2 goal.
> > > > 
> > > > Push notifications improve user experience regardless of specific
> > > > UI technology, regardless of whether we improve existing REST API
> > > > (e.g. introduce data aggregations) or not.
> > > > 
> > 

[ovirt-devel] [ANN] oVirt 3.6.1 First Release Candidate is now available for testing

[Sandro Bonazzola]

The oVirt Project is pleased to announce the availability
of the First Release Candidate of oVirt 3.6.1 for testing, as of November
25th, 2015.

This release is available now for Fedora 22,
Red Hat Enterprise Linux 6.7, CentOS Linux 6.7 (or similar) and
Red Hat Enterprise Linux >= 7.1, CentOS Linux >= 7.1 (or similar).

This release supports Hypervisor Hosts running
Red Hat Enterprise Linux >= 7.1, CentOS Linux >= 7.1 (or similar) and
Fedora 22.
Highly experimental support for Debian 8.1 Jessie has been added too.

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

Please refer to release notes [1] for Installation / Upgrade instructions.
A new oVirt Live ISO is also available[2].

Please note that mirrors[3] may need usually one day before being
synchronized.

Please refer to the release notes for known issues in this release.

[1] http://www.ovirt.org/OVirt_3.6_Release_Notes
[2] http://resources.ovirt.org/pub/ovirt-3.6-pre/iso/
[3] http://www.ovirt.org/Repository_mirrors#Current_mirrors

-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ANN] oVirt 3.6.1 First Release Candidate is now available for testing

[Sandro Bonazzola]

On Wed, Nov 25, 2015 at 3:28 PM, Sandro Bonazzola 
wrote:

> The oVirt Project is pleased to announce the availability
> of the First Release Candidate of oVirt 3.6.1 for testing, as of November
> 25th, 2015.
>
> This release is available now for Fedora 22,
> Red Hat Enterprise Linux 6.7, CentOS Linux 6.7 (or similar) and
> Red Hat Enterprise Linux >= 7.1, CentOS Linux >= 7.1 (or similar).
>
> This release supports Hypervisor Hosts running
> Red Hat Enterprise Linux >= 7.1, CentOS Linux >= 7.1 (or similar) and
> Fedora 22.
> Highly experimental support for Debian 8.1 Jessie has been added too.
>
> This release of oVirt 3.6.1 includes numerous bug fixes.
> See the release notes [1] for an initial list of the new features and bugs
> fixed.
>
> Please refer to release notes [1] for Installation / Upgrade instructions.
> A new oVirt Live ISO is also available[2].
>
> Please note that mirrors[3] may need usually one day before being
> synchronized.
>
> Please refer to the release notes for known issues in this release.
>
> [1] http://www.ovirt.org/OVirt_3.6_Release_Notes
>

sorry, the right address is http://www.ovirt.org/OVirt_3.6.1_Release_Notes


> [2] http://resources.ovirt.org/pub/ovirt-3.6-pre/iso/
> [3] http://www.ovirt.org/Repository_mirrors#Current_mirrors
>
> --
> 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
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel