Open Stack

Hi all,
I moved this conversation to openstack-dev to get a broader audience, since
we started to discuss technical details.

Raw notes from demo session:
https://etherpad.openstack.org/p/cinder-neutron-plugins-second-demo.

Let me start answering on a few questions below from Roman & Nathan.

> How are we planning to distribute fuel plugin builder and its updates?
> Ideally, it should be available externally (outside of master node). I
> don't want us to repeat the same mistake as we did with Fuel client, which
> doesn't seem to be usable as an external dependency.

The plan was to have Fuel Plugin Builder (fpb) on PyPI. Ideally it should
be backward compatible with older Fuel release, i.e. when there is Fuel 7.0
out, you should be still able to create plugin for Fuel 6.0. If that it is
going to be overcomplicated - I suggested to produce fpb for every Fuel
release, and name it like fpb60, fpb61, fpb70, etc. Then it becomes easier
to support and maintain plugin builders for certain versions of Fuel.
Speaking about Fuel Client - there is no mistake. It's been discussed
dozens of times, it's just lack of resources to make it on PyPI as well as
to fix a few other things. I hope it could be done as part of efforts from
[2].

- Perhaps we have a separate settings tab just for Plug-Ins?    For some
> complex plug-ins, they might require a dedicated tab.   If we have too many
> tabs it could get messy.



> Shall we consider a separate place in UI (tab) for plugins? Settings tab
> seems to be overloaded.


This is certainly under planning and discussion for future releases. See
[1], for example. For 6.0, we agreed that we can just extend existing
Settings tab with plugins-related fields.

One minor thing from me, which I forgot to mention during the demo:
verbosity of fpb run. I understand it might sound like a bikeshedding now,
but I believe if we develop it right from the very beginning, then we can
save some time later. So I would suggest normal, short INFO output, and
verbose one with --debug.

Thanks for feedback folks!!!

[1]
https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg37196.html
[2]
https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg37001.html


---------- Forwarded message ----------
From: Nathan Trueblood <ntrueblood at mirantis.com>
Date: Sat, Oct 18, 2014 at 3:24 AM
Subject: Re: plugins

Agreed - I thought this initial PoC was great.

A few initial thoughts about settings in the UI and plug-in in general:

- Perhaps we have a separate settings tab just for Plug-Ins?    For some
complex plug-ins, they might require a dedicated tab.   If we have too many
tabs it could get messy.
- It seems like we should consider how we handle the VMWare settings in
light of plug-ins as well.   Since with VMWare we have a lot of setting to
configure and settings validation.
- Do we offer any kind of validation for settings on plug-ins?   Or some
way to for the developer to ensure that setting that cannot be default or
computed get requested for the plug-in?

- We need to think carefully about both the plug-in developer experience
(how hard to test, get error messages, etc) and the experience for the user
who deploys the plug-in into an environment.


-Nathan

On Fri, Oct 17, 2014 at 4:13 PM, Roman Alekseenkov <
ralekseenkov at mirantis.com> wrote:
>
>
> I watched both videos (creating a file with the text from UI && installing
> and starting a service).
>
> It looks pretty good!! Some initial feedback/questions:
>
>    1. I like the fact that fuel plugin builder appends version to the
>    name and makes it "fuel-awesome-plugin-1.2.3.tar". The approach is similar
>    to Java/Maven and is a good one.
>    2. I feel like we should not require user to unpack the plugin before
>    installing it. Moreover, we may chose to distribute plugins in our own
>    format, which we may potentially change later. E.g. "lbaas-v2.0.fp". I'd
>    rather stick with two actions:
>       - Assembly (externally): fpb --build <name>
>       - Installation (on master node): fuel --install-plugin <name>
>    3. How are we planning to distribute fuel plugin builder and its
>    updates? Ideally, it should be available externally (outside of master
>    node). I don't want us to repeat the same mistake as we did with Fuel
>    client, which doesn't seem to be usable as an external dependency.
>    4. How do we handle errors?
>       - What happens if an error occurs during plugin installation?
>       - What happens if an error occurs during plugin execution? Does it
>       (should it?) fail the deployment? Will we show user an error message with
>       the name of plugin that failed?
>       5. Shall we consider a separate place in UI (tab) for plugins?
>    Settings tab seems to be overloaded.
>    6. When are we planning to focus on the 2 plugins which were
>    identified as must-haves for 6.0? Cinder & LBaaS
>
> Once again, great job guys!
>
> Thanks,
> Roman
>
> On Fri, Oct 17, 2014 at 9:32 AM, Mike Scherbakov <mscherbakov at mirantis.com
> > wrote:
>
>> Thanks, Evgeny, excellent work!
>> Roman, I believe we are "green" with the feature. Watch yourself.
>>
>> Mike Scherbakov
>> #mihgen
>> On Oct 17, 2014 8:25 PM, "Evgeniy L" <eli at mirantis.com> wrote:
>>
>>> Hi guys, here are the videos from the demo
>>>
>>> Part 1
>>> https://drive.google.com/file/d/0B7I3b5vI7ZYXUGY1QVYyX3NLTWc/view
>>>
>>> Part 2
>>> https://drive.google.com/file/d/0B7I3b5vI7ZYXWkRmV05fT1VEQkk/view
>>>
>>> Thanks,
>>>
>>>
>

-- 
Mike Scherbakov
#mihgen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141019/a60938d7/attachment.html>