Hi all,
A customer has asked that Brooklyn give an error when attempting to
deploy "deprecated" catalog items (i.e. refuse to deploy them).
In my opinion, this is not quite the classic meaning of "deprecated"
[1,2]. I suggest we add another state for catalog items (e.g. "disabled").
Do people agree? Or think we should change the behaviour of deprecated?
_*Existing behaviour*_
Items in the catalog can be marked as deprecated. This means the item is
still kept in the catalog, but its metadata says "deprecated".
In the Brooklyn web-console "add application" wizard, the deprecated
item is hidden. However, if you specify that exact version in YAML, then
you can still use it.
Note: it's important to not delete the catalog item if any applications
are using it. On rebind (i.e. restarting Brooklyn), we want to be able
to find the catalog item for class-loading purposes (e.g. to find out
the right OSGi bundles).
_*Proposal*_
We leave "deprecated" to have (mostly) the existing behaviour. We
augment this to log.warn whenever an app is deployed that is deprecated.
(It would be nice to show in the web-console that a deprecated app was
used, but I suggest we defer that).
We add "disabled". When a catalog item is disabled, it cannot be used
for deploying new apps. Any such attempt would give an error.
_*In the future...*_
Longer term, we could consider changing the behaviour of "deleting" a
catalog item. For example, the item would no longer be listable or
usable. However, it would not be expunged from the catalog until there
were no more active uses of that catalog item. This would be detected
automatically (akin to garbage collection).
We could perhaps add an "expunge" for catalog items that entirely
deleted it from the catalog, even if app instances existed.
Aled
[1] https://en.wikipedia.org/wiki/Deprecation
"indicate that it should be avoided"
"a feature, design, or practice that is permitted but no longer
recommended"
[2] http://docs.oracle.com/javase/7/docs/api/java/lang/Deprecated.html
