10:07 a.m.
I am playing with the new hawkular services distro to see if it can get me moving again
with the "no more accounts, need to pass tenant header" stuff:
https://github.com/hawkular/hawkular-services/pull/1
Has anyone played with this? It appears there is no default user created so that means
this isn't a fully working distro yet - at least you can't unzip, run, and expect
things to work.
There doesn't exist a -Pdev profile that you can use to build a distro for demo and
developer purposes (like our old kettle builds, -Pdev would give you a jdoe:password user
to play with).
Am I missing something or is this just not fully cooked yet?
3:29 a.m.
Hi Mazz, inline...
On 2016-05-20 17:07, John Mazzitelli wrote:
I am playing with the new hawkular services distro to see if it can
get me moving again with the "no more accounts, need to pass tenant header"
stuff:
https://github.com/hawkular/hawkular-services/pull/1
Has anyone played with this? It appears there is no default user created so that means
this isn't a fully working distro yet - at least you can't unzip, run, and expect
things to work.
There doesn't exist a -Pdev profile that you can use to build a distro for demo and
developer purposes (like our old kettle builds, -Pdev would give you a jdoe:password user
to play with).
I have added maven dev profile yesterday, that adds jdoe:password. The
present state of the PR#1 also boots without any apparent failures. Now,
we need to figure out how to itest it.
-- P
3:48 a.m.
On 24.05.2016 10:29, Peter Palaga wrote:
I have added maven dev profile yesterday, that adds jdoe:password.
The
present state of the PR#1 also boots without any apparent failures. Now,
we need to figure out how to itest it.
Let me put my QE hat and share my thoughts: Hawkular Services REST
endpoints is what we expose as API to other clients, like agents, the Go
client, the Ruby client and so on. What is done "inside" doesn't matter
much, as long as this API is stable. So, I'd build a set of use cases
and do a set of independent test cases, which could in turn be run by
CI/CD platform.
We could even get fancy and do it using some "Given/When/Then" framework
like Cucumber, so that end users can use it as reference on how to use
Hawkular Services.
- Juca.
4:38 a.m.
Hi *,
PR#1 was just merged and you are all invited to build and try the
Services [1]. You may want to build with -Pdev to get a distro with
jdoe:password.
[1] https://github.com/hawkular/hawkular-services
More inline...
On 2016-05-24 10:48, Juraci Paixão Kröhling wrote:
On 24.05.2016 10:29, Peter Palaga wrote:
> I have added maven dev profile yesterday, that adds jdoe:password. The
> present state of the PR#1 also boots without any apparent failures. Now,
> we need to figure out how to itest it.
Let me put my QE hat and share my thoughts: Hawkular Services REST
endpoints is what we expose as API to other clients, like agents, the Go
client, the Ruby client and so on. What is done "inside" doesn't matter
much, as long as this API is stable. So, I'd build a set of use cases
and do a set of independent test cases, which could in turn be run by
CI/CD platform.
We could even get fancy and do it using some "Given/When/Then" framework
like Cucumber, so that end users can use it as reference on how to use
Hawkular Services.
@Juca: I am not sure if you are proposing to create a new wide-coverage
test suite in Services git repo. I do not think that Services is a good
place for maintaining such a wide-coverage test suite. I think that
individual components should take care for their all-covering test
suites in their respective git repos.
As I said earlier on IRC, we should either (a) have a few basic smoke
tests in Services git repo, or (b) we should find a way to run itests
pulled as test-jars from the components' repos.
I think that (a) is a safer bet for now. Actually, the e2e tests now
present in Hawkular could be taken as a good starting point for what we
need here in Services.
Thanks,
Peter
- Juca.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
5:16 a.m.
On 24.05.2016 11:38, Peter Palaga wrote:
@Juca: I am not sure if you are proposing to create a new
wide-coverage
test suite in Services git repo. I do not think that Services is a good
place for maintaining such a wide-coverage test suite. I think that
individual components should take care for their all-covering test
suites in their respective git repos.
As I said earlier on IRC, we should either (a) have a few basic smoke
tests in Services git repo, or (b) we should find a way to run itests
pulled as test-jars from the components' repos.
I think that (a) is a safer bet for now. Actually, the e2e tests now
present in Hawkular could be taken as a good starting point for what we
need here in Services.
+1 . I was trying to avoid having duplicate logic/tests by having one
place that could be used as reference on "how to consume Hawkular
Services" (instead of "how to consume Metrics") and what to expect from
Inventory when you create something on Metrics, but in the end, there's
nothing special on Hawkular Services that doesn't exist on the
individual components themselves, I suppose. So, this would also be
redundant.
- Juca.
7:24 a.m.
On 24 May 2016, at 10:48, Juraci Paixão Kröhling wrote:
Let me put my QE hat and share my thoughts: Hawkular Services REST
endpoints is what we expose as API to other clients, like agents, the
Go
client, the Ruby client and so on. What is done "inside" doesn't
matter
much, as long as this API is stable. So, I'd build a set of use cases
and do a set of independent test cases, which could in turn be run by
CI/CD platform.
+1
In fact the ruby-client's test suite already tests a lot of this (*) and
could be used for this purpose
*) Standard operation mode is though to run against recorded cassettes,
so we would need to invest a bit more to reliably run with live-requests
against hawkular-services
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschäftsführer: Paul Argiry, Charles Cachera, Michael Cunningham,
Michael O'Neill
7:27 a.m.
----- Mensaje original -----
De: "Heiko W.Rupp" <hrupp(a)redhat.com>
Para: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
Enviados: Martes, 24 de Mayo 2016 14:24:51
Asunto: Re: [Hawkular-dev] the new hawkular services distro
On 24 May 2016, at 10:48, Juraci Paixão Kröhling wrote:
> Let me put my QE hat and share my thoughts: Hawkular Services REST
> endpoints is what we expose as API to other clients, like agents, the
> Go
> client, the Ruby client and so on. What is done "inside" doesn't
> matter
> much, as long as this API is stable. So, I'd build a set of use cases
> and do a set of independent test cases, which could in turn be run by
> CI/CD platform.
+1
In fact the ruby-client's test suite already tests a lot of this (*) and
could be used for this purpose
*) Standard operation mode is though to run against recorded cassettes,
so we would need to invest a bit more to reliably run with live-requests
against hawkular-services
+1
I like the idea to maintain the itest on the component to focus on pure REST API specifics
and use the client(s) (ruby here as it is most mature, but this can change on the future)
to test a wider integration test usecases.
7:39 a.m.
I'd say Golang client is the most mature as it's the only one in production use ;)
(and those production use-cases are included in its tests). But of course it's metrics
only.
Metrics itself has large amount of rest-tests, so repeating all of those makes no sense.
They could be run against a live Hawkular Services instance though.
- Micke
----- Original Message -----
From: "Lucas Ponce" <lponce(a)redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
Sent: Tuesday, May 24, 2016 3:27:52 PM
Subject: Re: [Hawkular-dev] the new hawkular services distro
----- Mensaje original -----
De: "Heiko W.Rupp" <hrupp(a)redhat.com>
Para: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
Enviados: Martes, 24 de Mayo 2016 14:24:51
Asunto: Re: [Hawkular-dev] the new hawkular services distro
On 24 May 2016, at 10:48, Juraci Paixão Kröhling wrote:
> Let me put my QE hat and share my thoughts: Hawkular Services REST
> endpoints is what we expose as API to other clients, like agents, the
> Go
> client, the Ruby client and so on. What is done "inside" doesn't
> matter
> much, as long as this API is stable. So, I'd build a set of use cases
> and do a set of independent test cases, which could in turn be run by
> CI/CD platform.
+1
In fact the ruby-client's test suite already tests a lot of this (*) and
could be used for this purpose
*) Standard operation mode is though to run against recorded cassettes,
so we would need to invest a bit more to reliably run with live-requests
against hawkular-services
+1
I like the idea to maintain the itest on the component to focus on pure REST API specifics
and use the client(s) (ruby here as it is most mature, but this can change on the future)
to test a wider integration test usecases.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
3138
days inactive
3142
days old
7 comments
6 participants
participants (6)
-
Heiko W.Rupp -
John Mazzitelli -
Juraci Paixão Kröhling -
Lucas Ponce -
Michael Burman -
Peter Palaga