3:30 a.m.
With embedded agents, we lost few main features:
- Ability to discover servers that are off or not (yet) instrumented
- Ability to start servers remotely
- Ability to report DOWN availability (other than by lack of UP)
Should we reintroduce a small (optional ?) host agent ?
The agent would only fulfill those tasks (+ embedded agent installer) and
redirect all other tasks to the embedded agents.
We can address a limited set of platforms (Linux only) to start with, and
maybe use environment specific features if those exists (Like RHEV-M host
agent if appropriate)
WDYT ?
Thomas
4:26 a.m.
IMHO, rather than implement our own, we should try to leverage some of the
already existing solutions in this area like collectd and only write a simple?
"proxy" for it that would take its input and send relevant info to metrics,
inventory and/or other hawkular components. Essentially we should enhance
ptrans to be a true piece of hawkular glue.
This could even sit as a middleman on a remote machine (or indeed on the
hawkular server itself) and manage a number of "native" agents.
On Tuesday, February 09, 2016 10:30:12 Thomas Heute wrote:
With embedded agents, we lost few main features:
- Ability to discover servers that are off or not (yet) instrumented
- Ability to start servers remotely
- Ability to report DOWN availability (other than by lack of UP)
Should we reintroduce a small (optional ?) host agent ?
The agent would only fulfill those tasks (+ embedded agent installer) and
redirect all other tasks to the embedded agents.
We can address a limited set of platforms (Linux only) to start with, and
maybe use environment specific features if those exists (Like RHEV-M host
agent if appropriate)
WDYT ?
Thomas
7:16 a.m.
When you say "discover servers" and "start servers" - what do you mean
by servers? WildFly servers or just machines (bare metal computers, VMs, etc)?
----- Original Message -----
With embedded agents, we lost few main features:
- Ability to discover servers that are off or not (yet) instrumented
- Ability to start servers remotely
- Ability to report DOWN availability (other than by lack of UP)
Should we reintroduce a small (optional ?) host agent ?
The agent would only fulfill those tasks (+ embedded agent installer) and
redirect all other tasks to the embedded agents.
We can address a limited set of platforms (Linux only) to start with, and
maybe use environment specific features if those exists (Like RHEV-M host
agent if appropriate)
WDYT ?
Thomas
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
7:17 a.m.
I mean WF servers
On Tue, Feb 9, 2016 at 2:16 PM, John Mazzitelli <mazz(a)redhat.com> wrote:
When you say "discover servers" and "start
servers" - what do you mean by
servers? WildFly servers or just machines (bare metal computers, VMs, etc)?
----- Original Message -----
>
> With embedded agents, we lost few main features:
> - Ability to discover servers that are off or not (yet) instrumented
> - Ability to start servers remotely
> - Ability to report DOWN availability (other than by lack of UP)
>
> Should we reintroduce a small (optional ?) host agent ?
>
> The agent would only fulfill those tasks (+ embedded agent installer) and
> redirect all other tasks to the embedded agents.
>
> We can address a limited set of platforms (Linux only) to start with, and
> maybe use environment specific features if those exists (Like RHEV-M host
> agent if appropriate)
>
> WDYT ?
>
> Thomas
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
8:20 a.m.
I mean WF servers
The Hawkular Wildfly Agent can monitor remote WildFly servers. It just doesn't
discover them nor does it have the ability to start them (but it does have the ability to
restart them, or shut them down).
The "embedded agent" can live in any WildFly server. So really, we could ship a
standalone agent that consists of nothing more than a vanilla WildFly Server with the
agent installed in it (we used to be able to run in WildFly Core, but I don't think it
can today with some dependencies the agent has). But a stripped down WildFly (removing
unused things like the tx manager, deployment scanner, things like that) could be used to
house a standalone agent.
If something can auto-discovery WildFly servers, they can issue JBoss CLI commands to the
wildfly server/agent combo to add a <remote-dmr> setting so that agent can start
monitoring those discovered servers. Or you can inject an agent to discovered WildFly
servers using the installer. What that "auto-discovery" process is, I dunno.
Just wanted to bring that up.
----- Original Message -----
I mean WF servers
>
> On Tue, Feb 9, 2016 at 2:16 PM, John Mazzitelli <mazz(a)redhat.com> wrote:
>
> > When you say "discover servers" and "start servers" - what
do you mean by
> > servers? WildFly servers or just machines (bare metal computers, VMs, etc)?
> >
> > ----- Original Message -----
> > >
> > > With embedded agents, we lost few main features:
> > > - Ability to discover servers that are off or not (yet) instrumented
> > > - Ability to start servers remotely
> > > - Ability to report DOWN availability (other than by lack of UP)
> > >
> > > Should we reintroduce a small (optional ?) host agent ?
> > >
> > > The agent would only fulfill those tasks (+ embedded agent installer) and
> > > redirect all other tasks to the embedded agents.
> > >
> > > We can address a limited set of platforms (Linux only) to start with, and
> > > maybe use environment specific features if those exists (Like RHEV-M host
> > > agent if appropriate)
> > >
> > > WDYT ?
> > >
> > > Thomas
> > >
> > > _______________________________________________
> > > hawkular-dev mailing list
> > > hawkular-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > >
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >
> >
> >
>
8:26 a.m.
Here the first problem I would like to solve is really to start a server
(say a server crashed) from Hawkular.
Second, discover servers that are not yet instrumented and/or started.
I'm looking for options (extending/reusing existing projects is definitely
a +1)
On Tue, Feb 9, 2016 at 3:20 PM, John Mazzitelli <mazz(a)redhat.com> wrote:
> I mean WF servers
The Hawkular Wildfly Agent can monitor remote WildFly servers. It just
doesn't discover them nor does it have the ability to start them (but it
does have the ability to restart them, or shut them down).
The "embedded agent" can live in any WildFly server. So really, we could
ship a standalone agent that consists of nothing more than a vanilla
WildFly Server with the agent installed in it (we used to be able to run in
WildFly Core, but I don't think it can today with some dependencies the
agent has). But a stripped down WildFly (removing unused things like the tx
manager, deployment scanner, things like that) could be used to house a
standalone agent.
If something can auto-discovery WildFly servers, they can issue JBoss CLI
commands to the wildfly server/agent combo to add a <remote-dmr> setting so
that agent can start monitoring those discovered servers. Or you can inject
an agent to discovered WildFly servers using the installer. What that
"auto-discovery" process is, I dunno.
Just wanted to bring that up.
----- Original Message -----
> I mean WF servers
>
> On Tue, Feb 9, 2016 at 2:16 PM, John Mazzitelli <mazz(a)redhat.com> wrote:
>
> > When you say "discover servers" and "start servers" - what
do you mean
by
> > servers? WildFly servers or just machines (bare metal computers, VMs,
etc)?
> >
> > ----- Original Message -----
> > >
> > > With embedded agents, we lost few main features:
> > > - Ability to discover servers that are off or not (yet) instrumented
> > > - Ability to start servers remotely
> > > - Ability to report DOWN availability (other than by lack of UP)
> > >
> > > Should we reintroduce a small (optional ?) host agent ?
> > >
> > > The agent would only fulfill those tasks (+ embedded agent
installer) and
> > > redirect all other tasks to the embedded agents.
> > >
> > > We can address a limited set of platforms (Linux only) to start
with, and
> > > maybe use environment specific features if those exists (Like RHEV-M
host
> > > agent if appropriate)
> > >
> > > WDYT ?
> > >
> > > Thomas
> > >
> > > _______________________________________________
> > > hawkular-dev mailing list
> > > hawkular-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > >
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >
> >
> >
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
6:53 a.m.
Hi,
Or could we use ssh to command these Wildfly instances? Kinda like in the RHQ we had
remote agent installation using ssh, but now instead we could do Wildfly/EAP instance
management with remote commands (thus giving us "agentless" management
solution). I know this time we should probably solve the ssh key issue as well, but in any
case it seems kinda important to be able to start an instance (otherwise it's kinda
useless management tool).
Unless we hope that everything is ran with Openshift & Docker..
- Micke
----- Original Message -----
From: "Thomas Heute" <theute(a)redhat.com>
To: "John Mazzitelli" <mazz(a)redhat.com>, "Discussions around Hawkular
development" <hawkular-dev(a)lists.jboss.org>
Sent: Tuesday, February 9, 2016 4:26:32 PM
Subject: Re: [Hawkular-dev] Host agent ?
Here the first problem I would like to solve is really to start a server (say a server
crashed) from Hawkular.
Second, discover servers that are not yet instrumented and/or started.
I'm looking for options (extending/reusing existing projects is definitely a +1)
On Tue, Feb 9, 2016 at 3:20 PM, John Mazzitelli < mazz(a)redhat.com > wrote:
I mean WF servers
The Hawkular Wildfly Agent can monitor remote WildFly servers. It just doesn't
discover them nor does it have the ability to start them (but it does have the ability to
restart them, or shut them down).
The "embedded agent" can live in any WildFly server. So really, we could ship a
standalone agent that consists of nothing more than a vanilla WildFly Server with the
agent installed in it (we used to be able to run in WildFly Core, but I don't think it
can today with some dependencies the agent has). But a stripped down WildFly (removing
unused things like the tx manager, deployment scanner, things like that) could be used to
house a standalone agent.
If something can auto-discovery WildFly servers, they can issue JBoss CLI commands to the
wildfly server/agent combo to add a <remote-dmr> setting so that agent can start
monitoring those discovered servers. Or you can inject an agent to discovered WildFly
servers using the installer. What that "auto-discovery" process is, I dunno.
Just wanted to bring that up.
----- Original Message -----
I mean WF servers
>
> On Tue, Feb 9, 2016 at 2:16 PM, John Mazzitelli < mazz(a)redhat.com > wrote:
>
> > When you say "discover servers" and "start servers" - what
do you mean by
> > servers? WildFly servers or just machines (bare metal computers, VMs, etc)?
> >
> > ----- Original Message -----
> > >
> > > With embedded agents, we lost few main features:
> > > - Ability to discover servers that are off or not (yet) instrumented
> > > - Ability to start servers remotely
> > > - Ability to report DOWN availability (other than by lack of UP)
> > >
> > > Should we reintroduce a small (optional ?) host agent ?
> > >
> > > The agent would only fulfill those tasks (+ embedded agent installer) and
> > > redirect all other tasks to the embedded agents.
> > >
> > > We can address a limited set of platforms (Linux only) to start with, and
> > > maybe use environment specific features if those exists (Like RHEV-M host
> > > agent if appropriate)
> > >
> > > WDYT ?
> > >
> > > Thomas
> > >
> > > _______________________________________________
> > > hawkular-dev mailing list
> > > hawkular-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > >
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >
> >
> >
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
9:44 a.m.
On Feb 10, 2016, at 8:13 AM, Heiko W.Rupp <hrupp(a)redhat.com>
wrote:
On 10 Feb 2016, at 13:53, Michael Burman wrote:
> Or could we use ssh to command these Wildfly instances? Kinda like in
> the RHQ we had remote agent installation
If we go that route, we should consider using Ansible for the
task.
Wouldn’t introducing/requiring Ansible to handle (re)starts be a bit overkill?
9:55 a.m.
On 10.02.2016 16:44, John Sanda wrote:
Wouldn’t introducing/requiring Ansible to handle (re)starts be a bit
overkill?
For starting standalone Wildfly instances, yes. But I think this opens a
door for future features, while keeping key management out of our sight.
For instance, we could later on implement a list of timers and their
statuses (systemctl list-timers), a list of services that are running,
start/stop/restart services and so on.
- Juca.
3025
days inactive
3026
days old
9 comments
7 participants
participants (7)
-
Heiko W.Rupp -
John Mazzitelli -
John Sanda -
Juraci Paixão Kröhling -
Lukas Krejci -
Michael Burman -
Thomas Heute