RE: Port selection

 

                Multiple CIMOMs on a single server is the current state
of the industry. SNIA has a work item to try and solve many of

the shared CIMOM issues. I will make sure items listed in this tread are
on the list.

 

VMware is the only environment where a shared CIMOM is working. It
starts by shipping the CIMOM as part of the hypervisor.

It also includes providers for most of the "Interop" namespace (base
server, profile registration, ... ). They also impose their

choice of ports, security, memory use, and more.

 

 

                                Steve Peters

                                PMC-Sierra

 

 

 

From: [email protected] [mailto:[email protected]] 
Sent: Friday, October 21, 2011 11:17 AM
To: [email protected]; [email protected];
[email protected]
Cc: [email protected]; [email protected]; [email protected]
Subject: 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]>
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]>
To: Vitezslav Crhonek <[email protected]>
Cc: "[email protected]" <[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/Buil
dAndReleaseOptions.html?rev=1.24.2.1
<http://cvs.opengroup.org/cgi-bin/viewcvs.cgi/*checkout*/pegasus/doc/Bui
ldAndReleaseOptions.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
<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]> 
To:        "[email protected]" <[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
<http://www.openpegasus.org/pp/upreviews/40/2362/orig/PEP290.html> 

Because this feature would be useful in some situations.

Best regards,
Vitezslav Crhonek