Vladimir, This looks like a fairly standards compliant packaging wheel to me: "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"
Can you point at the specific part you think we're reinventing? Thanks, On Tue, Aug 5, 2014 at 8:46 AM, Vladimir Kuklin <vkuk...@mirantis.com> wrote: > Nick > > I was wondering if we are reinventing a wheel a little bit here. I am > talking about plugin format. It seems that our plugin structure is a bundle > of three entities: > 1) code, whether it is python, puppet or ruby > 2) some artifacts or static data, e.g. rpm or deb packages > 3) metadata (openstack.yaml, module version, requirements and so on) > > I am pretty sure that there is already a framework that can handle such > bundles. I think, we need to look for analogues in Java world an their > alternatives in python. It should be more advanced than pip obviously and > more abstract, but I think we should give it a shot. > > 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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~fuel-dev > More help : https://help.launchpad.net/ListHelp > > > -- > Mailing list: https://launchpad.net/~fuel-dev > Post to : fuel-dev@lists.launchpad.net > Unsubscribe : https://launchpad.net/~fuel-dev > More help : https://help.launchpad.net/ListHelp > -- Dmitry Borodaenko -- Mailing list: https://launchpad.net/~fuel-dev Post to : fuel-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp