Re: Concerns raised about "production-readiness"

Thanks for the excellent write-up and reply.
To not confuse the "Port selection" thread I haven given my reply
a different title.

I am only involving myself here since
a few of your concerns were addressed in the latest OpenPegasus releases
and in a few cases I would like to understand the concern more precisely.

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".

---> With OpenPegasus 2.11, 2.11.1
and soon 2.10.1 you can group providers in separate process(es).
That way you can have each set of providers from a vendor clearly split
from another vendor's providers. This feature was introduced with PEP#356
- Provider Module Grouping. Also, a lot of work has went into OpenPegasus
to reduce the overhead from Out of Process communication to as little as
10-15% instruction path length versus running In-Process as well as making
the Out-of-Process mode more robust (PEP#349 ).
Meaning, if providers from one vendor behave badly they will only impact
themselves. I highly recommend making use of that Provider Module Grouping-feature
if you have to deal with third-party vendor providers.

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.

--> That's not completely true. You
can update a provider without restarting the CIM Server by disabling the
provider module using the cimprovider command, replacing the provider library
and enabling the provider module again. Doing the same without using the
cimprovider command is a little bit more difficult, but since the operations
cimprovider does execute are standard CIM operations you can write your
own client doing the same from remote.

3.) Even if your
providers do conform to CMPI and work in SFCB, they may not work in Pegasus.

--> Same vice versa in my experience
;) , provider who do conform to CMPI and work in Pegasus probably won't
work in SFCB. The hidden issue is that the CMPI specification is not as
precise as it needs to be. Even though we are trying to get the CMPI work
group set up and running to correct a number of the issues in a CMPI 2.1
version, so far we have failed to get The OpenGroup ready to support.

4.) security - Pegasus does not easily support
having different credentials for different providers.

--> Providers can be run either using
the DesignatedUser concept (a specific credential used by a provider) or
following the approach of Run-as-Requestor (provider runs with the credentials
of the requestor). But maybe I just do not understand the issue.

5) global settings that should be provider-specific...

--> I do not understand how you want
to have a CIM Server communicating by the use of SSL for one provider(or
set of providers) and not for another set. If your example is about the
fact that SSL should not be optional, I can agree to that. Especially since
if built with SSL you can disable the SSL port in OP on run-time. I do
agree though that OpenPegasus today does offer too many options on build/compile
time. One of our targets is to simplify by either removing options or making
them dynamic on run-time (probably in version 3.0).

6) Standards conformance...

(Query Languages)

--> At least I can assure you that
we recognize this as a weak point and are working on a solution for it.

Mit freundlichen Grüßen / Kind regards

Marek Szermutzky

Software Engineer / OpenPegasus Maintainer (PMC) and z/OS PlatformRep.

IBM Systems &Technology Group, Systems Software Development / z/OS
Capacity Management and Support

-------------------------------------------------------------------------------------------------------------------------------------------

IBM Deutschland

Schoenaicher Str. 220

71032 Boeblingen

Phone: +49-7031-16-5182

E-Mail: [email protected]

-------------------------------------------------------------------------------------------------------------------------------------------

IBM Deutschland Research & Development GmbH / Vorsitzender des Aufsichtsrats:
Martin Jetter

Geschäftsführung: Dirk Wittkopp

Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart,
HRB 243294

From:
Paul von Behren <[email protected]>

To:
Kirk Augustin <[email protected]>

Cc:
Venkateswara R Puvvada
<[email protected]>, Vitezslav Crhonek <[email protected]>,
"[email protected]" <[email protected]>

Date:
21.10.2011 18:21

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/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