Open Stack

First of all, IMHO this approach is not a requirement.
Each project can choose their preferred way.

# Hopefully all dashboards are listed in the horizon plugin registry
if you have a dashboard support.
# https://docs.openstack.org/developer/horizon/install/plugin-registry.html

The following is my thought and reason I chose a separate project for
fwaas/vpnaas dashboards. We just follow what most horizon plugins do.

I believe translation support in the dashboard is one of
important aspects. As my hat of I18 team, our rough user survey shows us
that the dashboard is the area users need translations most.
The translation script in our infra supports only a separate project model
(I am one of the author of the current script) and at now we have no plan to
enhance it unless some new volunteer who wants to explore it.
In case of the FWaaS/VPNaaS dashboard, we already support translation now
and would like to keep it without exploring a new way.

I don't talk about testing much here. It is a straight forward topic.

Another point is from the deployment perspective.
Deployers might want not to install unnecessary things. Neutron and horizon may
deploy different servers and they may not install unrelated stuff.
It also affect distro packaging. Packages may need to create a separate package
from one source: one for neutron plugin and the other for horizon plugin.

This is my view I personally prefer to a separate repository.

Thanks,
Akihiro

2017-06-21 19:07 GMT+09:00 Thomas Morin <thomas.morin at orange.com>:
> Kevin Benton :
>> Some context here:
>> http://lists.openstack.org/pipermail/openstack-dev/2017-April/115200.html
>>
>
> Thanks, I had missed this one.
>
> So, what I gather is that the only drawback noted for "(b) dashboard code in
> individual project" is "Requires extra efforts to support neutron and
> horizon codes in a single repository for testing and translation supports.
> Each project needs to explore the way.".   While I won't disagree, my
> question would be the following: since we have something that works (except
> dashboard translation, which we haven't explored), should we move to the
> model agreed on for new work (given that there is also overhead in creating
> and maintaining a new repo) ?
>
> Best,
>
> -Thomas
>
>
> On Wed, Jun 21, 2017 at 2:33 AM, Thomas Morin <thomas.morin at orange.com>
> wrote:
>>
>> Hi Akihiro,
>>
>> While I understand the motivation to move these dashboards from
>> openstack/horizon, what is the reason to prefer a distinct repo for the
>> dashboard rather than hosting it in the main repo of these projects ?
>>
>> (networking-bgpvpn has had a dashboard for some time already, it is hosted
>> under networking-bgpvpn/bgpvpn_dashboard and we haven't heard about any
>> drawback)
>>
>> Thanks,
>>
>> -Thomas
>>
>>
>>
>> Akihiro Motoki :
>>
>> Hi neutron and horizon teams (especially fwaas and vpnaas folks),
>>
>> As we discussed so far, I prepared separate git repositories for FWaaS
>> and VPNaaS dashboards.
>> http://git.openstack.org/cgit/openstack/neutron-fwaas-dashboard/
>> http://git.openstack.org/cgit/openstack/neutron-vpnaas-dashboard/
>>
>> All new features will be implemented in the new repositories, for
>> example, FWaaS v2 support.
>> The initial core members consist of neutron-fwaas/vpnaas-core
>> (respectively) + horizon-core.
>>
>> There are several things to do to complete the split out.
>> I gathered a list of work items at the etherpad and we will track the
>> progress here.
>> https://etherpad.openstack.org/p/horizon-fwaas-vpnaas-splitout
>> If you are interested in helping the efforts, sign up on the etherpad
>> or contact me.
>>
>> I would like to release the initial release which is compatible with
>> the current horizon
>> FWaaS/VPNaaS dashboard (with no new features).
>> I hope we can release it around R-8 week (Jul 3) or R-7 (Jul 10).
>>
>> It also will be good examples for neutron stadium/related projects
>> which are interested in
>> adding dashboard support. AFAIK, networking-sfc, tap-as-a-service are
>> interested in it.
>>
>> Thanks,
>> Akihiro
>>
>> __________________________________________________________________________
>> 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
>
>
>
> __________________________________________________________________________
> 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
>