Re: [ovirt-devel] Thoughts on modularization

----- Original Message ----- > From: "Yair Zaslavsky" <yzaslavs(a)redhat.com&gt; > To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; > Cc: "Vojtech Szocs" <vszocs(a)redhat.com&gt;, "Mark Proctor" <mdproctor(a)gmail.com&gt;, devel(a)ovirt.org > Sent: Wednesday, November 5, 2014 9:40:05 PM > Subject: Re: [ovirt-devel] Thoughts on modularization > > > > ----- Original Message ----- >> From: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; >> To: "Vojtech Szocs" <vszocs(a)redhat.com&gt; >> Cc: "Mark Proctor" <mdproctor(a)gmail.com&gt;, devel(a)ovirt.org >> Sent: Wednesday, November 5, 2014 6:16:15 PM >> Subject: Re: [ovirt-devel] Thoughts on modularization >> >> >> >> ----- Original Message ----- >>> From: "Vojtech Szocs" <vszocs(a)redhat.com&gt; >>> To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; >>> Cc: devel(a)ovirt.org, "Mark Proctor" <mdproctor(a)gmail.com&gt; >>> Sent: Wednesday, November 5, 2014 6:07:50 PM >>> Subject: Re: [ovirt-devel] Thoughts on modularization >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; >>>> To: "Vojtech Szocs" <vszocs(a)redhat.com&gt; >>>> Cc: devel(a)ovirt.org, "Mark Proctor" <mdproctor(a)gmail.com&gt; >>>> Sent: Wednesday, November 5, 2014 4:32:31 PM >>>> Subject: Re: [ovirt-devel] Thoughts on modularization >>>> >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Vojtech Szocs" <vszocs(a)redhat.com&gt; >>>>> To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; >>>>> Cc: devel(a)ovirt.org, "Mark Proctor" <mdproctor(a)gmail.com&gt; >>>>> Sent: Wednesday, November 5, 2014 5:24:14 PM >>>>> Subject: Re: [ovirt-devel] Thoughts on modularization >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; >>>>>> To: "Vojtech Szocs" <vszocs(a)redhat.com&gt; >>>>>> Cc: devel(a)ovirt.org, "Mark Proctor" <mdproctor(a)gmail.com&gt; >>>>>> Sent: Wednesday, November 5, 2014 4:12:06 PM >>>>>> Subject: Re: [ovirt-devel] Thoughts on modularization >>>>>> >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Vojtech Szocs" <vszocs(a)redhat.com&gt; >>>>>>> To: devel(a)ovirt.org >>>>>>> Cc: "Mark Proctor" <mdproctor(a)gmail.com&gt; >>>>>>> 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. I'm not against config files, annotations are static metadata too anyway.

>>> * 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(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel >> _______________________________________________ Devel mailing list Devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/devel