Open Stack

Hi,

As for the questions:

1. I’d say there is no reason to keep a separate dashboard along with Project and Admin, so the panels should go under the “Data processing” panel group in the Project dashboard. Projects like Trove and Heat have already done that.

2. c) looks like the most reasonable way.

Also It’s important that our panels should be available only if sahara service is running and registered in the catalog. The common practice I guess is adding special files to openstack_dashboard/enabled (or openstack_dashboard/local/enabled) directory. So there is no more need to modify horizon’s config files to enable the dashboard.

Best Regards,
Nikita Konovalov
Mirantis, Inc

On Apr 17, 2014, at 23:06 , Chad Roberts <croberts at redhat.com> wrote:

> Per blueprint  https://blueprints.launchpad.net/horizon/+spec/merge-sahara-dashboard we are merging the Sahara Dashboard UI code into the Horizon code base.
> 
> Over the last week, I have been working on making this merge happen and along the way some interesting questions have come up.  Hopefully, together we can make the best possible decisions.
> 
> Sahara is the Data Processing platform for Openstack.  During incubation and prior to that, a horizon dashboard plugin was developed to work with the data processing api.  Our original implementation was a separate dashboard that we would activate by adding to HORIZON_CONFIG and INSTALLED_APPS.  The layout gave us a root of "Sahara" on the same level as Admin and Project.  Under Sahara, we have 9 panels that make-up the entirety of the functionality for the Sahara dashboard.
> 
> Over the past week there seems to be at least 2 questions that have come up.  I'd like to get input from anyone interested.  
> 
> 1)  Where should the functionality live within the Horizon UI? So far, 2 options have been presented.
>    a)  In a separate dashboard (same level as Admin and Project).  This is what we had in the past, but it doesn't seem to fit the flow of Horizon very well.  I had a review up for this method at one point, but it was shot down, so it is currently abandoned.
>    b)  In a panel group under Project.  This is what I have stared work on recently. This seems to mimic the way other things have been integrated, but more than one person has disagreed with this approach.
>    c)  Any other options?
> 
> 
> 2)  Where should the code actually reside?
>    a)  Under openstack_dashboards/dashboards/sahara  (or data_processing).  This was the initial approach when the target was a separate dashboard.
>    b)  Have all 9 panels reside in openstack_dashboards/dashboards/project.  To me, this is likely to eventually make a mess of /project if more and more things are integrated there.
>    c)  Place all 9 data_processing panels under openstack_dashboards/dashboards/project/data_processing  This essentially groups the code by panel group and might make for a bit less mess.
>    d)  Somewhere else?
> 
> 
> The current plan is to discuss this at the next Horizon weekly meeting, but even if you can't be there, please do add your thoughts to this thread.
> 
> Thanks,
> Chad Roberts (crobertsrh on irc)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140418/8474d276/attachment.html>