RE: Port selection

I agree with Kirk.  If the system is going to be compliant with SMI-S, there can only be 1 instantiation of the Base Server Profile on the system.  And the only way that can happen is if all providers are running under a single CIMOM and that CIMOM provides the Base Server Profile instance.

Dave Barrett

From: Kirk Augustin [mailto:[email protected]]
Sent: Friday, October 21, 2011 1:58 PM
To: [email protected]; [email protected]
Cc: [email protected]; [email protected]; [email protected]
Subject: Re: Port selection

That is not an answer.
It is not scalable.
That would potentially lead to each vender requiring its own server.
In which case CIM is pointless.
The whole point is "Common" in CIM.
Vendors who do follow generic APIs should not be certified.
And SLP is not a solution because it is not well integrated, is much too slow, and clients are not supposed to change ports, much less search for one.

Kirk  Augustin
11821 NW McNamee Rd
Portland, OR 97231
HM: 503-289-4356
WK: 503-744-8841
________________________________
From: "[email protected]" <[email protected]>
To: [email protected]; [email protected]
Cc: [email protected]; [email protected]; [email protected]
Sent: Friday, October 21, 2011 9:30 AM
Subject: RE: Port selection
Hi Kirk -

I was ready to hit "send" on this and just then saw Paul's excellent reply, which already covers most of my points.  I'm still hitting "send" anyway. :)

I would like to offer a perspective on (1) why it is necessary to allow two CIMOM instances to run on a single host, and (2) why it is not an interoperability problem.

Often, an end user may wish to install a provider which was obtained from an external source, meaning that the user has no control over how the provider was built. Such a provider may very well have restrictions upon which version of CIMOM under which it is operated. In fact, in the real world often a provider comes packaged with a specific CIMOM with which it has been built, tested, and qualified.  Often the provider vendor will *not* support the use of the provider unless it is used under the specific CIMOM with which the vendor has qualified it, and quite understandably so.  This supported version of CIMOM is often *not* the same version of the CIMOM that may come packaged and pre-installed on a particular host, and may not even be from the same CIMOM vendor!  Therefore, the end user has three choices:

Choice 1: Use the third-party provider under the unsupported (Host-OS-supplied) CIMOM. This cannot be done in an enterprise environment, as enterprise customers would never purchase a system that is running with unsupported components. In fact it may not even work at all (due to library mismatches, different CIMOM vendors, etc.).

Choice 2: Disable the CIMOM that comes pre-packaged with the host OS, and use the CIMOM that is supported with the desired provider. This is also not a good solution, as the prepackaged Host providers will then be unavailable.

Choice 3: Run both CIMOMs, each on different ports, as we've been discussing.

Regarding interoperability:  If interoperability is a concern, then both server-side (provider vendors) and client-side are most likely dealing with SMI-S based implementations.  If so, SMI-S supports SLP as a CIMOM discovery mechanism.  SMI-S's use of SLP fully accounts for the fact that multiple CIMOMs may be running on different ports on a single host. Clients need not depend on having any particular CIMOM running on a fixed, "well-known" port number, as SLP will inform the client which port to use.

Cheers,
- Bob Tillman



From: Paul von Behren [mailto:[email protected]]
Sent: Friday, October 21, 2011 12:21 PM
To: Kirk Augustin
Cc: Venkateswara R Puvvada; Vitezslav Crhonek; [email protected]
Subject: Re: Port selection

The main motivations (at least for some companies) for multiple servers are not name collision issues, but "production readiness".
1) Pegasus (and some other CIMOMs) behave badly when one provider has problems.  If you are shipping a production-level software solution, you can't tell your users "sorry, our software is not working because some other vendor's stuff is broken, we can't help you".
2) upgrades - Pegasus requires a restart when any provider is updated - even a provider in a different namespace from a different company.  This is just not acceptable for a robust solution.
3) provider API compatibility - if you create providers for Pegasus proprietary APIs, you can't use them in SFCB.  Even if your providers do conform to CMPI and work in SFCB, they may not work in Pegasus.   Providers written in Java per the JSR48 standard won't work in Pegasus.  If you want your company's providers to work, you need to install a compatible CIMOM.
4) security - Pegasus does not easily support having different credentials for different providers.  Different CIM providers hosted on one server may be instrumenting unrelated components owned by different organizations and require different credentials
5) global settings that should be provider-specific - there are too many aspects of Pegasus that should be configurable per-provider rather than global.  To assure any provider and be installed on any Pegasus instance, every Pegasus instance needs to support all features in every instance.  In other words, every running copy of Pegasus needs to allows SSL, SLP, and numerous other features - but the install for each provider should select which ones apply. All compile-time options should be eliminated to meet this goal.  For example, most companies agree that SSL is mandatory (SMI-S requires it for standards conformance), but Pegasus can be built without SSL.  Vendor A is using Pegasus for something where security is not critical and their installer sets up Pegasus with no SSL.  Then vendor B comes along and requires SSL - vendor B has no idea what global features vendor A needs, so they can't reliably guess what dialect of Pegasus could be used for both vendors A and B.  Easiest solution is to have each vendor run in a separate Pegasus instance.
6) Standards conformance - as currently coded, Pegasus does not fully support either the standard CQL filter specification or the WQL subset specified in SMI-S.  To be completely conformant to SMI-S, a vendor must modify Pegasus.  This modification is a pretty easy if you disable a bunch of non-standard filter features provided in Pegasus.  But just like in the the SSL example, you don't know whether other CIM providers rely on those filter features or the non-standard Pegasus QL support.  So a separate CIMOMis a good workaround.

I'm not saying that Pegasus needs to address all these issues above; I don't view multiple CIMOMs as being evil.  What I am saying is that Pegasus would need significant changes to achieve Kirk's lofty goals.

Paul


On Fri, Oct 21, 2011 at 9:40 AM, Kirk Augustin <[email protected]<mailto:[email protected]>> wrote:
There is never a need to have more than one CIM server per machine.
The whole point is interoperability, and namespace qualification makes collision avoidance trivial.

Kirk Augustin
11821 NW McNamee Rd
Portland, OR 97231
HM: 503-289-4356
WK: 503-744-8841
________________________________
From: Venkateswara R Puvvada <[email protected]<mailto:[email protected]>>
To: Vitezslav Crhonek <[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Sent: Thursday, October 20, 2011 10:37 PM
Subject: Re: Port selection

Vitezslav,

Some runtime config options are fixed and hidden in release builds. httpPort is part of those config options.

http://cvs.opengroup.org/cgi-bin/viewcvs.cgi/*checkout*/pegasus/doc/BuildAndReleaseOptions.html?rev=1.24.2.1

If there is a requirement to run multiple cimservers on a single system,  use Pegasus PEGASUS_FLAVOR option which makes httpPort and httpsPort visible/ not fixed.

http://www.openpegasus.org/pp/uploads/40/21277/PEP350_MultiCIMOM.htm

PEP 290 was not implemented. There was a debate to use HTTP Host header to identify target host instead of using the port.

Venkat




From:        Vitezslav Crhonek <[email protected]<mailto:[email protected]>>
To:        "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Date:        20/10/2011 20:56
Subject:        Port selection
________________________________



Hello,

Is there any possibility to set own http/https port values?

I see httpPort and httpsPort options, but it seems that these options
are disabled:

$ cimconfig -g httpPort
Specified property name was not found.
CIM_ERR_NOT_FOUND: Configuration property "httpPort"

Is there any way how to enable them? (Probably some env. variable during
build time?)

I'm also curious what happened with PEP #290:
http://www.openpegasus.org/pp/upreviews/40/2362/orig/PEP290.html

Because this feature would be useful in some situations.

Best regards,
Vitezslav Crhonek