Kirill: The failures are just as visible, since the cores still control merging anyway. The only difference is that if it takes a few days to fix something in upstream Horizon, you needn't block your own content in the meantime. Later in the release cycle (around N-3, for example) cores could just not merge failing tests. Regardless, this is just a recommendation, and if you're comfortable adjusting to issues as they come through, then thats fine to base off master.
Graham: The "risk" I refer to is in that in any project architecture rewrite you can make mistakes and break functionality. So that risk only arises from a rewrite. "It also means that as a plugin I know that the released version of my plugin has been tested in my gate with the exact version of the code that the horizon team release." - I don't understand this part. If we release a horizon lib, we'd still being doing milestone releases to PyPI. So again, whether you consume that as a tarball or a PyPI package makes little difference to the day to day testing of your plugin. Its the same code. Ideally - yes, we'd probably split horizon as a separate library, but thats something to discuss at the summit and judge demand, because most discussions thus far have concluded that its a lower priority issue than others. Rob On 20 July 2016 at 17:36, Hayes, Graham <graham.ha...@hpe.com<mailto:graham.ha...@hpe.com>> wrote: On 20/07/2016 15:13, Rob Cresswell wrote: > Yes, it would mean changing your requirements after a release. So, for > example you might run two gate tests: > > - A voting Horizon-stable/milestone test, (or both) > - A non-voting Horizon-master test > > That gives you a lot of control over making your tests passing (multiple > patches to make the Horizon-master test pass, or all in one patch set > alongside the horizon-milestone test bump), rather than random failures > each week. You'd still be able to track the failures as they come in, > but they won't break your gate each time. I don't want control, I want to consume a library in a standard way - the way we consume libraries from the rest of openstack. > I don't think where horizon (the library) lives would change how you > version against it. We don't currently have any plans to separate the > two; while we realise its a desirable change, weighing the work and risk > involved in the split architecture vs the end result, we've chosen to > work on other higher priority items for now (performance, filtering > improvements, angular work etc.) Well, if would stop us having a reference to git branch in our requirements, and allow to use the standard global requirements process to manage the dependency. It also means that as a plugin I know that the released version of my plugin has been tested in my gate with the exact version of the code that the horizon team release. We can still do multiple patches to fix any changes in the horizon library, and in the tip of the chain update the version in requirements. The risk has just been moved to the plugins, which is not ideal. It also makes downstream consumption *a lot* easier. > > > On 20 July 2016 at 13:38, Hayes, Graham > <graham.ha...@hpe.com<mailto:graham.ha...@hpe.com> > <mailto:graham.ha...@hpe.com<mailto:graham.ha...@hpe.com>>> wrote: > > On 20/07/2016 10:16, Rob Cresswell wrote: > > Hey all, > > > > So we've had a few issues with plugin stability recently, and its > > apparent that many plugins are building off Horizon master as a > > dependency. I would really advise against this. A more manageable > > development process may be to: > > > > - Base stable plugins against a stable release of Horizon > > - Base WIP versions/new plugins off the last Horizon milestone, b2 in > > this case, and then bump the version and capture issues within the same > > patch. This should prevent random breakages, and should allow you to > > just look at the release notes for that milestone. > > So this would mean changing tox.ini or requirements files after each > horizon release? > > This dovetails nicely with the other thread about how we should be doing > cross project interactions. > > What would be best, would be having horizon released as a separate > library on pypi like the clients and oslo libs. > > Then openstack-dashboard, and all the plugins could rely on the same > base library, without hacks like: > > deps = > -r{toxinidir}/requirements.txt > -r{toxinidir}/test-requirements.txt > http://tarballs.openstack.org/horizon/horizon-master.tar.gz > > in tox.ini or > > # Testing Requirements > > http://tarballs.openstack.org/horizon/horizon-master.tar.gz#egg=horizon > > in (test-)requirements.txt > > Is that on roadmap? > > > On the Horizon side, we've moved our FF a week earlier, so I think that > > week combined with the usual RC period should be enough time to fix > > bugs. We'll aim to make sure our release notes are complete with regards > > to breaking issues for plugins, and deprecate appropriately. > > > > Rob > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > <http://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://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
