brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aledsage <>
Subject [GitHub] brooklyn-library pull request #44: RiakNode Internal Networking
Date Fri, 24 Jun 2016 20:06:07 GMT
Github user aledsage commented on a diff in the pull request:
    --- Diff: software/nosql/src/main/java/org/apache/brooklyn/entity/nosql/riak/
    @@ -99,17 +110,59 @@ public boolean isPackageDownloadUrlProvided() {
         protected Collection<Integer> getRequiredOpenPorts() {
    -        // TODO this creates a huge list of inbound ports; much better to define on a
security group using range syntax!
    -        int erlangRangeStart = getConfig(ERLANG_PORT_RANGE_START).iterator().next();
    -        int erlangRangeEnd = getConfig(ERLANG_PORT_RANGE_END).iterator().next();
    +        PortRange erlangPorts = config().get(ERLANG_PORT_RANGE);
    +        Integer erlangRangeStart = config().get(ERLANG_PORT_RANGE_START);
    +        Integer erlangRangeEnd = config().get(ERLANG_PORT_RANGE_END);
    +        if (erlangRangeStart == null) erlangRangeStart = Iterables.get(erlangPorts, 0);
    +        if (erlangRangeEnd == null) erlangRangeEnd = Iterables.getLast(erlangPorts);
    +        sensors().set(ERLANG_PORT_RANGE_START, erlangRangeStart);
    --- End diff --
    I'm a bit confused by the deprecation of this. I'd have expected:
    * a `log.warn` when using the deprecated value (i.e. when it's not null), to alert people
that they are using the deprecated value
    * us not to use the sensor (other than to set it for backwards compatibility), given it's
deprecated - but it's later used in `configureInternalNetwork`.
    * changing the key's name might cause backwards compatibility problems (even though you
have `@SetFromFlag` with the old name). The setFromFlag stuff doesn't work for inherited config,
I believe.
    * I'd have expected you to keep the old key (deprecated) and declare the new key; to read
the value from both and to warn if `getRaw()` is non-null for the old one. If you do that,
then we are free to delete it at some point. The way you've changed it, then it's hard to
ever delete the `@SetFromFlag` name.
    Using PortRange doesn't feel quite right. Our `PortRange` does not have to be linear (e.g.
you could do `PortRanges.fromString("1,3,5")`).
    We subsequently use it as though it must be a contiguous range, with a simple start and
end value. Maybe we should just leave the configuration as that?

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

View raw message