There is no version of spacecmd-1.6.5-1.el5 neither in Fedora nor in EPEL. So I believe you are using Spacewalk nightly. Changing product to Spacewalk.

Created attachment 530109 [details]
/usr/lib/python2.4/site-packages/spacecmd/errata.py from the version 1.6.5

Hello

After taking a look at the code and the respond from the satellite server, I discover it seems that the response format change depending on the errata name.

For exemple with the searching string = 2009:1103
We can have this 2 king of answers
{ 'date': '2009-06-16 06:00:00', 'synopsis': 'cman bug fix update', 'type': 'Bug Fix Advisory', 'id': 1561 }
{ 'advisory_name': 'CLA-2009:1103-6', 'advisory_type': 'Bug Fix Advisory', 'date': '2009-06-16 06:00:00', 'id': 33766, 'advisory_synopsis': 'cman bug fix update' }

So in one case the dictionary key name is 'synopsis' and for the other it is 'advisory_synopsis'

I have made a patch who is checking the dictionary key before trying to append to the result.

Actualy this fix only the errata_search function, but the problem still in other searching option like errata_summary
Could someone test my patch and tell me if it is fine before I apply it to the whole file ?

Created attachment 532079 [details]
/usr/lib/python2.4/site-packages/spacecmd/errata.py from the version 1.6.5

Hi

I have fixed the whole file errata.py.
Now all the functions seems working fine

I have taken a look at the patch, however I'm unable from a quick test to reproduce the problem (satellite 5.4.1 and latest git spacecmd), and therefore to test the patch.

I'm aiming to look at this in more detail, but if the reporter can provide any more details about steps to reproduce, and also to re-test with the latest nightly build spacecmd, that would be helpful.

Cliff, if Aron is happy for me to take this, you can assign the bug to me and I'll work through getting a solution committed.

Hello

I tryed with the latest spacecmd rpm: spacecmd-1.7.5-1.el5.noarch.rpm
from: http://spacewalk.redhat.com/yum/nightly/RHEL/5/x86_64/
but the problem still occur.

What I discover :
- the problem is when the errata is present in an CLONE channel
- this is a python error as it is getting an unexpected key name

When I remove the filter and just let giving all the errata list array I got this 2 kind of answers for the same errata number

{ 'date': '2009-06-16 06:00:00', 'synopsis': 'cman bug fix update', 'type':'Bug Fix Advisory', 'id': 1561 }
{ 'advisory_name': 'CLA-2009:1103-6', 'advisory_type': 'Bug Fix Advisory', 'date': '2009-06-16 06:00:00', 'id': 33766, 'advisory_synopsis': 'cman bug fix update' }


One last important information, I am not using Spacewalk but RedHat Satellite 5.4
(originaly I posted the bug in spacecmd BZ).

I am searching a way to explain you how to reproduce the bug, but I don't know what to say as the install seems quite standart.
May be you could tell me what to look at, as one side of the issue is the errata list array response from Satellite ...

Can you please confirm which version of spacewalk-java you have installed, I've tested on satellite 5.4.1 with the following version and don't see any problem:

$ rpm -q spacewalk-java
spacewalk-java-1.2.39-113.el5sat
$ rpm -q spacecmd
spacecmd-1.7.5-1.el5
$ spacecmd errata_search 2007:0893 2>/dev/null
RHEA-2007:0893  krb5 bug fix enhancement update                     2007-11-07
CLA-2007:0893   krb5 bug fix enhancement update                     2007-11-07

that's weird...
What I get is close to your env

# rpm -q spacewalk-java
spacewalk-java-1.2.39-97.el5sat
# rpm -q spacecmd
spacecmd-1.7.5-1.el5
# spacecmd errata_search 2007:0893
INFO: Connected to https://localhost/rpc/api as xxx
ERROR: 'advisory_synopsis'


I modifyed the file /usr/lib/python2.4/site-packages/spacecmd/errata.py for testing, in order to get the whole array list data
Could you plase try this patch and compare with the results I had ?

Created attachment 564483 [details]
just for testing

this give the whole array data of errata

Dumping the self.all_errata.values() elements on my test box shows all items (clone and original errata) contain the advisory_synopsis key.

ok, then it seems the problem come from the Satellite server, it should not reply with 'synopsis' key name.
tomorrow I will take a look inside the DB...

In the API documentation I found this information about the function listErrata
---------
Method: listErrata
Returns:
    string "advisory_synopsis" - Summary of the erratum.
    string "synopsis (Deprecated)"
----------
	
So I tested a simple script who is only using this listErrata directly:

	for errata_data in client.channel.software.listErrata(key, CHANNEL):
		print errata_data


What i get is :
{'advisory_name': 'RHBA-2009:1103', 'advisory_type': 'Bug Fix Advisory', 'issue_date': '2009-06-16 06:00:00', 'advisory': 'RHBA-2009:1103', 'last_modified_date': '2009-06-16 09:33:07', 'id': 1561, 'synopsis': 'cman bug fix update', 'date': '2009-06-16 06:00:00', 'update_date': '2009-06-16 06:00:00', 'advisory_synopsis': 'cman bug fix update'}

The API is giving back both 'synopsis' and 'advisory_synopsis'
Somewhere beetween Satellite API and spacecmd, the key name 'advisory_synopsis' is lost ...

In the old spacecmd version 1.2.2 it is using only 'synopsis' key name.
line 419	re.search(query, self.all_errata[name]['synopsis'], re.I):

Even if the case seems to be "special", it could be good spacecmd is handling correctly both type of return from the API, for compatibility purpose.
As the origin of the issue is a change in the key name.
The choice is your...

(In reply to comment #14)
> In the API documentation I found this information about the function listErrata
> ---------
> Method: listErrata
> Returns:
>     string "advisory_synopsis" - Summary of the erratum.
>     string "synopsis (Deprecated)"
> ----------
> 
> So I tested a simple script who is only using this listErrata directly:
> 
>  for errata_data in client.channel.software.listErrata(key, CHANNEL):
>   print errata_data
> 
> 
> What i get is :
> {'advisory_name': 'RHBA-2009:1103', 'advisory_type': 'Bug Fix Advisory',
> 'issue_date': '2009-06-16 06:00:00', 'advisory': 'RHBA-2009:1103',
> 'last_modified_date': '2009-06-16 09:33:07', 'id': 1561, 'synopsis': 'cman bug
> fix update', 'date': '2009-06-16 06:00:00', 'update_date': '2009-06-16
> 06:00:00', 'advisory_synopsis': 'cman bug fix update'}
> 
> The API is giving back both 'synopsis' and 'advisory_synopsis'
> Somewhere beetween Satellite API and spacecmd, the key name 'advisory_synopsis'
> is lost ...

Well, spacecmd is simply calling the API, so there's no reason for the results to be different.  Also this behavior is inconsistent with your original report, where you indicated things were returned containing *only* the 'synopsis' key.

> In the old spacecmd version 1.2.2 it is using only 'synopsis' key name.
> line 419 re.search(query, self.all_errata[name]['synopsis'], re.I):
> 
> Even if the case seems to be "special", it could be good spacecmd is handling
> correctly both type of return from the API, for compatibility purpose.
> As the origin of the issue is a change in the key name.
> The choice is your...

Since the "old" key is marked deprecated, I don't see any advantage to adding it to current code - when things are marked deprecated in an API it means they will go away at some point in the future, so you should move away from using them, so adding it now will simply create work when we need to remove it in the future.

Have you tried updating your satellite as I suggested, so your spacewalk-java is at least as new as the version I tested and identified as working?

The data get by spacecmd is giving only 'synopsis' which give the error message "ERROR: advisory_synopsis", because 'advisory_synopsis' is missing and the latest spacecmd wants 'advisory_synopsis'.
Out of spacecmd the API is giving both 'synopsis' and 'advisory_synopsis'
Do you understand, this is not inconsistent with my original report :-/

I have the feeling my patch is not the good way to fix it, as the issue seems not to be in errata.py

ok I give up.

(In reply to comment #16)
> The data get by spacecmd is giving only 'synopsis' which give the error message
> "ERROR: advisory_synopsis", because 'advisory_synopsis' is missing and the
> latest spacecmd wants 'advisory_synopsis'.
> Out of spacecmd the API is giving both 'synopsis' and 'advisory_synopsis'
> Do you understand, this is not inconsistent with my original report :-/

Ok, so I do understand, and I'm trying hard to help you, but without any way to reproduce your problem it is quite difficult.

In comment#2 you did say that the "response from the satellite server" had two different conflicting formats, which I read as getting bad data from the API call - your comment #15 says something different, ie the API call is returning good data, but the internal all_errata list in spacecmd contains duplicate values..

Perhaps your spacecmd errata cache contains some bad data, please can you try the following (testing between steps):
- spacecmd clear_caches
- rm -f ~/.spacecmd/<server>/errata
- update to the latest satellite packages so we are testing the same version

> I have the feeling my patch is not the good way to fix it, as the issue seems
> not to be in errata.py

I agree - I don't currently think it's a bug in spacecmd, or I would happily have implemented a fix.

I agree with you, you have to be able to reproduce it on your system... I am sorry I have no clue how to help you doing it...

but:

No, I didn't say "conflicting formats" but "this 2 king of answers" (I misspelled the word "kind") and "response format change"
 comment #2
 > After taking a look at the code and the respond from the satellite server, I
 > discover it seems that the response format change depending on 
 > the errata name.
 > For exemple with the searching string = 2009:1103
 > We can have this 2 king of answers
 > ...
 > So in one case the dictionary key name is 'synopsis' and for 
 > the other it is 'advisory_synopsis'

No, internal all_errata list in spacecmd does not contain duplicate values, this is the opposite as 'advisory_synopsis' is missing in 1 of the 2 kind of answers.
 comment #14
 > The API is giving back both 'synopsis' and 'advisory_synopsis'
 > Somewhere beetween Satellite API and spacecmd, the key name
 > 'advisory_synopsis' is lost ..

you make me feel my explanations are unbelievable...
please have a another read to my previous comment and tell me this is clear,
otherwise I will not sleep well tonight ;-)

Anyway, thanks for your help, I got a better view of it.
I stop the investigation as the patch is perfectly.
Just wanted to share this issue and the workaround I found, isn't it the open source way to do :-)

From comment#2:
{ 'date': '2009-06-16 06:00:00', 'synopsis': 'cman bug fix update', 'type':
'Bug Fix Advisory', 'id': 1561 }

From comment#14:
{'advisory_name': 'RHBA-2009:1103', 'advisory_type': 'Bug Fix Advisory',
'issue_date': '2009-06-16 06:00:00', 'advisory': 'RHBA-2009:1103',
'last_modified_date': '2009-06-16 09:33:07', 'id': 1561, 'synopsis': 'cman bug
fix update', 'date': '2009-06-16 06:00:00', 'update_date': '2009-06-16
06:00:00', 'advisory_synopsis': 'cman bug fix update'}

So for errata ID 1561, the API is returning the correct data (contains advisory_synopsis key), the spacecmd all_errata list contains an incorrect entry for errata id 1561.

The thing between the API and all_errata in spacecmd is the errata cache, so can you please try clearing this using the steps mentioned in comment#17 and report back - I think this may fix your problem.

yes, you got it, it has fixed the issue.

doing only "spacecmd clear_caches" was enough, when i do the errata_search there was this message
** Generating errata cache **


But it raise me a general question:
as the cache seems to be not always reliable, could it be good to flush the cache every time ?
or avoiding using it ?


Thanks for all :-)

(In reply to comment #20)
> yes, you got it, it has fixed the issue.
good :)
 
> doing only "spacecmd clear_caches" was enough, when i do the errata_search
> there was this message
> ** Generating errata cache **
> 
> 
> But it raise me a general question:
> as the cache seems to be not always reliable, could it be good to flush the
> cache every time ?
> or avoiding using it ?
No, I think the performance hit of not using the cache would be far, far too much, and generally the spacecmd caching works quite well.  

I think you hit problems because you updated your satellite (and spacecmd), without clearing the caches, in general you should do a spacecmd clear_caches after any significant change in the satellite content or update level.

If you really wanted to force cache-flushing every time, you could simply do this:

alias spacecmd="spacecmd clear_caches && spacecmd"

I'm pretty sure you'll quickly find that the performance is too bad to be useful if you do this though.

Maybe there is some scope for additional logic in spacecmd which considers more variables when deciding when to rebuild the caches, I'll add that to my TODO list and give it some thought.  For now though, periodic manual clear_caches is the best solution.

As per comment#20, traced to an issue specific to the reporters environment so this can be closed as NOTABUG.