Re: Port selection

10 years ago I did not have to hardcode anything at all.
I just followed the schema.

CIM has been around since before 1995.
All the main devices, like drives, network adapters, etc., all worked fine without any variations, from quirks or APIs.
By now I expected the cimom to have become integrated with the OS.
Instead, we have cimom flavor of the week, with even wider variances, it seems to me.

 
Kirk & Trish Augustin
11821 NW McNamee Rd
Portland, OR 97231


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


>________________________________
>From: "Hwang, Johnny" <[email protected]>
>To: Kirk Augustin <[email protected]>; Steve Peters <[email protected]>; [email protected]; [email protected]; [email protected]
>Cc: [email protected]; [email protected]; [email protected]
>Sent: Friday, October 21, 2011 1:20 PM
>Subject: RE: Port selection
>
>
>Au contraire, it’s been a big step up from what it was 10 years ago. Instead of hardcoding the APIs of every vendor, you simply need to sometimes hardcode the quirks of other vendors, which is a reduction of work by at least two orders of magnitude. It’s just that reducing that hardcoding down to zero is not worth the effort needed to make every provider and CIMOM flawless. Tradeoffs happen. Perfection is always 10 years away, so worry about perfection when the day comes. 
> 
>From:Kirk Augustin [mailto:[email protected]] 
>Sent: Friday, October 21, 2011 1:10 PM
>To: Steve Peters; [email protected]; [email protected]; [email protected]
>Cc: [email protected]; [email protected]; [email protected]
>Subject: Re: Port selection
> 
>It is in the spec that clients must  be able to access the cimom without knowing anything else about it.
>If there is more than one server, each with different limitations, ports, etc., then how would a generic client be able to connect to the real server?
>The server is not supposed to be some proprietary system of its own, but THE single source of management and configuration information of the machine.
>That can't be true if there is more than one.
> 
>If one strays from that path, then the whole point of CIM disappears.
>Then we might as well all go back to writing our own separate and proprietary management systems again, with the last 10 years being a waste of time.
> 
>Kirk Augustin
>11821 NW McNamee Rd
>Portland, OR 97231
>HM: 503-289-4356
>WK: 503-744-8841
>
>________________________________
>
>From:Steve Peters <[email protected]>
>To: [email protected]; [email protected]; [email protected]; [email protected]
>Cc: [email protected]; [email protected]; [email protected]
>Sent: Friday, October 21, 2011 11:35 AM
>Subject: RE: Port selection
>Dave,
> 
>                SMI-S doesn’t require a single instance of Base Server. I agree a single instance per CIMOM is a good idea, but can’t
>even find that in the Specification.
> 
> 
>                                Steve Peters
> 
>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/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
> 
> 
> 
> 
>
>