Re: broken build

[Owen Nichols]

Thanks Bruce!  I’ve updated the release script to make a PR instead of 
committing directly to develop when adding the old version.

> On Sep 27, 2019, at 5:04 PM, Bruce Schuchardt  wrote:
> 
> I've pushed changes to handle v1.10.0 in our tests
> 
> Please don't push changes to our repo w/o running them through our tests.
> 
> You might think changing something like setting.gradle isn't a big deal but 
> in this case it exposed problems that needed to be addressed.
> 

re: broken build

[Bruce Schuchardt]

I've pushed changes to handle v1.10.0 in our tests

Please don't push changes to our repo w/o running them through our tests.

You might think changing something like setting.gradle isn't a big deal 
but in this case it exposed problems that needed to be addressed.

Cutting Geode 1.9.2

[Udo Kohlmeyer]

Hi there Geode Dev's,

There seems to be consensus on cutting Geode 1.9.2. 
https://lists.apache.org/thread.html/9b5f5c58e1b298d9d0ca870a0deec06f7344a60809790c75a5f68bfa@%3Cdev.geode.apache.org%3E


Would there be any willing candidates who would raise their hand to 
shepherd this release? Maybe some one from our newer/younger committers?


--Udo

Re: Lingering Geode 1.10.0 release issues

[Bruce Schuchardt]

Unfortunately I'm finding that our gradle build scripts are also using 
string comparisons on Geode versions.  You can't do something like


    (oldGeodeVersion >= "1.7.0")

and expect that to work when the version is "1.10.0"

On 9/27/19 10:12 AM, Bruce Schuchardt wrote:
Some backward-compatibility tests are using string comparisons on 
versions, which isn't working well with our new "1.10.0".  Others are 
converting version strings into numbers, so 1.10.0 becomes 1100.  
That's working okay but is also a time-bomb.  I'm changing the tests 
to use a new TestVersion class that knows how to work with 
major.minor.patch strings.


On 9/27/19 9:28 AM, Dan Smith wrote:

Bruce has picked up GEODE-7250.

-Dan

On Fri, Sep 27, 2019 at 9:27 AM Dick Cavender  
wrote:



If you try and brew update to Geode 1.10.0 you won't get it until our
1.10.0 homebrew PR 


gets
through their checks and their Jenkins servers seem to be having 
problems

this week so this is still in flight.

On geode develop I've had to revert the "add 1.10.0 to old versions" 
post

release change because it was causing tests to fail. Until new JIRA
GEODE-7250 is fixed we will not be testing 1.10.0 as an old version. 
This
JIRA needs to be prioritized and the PR with the fix needs to 
include the

revert changes to get 1.10.0 back in the old versions.

Let me know if anyone has questions on these.

-Dick

Re: Lingering Geode 1.10.0 release issues

[Bruce Schuchardt]

Some backward-compatibility tests are using string comparisons on 
versions, which isn't working well with our new "1.10.0".  Others are 
converting version strings into numbers, so 1.10.0 becomes 1100.  That's 
working okay but is also a time-bomb.  I'm changing the tests to use a 
new TestVersion class that knows how to work with major.minor.patch strings.


On 9/27/19 9:28 AM, Dan Smith wrote:

Bruce has picked up GEODE-7250.

-Dan

On Fri, Sep 27, 2019 at 9:27 AM Dick Cavender  wrote:


If you try and brew update to Geode 1.10.0 you won't get it until our
1.10.0 homebrew PR 
gets
through their checks and their Jenkins servers seem to be having problems
this week so this is still in flight.

On geode develop I've had to revert the "add 1.10.0 to old versions" post
release change because it was causing tests to fail. Until new JIRA
GEODE-7250 is fixed we will not be testing 1.10.0 as an old version. This
JIRA needs to be prioritized and the PR with the fix needs to include the
revert changes to get 1.10.0 back in the old versions.

Let me know if anyone has questions on these.

-Dick

Re: Lingering Geode 1.10.0 release issues

[Robert Houghton]

Did the 'merge release branch into master and develop' go smoothly?

On Fri, Sep 27, 2019 at 9:27 AM Dick Cavender  wrote:

> If you try and brew update to Geode 1.10.0 you won't get it until our
> 1.10.0 homebrew PR 
> gets
> through their checks and their Jenkins servers seem to be having problems
> this week so this is still in flight.
>
> On geode develop I've had to revert the "add 1.10.0 to old versions" post
> release change because it was causing tests to fail. Until new JIRA
> GEODE-7250 is fixed we will not be testing 1.10.0 as an old version. This
> JIRA needs to be prioritized and the PR with the fix needs to include the
> revert changes to get 1.10.0 back in the old versions.
>
> Let me know if anyone has questions on these.
>
> -Dick
>

Re: Lingering Geode 1.10.0 release issues

[Dan Smith]

Bruce has picked up GEODE-7250.

-Dan

On Fri, Sep 27, 2019 at 9:27 AM Dick Cavender  wrote:

> If you try and brew update to Geode 1.10.0 you won't get it until our
> 1.10.0 homebrew PR 
> gets
> through their checks and their Jenkins servers seem to be having problems
> this week so this is still in flight.
>
> On geode develop I've had to revert the "add 1.10.0 to old versions" post
> release change because it was causing tests to fail. Until new JIRA
> GEODE-7250 is fixed we will not be testing 1.10.0 as an old version. This
> JIRA needs to be prioritized and the PR with the fix needs to include the
> revert changes to get 1.10.0 back in the old versions.
>
> Let me know if anyone has questions on these.
>
> -Dick
>

Lingering Geode 1.10.0 release issues

[Dick Cavender]

If you try and brew update to Geode 1.10.0 you won't get it until our
1.10.0 homebrew PR  gets
through their checks and their Jenkins servers seem to be having problems
this week so this is still in flight.

On geode develop I've had to revert the "add 1.10.0 to old versions" post
release change because it was causing tests to fail. Until new JIRA
GEODE-7250 is fixed we will not be testing 1.10.0 as an old version. This
JIRA needs to be prioritized and the PR with the fix needs to include the
revert changes to get 1.10.0 back in the old versions.

Let me know if anyone has questions on these.

-Dick

Re: ssl configuration parameters

[Mario Kevo]

A correction is needed here, this seems to actually work. The catch is
that if a JmxOperationInvoker is created from a client with a “ssl-
enabled-components” scope broader than the one defined on the locators
and servers, it seems to override it “cluster” scope. Is this behavior
expected?
 

On Thu, 2019-09-26 at 19:21 +, Mario Kevo wrote:
> Hi geode dev,
>  
> We would need to clarify the meaning of some ssl configuration
> parameters. When the flag “ssl-enabled-components” is set to
> “cluster”,
> our understanding is that this means geode would enforce SSL only
> between members of the same distributedSystem (same site). This would
> imply that communication between sites (gateway communication and
> site2site locator communication) wouldn’t be encrypted with ssl? Is
> this understanding correct?
>  
> If so, the behavior seems to differ: locator2locator communication
> between 2 sites/distributed systems fails if their certificates
> aren’t
> properly configured, meaning that ssl is still enforced in that
> communication.
> 
> Thanks,
> Mario