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 <fa...@plumgrid.com> wrote: > On Wed, Nov 25, 2015 at 12:06 PM, Armando M. <arma...@gmail.com> wrote: > >> >> >> On 24 November 2015 at 21:46, Akihiro Motoki <amot...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
