I have the same opinion as Kevin, UI support for a feature in the neutron repo should be in the main horizon repo.
I believe this improves usability too. If I have a neutron deployment (it is a typical deployment now), I would like to use neutron feature support only after installing the main horizon (though there are several feature gaps). Akihiro 2017-02-06 19:50 GMT+09:00 Kevin Benton <[email protected]>: > Well the UIs for the extensions inside the main Neutron repo are in the > main horizon repo so far (e.g. routers, floating IPs, security groups, > etc). LBaaS is a separate repo with separate devs so it makes sense to me > that it would have its own UI repo. > > Trunks would be the the first extension that lives in the Neutron tree > that would have its own UI repo living somewhere else. I don't see how we > could avoid bitrot (or find UI contributors in the first place) if every > upstream feature will be expected to have its own UI repo, core team, bug > tracker, and release management. That will be a huge overhead to adding > support for new neutron features. > > > On Feb 6, 2017 03:36, "Rob Cresswell (rcresswe)" <[email protected]> > wrote: > > Core Neutron features should be within Horizon, with extensions outside. > This is a little hazy since even the default behaviour in Neutron is still > a plugin, but thats the general idea. There are already some features > outside, like the lbaas dashboard. Personally, I’d keep them in their own > repo; makes it much easier to manage scope. It’d be a huge pain if one > extensions UI holds up others at release time due to broken tests etc. > > Rob > > > On 6 Feb 2017, at 07:02, Richard Jones <[email protected]> wrote: > > > > That idea has merit, though I don't know what the scope for such a > > 'neutron-ui' might be. I'm definitely supportive of the Neutron Trunks > > UI efforts, but it'd be good to get an answer on this scope question > > before rolling along and creating the project. > > > > > > Richard > > > > On 6 February 2017 at 12:14, Kevin Benton <[email protected]> wrote: > >> If the horizon team would like neutron features to live outside, I > wonder if > >> it would make more sense to create a new 'neutron-ui' repo instead of it > >> being trunk specific. That way we don't have to come up with a new repo > for > >> every new feature that needs a horizon UI. > >> > >> On Feb 3, 2017 09:26, "Bence Romsics" <[email protected]> wrote: > >>> > >>> Hi All, > >>> > >>> I'd like to add support for Neutron Trunks [1][2] into Horizon > >>> together with a few colleagues in the Pike cycle. We thought of > >>> writing a new Horizon plugin [3] for that purpose. That way I hope to > >>> keep it optional for deployment and minimize the maintenance cost for > >>> the Horizon core team. Of course we'd welcome all review feedback, > >>> especially from the Horizon and Neutron teams. > >>> > >>> To host the work I'd like create a new project: > openstack/neutron-trunk-ui > >>> > >>> Following the Project Creator's Guide, here's a proposed new project > >>> config: > >>> > >>> https://review.openstack.org/428730 > >>> > >>> And the corresponding governance change: > >>> > >>> https://review.openstack.org/428796 > >>> > >>> Please review them and if you agree approve. Or guide me to a better > >>> change. > >>> > >>> Thanks in advance, > >>> Bence Romsics > >>> > >>> [1] > >>> https://github.com/openstack/openstack-manuals/blob/master/d > oc/networking-guide/source/config-trunking.rst > >>> [2] https://wiki.openstack.org/wiki/Neutron/TrunkPort > >>> [3] http://docs.openstack.org/developer/horizon/tutorials/plugin.html > >>> > >>> ____________________________________________________________ > ______________ > >>> OpenStack Development Mailing List (not for usage questions) > >>> Unsubscribe: [email protected] > enstack.org?subject:unsubscribe > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> ____________________________________________________________ > ______________ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: [email protected] > enstack.org?subject:unsubscribe > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > > > ____________________________________________________________ > ______________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: [email protected] > enstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
