[jbosstools-dev] $0 subscription downloads - Stacks integration with download manager

[Max Rydahl Andersen]

> I'd like to suggest that we add a new attribute "downloadManagerUrl".
> This will ensure clients know that this is a workflow url and not a
> static url for downloading a file.

The original idea was that downloadUrl would be sufficient and then just 
a label
to mark it as something that can use the download manager api and the 
tools would
know the url to use for that download mechanism (maybe we could have the 
label be:
downloadmanager: <initial-resturl> ? and you look up that label and know 
what to start from?)

Is that no longer an option ?

> There's 2 parts to the rest service written by David. First is the 
> rest
> service url itself, and the second is the file we're requesting.
> Currently a url for one part of the rest workflow (in this example, to
> get terms and conditions) looks like this:
>
> ${download-manager-server}/rest/tc?downloadURL=/content/origin/files/sha256/42/42a9766b4914af02350a39612eb587170e7bf079143cc70886c9cf33022b433c/jboss-eap-6.0.0.dv.ci-installer.jar
>
> You can see the two parts are the rest service url (on test server,
> https://www-eng.jboss.org/download-manager/rest/tc)  and the second 
> part
> is what we're requesting (in this case,
> /content/origin/files/sha256/42/42a9766b4914af02350a39612eb587170e7bf079143cc70886c9cf33022b433c/jboss-eap-6.0.0.dv.ci-installer.jar)
>
> I see a few problems here. The first is that, in my opinion, those 
> urls
> are pretty long to be including in stacks.yaml

Irrelevant. Those urls are already used on our download pages so I don't 
see that as a big issue at all.

> The second, is that the rest services do not point to the next url to
> request. For example, if I go to the tc-accepted rest service to see 
> if
> the terms and conditions were accepted yet, it does not point me to 
> the
> next url in the workflow. Because of this, there's really no single
> entry-point in the workflow, and each rest service url is kind of a
> standalone url.

Sounds like something that should get fixed in the download service ?

> With the second point in mind, we might just want our stacks.yaml
> attribute to say 
> downloadManagerPath=jboss-eap-6.0.0.dv.ci-installer.jar.

Rather fix the download service so no such weird details has to leak 
into stacks.yml.

> The client (in this case jbosstools) would pass that string to the
> download manager rest service it chooses to use. The download-manager
> server would resolve jboss-eap-6.0.0.dv.ci-installer.jar to its more
> specific /content/sha256/23423823423/etc  path, and proceed normally.
>
> One concern with this approach is that the stacks.yaml will never
> include the actual url of the rest service entry point. Even if we
> wanted to have stacks.yaml point to the entry point, there's no one
> entry-point since the rest services do not point to the next step in 
> the
> workflow.

lets fix the service to be complete then ?

/max