fuel-dev team mailing list archive

[Nikolay Markov <nmarkov@xxxxxxxxxxxx>]

Hi David,

Sure, each plugin will include just it's own business logic which will use
certaing places in the code (called hooks) to interact with Fuel/Nailgun
code.

Let me give you an example - if plugin provides just a custom role in
Nailgun and some RPC serialization logic - then it will be just a config
file with role description (as we now have it in openstack.yaml) and a
Python module containing a single class (which inherits from one or
multiple built-in ones in Nailgun) with a couple of methods on additional
serialization, both files are located in Python package with it's own
setup.py. Then, this package should be packed as an RPM and will be
installed into Nailgun container on master node, which will make this code
visible and usable from Nailgun.


On Tue, Aug 5, 2014 at 6:06 PM, David Easter <deaster@xxxxxxxxxxxx> wrote:

> > As for now, it looks like each plugin or group of plugins will have it's
> own repo and will be provided as a bunch of RPM packages to install into
> Docker containers.
>
> Hi Nick,
>
>   Thanks for the update.  Just to better understand this item, when you
> say that each plugin or group of plugin will have it’s own repo, will the
> partner/customer/services create this repo to contain only the delta in
> functionality that their plugin provides?  Or would they need to create an
> entire repo for all the OpenStack services - including services that were
> not modified?  I assume (and hope) the former so that plug–ins can stay
> small and focused, but just wanted to make sure.  In other words, if I’m
> adding a Cinder driver, I need only supply RPM packages that contain the
> driver, install scripts for my driver and UI changes – I wouldn’t have to
> create an entire deployment of Neutron, Keystone, Glance, Nova, etc that
> just happens to also contain my Cinder driver – right?
>
> Thanks,
>
> -Dave Easter
>
> From: Nikolay Markov <nmarkov@xxxxxxxxxxxx>
> Date: Tuesday, August 5, 2014 at 6:53 AM
> To: "fuel-dev@xxxxxxxxxxxxxxxxxxx" <fuel-dev@xxxxxxxxxxxxxxxxxxx>
> Subject: [Fuel-dev] Meeting notes on Fuel Plugins
>
> Hello everybody!
>
> We had a meeting on Fuel (mostly Nailgun) plugins architecture. So, there
> were multiple topics to discuss, we didn't really achieve an agreement, but
> made some really helpful notes.
>
> 1. We should provide infrastructure for plugins, which means making most
> of Nailgun entities abstract/default, allowing plugins to override them and
> implement their own business logic on top. This may include multiple levels
> (usually two), like Neutron plugin and NSX plugin for Neutron plugin.
> 2. There will be some core plugins, which will be installed together with
> Nailgun and can't be deleted without ruining an important functionality.
> 3. In some cases plugins will override behaviour of default Nailgun HTTP
> handlers, but in this case they will follow some certain guides on
> formatting.
> 4. We leave existing hooks as is and add it when needed, it's too hard for
> now to determine certain places which may be overrided. Also, we already
> need some infrastructure for third-party developers to jump from.
> 5. Some documentation on how plugins should be provided and tested. As for
> now, it looks like each plugin or group of plugins will have it's own repo
> and will be provided as a bunch of RPM packages to install into Docker
> containers.
>
> Any additions, colleagues?
>
> Also, we're planning to organize a meeting in English tomorrow together
> with guys from Poland and maybe other places. Which time is the most
> appropriate for you?
>
> --
> Best regards,
> Nick Markov
> -- Mailing list: https://launchpad.net/~fuel-dev Post to :
> fuel-dev@xxxxxxxxxxxxxxxxxxx Unsubscribe : https://launchpad.net/~fuel-dev
> More help : https://help.launchpad.net/ListHelp
>



-- 
Best regards,
Nick Markov