brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Turli <andrea.tu...@cloudsoftcorp.com>
Subject Re: catalog item deprecated/disabled: forbidding deployment
Date Wed, 19 Aug 2015 12:02:34 GMT
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]: https://cloud.google.com/compute/docs/reference/latest/images/deprecate

On Wed, 19 Aug 2015 at 12:11 Alasdair Hodge <
alasdair.hodge@cloudsoftcorp.com> 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 brooklyn.property 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] 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
> >
> >
>
>
> --
> 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.
>

-- 
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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message