Github user ahgittin commented on the issue:
    if the goal is purely to make the information available in the UI can't we 
use the existing API ?
    reading `/v1/applications/0001` gives you a block including `locations: 
[0002]`, you can then do `/v1/locations/0002` and you get all the `config:` back
    agree it isn't very nice but rather than invest time in an enricher and a 
ui which uses interim sensors, we could have the ui use the existing api
    or if we want to move towards a better solution we could (fairly easily i 
    1. expand the 
    `EntityRelations` to include `AT_LOCATION` (inverse `LOCATION_FOR`) and 
`USING_MACHINE_LOCATION` (no inverse, only present when `AT_LOCATION` is also 
present), and then 
    2. provide a `.../entities/xxx/relations/using_machine_location` call 
(returning a list of brooklyn object summaries, or at least their id's and 
    3. if needed (because the relations model isn't populated well for 
locations) put some hardcoded logic into the api call to include things from 
the Entity.locations()` method
    though thinking about it if we write the ui to work against the current api 
it would actually be a tiny change to use the above
    the DSL supporting relations feels like a bit more work.
    i also wonder whether the REST API should allow long chains --- eg to find 
the requested OS of the load balancer of an entity:
    instead of requiring user to fetch 
`../entities/xxx/relations/targetted_by`, getting a `ref1` link, then 
`${ref1}/relations/using_machine_location` (as `ref2') , then finally 
    (just an idea, on balance i think that can wait...)

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

Reply via email to