[GitHub] brooklyn-server issue #471: add location details as sensors
Github user andreaturli commented on the issue: https://github.com/apache/brooklyn-server/pull/471 thanks @geomacy @sam @ahgittin and @googlielmo for your feedbacks As the goal is purely to make the information available in the UI I think we should use the existing API and show them maybe in the summary tab as _Location_ block. I'll close this PR and I'll open a new one asap --- 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 infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] brooklyn-server issue #471: add location details as sensors
Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-server/pull/471
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
expect)
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
url's)
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:
.../entities/xxx/relations/targetted_by[0]/relations/using_machine_location[0]/config/osFamily
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
`${ref2}/config/osFamily`.
(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 infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] brooklyn-server issue #471: add location details as sensors
Github user geomacy commented on the issue: https://github.com/apache/brooklyn-server/pull/471 @sjcorbett, agreed, - to tie some threads together I'll link @ahgittin's suggestion here https://github.com/apache/brooklyn-server/pull/300#issuecomment-262499059. I'd agree that doing it in an enricher is preferable to adding it by default on entities, and would be a useful interim step before a full `relations()` implementation. --- 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 infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] brooklyn-server issue #471: add location details as sensors
Github user sjcorbett commented on the issue: https://github.com/apache/brooklyn-server/pull/471 Another interim option would be to write an enricher that does the publication so its inclusion is up to the user. --- 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 infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] brooklyn-server issue #471: add location details as sensors
Github user googlielmo commented on the issue: https://github.com/apache/brooklyn-server/pull/471 I'd like to preserve the gist of @andreaturli's proposal. To address @ahgittin's comment, I propose that, instead of adding more sensors, we publish this information as additional properties of the existing `softwareservice.ProvisioningLocation` sensor, a JSON object. They may be then picked up by the UI in a separate location panel later on. --- 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 infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] brooklyn-server issue #471: add location details as sensors
Github user andreaturli commented on the issue: https://github.com/apache/brooklyn-server/pull/471 @ahgittin would it be useful to add those details to the summary tab instead, maybe? I think I'm simply trying to bubble them up so they are more evident, but they don't need to be "consumable" from blueprints in the use case I've in mind. --- 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 infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] brooklyn-server issue #471: add location details as sensors
Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-server/pull/471
i worry about this because if blueprints are built relying on this then we
are committed to having it always -- feels useful in the short term, but longer
term wasteful to keep this copy of data, and confusing if eg we have two
locations, do we copy both their sensor data?
if there's a strong use case then could add it but otherwise i'd rather not
do it here, but instead add support for
`$brooklyn:relation("running_on_machine").config("xxx")` (as suggested on
mailing list last night) /cc @grkvlt
---
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 infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] brooklyn-server issue #471: add location details as sensors
Github user andreaturli commented on the issue: https://github.com/apache/brooklyn-server/pull/471 thanks @googlielmo for the first (offline) review --- 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 infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
