Open Stack

I like the idea of doing a Horizon plugin, similar to a devstack plugin...
So choice (c) is my preference, given my current understanding. May be good
to try it on one subproject and see how it works out. Would give a concrete
example to discuss.

Regards,

Paul Michali (pc_m)

On Wed, Nov 25, 2015 at 2:13 AM Fawad Khaliq <fawad at plumgrid.com> wrote:

> On Wed, Nov 25, 2015 at 12:06 PM, Armando M. <armamig at gmail.com> wrote:
>
>>
>>
>> On 24 November 2015 at 21:46, Akihiro Motoki <amotoki at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Neutron has now various subprojects and some of them would like to
>>> implement Horizon supports. Most of them are additional features.
>>> I would like to start the discussion where we should have horizon
>>> support.
>>>
>>> [Background]
>>> Horizon team introduced a plugin mechanism and we can add horizon panels
>>> from external repositories. Horizon team is recommending external repos
>>> for
>>> additional services for faster iteration and features.
>>> We have various horizon related repositories now [1].
>>>
>>> In Neutron related world, we have neutron-lbaas-dashboard and
>>> horizon-cisco-ui repos.
>>>
>>> [Possible options]
>>> There are several possible options for neutron sub-projects.
>>> My current vote is (b), and the next is (a). It looks a good balance to
>>> me.
>>> I would like to gather broader opinions,
>>>
>>> (a) horizon in-tree repo
>>> - [+] It was a legacy approach and there is no initial effort to setup a
>>> repo.
>>> - [+] Easy to share code conventions.
>>> - [-] it does not scale. Horizon team can be a bottleneck.
>>>
>>> (b) a single dashboard repo for all neutron sub-projects
>>> - [+] No need to set up a repo by each sub-project
>>> - [+] Easier to share the code convention. Can get horizon reviewers.
>>> - [-] who will be a core reviewer of this repo?
>>>
>>> (c) neutron sub-project repo
>>>
>>
>> All circumstances considered, I think c) is the only viable one.
>>
> +1
>
>>
>>
>>> - [+] Each sub-project can develop a dashboard fast.
>>> - [-] It is doable, but the directory tree can be complicated.
>>>
>>
>> why? do you envision something else other than /horizon directory in the
>> tree?
>>
>>
>>> - [-] Lead to too many repos and the horizon team/liaison cannot cover
>>> all.
>>>
>>
>> If that's true for horizon, shouldn't the same be true for the neutron
>> team :)? IMO, the level of feedback/oversight provided is always going to
>> be constant (you can't clone people) no matter how the efforts are
>> distributed. I'd rather empower the individual projects.
>>
> Agree. +1
>
>>
>>
>>>
>>> (d) a separate repo per neutron sub-project
>>> Similar to (c)
>>> - [+] A dedicate repo for dashboard simplifies the directory tree.
>>> - [-] Need to setup a separate repo.
>>> - [-] Lead to too many repos and the horizon team/liaison cannot cover
>>> all.
>>>
>>
>>> Note that this mail is not intended to move the current neutron
>>> support in horizon
>>> to outside of horizon tree. I would like to discuss Horizon support of
>>> additional features.
>>>
>>> Akihiro
>>>
>>> [1] http://docs.openstack.org/developer/horizon/plugins.html
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151125/30c2c95c/attachment.html>