Bug 468400

Summary: getting the SBLIM, openwsman, OMC stacks into Fedora
Product: [Fedora] Fedora Reporter: Matt Domsch <matt_domsch>
Component: distributionAssignee: Bill Nottingham <notting>
Status: CLOSED CURRENTRELEASE QA Contact: Bill Nottingham <notting>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: dcantrell, ejratl, j, jwboyer, linux-bugs, praveen_paladugu, rvokal, srinivas_ramanatha, vcrhonek
Target Milestone: ---Keywords: Tracking
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-01-04 22:28:39 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 458024, 458025, 466183, 468287, 468329, 469002, 470293, 502596, 502818, 502834, 502843, 502854, 503482, 503495, 503496, 503510, 503727, 503939, 509445    
Bug Blocks: 502609    

Description Matt Domsch 2008-10-24 15:47:57 UTC
Description of problem:
http://sblim.wiki.sourceforge.net/ and http://openwsman.org/
includes a boatload of DMTF standards-based open source software for managing systems.

This tracks the inclusion of those components into Fedora.

Comment 1 Matt Domsch 2008-10-27 19:02:11 UTC
Add components from OMC as well.
http://developer.novell.com/wiki/index.php/OMC

Comment 2 Jason Tibbitts 2009-07-11 07:27:33 UTC
I just wanted to note that there are many more sblim* review tickets submitted that don't block this ticket, and that none of the review pool seems to have any idea of how to deal with any of them.  I'd wager that none of us has any idea what sblim is.  Is it possible to get any kind of a simple writeup as to what we're supposed to do with all 20+ of these tickets, or perhaps some basic packaging guidelines?

Comment 3 Praveen K Paladugu 2009-07-13 13:58:23 UTC
Jason,

  The plan is to get these packages into Fedora and in time into "Red Hat" to enable remote management capabilities in "Red Hat".


SBLIM (pronounced "sublime") is an umbrella project for a collection of systems management tools to enable WBEM on Linux. Using the components of the SBLIM project, you can manage your Linux systems using open, standards-based technology.
(From: http://sblim.wiki.sourceforge.net/)


SBLIM (pronounced "sublime"), the Standards Based Linux Instrumentation for Manageability is an IBM-initiated Open Source project, intended to enhance the manageability of GNU/Linux systems. It does so by enabling WBEM, Web Based Enterprise Management.
(From: https://sourceforge.net/projects/sblim/)

I obtained the above primers, please see if this helps.

Thank you
Praveen

Comment 4 Jason Tibbitts 2009-07-13 15:47:29 UTC
(In reply to comment #3)

>   The plan is to get these packages into Fedora and in time into "Red Hat" to
> enable remote management capabilities in "Red Hat".

Plans for Red Hat are completely immaterial to Fedora.  If someone has a corporate interest in getting these in, perhaps they could also donate some of their corporate manpower or money towards getting them reviewed.  What really matters here is available time and available expertise in the almost entirely volunteer review pool.  

> SBLIM (pronounced "sublime") is an umbrella project for a collection of 
> systems

Yes, that much is clear from wikipedia.

> I obtained the above primers, please see if this helps.

Well, what would really help is something directly related to packaging:

Is there an expected directory structure for the various types of sblim-* packages?  Where do the executable, library and configuration files need to go in order for these packages to be recognized by whatever master daemons control the whole sblim system?  Are there any specific license issues we need to look out for?  Is there a spec file template that these packages can be expected to follow?  Is there a particular format for the package names that needs to be adhered to for server and client components?  That kind of thing.

If you expect to have more of these packages come up in the future, it would be good to take the above and compile it into a guideline document that we can get accepted by the packaging committee so that everyone will be on the same page and we can have quality package submissions, easy reviews and consistent maintainability.

Comment 5 Praveen K Paladugu 2009-09-09 19:01:58 UTC
Some of the rules include:

1) Make sure each provider Requires: tog-pegasus (or sblim-sfcb). Each provider should "Require" anyone cim sever for now. This is going to change in future.

2) Make sure all the cmpi libraries are in /usr/lib/cmpi directory.

3) Make sure all the provider libraries are in /usr/lib directory

3) Each provider should register in %postin and unregister in %preun to the cim server.

4) Some of the providers may have hard-coded shared objects hard coded. So eliminating all the *.so from the base package is not the right thing to do every time. So, check if the names of the shared objects are hard coded in the sources.

5) All the registration and mof files go to /usr/share/%{name}


Above are some of the rules I came across. I will add more, as I come across new ones. 

Sorry for the delay in responding.

Comment 6 Matt Domsch 2009-09-24 16:58:00 UTC
https://fedoraproject.org/wiki/PackagingDrafts/CMPIPlugins

now contains a draft with these rules, somewhat cleaned up.  This needs further review, and to be taken to a Packaging Committee meeting.

Comment 7 Bill Nottingham 2012-01-04 22:28:39 UTC
All dependent bugs closed.