Thanks, and yes: I'll ensure tests cover rebinding where the values are
absent.
Aled
On 20/08/2015 13:20, Alex Heneveld wrote:
aled-
+1 multiple booleans. something might be disabled but not
deprecated. there would be no functional difference but it might be a
semantic difference.
can we make sure persisted state is happy if the entry is absent, it
just defaults to false?
best
alex
On 20/08/2015 13:12, Aled Sage wrote:
Hi all,
I'd like to finish this soon, so would like to reach consensus:
I lean towards boolean for deprecated:
* because disabling/enabling shouldn't clear whether it is "deprecated"
* because google images use a separate piece of metadata for each of
deprecated, obsolete and deleted (and hopefully they thought about
it a lot; they also have "reason").
---
We can refactor it later - it's (mostly) back-end stuff.
However, we'd need to be careful to transform the catalog item's
persisted state (which will store the booleans).
The REST API also implies a mental model of separate metadata
properties. The api allows:
POST /v1/catalog/{itemId}/deprecated/true
POST /v1/catalog/{itemId}/deprecated/false
POST /v1/catalog/{itemId}/disabled/true
POST /v1/catalog/{itemId}/disabled/false
An alternative would be something like:
POST /v1/catalog/{itemId}/availability/available
POST /v1/catalog/{itemId}/availability/deprecated
POST /v1/catalog/{itemId}/availability/disabled
Aled
On 19/08/2015 14:55, Aled Sage wrote:
Thanks Alex, all,
I'd just finished implementing the basic "boolean disabled"
functionality [1].
Yes, disabled is stronger than deprecated.
Enumeration: interesting suggestion. Not sure - hard to know what if
any other states we'd add, and whether there's any use-case for
setting as both deprecated + disabled.
I am tempted to change to an enumeration, even though I don't want
to have to do more work on it right now!
Thoughts?
"Replacement" field (as GCE have). Nice idea. Can be added
separately/later, I think. Normally it's because there is a newer
version of the blueprint that should be used instead, which is
fairly self evident. But I'm sure it would be useful in other
situations.
Aled
[1] https://github.com/apache/incubator-brooklyn/pull/850 (but needs
rebased against master for package renames)
On 19/08/2015 14:36, Alex Heneveld wrote:
+1 to the idea of "disabled"
Presumably disabled is stronger than deprecated. Do we want both
as booleans or an enum e.g. "availability" ?
Could be nice to have a "replacement" field (which can be set to
refer to a catalog item to use instead) and perhaps an
availability_comment (free-form text on why something is
deprecated/disabled)... just some thoughts.
--A
On 19/08/2015 14:20, Andrea Turli wrote:
Hi Aled,
not different, simply I was wondering if a schema like the one
used in GCE
{
"state": string,
"replacement": string,
"deprecated": string,
"obsolete": string,
"deleted": string
}
could have been of any help.
Seems like `disabled` is similar to `obsolete` so your proposal is
in line
with GCE approach, I think.
My two cents,
Andrea
On Wed, 19 Aug 2015 at 15:06 Aled Sage <[email protected]> wrote:
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?
Aled
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]:
https://cloud.google.com/compute/docs/reference/latest/images/deprecate
On Wed, 19 Aug 2015 at 12:11 Alasdair Hodge <
[email protected]> 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.
