Re: [openstack-dev] [TripleO] [Horizon] [Tuskar] [UI] Horizon and Tuskar-UI merge
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). 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
Re: [openstack-dev] [TripleO] [Horizon] [Tuskar] [UI] Horizon and Tuskar-UI merge
On 17/12/13 09:04, Thomas Goirand wrote: On 12/16/2013 10:32 PM, Jaromir Coufal wrote: [snip] 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. 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. [snip] The thing is, as Jarda writes, that Tuskar is for managing a different cloud than the rest of the Horizon. With TripleO you have two clouds, one, called Undercloud, consists of real hardware and is managed by the datacenter administrators -- that is the one where Tuskar runs. The other, called Overcloud, is deployed on the Undercloud machines, and is the cloud that the users actually use. It's managed by normal Horizon. Those two instances of Horizon live on separate machines, in separate networks and have separate sets of users. I agree that in a general case your proposition would be much better, but in this case it doesn't really make sense to have the normal Horizon in Undercloud, and require the admins to specially configure the users to see Tuskar. Instead, a preconfigured installation of Horizon with Tuskar enabled seems much better. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Horizon] [Tuskar] [UI] Horizon and Tuskar-UI merge
On 12/17/2013 09:04 AM, Thomas Goirand wrote: 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). Also, it seems we have a consensus, when is it expected to happen? For Icehouse b2 maybe? Just my 2 cents, The issue is, that you can not do anything with it, when it's not configured. The other thing: When you're up to try it, you need quite a few machines (to install OpenStack on them) etc. Thus I think, disabled by default is the best way to not to confuse people, since you now need to know, what you're doing. We might/should rethink this decision in the future. The other suggestion (totally unrelated to Tuskar) you had was: to store config data in a database instead of a (python) config file. Currently, Horizon does not require a database, and I'd love to keep it that way. There are currently two configs to be changed once, when configuring the Dashboard: ALLOWED_HOSTS and OPENSTACK_HOST. The first is to configure the host to run on, the other points to keystone. This gets you up and running. We're inheriting config file handling from Django, and this consists on parsing python files. But, if you look at https://github.com/openstack/horizon/tree/master/openstack_dashboard/local/enabled you'll see a more .ini-file approach, probably more like you were thinking. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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
Re: [openstack-dev] [TripleO] [Horizon] [Tuskar] [UI] Horizon and Tuskar-UI merge
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
Re: [openstack-dev] [TripleO] [Horizon] [Tuskar] [UI] Horizon and Tuskar-UI merge
On 12/13/2013 03:08 PM, Ladislav Smola wrote: Horizoners, As discussed in TripleO and Horizon meetings, we are proposing to move Tuskar UI under the Horizon umbrella. Since we are building our UI solution on top of Horizon, we think this is a good fit. It will allow us to get feedback and reviews from the appropriate group of developers. I don't think, we really disagree here. My main concern would be more: what do we get, if we make up another project under the umbrella of horizon? I mean, what does that mean at all? My proposal would be, to send patches directly to horizon. As discussed in last weeks horizon meeting, tuskar UI would become integrated in Horizon, but disabled by default. This would enable a faster integration in Horizon and would reduce the overhead of creating a separate repositoy, installation instructions, packaging etc. etc. From the horizon side: we would get some new contributors (and hopefully reviewers), which is very much appreciated. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Horizon] [Tuskar] [UI] Horizon and Tuskar-UI merge
On 2013/16/12 14:03, Matthias Runge wrote: On 12/13/2013 03:08 PM, Ladislav Smola wrote: Horizoners, As discussed in TripleO and Horizon meetings, we are proposing to move Tuskar UI under the Horizon umbrella. Since we are building our UI solution on top of Horizon, we think this is a good fit. It will allow us to get feedback and reviews from the appropriate group of developers. I don't think, we really disagree here. My main concern would be more: what do we get, if we make up another project under the umbrella of horizon? I mean, what does that mean at all? My proposal would be, to send patches directly to horizon. As discussed in last weeks horizon meeting, tuskar UI would become integrated in Horizon, but disabled by default. This would enable a faster integration in Horizon and would reduce the overhead of creating a separate repositoy, installation instructions, packaging etc. etc. From the horizon side: we would get some new contributors (and hopefully reviewers), which is very much appreciated. Matthias 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Horizon] [Tuskar] [UI] Horizon and Tuskar-UI merge
On 12/16/2013 03:32 PM, Jaromir Coufal wrote: On 2013/16/12 14:03, Matthias Runge wrote: On 12/13/2013 03:08 PM, Ladislav Smola wrote: Horizoners, As discussed in TripleO and Horizon meetings, we are proposing to move Tuskar UI under the Horizon umbrella. Since we are building our UI solution on top of Horizon, we think this is a good fit. It will allow us to get feedback and reviews from the appropriate group of developers. I don't think, we really disagree here. My main concern would be more: what do we get, if we make up another project under the umbrella of horizon? I mean, what does that mean at all? My proposal would be, to send patches directly to horizon. As discussed in last weeks horizon meeting, tuskar UI would become integrated in Horizon, but disabled by default. This would enable a faster integration in Horizon and would reduce the overhead of creating a separate repositoy, installation instructions, packaging etc. etc. From the horizon side: we would get some new contributors (and hopefully reviewers), which is very much appreciated. Matthias 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Thanks for pointing this out, In Horizon you can easily decide which dashboards to show, so the Infrastructure management Horizon instance can have Project and Admin dashboards disabled. I think there has been discussed that some panels of Admin dashboard should be required for infrastructure management. We can solve this by adding those selected Admin panels also into Infrastructure dashboard. Jirka ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Horizon] [Tuskar] [UI] Horizon and Tuskar-UI merge
On 12/16/2013 04:22 PM, Jiri Tomasek wrote: Thanks for pointing this out, In Horizon you can easily decide which dashboards to show, so the Infrastructure management Horizon instance can have Project and Admin dashboards disabled. I think there has been discussed that some panels of Admin dashboard should be required for infrastructure management. We can solve this by adding those selected Admin panels also into Infrastructure dashboard. Jirka Oh, I would expect a new role for an infrastructure admin; that role shouldn't necessarily see running instances or tenants etc. at all. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] [Horizon] [Tuskar] [UI] Horizon and Tuskar-UI merge
Horizoners, As discussed in TripleO and Horizon meetings, we are proposing to move Tuskar UI under the Horizon umbrella. Since we are building our UI solution on top of Horizon, we think this is a good fit. It will allow us to get feedback and reviews from the appropriate group of developers. Tuskar UI is a user interface for the design, deployment, monitoring, and management of OpenStack. The code is built on the Horizon framework and facilitates the TripleO approach to deployment. We work closely with the TripleO team and will continue to do so. The Tuskar UI itself is implemented as a new tab, headed Infrastructure, which is added as a dashboard to OpenStack Horizon. For more information about the TripleO project, check out the project wiki: https://wiki.openstack.org/wiki/TripleO. The following is a proposal on how the Tuskar UI project could be integrated: - Create a new codebase for the Tuskar-UI under the horizon umbrella, with its own core team - As an exception to the usual contribution process, commits to Tuskar-UI codebase. may be pushed, +2 and approved by one company. This is intended to make the development process faster. We are currently developing the Tuskar-UI at a fast pace and there are not yet many contributors who aren't employed by Red Hat that are familiar with the code. As the code stabilises, and attracts users and developers, this exception can be removed. - The Tuskar-UI cores would be cores of Tuskar-UI codebase only. Horizon cores would be cores of the whole Horizon program. What does it mean for Horizon? - There will be more developers, reviewers and patches coming to Horizon (as a program). - Horizon contributors will have time to get familiar with the Tuskar-UI code, before we decide to merge it into the Horizon codebase. If you have any questions, please ask! Thanks, Tuskar UI team ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
