fuel-dev team mailing list archive

[Mike Scherbakov <mscherbakov@xxxxxxxxxxxx>]

As far as Fuel modularity is concerned, I'd ask everyone to check the etherpad
created by Andrew <https://etherpad.openstack.org/p/bp-fuel-modularization> and
provide your comments there.

Also, can we extract the wiki page for the outer use?

On Thu, Nov 21, 2013 at 11:56 AM, Evgeniy L <eli@xxxxxxxxxxxx> wrote:

> It is necessary to take into account the fact that this design [1] was
> written half of year ago.
> So, I'm sure that some parts of this doc are outdated.
> E.g. if we will use lxc containers for master node [2] plugin installation
> process will be changed.
>
> [1] https://mirantis.jira.com/wiki/display/PRD/Pluggable+architecture
> [2] "Technical details" section
> https://docs.google.com/a/mirantis.com/document/d/1Mem9LP7ysaHNNSltlCLPw36jHix5ULlKmsMgTViHfog/edit#heading=h.8n4jqukl6fbe
>
>
> On Thu, Nov 21, 2013 at 2:20 AM, Andrew Woodward <awoodward@xxxxxxxxxxxx>wrote:
>
>> I've reviewed Evgeniy's Plugin docs and feel that under the scope of
>> VMware integration that It would be possible to skip (for now) the large
>> amount of work that would be required to implement a full function Plugin
>> interface. Instead, if we take the time to document all the intentions of
>> the plugin framework, and then only work on the aspects needed for the
>> VMware integration such as the low-level hooks that I've attempted to
>> document in [1].
>>
>> This would allow us to accelerate on the work required for vmw, and start
>> building the framework needed to manage this type of work further. This
>> would require us to ship a separate version with vmw embedded, but should
>> allow us to pull it into a package as soon as the remaining framework is
>> ready.
>>
>> As to the plugin framework itself, Evgeniy goes into a lot of great
>> detail I don't know if this is derived from any prior art /experience. I
>> would recommend reviewing what some other community projects implement such
>> as cacti (php)[2][3]. Which has a very strong community supported plugin
>> ecosystem. In some cases, other plugins expose further hooks that
>> subsequent plugins can also access.
>>
>> In the next day or two, I'd like to merge Evgeniy's thoughts with mine on
>> the matter of Plugin Architecture, and this discuss this further.
>>
>> [1] https://etherpad.openstack.org/p/bp-fuel-modularization
>> [2] http://docs.cacti.net/plugins:development.create_new
>> [3] http://docs.cacti.net/plugins:development.hook_api_ref
>>
>>
>>
Thanks,
-- 
Mike Scherbakov
#mihgen