Open Stack

Are there no comment after I added more detail?
No inputs from both horizon and neutron side.....

Although Horizon team is tackling to address some problems around
horizon plugin mechanism
such as translations, I think option (c) requires neutron subprojects
to do some extra efforts
around infra scripts. They are specific to neutron subproject
directory structure and neutron
subprojects should be responsible to deal with them as option (c) is a
choice of neutron side.
please check the details of my previous post.

I am not sure it is okay to neutron suboprojects?

Akihiro


2015-12-02 17:23 GMT+09:00 Akihiro Motoki <amotoki at gmail.com>:
> Thanks all.
> All comments so far are from neutron side. I would like to wait inputs
> from horizon side, especially David.
>
> Option (c) is what we do in neutron sub-projects under neutron stadium model and
> I agree it makes sense and sounds natural to neutron folks.
>
> My initial mail just did not cover technical points or horizon
> developer perspective
> if we go to option (c). Let me share them.
>
> [Horizon developer perspective]
>
> I think we need some collaboration points between neutron subprojects
> and horizon team (+ UX team).
> to share knowledge or conventions in the dashboard development.
> Not so many neutron developers are aware of horizon side changes, so I
> think Horizon side
> needs to care of these repositories to some extent for better UX
> consistency or framework changes.
>
> We are going to the self-management models in individual repos, so I believe
> each team watches horizon side changes to some extent, and keep their
> dashboard up-to-date.
>
> From Horizon point of view, it seems good to me if the following are done:
>
> - Use a consistent directory name for a dashboard support in each
> repository (e.g., "dashboard")
>   Gerrit support filename based query, so it allows horizon developers
> can reach dashboard related reviews.
> - Keep up-to-date Horizon plugin registry
> http://docs.openstack.org/developer/horizon/plugins.html
> - Use horizon plugin model rather than adhoc approach
> - Documentation on config options (at now, horizon does not support
> oslo.config generator)
>
> [Technical topics]
>
> - We need to have two testing setup for both neutron and horizon.
>   I think most dashboard tests depend on Horizon (or at least Django)
>
> - Does (test-)requirements.txt contain neutron and horizon dependencies?
>   For horizon itself, perhaps no. Our test tool chains should install horizon
>   as we do for neutron dependency.
>   For other requirements, I am not sure at this moment.
>
> - Separate translation support for dashboard and server code.
>   Django and oslo.i18n (python gettext) use different approach to find
> translation catalog,
>   so we need to prepare a separate tool chain for both translation catalog.
>   It requires the infra script change.
>
>   # Normal Horizon plugin translation support is an ongoing effort,
>   # but option (c) needs extra effort.
>
> [Packaging perspective]
>
> I am not sure how it affects.
> There is one concern as a package consumer.
>
>> Getting additional packages through distro channels can be surprisingly difficult for new packages. :/
>
> How neutron team can answer to this?
> I think it is not specific to neutron subproject dashboard discussion.
> Neutron stadium mode already has this problem.
> Input from packaging side would be appreciated.
>
> Thanks,
> Akihiro
>
> 2015-11-25 14:46 GMT+09:00 Akihiro Motoki <amotoki at gmail.com>:
>> 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
>> - [+] Each sub-project can develop a dashboard fast.
>> - [-] It is doable, but the directory tree can be complicated.
>> - [-] Lead to too many repos and the horizon team/liaison cannot cover all.
>>
>> (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