fuel-dev team mailing list archive

[David Easter <deaster@xxxxxxxxxxxx>]

Dmitry,

  These are good suggestions.   A few additional comments:

> Function which automatically loads each plugin (e.g. it should execute init
manifest of each class with name mask "plugin_.*") is required.

For this one, I¹d like to keep in mind the desired requirement for a 3rd
party vendor to provide a plug-in module that can be downloaded and
connected to Fuel post-release - i.e. in the field and post-installation of
the Fuel Master Node.

Here¹s the general user story for those unfamiliar with the goals for the
pluggable architecture:
User Story
 Partners and community members are asking for ways to add their own value
to Fuel so that customers will automatically have an option to utilize a
partner¹s offering.   There are several situations that a pluggable
architecture needs to address:
Inclusion of partner drivers
 Partners and community members want to make Fuel capable of deploying
drivers for their offering that are designed to work with OpenStack.  By
making these driver deployments (semi-)automatically available in Fuel,
their expectation is that customers will be more likely to use their
solution.
 In some cases, including a driver may require only introducing the driver
itself onto the Fuel Master Node and making it available as a deployment
option in a configuration template.  For example, if a vendor was providing
a driver that integrated with Neutron (Quantum), the partner would expect
that Fuel could offer to deploy that driver anywhere that Neutron were
deployed.  
 A slightly more advanced case is where the driver also requires
configuration questions to be answered prior to deployment.  This will mean
that the pluggable architecture will need to enable partners to add either
an additional screen or additional configuration options to existing screens
within Fuel. 
 Another case would be where the driver is already included in OpenStack
core projects and thus is already available in a distribution that contains
the OpenStack core projects.  In this situation, the pluggable architecture
would only need enable additional screens or configuration options within
Fuel.
Adding value-add utilities
 Another point of integration will be to complete utilities that add value
to Fuel overall, but are not part of the core product.  Examples of this
include the Real-Time Dashboard and Testing Framework.  These items need to
be ³plugged in² and available as Fuel deploys a complete solution, but are
sitting just outside of OpenStack itself.  In some cases, agents may be
deployed to nodes to enable functionality (e.g. monitoring / testing) but
are not mandatory for OpenStack to run properly.


 To make the pluggable architecture as useful as possible, it should allow
for two situations:
* Inclusion of drivers/utilities/value-add as part of a distribution.  In
other words, upon receiving a new version of the distribution, the added
value would be included in the release itself with no need to download
anything additional.  Menu options, screens and other integration points
would be visible and available immediately.
> * 
> * A variation on this would be to have the items in the released version, but
> only activated upon meeting a condition defined by the 3rd party vendor (e.g.
> entering a key)
* 
* Ability for a 3rd party vendor to provide a plug-in module that can be
downloaded and connected to Fuel post-release - i.e. in the field.  The
architecture would, upon completion of the install for the 3rd party
plug-in, make the driver/utilities/value-add options available to the Fuel
user.  This will require that the Fuel UI be dynamic in nature.
> * 
> * A potential way (but not the only way) to implement this would be to have a
> directory structure where 3rd party content can be loaded by vendors.  Fuel
> would read from this directory at an appropriate time (refresh, reboot) and
> upon detecting the 3rd party content, activate it.
> * 
> * An ability to download the plug-in module to the server (where Fuel will be
> installed) prior to the installation of the Fuel Master Node is also a
> possibility, although implementing only in this manner severely limits the
> value of the plug-in architecture to partners.
 Thanks,

- David J. Easter
  Product Line Manager,  Mirantis


From:  Roman Alekseenkov <ralekseenkov@xxxxxxxxxxxx>
Date:  Friday, December 27, 2013 at 5:23 PM
To:  Dmitry Ukov <dukov@xxxxxxxxxxxx>
Cc:  "fuel-dev@xxxxxxxxxxxxxxxxxxx" <fuel-dev@xxxxxxxxxxxxxxxxxxx>
Subject:  Re: [Fuel-dev] Fuel plugin ideas

Dmitry - sounds like a great start.

Team,

Pluggable architecture is a priority for 4.1. Given that we are now done
with Havana release, please make an effort to review and give prompt
feedback to Dmitry.

Thanks,
Roman

On Wednesday, December 25, 2013, Dmitry Ukov  wrote:
> Hello folks,
> recently I've refactored integration of Neutron Nicira NSX plugin installation
> into fuel library (https://review.openstack.org/#/c/64002/). All modifications
> are gathered into one puppet module.
> I have some thoughts on implementation of plugin system in Fuel library
> 1. Each plugin has to be implemented as a separate module. Init manifest
> withouta input parameters (init.pp) should be used as an entry point to each
> plugin.
> 2. All parameters for plugin should be kept in astute.yaml
> 3. Plugin naming convention should be developed.
> 4. Function which automatically loads each plugin (e.g. it should execute init
> manifest of each class with name mask "plugin_.*") is required.
> 5. Staging system should be implemented. All plugins have to be executed in a
> separate stage (e.g. Stage['main'] -> stage {'plugins':} )
> 6. Each puppet class which is used with library has to have the ability to be
> disabled from plugin
> 7. This is necessary because plugins may require to disable some services.
> Alternatively this can be implemented by using resource collections (e.g.
> Service <| title == l3-agent|> { noop => true }) but we can't execute plugin
> in a separate stage in this case.
> What do you think on this? I'd like hear a feedback on my ideas and module
> implementation.
> Thank you in advance.
> 
> -- 
> Kind regards
> Dmitry Ukov
> IT Engineer
> Mirantis, Inc.
> 
-- 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