Improving the catalogue

[sjcorbett]

• Can I add new entries to the catalogue when Brooklyn is already running?
• Are those new entries persisted?
• Can I refer to YAML blueprints in catalog.xml?
• How do I manage several versions of the same application?

I'd like to see these questions answered in documentation on http://brooklyncentral.github.io.

[ahgittin]

Currently: no, no, no, no.

I think this issue should be changed to "Update Catalog" to fix these limitations. (Catalog was a very quick placeholder and has always been meant to be revisited when we better understand.)

Several things I'd like to see changed:

1. Ability to support YAML blueprints as well as classes.

2. Ability to indicate compatible brooklyn versions.

3. Remove catalog "scanning" mode. This is too slow on startup and heavyweight. Instead:

• There should be an operation via the REST API and GUI which allows manual updates to the catalog (class, yaml, or import a catalog from elsewhere), as well as triggering a "populate catalog by scanning" command
• There should be an operation to verify catalog items to make it easy to spot those which are not compatible (if metadata indicates a different version of brooklyn) or problematic (if they won't load) so that they can be removed
• On first load if there is no catalog, give the option to scan and/or import a predefined catalog (e.g. at cloudsoftcorp.com)

4. Ability to support tags, and search based on tags in the GUI.

Finally we want to support versioning but I think this should be a separate issue (it impacts catalog but is mostly independent). I expect this will likely leverage OSGi for classpath isolation as well as dependency resolution. What would be really cool is a "test-switch-version" which will serialize an existing app instance brooklyn model from one version then attempt to deserialize it with another version, so we can live-update blueprints.

[grkvlt]

See #1286 for YAML in Catalog