----- Original Message -----
From: "Yair Zaslavsky" <yzaslavs(a)redhat.com>
To: "Einav Cohen" <ecohen(a)redhat.com>
Cc: "Vojtech Szocs" <vszocs(a)redhat.com>, "Oved Ourfali"
<ovedo(a)redhat.com>, users(a)ovirt.org
Sent: Friday, October 31, 2014 10:51:03 PM
Subject: Re: [ovirt-users] webhook
----- Original Message -----
> From: "Einav Cohen" <ecohen(a)redhat.com>
> To: "Vojtech Szocs" <vszocs(a)redhat.com>
> Cc: "Oved Ourfali" <ovedo(a)redhat.com>, users(a)ovirt.org
> Sent: Friday, October 31, 2014 9:01:34 PM
> Subject: Re: [ovirt-users] webhook
>
> > ----- Original Message -----
> > From: "Vojtech Szocs" <vszocs(a)redhat.com>
> > Sent: Friday, October 31, 2014 11:51:53 AM
> >
> > Hi,
> >
> > if I get this correctly, you'd like to be notified when certain event
> > happens (VM created/deleted/etc.) and react upon that. I see multiple
> > possible approaches here:
> >
> > 0, improve Engine extension API (refer to Alon Bar-Lev for details)
> > - if extensions can be packaged as JARs and these JARs could include
> > web fragments [1] it would mean the possibility to deploy custom
> > servlets onto existing Engine instance (in context of webapp that
> > processes extensions)
> > - your custom Java servlet could query REST interface (or be notified
> > once something happens, but AFAIK we don't have that implemented
> > yet)
> > and do whatever logic is needed
> > - once I asked Alon about ^^ but never got response from him
> > - IMHO this would be a nice way to deploy custom Java code on Engine
Please allow me to step in as someone who worked on the extensions API as
well,
There are more "missing bits" here.
You are referring to the "webapp side", but this is not enough.
We have also the engine side which has to become more pluggable.
Agreed. For me, the "webapp side" is really an interesting option, since it
would mean that 3rd parties could write custom code that would consume our
existing Java/Engine "services" (assuming these could be exposed across WARs).
In other words, plug custom Java code into Engine ("inside-product
integration"),
as opposed to typical scenario where 3rd party system uses Engine REST interface
("outside-product integration").
In addition, we will probably need to handle all kinds of issues that
rise
from our singletons at engine - class loading might be an issue here, no?
Hm, Java class loaders have hierarchy, so if we put shared Java "services"
(ideally exposed and injectable as CDI beans) into class loader above specific
webapp (WAR) class loaders, it wouldn't be a problem. But I can be wrong here.
You don't want the "X-ton" (doubleton, tripleton,
etc..) phenomena in your
setup - you don't want for example X instances of AsyncTaskManager.
I think that in general we should strive to turn engine into way more
pluggable/modular than it is now, imagine an "engine microkernel" (for those
of you who did not hear the term microkernel, I am referring you to jboss
architecture) - we should have a "thin microkernel" and the rest of the code
should be pluggable, using the extension API (and perhaps web fragments as
well).
What do you think?
Great ideas :)
> >
> > [1]
https://blogs.oracle.com/swchan/entry/servlet_3_0_web_fragment
> >
> > 1, improve UI plugin API
> > - add "VirtualMachineDataLoaded" event fired upon each refresh of
> > VM data in UI table (generalization -> "{Entity}DataLoaded")
> > - this is similar to existing "{Entity}SelectionChange" events
>
> relying on changes in the UI table is a bad idea:
>
> (1) potentially missing events:
> the UI displays paginated data; if my VMs are sorted by name, and
> I have 1000 VMs in my setup, and I just added a VM named "z", it will
> be added to the last "page" which is not displayed right now, so I
> wouldn't even be aware that something was added.
>
> (2) potentially "creating" "fake" events:
> changes in the displayed data in the UI can occur due to change in the
> Search query; if I have 50 VMs in my setup, and I initially had the
> "Vms:" search query, and now I change it to "VMs: name = a*",
which
> results in displaying only 10 VMs, this may falsely hint on removal
> of 40 VMs from the system.
>
> >
> > 2, write UI plugin that uses oVirtJS to periodically check VM events
>
> not sure if this is referring to VM-related events in the code (e.g.
> hooking to the click on "OK" within the New VM / Remove VM dialog,
> or hooking to the "Success" callback of the action response, or
> something similar), or to the VM-related "Events" (i.e. the ones that
> are displayed in the GUI within the Events main-tab / bottom section).
> If the former: can be done, I assume, though not sure how complex it
> would be to implement the infrastructure for that.
> If the latter: this will "catch" actions that were performed either
> via the GUI or outside the GUI; in this case, it would probably be
> better to use an Engine extension API (solution "0" above) rather
> than a UI plugin, since it will be more reliable, will be active
> even when the GUI is not in use, etc.
>
> >
> > The disadvantage of 1, and 2, is that WebAdmin GUI must be open.
> > In any case, if you'd like to explore the possibility of doing this
> > via UI plugin, I'm here to help.
> >
> > Vojtech
> >
> >
> > ----- Original Message -----
> > > From: "Oved Ourfali" <ovedo(a)redhat.com>
> > > To: "Yair Zaslavsky" <yzaslavs(a)redhat.com>
> > > Cc: "Koen Vanoppen" <vanoppen.koen(a)gmail.com>,
users(a)ovirt.org,
> > > "Vojtech
> > > Szocs" <vszocs(a)redhat.com>
> > > Sent: Thursday, October 30, 2014 2:10:12 PM
> > > Subject: Re: [ovirt-users] webhook
> > >
> > > Hi
> > >
> > > CC-ing also Vojtech, the "father" of the UI plugins.
> > >
> > > Anyway, the only way to accomplish that via UI plugins at the moment is
> > > via
> > > adding a new "action menu item", that in the background deleted
the VM,
> > > and
> > > reports to Foreman.
> > > I would be nice to have a "hook" for different UI action items,
but it
> > > isn't
> > > available at the moment.
> > > There are plenty code samples for UI plugins, most of them available
> > > at:
> > >
http://www.ovirt.org/Features/UIPlugins
> > >
> > > I must say that I'm not sure webhooks are the right approach for
that,
> > > as
> > > I
> > > guess it is relevant only in environments in which one doesn't use
the
> > > API/CLI/SDK....
> > > but.. it will be a cool feature!
> > >
> > > Regards,
> > > Oved
> > >
> > > ----- Original Message -----
> > > > From: "Yair Zaslavsky" <yzaslavs(a)redhat.com>
> > > > To: "Koen Vanoppen" <vanoppen.koen(a)gmail.com>
> > > > Cc: "Oved Ourfali" <ovedo(a)redhat.com>,
users(a)ovirt.org
> > > > Sent: Thursday, October 30, 2014 1:44:38 PM
> > > > Subject: Re: [ovirt-users] webhook
> > > >
> > > > Oved - can we implement something like this using ui-plugins?
> > > >
> > > >
> > > > ----- Original Message -----
> > > > > From: "Koen Vanoppen" <vanoppen.koen(a)gmail.com>
> > > > > To: users(a)ovirt.org
> > > > > Sent: Monday, October 27, 2014 4:06:40 PM
> > > > > Subject: [ovirt-users] webhook
> > > > >
> > > > > Hi all,
> > > > >
> > > > > Just a quick question. Is it possible to set a webhook on the
> > > > > removal
> > > > > and
> > > > > creation of a new vm? So we can send to foreman a delete action
> > > > > when
> > > > > the
> > > > > VM
> > > > > is deleted...
> > > > >
> > > > > Kind regards,
> > > > >
> > > > > Koen
> > > > >
> > > > > _______________________________________________
> > > > > Users mailing list
> > > > > Users(a)ovirt.org
> > > > >
http://lists.ovirt.org/mailman/listinfo/users
> > > > >
> > > > _______________________________________________
> > > > Users mailing list
> > > > Users(a)ovirt.org
> > > >
http://lists.ovirt.org/mailman/listinfo/users
> > > >
> > >
> > _______________________________________________
> > Users mailing list
> > Users(a)ovirt.org
> >
http://lists.ovirt.org/mailman/listinfo/users
> >
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
>
http://lists.ovirt.org/mailman/listinfo/users
>