[openstack-dev] [Horizon][Neutron] dashboard repository for neutron subprojects

Brandon Logan brandon.logan at RACKSPACE.COM
Wed Nov 25 17:33:22 UTC 2015



Sent from Nine<http://www.9folders.com/>

From: Kyle Mestery <mestery at mestery.com>
Sent: Nov 25, 2015 8:18 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Horizon][Neutron] dashboard repository for neutron subprojects

On Wed, Nov 25, 2015 at 1:06 AM, Armando M. <armamig at gmail.com<mailto:armamig at gmail.com>> wrote:


On 24 November 2015 at 21:46, Akihiro Motoki <amotoki at gmail.com<mailto: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.

+1000

Option C seems like the way forward here.


(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://OpenStack-dev-request@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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 I have to agree with C) as well.  I do worry about the scope of the projects becoming way too large though.  If this continues these projects are going to need to have people that are SMEs in all things OR implement something like the Lt system main neutron has right now.  I'm OK crossing that bridge when we get to it though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151125/cbc16621/attachment.html>


More information about the OpenStack-dev mailing list