<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Dec 23, 2015 at 9:16 PM, Akihiro Motoki <span dir="ltr"><<a href="mailto:amotoki@gmail.com" target="_blank">amotoki@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Are there no comment after I added more detail?<br>
No inputs from both horizon and neutron side.....<br>
<br>
Although Horizon team is tackling to address some problems around<br>
horizon plugin mechanism<br>
such as translations, I think option (c) requires neutron subprojects<br>
to do some extra efforts<br>
around infra scripts. They are specific to neutron subproject<br>
directory structure and neutron<br>
subprojects should be responsible to deal with them as option (c) is a<br>
choice of neutron side.<br>
please check the details of my previous post.<br>
<br>
I am not sure it is okay to neutron suboprojects?<br></blockquote><div>I think option (c) would work fine. My vote would be to go with it. Would</div><div>be best if someone could capture a devref around this similar to what</div><div>HenryG did around DB and alembic for subprojects.  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Akihiro<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
2015-12-02 17:23 GMT+09:00 Akihiro Motoki <<a href="mailto:amotoki@gmail.com">amotoki@gmail.com</a>>:<br>
> Thanks all.<br>
> All comments so far are from neutron side. I would like to wait inputs<br>
> from horizon side, especially David.<br>
><br>
> Option (c) is what we do in neutron sub-projects under neutron stadium model and<br>
> I agree it makes sense and sounds natural to neutron folks.<br>
><br>
> My initial mail just did not cover technical points or horizon<br>
> developer perspective<br>
> if we go to option (c). Let me share them.<br>
><br>
> [Horizon developer perspective]<br>
><br>
> I think we need some collaboration points between neutron subprojects<br>
> and horizon team (+ UX team).<br>
> to share knowledge or conventions in the dashboard development.<br>
> Not so many neutron developers are aware of horizon side changes, so I<br>
> think Horizon side<br>
> needs to care of these repositories to some extent for better UX<br>
> consistency or framework changes.<br>
><br>
> We are going to the self-management models in individual repos, so I believe<br>
> each team watches horizon side changes to some extent, and keep their<br>
> dashboard up-to-date.<br>
><br>
> From Horizon point of view, it seems good to me if the following are done:<br>
><br>
> - Use a consistent directory name for a dashboard support in each<br>
> repository (e.g., "dashboard")<br>
>   Gerrit support filename based query, so it allows horizon developers<br>
> can reach dashboard related reviews.<br>
> - Keep up-to-date Horizon plugin registry<br>
> <a href="http://docs.openstack.org/developer/horizon/plugins.html" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/horizon/plugins.html</a><br>
> - Use horizon plugin model rather than adhoc approach<br>
> - Documentation on config options (at now, horizon does not support<br>
> oslo.config generator)<br>
><br>
> [Technical topics]<br>
><br>
> - We need to have two testing setup for both neutron and horizon.<br>
>   I think most dashboard tests depend on Horizon (or at least Django)<br>
><br>
> - Does (test-)requirements.txt contain neutron and horizon dependencies?<br>
>   For horizon itself, perhaps no. Our test tool chains should install horizon<br>
>   as we do for neutron dependency.<br>
>   For other requirements, I am not sure at this moment.<br>
><br>
> - Separate translation support for dashboard and server code.<br>
>   Django and oslo.i18n (python gettext) use different approach to find<br>
> translation catalog,<br>
>   so we need to prepare a separate tool chain for both translation catalog.<br>
>   It requires the infra script change.<br>
><br>
>   # Normal Horizon plugin translation support is an ongoing effort,<br>
>   # but option (c) needs extra effort.<br>
><br>
> [Packaging perspective]<br>
><br>
> I am not sure how it affects.<br>
> There is one concern as a package consumer.<br>
><br>
>> Getting additional packages through distro channels can be surprisingly difficult for new packages. :/<br>
><br>
> How neutron team can answer to this?<br>
> I think it is not specific to neutron subproject dashboard discussion.<br>
> Neutron stadium mode already has this problem.<br>
> Input from packaging side would be appreciated.<br>
><br>
> Thanks,<br>
> Akihiro<br>
><br>
> 2015-11-25 14:46 GMT+09:00 Akihiro Motoki <<a href="mailto:amotoki@gmail.com">amotoki@gmail.com</a>>:<br>
>> Hi,<br>
>><br>
>> Neutron has now various subprojects and some of them would like to<br>
>> implement Horizon supports. Most of them are additional features.<br>
>> I would like to start the discussion where we should have horizon support.<br>
>><br>
>> [Background]<br>
>> Horizon team introduced a plugin mechanism and we can add horizon panels<br>
>> from external repositories. Horizon team is recommending external repos for<br>
>> additional services for faster iteration and features.<br>
>> We have various horizon related repositories now [1].<br>
>><br>
>> In Neutron related world, we have neutron-lbaas-dashboard and<br>
>> horizon-cisco-ui repos.<br>
>><br>
>> [Possible options]<br>
>> There are several possible options for neutron sub-projects.<br>
>> My current vote is (b), and the next is (a). It looks a good balance to me.<br>
>> I would like to gather broader opinions,<br>
>><br>
>> (a) horizon in-tree repo<br>
>> - [+] It was a legacy approach and there is no initial effort to setup a repo.<br>
>> - [+] Easy to share code conventions.<br>
>> - [-] it does not scale. Horizon team can be a bottleneck.<br>
>><br>
>> (b) a single dashboard repo for all neutron sub-projects<br>
>> - [+] No need to set up a repo by each sub-project<br>
>> - [+] Easier to share the code convention. Can get horizon reviewers.<br>
>> - [-] who will be a core reviewer of this repo?<br>
>><br>
>> (c) neutron sub-project repo<br>
>> - [+] Each sub-project can develop a dashboard fast.<br>
>> - [-] It is doable, but the directory tree can be complicated.<br>
>> - [-] Lead to too many repos and the horizon team/liaison cannot cover all.<br>
>><br>
>> (d) a separate repo per neutron sub-project<br>
>> Similar to (c)<br>
>> - [+] A dedicate repo for dashboard simplifies the directory tree.<br>
>> - [-] Need to setup a separate repo.<br>
>> - [-] Lead to too many repos and the horizon team/liaison cannot cover all.<br>
>><br>
>><br>
>> Note that this mail is not intended to move the current neutron<br>
>> support in horizon<br>
>> to outside of horizon tree. I would like to discuss Horizon support of<br>
>> additional features.<br>
>><br>
>> Akihiro<br>
>><br>
>> [1] <a href="http://docs.openstack.org/developer/horizon/plugins.html" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/horizon/plugins.html</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>