fuel-dev team mailing list archive

[David Easter <deaster@xxxxxxxxxxxx>]

> 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