support for 'exported resources' #247

New Issue

ungleich-gitea · 2021-11-20T15:22:26Z

ungleich-gitea commented

2021-11-20 15:22:26 +00:00

Created by: asteven

RFC

use case

need a way to get X from host A when configuring host B
something like exported resources in puppet

example

# run on host A to setup an opennebula controller
type/__opennebula_controller/
   export/
      oneadmin-password
      ssh-key
      oneadmin-userid
      oneadmin-groupid

# then cdist does something like this
# where the script is executed on the target_host
# but the output saved on the server
# just like explorers work - but executed as last thing instead of as first
$__type/export/oneadmin-password > $__object/export/oneadmin-password


--------------------------------------------------------------------------------

# run on host B to config for use with opennebula controller on host A
__opennebula_node --controller one-1.example.lan
# and in the manifest:
# type/__opennebula_node/manifest
...
controller="$(cat "$__object/parameter/controller")"
oneadmin_password="$(cat "$__export/$controller/oneadmin-password")"
ssh_key="$(cat "$__export/$controller/ssh-key")"
oneadmin_userid="$(cat "$__export/$controller/oneadmin-userid")"
oneadmin_groupid="$(cat "$__export/$controller/oneadmin-groupid")"
...

thoughts

no 'api' to talk to the cache from types
cdist types have no way to get data after the object has finished,
this is also not available in the cache
could create another type that runs after and get's the data via explorers,
e.g. __opennebula_controller_exports, and get that from the cache later on,
but feels quite hacky

*Created by: asteven* RFC ### use case - need a way to get X from host A when configuring host B - something like exported resources in puppet ### example ``` # run on host A to setup an opennebula controller type/__opennebula_controller/ export/ oneadmin-password ssh-key oneadmin-userid oneadmin-groupid # then cdist does something like this # where the script is executed on the target_host # but the output saved on the server # just like explorers work - but executed as last thing instead of as first $__type/export/oneadmin-password > $__object/export/oneadmin-password -------------------------------------------------------------------------------- # run on host B to config for use with opennebula controller on host A __opennebula_node --controller one-1.example.lan # and in the manifest: # type/__opennebula_node/manifest ... controller="$(cat "$__object/parameter/controller")" oneadmin_password="$(cat "$__export/$controller/oneadmin-password")" ssh_key="$(cat "$__export/$controller/ssh-key")" oneadmin_userid="$(cat "$__export/$controller/oneadmin-userid")" oneadmin_groupid="$(cat "$__export/$controller/oneadmin-groupid")" ... ``` ### thoughts - no 'api' to talk to the cache from types - cdist types have no way to get data _after_ the object has finished, this is also not available in the cache - could create another type that runs after and get's the data via explorers, e.g. __opennebula_controller_exports, and get that from the cache later on, but feels quite hacky

ungleich-gitea added this to the future milestone 2021-11-20 15:22:26 +00:00

ungleich-gitea added the

Stale

label 2021-11-20 15:22:26 +00:00

ungleich-gitea closed this issue

2021-11-20 15:22:26 +00:00

ungleich-gitea commented

2021-11-20 15:49:58 +00:00

closed

ungleich-gitea commented

2021-11-20 15:49:59 +00:00

Created by: asteven

Thinking some more about this, the 'exports' if we want to stick with that name for the moment should be collected and stored in a global 'database', independent of __target_host or cache or whatever.

The structure should not be dictated by cdist, the types should create their own namespaces.
$__export/$namespace/$key

e.g.

$__export/
   ssh_host_keys/
      some-host.domain.tld/
         ssh_host_dsa_key.pub
         ssh_host_ecdsa_key.pub
         ssh_host_key.pub
         ssh_host_rsa_key.pub
      other-host.domain.tld/
         ssh_host_dsa_key.pub
         ssh_host_ecdsa_key.pub
         ssh_host_key.pub
         ssh_host_rsa_key.pub

$__export/
   opennebula/
      my-fancy-cluster-name/
         exports
         oneadmin-password
         ssh-key
         oneadmin-userid
         oneadmin-groupid
      even-fancier-cluster/
         exports
         oneadmin-password
         ssh-key
         oneadmin-userid
         oneadmin-groupid

$__export/
   whatever/you/want/
      foo
      nested/to/
         wherever

*Created by: asteven* Thinking some more about this, the 'exports' if we want to stick with that name for the moment should be collected and stored in a global 'database', independent of __target_host or cache or whatever. The structure should not be dictated by cdist, the types should create their own namespaces. $__export/$namespace/$key e.g. ``` $__export/ ssh_host_keys/ some-host.domain.tld/ ssh_host_dsa_key.pub ssh_host_ecdsa_key.pub ssh_host_key.pub ssh_host_rsa_key.pub other-host.domain.tld/ ssh_host_dsa_key.pub ssh_host_ecdsa_key.pub ssh_host_key.pub ssh_host_rsa_key.pub $__export/ opennebula/ my-fancy-cluster-name/ exports oneadmin-password ssh-key oneadmin-userid oneadmin-groupid even-fancier-cluster/ exports oneadmin-password ssh-key oneadmin-userid oneadmin-groupid $__export/ whatever/you/want/ foo nested/to/ wherever ```

ungleich-gitea commented

2021-11-20 15:50:01 +00:00

Created by: telmich

Moin Moin,

I think this is a great approach - I would probably call it something
like "final" or "post", because the job of these scripts is not limited
to exporting information.

Additionally, it's worth thinking about a global "final" / "export"
script - the example you showed is more type specific (great!), but
maybe one wants to export other stuff as well; the resulting structure
could be something like this:

$__export/
    $hostname/
        global/
            <names of export scripts>
        object/
            __opennebula_node/
                <names of export scripts>
            __another_type_with/
                object_id/
                    <names of export scripts>

I think it is a very good approach - even if this was not the final
solution, I think it is going into the right way!

Cheers,

Nico

Steven Armstrong [Thu, Dec 19, 2013 at 01:02:19AM -0800]:

RFC

use case

need a way to get X from host A when configuring host B

something like exported resources in puppet

example
# run on host A to setup an opennebula controller
type/__opennebula_controller/
   export/
      oneadmin-password
      ssh-key
      oneadmin-userid
      oneadmin-groupid

# then cdist does something like this
# where the script is executed on the target_host
# but the output saved on the server
# just like explorers work - but executed as last thing instead of as first
$__type/export/oneadmin-password > $__object/export/oneadmin-password


--------------------------------------------------------------------------------

# run on host B to config for use with opennebula controller on host A
__opennebula_node --controller one-1.example.lan
# and in the manifest:
# type/__opennebula_node/manifest
...
controller="$(cat "$__object/parameter/controller")"
oneadmin_password="$(cat "$__export/$controller/oneadmin-password")"
ssh_key="$(cat "$__export/$controller/ssh-key")"
oneadmin_userid="$(cat "$__export/$controller/oneadmin-userid")"
oneadmin_groupid="$(cat "$__export/$controller/oneadmin-groupid")"
...
thoughts

no 'api' to talk to the cache from types

cdist types have no way to get data after the object has finished,
this is also not available in the cache

could create another type that runs after and get's the data via explorers,
e.g. __opennebula_controller_exports, and get that from the cache later on,
but feels quite hacky

Reply to this email directly or view it on GitHub:
https://github.com/telmich/cdist/issues/235

PGP key: 7ED9 F7D3 6B10 81D7 0EC5 5C09 D7DC C8E4 3187 7DF0

*Created by: telmich* Moin Moin, I think this is a great approach - I would probably call it something like "final" or "post", because the job of these scripts is not limited to exporting information. Additionally, it's worth thinking about a global "final" / "export" script - the example you showed is more type specific (great!), but maybe one wants to export other stuff as well; the resulting structure could be something like this: ``` $__export/ $hostname/ global/ <names of export scripts> object/ __opennebula_node/ <names of export scripts> __another_type_with/ object_id/ <names of export scripts> ``` I think it is a very good approach - even if this was not the final solution, I think it is going into the right way! Cheers, Nico Steven Armstrong [Thu, Dec 19, 2013 at 01:02:19AM -0800]: > RFC > > ### use case > - need a way to get X from host A when configuring host B > - something like exported resources in puppet > > ### example > > ``` > # run on host A to setup an opennebula controller > type/__opennebula_controller/ > export/ > oneadmin-password > ssh-key > oneadmin-userid > oneadmin-groupid > > # then cdist does something like this > # where the script is executed on the target_host > # but the output saved on the server > # just like explorers work - but executed as last thing instead of as first > $__type/export/oneadmin-password > $__object/export/oneadmin-password > > > -------------------------------------------------------------------------------- > > # run on host B to config for use with opennebula controller on host A > __opennebula_node --controller one-1.example.lan > # and in the manifest: > # type/__opennebula_node/manifest > ... > controller="$(cat "$__object/parameter/controller")" > oneadmin_password="$(cat "$__export/$controller/oneadmin-password")" > ssh_key="$(cat "$__export/$controller/ssh-key")" > oneadmin_userid="$(cat "$__export/$controller/oneadmin-userid")" > oneadmin_groupid="$(cat "$__export/$controller/oneadmin-groupid")" > ... > ``` > > ### thoughts > - no 'api' to talk to the cache from types > - cdist types have no way to get data _after_ the object has finished, > this is also not available in the cache > - could create another type that runs after and get's the data via explorers, > e.g. __opennebula_controller_exports, and get that from the cache later on, > but feels quite hacky > > --- > > Reply to this email directly or view it on GitHub: > https://github.com/telmich/cdist/issues/235 ## PGP key: 7ED9 F7D3 6B10 81D7 0EC5 5C09 D7DC C8E4 3187 7DF0

Sign in to join this conversation.