Bug 521062

Summary:	Spacewalk API Enhancements
Product:	[Community] Spacewalk	Reporter:	Andy Speagle <andy.speagle>
Component:	API	Assignee:	Tomas Lestach <tlestach>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Red Hat Satellite QA List <satqe-list>
Severity:	medium	Docs Contact:
Priority:	low
Version:	0.6	CC:	derks, roysjosh, tlestach
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-08-05 12:19:48 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:
Bug Blocks:	723481

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):
0.6

How reproducible:
RFE

Steps to Reproduce:
1. 
2.
3.
  
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:

listUnpublishedErrata

Arguments:
    session_token

Returns
    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.

Thanks,

Andy

Comment 5 Jan Pazdziora (Red Hat) 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 (Red Hat) 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

Closing as CURRENTRELEASE

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?