Re: [DISCUSS] Criteria for PMC, committers

[Dan Smith]

One concern I have about not bundling committer and PMC membership is that
there is not much incentive to nominate someone to become a PMC member.
When someone is an active contributor but not a committer it's visible in
the fact that they have to ask others to merge their PRs, which also
provides incentive to nominate them. But once they are a committer it's not
really obvious that someone is not also a PMC member, so there is no
reminder to nominate them for the next step.

For that reason I think we should continue bundling the two.

I'm also concerned with the "mateship bias" that Udo described. I do think
evidence of good judgement and a sense of responsibility is much more
important than the code that a nominee writes, and that's much easier to
judge if you have more contact with them. But maybe we can look for that
evidence specifically in the mailing list and PR comments?

-Dan

On Tue, Jun 4, 2019 at 2:59 PM Mark Bretl  wrote:

> I think in any point of view we are looking at Committer or PMC membership,
> it does come down to merit. Does the person have the merit, which can also
> be trust, to be a Committer and/or PMC member?
>
> The difference between Committer and PMC member is not simply being
> 'gatekeepers' of the codebase, PMC members provide oversight to the entire
> project [1], which I cannot put the same responsibility on a Committer. I
> don't think there has to a promotion path in terms of Committer -> PMC,
> however, I do believe there is a distinction between the two, especially
> since it is the Apache Board which ultimately makes the decision for PMC
> membership. A candidate be nominated for both at one time, but then it
> would be an all or nothing vote.
>
> --Mark
>
> [1]: https://www.apache.org/foundation/governance/pmcs.html
>
> On Fri, May 31, 2019 at 3:17 PM Jacob Barrett  wrote:
>
> > I think it's a lot of what is under the contributing section, but I think
> > it needs to be cleaned up. A lot of the what should be done is lost under
> > the screen shots of things. I nice clear bullet point, with maybe links
> to
> > the wiki for details, would be nice. If we collected all of this in the
> > CONTRIBUTING.md its right there in your source and baked into GitHub,
> which
> > is the primary place developers go, not the wiki. Then our PR template
> > could just say something like “[ ] complies with contributing
> guidelines”.
> > Eh??
> >
> > -Jake
> >
> >
> > > On May 31, 2019, at 3:12 PM, Anthony Baker  wrote:
> > >
> > > Are you thinking in terms of something like this?
> > > https://cwiki.apache.org/confluence/display/GEODE/Code+of+Conduct <
> > https://cwiki.apache.org/confluence/display/GEODE/Code+of+Conduct>
> > >
> > > Or something more specific to coding tasks?
> > >
> > >
> > > Thanks,
> > > Anthony
> > >
> > >
> > >> On May 31, 2019, at 2:41 AM, Owen Nichols 
> wrote:
> > >>
> > >> I think it might be helpful to first define clearly what code of
> > conduct a committer is expected to follow.  That exercise would help
> frame
> > exactly what we are trusting new (and existing) committers to adhere to.
> > >
> >
> >
>

Re: what is the best way to update a geode pull request

[Kirk Lund]

+1 for doing whatever facilitates reviewing and is best for the PR (which
may vary by PR or even reviewers)
-1 to disallowing or even strongly discouraging force pushing in a PR (go
ahead and merge or rebase as each person prefers but don't force that
preference on others)

I prefer to separate cleanup/refactor commits from behavior change commits
but I accept that it's on a per-case or per-author basis. I care more about
cleaning up code and adding unit tests than making the reviewing easier.

On Fri, May 31, 2019 at 5:32 PM Aaron Lindsey  wrote:

> +1 to updating the PR template. I've noticed that few people actually
> follow it and sometimes they just remove it altogether.
> +1 to pushing PR changes as separate commits. This makes PR review easier.
>
> Sometimes it's helpful to me as a reviewer for the initial PR to be split
> into multiple commits as well. Also, I like Robert's suggestion of merge
> instead of rebase when the PR is out-of-date with develop.
>
> - Aaron
>
>
> On Fri, May 31, 2019 at 2:50 PM Jacob Barrett  wrote:
>
> >
> >
> > > On May 31, 2019, at 2:40 PM, Udo Kohlmeyer  wrote:
> > >
> > > If we are concerned about the single line that can break the product,
> > then our testing has failed us on so many levels, that there is no hope.
> >
> > Sorry, I used a hyperbolic statement about looking for 1 line out of
> 1000.
> > The point was “formatting” or “cleanup” style commits are better left
> > separate because looking for the real change in that sea of change is
> hard.
> >
> > > But looking forward to see how long one can sustain the "factor ->
> > commit -> make changes required to fulfill JIRA -> commit -> manual
> merge"…
> >
> > It’s only a problem if you are cleaning up lots a code. Not a bad problem
> > to have and the future looks brighter each time.
> >
> > > Also, who reviews the refactor, because even that can introduce
> > unintentional bugs... same effort as single commit. In single commit, if
> > the refactor has made code cleaner, clearer and simpler, maybe 1 commit
> is
> > easier to follow.
> >
> > I think there is a distinction between a refactor and cleanup. Consider
> > the time we decide to reformat all the code, that was a cleanup. Now as
> we
> > are going through the code and IJ reports every other line as a static
> > analyzer warning, fixing that is a cleanup. All these cleanups have been
> > reviews like any other PR. Th point being made was that they are done in
> a
> > way that allows the reviewer to review the clean and the change
> > independently.
> >
> > A refactor would would be a complete reorganization of code and should
> > have the tests, reviews, etc. that go with it.
> >
> > Regardless, all are reviewed.
> >
> > -Jake
> >
> >
>

Re: [DISCUSS] require reviews before merging a PR

[Kirk Lund]

I'm -1 for requiring N reviews before merging a commit.

Overall, I support Lazy Consensus. If I post a PR that fixes the flakiness
in a test, the precheckin jobs prove it, and it sits there for 2 weeks
without reviews, then I favor merging it in at that point without any
reviews. I'm not going to chase people around or spam the dev list over and
over asking for reviews. Nothing in the Apache Way says you have to do
reviews before committing -- some projects prefer "commit then review"
instead of "review then commit". You can always look at the code someone
changed and you can always change it further or revert it.

I think if we don't trust our committers then we have a bigger systemic
problem that becoming more strict about PR reviews isn not going to fix.

Overall, I also favor pairing/mobbing over reviews. Without being there
during the work, a reviewer lacks the context to understand why it was done
the way it was done.

If we cannot establish or maintain trust in committers, then I think we
should remove committer status from everyone and start over as a project,
proposing and accepting one committer at a time.

Instead of constraints on reviews, I would prefer to establish new criteria
for coding such as:
1) all classes touched in a PR must have a unit test created if none exists
2) all code touched in a PR must have unit test coverage (and possibly
integration test coverage) specific to the changes
3) all new classes must have full unit test coverage
4) all code touched in a PR must follow clean code principles (which would
obviously need defining on the wiki)

Then it becomes the responsibility of the author(s) and committer(s) of
that PR to ensure that the code and the PR follows the project's criteria
for code quality and test coverage. It also becomes easier to measure the
PRs of a non-committer to determine if we think they would make a good
committer (for example, do they adhere to clean code quality and unit
testing with mocks? -- along with any other criteria).

On Thu, May 30, 2019 at 3:51 PM Owen Nichols  wrote:

> It seems common for Geode PRs to get merged with only a single green
> checkmark in GitHub.
>
> According to https://www.apache.org/foundation/voting.html we should not
> be merging PRs with fewer than 3 green checkmarks.
>
> Consensus is a fundamental value in doing things The Apache Way.  A single
> +1 is not consensus.  Since we’re currently discussing what it takes to
> become a committer and what standards a committer is expected to uphold, it
> seems like a good time to review this policy.
>
> GitHub can be configured to require N reviews before a commit can be
> merged.  Should we enable this feature?
>
> -Owen
> VOTES ON CODE MODIFICATION <
> https://www.apache.org/foundation/voting.html#votes-on-code-modification>
> For code-modification votes, +1 votes are in favour of the proposal, but
> -1 votes are vetos 
> and kill the proposal dead until all vetoers withdraw their -1 votes.
>
> Unless a vote has been declared as using lazy consensus <
> https://www.apache.org/foundation/voting.html#LazyConsensus> , three +1
> votes are required for a code-modification proposal to pass.
>
> Whole numbers are recommended for this type of vote, as the opinion being
> expressed is Boolean: 'I approve/do not approve of this change.'
>
>
> CONSENSUS GAUGING THROUGH SILENCE <
> https://www.apache.org/foundation/voting.html#LazyConsensus>
> An alternative to voting that is sometimes used to measure the
> acceptability of something is the concept of lazy consensus <
> https://www.apache.org/foundation/glossary.html#LazyConsensus>.
>
> Lazy consensus is simply an announcement of 'silence gives assent.’ When
> someone wants to determine the sense of the community this way, it might do
> so with a mail message such as:
> "The patch below fixes GEODE-12345; if no-one objects within three days,
> I'll assume lazy consensus and commit it."
>
> Lazy consensus cannot be used on projects that enforce a
> review-then-commit <
> https://www.apache.org/foundation/glossary.html#ReviewThenCommit> policy.
>
>
>

Re: [DISCUSS] Disable merge for failing pull requests

[Jacob Barrett]

I’m still not interested until there is a solution for all community members to 
retrigger failed jobs. Also not excited about not having a way to override if 
there is a known issue that prevents a job from going green. My last PR needed 
multiple reruns because of a known flakey test with an active ticket. While 
mine eventually went green on its own it would have been annoying to keep 
hitting a retrigger. 

-jake


> On Jun 4, 2019, at 4:06 PM, Owen Nichols  wrote:
> 
> I’d like to follow up on this discussion from late last year.  Six months 
> ago, Kirk wrote:
> 
>> After we get it more consistently GREEN, I would be willing to change my 
>> vote to +1.
> 
> While we’re still not perfect, I have noticed that PR checks go green much 
> more consistently now than they did six months ago.  Also, Ryan wrote:
> 
 I think we'd need clear guidelines on what to do if your PR fails due 
 to something seemingly unrelated.
> 
> 
> If you still encounter a flaky failure occasionally, you can either 
> re-trigger all checks with an empty commit, or just ask on the dev list and 
> someone will be happy to help you re-trigger only your failed check.
> 
> 
> The above concerns were commonly cited as reasons for not moving ahead with 
> the proposal to enable GitHub policy to disable merge button until checks 
> have passed.  Even with these addressed, there is still a “people over 
> process” argument to be made for not imposing an enforced process (see recent 
> thread that rejected imposing a requirement of >0 reviews before allowing 
> merge).
> 
> 
> So, is there any interest at all in tightening GitHub controls?  Or maybe a 
> better way to approach the question is: are we Very Happy with our current 
> source control practices?
> 
> -Owen
> 
>> On Dec 26, 2018, at 4:03 PM, Kirk Lund  wrote:
>> 
>> I'm changing my vote to -1 for disallowing merge until precheck passes.
>> 
>> The reason is that it's rare for me to see a 100% clean precheckin for any
>> of my PRs. There seems to always be some failure unrelated to my PR. For
>> example PR #3042 just hit GEODE-6008. If we make the change to disable the
>> merge button, then my PR could potentially be blocked indefinitely.
>> 
>> After we get it more consistently GREEN, I would be willing to change my
>> vote to +1.
>> 
>>> On Fri, Dec 21, 2018 at 10:36 AM Kirk Lund  wrote:
>>> 
>>> I was responding to Udo's comment:
>>> 
>>> "Could one not configure the button that the owner of the PR cannot merge
>>> the PR?"
>>> 
>>> I'm +1 for disallowing merge until precheck passes.
>>> I'm -1 for disallowing the owner of the PR to merge it.
>>> 
 On Fri, Dec 21, 2018 at 9:28 AM Helena Bales  wrote:
 
 Kirk, this change would not require you to get someone to merge it. It
 would just require that your PR pass CI before it can be merged.
 
> On Thu, Dec 20, 2018 at 2:38 PM Kirk Lund  wrote:
> 
> I have enough trouble just getting other developers to review my PR. I
> don't want to have to struggle to find someone to merge it for me, too.
> 
>> On Mon, Nov 19, 2018 at 4:09 PM Udo Kohlmeyer  wrote:
>> 
>> I don't believe "name and shame" is a hammer we should wield, but if
 we
>> have use it... use it wisely
>> 
>> Could one not configure the button that the owner of the PR cannot
 merge
>> the PR?
>> 
>> --Udo
>> 
>> 
>>> On 11/19/18 16:03, Dan Smith wrote:
>>> Closing the loop on this thread - I don't feel like there was enough
>>> agreement to go forwards with disabling the merge button, so I'm
 going
> to
>>> drop this for now.
>>> 
>>> I would like to see everyone make sure that they only merge green
 PRs.
>>> Maybe we can go with a name and shame approach? As in, we shouldn't
 see
>> any
>>> new PRs show up in this query:
>>> 
>>> 
>> 
> 
 https://github.com/apache/geode/pulls?utf8=%E2%9C%93=is%3Apr+is%3Amerged+status%3Afailure
>>> 
>>> -Dan
>>> 
>>> On Tue, Nov 13, 2018 at 10:19 AM Ryan McMahon 
>> wrote:
>>> 
 +1 I like this idea, but I recognize that it will be a challenge
 when
>> there
 is still some flakiness to the pipeline.  I think we'd need clear
 guidelines on what to do if your PR fails due to something
 seemingly
 unrelated.  For instance, we ran into GEODE-5943 (flaky
>> EvictionDUnitTest)
 in our last PR, and saw that there was already an open ticket for
 the
 flakiness (we even reverted our change and reproduced to be
 sure).  So
>> we
 triggered another PR pipeline and it passed the second time.  Is
>> rerunning
 the pipeline again sufficient in this case?  Or should we have
 stopped
>> what
 we were doing and took up GEODE-5943, assuming it wasn't assigned
 to
 someone?  If it was already assigned to someone, do we wait until
 

Re: [DISCUSS] Disable merge for failing pull requests

[Owen Nichols]

I’d like to follow up on this discussion from late last year.  Six months ago, 
Kirk wrote:

> After we get it more consistently GREEN, I would be willing to change my vote 
> to +1.

While we’re still not perfect, I have noticed that PR checks go green much more 
consistently now than they did six months ago.  Also, Ryan wrote:

>>>  I think we'd need clear guidelines on what to do if your PR fails due 
>>> to something seemingly unrelated.


If you still encounter a flaky failure occasionally, you can either re-trigger 
all checks with an empty commit, or just ask on the dev list and someone will 
be happy to help you re-trigger only your failed check.


The above concerns were commonly cited as reasons for not moving ahead with the 
proposal to enable GitHub policy to disable merge button until checks have 
passed.  Even with these addressed, there is still a “people over process” 
argument to be made for not imposing an enforced process (see recent thread 
that rejected imposing a requirement of >0 reviews before allowing merge).


So, is there any interest at all in tightening GitHub controls?  Or maybe a 
better way to approach the question is: are we Very Happy with our current 
source control practices?

-Owen

> On Dec 26, 2018, at 4:03 PM, Kirk Lund  wrote:
> 
> I'm changing my vote to -1 for disallowing merge until precheck passes.
> 
> The reason is that it's rare for me to see a 100% clean precheckin for any
> of my PRs. There seems to always be some failure unrelated to my PR. For
> example PR #3042 just hit GEODE-6008. If we make the change to disable the
> merge button, then my PR could potentially be blocked indefinitely.
> 
> After we get it more consistently GREEN, I would be willing to change my
> vote to +1.
> 
> On Fri, Dec 21, 2018 at 10:36 AM Kirk Lund  wrote:
> 
>> I was responding to Udo's comment:
>> 
>> "Could one not configure the button that the owner of the PR cannot merge
>> the PR?"
>> 
>> I'm +1 for disallowing merge until precheck passes.
>> I'm -1 for disallowing the owner of the PR to merge it.
>> 
>> On Fri, Dec 21, 2018 at 9:28 AM Helena Bales  wrote:
>> 
>>> Kirk, this change would not require you to get someone to merge it. It
>>> would just require that your PR pass CI before it can be merged.
>>> 
>>> On Thu, Dec 20, 2018 at 2:38 PM Kirk Lund  wrote:
>>> 
 I have enough trouble just getting other developers to review my PR. I
 don't want to have to struggle to find someone to merge it for me, too.
 
 On Mon, Nov 19, 2018 at 4:09 PM Udo Kohlmeyer  wrote:
 
> I don't believe "name and shame" is a hammer we should wield, but if
>>> we
> have use it... use it wisely
> 
> Could one not configure the button that the owner of the PR cannot
>>> merge
> the PR?
> 
> --Udo
> 
> 
> On 11/19/18 16:03, Dan Smith wrote:
>> Closing the loop on this thread - I don't feel like there was enough
>> agreement to go forwards with disabling the merge button, so I'm
>>> going
 to
>> drop this for now.
>> 
>> I would like to see everyone make sure that they only merge green
>>> PRs.
>> Maybe we can go with a name and shame approach? As in, we shouldn't
>>> see
> any
>> new PRs show up in this query:
>> 
>> 
> 
 
>>> https://github.com/apache/geode/pulls?utf8=%E2%9C%93=is%3Apr+is%3Amerged+status%3Afailure
>> 
>> -Dan
>> 
>> On Tue, Nov 13, 2018 at 10:19 AM Ryan McMahon 
> wrote:
>> 
>>> +1 I like this idea, but I recognize that it will be a challenge
>>> when
> there
>>> is still some flakiness to the pipeline.  I think we'd need clear
>>> guidelines on what to do if your PR fails due to something
>>> seemingly
>>> unrelated.  For instance, we ran into GEODE-5943 (flaky
> EvictionDUnitTest)
>>> in our last PR, and saw that there was already an open ticket for
>>> the
>>> flakiness (we even reverted our change and reproduced to be
>>> sure).  So
> we
>>> triggered another PR pipeline and it passed the second time.  Is
> rerunning
>>> the pipeline again sufficient in this case?  Or should we have
>>> stopped
> what
>>> we were doing and took up GEODE-5943, assuming it wasn't assigned
>>> to
>>> someone?  If it was already assigned to someone, do we wait until
>>> that
> bug
>>> is fixed before we run through the PR pipeline again?
>>> 
>>> I think if anything this will help us treat bugs that are causing a
 red
>>> pipeline as critical, and I think that is a good thing.  So I'm
>>> still
 +1
>>> despite the flakiness.  Just curious what people think about how we
> should
>>> handle cases where there is a known failure and it is indeed
>>> unrelated
> to
>>> our PR.
>>> 
>>> Ryan
>>> 
>>> 
>>> On Mon, Nov 12, 2018 at 2:49 PM Jinmei Liao 
 wrote:
>>> 
 Just to clarify, that flaky EvictionDUnitTest is old 

Re: [DISCUSS] Criteria for PMC, committers

[Mark Bretl]

I think in any point of view we are looking at Committer or PMC membership,
it does come down to merit. Does the person have the merit, which can also
be trust, to be a Committer and/or PMC member?

The difference between Committer and PMC member is not simply being
'gatekeepers' of the codebase, PMC members provide oversight to the entire
project [1], which I cannot put the same responsibility on a Committer. I
don't think there has to a promotion path in terms of Committer -> PMC,
however, I do believe there is a distinction between the two, especially
since it is the Apache Board which ultimately makes the decision for PMC
membership. A candidate be nominated for both at one time, but then it
would be an all or nothing vote.

--Mark

[1]: https://www.apache.org/foundation/governance/pmcs.html

On Fri, May 31, 2019 at 3:17 PM Jacob Barrett  wrote:

> I think it's a lot of what is under the contributing section, but I think
> it needs to be cleaned up. A lot of the what should be done is lost under
> the screen shots of things. I nice clear bullet point, with maybe links to
> the wiki for details, would be nice. If we collected all of this in the
> CONTRIBUTING.md its right there in your source and baked into GitHub, which
> is the primary place developers go, not the wiki. Then our PR template
> could just say something like “[ ] complies with contributing guidelines”.
> Eh??
>
> -Jake
>
>
> > On May 31, 2019, at 3:12 PM, Anthony Baker  wrote:
> >
> > Are you thinking in terms of something like this?
> > https://cwiki.apache.org/confluence/display/GEODE/Code+of+Conduct <
> https://cwiki.apache.org/confluence/display/GEODE/Code+of+Conduct>
> >
> > Or something more specific to coding tasks?
> >
> >
> > Thanks,
> > Anthony
> >
> >
> >> On May 31, 2019, at 2:41 AM, Owen Nichols  wrote:
> >>
> >> I think it might be helpful to first define clearly what code of
> conduct a committer is expected to follow.  That exercise would help frame
> exactly what we are trusting new (and existing) committers to adhere to.
> >
>
>

Re: Static Analysis Tools such as SonarQube or others?

[Charlie Black]

I used SonarQube on a project it helped the team where to focus on next.
 The reports that it generates are extremely useful to help see how the
code progresses over time across the many dimensions.


On Tue, Jun 4, 2019 at 12:46 PM Mark Bretl  wrote:

> I have used SonarQube for many years, including integrating for the Geode
> codebase in the past and using it now my current day job, and like it a
> lot. The ASF hosts a server at https://builds.apache.org/analysis/,
> however, the version is quite old and does not have features such as
> Quality Gating or PR decoration. There is now a cloud version at
> https://sonarcloud.io, which is free for open source projects.
>
> As Dan said, in order to make them productive, they need to be integrated
> into the CI pipeline or the issues will end up as noise.
>
> --Mark
>
> On Tue, Jun 4, 2019 at 11:30 AM Dan Smith  wrote:
>
> > We're currently running PMD as part of the gradle build. PMD is just
> > running a couple of rules specifically to look for mutable statics. We've
> > also enabled integration with lgtm to get a report -
> > https://lgtm.com/projects/g/apache/geode/.
> > 
> >
> > I think added more static analysis is a good idea. I'm not that
> particular
> > about which tool(s) we are using - although maybe we should focus on open
> > source tools? I do think that in order to be valuable, the static
> analysis
> > rules need to fail the build like we're doing with spotless and PMD. So I
> > think an approach of cleaning up and enforcing one rule at a time is
> better
> > than just generating a report with a bunch of rule violations.
> >
> > -Dan
> >
> >
> > On Tue, Jun 4, 2019 at 6:56 AM Peter Tran  wrote:
> >
> > > Hi all,
> > >
> > > Has anyone had experience using static analysis tools such as
> SonarQube?
> > > Were there helpful? And favourites that worked well?
> > >
> > > Thanks
> > >
> >
>


-- 
Charlie Black | cbl...@pivotal.io

Re: [PROPOSAL] Add hostname-for-clients to ConfigurationProperties

[Jinmei Liao]

Thanks for the feedback. Both Dan and Juan pointed out how the
hostname-for-clients are configured for each individual components
currently:  server/locator/gateway receivers are from gfsh commands options
and jmx are from gemfire properties. Let me revise my original proposal to:
Let's add a global property "hostname-for-clients" in the geode properties
that will be the default value if not overridden by those specific
configurations.

Thanks!

On Tue, Jun 4, 2019 at 1:14 PM Juan José Ramos  wrote:

> Hello Jinmei,
>
> Applying this change will prevent users from using different NICs for
> different types of traffic, meaning that the same server won't be able to
> listen for JMX connections on *NIC1* and regular client-server connections
> on *NIC2*, right?. If my assumption is correct then we'd be removing an
> existing cool feature from the product, so my vote would be -1.
> Cheers.
>
>
> On Tue, Jun 4, 2019 at 9:06 PM Dan Smith  wrote:
>
> > A user can configure the hostname-for-clients for locators and gateway
> > receivers - they are part of the respective gfsh commands. Are you
> > suggesting deprecating those settings as well, or just having a global
> > property that is the default value if it is not overridden for a specific
> > locator, cache-server, or gateway-receiver?
> >
> > -Dan
> >
> > On Tue, Jun 4, 2019 at 12:02 PM Jinmei Liao  wrote:
> >
> > > We have "jmx-manager-hostname-for-clients" in the geode properties, we
> > > think it would be a good idea to deprecate that and use
> > > "hostname-for-clients" for the entire server. Currently we already need
> > > this property when launching a locator and start a gateway-receiver,
> and
> > we
> > > have no way to pre-configure them.
> > >
> > > This is first step towards fixing our current problem of cluster
> > > configuration prescribing specific hostname-for-senders for gateway
> > > receivers.
> > >
> > > Thoughts/comments?
> > >
> >
>
>
> --
> Juan José Ramos Cassella
> Senior Technical Support Engineer
> Email: jra...@pivotal.io
> Office#: +353 21 4238611
> Mobile#: +353 87 2074066
> After Hours Contact#: +1 877 477 2269
> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> How to upload artifacts:
> https://support.pivotal.io/hc/en-us/articles/204369073
> How to escalate a ticket:
> https://support.pivotal.io/hc/en-us/articles/203809556
>
> [image: support]  [image: twitter]
>  [image: linkedin]
>  [image: facebook]
>  [image: google plus]
>  [image: youtube]
> 
>


-- 
Cheers

Jinmei

Re: [PROPOSAL] Add hostname-for-clients to ConfigurationProperties

[Juan José Ramos]

Hello Jinmei,

Applying this change will prevent users from using different NICs for
different types of traffic, meaning that the same server won't be able to
listen for JMX connections on *NIC1* and regular client-server connections
on *NIC2*, right?. If my assumption is correct then we'd be removing an
existing cool feature from the product, so my vote would be -1.
Cheers.


On Tue, Jun 4, 2019 at 9:06 PM Dan Smith  wrote:

> A user can configure the hostname-for-clients for locators and gateway
> receivers - they are part of the respective gfsh commands. Are you
> suggesting deprecating those settings as well, or just having a global
> property that is the default value if it is not overridden for a specific
> locator, cache-server, or gateway-receiver?
>
> -Dan
>
> On Tue, Jun 4, 2019 at 12:02 PM Jinmei Liao  wrote:
>
> > We have "jmx-manager-hostname-for-clients" in the geode properties, we
> > think it would be a good idea to deprecate that and use
> > "hostname-for-clients" for the entire server. Currently we already need
> > this property when launching a locator and start a gateway-receiver, and
> we
> > have no way to pre-configure them.
> >
> > This is first step towards fixing our current problem of cluster
> > configuration prescribing specific hostname-for-senders for gateway
> > receivers.
> >
> > Thoughts/comments?
> >
>


-- 
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jra...@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556

[image: support]  [image: twitter]
 [image: linkedin]
 [image: facebook]
 [image: google plus]
 [image: youtube]

Re: [PROPOSAL] Add hostname-for-clients to ConfigurationProperties

[Dan Smith]

A user can configure the hostname-for-clients for locators and gateway
receivers - they are part of the respective gfsh commands. Are you
suggesting deprecating those settings as well, or just having a global
property that is the default value if it is not overridden for a specific
locator, cache-server, or gateway-receiver?

-Dan

On Tue, Jun 4, 2019 at 12:02 PM Jinmei Liao  wrote:

> We have "jmx-manager-hostname-for-clients" in the geode properties, we
> think it would be a good idea to deprecate that and use
> "hostname-for-clients" for the entire server. Currently we already need
> this property when launching a locator and start a gateway-receiver, and we
> have no way to pre-configure them.
>
> This is first step towards fixing our current problem of cluster
> configuration prescribing specific hostname-for-senders for gateway
> receivers.
>
> Thoughts/comments?
>

Re: Static Analysis Tools such as SonarQube or others?

[Mark Bretl]

I have used SonarQube for many years, including integrating for the Geode
codebase in the past and using it now my current day job, and like it a
lot. The ASF hosts a server at https://builds.apache.org/analysis/,
however, the version is quite old and does not have features such as
Quality Gating or PR decoration. There is now a cloud version at
https://sonarcloud.io, which is free for open source projects.

As Dan said, in order to make them productive, they need to be integrated
into the CI pipeline or the issues will end up as noise.

--Mark

On Tue, Jun 4, 2019 at 11:30 AM Dan Smith  wrote:

> We're currently running PMD as part of the gradle build. PMD is just
> running a couple of rules specifically to look for mutable statics. We've
> also enabled integration with lgtm to get a report -
> https://lgtm.com/projects/g/apache/geode/.
> 
>
> I think added more static analysis is a good idea. I'm not that particular
> about which tool(s) we are using - although maybe we should focus on open
> source tools? I do think that in order to be valuable, the static analysis
> rules need to fail the build like we're doing with spotless and PMD. So I
> think an approach of cleaning up and enforcing one rule at a time is better
> than just generating a report with a bunch of rule violations.
>
> -Dan
>
>
> On Tue, Jun 4, 2019 at 6:56 AM Peter Tran  wrote:
>
> > Hi all,
> >
> > Has anyone had experience using static analysis tools such as SonarQube?
> > Were there helpful? And favourites that worked well?
> >
> > Thanks
> >
>

[PROPOSAL] Add hostname-for-clients to ConfigurationProperties

[Jinmei Liao]

We have "jmx-manager-hostname-for-clients" in the geode properties, we
think it would be a good idea to deprecate that and use
"hostname-for-clients" for the entire server. Currently we already need
this property when launching a locator and start a gateway-receiver, and we
have no way to pre-configure them.

This is first step towards fixing our current problem of cluster
configuration prescribing specific hostname-for-senders for gateway
receivers.

Thoughts/comments?

Re: Static Analysis Tools such as SonarQube or others?

[Dan Smith]

We're currently running PMD as part of the gradle build. PMD is just
running a couple of rules specifically to look for mutable statics. We've
also enabled integration with lgtm to get a report -
https://lgtm.com/projects/g/apache/geode/.


I think added more static analysis is a good idea. I'm not that particular
about which tool(s) we are using - although maybe we should focus on open
source tools? I do think that in order to be valuable, the static analysis
rules need to fail the build like we're doing with spotless and PMD. So I
think an approach of cleaning up and enforcing one rule at a time is better
than just generating a report with a bunch of rule violations.

-Dan


On Tue, Jun 4, 2019 at 6:56 AM Peter Tran  wrote:

> Hi all,
>
> Has anyone had experience using static analysis tools such as SonarQube?
> Were there helpful? And favourites that worked well?
>
> Thanks
>

Re: Is the documentation wrong here?

[Dave Barnes]

@liyuj Congratulations on finding a Geode doc bug. To get the problem on
the official "to do" list, you are hereby encouraged to open a JIRA ticket
in the Geode project, citing the 'docs' component. Your original email with
Jared's response would serve well as the bug description.

If you'd like to, you can then edit the doc source and submit the fix as a
pull request. If not, just filing the JIRA ticket is a good start toward
getting the problem fixed.

On Tue, Jun 4, 2019 at 9:29 AM Jared Stewart 
wrote:

> Yes, I believe the docs there are out of date and need to be updated.  This
> change in the naming of deployed jars was introduced in Geode 1.2 by
> https://github.com/apache/geode/pull/429.
>
> On Tue, Jun 4, 2019 at 7:27 AM liyuj <18624049...@163.com> wrote:
>
> > Hi,
> >
> >
> >
> https://geode.apache.org/docs/guide/19/configuring/cluster_config/deploying_application_jars.html
> >
> > This document has such a paragraph:
> >
> >
> > Versioning of JAR Files
> >
> > When you deploy JAR files to a cluster or member group, the JAR file is
> > modified to indicate version information in its name. Each JAR filename
> > is prefixed with|vf.gf#|and  
> contains a version
> > number at the end of the
> > filename. For example, if you deploy|MyClasses.jar|five times, the
> > filename is displayed as|vf.gf#MyClasses.jar#5|when
> 
> >  you list all
> > deployed jars.
> >
> > but,in my environment, it is shown as follows:
> >
> > gfsh>list deployed
> > Member  |  JAR   | JAR Location
> > --- | -- |
> > ---
> > server1 | ra.jar | /media/liyujue/data/geode/server1/ra.v1.jar
> > server1 | mx4j-3.0.2.jar |
> > /media/liyujue/data/geode/server1/mx4j-3.0.2.v1.jar
> > server2 | ra.jar | /media/liyujue/data/geode/server2/ra.v1.jar
> > server2 | mx4j-3.0.2.jar |
> > /media/liyujue/data/geode/server2/mx4j-3.0.2.v1.jar
> >
> > Is the documentation wrong here?
> >
> >
>

Re: Is the documentation wrong here?

[Jared Stewart]

Yes, I believe the docs there are out of date and need to be updated.  This
change in the naming of deployed jars was introduced in Geode 1.2 by
https://github.com/apache/geode/pull/429.

On Tue, Jun 4, 2019 at 7:27 AM liyuj <18624049...@163.com> wrote:

> Hi,
>
>
> https://geode.apache.org/docs/guide/19/configuring/cluster_config/deploying_application_jars.html
>
> This document has such a paragraph:
>
>
> Versioning of JAR Files
>
> When you deploy JAR files to a cluster or member group, the JAR file is
> modified to indicate version information in its name. Each JAR filename
> is prefixed with|vf.gf#|and  contains a version
> number at the end of the
> filename. For example, if you deploy|MyClasses.jar|five times, the
> filename is displayed as|vf.gf#MyClasses.jar#5|when
>  you list all
> deployed jars.
>
> but,in my environment, it is shown as follows:
>
> gfsh>list deployed
> Member  |  JAR   | JAR Location
> --- | -- |
> ---
> server1 | ra.jar | /media/liyujue/data/geode/server1/ra.v1.jar
> server1 | mx4j-3.0.2.jar |
> /media/liyujue/data/geode/server1/mx4j-3.0.2.v1.jar
> server2 | ra.jar | /media/liyujue/data/geode/server2/ra.v1.jar
> server2 | mx4j-3.0.2.jar |
> /media/liyujue/data/geode/server2/mx4j-3.0.2.v1.jar
>
> Is the documentation wrong here?
>
>

Is the documentation wrong here?

[liyuj]

Hi,

https://geode.apache.org/docs/guide/19/configuring/cluster_config/deploying_application_jars.html

This document has such a paragraph:


   Versioning of JAR Files

When you deploy JAR files to a cluster or member group, the JAR file is 
modified to indicate version information in its name. Each JAR filename 
is prefixed with|vf.gf#|and contains a version number at the end of the 
filename. For example, if you deploy|MyClasses.jar|five times, the 
filename is displayed as|vf.gf#MyClasses.jar#5|when you list all 
deployed jars.


but,in my environment, it is shown as follows:

gfsh>list deployed
Member  |  JAR   | JAR Location
--- | -- | 
---

server1 | ra.jar | /media/liyujue/data/geode/server1/ra.v1.jar
server1 | mx4j-3.0.2.jar | 
/media/liyujue/data/geode/server1/mx4j-3.0.2.v1.jar

server2 | ra.jar | /media/liyujue/data/geode/server2/ra.v1.jar
server2 | mx4j-3.0.2.jar | 
/media/liyujue/data/geode/server2/mx4j-3.0.2.v1.jar


Is the documentation wrong here?

Static Analysis Tools such as SonarQube or others?

[Peter Tran]

Hi all,

Has anyone had experience using static analysis tools such as SonarQube?
Were there helpful? And favourites that worked well?

Thanks