Deploy app using URL to a blueprint

[richardcloudsoft]

Changes the behaviour of the "Create App" YAML tab to allow the user to present a URL that contains the actual blueprint. The URL is fetched and the content is used as a YAML blueprint.

[buildhive]

Brooklyn Central » brooklyn #2387 SUCCESS This pull request looks good (what's this?)

[ahgittin]

so, effectively we are saying if the so-called yaml input is actually a URL we import it? feels safe enough as a convenience because a URL will never be a valid YAML plan

this feels like the sort of overloading i'd do :) ... i think i'm okay with this if others are

another option would be to do three things:

1) support URL as the service type:

services:
- type: http://path/to/my1.yaml

2) automatically promote the unique child service for any blueprint which declares one service, nothing else (no name, or root brooklyn.* options), and where that service can be treated like an app (it is an App class or a blueprint which can be made to be an app class). i've been thinking about this for a while and on balance it feels the best way to avoid these irritating wrapper apps, particularly if we are supporting references.

3) where additional flags are supplied to a referenced blueprint, they are appended to underlying maps/lists

services:
- type: http://path/to/my1.yaml
  brooklyn.config: { addl_config: 42 }

so two questions:

• WDYT of the proposal I'm making?
• If we action this proposal (very soon) do we still want to support the simple overloaded convenience of this PR?

(my opinion is yes to both)

[aledsage]

Longer term, we should change our web-console to have separate text boxes for URI and for yaml. Until then, it's ok to put this in. But before we release 0.7.0 GA I'd go for the separate API calls for URL and yaml.

Want to use this with a customer asap.

For your proposal, will think about it more. First impression is good.

[richardcloudsoft]

Liked @aledsage's suggested change of using getResourceAsString() so have switched to that.

@ahgittin your suggestion is really good, but it's solving a different kind of problem that this PR intends to solve. So "yes to both" :smiley:

[buildhive]

Brooklyn Central » brooklyn #2407 SUCCESS This pull request looks good (what's this?)