Hi,
a lot of our current functionality assumes that fixed types are already present in the system via the plugin-descriptor.
Now with the dynamic type work by Alex the game has changed: there is a ChildTypeDiscoveryFacet that can detect new resource types and ChildTypeDiscovery classes can find resources of that type and the world is good again :)
But after a pc/agent restart, the type is not know (anymore), but resources of the type are commited in the server, which leads to situations like this:
2010-10-21 22:25:00,360 DEBUG [InventoryManager.discovery-1] (rhq.core.pc.inventory.InventoryManager)- Merging [Resource[id=10411, type=FooBar, key=nagiosKey@Nr: foo, name=nagiosKey@Nr: foo, parent=Nagios@pickeldi:6557]] into local inventory... 2010-10-21 22:25:00,360 ERROR [InventoryManager.discovery-1] (rhq.core.pc.inventory.InventoryManager)- Unable to merge Resource Resource[id=10411, type=FooBar, key=nagiosKey@Nr: foo, name=nagiosKey@Nr: foo, parent=Nagios@pickeldi:6557] - its type is unknown - perhaps the [NagiosMonitor] plugin jar was manually removed from the Server's rhq-plugins dir?
Is there an (easy) way to reconnect the resources to the type once the type got re-discovered as described above?
Thanks Heiko
Am 21.10.2010 um 22:31 schrieb Heiko W.Rupp:
Is there an (easy) way to reconnect the resources to the type once the type got re-discovered as described above?
Ah, I see near the end of org.rhq.core.pc.inventory.InventoryManager#mergeResource resource.setResourceType(fullResourceType);
resourceContainer = initResourceContainer(resource); ... refreshResourceComponentState(resourceContainer, pluginConfigUpdated);
I guess this would mean to find the resource without type once the type is known again and run those above lines. Or is there a better idea? Especially as it looks like the information about that resource is lost when the first merge fails
Heiko
Is there any documentation regarding the dynamic typing system? (or does it have any relation to http://rhq-project.org/display/RHQ/Design-Dynamic+Metadata )?
It seems like the types, once discovered, need to be persisted and merged on the server for consistency with the rest of the model... those would also need to be persistently sync'ed to the agents as well. Right?
-Greg
On Oct 21, 2010, at 4:37 PM, Heiko W.Rupp wrote:
Am 21.10.2010 um 22:31 schrieb Heiko W.Rupp:
Is there an (easy) way to reconnect the resources to the type once the type got re-discovered as described above?
Ah, I see near the end of org.rhq.core.pc.inventory.InventoryManager#mergeResource resource.setResourceType(fullResourceType);
resourceContainer = initResourceContainer(resource);
... refreshResourceComponentState(resourceContainer, pluginConfigUpdated);
I guess this would mean to find the resource without type once the type is known again and run those above lines. Or is there a better idea? Especially as it looks like the information about that resource is lost when the first merge fails
Heiko
-- Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München Handelsregister: Amtsgericht München HRB 153243 Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel
Hi,
Am 21.10.2010 um 22:42 schrieb Greg Hinkle:
Is there any documentation regarding the dynamic typing system? (or does it have any relation to http://rhq-project.org/display/RHQ/Design-Dynamic+Metadata )?
I think it is under the Nagios name (http://support.rhq-project.org/display/RHQ/Plugins+-+Nagios) and Alex will over the weekend latest update the wiki.
It seems like the types, once discovered, need to be persisted and merged on the server for consistency with the rest of the model... those would also need to be persistently sync'ed to the
They are (with the caveat that a plugin update will kill them, as the Metadata code assumes them as non-existent if they don't come from the plugin descriptor). And also added pc side.
agents as well. Right?
This persistency on the agent is not (yet) done which is one of the reasons, I posed my question :)
Thanks Heiko
Ok, So as Mazz is mentioning there's a few more things that are needed to finish this:
* Don't throw away "dynamic" types on plugin updates (this has implications... perhaps dynamic types should be like concrete implementations of an abstract type from the static metadata)
* Not sure if Types are being discovered on the server or agent, but they need to be able to be merged if happening from multiple places
* Need to be sync'ed down to the agents (when plugins are updated AND whenever the dynamic type is updated)
* Persisted on the agent so it can operate against the dynamic type data
Furthermore, what about "user edits" to this data. We originally conceived of scenarios where the admin would be able to select the MBeans he wanted to import and then be able to customize things like metric names, descriptions and which pieces would get exposed into the type system. This would call for another layer of change management to ensure user edits aren't overwritten by the type discovery mechanism.
-Greg
On Oct 21, 2010, at 4:47 PM, Heiko W.Rupp wrote:
Hi,
Am 21.10.2010 um 22:42 schrieb Greg Hinkle:
Is there any documentation regarding the dynamic typing system? (or does it have any relation to http://rhq-project.org/display/RHQ/Design-Dynamic+Metadata )?
I think it is under the Nagios name (http://support.rhq-project.org/display/RHQ/Plugins+-+Nagios) and Alex will over the weekend latest update the wiki.
It seems like the types, once discovered, need to be persisted and merged on the server for consistency with the rest of the model... those would also need to be persistently sync'ed to the
They are (with the caveat that a plugin update will kill them, as the Metadata code assumes them as non-existent if they don't come from the plugin descriptor). And also added pc side.
agents as well. Right?
This persistency on the agent is not (yet) done which is one of the reasons, I posed my question :)
Thanks Heiko
-- Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München Handelsregister: Amtsgericht München HRB 153243 Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel
Greg,
Am 21.10.2010 um 22:55 schrieb Greg Hinkle:
Ok, So as Mazz is mentioning there's a few more things that are needed to finish this:
Yes. Alex'w work was not meant as a finished 'product', but really as a proof of concept that dynamic types are possible with the concrete implementation of his Nagios Plugin
- Don't throw away "dynamic" types on plugin updates (this has implications... perhaps dynamic types should be like concrete implementations of an abstract type from the static metadata)
Or we add a flag to them, so that they do not get implicitly deleted
Heiko
On Oct 22, 2010, at 11:07 AM, Heiko W.Rupp wrote:
Greg,
Am 21.10.2010 um 22:55 schrieb Greg Hinkle:
Ok, So as Mazz is mentioning there's a few more things that are needed to finish this:
Yes. Alex'w work was not meant as a finished 'product', but really as a proof of concept that dynamic types are possible with the concrete implementation of his Nagios Plugin
Yup, best way to implement a feature like this. I'd like to volunteer to try the dynamic JMX version of this.
- Don't throw away "dynamic" types on plugin updates (this has implications... perhaps dynamic types should be like concrete implementations of an abstract type from the static metadata)
Or we add a flag to them, so that they do not get implicitly deleted
Right. That's exactly what I had in mind... but the idea of it being a concrete instance of an abstract type would still give the plugin developer the ability to remove them in a plugin upgrade. (If the abstract type is deleted from a plugin, it's concrete instances are deleted as well)
We'd also need flags for what types the admin has accepted and what types he's customized right? I think the types need to go through the sync process back to the server before discovery on them can run (as they may need to be merged with other instantiations of the same type or user customized versions)
Heiko
-- Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München Handelsregister: Amtsgericht München HRB 153243 Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel
Am 22.10.2010 um 17:13 schrieb Greg Hinkle:
Yup, best way to implement a feature like this. I'd like to volunteer to try the dynamic JMX version of this.
That would be awesome. Another thing that desperately needs this is SNMP(get) to get information from network devices.
Right. That's exactly what I had in mind... but the idea of it being a concrete instance of an abstract type would still give the plugin developer the ability to remove them in a plugin upgrade. (If the abstract type is deleted from a plugin, it's concrete instances are deleted as well)
Yes, interesting. This would also allow to predefine some metrics / operations / ... on that abstract type that would apply to all instances no matter what concrete subtype would be discovered.
We'd also need flags for what types the admin has accepted and what types he's customized right? I think the types need to go through the sync process back to the server before discovery on them can run (as they may need to be merged with other instantiations of the same type or user customized versions)
I did not have customization on the radar so far They are sent to the server and added to the agents inventory. The current version implies that all agents have the same plugins + detect the same custom types. That may actually be wrong - so I wonder if actually the agent name should be added to the type name if a 2nd instance of a found type from a different agent returns different metadata for it.
Heiko
Am 21.10.2010 um 22:42 schrieb Greg Hinkle:
Is there any documentation regarding the dynamic typing system? (or does it have any relation to
As I said, Alex will update the Wiki over the weekend
I've attached a sequence diagram that should outline what is currently going on.
Two key points are:
- A ChildTypeDiscoveryRunner is looking at servers that implement a ChildResourceTypeDiscoveryFacet and ask this for new types. - While parsing the plugin descriptor for the plugin, for said server, two new attributes on the <server> tag are evaluated:
childTypeDiscovery="NagiosMonitorChildTypeDiscovery" childTypeClass="NagiosMonitorChildTypeComponent"
Now when the service discovery runs and checks for children of the server, the PluginMetadataManager returns the respective childTypeDiscovery class for the new dynamic type.
And you are absolutely right about the work to do.
some background info that may or may not be relevent:
unlike resources, resource types are not synced with the server.
When the PC starts, it will sync its inventory with the server - essentially the server sends down all the information it knows about that agent's resources and the agent will reconcile that information (the server's information is authoritative - so if both the agent and server has information about a resource, the server's information "wins" and the agent will use the server data, throwing out whatever data it did have that conflicted with the server).
There is no syncing like that with types. The sync'ing is implicitly performed when the agent downloads/updates its plugins. The agent will guarantee that the PC gets the latest-n-greatest plugins. Because of this, when the PC starts up, all it needs to do is read the plugins' metadata and it knows it is synced with the server's metadata because the PC was told that the plugins it has has already been synced.
Now how is this related? Somehow, your dynamic metadata that is on the server needs to be sync'ed down to the agent - in the same way that resources are sync'ed today. How you would do that I dunno - but clearly, due to the fact that metadata is being created on the fly and stored on the server, there needs to be a way for the agent to download that metadata and reconcile it with whatever dynamic metadata the agent already has (maybe the agent persisted the metadata itself in the /data directory?).
On 10/21/2010 04:37 PM, Heiko W.Rupp wrote:
Am 21.10.2010 um 22:31 schrieb Heiko W.Rupp:
Is there an (easy) way to reconnect the resources to the type once the type got re-discovered as described above?
Ah, I see near the end of org.rhq.core.pc.inventory.InventoryManager#mergeResource resource.setResourceType(fullResourceType);
resourceContainer = initResourceContainer(resource);
... refreshResourceComponentState(resourceContainer, pluginConfigUpdated);
I guess this would mean to find the resource without type once the type is known again and run those above lines. Or is there a better idea? Especially as it looks like the information about that resource is lost when the first merge fails
Heiko
Am 21.10.2010 um 22:45 schrieb John Mazzitelli:
clearly, due to the fact that metadata is being created on the fly and stored on the server, there needs to be a way for the agent to download that metadata and reconcile it with whatever dynamic metadata the agent already has (maybe the agent persisted the metadata itself in the /data directory?).
And/or add some 'getTypesFromServer()' between plugins update and pc start. But storing them locally and reading from there probably makes a lot of sense.
Heiko
That might not be a bad solution. This would be analogous to the way we sync types now - the syncing of the plugins by the agent (prior to PC startup) is essentially how we sync types today. The agent could (after it syncs the plugins but before starting the PC) call a remote method on the server to obtain dynamic types and serialize the types in /data. The PC, on startup, would read in that /data file and deserialize those dynamic types right after it reads the plugins' metadata (which happens pretty early on in the PC startup). The dynamic types would be stored in the same collection as the static types - so once the PC is running, there would be no difference between dynamic and static types (in other words, the PC probably would have no reason to know or care if a type is dynamic or not - its just "a type" and that should be good enough).
On 10/21/2010 04:50 PM, Heiko W.Rupp wrote:
Am 21.10.2010 um 22:45 schrieb John Mazzitelli:
clearly, due to the fact that metadata is being created on the fly and stored on the server, there needs to be a way for the agent to download that metadata and reconcile it with whatever dynamic metadata the agent already has (maybe the agent persisted the metadata itself in the /data directory?).
And/or add some 'getTypesFromServer()' between plugins update and pc start. But storing them locally and reading from there probably makes a lot of sense.
Heiko
rhq-devel@lists.fedorahosted.org