support for 'exported resources' #247

Closed
opened 2021-11-20 15:22:26 +00:00 by ungleich-gitea · 3 comments

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
Author
Owner

closed

closed
Author
Owner

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 ```
Author
Owner

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.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: ungleich-public/cdist#247
No description provided.