Re: [openstack-dev] [Horizon][Tuskar-UI] Location for common dashboard code?
Hiya, That makes sense. Just to take a concrete example - in tuskar-ui, our flavors' table code (https://github.com/openstack/tuskar-ui/blob/master/tuskar_ui/infrastructure/flavors/tables.py) uses the following code from openstack_dashboard.dashboards.admin.flavors.tables (https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/admin/flavors/tables.py): 1) extends CreateFlavor LinkAction to modify the linked url 2) extends DeleteFlavor DeleteAction to add an 'allowed' check 3) uses FlavorFilterAction FilterAction 4) uses get_size and get_disk_size methods for formatting a column value Would it be suggested that all of the above from the admin dashboard go into openstack_dashboard/common? I could see arguments for tuskar-ui not to extend 1) and simply create a new LinkAction since we're using an entirely new url. 4) seems to me that it might possibly belong in the api code. So would we just take 2) and 3) and stick it in openstack_dashboard/common/flavors/tables.py or something. . . ? Thanks, Tzu-Mainn Chen - Original Message - > I think this falls inline with other items we are working toward in > Horizon, namely more pluggable components on panels. > > I think creating a directory in openstack_dashboard for these reusable > components makes a lot of sense. And usage should eventually moved to > there. > I would suggest something as mundane as ³openstack_dashboard/common². > > David > > On 5/28/14, 10:36 AM, "Tzu-Mainn Chen" wrote: > > >Heya, > > > >Tuskar-UI is currently extending classes directly from > >openstack-dashboard. For example, right now > >our UI for Flavors extends classes in both > >openstack_dashboard.dashboards.admin.flavors.tables and > >openstack_dashboard.dashboards.admin.flavors.workflows. In the future, > >this sort of pattern will > >increase; we anticipate doing similar things with Heat code in > >openstack-dashboard. > > > >However, since tuskar-ui is intended to be a separate dashboard that has > >the potential to live > >away from openstack-dashboard, it does feel odd to directly extend > >openstack-dashboard dashboard > >components. Is there a separate place where such code might live? > >Something similar in concept > >to > >https://github.com/openstack/horizon/tree/master/openstack_dashboard/usage > > ? > > > > > >Thanks, > >Tzu-Mainn Chen > > > >___ > >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 > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon][Tuskar-UI] Location for common dashboard code?
We are in the process of removing the redundancy between Project and Admin by using RBAC to allow sharing of one code base for multiple roles. This is a WIP. David On 5/28/14, 1:53 PM, "Tzu-Mainn Chen" wrote: >Hi Doug, > >Thanks for the response! I agree with you in the cases where we are >extending >things like panels; if you're extending those, you're extending the >dashboard >itself. However, things such as workflows feel like they could >reasonably live >independently of the dashboard for re-use elsewhere. > >Incidentally, I know that within openstack_dashboard there are cases >where, say, >the admin dashboard extends instances tables from the project dashboard. >That >feels a bit odd to me; wouldn't it be cleaner to have both dashboards >extend >some common instances table that lives independently of either dashboard? > >Thanks, >Tzu-Mainn Chen > >- Original Message - >> Hey Tzu-Mainn, >> >> I've actually discouraged people from doing this sort of thing when >> customizing Horizon. IMO it's risky to extend those panels because they >> really aren't intended as extension points. We intend Horizon to be >> extensible by adding additional panels or dashboards. I know you are >> closely involved in Horizon development, so you are better able to >>manage >> that better than most customizers. >> >> Still, I wonder if we can better address this for Tuskar-UI as well as >> other situations by defining extensibility points in the dashboard >>panels >> and workflows themselves. Like well defined ways to add/show a column >>of >> data, add/hide row actions, add/skip a workflow step, override text >> elements, etc. Is it viable to create a few well defined extension >>points >> and meet your need to modify existing dashboard panels? >> >> In any case, it seems to me that if you are overriding the dashboard >> panels, it's reasonable that tuskar-ui should be dependent on the >> dashboard. >> >> Doug Fish >> >> >> >> >> >> From:Tzu-Mainn Chen >> To: "OpenStack Development Mailing List (not for usage questions)" >> , >> Date:05/28/2014 11:40 AM >> Subject: [openstack-dev] [Horizon][Tuskar-UI] Location for common >> dashboardcode? >> >> >> >> Heya, >> >> Tuskar-UI is currently extending classes directly from >>openstack-dashboard. >> For example, right now >> our UI for Flavors extends classes in both >> openstack_dashboard.dashboards.admin.flavors.tables and >> openstack_dashboard.dashboards.admin.flavors.workflows. In the future, >> this sort of pattern will >> increase; we anticipate doing similar things with Heat code in >> openstack-dashboard. >> >> However, since tuskar-ui is intended to be a separate dashboard that has >> the potential to live >> away from openstack-dashboard, it does feel odd to directly extend >> openstack-dashboard dashboard >> components. Is there a separate place where such code might live? >> Something similar in concept >> to >> >>https://github.com/openstack/horizon/tree/master/openstack_dashboard/usag >>e >> ? >> >> >> Thanks, >> Tzu-Mainn Chen >> >> ___ >> 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 >> > >___ >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] [Horizon][Tuskar-UI] Location for common dashboard code?
I think this falls inline with other items we are working toward in Horizon, namely more pluggable components on panels. I think creating a directory in openstack_dashboard for these reusable components makes a lot of sense. And usage should eventually moved to there. I would suggest something as mundane as ³openstack_dashboard/common². David On 5/28/14, 10:36 AM, "Tzu-Mainn Chen" wrote: >Heya, > >Tuskar-UI is currently extending classes directly from >openstack-dashboard. For example, right now >our UI for Flavors extends classes in both >openstack_dashboard.dashboards.admin.flavors.tables and >openstack_dashboard.dashboards.admin.flavors.workflows. In the future, >this sort of pattern will >increase; we anticipate doing similar things with Heat code in >openstack-dashboard. > >However, since tuskar-ui is intended to be a separate dashboard that has >the potential to live >away from openstack-dashboard, it does feel odd to directly extend >openstack-dashboard dashboard >components. Is there a separate place where such code might live? >Something similar in concept >to >https://github.com/openstack/horizon/tree/master/openstack_dashboard/usage > ? > > >Thanks, >Tzu-Mainn Chen > >___ >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] [Horizon][Tuskar-UI] Location for common dashboard code?
Hmm yes. Maybe the common base instances table could even be part of the extensible stuff in Horizon Sent from my iPhone > On May 28, 2014, at 2:53 PM, Tzu-Mainn Chen wrote: > > Hi Doug, > > Thanks for the response! I agree with you in the cases where we are extending > things like panels; if you're extending those, you're extending the dashboard > itself. However, things such as workflows feel like they could reasonably > live > independently of the dashboard for re-use elsewhere. > > Incidentally, I know that within openstack_dashboard there are cases where, > say, > the admin dashboard extends instances tables from the project dashboard. That > feels a bit odd to me; wouldn't it be cleaner to have both dashboards extend > some common instances table that lives independently of either dashboard? > > Thanks, > Tzu-Mainn Chen > > - Original Message - >> Hey Tzu-Mainn, >> >> I've actually discouraged people from doing this sort of thing when >> customizing Horizon. IMO it's risky to extend those panels because they >> really aren't intended as extension points. We intend Horizon to be >> extensible by adding additional panels or dashboards. I know you are >> closely involved in Horizon development, so you are better able to manage >> that better than most customizers. >> >> Still, I wonder if we can better address this for Tuskar-UI as well as >> other situations by defining extensibility points in the dashboard panels >> and workflows themselves. Like well defined ways to add/show a column of >> data, add/hide row actions, add/skip a workflow step, override text >> elements, etc. Is it viable to create a few well defined extension points >> and meet your need to modify existing dashboard panels? >> >> In any case, it seems to me that if you are overriding the dashboard >> panels, it's reasonable that tuskar-ui should be dependent on the >> dashboard. >> >> Doug Fish >> >> >> >> >> >> From:Tzu-Mainn Chen >> To:"OpenStack Development Mailing List (not for usage questions)" >>, >> Date:05/28/2014 11:40 AM >> Subject:[openstack-dev] [Horizon][Tuskar-UI] Location for common >>dashboardcode? >> >> >> >> Heya, >> >> Tuskar-UI is currently extending classes directly from openstack-dashboard. >> For example, right now >> our UI for Flavors extends classes in both >> openstack_dashboard.dashboards.admin.flavors.tables and >> openstack_dashboard.dashboards.admin.flavors.workflows. In the future, >> this sort of pattern will >> increase; we anticipate doing similar things with Heat code in >> openstack-dashboard. >> >> However, since tuskar-ui is intended to be a separate dashboard that has >> the potential to live >> away from openstack-dashboard, it does feel odd to directly extend >> openstack-dashboard dashboard >> components. Is there a separate place where such code might live? >> Something similar in concept >> to >> https://github.com/openstack/horizon/tree/master/openstack_dashboard/usage >> ? >> >> >> Thanks, >> Tzu-Mainn Chen >> >> ___ >> 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 > > ___ > 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] [Horizon][Tuskar-UI] Location for common dashboard code?
Hi Doug, Thanks for the response! I agree with you in the cases where we are extending things like panels; if you're extending those, you're extending the dashboard itself. However, things such as workflows feel like they could reasonably live independently of the dashboard for re-use elsewhere. Incidentally, I know that within openstack_dashboard there are cases where, say, the admin dashboard extends instances tables from the project dashboard. That feels a bit odd to me; wouldn't it be cleaner to have both dashboards extend some common instances table that lives independently of either dashboard? Thanks, Tzu-Mainn Chen - Original Message - > Hey Tzu-Mainn, > > I've actually discouraged people from doing this sort of thing when > customizing Horizon. IMO it's risky to extend those panels because they > really aren't intended as extension points. We intend Horizon to be > extensible by adding additional panels or dashboards. I know you are > closely involved in Horizon development, so you are better able to manage > that better than most customizers. > > Still, I wonder if we can better address this for Tuskar-UI as well as > other situations by defining extensibility points in the dashboard panels > and workflows themselves. Like well defined ways to add/show a column of > data, add/hide row actions, add/skip a workflow step, override text > elements, etc. Is it viable to create a few well defined extension points > and meet your need to modify existing dashboard panels? > > In any case, it seems to me that if you are overriding the dashboard > panels, it's reasonable that tuskar-ui should be dependent on the > dashboard. > > Doug Fish > > > > > > From: Tzu-Mainn Chen > To: "OpenStack Development Mailing List (not for usage questions)" > , > Date: 05/28/2014 11:40 AM > Subject: [openstack-dev] [Horizon][Tuskar-UI] Location for common > dashboard code? > > > > Heya, > > Tuskar-UI is currently extending classes directly from openstack-dashboard. > For example, right now > our UI for Flavors extends classes in both > openstack_dashboard.dashboards.admin.flavors.tables and > openstack_dashboard.dashboards.admin.flavors.workflows. In the future, > this sort of pattern will > increase; we anticipate doing similar things with Heat code in > openstack-dashboard. > > However, since tuskar-ui is intended to be a separate dashboard that has > the potential to live > away from openstack-dashboard, it does feel odd to directly extend > openstack-dashboard dashboard > components. Is there a separate place where such code might live? > Something similar in concept > to > https://github.com/openstack/horizon/tree/master/openstack_dashboard/usage > ? > > > Thanks, > Tzu-Mainn Chen > > ___ > 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 > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon][Tuskar-UI] Location for common dashboard code?
Hey Tzu-Mainn, I've actually discouraged people from doing this sort of thing when customizing Horizon. IMO it's risky to extend those panels because they really aren't intended as extension points. We intend Horizon to be extensible by adding additional panels or dashboards. I know you are closely involved in Horizon development, so you are better able to manage that better than most customizers. Still, I wonder if we can better address this for Tuskar-UI as well as other situations by defining extensibility points in the dashboard panels and workflows themselves. Like well defined ways to add/show a column of data, add/hide row actions, add/skip a workflow step, override text elements, etc. Is it viable to create a few well defined extension points and meet your need to modify existing dashboard panels? In any case, it seems to me that if you are overriding the dashboard panels, it's reasonable that tuskar-ui should be dependent on the dashboard. Doug Fish From: Tzu-Mainn Chen To: "OpenStack Development Mailing List (not for usage questions)" , Date: 05/28/2014 11:40 AM Subject: [openstack-dev] [Horizon][Tuskar-UI] Location for common dashboard code? Heya, Tuskar-UI is currently extending classes directly from openstack-dashboard. For example, right now our UI for Flavors extends classes in both openstack_dashboard.dashboards.admin.flavors.tables and openstack_dashboard.dashboards.admin.flavors.workflows. In the future, this sort of pattern will increase; we anticipate doing similar things with Heat code in openstack-dashboard. However, since tuskar-ui is intended to be a separate dashboard that has the potential to live away from openstack-dashboard, it does feel odd to directly extend openstack-dashboard dashboard components. Is there a separate place where such code might live? Something similar in concept to https://github.com/openstack/horizon/tree/master/openstack_dashboard/usage ? Thanks, Tzu-Mainn Chen ___ 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
[openstack-dev] [Horizon][Tuskar-UI] Location for common dashboard code?
Heya, Tuskar-UI is currently extending classes directly from openstack-dashboard. For example, right now our UI for Flavors extends classes in both openstack_dashboard.dashboards.admin.flavors.tables and openstack_dashboard.dashboards.admin.flavors.workflows. In the future, this sort of pattern will increase; we anticipate doing similar things with Heat code in openstack-dashboard. However, since tuskar-ui is intended to be a separate dashboard that has the potential to live away from openstack-dashboard, it does feel odd to directly extend openstack-dashboard dashboard components. Is there a separate place where such code might live? Something similar in concept to https://github.com/openstack/horizon/tree/master/openstack_dashboard/usage ? Thanks, Tzu-Mainn Chen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
