Bug 836300 - Support export of images from skynet, when using topic export.
Support export of images from skynet, when using topic export.
Product: Topic Tool
Classification: Other
Component: cli-Topic_Tool (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Stephen Gordon
Depends On:
  Show dependency treegraph
Reported: 2012-06-28 11:52 EDT by Stephen Gordon
Modified: 2012-12-11 17:05 EST (History)
3 users (show)

See Also:
Fixed In Version: topic-tool-0.1.3-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-12-11 17:05:17 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Comment 1 Stephen Gordon 2012-07-18 16:59:19 EDT
Hey Matt,

Is there currently an easy way to retrieve images over say the REST interface, assuming I know the filename as stored in skynet (images/N.png)?


Comment 2 Lee Newson 2012-07-18 18:53:01 EDT
The images are exposed via the rest interface but it's in byte array form so that might not be very helpful.

Sample URL:


There's also:


but for that URL you need to be logged in, so that's not likely to be much help.

Matt might know of some thing else but that's all I can think of.
Comment 3 Stephen Gordon 2012-07-18 23:50:01 EDT
When you say you need to be logged in, can the authentication be provided via HTTP auth in the same way as for the REST API calls?
Comment 4 Lee Newson 2012-07-19 00:35:56 EDT
This is probably something that needs to be answered by Matt as he knows a lot more about Seam then I do.

However the part that determines if you're logged in from my knowledge is the JSESSIONID cookie. You should be able to get the cookie from logging in using form auth through the login page, but I haven't tried it myself so I can't be sure. I'd say your best bet is to wait for Matt to respond.

And just to add a bit more context:

Seam is responsible for handling the login details for skynet, so we actually don't really deal with low level calls such as setting the HTTP headers up. Hence why I'm not very sure.
Comment 6 Stephen Gordon 2012-11-28 14:23:15 EST
Looking at the parsing logic the main issue here is going to be that topic tool deals with hybrid books. As a result when it is parsing and looking at image tags it only parses those which are identified by a <topic_name>.images/ relative URL prefix.

This isn't possible with skynet images which just use images/<ID>.png which is basically indistinguishable from any "normal" image in a hybrid book. I think the best way to deal with this when parsing is to do the following:

- When encountering an image data check the relative URL / file name.
- If it matches the legacy topic syntax, use the existing logic.
- If the basename contains non-numeric characters skip and move on.
- If the basename contains only numeric characters see if an image can be retrieved from skynet. In the event this fails assume the image is in fact a local one and just print a warning.
Comment 7 Stephen Gordon 2012-11-28 14:39:45 EST
For an additional challenge, this probably has to be done without adding dependencies on json and json-simple. Adding dependencies on those libraries would break the packaging of topic tool on RHEL.
Comment 10 Stephen Gordon 2012-12-11 16:16:49 EST
Committed revision 87563.
Comment 11 Stephen Gordon 2012-12-11 17:00:42 EST
Committed revision 87564 to toolkit repo. The topic-tool-0.1.3-1 build is now available in the ecs-toolkit repository.

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