<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Initially I don’t think I like the idea of making master-horizon job non-voting for murano-dashboard.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="margin: 0px;">Here are some reasons: </div><div id="bloop_customfont" style="margin: 0px;"><span class="Apple-tab-span" style="white-space:pre">    </span>1) We would still need to fix murano-dashboard to work with master horizon (since we would need to be released together)</div><div id="bloop_customfont" style="margin: 0px;"><span class="Apple-tab-span" style="white-space:pre">      </span>2) The breakage would be less visible</div><div id="bloop_customfont" style="margin: 0px;"><span class="Apple-tab-span" style="white-space:pre"> </span>3) I can imagine a situation when a change would pass on master but would not pass on a previous stable point release (even worse this release can be n3). Say we’re trying to use some function/feature, that has just landed.</div><div id="bloop_customfont" style="margin: 0px;"><br></div><div id="bloop_customfont" style="margin: 0px;">Those are my initial ideas about this, have give it a bit more time, to think more carefully.</div><div id="bloop_customfont" style="margin: 0px;"><br></div><div id="bloop_customfont" style="margin: 0px;">BTW, I can fetch the numbers on how many times murano-dashboard gate was broken by changes in horizon, during M and N cycles, if you’re interested. Also for murano-dashboard we run our integration selenium tests as a 3d-party CI, so technically we’re not blocked by the job not working, in case we need to land some security patch. =)</div><br> <div id="bloop_sign_1469030107870658816" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Kirill Zaitsev</div><div style="font-family:helvetica,arial;font-size:13px">Murano Project Tech Lead</div><div style="font-family:helvetica,arial;font-size:13px">Software Engineer at</div><div style="font-family:helvetica,arial;font-size:13px">Mirantis, Inc</div></div> <br><p class="airmail_on">On 20 juillet 2016 at 17:10:46, Rob Cresswell (<a href="mailto:robert.cresswell@outlook.com">robert.cresswell@outlook.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>



<title></title>


<div dir="ltr">Yes, it would mean changing your requirements after
a release. So, for example you might run two gate tests:<br>
<br>
<div>- A voting Horizon-stable/milestone test, (or both)</div>
<div>- A non-voting Horizon-master test<br>
<br>
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.<br>
<br>
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.)<br>
<br>
Rob<br>
<br>
<br></div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 20 July 2016 at 13:38, 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 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></span>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>
   <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>
<span class="im HOEnZb"><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></span>
<div class="HOEnZb">
<div class="h5">
__________________________________________________________________________<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>


__________________________________________________________________________
<br>OpenStack Development Mailing List (not for usage questions)
<br>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
<br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<br></div></div></span></blockquote></body></html>