Description of problem: client.channel.software.listErrata variant which takes a start and end date is broken. There are several problems (detailed below) Version-Release number of selected component (if applicable): Observed on Satellite 5.4.1 (spacewalk-java-1.2.39-113.el5sat) problem believed to still exist in upstream spacewalk How reproducible: Always Steps to Reproduce: Run attached repoducer script Actual results: $ ./api_reproducer2.py listErrata(key, channel) : "date" same as issue_date : OK [{'advisory_name': 'RHBA-2007:0574', 'advisory_type': 'Bug Fix Advisory', 'issue_date': '2007-10-30 04:00:00', 'advisory': 'RHBA-2007:0574', 'last_modified_date': '2007-11-08 14:17:06', 'id': 852, 'synopsis': 'libXp bug fix update', 'date': '2007-10-30 04:00:00', 'update_date': '2007-11-07 05:00:00', 'advisory_synopsis': 'libXp bug fix update'}] Selected errata on 20071030 - 20071030 : Selected errata on 20071030 - 20071031 : Selected errata on 20071108 - 20071108 : Selected errata on 20071108 - 20071109 : {'date': '11/7/07', 'advisory_type': 'Bug Fix Advisory', 'id': 789, 'advisory_name': 'RHBA-2007:0959', 'advisory_synopsis': 'Updated kernel packages for Red Hat Enterprise Linux 5 Update 1'} {'date': '11/7/07', 'advisory_type': 'Bug Fix Advisory', 'id': 786, 'advisory_name': 'RHBA-2007:0579', 'advisory_synopsis': 'gfs2-utils bug fix update'} {'date': '11/7/07', 'advisory_type': 'Bug Fix Advisory', 'id': 852, 'advisory_name': 'RHBA-2007:0574', 'advisory_synopsis': 'libXp bug fix update'} {'date': '11/7/07', 'advisory_type': 'Product Enhancement Advisory', 'id': 840, 'advisory_name': 'RHEA-2007:0658', 'advisory_synopsis': 'redhat-rpm-config enhancement update'} {'date': '11/7/07', 'advisory_type': 'Bug Fix Advisory', 'id': 813, 'advisory_name': 'RHBA-2007:0544', 'advisory_synopsis': 'selinux-policy bug fix update'} {'date': '10/30/07', 'advisory_type': 'Bug Fix Advisory', 'id': 766, 'advisory_name': 'RHBA-2007:0826', 'advisory_synopsis': 'strace bug fix update'} {'date': '11/8/07', 'advisory_type': 'Security Advisory', 'id': 884, 'advisory_name': 'RHSA-2007:1027', 'advisory_synopsis': 'Important: tetex security update'} {'date': '11/8/07', 'advisory_type': 'Security Advisory', 'id': 885, 'advisory_name': 'RHSA-2007:1037', 'advisory_synopsis': 'Important: openldap security and enhancement update'} Expected results: Using the call to listErrata with no date arguments gives us the following information for this example errata (need to choose one with different issued and modified date): RHBA-2007:0574 issue_date : '2007-10-30 04:00:00' last_modified_date : '2007-11-08 14:17:06' update_date : '2007-11-07 05:00:00' date: '2007-10-30 04:00:00' When listing errata based on a date range the following is expected: 1 - A date range including the issue date will include this errata 2 - The returned 'date' key will match the issue date However, as we can see from the reproducer output above, neither of these is true, we actually have to select a range of 20071108 - 20071109, then we get a returned 'date' field which is '11/7/07', so it seems to return the update_date not the issue date as mentioned in the docs. So to summarise, the selection criteria seem to match the last_modified_date, which then returns the update_date. Selecting based on last_modified_date makes no sense, as it may change. IMHO the only sane thing to do here is to consistently use issue_date throughout.
Created attachment 564536 [details] Python API script which demonstrates the problem
Not sure, whether issue_date is the only sane attribute for selection, but might be the most suitable one in our case. Definitely much much better than last_modified. spacewalk.git: 2e9449ca4316b21cec273fc9fdf7b24f4f9599f8 Steve, having the change in upstream (in spacewalk-java packages starting from v 1.7.38-1), it would be great, if you could give some feedback, if the behavior is what you expected.
Steve, thank you for the detailed explanation and a nice reproducer!
Tomas, thanks for the response, I'll try to get some testing done on the fixed spacewalk version this week.
Tomas, I finally had time to get my spacewalk test environment working, and have tested with the latest spacewalk-nightly (spacewalk-java-1.7.54-1.fc16.noarch) $ ./api_reproducer.py listErrata(key, channel) : "date" same as issue_date : OK [{'advisory_name': 'RHBA-2007:0574', 'advisory_type': 'Bug Fix Advisory', 'issue_date': '2007-10-30 04:00:00', 'advisory': 'RHBA-2007:0574', 'update_date': '2007-11-07 05:00:00', 'last_modified_date': '2007-11-08 14:17:06', 'synopsis': 'libXp bug fix update', 'id': 1987, 'advisory_synopsis': 'libXp bug fix update'}] Selected errata on 20071030 - 20071030 : [] Selected errata on 20071030 - 20071031 : [{'date': '11/7/07', 'advisory_type': 'Bug Fix Advisory', 'id': 1987, 'advisory_name': 'RHBA-2007:0574', 'advisory_synopsis': 'libXp bug fix update'}] Selected errata on 20071108 - 20071108 : [] Selected errata on 20071108 - 20071109 : [] This is working better but it's still not right: The dict returned from the listErrata(key,channel) call now no longer contains the "date" key (which is not marked deprecated in the docs), but it does still contain the issue/update/last_modified dates (which are marked deprecated). Also the selection of the errata in the listErrata(key,channel, start_time, end_time) looks better, but the returned "date" field here seems to the the update_date, not the issue_date (or "Date erratum was created" as described in the API docs) I was also expecting to see the errata selected in the "20071030 - 20071030" case, but I think this may just be a bug in my reproducer script - I guess start date should have a time of 00:00 and end date should have a time of 23:59 so that selecting a start and end of the same day will return all errata created on that day. Happy to test any further changes :)
Hey Steve, 1. listErrata(sessionKey,channelLabel) never returned 'date', just 'issue_date', 'update_date' and 'last_modified_date' 2. listErrata with Date attributes: - I added 'issue_date' to be returned - I renamed current update_date returned as 'date' to 'update_date' spacewalk.git: 164320efe6da610bd2fb35acd69eed2f0cc3d381 3. This could be an option, but the errata search checks just for the date, taking time as 00:00. The recommended way is to set enddate to one day later - 20071031., so you get all errata issued within the previous date.
Hi Tomas, Re (1) - sorry, I don't think that's right? :confused: If you look at my initial reproducer (from satellite 5.4.1): $ ./api_reproducer2.py listErrata(key, channel) : "date" same as issue_date : OK [{'advisory_name': 'RHBA-2007:0574', 'advisory_type': 'Bug Fix Advisory', 'issue_date': '2007-10-30 04:00:00', 'advisory': 'RHBA-2007:0574', 'last_modified_date': '2007-11-08 14:17:06', 'id': 852, 'synopsis': 'libXp bug fix update', 'date': '2007-10-30 04:00:00', 'update_date': '2007-11-07 05:00:00', 'advisory_synopsis': 'libXp bug fix update'}] This contains a "date" key : 'date': '2007-10-30 04:00:00' This is also in alignment with the API docs: <snip from satellite 5.4.1, spacewalk-java-1.2.39-115> Method: listErrata Description: List the errata applicable to a channel Parameters: * string sessionKey * string channelLabel - channel to query Returns: * array: o struct - errata + int "id" - Errata Id + string "date" - Date erratum was created. + string "advisory_synopsis" - Summary of the erratum. + string "advisory_type" - Type label such as Security, Bug Fix + string "advisory_name" - Name such as RHSA, etc + string "advisory" - name of the advisory (Deprecated) + string "issue_date" - date format follows YYYY-MM-DD HH24:MI:SS (Deprecated) + string "update_date" - date format follows YYYY-MM-DD HH24:MI:SS (Deprecated) + string "synopsis (Deprecated)" + string "last_modified_date" - date format follows YYYY-MM-DD HH24:MI:SS (Deprecated) </snip> So this says "date" == Date erratum was created, which I interpret as the same as "issue_date" but perhaps they are different. I'm also confused as to why some of these fields are marked deprecated, I've been avoiding using them for this reason, but your response seems to indicate these keys are still actively used? So my second reproducer test in comment#5 using spacewalk-nightly lacks the "date" key, which was present in the initial test. This missing key breaks spacecmd amongst other things. The latest API docs (from spacewalk-nightly) still mention this key too?
> 1. API call channel.software.listErrata(key, channel) > -- have to return "date" according to the documentation. Right, but this is an another issue than this BZ, right? > -- should not print depricated filds It shall. We basically just add new attributes and API calls. We do not remove neither API calls nor API attributes not to break existing customer scripts. > 2. API calls channel.software.listErrata(key, channel,startDate) and > channel.software.listErrata(key, channel,startDate,endDate) > return field 'update_date' that is not in the documentation. Valid point. > 3. Field 'date' is equal to 'update_date' This is correct. 'date' attribute has always been the errata update date, it just wasn't clear from the naming. I just added 'issue_date' and 'update_date' to have it more clear. spacewalk.git: 3194f427898335051fb08a26d6751d99c3476bba 2d28b81e605d0cca0db0dda5f2e82f9a049e9502
This issue is resolved with the release of RHN Satellite 5.5. As of September 20th 2012, RHN Satellite 5.5 has been generally available. Release Notes and other 5.5 documentation can be found here: https://access.redhat.com/knowledge/docs/Red_Hat_Network_Satellite/ The associated Errata for the 5.5 release are: 5.5 Satellite GA Errata - http://rhn.redhat.com/errata/RHEA-2012-1296.html 5.5 Upgrade Errata - http://rhn.redhat.com/errata/RHEA-2012-1298.html 5.5 RHN Proxy GA Errata - http://rhn.redhat.com/errata/RHEA-2012-1297.html 5.5 RHN Tools GA Errata - http://rhn.redhat.com/errata/RHEA-2012-1299.html Regards, Clifford - Engineering Manager, Satellite