Bug 521062 - Spacewalk API Enhancements
Summary: Spacewalk API Enhancements
Alias: None
Product: Spacewalk
Classification: Community
Component: API
Version: 0.6
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Tomas Lestach
QA Contact: Red Hat Satellite QA List
Depends On:
Blocks: space16
TreeView+ depends on / blocked
Reported: 2009-09-03 12:18 UTC by Andy Speagle
Modified: 2011-08-05 12:37 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-08-05 12:19:48 UTC

Attachments (Terms of Use)

Description Andy Speagle 2009-09-03 12:18:10 UTC
Description of problem:

I would like to see a couple of enhancements to the Spacewalk API in regards to Errata.

1) At creation time, user should be able to specify the initial date of the errata.  Often, an errata is released long ago that needs to be added.  Being able to specify its original release date would assist in identifying old vs new errata.  (server.errata.create)

2) When an errata is published, user should be able to specify exactly which packages relevant to the errata are pushed to the channel(s) in question.  Multiple OS versions could be relevant to an errata and a blanket "publish" can cause packages to be pushed to the wrong channels. (server.errata.publish, server.errata.create)

3) We need the ability to merge individual errata together.  For instance, if a pre-existing errata is identical in advisory number to another being added to the system, need a mechanism for merging these advisories (and all relevant data) under a single advisory.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 1 BJ Dierkes 2010-02-03 19:49:06 UTC
I would like to add my own request regarding the errata api.  Currently there is no way to list unpublished errata.  You can create errata without publishing or selecting channels, but you can't list unpublished errata.  Please add:



    list of errata ids

Comment 2 Tomas Lestach 2010-05-04 14:36:24 UTC
errata.listUnpublishedErrata was added in commit: 3858b5b578f513f13315f75ad60ffc7a341a857b

Comment 3 Tomas Lestach 2010-05-05 07:48:26 UTC
Hello Andy,
see my comments:

1.) If I understood you correctly, you'd like to set manually the issue date of errata. If I create a spacewalk erratum, I always want to use the date when I created/publish it, not any other ... Could you explain more your reason?

2.) It seems you discovered some kind of misbehavior when publishing errata. Could you file a bugzilla with a reproducer for that, please?
Otherwise this shall not be necessary, because the packages shall be pushed to correct channels.

3.) This isn't actually the way how to handle errata. If an erratum gets published once, it cannot be modified any more! Otherwise 2 systems with the same erratum applied could end up with different packages installed. And this is not what we and system admins want to do.
In case you mean just modifying an unpublished erratum, I suppose you miss only an errata.edit API call. (Nowadays you always can delete the previous and create a new erratum.)

Comment 4 Andy Speagle 2010-05-05 11:15:52 UTC
Hi Tomas,

1)  The rationale for this request is that I maintain official RHEL software channels in my Spacewalk server.  Via the RHN API, I clone the official errata and create them in Spacewalk.  I would like to be able to set the issue data to the issue date of the RHN cloned errata.

2) & 3)  These are both related to my failed understanding of how errata work in Spacewalk.  I had managed Satellite servers in the past, and remembered that errata could affect multiple channels.  When I tried to replicate that function in Spacewalk and publish such multi-channel errata I ended up with packages meant for RHEL 5 in my RHEL 4 channels.  Additionally, I maintain both authoritative and production sets of software channels.  By authoritative, I mean that it's a channel that consists of every package ever released for a distribution.  By production, I meant that I only clone and release errata and packages once they are approved for production use.  My production systems are subscribed to production channels only.  In Satellite, when I cloned a multi-channel errata, if it had already been cloned to another production channel, I would see the option to "merge" errata.  Again, I assert that I'm merely failing to understand the process and/or trying to do something with Spacewalk that isn't intended.



Comment 5 Jan Pazdziora 2010-11-19 16:04:17 UTC
Mass-moving to space13.

Comment 6 Miroslav Suchý 2011-04-11 07:32:51 UTC
We did not have time for this one during Spacewalk 1.4 time frame. Mass moving to Spacewalk 1.5.

Comment 7 Miroslav Suchý 2011-04-11 07:36:57 UTC
We did not have time for this one during Spacewalk 1.4 time frame. Mass moving to Spacewalk 1.5.

Comment 8 Jan Pazdziora 2011-07-20 11:50:57 UTC
Aligning under space16.

Comment 9 Tomas Lestach 2011-08-05 12:19:48 UTC
The request from Comment#1 landed in Spacewalk 1.3.

Request 1) from #Description we decided not to implement. Modifying issue date of errata isn't a correct thing to do.

Requests 2) & 3) from Comment#4 shall be clear now - the errata concept is following:
- an erratum may be created and modified until it's in unpublished state
- after publishing an erratum, no changes of that erratum shall be allowed
- when there's a need of another update, creation of new erratum is recommended


Comment 10 Andy Speagle 2011-08-05 12:37:23 UTC
Request 1) Perhaps there's a misunderstanding of what I'm asking.  I don't want to "modify" the issue date of an errata, I merely want to be able to set it to an arbitrary date upon creation rather than "today."  Whether errata are scraped from a mailing list, or downloaded from RHN, the errata and its relevant packages might be from some time ago.  Therefore, being able to set the "issue date" to the date from when it was released either to RHN or <insert other repository here> is important for seeing at a glance when things were released.  I'm not terribly certain what's "inappropriate" about that.  Can you please clarify?

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