[ovirt-users] webhook

Sat Nov 1 05:34:39 EDT 2014

Whoow, just missed a couple of days I see... thanks everybody for your
already given support!! I will discuss this also with my colleague on
Monday. And I must say I'm impressed about all the fedback! This could be
indeed a very nice extension to oVirt, because I guess we are not the only
ones who are in need of this or will be in the future.
Thanks again!

2014-10-31 22:51 GMT+01:00 Yair Zaslavsky <yzaslavs at redhat.com>:

>
>
> ----- Original Message -----
> > From: "Einav Cohen" <ecohen at redhat.com>
> > To: "Vojtech Szocs" <vszocs at redhat.com>
> > Cc: "Oved Ourfali" <ovedo at redhat.com>, users at ovirt.org
> > Sent: Friday, October 31, 2014 9:01:34 PM
> > Subject: Re: [ovirt-users] webhook
> >
> > > ----- Original Message -----
> > > From: "Vojtech Szocs" <vszocs at 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.
> 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?
> 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?
>
> > >
> > > [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 at redhat.com>
> > > > To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > > > Cc: "Koen Vanoppen" <vanoppen.koen at gmail.com>, users at ovirt.org,
> "Vojtech
> > > > Szocs" <vszocs at 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 at redhat.com>
> > > > > To: "Koen Vanoppen" <vanoppen.koen at gmail.com>
> > > > > Cc: "Oved Ourfali" <ovedo at redhat.com>, users at 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 at gmail.com>
> > > > > > To: users at 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 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
> > >
> > _______________________________________________
> > 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/users/attachments/20141101/da23e612/attachment-0001.html>