> 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 plugins 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 <[email protected]> Date: Tuesday, August 5, 2014 at 6:53 AM To: "[email protected]" <[email protected]> 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 : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
-- Mailing list: https://launchpad.net/~fuel-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
