fuel-dev team mailing list archive

[Andrew Woodward <awoodward@xxxxxxxxxxxx>]

I've started working on a scrubbed version of the doc and should have it
worked up on monday

Andrew
Mirantis


On Fri, Nov 22, 2013 at 1:30 AM, Evgeniy L <eli@xxxxxxxxxxxx> wrote:

> >> Also, can we extract the wiki page for the outer use?
>
> Do you want to extract it as is? In google doc?
> It think it will be better to extract it when we will actualize this page.
>
> Thanks,
>
>
> On Fri, Nov 22, 2013 at 1:00 PM, Mike Scherbakov <mscherbakov@xxxxxxxxxxxx
> > wrote:
>
>> 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
>>
>
>