cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (CLOUDSTACK-8832) Update Nuage VSP plugin to work with Nuage VSP release 3.2
Date Tue, 03 Nov 2015 21:45:27 GMT


ASF GitHub Bot commented on CLOUDSTACK-8832:

Github user mlsorensen commented on the pull request:
        I largely agree, it provides the best experience for our end users if
    we can always verify that plugins are functional and maintainable. On the
    flip side, it seems that's part of the point of plugins. It isolates vendor
    or implementation-specific code, making it easier to pick up by someone
    else who may have domain knowledge but not CloudStack knowledge, or to easy
    to remove if it becomes dead code.
        In the case of vendors, if they stop their involvement, the most likely
    end result is that the code won't be maintained, and if we haven't been
    given means to test then we won't know on our own if it is functional. If
    the vendor has ended involvement though, even if they've provided means to
    test the code then those means may become defunct as well (e.g. software,
    system, or license is deprecated), so providing means to the community for
    testing doesn't seem to help much if we don't have continued vendor
    support. In the past we have simply held a community vote to determine who
    cares about the plugin, followed by removal, or if there's someone who
    cares about the code and is in a position to maintain and provide testing
    for it, they become the community maintainer for that code.
         One note of caution, the nature of the plugin architecture also
    provides room for vendors to work on their own and provide their code
    and/or artifacts to their customers. Short of the tiny core changes in this
    request, they don't need to provide this code to the community. I'd prefer
    to err on the side of being inviting to vendor contributions and bring the
    developers into the community, rather than holding them at arm's length and
    asking for a clean handoff or insurance policy in case they disappear.
    We've seen community members jump jobs and still stick around because they
    found an inviting environment where their contributions were welcomed and
    valued, and they grew within the community, and I almost consider that
    culture more important than ensuring any maintainer's duties can be
    replaced by someone else in the community.
        Then again, I'm only tangentially involved in the community right now,
    so I won't feel bad if anyone takes my opinion with a grain of salt.
         TL; DR - While I'd really, really like to see vendors provide support
    to make their plugins testable by the community, I don't think that it buys
    us much in regards to maintaining the plugin if the vendor stops their
    community involvement, short of having donated hardware with perpetual
    license and free updates. As such, I'd rather lower the bar for developers
    to maintain their plugin code, with the fallback of being able to easily
    remove abandoned plugin code as a last resort.
    On Tue, Nov 3, 2015 at 12:11 PM, John Burwell <>
    > @ustcweizhou <> @remibergsma
    > <> this is a massive technical debt that we
    > are carrying with other plugins, and I think we need to stop to expanding
    > that debt. In some cases, we (i.e. ASF) have been granted licenses for
    > virtual appliances to test plugin operation (a completely valid way to
    > verify operation). For others, we are shipping code that has not been
    > verified for a number of releases. In the past, plugins have been
    > contributed and tested for a release, but those contributors have not
    > remained active to maintain the plugin. Since the community lacks the
    > equipment or test rigs, no one else can pick up maintenance -- leaving us
    > with bit rotting code. In summary, as a community, we should not be
    > accepting the responsibility to support and maintain code whose operation
    > we cannot verify -- plugin or core. The question of what to do with
    > existing plugi ns that don't meet this criteria is a discussion for another
    > thread.
    > —
    > Reply to this email directly or view it on GitHub
    > <>.

> Update Nuage VSP plugin to work with Nuage VSP release 3.2
> ----------------------------------------------------------
>                 Key: CLOUDSTACK-8832
>                 URL:
>             Project: CloudStack
>          Issue Type: Improvement
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Management Server
>    Affects Versions: 4.6.0
>            Reporter: Nick Livens
>            Assignee: Nick Livens
>         Attachments: nuageVspMarvinLogs.tar.gz
> Nuage VSP 3.2 is being released, we want to bring the plugin up to date for this release

This message was sent by Atlassian JIRA

View raw message