Initially I don’t think I like the idea of making master-horizon job non-voting for murano-dashboard.
Here are some reasons:
1) We would still need to fix murano-dashboard to work with master
horizon (since we would need to be released together)
2) The breakage would be less visible
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.
Those are my initial ideas about this, have give it a bit more time, to think
more carefully.
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. =)
--
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc
On 20 juillet 2016 at 17:10:46, Rob Cresswell (robert.cressw...@outlook.com)
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 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.)
Rob
On 20 July 2016 at 13:38, Hayes, Graham <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://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
signature.asc
Description: Message signed with OpenPGP using AMPGpg
__________________________________________________________________________ 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
