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

Wednesday, 25 November 2015



----- Original Message -----
...
 From: "Eli Mesika" <emesika(a)redhat.com&gt;
 To: "Vojtech Szocs" <vszocs(a)redhat.com&gt;
 Cc: "Piotr Kliczewski" <pkliczew(a)redhat.com&gt;, "Michal
Skrivanek" <mskrivan(a)redhat.com&gt;, &quot;engine-devel(a)ovirt.org&quot;
 <devel(a)ovirt.org&gt;
 Sent: Wednesday, November 25, 2015 10:42:35 AM
 Subject: Re: [ovirt-devel] Push notifications in 4.0 backend
 
 
 ----- Original Message -----
 > From: "Vojtech Szocs" <vszocs(a)redhat.com&gt;
 > To: "Martin Betak" <mbetak(a)redhat.com&gt;
 > Cc: &quot;engine-devel(a)ovirt.org&quot; <devel(a)ovirt.org&gt;, "Piotr
Kliczewski"
 > <pkliczew(a)redhat.com&gt;, "Michal Skrivanek"
 > <mskrivan(a)redhat.com&gt;
 > Sent: Monday, November 23, 2015 6:22:45 PM
 > Subject: Re: [ovirt-devel] Push notifications in 4.0 backend
 > 
 > 
 > 
 > ----- Original Message -----
 > > From: "Martin Betak" <mbetak(a)redhat.com&gt;
 > > To: "Vojtech Szocs" <vszocs(a)redhat.com&gt;
 > > Cc: "Einav Cohen" <ecohen(a)redhat.com&gt;,
&quot;engine-devel(a)ovirt.org&quot;
 > > <devel(a)ovirt.org&gt;, "Roy Golan" <rgolan(a)redhat.com&gt;,
 > > "Roman Mohr" <rmohr(a)redhat.com&gt;, "Michal Skrivanek"
 > > <mskrivan(a)redhat.com&gt;,
 > > "Piotr Kliczewski" <pkliczew(a)redhat.com&gt;,
 > > "Tomas Jelinek" <tjelinek(a)redhat.com&gt;, "Alexander
Wels"
 > > <awels(a)redhat.com&gt;,
 > > "Greg Sheremeta" <gshereme(a)redhat.com&gt;,
 > > "Scott Dickerson" <sdickers(a)redhat.com&gt;, "Arik
Hadas"
 > > <ahadas(a)redhat.com&gt;,
 > > "Allon Mureinik" <amureini(a)redhat.com&gt;,
 > > "Shmuel Melamud" <smelamud(a)redhat.com&gt;, "Jakub
Niedermertl"
 > > <jniederm(a)redhat.com&gt;, "Marek Libra"
 > > <mlibra(a)redhat.com&gt;, "Martin Perina"
<mperina(a)redhat.com&gt;, "Alona Kaplan"
 > > <alkaplan(a)redhat.com&gt;, "Martin Mucha"
 > > <mmucha(a)redhat.com&gt;
 > > 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" <vszocs(a)redhat.com&gt;
 > > > To: "Martin Betak" <mbetak(a)redhat.com&gt;, "Einav
Cohen"
 > > > <ecohen(a)redhat.com&gt;
 > > > Cc: &quot;engine-devel(a)ovirt.org&quot; <devel(a)ovirt.org&gt;, "Roy
Golan"
 > > > <rgolan(a)redhat.com&gt;, "Roman Mohr"
<rmohr(a)redhat.com&gt;,
 > > > "Michal Skrivanek" <mskrivan(a)redhat.com&gt;, "Piotr
Kliczewski"
 > > > <pkliczew(a)redhat.com&gt;, "Tomas Jelinek"
 > > > <tjelinek(a)redhat.com&gt;, "Alexander Wels"
<awels(a)redhat.com&gt;, "Greg
 > > > Sheremeta" <gshereme(a)redhat.com&gt;, "Scott
 > > > Dickerson" <sdickers(a)redhat.com&gt;
 > > > 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 upon such changes.
 > > > 
 > > > I'm interested what Engine backend maintainers' thoughts are.
 > > > 
 > > > Regards,
 > > > Vojtech
 > > > 
 > > > 
 > > > ----- Original Message -----
 > > > > From: "Martin Betak" <mbetak(a)redhat.com&gt;
 > > > > To: &quot;engine-devel(a)ovirt.org&quot; <devel(a)ovirt.org&gt;
 > > > > Cc: "Roy Golan" <rgolan(a)redhat.com&gt;, "Roman
Mohr" <rmohr(a)redhat.com&gt;,
 > > > > "Michal Skrivanek" <mskrivan(a)redhat.com&gt;,
 > > > > "Piotr Kliczewski" <pkliczew(a)redhat.com&gt;,
"Vojtech Szocs"
 > > > > <vszocs(a)redhat.com&gt;, "Tomas Jelinek"
<tjelinek(a)redhat.com&gt;
 > > > > Sent: Wednesday, November 11, 2015 4:34:11 PM
 > > > > Subject: Push notifications in 4.0 backend
 > > > > 
 > > > > Hi All,
 > > > > 
 > > > > I would like to take this opportunity to start a discussion
 > > > > about the possibility of implementing a user facing change
 > > > > notifications.
 > > > > 
 > > > > The benefit of this would be to remove the need for periodic polling
 > > > > from frontends and other services that consume our REST API.
 > > > > 
 > > > > Also implmenting a common infrastructure on the backend for event
 > > > > notifications (e.g. CDI events) would further reduce the internal
 > > > > need for polling the DB by the backend itself, maybe even reducing
 > > > > the need to use DB for some things and just keep them in memory and
 > > > > updated by CDI event observers.
 > > > > 
 > > > > There are many solutions how to provide the user-facing part of the
 > > > > notifications:
 > > > > Doctor Rest, MQTT, websocket, server-sent events, ... .  Ideally
 > > > > these
 > > > > notifications
 > > > > should be consumable both by web browser (webadmin/userportal) but
 > > > > also
 > > > > by
 > > > > other services (such as ManageIQ), or other REST clients such as
 > > > > moVirt
 > > > > android client.
 > > > > 
 > > > > But regardless of the chosen user-facing transport, I believe a
 > > > > common
 > > > > infrastructure
 > > > > can be implemented on the BLL layer with the usage of CDI events
 > > > > fired
 > > > > from
 > > > > commands.
 > > > > I see 2 major sources of changes in the engine (please correct me if
 > > > > this
 > > > > is
 > > > > wrong):
 > > > > 1) CRUD & management commands
 > > > > 2) Vms/Hosts monitoring
 > > > > 
 > > > > the changes originating from 2) are AFAIK very localized and not so
 > > > > numerous
 > > > > so a manual
 > > > > firing of appropriate events for VMs and Hosts could be added here.
 > > > > 
 > > > > The 1) case is more extensive in terms of required code changes.
 > > > > While
 > > > > a
 > > > > manual solution
 > > > > would still be feasible, I believe there is place for a more
 > > > > automated/declarative way.
 > > > > 
 > > > > One solution for 1) that comes to my mind are simple command-level
 > > > > annotations covering the
 > > > > Created, Updated, Removed (C, U, and D from CRUD) cases. The goal
 > > > > here
 > > > > is
 > > > > to
 > > > > fire the
 > > > > appropriate CDI events when an entity is created/updated/deleted.
 > > > > Since
 > > > > commands usually
 > > > > contain getters for entities they work with (such as getVm(),
 > > > > getVds(),
 > > > > getStorageDomain() ...)
 > > > > It should be sufficient for the most common simple cases (of course
 > > > > this
 > > > > will
 > > > > not cover
 > > > > everything) to use annotation @Creates, @Updates, @Removes on the
 > > > > commands
 > > > > classes, where
 > > > > parameters of the annotation should specify the getter method that
 > > > > returns
 > > > > the affected entity
 > > > > (VM/VDS/StorageDomain...). This could be specified by the entity
 > > > > class
 > > > > token
 > > > > or method name
 > > > > (depending on the level of "magic" one prefers :-) and the
 > > > > CommandBase
 > > > > infrastructure would
 > > > > then collect those annotations and upon successful completion of the
 > > > > command
 > > > > fire the
 > > > > appropriate events.
 > > > > 
 > > > > Example #1:
 > > > > @Updates('getVm') // or @Updates(VM.class)?
 > > > > public class UpdateVmCommand<...>  extends
VmManagementComandBase ...
 > > > > 
 > > > > Note that since Java 8 we have repeatable annotations so we can have
 > > > > more
 > > > > complex commands
 > > > > that affect more entities.
 > > > > 
 > > > > Example #2:
 > > > > @Updates(Vm.class)
 > > > > @Updates(VmTemplate.class)
 > > > > // possibly also some @Creates and @Removes annotations or their
 > > > > combination
 > > > > public class ContrivedExampleCommand extends SomeCommandBase
 > > > > 
 > > > > the infrastructure would then look upon successful completion of the
 > > > > command
 > > > > on the getVm()
 > > > > and getVmTemplate() methods, invoke them, determine the resulting
 > > > > types
 > > > > of
 > > > > entities VM and VmTemplate
 > > > > and since the annotations used were @Updates fire CDI event
 > > > > equivalent
 > > > > to
 > > > > 
 > > > >   @Inject
 > > > >   @Updated // our custom CDI qualifier
 > > > >   Event<VM> vmChangedEvent;
 > > > > 
 > > > > and anologously for VmTemplate.
 > > > > 
 > > > > But regardless of the exact implementation of the CDI event firing:
 > > > > whether
 > > > > manual, the above
 > > > > proposal, or some crazy usage of AspectJ - the interface for the
rest
 > > > > of
 > > > > the
 > > > > code should always
 > > > > be the like this:
 > > > > 
 > > > > public void onVmChanged(@Observes @Updated VM vm) {
 > > > >     // ....
 > > > > }
 > > > > 
 > > > > On top of this, I believe, we can build the user-facing part of push
 > > > > notifications and also
 > > > > improve our existing backend code.
 > > > > 
 > > > > Thank you for reading this long email and I welcome any comments or
 > > > > counter-proposals you
 > > > > might have on this topic :-)
 > > > > 
 > > > > Best regards,
 > > > > 
 > > > > Martin
 > > > > 
 > > > 
 > > 
 > _______________________________________________
 > Devel mailing list
 > Devel(a)ovirt.org
 > http://lists.ovirt.org/mailman/listinfo/devel
 > 
 _______________________________________________
 Devel mailing list
 Devel(a)ovirt.org
 http://lists.ovirt.org/mailman/listinfo/devel

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

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