You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by andreaturli <gi...@git.apache.org> on 2016/11/30 13:55:32 UTC
[GitHub] brooklyn-server pull request #471: add location details as sensors
GitHub user andreaturli opened a pull request:
https://github.com/apache/brooklyn-server/pull/471
add location details as sensors
Adds location.configKeys as sensors to the entity in addition to `SoftwareProcess.PROVISIONING_LOCATION, location`
<img width="991" alt="screen shot 2016-11-30 at 2 50 51 pm" src="https://cloud.githubusercontent.com/assets/222887/20754778/cfffae12-b70c-11e6-8a52-9ecf2952ba11.png">
Notice, it explicitly filters out some config keys:
-`identity`, `credential` for security reasons
- `spec.*`, `machineCreationSemaphore` as not meaningful/redundant
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/andreaturli/brooklyn-server feature/location-details
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/brooklyn-server/pull/471.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #471
----
commit de31f86fae9f38d492782a3799289892dd573eb1
Author: Andrea Turli <an...@gmail.com>
Date: 2016-11-30T11:30:23Z
add location details as sensors
----
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] brooklyn-server issue #471: add location details as sensors
Posted by sjcorbett <gi...@git.apache.org>.
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] brooklyn-server issue #471: add location details as sensors
Posted by googlielmo <gi...@git.apache.org>.
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] brooklyn-server issue #471: add location details as sensors
Posted by ahgittin <gi...@git.apache.org>.
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] brooklyn-server issue #471: add location details as sensors
Posted by andreaturli <gi...@git.apache.org>.
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] brooklyn-server issue #471: add location details as sensors
Posted by ahgittin <gi...@git.apache.org>.
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] brooklyn-server pull request #471: add location details as sensors
Posted by andreaturli <gi...@git.apache.org>.
Github user andreaturli closed the pull request at:
https://github.com/apache/brooklyn-server/pull/471
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] brooklyn-server issue #471: add location details as sensors
Posted by geomacy <gi...@git.apache.org>.
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] brooklyn-server issue #471: add location details as sensors
Posted by andreaturli <gi...@git.apache.org>.
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] brooklyn-server issue #471: add location details as sensors
Posted by andreaturli <gi...@git.apache.org>.
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---