Bug 495598 - [RHSS RFE] RHN API getting OS/version
[RHSS RFE] RHN API getting OS/version
Status: CLOSED NOTABUG
Product: Red Hat Satellite 5
Classification: Red Hat
Component: New Feature (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Todd Sanders
wes hayutin
: FutureFeature, Triaged
Depends On: 444222
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-13 19:38 EDT by wes hayutin
Modified: 2010-06-28 14:43 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: 444222
Environment:
Last Closed: 2010-06-28 14:43:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description wes hayutin 2009-04-13 19:38:15 EDT
+++ This bug was initially created as a clone of Bug #444222 +++

Escalated to Bugzilla from IssueTracker

--- Additional comment from tao@redhat.com on 2008-04-25 16:34:05 EDT ---

In Satellite 4.x, can I pull the OS and version (e.g. OS:3 version:U8) with the api?  I don't see anything in the api docs that looks like it will do what I want.


This event sent from IssueTracker by jwest  [SEG - Feature Request]
 issue 164418

--- Additional comment from tao@redhat.com on 2008-04-25 16:34:06 EDT ---

General Escalation Information
State the problem

   1. Provide time and date of the problem

n/a

   2. Provide clear and concise problem description as it is understood at
the time of escalation

can't get client system OS/version info via satellite API

   3. State specific action requested of SEG

state whether or not this is possible, if there is a "backdoor" method
of doing so. 

   4. State whether or not a defect in the product is suspected

no defect suspected, possible RFE candidate?

   5. If there is a proposed patch, make sure it is in unified diff format
(diff -pruN)

n/a


Provide supporting info

   1. State other actions already taken in working the problem:

talked to rhn-satellite list, no response.  Also emailed ade lee (who has
written several custom RHN API scripts for this customer, no response. 
Basically they're looking to add this function to one of his existing
scripts.

   2. Attach sosreport

n/a

   3. Attach other supporting data

n/a

   4. Provide issue repro information:

n/a

   5. List any known hot-fix packages on the system

n/a

   6. List any customer applied changes from the last 30 days 

n/a

RHN Specific

   1. State whether Satellite or RHN hosted

satellite 4.x

   2. for Satellite: Provide output of ''satellite-debug'' and
''sysreport'' (for both satellite and proxy).

n/a

   3. Good practice - satellite-debug

n/a

   4. If the issue occurred during/after an upgrade:

n/a



This event sent from IssueTracker by jwest  [SEG - Feature Request]
 issue 164418

--- Additional comment from tao@redhat.com on 2008-04-25 16:34:07 EDT ---

BTW, SEG:

I did suggest to the customer to consider using "listPackages" to get
the installed packages on each system and then key on redhat-release
and/or kernel. 

I'm not sure what you would do in a situation where you have (for
example) a RHEL 3 U2 system running the RHEL 3 U4 kernel (but it seems
like any magic "getVersion" call would have the same problem, wouldn't
it?).  

My gut would be to lean towards keying on the version of the
redhat-release package. 

Also mentioned to the customer that there is a "getRunningKernel" call
in the 5.1.0 API.

I think he's looking for something cleaner.  I'm pretty sure the answer
is "we don't have that" but I want to be sure.

thanks.

-- 
Paul Novarese


This event sent from IssueTracker by jwest  [SEG - Feature Request]
 issue 164418

--- Additional comment from tao@redhat.com on 2008-04-25 16:34:07 EDT ---

Hi Jon,

As we discussed on the phone, here's a list of the kernel and
redhat-release package included with each RHEL 3 update.  

RHEL 3 GOLD:
redhat-release-3AS-1
kernel-2.4.21-4.EL

RHEL3 U1:
redhat-release-3AS-7
kernel-2.4.21-9.EL

RHEL3 U2:
redhat-release-3AS-7.2
kernel-2.4.21-15.EL

RHEL3 U3:
redhat-release-3AS-7.3
kernel-2.4.21-20.EL

RHEL3 U4:
redhat-release-3AS-7.4
kernel-2.4.21-27.EL

RHEL3 U5:
redhat-release-3AS-13.5.1
kernel-2.4.21-32.EL

RHEL3 U6:
redhat-release-3AS-13.6.2
kernel-2.4.21-37.EL

RHEL3 U7:
redhat-release-3AS-13.7.3
kernel-2.4.21-40.EL

RHEL3 U8:
redhat-release-3AS-13.8.3
kernel-2.4.21-47.EL

RHEL3 U9:
redhat-release-3AS-13.9.5
kernel-2.4.21-50.EL


This event sent from IssueTracker by jwest  [SEG - Feature Request]
 issue 164418

--- Additional comment from tao@redhat.com on 2008-04-25 16:34:08 EDT ---

Hi Paul,

Looking over the current API calls (up to 5.x) and
http://wiki.rhndev.redhat.com/wiki/5.1_API_Enhancements_Spec, I would tend
to agree with you.  We'll get system.getKernel in 5.1, it sounds like, but
right now we don't have something more straightforward than those
workarounds.

So, this sounds like a RFE - lemme know if you agree, and I'll kick it
over to SEG - Features.
Thx,

Xixi

Internal Status set to 'Waiting on Support'

This event sent from IssueTracker by jwest  [SEG - Feature Request]
 issue 164418

--- Additional comment from tao@redhat.com on 2008-04-25 16:34:09 EDT ---

[Customer/Frontline driven section] -- This section should be completed by
the front-line engineer with the assistance of the customer.

* Who is the customer?

Dell-enterprise

* What is the exact nature of the problem trying to be solved with this
request?

Customer needs a reliable way to pull data from satellite API to get OS
version (e.g. RHEL 3.9, RHEL 4.5, etc) for client systems.  This customer
does not have any solaris clients but that might be a consideration.

* What, if any, business requirements are satisfied by this request? (What
is the use case context?)

From the customer: "This is all about how we see the reporting done. 
Right now we run reports against the API and have to parse/sort the data
and make
assumptions on the OS/version based on the kernel.  Seems like it would
be a good idea to  include that in the API."

Honestly, I'm not really sure if there's a good way to do this, since
many customers routinely upgrade the kernel without upgrading everything
else.  I recommended that the customer may want to examine the version of
redhat-release in addition to the kernel to make his workaround a little
bit more robust.

* List the functional requirement(s) for performing the action(s) that are
not presently possible. Please focus on describing the problem related
requirements without projecting any specific solution.

An API call that returns the requested information

*  Each functional requirement must have clear acceptance criteria so Red
Hat understands what success looks like. If test cases can be provided
this would be even more ideal (bonus points for RHTS test cases).

n/a

* What is the desired release vehicle to satisfy these requirements? Major
release Minor release

Satellite 5.2

* Please justify with reference to the release vehicle policy described in
the RHEL Inclusion Criteria wiki page

* What package(s) are affected by this RFE? (List "new" if new
technology is likely to be required) 

RHSS

[Red Hat Sales/Frontline] -- This section should be completed by the front
line engineer with the assistance of the account manager/sales rep.

* Who is the sales sponsor? 

Stuart Anderson

Internal Status set to 'Waiting on SEG'

This event sent from IssueTracker by jwest  [SEG - Feature Request]
 issue 164418

--- Additional comment from jsherril@redhat.com on 2009-03-19 17:33:29 EDT ---

We've kinda added this within system.getDetails()

in 5.3 it should return 'release'  which is basically a string such as "4AS", or "5Server".  This is the same info that you can see under the system details "release" field.  

If you want which 'update' release it's at, i'd suggest just using the version of 'redhat-release' that is installed.  That's the best estimate of what update level the release is at.

--- Additional comment from whayutin@redhat.com on 2009-04-13 14:07:26 EDT ---

can get release..

proxy.version=5.1
client for 'http://grandprix.rhndev.redhat.com/rpc/api' - created
logged in (admin/dog8code), token: '2104xdb2a718f5de42045dea0f8f860d92b94'
client for 'http://grandprix.rhndev.redhat.com/rpc/api' - created
logged in (admin/dog8code), token: '2105x1f03b7cdc4f4b539ad2a3b9c8a2dfcf2'
Processing method: registration.new_system
System Registered 1000010866  - api-testkz3uoFTHGP5OR
Reading package profile: /rhel-i386-as-5.json
release = 5Server

System.out.println("release = "+ details.get("release"));


can get kernel

String string = (String) client.execute("system.get_running_kernel", securityToken, getSampleSystemId());
	    System.out.println("kernel = "+ string);

logged in (admin/dog8code), token: '2108xe7d6b77545111ddd4000aa71b33c1357'
kernel = 2.6.9-78.EL

I cant get the RHEL update version w/o listing all the system's packages.  I think thats not good enough...

Sending this back..
I think it is important to have an api that returns the update level of rhel.
The api should return something like

5Server U3
or
4AS U7

Take another look, that *may* be out of scope.

--- Additional comment from whayutin@redhat.com on 2009-04-13 14:37:48 EDT ---

can be related at least by function to..
https://bugzilla.redhat.com/show_bug.cgi?id=495541

--- Additional comment from whayutin@redhat.com on 2009-04-13 19:34:20 EDT ---

ok.. after speaking w/ Cliff, I agree that getting the true Update level of RHEL is some what meaningless.  So I think this should pass.

Customer can get the following from the api.

Major release  rhel4/5 etc.
kernel level
and package list.

verified that the api can successfully run all three.



----------------------------------------------------------------------------
actually I'll clone it for next release too..  The original request was Comment #1 From  Issue Tracker (tao@redhat.com)  2008-04-25 16:34:05 EDT   (-) [reply] -------      Private

In Satellite 4.x, can I pull the OS and version (e.g. OS:3 version:U8) with the
api?  I don't see anything in the api docs that looks like it will do what I
want.

Lets see what we can do to return something like ..  OS:3 version:U8, maybe its useful, maybe its not.
Comment 1 Clifford Perry 2010-06-28 14:43:32 EDT
Closing. I cannot figure out what this bug is tracking and was cloned from the other bug which is closed. .

Note You need to log in before you can comment on or make changes to this bug.