Pulse - Non-Embedded Mode

[Michael Oleske <mo...@pivotal.io>]

Hi Geode Community!

Some colleagues and I were looking at GEODE-6683 (
https://issues.apache.org/jira/browse/GEODE-6683) and noticed that we do
not have test coverage for running Pulse in non-embedded mode.  We were
wondering what our strategy is around Pulse in non-embedded mode. In order
to fully fix the issue, we would prefer to have a high-level acceptance
test that actually tries to run Pule in non-embedded mode (we could not
find an existing acceptance test that performs this).   However, this
non-embedded mode seems a bit odd, as the instructions for it (
https://geode.apache.org/docs/guide/19/tools_modules/pulse/pulse-hosted.html)
are slightly confusing and need some updating for geode (such as making
sure geode-core is on the class path). It seems strange to try and host a
web app in this way, especially with the extra configuration needed (cannot
just plop the Pulse war file in my web server with some config and have it
work).  So there's some questions about the best path forward.

1.  Should we continue supporting non-embedded mode for Pulse?  It seems
like it may be useful to allow Pulse to run outside of a member, but not as
it currently does.  If it was deprecated, I wouldn't be as insistent on an
acceptance test for it.

2.  Should we try to make a separate artifact that is intended to be
deployed on a web server?  This would have a new artifact that could run
elsewhere then (with maybe a user provided config file for properties.)

3.  For the issue that brought up these questions (GEODE-6683), we have
currently only written some unit tests to add the properties. So the
current question is what type of path forward should we take?


-michael

Re: Pulse - Non-Embedded Mode

[Jens Deppe <jd...@pivotal.io>]

Another option might be to turn Pulse into a separate and standalone
(Spring Boot?) app. Perhaps that might be an acceptable compromise for
pulling it out of the locator completely.

--Jens

On Wed, May 1, 2019 at 11:26 AM Anilkumar Gingade <ag...@pivotal.io>
wrote:

> We should be supporting non-embedded mode; I believe most of the app-server
> based use cases will be doing this. This also reduces the resource usage on
> the geode cluster.
>
>
>
> On Wed, May 1, 2019 at 10:44 AM Dan Smith <ds...@pivotal.io> wrote:
>
> > Option 2 does sound like a good way to go. It does seem like if you are
> > making changes to fix non-embedded mode, you probably need to add an
> > acceptance test for that mode since there is non already, regardless of
> > whether you deprecate non-embedded mode.
> >
> > I have no issues with deprecating either embedded or non-embedded mode. I
> > don't think we've put a lot of energy into pulse recently.
> >
> > -Dan
> >
> >
> > On Tue, Apr 30, 2019 at 2:12 PM Jens Deppe <jd...@pivotal.io> wrote:
> >
> > > More accurately, I think geode-core is only required when TLS is
> enabled
> > on
> > > the locator and Pulse needs to make JMX/RMI calls over TLS.
> > >
> > > I would vote for option 2 in this scenario.
> > >
> > > --Jens
> > >
> > > On Tue, Apr 30, 2019 at 1:44 PM Jinmei Liao <ji...@pivotal.io> wrote:
> > >
> > > > I believe to run pulse in non-embedded mode, you just need to install
> > the
> > > > war in a web server and some configuration changes, you don't need
> > > > geode-core at all.
> > > >
> > > > We do lack the acceptance test to run pulse in non-embedded mode
> > though.
> > > We
> > > > have a few unit tests that touches some aspect of it.
> > > >
> > > > On Tue, Apr 30, 2019 at 12:10 PM Michael Oleske <mo...@pivotal.io>
> > > > wrote:
> > > >
> > > > > Hi Geode Community!
> > > > >
> > > > > Some colleagues and I were looking at GEODE-6683 (
> > > > > https://issues.apache.org/jira/browse/GEODE-6683) and noticed that
> > we
> > > do
> > > > > not have test coverage for running Pulse in non-embedded mode.  We
> > were
> > > > > wondering what our strategy is around Pulse in non-embedded mode.
> In
> > > > order
> > > > > to fully fix the issue, we would prefer to have a high-level
> > acceptance
> > > > > test that actually tries to run Pule in non-embedded mode (we could
> > not
> > > > > find an existing acceptance test that performs this).   However,
> this
> > > > > non-embedded mode seems a bit odd, as the instructions for it (
> > > > >
> > > > >
> > > >
> > >
> >
> https://geode.apache.org/docs/guide/19/tools_modules/pulse/pulse-hosted.html
> > > > > )
> > > > > are slightly confusing and need some updating for geode (such as
> > making
> > > > > sure geode-core is on the class path). It seems strange to try and
> > > host a
> > > > > web app in this way, especially with the extra configuration needed
> > > > (cannot
> > > > > just plop the Pulse war file in my web server with some config and
> > have
> > > > it
> > > > > work).  So there's some questions about the best path forward.
> > > > >
> > > > > 1.  Should we continue supporting non-embedded mode for Pulse?  It
> > > seems
> > > > > like it may be useful to allow Pulse to run outside of a member,
> but
> > > not
> > > > as
> > > > > it currently does.  If it was deprecated, I wouldn't be as
> insistent
> > on
> > > > an
> > > > > acceptance test for it.
> > > > >
> > > > > 2.  Should we try to make a separate artifact that is intended to
> be
> > > > > deployed on a web server?  This would have a new artifact that
> could
> > > run
> > > > > elsewhere then (with maybe a user provided config file for
> > properties.)
> > > > >
> > > > > 3.  For the issue that brought up these questions (GEODE-6683), we
> > have
> > > > > currently only written some unit tests to add the properties. So
> the
> > > > > current question is what type of path forward should we take?
> > > > >
> > > > >
> > > > > -michael
> > > > >
> > > >
> > > >
> > > > --
> > > > Cheers
> > > >
> > > > Jinmei
> > > >
> > >
> >
>

Re: Pulse - Non-Embedded Mode

[Anilkumar Gingade <ag...@pivotal.io>]

We should be supporting non-embedded mode; I believe most of the app-server
based use cases will be doing this. This also reduces the resource usage on
the geode cluster.



On Wed, May 1, 2019 at 10:44 AM Dan Smith <ds...@pivotal.io> wrote:

> Option 2 does sound like a good way to go. It does seem like if you are
> making changes to fix non-embedded mode, you probably need to add an
> acceptance test for that mode since there is non already, regardless of
> whether you deprecate non-embedded mode.
>
> I have no issues with deprecating either embedded or non-embedded mode. I
> don't think we've put a lot of energy into pulse recently.
>
> -Dan
>
>
> On Tue, Apr 30, 2019 at 2:12 PM Jens Deppe <jd...@pivotal.io> wrote:
>
> > More accurately, I think geode-core is only required when TLS is enabled
> on
> > the locator and Pulse needs to make JMX/RMI calls over TLS.
> >
> > I would vote for option 2 in this scenario.
> >
> > --Jens
> >
> > On Tue, Apr 30, 2019 at 1:44 PM Jinmei Liao <ji...@pivotal.io> wrote:
> >
> > > I believe to run pulse in non-embedded mode, you just need to install
> the
> > > war in a web server and some configuration changes, you don't need
> > > geode-core at all.
> > >
> > > We do lack the acceptance test to run pulse in non-embedded mode
> though.
> > We
> > > have a few unit tests that touches some aspect of it.
> > >
> > > On Tue, Apr 30, 2019 at 12:10 PM Michael Oleske <mo...@pivotal.io>
> > > wrote:
> > >
> > > > Hi Geode Community!
> > > >
> > > > Some colleagues and I were looking at GEODE-6683 (
> > > > https://issues.apache.org/jira/browse/GEODE-6683) and noticed that
> we
> > do
> > > > not have test coverage for running Pulse in non-embedded mode.  We
> were
> > > > wondering what our strategy is around Pulse in non-embedded mode. In
> > > order
> > > > to fully fix the issue, we would prefer to have a high-level
> acceptance
> > > > test that actually tries to run Pule in non-embedded mode (we could
> not
> > > > find an existing acceptance test that performs this).   However, this
> > > > non-embedded mode seems a bit odd, as the instructions for it (
> > > >
> > > >
> > >
> >
> https://geode.apache.org/docs/guide/19/tools_modules/pulse/pulse-hosted.html
> > > > )
> > > > are slightly confusing and need some updating for geode (such as
> making
> > > > sure geode-core is on the class path). It seems strange to try and
> > host a
> > > > web app in this way, especially with the extra configuration needed
> > > (cannot
> > > > just plop the Pulse war file in my web server with some config and
> have
> > > it
> > > > work).  So there's some questions about the best path forward.
> > > >
> > > > 1.  Should we continue supporting non-embedded mode for Pulse?  It
> > seems
> > > > like it may be useful to allow Pulse to run outside of a member, but
> > not
> > > as
> > > > it currently does.  If it was deprecated, I wouldn't be as insistent
> on
> > > an
> > > > acceptance test for it.
> > > >
> > > > 2.  Should we try to make a separate artifact that is intended to be
> > > > deployed on a web server?  This would have a new artifact that could
> > run
> > > > elsewhere then (with maybe a user provided config file for
> properties.)
> > > >
> > > > 3.  For the issue that brought up these questions (GEODE-6683), we
> have
> > > > currently only written some unit tests to add the properties. So the
> > > > current question is what type of path forward should we take?
> > > >
> > > >
> > > > -michael
> > > >
> > >
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
>

Re: Pulse - Non-Embedded Mode

[Dan Smith <ds...@pivotal.io>]

Option 2 does sound like a good way to go. It does seem like if you are
making changes to fix non-embedded mode, you probably need to add an
acceptance test for that mode since there is non already, regardless of
whether you deprecate non-embedded mode.

I have no issues with deprecating either embedded or non-embedded mode. I
don't think we've put a lot of energy into pulse recently.

-Dan


On Tue, Apr 30, 2019 at 2:12 PM Jens Deppe <jd...@pivotal.io> wrote:

> More accurately, I think geode-core is only required when TLS is enabled on
> the locator and Pulse needs to make JMX/RMI calls over TLS.
>
> I would vote for option 2 in this scenario.
>
> --Jens
>
> On Tue, Apr 30, 2019 at 1:44 PM Jinmei Liao <ji...@pivotal.io> wrote:
>
> > I believe to run pulse in non-embedded mode, you just need to install the
> > war in a web server and some configuration changes, you don't need
> > geode-core at all.
> >
> > We do lack the acceptance test to run pulse in non-embedded mode though.
> We
> > have a few unit tests that touches some aspect of it.
> >
> > On Tue, Apr 30, 2019 at 12:10 PM Michael Oleske <mo...@pivotal.io>
> > wrote:
> >
> > > Hi Geode Community!
> > >
> > > Some colleagues and I were looking at GEODE-6683 (
> > > https://issues.apache.org/jira/browse/GEODE-6683) and noticed that we
> do
> > > not have test coverage for running Pulse in non-embedded mode.  We were
> > > wondering what our strategy is around Pulse in non-embedded mode. In
> > order
> > > to fully fix the issue, we would prefer to have a high-level acceptance
> > > test that actually tries to run Pule in non-embedded mode (we could not
> > > find an existing acceptance test that performs this).   However, this
> > > non-embedded mode seems a bit odd, as the instructions for it (
> > >
> > >
> >
> https://geode.apache.org/docs/guide/19/tools_modules/pulse/pulse-hosted.html
> > > )
> > > are slightly confusing and need some updating for geode (such as making
> > > sure geode-core is on the class path). It seems strange to try and
> host a
> > > web app in this way, especially with the extra configuration needed
> > (cannot
> > > just plop the Pulse war file in my web server with some config and have
> > it
> > > work).  So there's some questions about the best path forward.
> > >
> > > 1.  Should we continue supporting non-embedded mode for Pulse?  It
> seems
> > > like it may be useful to allow Pulse to run outside of a member, but
> not
> > as
> > > it currently does.  If it was deprecated, I wouldn't be as insistent on
> > an
> > > acceptance test for it.
> > >
> > > 2.  Should we try to make a separate artifact that is intended to be
> > > deployed on a web server?  This would have a new artifact that could
> run
> > > elsewhere then (with maybe a user provided config file for properties.)
> > >
> > > 3.  For the issue that brought up these questions (GEODE-6683), we have
> > > currently only written some unit tests to add the properties. So the
> > > current question is what type of path forward should we take?
> > >
> > >
> > > -michael
> > >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>

Re: Pulse - Non-Embedded Mode

[Jens Deppe <jd...@pivotal.io>]

More accurately, I think geode-core is only required when TLS is enabled on
the locator and Pulse needs to make JMX/RMI calls over TLS.

I would vote for option 2 in this scenario.

--Jens

On Tue, Apr 30, 2019 at 1:44 PM Jinmei Liao <ji...@pivotal.io> wrote:

> I believe to run pulse in non-embedded mode, you just need to install the
> war in a web server and some configuration changes, you don't need
> geode-core at all.
>
> We do lack the acceptance test to run pulse in non-embedded mode though. We
> have a few unit tests that touches some aspect of it.
>
> On Tue, Apr 30, 2019 at 12:10 PM Michael Oleske <mo...@pivotal.io>
> wrote:
>
> > Hi Geode Community!
> >
> > Some colleagues and I were looking at GEODE-6683 (
> > https://issues.apache.org/jira/browse/GEODE-6683) and noticed that we do
> > not have test coverage for running Pulse in non-embedded mode.  We were
> > wondering what our strategy is around Pulse in non-embedded mode. In
> order
> > to fully fix the issue, we would prefer to have a high-level acceptance
> > test that actually tries to run Pule in non-embedded mode (we could not
> > find an existing acceptance test that performs this).   However, this
> > non-embedded mode seems a bit odd, as the instructions for it (
> >
> >
> https://geode.apache.org/docs/guide/19/tools_modules/pulse/pulse-hosted.html
> > )
> > are slightly confusing and need some updating for geode (such as making
> > sure geode-core is on the class path). It seems strange to try and host a
> > web app in this way, especially with the extra configuration needed
> (cannot
> > just plop the Pulse war file in my web server with some config and have
> it
> > work).  So there's some questions about the best path forward.
> >
> > 1.  Should we continue supporting non-embedded mode for Pulse?  It seems
> > like it may be useful to allow Pulse to run outside of a member, but not
> as
> > it currently does.  If it was deprecated, I wouldn't be as insistent on
> an
> > acceptance test for it.
> >
> > 2.  Should we try to make a separate artifact that is intended to be
> > deployed on a web server?  This would have a new artifact that could run
> > elsewhere then (with maybe a user provided config file for properties.)
> >
> > 3.  For the issue that brought up these questions (GEODE-6683), we have
> > currently only written some unit tests to add the properties. So the
> > current question is what type of path forward should we take?
> >
> >
> > -michael
> >
>
>
> --
> Cheers
>
> Jinmei
>

Re: Pulse - Non-Embedded Mode

[Jinmei Liao <ji...@pivotal.io>]

I believe to run pulse in non-embedded mode, you just need to install the
war in a web server and some configuration changes, you don't need
geode-core at all.

We do lack the acceptance test to run pulse in non-embedded mode though. We
have a few unit tests that touches some aspect of it.

On Tue, Apr 30, 2019 at 12:10 PM Michael Oleske <mo...@pivotal.io> wrote:

> Hi Geode Community!
>
> Some colleagues and I were looking at GEODE-6683 (
> https://issues.apache.org/jira/browse/GEODE-6683) and noticed that we do
> not have test coverage for running Pulse in non-embedded mode.  We were
> wondering what our strategy is around Pulse in non-embedded mode. In order
> to fully fix the issue, we would prefer to have a high-level acceptance
> test that actually tries to run Pule in non-embedded mode (we could not
> find an existing acceptance test that performs this).   However, this
> non-embedded mode seems a bit odd, as the instructions for it (
>
> https://geode.apache.org/docs/guide/19/tools_modules/pulse/pulse-hosted.html
> )
> are slightly confusing and need some updating for geode (such as making
> sure geode-core is on the class path). It seems strange to try and host a
> web app in this way, especially with the extra configuration needed (cannot
> just plop the Pulse war file in my web server with some config and have it
> work).  So there's some questions about the best path forward.
>
> 1.  Should we continue supporting non-embedded mode for Pulse?  It seems
> like it may be useful to allow Pulse to run outside of a member, but not as
> it currently does.  If it was deprecated, I wouldn't be as insistent on an
> acceptance test for it.
>
> 2.  Should we try to make a separate artifact that is intended to be
> deployed on a web server?  This would have a new artifact that could run
> elsewhere then (with maybe a user provided config file for properties.)
>
> 3.  For the issue that brought up these questions (GEODE-6683), we have
> currently only written some unit tests to add the properties. So the
> current question is what type of path forward should we take?
>
>
> -michael
>


-- 
Cheers

Jinmei