[ovirt-devel] Thoughts on modularization

Tue Nov 11 13:23:14 UTC 2014

On 11/07/2014 04:53 PM, Vojtech Szocs wrote:
>
> ----- Original Message -----
>> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Mark Proctor" <mdproctor at gmail.com>, devel at 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 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.
> I'm not against config files, annotations are static metadata too anyway.

correct and CDI has both abilities - annotation and XML configuration

some of the things you are talking about here is established for long 
time using jboss-osgi btw.

will dig for examples for OSGI & CDI interactions as I seen few .

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