How manage tag (exported ressources)

[Albert Shih]

Hi,

I would like to know how you or what's best practice to manage tag in
exported resources.

For example I have two hosts H1 and H2->100, and I want export file_line from H2->100
to H1.

So or I use a standardized tag (like "for_${::fqdn}" whatever the kind of
resource) than in H1 I can very easily imported those resource. Or I need
share a information between those two hosts (and I don't know how to do
that properly when I have lot of exported resources).

What's best way ?

Regards.
--
Albert SHIH
Observatoire de Paris

[jcbollinger]

I would start by generalizing the problem a bit.  Why do you want to export a resource from H1 to H2->100?  There are two aspects that I would recommend being reflected by one or more tags:

1. File_line is a very generic resource.  It will likely be helpful, therefore, to tag instances with something that narrows that type in a meaningful way.  For example, if there were not already a Host resource type, then you might use File_line tagged with something like "hosts_line" for the same purpose.
2. Since you specifically want one host to collect this resource, it sounds like there is a question of scope that might be appropriately reflected by a tag.  It is unlikely that H1's identity is an appropriate descriptor for that scope, however.  The scope in question might be a data center, a compute cluster, an application, or similar.  That's what should be reflected by tagging.  Or maybe you don't actually need a scope narrower than your whole site after all.

This permits you to decouple H1 and H2->100 from each other, making the whole arrangement both clearer and more flexible.  H2->100 does not need to know or care which node(s), if any, are going to collect the resources it exports, and it doesn't need to do anything differently if that changes.  On the H1 side, the purpose of collecting the particular resources it does is clearer.

John

[Albert Shih]

Le 12/02/2018 à 07:11:23-0800, jcbollinger a écrit
>

HI,

>
> I would start by generalizing the problem a bit.  Why do you want to export a
> resource from H1 to H2->100?  There are two aspects that I would recommend

file_line was just a example, because currently I work on that.

> being reflected by one or more tags:
>

> 1. File_line is a very generic resource.  It will likely be helpful,

> therefore, to tag instances with something that narrows that type in a
> meaningful way.  For example, if there were not already a Host resource
> type, then you might use File_line tagged with something like "hosts_line"
> for the same purpose.

> 2. Since you specifically want one host to collect this resource, it sounds

> like there is a question of scope that might be appropriately reflected by
> a tag.  It is unlikely that H1's identity is an appropriate descriptor for
> that scope, however.  The scope in question might be a data center, a
> compute cluster, an application, or similar.  That's what should be

You're absolutly right, in fact that's exactly why I ask. In some way I
know using the hostname was a wrong idea. But didn't find a another way.

> This permits you to decouple H1 and H2->100 from each other, making the whole
> arrangement both clearer and more flexible.  H2->100 does not need to know or
> care which node(s), if any, are going to collect the resources it exports, and
> it doesn't need to do anything differently if that changes.  On the H1 side,
> the purpose of collecting the particular resources it does is clearer.

Thanks for the suggestion.

But where should I put this tag information ? For example let's say I've
two « nagios_like » one master, one slave. So I need two tags :

monitoring_master
monitoring_slave

Inside all my module I would like to export to those two tags, so should I
put them inside

hieradata/common.yaml

with something like

monitoring_master_tag: 'monitoring_master'
monitoring_slave_tag: 'monitoring_slave'

so I can access to those informations informations everywhere. Or do it in
other way because it's « bad » way to do that?

Regards

JAS
--
Albert SHIH
xmpp: j...@obspm.fr
Heure local/Local time:
Fri Feb 16 13:42:57 CET 2018