Open Stack

Hi team,

I'm speaking mostly from Horizon side, but it should be pretty the same for
others.

We started a discussion today at the Horizon's meeting but we don't have
any decision now.

For the current release cycle, it looks reasonable to test plugins over the
latest master on gates. We're thinking to introduce horizon-lib but we need
further discussions on it.

Horizon follows stable policy and we try to do our best to not break any
existing plugin. Unfortunately, due to some cross-projects
miscommunications, there were some issues with plugins this cycle. I'm
ready to work with plugins team to fix these issues asap.

To prevent such issues in the future, I think it would be good to have
cross-project jobs on Horizon's gates too. We should run at least plugins
unit-tests against Horizon's proposed patch to make sure that we don't
break anything in plugins. E.g. if we drop some deprecated feature or make
an incompatible change, such job will notify us that we need to update
a plugin first before merging patch to Horizon. I don't know what is the
best way to implement such jobs so it would be good to get some inputs and
help from Infra team here.



Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Wed, Apr 25, 2018 at 7:40 PM, Jeremy Stanley <fungi at yuggoth.org> wrote:

> On 2018-04-25 12:03:54 -0400 (-0400), Doug Hellmann wrote:
> [...]
> > Especially now with lower-constraints jobs in place, having plugins
> > rely on features only available in unreleased versions of service
> > projects doesn't make a lot of sense. We test that way *between*
> > services using integration tests that use the REST APIs, but we
> > also have some pretty strong stability requirements in place for
> > those APIs.
> [...]
>
> This came up again a few days ago for sahara-dashboard. We talked
> through some obvious alternatives to keep its master branch from
> depending on an unreleased state of horizon and the situation today
> is that plugin developers have been relying on developing their
> releases in parallel with the services. Not merging an entire
> development cycle's worth of work until release day (whether that's
> by way of a feature branch or by just continually rebasing and
> stacking in Gerrit) would be a very painful workflow for them, and
> having to wait a full release cycle before they could start
> integrating support for new features in the service would be equally
> unfortunate.
>
> As for merging the plugin and service repositories, they tend to be
> developed by completely disparate teams so that could require a fair
> amount of political work to solve. Extracting the plugin interface
> into a separate library which releases more frequently than the
> service does indeed sound like the sanest option, but will also
> probably take quite a while for some teams to achieve (I gather
> neutron-lib is getting there, but I haven't heard about any work
> toward that end in Horizon yet).
> --
> Jeremy Stanley
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180425/2ce395d7/attachment.html>