Service discovery: should we use SLP?

Stephen C. Tweedie sct at redhat.com
Mon Jun 24 12:36:59 UTC 2013


Hi,

On Fri, 2013-06-21 at 17:00 +0200, Tomáš Smetana wrote:

>   I have mentioned this several times before: I had been asked to provide
> some example scripts that would "for every computer on the network... do
> something".  It's not quite obvious how to actually find every WBEM-capable
> device on the network.

I'm not sure we _want_ to.  I expect that it's usually more a case of
"find all devices which match criteria $TEST" than "find absolutely
every device and give me the full list."  On a large network,
pre-pruning the set of systems is going to be important.  

(For small numbers you can probably just run the test on each one and
avoid the complexity, of course.)

Certainly tools like puppet/facter or mcollective support flexible ways
to select managed systems based on various info known about them.

So the next question for me would be, how would we model system info in
an SLP environment to allow that selectivity?  Require the CIM
infrastructure to interrogate system properties for all discovered
systems, or expose some basic granular per-system info over SLP itself?
The latter would seen to allow us to minimise network traffic, although
it would imply sending system-specific info over a channel not secured
by OpenLMI's own ssl connection, so we'd have to be careful about how we
do it.

It certainly _looks_ like we can do this via SLP --- 

> [tsmetana at zaphod ~]$ slptool -u f-19-local findattrs service:wbem
> (template-url-syntax=https://192.168.122.12:5989),(service-id=PG:192-168-122-12),(service-hi-name=Pegasus),(service-hi-description=Pegasus OpenPegasus Version 2.12.1 Development),(template-type=wbem),(template-version=1.0),(template-description=This template describes the attributes used for advertising Pegasus CIM Servers.),(InteropSchemaNamespace=root/PG_InterOp),(FunctionalProfilesSupported=Basic Read,Basic Write,Schema Manipulation,Instance Manipulation, 
> ...

as there seems to be a bunch of metadata already exposed here.

Any thoughts?

--Stephen




More information about the openlmi-devel mailing list