On Wed, Dec 23, 2015 at 9:16 PM, Akihiro Motoki <amot...@gmail.com> wrote:
> 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? > I think option (c) would work fine. My vote would be to go with it. Would be best if someone could capture a devref around this similar to what HenryG did around DB and alembic for subprojects. > > Akihiro > > > 2015-12-02 17:23 GMT+09:00 Akihiro Motoki <amot...@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 <amot...@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 > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev