I'm actually intending to go in another direction with this - and include the MAC_ADDRESS as an item fed to the hooks scripts. I'm still debating the precise mechanism of exposing the metadata - and would appreciate any preference you'd have. As I see it, there are essentially 3 major mechanisms:
Some sort of serialised single-argument call into a hook, with the expectation the hook knows how to deserialise it. I consider this undesirable, as hook writers may be impacted by any schema change.
Individual hook function calls per metadata piece. This would be resilient to schema changes, but may impose a burden on the hook writer
Wrapped helper functions in sb-provisioner that hooks can use at any time to obtain device data. I consider this the most desirable, provided the pattern is resilient to functions going missing.
I'm actually intending to go in another direction with this - and include the MAC_ADDRESS as an item fed to the hooks scripts. I'm still debating the precise mechanism of exposing the metadata - and would appreciate any preference you'd have. As I see it, there are essentially 3 major mechanisms: