fuel-dev team mailing list archive

[Dmitry Borodaenko <dborodaenko@xxxxxxxxxxxx>]

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 <vkuklin@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fuel-dev
> More help   : https://help.launchpad.net/ListHelp
>
>
> --
> 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
>



-- 
Dmitry Borodaenko