brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aled Sage <>
Subject Re: catalog item deprecated/disabled: forbidding deployment
Date Wed, 19 Aug 2015 13:06:22 GMT
Hi Andrea,

We are attaching metadata to the persisted catalog item. One can 
explicitly set "deprecated" on a catalog item, and the proposal is to 
add support for "disabled".

Is the GCE metadata a different approach from this?


On 19/08/2015 13:02, Andrea Turli wrote:
> Aled,
> interesting problem!
> I don't want to confuse things, but this reminds me of something I've seen
> before. Could metadata attached to the blueprint be an idea, like they do
> for images at GCE [1]?
> Best,
> Andrea
> [1]:
> On Wed, 19 Aug 2015 at 12:11 Alasdair Hodge <
>> wrote:
>> Agree with your proposal, Aled: WARN on deployment of any
>> deprecated/superseded catalog item, but permit it. Could also emit a
>> (different?) warning when rebinding to deprecated catalog items, but
>> that's less important IMO. I might even suggest that deprecated items
>> should still be available in the UI, but clearly discouraged for
>> deployment.
>> Agree with "disabled" in principle, but wonder how likely is it that
>> users will actually maintain that attribute on old catalog items.
>> Probably the best (== least surprising) available option however.
>> Your customer might appreciate a launch option or to
>> force deprecation warnings to be treated as errors, much like
>> configurable IDE settings for various compiler warnings. "--strict" or
>> something.
>> A.
>> --
>> Alasdair Hodge
>> Principal Engineer,
>> Cloudsoft Corporation
>> On 18/08/2015 20:01, Aled Sage wrote:
>>> 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]
>>>       "indicate that it should be avoided"
>>>       "a feature, design, or practice that is permitted but no longer
>>> recommended"
>>> [2]
>> --
>> Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
>>   Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
>> This e-mail message is confidential and for use by the addressee only. If
>> the message is received by anyone other than the addressee, please return
>> the message to the sender by replying to it and then delete the message
>> from your computer. Internet e-mails are not necessarily secure. Cloudsoft
>> Corporation Limited does not accept responsibility for changes made to this
>> message after it was sent.
>> Whilst all reasonable care has been taken to avoid the transmission of
>> viruses, it is the responsibility of the recipient to ensure that the
>> onward transmission, opening or use of this message and any attachments
>> will not adversely affect its systems or data. No responsibility is
>> accepted by Cloudsoft Corporation Limited in this regard and the recipient
>> should carry out such virus and other checks as it considers appropriate.

View raw message