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 < [email protected]> 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 < > [email protected]> > 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 <[email protected]> > 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
