RFC - Gateway sender to deliver transaction events atomically to receivers

[Alberto Gomez]

Hi,

Could you please review the RFC for "Gateway sender to deliver transaction 
events atomically to receivers"?

https://cwiki.apache.org/confluence/display/GEODE/Gw+sender+to+deliver+transaction+events+atomically+to+receivers

Deadline for comments is Wednesday, April 1st, 2020,

Thanks,

Alberto G.

Re: RFC: Add C Bindings to Geode Native Client

[Robert Houghton]

+1
YES.

Having a set of clean C headers also allows for using a broad set of code
generators for additional languages (Swig, for example).



On Tue, Mar 24, 2020 at 2:20 PM Blake Bender  wrote:

> Hello everyone,
>
> We'd like to add C bindings to the native client, in preparation for the
> larger task of adding support for new languages, e.g. .net core.  Please
> have a look at the proposal below and let me know what you think.
>
> Thanks,
>
> Blake
>
>
>
> https://cwiki.apache.org/confluence/display/GEODE/Add+C+Bindings+to+Native+Client+Library
>

Re: RFC: Add C Bindings to Geode Native Client

[Dan Smith]

+1

Great idea! Hey, it's also easy to call into C libraries from Java - maybe
we can write a java client ;)

It would be nice to see a little bit more detail about the actual API, like
what does a region put look like?

-Dan

On Wed, Mar 25, 2020 at 8:25 AM Robert Houghton 
wrote:

> +1
> YES.
>
> Having a set of clean C headers also allows for using a broad set of code
> generators for additional languages (Swig, for example).
>
>
>
> On Tue, Mar 24, 2020 at 2:20 PM Blake Bender  wrote:
>
> > Hello everyone,
> >
> > We'd like to add C bindings to the native client, in preparation for the
> > larger task of adding support for new languages, e.g. .net core.  Please
> > have a look at the proposal below and let me know what you think.
> >
> > Thanks,
> >
> > Blake
> >
> >
> >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Add+C+Bindings+to+Native+Client+Library
> >
>

Request for Apache Geode Wiki Edit Permission

[Barry Oglesby]

This is a request for permission to edit the Apache Geode Wiki using my
Apache credentials:

Username: boglesby
Email: bogle...@apache.org

Thanks,
Barry Oglesby

Re: RFC: Add C Bindings to Geode Native Client

[Michael Oleske]

+1

Would certainly be nice since the protobuf work is still mostly
experimental (and then I can continue my goal of Geode-ing all the
languages)

-michael


On Wed, Mar 25, 2020 at 9:03 AM Dan Smith  wrote:

> +1
>
> Great idea! Hey, it's also easy to call into C libraries from Java - maybe
> we can write a java client ;)
>
> It would be nice to see a little bit more detail about the actual API, like
> what does a region put look like?
>
> -Dan
>
> On Wed, Mar 25, 2020 at 8:25 AM Robert Houghton 
> wrote:
>
> > +1
> > YES.
> >
> > Having a set of clean C headers also allows for using a broad set of code
> > generators for additional languages (Swig, for example).
> >
> >
> >
> > On Tue, Mar 24, 2020 at 2:20 PM Blake Bender  wrote:
> >
> > > Hello everyone,
> > >
> > > We'd like to add C bindings to the native client, in preparation for
> the
> > > larger task of adding support for new languages, e.g. .net core.
> Please
> > > have a look at the proposal below and let me know what you think.
> > >
> > > Thanks,
> > >
> > > Blake
> > >
> > >
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Add+C+Bindings+to+Native+Client+Library
> > >
> >
>

Re: Request for Apache Geode Wiki Edit Permission

[Dan Smith]

Hi Barry,

You should have access now.

-Dan

On Wed, Mar 25, 2020 at 11:23 AM Barry Oglesby  wrote:

> This is a request for permission to edit the Apache Geode Wiki using my
> Apache credentials:
>
> Username: boglesby
> Email: bogle...@apache.org
>
> Thanks,
> Barry Oglesby
>

[VOTE] Apache Geode 1.12.0.RC1

[Ernest Burghardt]

Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.12.0.RC1.
Thanks to all the community members for their contributions to this release!

Please do a review and give your feedback, including the checks you
performed.

Voting deadline:
3PM PST Mon, March 30 2020.

Please note that we are voting upon the source tag:
rel/v1.12.0.RC1

Release notes:
https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.12.0

Source and binary distributions:
https://dist.apache.org/repos/dist/dev/geode/1.12.0.RC1/

Maven staging repo:
https://repository.apache.org/content/repositories/orgapachegeode-1065

GitHub:
https://github.com/apache/geode/tree/rel/v1.12.0.RC1
https://github.com/apache/geode-examples/tree/rel/v1.12.0.RC1
https://github.com/apache/geode-native/tree/rel/v1.12.0.RC1
https://github.com/apache/geode-benchmarks/tree/rel/v1.12.0.RC1

Pipelines:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-12-0-main
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-12-0-rc

Geode's KEYS file containing PGP keys we use to sign the release:
https://github.com/apache/geode/blob/develop/KEYS

Command to run geode-examples:
./gradlew -PgeodeReleaseUrl=
https://dist.apache.org/repos/dist/dev/geode/1.12.0.RC1
-PgeodeRepositoryUrl=
https://repository.apache.org/content/repositories/orgapachegeode-1065
build runAll

Regards
Ernie Burghardt

Re: RFC - Gateway sender to deliver transaction events atomically to receivers

[Dan Smith]

+1

I think this a good improvement to the way transactions behave with WAN! I
had a couple of more detailed comments I put on the doc.

Thanks,
-Dan

On Wed, Mar 25, 2020 at 8:05 AM Alberto Gomez 
wrote:

> Hi,
>
> Could you please review the RFC for "Gateway sender to deliver transaction
> events atomically to receivers"?
>
>
> https://cwiki.apache.org/confluence/display/GEODE/Gw+sender+to+deliver+transaction+events+atomically+to+receivers
>
> Deadline for comments is Wednesday, April 1st, 2020,
>
> Thanks,
>
> Alberto G.
>

Re: RFC - Gateway sender to deliver transaction events atomically to receivers

[Udo Kohlmeyer]

Hi there Alberto,

It's a "-1" from me.

I have raised my concerns in the RFC comments. To summarize, whilst I 
like the idea (I had never thought of that problem you are trying to 
solve), I don't know how this will behave at scale. Just looking at some 
of the comments, I think it is safe to say that many have similar feelings.


I like the notion of this proposal, but I'm not convinced that the 
solution is actually going solve the problem. I think it might solve 
only a very small part of the problem.


In essence you are proposing a distributed transaction over WAN and I 
don't see enough in the proposal to convince me that we have a solution 
that will solve this problem.


--Udo

On 3/25/20 8:04 AM, Alberto Gomez wrote:

Hi,

Could you please review the RFC for "Gateway sender to deliver transaction events 
atomically to receivers"?

https://cwiki.apache.org/confluence/display/GEODE/Gw+sender+to+deliver+transaction+events+atomically+to+receivers

Deadline for comments is Wednesday, April 1st, 2020,

Thanks,

Alberto G.

Passed: apache/geode-examples#407 (release/1.12.0 - bd18a64)

[Travis CI]

Build Update for apache/geode-examples
-

Build: #407
Status: Passed

Duration: 25 mins and 59 secs
Commit: bd18a64 (release/1.12.0)
Author: Ernie Burghardt
Message: temporarily point to staging repo for CI purposes

View the changeset: 
https://github.com/apache/geode-examples/compare/05c41c76c2d9...bd18a64edf6f

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

--

You can unsubscribe from build emails from the apache/geode-examples repository 
going to 
https://travis-ci.org/account/preferences/unsubscribe?repository=11483039&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

Errored: apache/geode-examples#408 (rel/v1.12.0.RC1 - 05c41c7)

[Travis CI]

Build Update for apache/geode-examples
-

Build: #408
Status: Errored

Duration: 1 min and 8 secs
Commit: 05c41c7 (rel/v1.12.0.RC1)
Author: Ernie Burghardt
Message: Bumping version to 1.12.0

View the changeset: 
https://github.com/apache/geode-examples/compare/rel/v1.12.0.RC1

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

--

You can unsubscribe from build emails from the apache/geode-examples repository 
going to 
https://travis-ci.org/account/preferences/unsubscribe?repository=11483039&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

RE: WAN replication issue in cloud native environments

[Alberto Bustamante Reyes]

Hi,

I have modified the RFC to include the alternative suggested by Bruce. Im also 
extending the deadline for sending comments to next Friday 27th March EOB.

Thanks!

BR/

Alberto B.

De: Bruce Schuchardt 
Enviado: lunes, 23 de marzo de 2020 22:38
Para: Alberto Bustamante Reyes ; Dan Smith 
; dev@geode.apache.org 
Cc: Jacob Barrett ; Anilkumar Gingade 
; Charlie Black 
Asunto: Re: WAN replication issue in cloud native environments


I think what Dan did was pass in a socket factory that would connect to his 
gateway instead of the requested server.  Doing it like that would require a 
lot less code change than what you’re currently doing and would get past the 
unit test problem.



I can point you to where you’d need to make changes for the Ping operatio:.  
PingOpImpl would need to send the ServerLocation it’s trying to reach.  
PingOp.execute() gets that as a parameter and PingOpImpl.sendMessage() writes 
it to the server.  The Ping command class’s cmdExecute would need to read that 
data if serverConnection.getClientVersion() is Version.GEODE_1_13_0 or later.  
Then it would have to compare the server location it read to that server’s 
coordinates and, if not equal, find the server with those coordinates and send 
a new DistributionMessage to it with the client’s identity.  There are plenty 
of DistributionMessage classes around to look at as precedents.  You send the 
message with 
serverConnection.getCache().getDistributionManager().putOutgoing(message).



You can PM me any time.  Dan could answer questions about his gateway work.





From: Alberto Bustamante Reyes 
Date: Monday, March 23, 2020 at 2:18 PM
To: Bruce Schuchardt , Dan Smith , 
"dev@geode.apache.org" 
Cc: Jacob Barrett , Anilkumar Gingade 
, Charlie Black 
Subject: RE: WAN replication issue in cloud native environments



Thanks for your answer and your comment in the wiki Bruce. I will take a closer 
look at what you mentioned, it is not clear enough for me how to implement it.



BTW, I forgot to set a deadline for the wiki review, I hope that Thursday 26th 
March is enough to receive comments.



De: Bruce Schuchardt 
Enviado: jueves, 19 de marzo de 2020 16:30
Para: Alberto Bustamante Reyes ; Dan Smith 
; dev@geode.apache.org 
Cc: Jacob Barrett ; Anilkumar Gingade 
; Charlie Black 
Asunto: Re: WAN replication issue in cloud native environments



I wonder if an approach similar to the SNI hostname PoolFactory changes would 
work for this non-TLS gateway.  The client needs to differentiate between the 
different servers so that it doesn’t declare all of them dead should one of 
them fail.  If the pool knew about the gateway it could direct all traffic 
there and the servers wouldn’t need to set a hostname-for-clients.



It’s not an ideal solution since the gateway wouldn’t know which server the 
client wanted to contact and there are sure to be other problems like creating 
a backup queue for subscriptions.  But that’s the case with the 
hostname-for-clients approach, too.





From: Alberto Bustamante Reyes 
Date: Wednesday, March 18, 2020 at 8:35 AM
To: Dan Smith , "dev@geode.apache.org" 
Cc: Bruce Schuchardt , Jacob Barrett 
, Anilkumar Gingade , Charlie Black 

Subject: RE: WAN replication issue in cloud native environments



Hi all,



As Bruce suggested me, I have created a wiki page describing the problem we are 
trying to solve: 
https://cwiki.apache.org/confluence/display/GEODE/Allow+same+host+and+port+for+all+gateway+receivers



Please let me know if further clarifications are needed.



Also, I have closed the PR I have been using until now, and created a new one 
with the current status of the solution, with one commit per issue described in 
the wiki: https://github.com/apache/geode/pull/4824



Thanks in advance!



De: Alberto Bustamante Reyes 
Enviado: lunes, 9 de marzo de 2020 11:24
Para: Dan Smith 
Cc: dev@geode.apache.org ; Bruce Schuchardt 
; Jacob Barrett ; Anilkumar 
Gingade ; Charlie Black 
Asunto: RE: WAN replication issue in cloud native environments



Thanks for point that out Dan. Sorry for the misunderstanding, as I only found 
that "affinity" (setServerAffinityLocation method) on the client code I thought 
you were talking about it.
Anyway, I did some more tests and it does not solve our problem...

I tried configuring the service affinity on k8s, but it breaks the first part 
of the solution (the changes implemented on LocatorLoadSnapshot that solves the 
problem of the replication) and senders do not connect to other receivers when 
the one they were

Re: RFC - Gateway sender to deliver transaction events atomically to receivers

[Jason Huynh]

I put some comments on the proposal on the wiki.

btw what are we voting on?  Just curious as I wasn't sure if we were voting
for the current proposal or whether we should continue this discussion?

I like the idea of having transactional ops be sent together in a batch if
possible and it would be an iterative improvement, whether that is a
complete solution to a larger problem, I think might be beyond what Alberto
was proposing?

Again I am not exactly sure if this was intended to be a vote but I
would +1 the attempt and continuation of the discussion/proposal and
probably -0 the current proposal as there are some ideas/things to iron
out.




On Wed, Mar 25, 2020 at 3:49 PM Udo Kohlmeyer  wrote:

> Hi there Alberto,
>
> It's a "-1" from me.
>
> I have raised my concerns in the RFC comments. To summarize, whilst I
> like the idea (I had never thought of that problem you are trying to
> solve), I don't know how this will behave at scale. Just looking at some
> of the comments, I think it is safe to say that many have similar feelings.
>
> I like the notion of this proposal, but I'm not convinced that the
> solution is actually going solve the problem. I think it might solve
> only a very small part of the problem.
>
> In essence you are proposing a distributed transaction over WAN and I
> don't see enough in the proposal to convince me that we have a solution
> that will solve this problem.
>
> --Udo
>
> On 3/25/20 8:04 AM, Alberto Gomez wrote:
> > Hi,
> >
> > Could you please review the RFC for "Gateway sender to deliver
> transaction events atomically to receivers"?
> >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Gw+sender+to+deliver+transaction+events+atomically+to+receivers
> >
> > Deadline for comments is Wednesday, April 1st, 2020,
> >
> > Thanks,
> >
> > Alberto G.
> >
>

Re: RFC - Gateway sender to deliver transaction events atomically to receivers

[Udo Kohlmeyer]

My vote was to implement said solution.

But it is a HUGE +1 to continue the discussion to resolve the issue 
identified!


--Udo

On 3/25/20 4:14 PM, Jason Huynh wrote:

I put some comments on the proposal on the wiki.

btw what are we voting on?  Just curious as I wasn't sure if we were voting
for the current proposal or whether we should continue this discussion?

I like the idea of having transactional ops be sent together in a batch if
possible and it would be an iterative improvement, whether that is a
complete solution to a larger problem, I think might be beyond what Alberto
was proposing?

Again I am not exactly sure if this was intended to be a vote but I
would +1 the attempt and continuation of the discussion/proposal and
probably -0 the current proposal as there are some ideas/things to iron
out.




On Wed, Mar 25, 2020 at 3:49 PM Udo Kohlmeyer  wrote:


Hi there Alberto,

It's a "-1" from me.

I have raised my concerns in the RFC comments. To summarize, whilst I
like the idea (I had never thought of that problem you are trying to
solve), I don't know how this will behave at scale. Just looking at some
of the comments, I think it is safe to say that many have similar feelings.

I like the notion of this proposal, but I'm not convinced that the
solution is actually going solve the problem. I think it might solve
only a very small part of the problem.

In essence you are proposing a distributed transaction over WAN and I
don't see enough in the proposal to convince me that we have a solution
that will solve this problem.

--Udo

On 3/25/20 8:04 AM, Alberto Gomez wrote:

Hi,

Could you please review the RFC for "Gateway sender to deliver

transaction events atomically to receivers"?



https://cwiki.apache.org/confluence/display/GEODE/Gw+sender+to+deliver+transaction+events+atomically+to+receivers

Deadline for comments is Wednesday, April 1st, 2020,

Thanks,

Alberto G.

Re: RFC - Gateway sender to deliver transaction events atomically to receivers

[Dan Smith]

> btw what are we voting on?  Just curious as I wasn't sure if we were
voting
for the current proposal or whether we should continue this discussion?

Sorry, just +1'd because I like the idea, not to imply we're voting on
anything. I thought that's a general apache convention during a discussion.

> In essence you are proposing a distributed transaction over WAN

I wouldn't equate this with distribution transactions at all. This is just
trying to group transaction events together in a batch. I don't think we
need to solve the whole distribution transaction problem with this proposal.

I remember someone trying to accomplish this same thing on top of geode
with TransactionListener that dumped into a separate region or something
like that. Barry might remember more details. Having a
--group-transaction-events options seems much more user friendly.

-Dan

On Wed, Mar 25, 2020 at 4:19 PM Udo Kohlmeyer  wrote:

> My vote was to implement said solution.
>
> But it is a HUGE +1 to continue the discussion to resolve the issue
> identified!
>
> --Udo
>
> On 3/25/20 4:14 PM, Jason Huynh wrote:
> > I put some comments on the proposal on the wiki.
> >
> > btw what are we voting on?  Just curious as I wasn't sure if we were
> voting
> > for the current proposal or whether we should continue this discussion?
> >
> > I like the idea of having transactional ops be sent together in a batch
> if
> > possible and it would be an iterative improvement, whether that is a
> > complete solution to a larger problem, I think might be beyond what
> Alberto
> > was proposing?
> >
> > Again I am not exactly sure if this was intended to be a vote but I
> > would +1 the attempt and continuation of the discussion/proposal and
> > probably -0 the current proposal as there are some ideas/things to iron
> > out.
> >
> >
> >
> >
> > On Wed, Mar 25, 2020 at 3:49 PM Udo Kohlmeyer 
> wrote:
> >
> >> Hi there Alberto,
> >>
> >> It's a "-1" from me.
> >>
> >> I have raised my concerns in the RFC comments. To summarize, whilst I
> >> like the idea (I had never thought of that problem you are trying to
> >> solve), I don't know how this will behave at scale. Just looking at some
> >> of the comments, I think it is safe to say that many have similar
> feelings.
> >>
> >> I like the notion of this proposal, but I'm not convinced that the
> >> solution is actually going solve the problem. I think it might solve
> >> only a very small part of the problem.
> >>
> >> In essence you are proposing a distributed transaction over WAN and I
> >> don't see enough in the proposal to convince me that we have a solution
> >> that will solve this problem.
> >>
> >> --Udo
> >>
> >> On 3/25/20 8:04 AM, Alberto Gomez wrote:
> >>> Hi,
> >>>
> >>> Could you please review the RFC for "Gateway sender to deliver
> >> transaction events atomically to receivers"?
> >>>
> >>
> https://cwiki.apache.org/confluence/display/GEODE/Gw+sender+to+deliver+transaction+events+atomically+to+receivers
> >>> Deadline for comments is Wednesday, April 1st, 2020,
> >>>
> >>> Thanks,
> >>>
> >>> Alberto G.
> >>>
>

Re: [VOTE] Apache Geode 1.12.0.RC1

[Dan Smith]

geode-assembly-1.12.0.zip does not appear to have any signature files
associated with it. It also looks like it just contains a Dockerfile - is
this actually an artifact we want to distribute?

-Dan

On Wed, Mar 25, 2020 at 2:12 PM Ernest Burghardt 
wrote:

> Hello Geode Dev Community,
>
> This is a release candidate for Apache Geode version 1.12.0.RC1.
> Thanks to all the community members for their contributions to this
> release!
>
> Please do a review and give your feedback, including the checks you
> performed.
>
> Voting deadline:
> 3PM PST Mon, March 30 2020.
>
> Please note that we are voting upon the source tag:
> rel/v1.12.0.RC1
>
> Release notes:
>
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.12.0
>
> Source and binary distributions:
> https://dist.apache.org/repos/dist/dev/geode/1.12.0.RC1/
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachegeode-1065
>
> GitHub:
> https://github.com/apache/geode/tree/rel/v1.12.0.RC1
> https://github.com/apache/geode-examples/tree/rel/v1.12.0.RC1
> https://github.com/apache/geode-native/tree/rel/v1.12.0.RC1
> https://github.com/apache/geode-benchmarks/tree/rel/v1.12.0.RC1
>
> Pipelines:
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-12-0-main
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-12-0-rc
>
> Geode's KEYS file containing PGP keys we use to sign the release:
> https://github.com/apache/geode/blob/develop/KEYS
>
> Command to run geode-examples:
> ./gradlew -PgeodeReleaseUrl=
> https://dist.apache.org/repos/dist/dev/geode/1.12.0.RC1
> -PgeodeRepositoryUrl=
> https://repository.apache.org/content/repositories/orgapachegeode-1065
> build runAll
>
> Regards
> Ernie Burghardt
>

Passed: apache/geode-native#2350 (rel/v1.12.0.RC1 - 8ddc0e8)

[Travis CI]

Build Update for apache/geode-native
-

Build: #2350
Status: Passed

Duration: 1 hr, 20 mins, and 26 secs
Commit: 8ddc0e8 (rel/v1.12.0.RC1)
Author: Blake Bender
Message: GEODE-7694: fix pdx type lookup (#572)

- < operator should have used typeId, was using className which is NOT UNIQUE
- This should fix problems with __GEMFIRE_JSON PDX type
- fall back to comparing className when both typeIds are 0
- Local regions appear to operate with typeId == 0 for everything
- Local regions will still be broken for __GEMFIRE_JSON type, because className 
is the same for different types

View the changeset: 
https://github.com/apache/geode-native/compare/rel/v1.12.0.RC1

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

--

You can unsubscribe from build emails from the apache/geode-native repository 
going to 
https://travis-ci.org/account/preferences/unsubscribe?repository=11948127&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

Re: [VOTE] Apache Geode 1.12.0.RC1

[Owen Nichols]

My vote is non-binding, but I’m a -1 for this RC1.  Reasons:

i) The geode-examples release branch appears to have been branched from master, 
rather than develop (that's why there are still .zip artifacts).  Also, I see 
at least 3 PRs against examples that were mistakenly merged to master instead 
of develop (#89, #91, #92).  This needs to be sorted out and the branch re-cut 
correctly.

ii) As Dan pointed out, geode-assembly should not be generating an artifact, 
zip or otherwise.  I have included a fix for this as part of 
https://github.com/apache/geode/pull/4850

iii) As long as we need to make an RC2 anyway, I personally feel that it would 
be nice to align geode-native to its recent milestone (build/v10.1.0-build.254 
/ commit hash 35fcb1a66).  The current release branch is about half-a-dozen 
fixes behind this milestone.

-Owen

> On Mar 25, 2020, at 4:55 PM, Dan Smith  wrote:
> 
> geode-assembly-1.12.0.zip does not appear to have any signature files
> associated with it. It also looks like it just contains a Dockerfile - is
> this actually an artifact we want to distribute?
> 
> -Dan
> 
> On Wed, Mar 25, 2020 at 2:12 PM Ernest Burghardt 
> wrote:
> 
>> Hello Geode Dev Community,
>> 
>> This is a release candidate for Apache Geode version 1.12.0.RC1.
>> Thanks to all the community members for their contributions to this
>> release!
>> 
>> Please do a review and give your feedback, including the checks you
>> performed.
>> 
>> Voting deadline:
>> 3PM PST Mon, March 30 2020.
>> 
>> Please note that we are voting upon the source tag:
>> rel/v1.12.0.RC1
>> 
>> Release notes:
>> 
>> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.12.0
>> 
>> Source and binary distributions:
>> https://dist.apache.org/repos/dist/dev/geode/1.12.0.RC1/
>> 
>> Maven staging repo:
>> https://repository.apache.org/content/repositories/orgapachegeode-1065
>> 
>> GitHub:
>> https://github.com/apache/geode/tree/rel/v1.12.0.RC1
>> https://github.com/apache/geode-examples/tree/rel/v1.12.0.RC1
>> https://github.com/apache/geode-native/tree/rel/v1.12.0.RC1
>> https://github.com/apache/geode-benchmarks/tree/rel/v1.12.0.RC1
>> 
>> Pipelines:
>> 
>> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-12-0-main
>> 
>> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-12-0-rc
>> 
>> Geode's KEYS file containing PGP keys we use to sign the release:
>> https://github.com/apache/geode/blob/develop/KEYS
>> 
>> Command to run geode-examples:
>> ./gradlew -PgeodeReleaseUrl=
>> https://dist.apache.org/repos/dist/dev/geode/1.12.0.RC1
>> -PgeodeRepositoryUrl=
>> https://repository.apache.org/content/repositories/orgapachegeode-1065
>> build runAll
>> 
>> Regards
>> Ernie Burghardt
>> 

Broken: apache/geode-examples#410 (develop - 0ed1eed)

[Travis CI]

Build Update for apache/geode-examples
-

Build: #410
Status: Broken

Duration: 1 min and 32 secs
Commit: 0ed1eed (develop)
Author: Robert Houghton
Message: Add missing geode-lucene to dependency-substitution block

Authored-by: Robert Houghton 

View the changeset: 
https://github.com/apache/geode-examples/compare/813b76196c27...0ed1eed11d86

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

--

You can unsubscribe from build emails from the apache/geode-examples repository 
going to 
https://travis-ci.org/account/preferences/unsubscribe?repository=11483039&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.