The simplest solution is already built into the Horizon framework. Any panel or dashboard can be disabled by a check to determine if a service is available in the service catalog. Since there is an inherent above/under cloud separation here, the Tuskar service should not be available above cloud. Additionally, the same permission mechanism can trigger off roles, also in the service catalog. I see this as a simple implementation detail.
David > -----Original Message----- > From: Jay Pipes [mailto:jaypi...@gmail.com] > Sent: Tuesday, December 17, 2013 10:44 AM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [TripleO] [Horizon] [Tuskar] [UI] Horizon and > Tuskar-UI merge > > On 12/17/2013 03:04 AM, Thomas Goirand wrote: > > On 12/16/2013 10:32 PM, Jaromir Coufal wrote: > >> > >> This is important note. From information architecture and user > >> interaction point of view, I don't think it makes sense to keep all the > >> three tabs visible together (Project, Admin, Infrastructure). There are > >> lot of reasons, but main points: > >> > >> * Infrastructure itself is undercloud concept running in different > >> instance of Horizon. > >> > >> * Users dealing with deployment and infrastructure management are not > >> the users of OpenStack UI / Dashboard. It is different set of users. So > >> it doesn't make sense to have giant application, which provides each and > >> every possible feature. I think we need to keep focused. > >> > >> So by default, I would say that there should exist Project + Admin tab > >> together or Infrastructure. But never all three together. So when > >> Matthias say 'disabled by default', I would mean completely hidden for > >> user and if user wants to use Infrastructure management, he can enable > >> it in different horizon instance, but it will be the only visible tab > >> for him. So it will be sort of separate application, but still running > >> on top of Horizon. > >> > >> -- Jarda > > > > I think the "disabled by default" approach is the wrong one. Instead, we > > should have some users with enough credentials that will have the > > feature, and others will not. > > > > Also, Horizon is a web interface. Most of its switches could be made > > directly in the web interface, with the values stored in a db. That'd be > > so much nicer than stored in localsettings.py which starts, as time > > passes, to become overly complicated and ugly (it should, by the way, be > > a configuration file, not a python script: you can't expect > > administrators to understand python, but you do expect them to > > understand how to write in a .ini file). > > Welcome to Django. This isn't going to change any time soon :) > > Best, > -jay > > > Also, it seems we have a consensus, when is it expected to happen? For > > Icehouse b2 maybe? > > > > Just my 2 cents, > > > > Thomas > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
