Getting NodeMetadata available to entities

[Richard Downer <ri...@apache.org>]

Hi all.

I'm trying to solve a problem which basically involves getting a value from
the jclouds `NodeMetadata` into a sensor on all entities in that
`JcloudsLocation`. A `JcloudsLocationCustomizer` would appear to be useful
as it gets all the `NodeMetadata`, but as it doesn’t get a reference to the
entity it can’t add the sensor itself.

I looked at other possible solution but it seems that the `NodeMetadata` is
thrown away by Brooklyn once the machine is started, so a solution like
`EntityInitializer` isn’t going to work either. My current plan is to use a
location customizer to get the data needed and stash it somewhere in the
`MachineLocation` config, and an initializer to retrieve it and set a
sensor, but this sounds messy and also requires blueprints to be modified
to add the initializer.

Are there any other possible solutions?

Thanks
Richard.

Re: Getting NodeMetadata available to entities

[Richard Downer <ri...@apache.org>]

Hi Alex,

On 23 January 2018 at 10:39, Alex Heneveld <al...@cloudsoftcorp.com>
wrote:

> What values does it need?  Would it make sense to put it into
> BasicMachineMetadata and adjust JcloudsLocation.getMachineMetadata to add
> it for everything?
>

That would be a good solution for the medium or long term - there's not
much reason for having all the `NodeMetadata`, cherry-picking out the IP
address and then throwing the rest away! I suppose it's theoretically
possible that the metadata might include some sensitive information that is
not appropriate to be exposed in some kinds of service provider use cases
but I think that's unlikely to be a general problem.

What I specifically need is the `userMetadata`. The particular cloud
provider in question sets additional metadata k/v pairs, and one of these
values I would like to expose in the GUI.

However I'm really looking for a way to do this in the short term (without
waiting for a release cycle).

The other option if you want to opt-in at an initializer is for it to do
> `location.getConfig(CALLER_CONTEXT)` -- there isn't guaranteed to be
> exactly one Entity for each Location
> (might have multiple, might have none) so there isn't a
> `Location.getEntity()` and this value might not be an `Entity`, but if
> there _is_ such a one-to-one releationship where an entity creates a
> location, the usual pattern is that the Entity will set itself as this
> context.
>

Thanks, I'll look into this.

Cheers
Richard.

Re: Getting NodeMetadata available to entities

[Alex Heneveld <al...@cloudsoftcorp.com>]

Richard,

What values does it need?  Would it make sense to put it into 
BasicMachineMetadata and adjust JcloudsLocation.getMachineMetadata to 
add it for everything?

The other option if you want to opt-in at an initializer is for it to do 
`location.getConfig(CALLER_CONTEXT)` -- there isn't guaranteed to be 
exactly one Entity for each Location
(might have multiple, might have none) so there isn't a 
`Location.getEntity()` and this value might not be an `Entity`, but if 
there _is_ such a one-to-one releationship where an entity creates a 
location, the usual pattern is that the Entity will set itself as this 
context.

Best
Alex


On 23/01/2018 10:30, Richard Downer wrote:
> Hi all.
>
> I'm trying to solve a problem which basically involves getting a value from
> the jclouds `NodeMetadata` into a sensor on all entities in that
> `JcloudsLocation`. A `JcloudsLocationCustomizer` would appear to be useful
> as it gets all the `NodeMetadata`, but as it doesn’t get a reference to the
> entity it can’t add the sensor itself.
>
> I looked at other possible solution but it seems that the `NodeMetadata` is
> thrown away by Brooklyn once the machine is started, so a solution like
> `EntityInitializer` isn’t going to work either. My current plan is to use a
> location customizer to get the data needed and stash it somewhere in the
> `MachineLocation` config, and an initializer to retrieve it and set a
> sensor, but this sounds messy and also requires blueprints to be modified
> to add the initializer.
>
> Are there any other possible solutions?
>
> Thanks
> Richard.
>