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@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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev



_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev