Re: [openstack-dev] [horizon][plugins] Introduce horizonlib (again)
Hi Doug, We discussed this option a bit too. Maybe we need to think about this again. >From my point of view, it would be better to keep current release model for now, because we've got a very small amount of active horizon contributors, so current release model helps us deliver the project in time. From the other side, your option is less complicated and could be easier to implement. Let's get more feedback from the team before further discussion. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Wed, Jun 13, 2018 at 6:43 PM, Doug Hellmann wrote: > Excerpts from Ivan Kolodyazhny's message of 2018-06-13 18:01:26 +0300: > > Hi team, > > > > Last week on the Horizon meeting we discussed [1] possible options for > > Horizon release model to address current issues for plugins maintainers. > > Some background could be found here [2]. > > > > The main issue is that we should have some stable API for plugins and be > > able to release it as needed. We're trying to cover several use cases > with > > this effort. E.g: > > - do not break plugins with Horizon changes (cross-project CI would help > > with some issues here too) > > - provide an easy way to develop plugins which require specific Horizon > > version and features > > > > For now, most of the plugins use 'horizon' package to implement > > dashboard extensions. Some plugins use parts of 'openstack_dashboard' > > package. In such case, it becomes complicated to develop plugins based on > > current master and have CI up and running. > > > > The idea is to introduce something like 'horizonlib' or 'horizon-sdk' > with > > a stable API for plugin development. We're going to collect everything > > needed for this library, so plugins developers could consume only it and > do > > not relate on any internal Horizon things. > > > > We'd got horizonlib in the past. Unfortunately, we missed information > about > > what was good or bad but we'll do our best to succeed in this. > > > > > > If you have any comments or questions, please do not hesitate to drop few > > words into this conversation or ping me in IRC. We're going to collect as > > much feedback as we can before we'll discuss it in details during the > next > > PTG. > > > > > > [1] > > http://eavesdrop.openstack.org/meetings/horizon/2018/ > horizon.2018-06-06-15.01.log.html#l-29 > > [2] > > http://lists.openstack.org/pipermail/openstack-dev/2018- > March/128310.html > > > > Regards, > > Ivan Kolodyazhny, > > http://blog.e0ne.info/ > > Another solution that may end up being less work is to release Horizon > using the cycle-with-intermediary model and publish the releases to > PyPI. Those two changes would let you release changes at any point in > the cycle, to support your plugin authors, and would not require > reorganizing the code in Horizon to build a new release artifact. > > The release team would be happy to offer advice about how to make the > changes, if you want to talk about it. > > Doug > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon][plugins] Introduce horizonlib (again)
Excerpts from Ivan Kolodyazhny's message of 2018-06-13 18:01:26 +0300: > Hi team, > > Last week on the Horizon meeting we discussed [1] possible options for > Horizon release model to address current issues for plugins maintainers. > Some background could be found here [2]. > > The main issue is that we should have some stable API for plugins and be > able to release it as needed. We're trying to cover several use cases with > this effort. E.g: > - do not break plugins with Horizon changes (cross-project CI would help > with some issues here too) > - provide an easy way to develop plugins which require specific Horizon > version and features > > For now, most of the plugins use 'horizon' package to implement > dashboard extensions. Some plugins use parts of 'openstack_dashboard' > package. In such case, it becomes complicated to develop plugins based on > current master and have CI up and running. > > The idea is to introduce something like 'horizonlib' or 'horizon-sdk' with > a stable API for plugin development. We're going to collect everything > needed for this library, so plugins developers could consume only it and do > not relate on any internal Horizon things. > > We'd got horizonlib in the past. Unfortunately, we missed information about > what was good or bad but we'll do our best to succeed in this. > > > If you have any comments or questions, please do not hesitate to drop few > words into this conversation or ping me in IRC. We're going to collect as > much feedback as we can before we'll discuss it in details during the next > PTG. > > > [1] > http://eavesdrop.openstack.org/meetings/horizon/2018/horizon.2018-06-06-15.01.log.html#l-29 > [2] > http://lists.openstack.org/pipermail/openstack-dev/2018-March/128310.html > > Regards, > Ivan Kolodyazhny, > http://blog.e0ne.info/ Another solution that may end up being less work is to release Horizon using the cycle-with-intermediary model and publish the releases to PyPI. Those two changes would let you release changes at any point in the cycle, to support your plugin authors, and would not require reorganizing the code in Horizon to build a new release artifact. The release team would be happy to offer advice about how to make the changes, if you want to talk about it. Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [horizon][plugins] Introduce horizonlib (again)
Hi team, Last week on the Horizon meeting we discussed [1] possible options for Horizon release model to address current issues for plugins maintainers. Some background could be found here [2]. The main issue is that we should have some stable API for plugins and be able to release it as needed. We're trying to cover several use cases with this effort. E.g: - do not break plugins with Horizon changes (cross-project CI would help with some issues here too) - provide an easy way to develop plugins which require specific Horizon version and features For now, most of the plugins use 'horizon' package to implement dashboard extensions. Some plugins use parts of 'openstack_dashboard' package. In such case, it becomes complicated to develop plugins based on current master and have CI up and running. The idea is to introduce something like 'horizonlib' or 'horizon-sdk' with a stable API for plugin development. We're going to collect everything needed for this library, so plugins developers could consume only it and do not relate on any internal Horizon things. We'd got horizonlib in the past. Unfortunately, we missed information about what was good or bad but we'll do our best to succeed in this. If you have any comments or questions, please do not hesitate to drop few words into this conversation or ping me in IRC. We're going to collect as much feedback as we can before we'll discuss it in details during the next PTG. [1] http://eavesdrop.openstack.org/meetings/horizon/2018/horizon.2018-06-06-15.01.log.html#l-29 [2] http://lists.openstack.org/pipermail/openstack-dev/2018-March/128310.html Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
