4:01 p.m.
I added this comment to a JIRA:
https://issues.jboss.org/browse/HAWKULAR-1261?focusedCommentId=13476371&a...
This is to discuss how we want things to work wrt the agent pulling down configuration
from the server.
This is going to require me to rip up parts of the agent and i want to avoid doing
unnecessary work because it will not be trivial. Thus, I need to know how we want it to
work before I do anything.
Please enter your comments in that JIRA.
Or we can discuss in #hawkular.
8:17 p.m.
Can we maybe get something like a google doc started for this? I find that
can be a bit easier to collaborate on than with just the jira.
It might also be good to reserve a time to have a call to discuss this over
bluejeans.
As far as I can tell, the plan isn't to have server side configurations
(like you would with a pull model) but instead to continue to have client
side configurations but have the server be able to push out updates to the
client.
Will this require a new component to expose REST endpoints at the server
level? or are we planning on reusing an existing component?
Are we going to be able to have individual configurations per server, or
are we lumping things into server types (eg all EAP7 instances have the
same configuration)
On Thu, Oct 12, 2017 at 10:01 AM, John Mazzitelli <mazz(a)redhat.com> wrote:
I added this comment to a JIRA:
https://issues.jboss.org/browse/HAWKULAR-1261?focusedCommentId=13476371&
page=com.atlassian.jira.plugin.system.issuetabpanels:
comment-tabpanel#comment-13476371
This is to discuss how we want things to work wrt the agent pulling down
configuration from the server.
This is going to require me to rip up parts of the agent and i want to
avoid doing unnecessary work because it will not be trivial. Thus, I need
to know how we want it to work before I do anything.
Please enter your comments in that JIRA.
Or we can discuss in #hawkular.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
9:18 p.m.
It might also be good to reserve a time to have a call to discuss
this over
bluejeans.
As far as I can tell, the plan isn't to have server side configurations
(like you would with a pull model) but instead to continue to have client
side configurations but have the server be able to push out updates to the
client.
The idea isn't a "push from server to agent", rather its the agent pulling
its config from the server.
Will this require a new component to expose REST endpoints at the
server
level? or are we planning on reusing an existing component?
We already have something in place today:
https://github.com/hawkular/hawkular-commons/blob/mwm-wildfly/hawkular-in...
Are we going to be able to have individual configurations per server,
or
are we lumping things into server types (eg all EAP7 instances have the
same configuration)
Preferably we are going to be grouping config based on server type. I mention an example
in the JIRA comment:
These server-side configuration files are centrally located and will define types for all
servers to be managed. There is not going to be one uber file. There will be two files per
server kind (two files because one is for jmx exporter, the other is for our agent).
e.g.
EAP-7.0.0-Final-jmx-exporter.yaml
EAP-7.0.0-Final-inventory.yaml
Fuse-1.1.0-RC2-jmx-exporter.yaml
Fuse-1.1.0-RC2-inventory.yaml
So when EAP 7.1 is released, we'll just add two new files to the central location on
the server and the agent can start downloading those to managed EAP 7.1 servers.
11:20 p.m.
On 10/12/2017 3:18 PM, John Mazzitelli wrote:
> It might also be good to reserve a time to have a call to discuss
this over
> bluejeans.
>
> As far as I can tell, the plan isn't to have server side configurations
> (like you would with a pull model) but instead to continue to have client
> side configurations but have the server be able to push out updates to the
> client.
The idea isn't a "push from server to agent", rather its the agent pulling
its config from the server.
When you say, "As far as I can tell, the plan isn't to have server side
configurations", where is that coming from? It's true that in the
past we had agent-side
config, but it has been a while now that we've planned on going to a
centralized config, to avoid unnecessary complexity and to minimize the
need to update
agents. Anyway, as Mazz points out, the mechanism is already there to
serve up the files. I just wanted to make sure there isn't a change in
plan, or a doc, that
I'm not aware of.
> Will this require a new component to expose REST endpoints at the
server
> level? or are we planning on reusing an existing component?
We already have something in place today:
https://github.com/hawkular/hawkular-commons/blob/mwm-wildfly/hawkular-in...
> Are we going to be able to have individual configurations per server, or
> are we lumping things into server types (eg all EAP7 instances have the
> same configuration)
Preferably we are going to be grouping config based on server type. I mention an example
in the JIRA comment:
These server-side configuration files are centrally located and will define types for all
servers to be managed. There is not going to be one uber file. There will be two files per
server kind (two files because one is for jmx exporter, the other is for our agent).
e.g.
EAP-7.0.0-Final-jmx-exporter.yaml
EAP-7.0.0-Final-inventory.yaml
Fuse-1.1.0-RC2-jmx-exporter.yaml
Fuse-1.1.0-RC2-inventory.yaml
So when EAP 7.1 is released, we'll just add two new files to the central location on
the server and the agent can start downloading those to managed EAP 7.1 servers.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
9:03 a.m.
Just adding here, that the new model (as it is currently defined) makes it
mandatory to have unique resource type definition per server ; that is, the
resource types definitions cannot vary from an agent to another.
Technically speaking, it doesn't have feedId.
On Thu, Oct 12, 2017 at 11:20 PM, Jay Shaughnessy <jshaughn(a)redhat.com>
wrote:
On 10/12/2017 3:18 PM, John Mazzitelli wrote:
>> It might also be good to reserve a time to have a call to discuss this
over
>> bluejeans.
>>
>> As far as I can tell, the plan isn't to have server side configurations
>> (like you would with a pull model) but instead to continue to have
client
>> side configurations but have the server be able to push out updates to
the
>> client.
> The idea isn't a "push from server to agent", rather its the agent
pulling its config from the server.
When you say, "As far as I can tell, the plan isn't to have server side
configurations", where is that coming from? It's true that in the
past we had agent-side
config, but it has been a while now that we've planned on going to a
centralized config, to avoid unnecessary complexity and to minimize the
need to update
agents. Anyway, as Mazz points out, the mechanism is already there to
serve up the files. I just wanted to make sure there isn't a change in
plan, or a doc, that
I'm not aware of.
>> Will this require a new component to expose REST endpoints at the server
>> level? or are we planning on reusing an existing component?
> We already have something in place today:
>
> https://github.com/hawkular/hawkular-commons/blob/mwm-
wildfly/hawkular-inventory-parent/hawkular-inventory-
service/src/main/java/org/hawkular/inventory/handlers/
InventoryHandlers.java#L78-L94
>
>> Are we going to be able to have individual configurations per server, or
>> are we lumping things into server types (eg all EAP7 instances have the
>> same configuration)
> Preferably we are going to be grouping config based on server type. I
mention an example in the JIRA comment:
>
> These server-side configuration files are centrally located and will
define types for all servers to be managed. There is not going to be one
uber file. There will be two files per server kind (two files because one
is for jmx exporter, the other is for our agent).
>
> e.g.
> EAP-7.0.0-Final-jmx-exporter.yaml
> EAP-7.0.0-Final-inventory.yaml
> Fuse-1.1.0-RC2-jmx-exporter.yaml
> Fuse-1.1.0-RC2-inventory.yaml
>
> So when EAP 7.1 is released, we'll just add two new files to the central
location on the server and the agent can start downloading those to managed
EAP 7.1 servers.
> _______________________________________________
> 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
11:07 p.m.
Actually, the resource types are global across [hawkular] servers as
well, right? We'd likely use the same agent config files across
multiple server instances.
On 10/13/2017 3:03 AM, Joel Takvorian wrote:
Just adding here, that the new model (as it is currently defined)
makes it mandatory to have unique resource type definition per server
; that is, the resource types definitions cannot vary from an agent to
another.
Technically speaking, it doesn't have feedId.
On Thu, Oct 12, 2017 at 11:20 PM, Jay Shaughnessy <jshaughn(a)redhat.com
<mailto:jshaughn@redhat.com>> wrote:
On 10/12/2017 3:18 PM, John Mazzitelli wrote:
>> It might also be good to reserve a time to have a call to
discuss this over
>> bluejeans.
>>
>> As far as I can tell, the plan isn't to have server side
configurations
>> (like you would with a pull model) but instead to continue to
have client
>> side configurations but have the server be able to push out
updates to the
>> client.
> The idea isn't a "push from server to agent", rather its the
agent pulling its config from the server.
When you say, "As far as I can tell, the plan isn't to have server
side
configurations", where is that coming from? It's true that in the
past we had agent-side
config, but it has been a while now that we've planned on going to a
centralized config, to avoid unnecessary complexity and to
minimize the
need to update
agents. Anyway, as Mazz points out, the mechanism is already there to
serve up the files. I just wanted to make sure there isn't a
change in
plan, or a doc, that
I'm not aware of.
>> Will this require a new component to expose REST endpoints at
the server
>> level? or are we planning on reusing an existing component?
> We already have something in place today:
>
>
https://github.com/hawkular/hawkular-commons/blob/mwm-wildfly/hawkular-in...
<https://github.com/hawkular/hawkular-commons/blob/mwm-wildfly/hawkular-in...
>
>> Are we going to be able to have individual configurations per
server, or
>> are we lumping things into server types (eg all EAP7 instances
have the
>> same configuration)
> Preferably we are going to be grouping config based on server
type. I mention an example in the JIRA comment:
>
> These server-side configuration files are centrally located and
will define types for all servers to be managed. There is not
going to be one uber file. There will be two files per server kind
(two files because one is for jmx exporter, the other is for our
agent).
>
> e.g.
> EAP-7.0.0-Final-jmx-exporter.yaml
> EAP-7.0.0-Final-inventory.yaml
> Fuse-1.1.0-RC2-jmx-exporter.yaml
> Fuse-1.1.0-RC2-inventory.yaml
>
> So when EAP 7.1 is released, we'll just add two new files to the
central location on the server and the agent can start downloading
those to managed EAP 7.1 servers.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org <mailto:hawkular-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
<https://lists.jboss.org/mailman/listinfo/hawkular-dev>
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org <mailto:hawkular-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/hawkular-dev
<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
2391
days inactive
2395
days old
5 comments
4 participants
participants (4)
-
Jay Shaughnessy -
Joel Takvorian -
John Mazzitelli -
Matthew Wringe