Open Stack

Excerpts from Akihiro Motoki's message of 2017-04-11 00:09:10 +0900:
> Hi neutrinos (and horizoners),
> 
> As the title says, where would we like to have horizon dashboard for
> neutron stadium projects?
> There are several projects under neutron stadium and they are trying
> to add dashboard support.
> 
> I would like to raise this topic again. No dashboard support lands since then.
> Also Horizon team would like to move in-tree neutron stadium dashboard
> (VPNaaS and FWaaS v1 dashboard) to outside of horizon repo.
> 
> Possible approaches
> ----------------------------
> 
> Several possible options in my mind:
> (a) dashboard repository per project
> (b) dashboard code in individual project
> (c) a single dashboard repository for all neutron stadium projects
> 
> Which one sounds better?
> 
> Pros and Cons
> --------------------
> 
> (a) dashboard repository per project
>   example, networking-sfc-dashboard repository for networking-sfc
>   Pros
>    - Can use existing horizon related project convention and knowledge
>      (directory structure, testing, translation support)
>    - Not related to the neutron stadium inclusion. Each project can
> provide its dashboard
>      support regardless of neutron stadium inclusion.
>  Cons
>    - An additional repository is needed.
> 
> (b) dashboard code in individual project
>   example, dashboard module for networking-sfc
>   Pros:
>    - No additional repository
>    - Not related to the neutron stadium inclusion. Each project can
> provide its dashboard
>      support regardless of neutron stadium inclusion.
>  Cons:
>    - 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.
> 
> (c) a single dashboard repository for all neutron stadium projects
>    (something like neutron-advanced-dashboard)
>   Pros:
>     - No additional repository per project
>       Each project do not need a basic setup for dashboard and
> possible makes things simple.
>   Cons:
>     - Inclusion criteria depending on the neutron stadium inclusion/exclusion
>       (Similar discussion happens as for neutronclient OSC plugin)
>       Project before neutron stadium inclusion may need another implementation.
> 
> 
> My vote is (a) or (c) (to avoid mixing neutron and dashboard codes in a repo).
> 
> Note that as dashboard supports for feature in the main neutron repository
> are implemented in the horizon repository as we discussed several months ago.
> As an example, trunk support is being development in the horizon repo.
> 
> Thanks,
> Akihiro
> 

>From the release team's perspective, we would prefer (a), because
having one deliverable per package simplifies packaging and makes
more sense for deployments (no one would end up with dashboard
panels for features not supported by the backend).

Doug