You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Mark Mc Kenna <m4...@apache.org> on 2017/04/25 10:10:56 UTC
Tweak to application API returned location id
Hi All,
Ive opened a pr [1] that updates the behaviour of the application API so
that the application spec locations array contains the catalog item id
(instead of the unique ID)
IMO this is better behaviour, but as it is a behaviour change to the API I
thought it better to raise it here.
Opinions?
M
[1]
https://github.com/apache/brooklyn-server/pull/648
Re: Tweak to application API returned location id
Posted by Alex Heneveld <al...@cloudsoftcorp.com>.
Hi Mark-
I'd like to keep backwards compatibility. We don't know where this
might be used.
Also the catalog item ID isn't sufficient I don't think. Returning just
the catalog item ID means you lose any custom configuration on the
location in the blueprint (ie on top of the catalog item ID); I'm not
sure it even works at all if you use legacy "jclouds:aws-ec2" syntax;
and you won't get any added-after-deployed information. It isn't a
problem in many cases but it is a weaker API.
Could we add a new "locationsDetail" field which contains eg "{ [ id:
<old value>, catalogItemId: <what you want>, displayName: <optional>,
... ] }" and we could add any further metadata we want?
I'd also be in favour of doing this for all entities, not just applications.
Best
Alex
On 25/04/2017 20:41, Thomas Bouron wrote:
> Not that I am aware of. The only place where I can see this information is
> on the UI, summary tab.
> But that is for display only.
>
> Best.
>
> On Tue, 25 Apr 2017 at 18:48 Geoff Macartney <
> geoff.macartney@cloudsoftcorp.com> wrote:
>
>> What about possible backward compatibility issues? Might anything be
>> relying on the current behaviour?
>>
>>
>>
>> On Tue, 25 Apr 2017 at 12:15 Thomas Bouron <
>> thomas.bouron@cloudsoftcorp.com>
>> wrote:
>>
>>> Hi Mark.
>>>
>>> Yes, it makes sense to me as the location ID currently returned is only
>> for
>>> internal use. One can use it to get back the location information to
>>> `/v1/location` but:
>>>
>>> 1. it works with either the internal ID or catalog ID
>>> 2. it's deprecated since 0.7.0 and should be removed
>>>
>>> So +1 for me
>>>
>>>
>>> On Tue, 25 Apr 2017 at 11:11 Mark Mc Kenna <m4...@apache.org>
>> wrote:
>>>> Hi All,
>>>>
>>>> Ive opened a pr [1] that updates the behaviour of the application API
>> so
>>>> that the application spec locations array contains the catalog item id
>>>> (instead of the unique ID)
>>>>
>>>> IMO this is better behaviour, but as it is a behaviour change to the
>> API
>>> I
>>>> thought it better to raise it here.
>>>>
>>>> Opinions?
>>>>
>>>> M
>>>>
>>>> [1] \u200b
>>>> https://github.com/apache/brooklyn-server/pull/648
>>>>
>>> --
>>>
>>> Thomas Bouron \u2022 Senior Software Engineer @ Cloudsoft Corporation \u2022
>>> https://cloudsoft.io/
>>> Github: https://github.com/tbouron
>>> Twitter: https://twitter.com/eltibouron
>>>
Re: Tweak to application API returned location id
Posted by Thomas Bouron <th...@cloudsoftcorp.com>.
Not that I am aware of. The only place where I can see this information is
on the UI, summary tab.
But that is for display only.
Best.
On Tue, 25 Apr 2017 at 18:48 Geoff Macartney <
geoff.macartney@cloudsoftcorp.com> wrote:
> What about possible backward compatibility issues? Might anything be
> relying on the current behaviour?
>
>
>
> On Tue, 25 Apr 2017 at 12:15 Thomas Bouron <
> thomas.bouron@cloudsoftcorp.com>
> wrote:
>
> > Hi Mark.
> >
> > Yes, it makes sense to me as the location ID currently returned is only
> for
> > internal use. One can use it to get back the location information to
> > `/v1/location` but:
> >
> > 1. it works with either the internal ID or catalog ID
> > 2. it's deprecated since 0.7.0 and should be removed
> >
> > So +1 for me
> >
> >
> > On Tue, 25 Apr 2017 at 11:11 Mark Mc Kenna <m4...@apache.org>
> wrote:
> >
> > > Hi All,
> > >
> > > Ive opened a pr [1] that updates the behaviour of the application API
> so
> > > that the application spec locations array contains the catalog item id
> > > (instead of the unique ID)
> > >
> > > IMO this is better behaviour, but as it is a behaviour change to the
> API
> > I
> > > thought it better to raise it here.
> > >
> > > Opinions?
> > >
> > > M
> > >
> > > [1]
> > > https://github.com/apache/brooklyn-server/pull/648
> > >
> > --
> >
> > Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
> > https://cloudsoft.io/
> > Github: https://github.com/tbouron
> > Twitter: https://twitter.com/eltibouron
> >
>
--
Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
https://cloudsoft.io/
Github: https://github.com/tbouron
Twitter: https://twitter.com/eltibouron
Re: Tweak to application API returned location id
Posted by Geoff Macartney <ge...@cloudsoftcorp.com>.
What about possible backward compatibility issues? Might anything be
relying on the current behaviour?
On Tue, 25 Apr 2017 at 12:15 Thomas Bouron <th...@cloudsoftcorp.com>
wrote:
> Hi Mark.
>
> Yes, it makes sense to me as the location ID currently returned is only for
> internal use. One can use it to get back the location information to
> `/v1/location` but:
>
> 1. it works with either the internal ID or catalog ID
> 2. it's deprecated since 0.7.0 and should be removed
>
> So +1 for me
>
>
> On Tue, 25 Apr 2017 at 11:11 Mark Mc Kenna <m4...@apache.org> wrote:
>
> > Hi All,
> >
> > Ive opened a pr [1] that updates the behaviour of the application API so
> > that the application spec locations array contains the catalog item id
> > (instead of the unique ID)
> >
> > IMO this is better behaviour, but as it is a behaviour change to the API
> I
> > thought it better to raise it here.
> >
> > Opinions?
> >
> > M
> >
> > [1]
> > https://github.com/apache/brooklyn-server/pull/648
> >
> --
>
> Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
> https://cloudsoft.io/
> Github: https://github.com/tbouron
> Twitter: https://twitter.com/eltibouron
>
Re: Tweak to application API returned location id
Posted by Thomas Bouron <th...@cloudsoftcorp.com>.
Hi Mark.
Yes, it makes sense to me as the location ID currently returned is only for
internal use. One can use it to get back the location information to
`/v1/location` but:
1. it works with either the internal ID or catalog ID
2. it's deprecated since 0.7.0 and should be removed
So +1 for me
On Tue, 25 Apr 2017 at 11:11 Mark Mc Kenna <m4...@apache.org> wrote:
> Hi All,
>
> Ive opened a pr [1] that updates the behaviour of the application API so
> that the application spec locations array contains the catalog item id
> (instead of the unique ID)
>
> IMO this is better behaviour, but as it is a behaviour change to the API I
> thought it better to raise it here.
>
> Opinions?
>
> M
>
> [1]
> https://github.com/apache/brooklyn-server/pull/648
>
--
Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
https://cloudsoft.io/
Github: https://github.com/tbouron
Twitter: https://twitter.com/eltibouron