brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Zaccardo <mike.zacca...@cloudsoftcorp.com>
Subject Re: catalog item deprecated/disabled: forbidding deployment
Date Thu, 20 Aug 2015 15:20:28 GMT
+1 for booleans and +1 for the first REST proposal (4x methods)

-Mike
On Aug 20, 2015 5:21 AM, "Aled Sage" <aled.sage@gmail.com> wrote:

> 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 <aled.sage@gmail.com>
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 <
>>>>>>>> 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