Uploaded image for project: 'Infinispan'
  1. Infinispan
  2. ISPN-219

More sophisticated discovery of Infinispan instances from JOPR agent




      Currently, JOPR agent to Infinispan discovery is hardcoded to localhost. This needs further sophistication as indicated in:

      Oct 01 10:39:25 <galderz> pilhuhn, one question
      Oct 01 10:39:40 <galderz> the <plugin-configuration>, who uses it?
      Oct 01 10:40:05 <pilhuhn> that is used to pass in connection properties
      Oct 01 10:40:15 <galderz> to who?
      Oct 01 10:40:27 <galderz> to the jopr plugin itself?
      Oct 01 10:40:42 <pilhuhn> So in the ispn case, the remote jnp url would go int there , yes the plugin itself
      Oct 01 10:40:56 <pilhuhn> in the plugin DiscoveryCOmponent you e.g. do
      Oct 01 10:41:01 <galderz> right, so that currently is not in use at all, correct?
      Oct 01 10:41:07 <pilhuhn> yes
      Oct 01 10:41:23 <pilhuhn> Configuration c = resourceDiscoveryContext.getConfiguration();
      Oct 01 10:41:49 <galderz> and what's c:template about?
      Oct 01 10:42:04 <pilhuhn> String jnp Url = c.getSimpleProperty("xxx", "jmx:servive......"); with xxx being the property name from the deployment descirptor
      Oct 01 10:42:23 <pilhuhn> c:template allows you to provide tempates for the values a user can enter
      Oct 01 10:44:12 <pilhuhn> have a look at http://viewvc.rhq-project.org/cgi-bin/viewvc.cgi/rhq/trunk/modules/plugins/twitter/src/main/resources/META-INF/rhq-plugin.xml?view=log
      Oct 01 10:44:27 <galderz> so, let me get one thing straight
      Oct 01 10:44:43 <galderz> does it make sense to have anything other than localhost in the connectorAddress?
      Oct 01 10:44:56 <pilhuhn> There are 2 templates for Twitter and identi.ca that pre-fill the basic connection properties for that plugin to connect to the remote services
      Oct 01 10:45:07 <galderz> at the end of the day, can u assume the plugin will always be local to the infinispan instance?
      Oct 01 10:45:44 <pilhuhn> This depends on your usage. If you want an agent on all nodes with ispn on, then you can assume localhost
      Oct 01 10:46:02 <galderz> well, we have to make a choice
      Oct 01 10:46:11 <galderz> or rethink this cos either
      Oct 01 10:46:19 <pilhuhn> if you say that you only want one agent for e.g. 10 ispn nodes, then not :->
      Oct 01 10:46:21 <galderz> the rhq-plugin.xml is generated at build it
      Oct 01 10:46:59 <galderz> i think that at least
      Oct 01 10:47:17 <pilhuhn> A plugin can support manual-add and autodiscovery. Meaning that you can autodiscover ispn on the localhost and stil have a user manually add an instance on a remote host - here he has to provide the correct connection properties
      Oct 01 10:47:19 <galderz> that the port and host need to have a ${:} format
      Oct 01 10:47:54 <galderz> so that at least, when u start the agent, u can pass (optionally) the location of the infinispan instance
      Oct 01 10:48:04 <pilhuhn> That is done via c.getSimpleProperty(propertyName, defaultValue) in the plugin code
      Oct 01 10:48:28 <pilhuhn> but yes, you could do it your way too
      Oct 01 10:48:48 <galderz> hmmm, not sure if I like default values in code rather than in xml
      Oct 01 10:49:05 <galderz> but let me have a think about it
      Oct 01 10:49:33 <galderz> so, to get this right
      Oct 01 10:49:42 <galderz> how do u call up on the default template?
      Oct 01 10:49:58 <galderz> iow, how do I get the default template values?
      Oct 01 10:50:25 <pilhuhn> hm. dunno if you can get them.
      Oct 01 10:50:40 <pilhuhn> stop
      Oct 01 10:50:44 <pilhuhn> let me rephrase
      Oct 01 10:51:34 <pilhuhn> IIrc you get this just passed in (the default values you specify in plugin-xml) when you call c.getSimpleProperty();
      Oct 01 10:54:22 <galderz> another question, how can an agent connect to multiple infinispan instances?
      Oct 01 10:54:27 <galderz> each in different host and port?
      Oct 01 10:55:00 <pilhuhn> yes
      Oct 01 10:55:06 <galderz> how?
      Oct 01 10:55:19 <pilhuhn> You just need one resource in inventory per ispn instance
      Oct 01 10:55:40 <galderz> but the agent, how does it connect to each?
      Oct 01 10:55:49 <galderz> the agent has a single connectorAddress
      Oct 01 10:56:05 <galderz> so how on earth does it discover several instances in diff nodes?
      Oct 01 10:57:22 <pilhuhn> you could in the Discovery component e.g. sweep a whole subnet. Just do a loop for each IP, and if an ispn instance is found, create one DiscoveredResourceDetails object per instance found and return all of those instances
      Oct 01 10:58:25 <pilhuhn> or you could, if you have found one, (require one to start at localhost) ask this ispn instance for connection data of other instances in the grid and then create the DiscoveredResourceDetails objects for all of those
      Oct 01 10:58:28 <galderz> right, so the connector address is no longer a simple property
      Oct 01 10:58:38 <galderz> but makes sense to implement it as a list property
      Oct 01 10:58:45 <pilhuhn> no
      Oct 01 10:59:13 <pilhuhn> each resource runs in a separate context. per resource we instantiate one IspnComponent class
      Oct 01 10:59:32 <pilhuhn> with its own set of values for the plugin config
      Oct 01 10:59:49 <galderz> i don't get this
      Oct 01 10:59:57 <galderz> the plugin runs in an agent
      Oct 01 11:00:01 <galderz> that executes the discoveru
      Oct 01 11:00:05 <pilhuhn> yes
      Oct 01 11:00:13 <galderz> how do u past a list of ispn isstance urls to that plugin?
      Oct 01 11:00:20 <galderz> so that discovery can act on each of them?
      Oct 01 11:00:34 <pilhuhn> ah ok, yes that could be done via list
      Oct 01 11:00:37 <galderz> i.e. node1:6996, node2:6996...etc
      Oct 01 11:00:43 <pilhuhn> But then the user needs to provide the list
      Oct 01 11:00:59 <galderz> via a sys property
      Oct 01 11:01:14 <pilhuhn> what I was thinking is that you require 1 ispn instance on the host, the agent runs on.
      Oct 01 11:01:15 <galderz> it's not uncommon to have properties that act either as single value or lists
      Oct 01 11:02:01 <galderz> i..e tcpping host names
      Oct 01 11:02:09 <galderz> the possibilities are varios here, i agree
      Oct 01 11:02:17 <pilhuhn> ispn should know its topology?
      Oct 01 11:02:30 <galderz> ispn knows about the cluster
      Oct 01 11:02:37 <galderz> but an agent could be managing diff clusters
      Oct 01 11:02:40 <galderz> that don't talk to each other
      Oct 01 11:03:02 <galderz> anyway, this requires further thought
      Oct 01 11:03:22 <galderz> the easiest way is simply: 1 agent, 1 ispn instance
      Oct 01 11:03:38 <pilhuhn> yes
      Oct 01 11:04:00 <galderz> i'll suggest diff solutions in the list and see which ones make most sense to implement before GA




            gzamarre Galder ZamarreƱo
            gzamarre Galder ZamarreƱo
            0 Vote for this issue
            0 Start watching this issue