[ClusterLabs Developers] [openstack-dev] [HA] future of OpenStack OCF resource agents (was: resource-agents v4.2.0)

[Tim Bell]

Adam,

Personally, I would prefer the approach where the OpenStack resource agents are part of the repository in which they are used. This is also the approach taken in other open source projects such as Kubernetes and avoids the inconsistency where, for example, Azure resource agents are in the Cluster Labs repository but OpenStack ones are not. This can mean that people miss there is OpenStack integration available.

This does not reflect, in any way, the excellent efforts and results made so far. I don't think it would negate the possibility to include testing in the OpenStack gate since there are other examples where code is pulled in from other sources. 

Tim

-----Original Message-----
From: Adam Spiers <aspiers at suse.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Date: Wednesday, 24 October 2018 at 14:29
To: "developers at clusterlabs.org" <developers at clusterlabs.org>, openstack-dev mailing list <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [ClusterLabs Developers] [HA] future of OpenStack OCF resource agents (was: resource-agents v4.2.0)

    [cross-posting to openstack-dev]
    
    Oyvind Albrigtsen <oalbrigt at redhat.com> wrote:
    >ClusterLabs is happy to announce resource-agents v4.2.0.
    >Source code is available at:
    >https://github.com/ClusterLabs/resource-agents/releases/tag/v4.2.0
    >
    >The most significant enhancements in this release are:
    >- new resource agents:
    
    [snipped]
    
    > - openstack-cinder-volume
    > - openstack-floating-ip
    > - openstack-info
    
    That's an interesting development.
    
    By popular demand from the community, in Oct 2015 the canonical
    location for OpenStack-specific resource agents became:
    
        https://git.openstack.org/cgit/openstack/openstack-resource-agents/
    
    as announced here:
    
        http://lists.openstack.org/pipermail/openstack-dev/2015-October/077601.html
    
    However I have to admit I have done a terrible job of maintaining it
    since then.  Since OpenStack RAs are now beginning to creep into
    ClusterLabs/resource-agents, now seems a good time to revisit this and
    decide a coherent strategy.  I'm not religious either way, although I
    do have a fairly strong preference for picking one strategy which both
    ClusterLabs and OpenStack communities can align on, so that all
    OpenStack RAs are in a single place.
    
    I'll kick the bikeshedding off:
    
    Pros of hosting OpenStack RAs on ClusterLabs
    --------------------------------------------
    
    - ClusterLabs developers get the GitHub code review and Travis CI
      experience they expect.
    
    - Receive all the same maintenance attention as other RAs - any
      changes to coding style, utility libraries, Pacemaker APIs,
      refactorings etc. which apply to all RAs would automatically
      get applied to the OpenStack RAs too.
    
    - Documentation gets built in the same way as other RAs.
    
    - Unit tests get run in the same way as other RAs (although does
      ocf-tester even get run by the CI currently?)
    
    - Doesn't get maintained by me ;-)
    
    Pros of hosting OpenStack RAs on OpenStack infrastructure
    ---------------------------------------------------------
    
    - OpenStack developers get the Gerrit code review and Zuul CI
      experience they expect.
    
    - Releases and stable/foo branches could be made to align with
      OpenStack releases (..., Queens, Rocky, Stein, T(rains?)...)
    
    - Automated testing could in the future spin up a full cloud
      and do integration tests by simulating failure scenarios,
      as discussed here:
    
          https://storyboard.openstack.org/#!/story/2002129
    
      That said, that is still very much work in progress, so
      it remains to be seen when that could come to fruition.
    
    No doubt I've missed some pros and cons here.  At this point
    personally I'm slightly leaning towards keeping them in the
    openstack-resource-agents - but that's assuming I can either hand off
    maintainership to someone with more time, or somehow find the time
    myself to do a better job.
    
    What does everyone else think?  All opinions are very welcome,
    obviously.
    
    __________________________________________________________________________
    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