<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div dir="ltr">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.<br>
<br>
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.<br>
<br>
"<span style="font-size:12.8px">It also means that as a plugin I know that the released version of </span><span style="font-size:12.8px">my plugin has been tested in my gate with the exact version of the </span><span style="font-size:12.8px">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.<br>
</span><br>
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.
<div><br>
</div>
<div>Rob<br>
<br>
<br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 20 July 2016 at 17:36, Hayes, Graham <span dir="ltr">
<<a href="mailto:graham.hayes@hpe.com" target="_blank">graham.hayes@hpe.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="">On 20/07/2016 15:13, Rob Cresswell wrote:<br>
> Yes, it would mean changing your requirements after a release. So, for<br>
> example you might run two gate tests:<br>
><br>
> - A voting Horizon-stable/milestone test, (or both)<br>
> - A non-voting Horizon-master test<br>
><br>
> That gives you a lot of control over making your tests passing (multiple<br>
> patches to make the Horizon-master test pass, or all in one patch set<br>
> alongside the horizon-milestone test bump), rather than random failures<br>
> each week. You'd still be able to track the failures as they come in,<br>
> but they won't break your gate each time.<br>
<br>
</span>I don't want control, I want to consume a library in a standard way -<br>
the way we consume libraries from the rest of openstack.<br>
<span class=""><br>
> I don't think where horizon (the library) lives would change how you<br>
> version against it. We don't currently have any plans to separate the<br>
> two; while we realise its a desirable change, weighing the work and risk<br>
> involved in the split architecture vs the end result, we've chosen to<br>
> work on other higher priority items for now (performance, filtering<br>
> improvements, angular work etc.)<br>
<br>
</span>Well, if would stop us having a reference to git branch in our<br>
requirements, and allow to use the standard global requirements<br>
process to manage the dependency.<br>
<br>
It also means that as a plugin I know that the released version of<br>
my plugin has been tested in my gate with the exact version of the<br>
code that the horizon team release.<br>
<br>
We can still do multiple patches to fix any changes in the horizon<br>
library, and in the tip of the chain update the version in requirements.<br>
<br>
The risk has just been moved to the plugins, which is not ideal.<br>
<br>
It also makes downstream consumption *a lot* easier.<br>
<span class=""><br>
><br>
><br>
> On 20 July 2016 at 13:38, Hayes, Graham <<a href="mailto:graham.hayes@hpe.com">graham.hayes@hpe.com</a><br>
</span>
<div>
<div class="h5">> <mailto:<a href="mailto:graham.hayes@hpe.com">graham.hayes@hpe.com</a>>> wrote:<br>
><br>
> On 20/07/2016 10:16, Rob Cresswell wrote:<br>
> > Hey all,<br>
> ><br>
> > So we've had a few issues with plugin stability recently, and its<br>
> > apparent that many plugins are building off Horizon master as a<br>
> > dependency. I would really advise against this. A more manageable<br>
> > development process may be to:<br>
> ><br>
> > - Base stable plugins against a stable release of Horizon<br>
> > - Base WIP versions/new plugins off the last Horizon milestone, b2 in<br>
> > this case, and then bump the version and capture issues within the same<br>
> > patch. This should prevent random breakages, and should allow you to<br>
> > just look at the release notes for that milestone.<br>
><br>
> So this would mean changing tox.ini or requirements files after each<br>
> horizon release?<br>
><br>
> This dovetails nicely with the other thread about how we should be doing<br>
> cross project interactions.<br>
><br>
> What would be best, would be having horizon released as a separate<br>
> library on pypi like the clients and oslo libs.<br>
><br>
> Then openstack-dashboard, and all the plugins could rely on the same<br>
> base library, without hacks like:<br>
><br>
> deps =<br>
> -r{toxinidir}/requirements.txt<br>
> -r{toxinidir}/test-requirements.txt<br>
> <a href="http://tarballs.openstack.org/horizon/horizon-master.tar.gz" rel="noreferrer" target="_blank">
http://tarballs.openstack.org/horizon/horizon-master.tar.gz</a><br>
><br>
> in tox.ini or<br>
><br>
> # Testing Requirements<br>
><br>
> <a href="http://tarballs.openstack.org/horizon/horizon-master.tar.gz#egg=horizon" rel="noreferrer" target="_blank">
http://tarballs.openstack.org/horizon/horizon-master.tar.gz#egg=horizon</a><br>
><br>
> in (test-)requirements.txt<br>
><br>
> Is that on roadmap?<br>
><br>
> > On the Horizon side, we've moved our FF a week earlier, so I think that<br>
> > week combined with the usual RC period should be enough time to fix<br>
> > bugs. We'll aim to make sure our release notes are complete with regards<br>
> > to breaking issues for plugins, and deprecate appropriately.<br>
> ><br>
> > Rob<br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
</div>
</div>
> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<div class="HOEnZb">
<div class="h5">><br>
><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</body>
</html>