On 04/17/2014 03:06 PM, Chad Roberts 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)
hopefully (1) can be altered after a merge based on ux evaluation, so i'd say go w/ the most consistent approach to start (b).
best, matt _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
