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/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]>
> 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
>
> Because this feature would be useful in some situations.
>
> Best regards,
> Vitezslav Crhonek
>
>
>
>
>