Re: Port selection

However, the goal is not mine, nor is it new.
It has always been the point of CIM, and it the way CIM has always supposed to have worked.
It was the way it used to work.
While it is good CIM has been taken over for multiple practical uses, the origins are being forgotten.

 
Kirk Augustin
11821 NW McNamee Rd
Portland, OR 97231


HM: 503-289-4356
WK: 503-744-8841


>________________________________
>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]>
>Sent: Friday, October 21, 2011 9:21 AM
>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
>>>
>>> 
>>>
>>>
>>>
>
>
>