[ovirt-devel] Thoughts on modularization
Yair Zaslavsky
yzaslavs at redhat.com
Wed Nov 5 20:40:05 UTC 2014
----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Vojtech Szocs" <vszocs at redhat.com>
> Cc: "Mark Proctor" <mdproctor at gmail.com>, devel at ovirt.org
> Sent: Wednesday, November 5, 2014 6:16:15 PM
> Subject: Re: [ovirt-devel] Thoughts on modularization
>
>
>
> ----- Original Message -----
> > From: "Vojtech Szocs" <vszocs at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: devel at ovirt.org, "Mark Proctor" <mdproctor at gmail.com>
> > Sent: Wednesday, November 5, 2014 6:07:50 PM
> > Subject: Re: [ovirt-devel] Thoughts on modularization
> >
> >
> >
> > ----- Original Message -----
> > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > To: "Vojtech Szocs" <vszocs at redhat.com>
> > > Cc: devel at ovirt.org, "Mark Proctor" <mdproctor at gmail.com>
> > > Sent: Wednesday, November 5, 2014 4:32:31 PM
> > > Subject: Re: [ovirt-devel] Thoughts on modularization
> > >
> > >
> > >
> > > ----- Original Message -----
> > > > From: "Vojtech Szocs" <vszocs at redhat.com>
> > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > Cc: devel at ovirt.org, "Mark Proctor" <mdproctor at gmail.com>
> > > > Sent: Wednesday, November 5, 2014 5:24:14 PM
> > > > Subject: Re: [ovirt-devel] Thoughts on modularization
> > > >
> > > >
> > > >
> > > > ----- Original Message -----
> > > > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > To: "Vojtech Szocs" <vszocs at redhat.com>
> > > > > Cc: devel at ovirt.org, "Mark Proctor" <mdproctor at gmail.com>
> > > > > Sent: Wednesday, November 5, 2014 4:12:06 PM
> > > > > Subject: Re: [ovirt-devel] Thoughts on modularization
> > > > >
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > > From: "Vojtech Szocs" <vszocs at redhat.com>
> > > > > > To: devel at ovirt.org
> > > > > > Cc: "Mark Proctor" <mdproctor at gmail.com>
> > > > > > Sent: Wednesday, November 5, 2014 5:04:24 PM
> > > > > > Subject: [ovirt-devel] Thoughts on modularization
> > > > > >
> > > > > > Hi guys,
> > > > > >
> > > > > > I've discussed this recently with Yair and Mark, I just wanted to
> > > > > > share
> > > > > > some more thoughts on this topic -- in particular, how
> > > > > > modularization
> > > > > > problem can be approached (regardless of implementation details).
> > > > > >
> > > > > > I see two approaches here. The typical one is to define APIs for
> > > > > > modules
> > > > > > to consume. For example, oVirt Engine extension API has API for
> > > > > > auth
> > > > > > stuff; oVirt UI plugin API has API for showing tabs and dialogs,
> > > > > > etc.
> > > > > > The advantage is strict consistency, disadvantage is burden of
> > > > > > having
> > > > > > to maintain the whole API. With this approach, you tell modules:
> > > > > > "This
> > > > > > is the API to work with system, defining how you can plug into it."
> > > > > >
> > > > > > Now turn 180 degrees. The other approach, which is really
> > > > > > interesting,
> > > > > > is to let modules themselves export API. This naturally leads to
> > > > > > module
> > > > > > hierarchies. Ultimately, this leads to micro-kernel-style
> > > > > > development,
> > > > > > where all logic resides in modules. Now you might ask: "What if we
> > > > > > want
> > > > > > to employ some consistent work flow across multiple modules? For
> > > > > > example,
> > > > > > have some pluggable *auth* infra?" -- this can be done via some
> > > > > > "higher"
> > > > > > level module, that exports API and "lower" level modules consume
> > > > > > that
> > > > > > API.
> > > > > >
> > > > > > If you have any ideas, please share!
> > > > >
> > > > > Both solutions can be applied using existing extension api, an
> > > > > extension
> > > > > can
> > > > > locate other extension and interact with it the same way the core
> > > > > interacts
> > > > > with extensions.
> > > >
> > > > But how does core interact with extensions? I assume via well-defined
> > > > API, i.e. in accordance with first approach mentioned above.
> > >
> > > presentation:
> > > http://www.ovirt.org/File:Ovirt_3.5_-_aaa.pdf
> >
> > Thanks for sharing!
> >
> > >
> > > package org.ovirt.engine.api.extensions;
> > >
> > > /**
> > > * Interface of an extension.
> > > */
> > > public interface Extension {
> > >
> > > /**
> > > * Invoke operation.
> > > * @param input input parameters.
> > > * @param output output parameters.
> > > *
> > > * <p>
> > > * Interaction is done via the parameters.
> > > * Exceptions are not allowed.
> > > * </p>
> > > * <p>
> > > * Basic mappings available at {@link Base}.
> > > * </p>
> > > *
> > > * @see Base
> > > */
> > > void invoke(ExtMap input, ExtMap output);
> > >
> > > }
> >
> > OK, so it was my lack of knowledge of AAA implementation :)
> >
> > Since Extension interface is invoke-based, I assume that Engine
> > core (backend) invokes extensions on specific occasions, right?
>
> correct, and nothing prevents extension to invoke other extensions.
>
> > >
> > > > With second approach mentioned above, core would not interact with
> > > > extensions at all (or in a very limited way), instead - extensions
> > > > would interact with each other. In other words, extension would not
> > > > need to implement core-specific API (there would be none), instead
> > > > it would inject its dependencies (other modules/extensions) and
> > > > consume their APIs. This is the difference I wanted to point out :)
> > >
> > > The extension interface is primitive to enable exactly that, provided
> > > java
> > > people will open their minds :)
> >
> > Simple interface means great flexibility, now I understand the
> > rationale behind typed maps in extension API.
> >
> > What I had in mind was something like this (maybe crazy):
> >
> > * imagine for a moment that the backend is fully modular
> > (logic lives in modules, no logic outside modules)
> >
> > * @DependsOn("SomeOtherModule") // modules can form hierarchies
> > public class MyModule implements Module {
> > public void loaded() {} // executed just once per module
> > }
>
> you again using java magic for something that can go to declaration...
Vojtech, I have to agree with Alon here,
as much as I enjoyed in the past seeing hibernate move to annotations , I think in our case a configuration file is better.
>
> >
> > * API for fetching modules, i.e. getModuleByName('xxx')
>
> there is no need as within the extension context you have access to this
> information, all you need is iterate a list, see Base.java.
>
> > API for exporting module API, i.e. exportApiObject(foo)
>
> not sure why it is needed... once extension is loaded it is available.
>
> > This way, you'd have one "core" module, providing most general
> > functionality/abstractions. Then you'd have more specific modules,
> > plugged into "core" module's API etc. In other words, hierarchy of
> > modules. This is essentially modularization taken to extreme :)
> >
> > (BTW, above is just an idea.)
>
> not sure I understand what is the functionality difference between this and
> the primitive approach we already have...
>
> 1. every configuration at /etc/ovirt-engine/extensions.d and
> /usr/share/ovirt-engine/extensions.d are loaded during engine startup.
>
> 2. each extension has two phases load and init, during init an extension can
> locate other extensions by name via its context. it is true that probably
> missing functionality is to support ordering of the init and load, we left
> it into future as there was no actual need for this.
>
> 3. each extension can interact with other extension.
>
> 4. there must be core model to trigger the entire thing, core cannot be just
> a loader.
Alon, can you elaborate here on number 4?
In an ideal world, wouldn't you want to have the "engine core" be a small as something that goes over the extensions and loads them? and maybe let each extension expose somehow its relevant part of rest-api (besides of using ext-api to interact between extension and of course each extension should have the relevant logic implementerd within)
>
> Alon
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
More information about the Devel
mailing list