Need "edit" access to update Network Best Practices page

[Tod Morrison]

Hello,

I need *edit* access to 
https://cwiki.apache.org/confluence/display/GEODE/Network+Configuration+Best+Practices
 

 to update it with some current findings.

Let me know how to proceed.

Thanks,

Tod Morrison  |  Principal Customer Engineer - GemFire Support Lead
Support.Pivotal.io   |  Mon-Fri  9:00am to 5:30pm 
MT  |  1-877-477-2269

Re: Need "edit" access to update Network Best Practices page

[Kirk Lund]

Hi Tod, What's your wiki account name?

On Wed, Nov 1, 2017 at 11:39 PM, Tod Morrison  wrote:

> Hello,
>
> I need *edit* access to https://cwiki.apache.org/confluence/display/GEODE/
> Network+Configuration+Best+Practices to update it with some current
> findings.
>
> Let me know how to proceed.
>
> Thanks,
>
> Tod Morrison  |  Principal Customer Engineer - GemFire Support Lead
> Support.Pivotal.io   |  Mon-Fri  9:00am to
> 5:30pm MT  |  1-877-477-2269 <(877)%20477-2269>
>
>
>

Re: [DISCUSS] CI improvements

[Anthony Baker]

If you’d like to check this out, here’s the PR containing the pipeline and job 
scripts:
https://github.com/apache/geode/pull/1006

And the pipeline itself:
https://concourse.apachegeode-ci.info

There are three pipelines defined:

- develop:  runs `gradle build`.  Can be extended to include other precheckin 
tests based on feedback.
- docker-images: builds the container used for the develop pipeline.
- meta: watches for changes to the pipeline files and automatically updates the 
runtime pipelines.

Authentication is integrated with GitHub.  If you want the ability to manually 
stop/start jobs please request on the dev@g.a.o mailing list (same as for 
Jenkins) and include your GitHub id.

What do you think?

Anthony

> On Oct 6, 2017, at 7:08 AM, Anthony Baker  wrote:
> 
> Hi all,
> 
> I’d like to propose the following that we switch our continuous
> integration (CI) system from Jenkins [1] to Concourse [2].  I suggest
> this because we continue to experience a significant number of
> environmental-related test failures.
> 
> These issues include CPU interference from other Jenkins jobs on the
> same host, running out of disk space, port conflicts, and other
> gremlins.  The net effect is that we are only getting 1-2 successful
> builds per month.  Certainly not all test failures can be traced back
> to environmental issues.  However, internal testing on isolated VM’s
> shows a combined success rate of about 3X higher compared to ASF
> Jenkins for the same tests.  This is still definitely NotAwesome, but
> removing environmental factors will let us focus on stabilizing flaky
> tests.
> 
> Concourse is an Apache-licensed open source CI system based on
> pipelines.  The pipelines are defined in a YML file containing job
> definitions—inputs, outputs, resources, and tasks.  A task is simply a
> bash script that returns 0/1 for success/failure.  A web UI displays
> build status.  Importantly, each job runs inside an isolated
> container.  The containers are load-balanced across a pool of workers.
> For an example of a build pipeline, see [3] for the pipeline used to
> build concourse itself.
> 
> A Concourse environment is deployed and managed in cloud environments
> through bosh [4].  Pivotal has agreed to donate AWS and/or GCP compute
> and storage resources as well as manage the infrastructure.  These
> project resources would be available for use by all committers and
> community members regardless of corporate affiliations.  Note that
> AFAIK there is no explicit requirement to host CI on ASF
> infrastructure—unlike for critical project resources such as source
> code, mailing lists, and issue tracking.
> 
> The source for the pipeline and job scripts would reside within the
> geode-* repos.  Geode committers would be able to modify those, same
> as with our .travis.yml scripts.  All test results and build artifacts
> would be publicly viewable just like with our Jenkins build output
> today.  Requests for admin assistance would go through the dev@geode
> mailing list.
> 
> Thoughts?  As a first step we could run both CI systems side-by-side
> and see how the Concourse approach works for our project.
> 
> Thanks,
> Anthony
> 
> 
> [1] https://builds.apache.org/job/Geode-nightly/
> [2] https://concourse.ci
> [3] https://ci.concourse.ci
> [4] https://bosh.io

Failed: jinmeiliao/geode#64 (GEODE-1883 - 1d5f892)

[Travis CI]

Build Update for jinmeiliao/geode
-

Build: #64
Status: Failed

Duration: 9 minutes and 9 seconds
Commit: 1d5f892 (GEODE-1883)
Author: Jinmei Liao
Message: GEODE-1883: make auth-init optional

* Failed Tests:

CQClientAuthDunitTest. testPostProcess
ClientCQPostAuthorizationDUnitTest. testAllowCQForAllMultiusers
ClientCQPostAuthorizationDUnitTest. testAllowCQForAllMultiusersWithFailover
ClientCQPostAuthorizationDUnitTest. testDisallowCQForAllMultiusers
ClientCQPostAuthorizationDUnitTest. testDisallowCQForSomeMultiusers
ClientMultiUserAuthzDUnitTest. testOps1
ClientMultiUserAuthzDUnitTest. testOps2
ClientMultiUserAuthzDUnitTest. testOpsWithClientsInDifferentModes
MultiUserDurableCQAuthzDUnitTest. testCQForDurableClientsWithCloseKeepAliveFalse
MultiUserDurableCQAuthzDUnitTest. testCQForDurableClientsWithCloseKeepAliveTrue
MultiUserDurableCQAuthzDUnitTest. testCQForDurableClientsWithDefaultClose

View the changeset: https://github.com/jinmeiliao/geode/commit/1d5f892b31b5

View the full build log and details: 
https://travis-ci.org/jinmeiliao/geode/builds/296381581?utm_source=email&utm_medium=notification

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

Failed: jinmeiliao/geode#65 (GEODE-2153 - 2d09769)

[Travis CI]

Build Update for jinmeiliao/geode
-

Build: #65
Status: Failed

Duration: 10 minutes and 52 seconds
Commit: 2d09769 (GEODE-2153)
Author: Jinmei Liao
Message: field value query does not run through post processor

View the changeset: https://github.com/jinmeiliao/geode/commit/2d097691a54a

View the full build log and details: 
https://travis-ci.org/jinmeiliao/geode/builds/296381712?utm_source=email&utm_medium=notification

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

Re: Need "edit" access to update Network Best Practices page

[Bruce Schuchardt]

Wow - that page still refers to multicast discovery for cache servers.  
That's never been in Geode.



On 11/1/17 11:39 PM, Tod Morrison wrote:

Hello,

I need *edit* access to 
https://cwiki.apache.org/confluence/display/GEODE/Network+Configuration+Best+Practices to 
update it with some current findings.


Let me know how to proceed.

Thanks,

Tod Morrison  |  Principal Customer Engineer - GemFire Support Lead
Support.Pivotal.io |  Mon-Fri  9:00am to 
5:30pm MT  |  1-877-477-2269

Re: [DISCUSS] CI improvements

[Dan Smith]

Looks good. Should we go ahead and change this to run precheckin instead of
build?

-Dan

On Thu, Nov 2, 2017 at 9:53 AM, Anthony Baker  wrote:

> If you’d like to check this out, here’s the PR containing the pipeline and
> job scripts:
> https://github.com/apache/geode/pull/1006
>
> And the pipeline itself:
> https://concourse.apachegeode-ci.info
>
> There are three pipelines defined:
>
> - develop:  runs `gradle build`.  Can be extended to include other
> precheckin tests based on feedback.
> - docker-images: builds the container used for the develop pipeline.
> - meta: watches for changes to the pipeline files and automatically
> updates the runtime pipelines.
>
> Authentication is integrated with GitHub.  If you want the ability to
> manually stop/start jobs please request on the dev@g.a.o mailing list
> (same as for Jenkins) and include your GitHub id.
>
> What do you think?
>
> Anthony
>
> > On Oct 6, 2017, at 7:08 AM, Anthony Baker  wrote:
> >
> > Hi all,
> >
> > I’d like to propose the following that we switch our continuous
> > integration (CI) system from Jenkins [1] to Concourse [2].  I suggest
> > this because we continue to experience a significant number of
> > environmental-related test failures.
> >
> > These issues include CPU interference from other Jenkins jobs on the
> > same host, running out of disk space, port conflicts, and other
> > gremlins.  The net effect is that we are only getting 1-2 successful
> > builds per month.  Certainly not all test failures can be traced back
> > to environmental issues.  However, internal testing on isolated VM’s
> > shows a combined success rate of about 3X higher compared to ASF
> > Jenkins for the same tests.  This is still definitely NotAwesome, but
> > removing environmental factors will let us focus on stabilizing flaky
> > tests.
> >
> > Concourse is an Apache-licensed open source CI system based on
> > pipelines.  The pipelines are defined in a YML file containing job
> > definitions—inputs, outputs, resources, and tasks.  A task is simply a
> > bash script that returns 0/1 for success/failure.  A web UI displays
> > build status.  Importantly, each job runs inside an isolated
> > container.  The containers are load-balanced across a pool of workers.
> > For an example of a build pipeline, see [3] for the pipeline used to
> > build concourse itself.
> >
> > A Concourse environment is deployed and managed in cloud environments
> > through bosh [4].  Pivotal has agreed to donate AWS and/or GCP compute
> > and storage resources as well as manage the infrastructure.  These
> > project resources would be available for use by all committers and
> > community members regardless of corporate affiliations.  Note that
> > AFAIK there is no explicit requirement to host CI on ASF
> > infrastructure—unlike for critical project resources such as source
> > code, mailing lists, and issue tracking.
> >
> > The source for the pipeline and job scripts would reside within the
> > geode-* repos.  Geode committers would be able to modify those, same
> > as with our .travis.yml scripts.  All test results and build artifacts
> > would be publicly viewable just like with our Jenkins build output
> > today.  Requests for admin assistance would go through the dev@geode
> > mailing list.
> >
> > Thoughts?  As a first step we could run both CI systems side-by-side
> > and see how the Concourse approach works for our project.
> >
> > Thanks,
> > Anthony
> >
> >
> > [1] https://builds.apache.org/job/Geode-nightly/
> > [2] https://concourse.ci
> > [3] https://ci.concourse.ci
> > [4] https://bosh.io
>
>

Re: [DISCUSS] CI improvements

[Sean Goller]

Given the length of time precheckin seems to run, would it make sense to
break it up?

-Sean.

On Thu, Nov 2, 2017 at 11:49 AM, Dan Smith  wrote:

> Looks good. Should we go ahead and change this to run precheckin instead of
> build?
>
> -Dan
>
> On Thu, Nov 2, 2017 at 9:53 AM, Anthony Baker  wrote:
>
> > If you’d like to check this out, here’s the PR containing the pipeline
> and
> > job scripts:
> > https://github.com/apache/geode/pull/1006
> >
> > And the pipeline itself:
> > https://concourse.apachegeode-ci.info
> >
> > There are three pipelines defined:
> >
> > - develop:  runs `gradle build`.  Can be extended to include other
> > precheckin tests based on feedback.
> > - docker-images: builds the container used for the develop pipeline.
> > - meta: watches for changes to the pipeline files and automatically
> > updates the runtime pipelines.
> >
> > Authentication is integrated with GitHub.  If you want the ability to
> > manually stop/start jobs please request on the dev@g.a.o mailing list
> > (same as for Jenkins) and include your GitHub id.
> >
> > What do you think?
> >
> > Anthony
> >
> > > On Oct 6, 2017, at 7:08 AM, Anthony Baker  wrote:
> > >
> > > Hi all,
> > >
> > > I’d like to propose the following that we switch our continuous
> > > integration (CI) system from Jenkins [1] to Concourse [2].  I suggest
> > > this because we continue to experience a significant number of
> > > environmental-related test failures.
> > >
> > > These issues include CPU interference from other Jenkins jobs on the
> > > same host, running out of disk space, port conflicts, and other
> > > gremlins.  The net effect is that we are only getting 1-2 successful
> > > builds per month.  Certainly not all test failures can be traced back
> > > to environmental issues.  However, internal testing on isolated VM’s
> > > shows a combined success rate of about 3X higher compared to ASF
> > > Jenkins for the same tests.  This is still definitely NotAwesome, but
> > > removing environmental factors will let us focus on stabilizing flaky
> > > tests.
> > >
> > > Concourse is an Apache-licensed open source CI system based on
> > > pipelines.  The pipelines are defined in a YML file containing job
> > > definitions—inputs, outputs, resources, and tasks.  A task is simply a
> > > bash script that returns 0/1 for success/failure.  A web UI displays
> > > build status.  Importantly, each job runs inside an isolated
> > > container.  The containers are load-balanced across a pool of workers.
> > > For an example of a build pipeline, see [3] for the pipeline used to
> > > build concourse itself.
> > >
> > > A Concourse environment is deployed and managed in cloud environments
> > > through bosh [4].  Pivotal has agreed to donate AWS and/or GCP compute
> > > and storage resources as well as manage the infrastructure.  These
> > > project resources would be available for use by all committers and
> > > community members regardless of corporate affiliations.  Note that
> > > AFAIK there is no explicit requirement to host CI on ASF
> > > infrastructure—unlike for critical project resources such as source
> > > code, mailing lists, and issue tracking.
> > >
> > > The source for the pipeline and job scripts would reside within the
> > > geode-* repos.  Geode committers would be able to modify those, same
> > > as with our .travis.yml scripts.  All test results and build artifacts
> > > would be publicly viewable just like with our Jenkins build output
> > > today.  Requests for admin assistance would go through the dev@geode
> > > mailing list.
> > >
> > > Thoughts?  As a first step we could run both CI systems side-by-side
> > > and see how the Concourse approach works for our project.
> > >
> > > Thanks,
> > > Anthony
> > >
> > >
> > > [1] https://builds.apache.org/job/Geode-nightly/
> > > [2] https://concourse.ci
> > > [3] https://ci.concourse.ci
> > > [4] https://bosh.io
> >
> >
>

Re: [DISCUSS] CI improvements

[Dan Smith]

On Thu, Nov 2, 2017 at 11:58 AM, Sean Goller  wrote:

> Given the length of time precheckin seems to run, would it make sense to
> break it up?
>
> -Sean.
>

Sure, as long as we don't miss anything :)

-Dan

Broken: apache/geode#4649 (develop - 2c30b7e)

[Travis CI]

Build Update for apache/geode
-

Build: #4649
Status: Broken

Duration: 14 minutes and 42 seconds
Commit: 2c30b7e (develop)
Author: kohlmu-pivotal
Message: GEODE-3637: Moved client queue initialization into the 
ServerConnection.java
Added test to confirm asynchronous client queue creation

View the changeset: 
https://github.com/apache/geode/compare/b5603c188ed2...2c30b7ec4b2b

View the full build log and details: 
https://travis-ci.org/apache/geode/builds/296461173?utm_source=email&utm_medium=notification

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

Re: [DISCUSS] CI improvements

[Sean Goller]

precheckin is literally './gradlew build :geode-assembly:acceptanceTest
integrationTest distributedTest flakyTest' :)

-S.

On Thu, Nov 2, 2017 at 1:10 PM, Dan Smith  wrote:

> On Thu, Nov 2, 2017 at 11:58 AM, Sean Goller  wrote:
>
> > Given the length of time precheckin seems to run, would it make sense to
> > break it up?
> >
> > -Sean.
> >
>
> Sure, as long as we don't miss anything :)
>
> -Dan
>

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #728 was SUCCESSFUL (with 2187 tests)

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #728 was successful.
---
Scheduled
2189 tests in total.

https://build.spring.io/browse/SGF-NAG-728/





--
This message is automatically generated by Atlassian Bamboo