5:20 a.m.
Team,
As mentioned on IRC, we should not ship an embedded Cassandra with
Hawkular Services. Here are a couple of approaches we can follow to
accomplish that:
- Keep everything as is, but change the default value for
`hawkular.backend` to `remote` instead of the current `embedded_cassandra`
- Remove the embedded Cassandra entirely from Nest. This has
implications on how the integration tests are executed: we'd need to
ensure that each integration test suite starts an embedded Cassandra
before the test is executed. Or use an approach like Metrics, which
requires Cassandra to be running before the tests are started.
Which approach should be the one to follow?
- Juca.
5:26 a.m.
We should not embed Cassandra at all in that package. It would be confusing
if there is a security issue in Cassandra.
Thomas
On Tue, Jun 14, 2016 at 12:20 PM, Juraci Paixão Kröhling <
jpkroehling(a)redhat.com> wrote:
Team,
As mentioned on IRC, we should not ship an embedded Cassandra with
Hawkular Services. Here are a couple of approaches we can follow to
accomplish that:
- Keep everything as is, but change the default value for
`hawkular.backend` to `remote` instead of the current `embedded_cassandra`
- Remove the embedded Cassandra entirely from Nest. This has
implications on how the integration tests are executed: we'd need to
ensure that each integration test suite starts an embedded Cassandra
before the test is executed. Or use an approach like Metrics, which
requires Cassandra to be running before the tests are started.
Which approach should be the one to follow?
- Juca.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
5:31 a.m.
----- Mensaje original -----
De: "Juraci Paixão Kröhling"
<jpkroehling(a)redhat.com>
Para: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
Enviados: Martes, 14 de Junio 2016 12:20:11
Asunto: [Hawkular-dev] Removal of embedded Cassandra
Team,
As mentioned on IRC, we should not ship an embedded Cassandra with
Hawkular Services. Here are a couple of approaches we can follow to
accomplish that:
- Keep everything as is, but change the default value for
`hawkular.backend` to `remote` instead of the current `embedded_cassandra`
- Remove the embedded Cassandra entirely from Nest. This has
implications on how the integration tests are executed: we'd need to
ensure that each integration test suite starts an embedded Cassandra
before the test is executed. Or use an approach like Metrics, which
requires Cassandra to be running before the tests are started.
Which approach should be the one to follow?
Personally I prefer one that takes less steps to maintain our integration tests as they
are.
I'm not a fan of big refactoring just by this reason.
So, if we can solve these things with a variable better than change the whole nest and try
to package it again for itests.
- Juca.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
5:58 a.m.
On 14 Jun 2016, at 12:20, Juraci Paixão Kröhling wrote:
- Keep everything as is, but change the default value for
`hawkular.backend` to `remote` instead of the current `embedded_cassandra`
I think this needs to be the default no matter what is decided for the
next item.
- Remove the embedded Cassandra entirely from Nest. This has
I think this is the right thing to do.
before the test is executed. Or use an approach like Metrics, which
requires Cassandra to be running before the tests are started.
Yes, +1
6:10 a.m.
On 14.06.2016 12:58, Heiko W.Rupp wrote:
On 14 Jun 2016, at 12:20, Juraci Paixão Kröhling wrote:
> before the test is executed. Or use an approach like Metrics, which
> requires Cassandra to be running before the tests are started.
Yes, +1
Alright, that adds a bit of complexity, as developers have to remember
to start Cassandra before running tests. But I think it's a fair price
to pay.
I'll start working on that then, but we can keep discussing this :)
- Juca.
7:22 a.m.
2016-06-14 13:10 GMT+02:00 Juraci Paixão Kröhling <jpkroehling(a)redhat.com>:
On 14.06.2016 12:58, Heiko W.Rupp wrote:
> On 14 Jun 2016, at 12:20, Juraci Paixão Kröhling wrote:
>
>> before the test is executed. Or use an approach like Metrics, which
>> requires Cassandra to be running before the tests are started.
>
> Yes, +1
>
Alright, that adds a bit of complexity, as developers have to remember
to start Cassandra before running tests. But I think it's a fair price
to pay.
The added complexity is minimal really. For 'pip install ccm' works on all
platforms (well, Windows devs must install Python first)
And then you can create/manage the cluster you need in the version you
need. In just a few commands.
https://github.com/pcmanus/ccm
I'll start working on that then, but we can keep discussing this :)
- Juca.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
--
Thomas Segismont
JBoss ON Engineering Team
6:21 a.m.
On 14.06.2016 12:58, Heiko W.Rupp wrote:
On 14 Jun 2016, at 12:20, Juraci Paixão Kröhling wrote:
> - Keep everything as is, but change the default value for
> `hawkular.backend` to `remote` instead of the current `embedded_cassandra`
I think this needs to be the default no matter what is decided for the
next item.
If we don't ship Cassandra, then it makes no sense to have this
property, no? Or am I missing something?
- Juca.
8:21 a.m.
On 14 Jun 2016, at 13:21, Juraci Paixão Kröhling wrote:
On 14.06.2016 12:58, Heiko W.Rupp wrote:
> On 14 Jun 2016, at 12:20, Juraci Paixão Kröhling wrote:
>
>> - Keep everything as is, but change the default value for
>> `hawkular.backend` to `remote` instead of the current
>> `embedded_cassandra`
>
> I think this needs to be the default no matter what is decided for
> the
> next item.
If we don't ship Cassandra, then it makes no sense to have this
property, no? Or am I missing something?
I recall that multiple components evaluate this flag and
set the connection accordingly. But maybe I am confusing
it with CASSANDRA_NODES env variable right now.
This variable is only used though when hawkular.backend
is set to != embedded
8:49 a.m.
Wait, what? I didn't finish this thread but I just jumped out of my chair.
You mean I have to separately run and manage a C* cluster just to run itests?? Why would
we require that? So now the tests will always fail unless you have some extra server that
you run manually outside of the tests?
Plus, with that, it is not so simple anymore for Joe Developer to simply git clone and
"mvn clean install -Pitest" and see things work. They will now have to
separately install and run their own C* cluster (and first know that that has to be
done).
-1 that.
Forcing someone to run something OUTSIDE of the itest framework just to get the itests to
pass is wrong.
Or am I missing something? Will the itests framework run a standalone C* at the start and
shut it down after it finishes?
----- Original Message -----
On 14.06.2016 12:58, Heiko W.Rupp wrote:
> On 14 Jun 2016, at 12:20, Juraci Paixão Kröhling wrote:
>
>> - Keep everything as is, but change the default value for
>> `hawkular.backend` to `remote` instead of the current `embedded_cassandra`
>
> I think this needs to be the default no matter what is decided for the
> next item.
If we don't ship Cassandra, then it makes no sense to have this
property, no? Or am I missing something?
- Juca.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
9:28 a.m.
I agree with Mazz about the tests: tests should be predictable and fail
only when there's a failure on the *code*, so, having to install a
database, or having pre-existing data should *not* be something that
would break tests. At least for JPA modules, it's common to use an
embedded database for the tests, while the real module uses datasources
configured on the application server.
This problem could be avoided by having the integration tests to add the
embedded Cassandra WAR to the nest, binding it to a different port (to
avoid conflicting with possible Cassandra nodes running on the machine).
For dev builds: I'm not sure I like the idea of having embedded
Cassandra for dev builds but not for release builds. IMO, we should try
to not deviate too much, specially because we would catch problems only
when it's "too late". I'd rather require developers to install Cassandra
locally, on this scenario.
- Juca.
3114
days inactive
3114
days old
10 comments
6 participants
participants (6)
-
Heiko W.Rupp -
John Mazzitelli -
Juraci Paixão Kröhling -
Lucas Ponce -
Thomas Heute -
Thomas Segismont