Open Stack

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 <kevin at benton.pub>:

> 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)" <rcresswe at cisco.com>
> 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 <r1chardj0n3s at gmail.com> 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 <kevin at benton.pub> 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" <bence.romsics at gmail.com> 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: OpenStack-dev-request at lists.op
> enstack.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.op
> enstack.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.op
> enstack.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/20170206/65cfef85/attachment.html>