Open Stack

On Wed, Dec 23, 2015 at 9:16 PM, Akihiro Motoki <amotoki at 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 <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
>
> __________________________________________________________________________
> 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/20151223/9e3a9b2d/attachment.html>