Open Stack

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:jaypipes at gmail.com]
> Sent: Tuesday, December 17, 2013 10:44 AM
> To: openstack-dev at 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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>