Bug 801463

Summary:	lookupFileInfo and createOrUpdatePath issues for binary files
Product:	[Community] Spacewalk	Reporter:	Franky Van Liedekerke <liedekef>
Component:	API	Assignee:	Tomas Lestach <tlestach>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Red Hat Satellite QA List <satqe-list>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	1.7	CC:	jpazdziora
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	823798 842630 (view as bug list)		Environment:
Last Closed:	2012-11-01 16:19:54 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:	842630, 871344

Description Franky Van Liedekerke 2012-03-08 15:34:57 UTC

In the latest 1.7 release of spacewalk, lookupFileInfo still returns an empty content for binary files, while getEncodedFileRevision does return the content (base64 encoded I guess). Also createOrUpdatePath has no means to specify that the uploaded file is binary.
So what I suggest:

- either change lookupFileInfo to always return base64 encoded contents, or create a new API call lookupEncodedFileInfo for that
- add the "binary" option createOrUpdatePath, so we can specify that a file is binary

Comment 1 Tomas Lestach 2012-03-08 16:32:00 UTC

configchannel.lookupFileInfo API was never meant to return binary file content. However I do not see any reason to change this API to return base64 encoded content for binary files, if you may get the binary content using configchannel.getEncodedFileRevision.

You may upload binary files using configchannel.createOrUpdatePath API as base64 encoded. If the decoded content is pure ASCII, it's marked as Text file, otherwise as Binary. Do you see any issues with this behavior?


Please, create one BZ per issue to better track them.

Comment 2 Franky Van Liedekerke 2012-03-08 18:07:52 UTC

configchannel.lookupFileInfo fails if the config file in question contains xml tags, it seems to be wanting to interpret them when returning the content via the api. Therefore my reason for wanting encoded content. The info returned by configchannel.lookupFileInfo is now wrong for binary files (it claims the file is binary but the content is empty) and failing for some text files (like xml files).
Also: configchannel.getEncodedFileRevision needs a revision, so one needs to call configchannel.lookupFileInfo first on a file to get the revision and then configchannel.getEncodedFileRevision to get the correct content.
And for the uploading: I tested using a tar-file (containing a number of plain text files) and it was marked as a text file in the interface.

Do you wish that I create seperate tickets for this? One for the configchannel.lookupFileInfo failing, one for the configchannel.lookupFileInfo content being empty for binary files, and one for the binary-flag when using configchannel.createOrUpdatePath ?

Comment 3 Tomas Lestach 2012-03-13 10:54:32 UTC

I fixed several issues for binary config files. Some of them:

 configchannel.createOrUpdatePath now accepts also binary attribute
 configchannel.createOrUpdatePath - fixed handling of binary files
 configchannel.lookupFileInfo now returns base64 encoded content for binary files

I recommend to upload xml config files base64 encoded. 

spacewalk.git: b77a05778a707b5fb12b932b78e44d01f3a188de

If you see any other issues, please open another BZ. (I tried to address as many as possible within this one.)

Changing the RFE to a bugfix BZ as the upload of binary files via API was broken.

Comment 6 Jan Pazdziora 2012-10-30 19:24:33 UTC

Moving ON_QA. Packages that address this bugzilla should now be available in yum repos at http://yum.spacewalkproject.org/nightly/

Comment 7 Jan Pazdziora 2012-11-01 16:19:54 UTC

Spacewalk 1.8 has been released: https://fedorahosted.org/spacewalk/wiki/ReleaseNotes18