We should be able to handle simple apply actions in simple plans.
* `apply_prep` should be implicitly called on targets at least once in the plan. * It should support a data format of resource declaration.
Questions: should we use an array or hash?
{noformat} --- steps: # + This allows us to maintain manifest ordering which may be useful # - need to come up with safe keyword for resource_type - description: "single resource in array" resources: - _type: class title: "foo::bar" param1: foo noop: true - description: "single resource in array" resources: - type: class title: "foo::bar" param1: foo noop: true - resources: - package: nginx - package: ssh - file: /tmp/foo parameters: content: "hello world" - description: "single resource in array" resources: - type: class title: "foo::bar" parameters: param1: foo noop: true # Using refs may be confusing when people move to puppet code # Using refs forces users to understand some weird capitalization rules - description: "Use ref's as the key" Package['nginx']: File['/var/...']: content: $foo - description: "Use ref's as the key" - ref: Package['nginx'] - ref: File['/var/...'] content: $foo # No ordering is unacceptable - description: "single resource in hash by name" resources: foo::bar: _type: class param1: foo before: "File['/etc/fop']" noop: true # No ordering is unacceptable - description: "single resource in nested hash" resources: class: foo::bar: param1: class noop: true {noformat}
We should be able to handle simple apply actions in simple plans. * `apply_prep` should be implicitly called on targets at least once in the plan. * It should support a data format of resource declaration.
QuestionsObservations: should we use* must be an array or hash? so we can have manifest ordering * having type and title together on one line is preferable {noformat} --- steps: # + This allows us to maintain manifest ordering which may Can there be useful a parameter called "type" .
# - need to come up with safe keyword for resource_type -
description: "single resource in array" resources: - _type type: class
title: "foo::bar" param1: foo noop: true
- description: "single resource in array"
# Allows resources: to be easily scannable. - # Similar to step syntax where the step type: class or resource type is stored by the presence of a key. title: # Won't with with "foo::barparameters" type if one exists.
Lucy Wyman (JIRA)
unread,
Jun 11, 2019, 12:13:05 PM6/11/19
Reply to author
Sign in to reply to author
Forward
Sign in to forward
Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
We should be able to handle simple apply actions in simple plans. * `apply_prep` should be implicitly called on targets at least once in the plan. * It should support a data format of resource declaration.
Observations: * must be an array so we can have manifest ordering
* having type and title together on one line is preferable
* Test that a type called type works {noformat} --- steps: # Can there be a parameter called "type" .
- description: "single resource in array" resources: - type: class title: "foo::bar"
param1: foo noop: true # Allows resources to be easily scannable. # Similar to step syntax where the step type or resource type is stored by the presence of a key. # Won't work with with "parameters" type if one exists.
We should be able to handle simple apply actions in simple plans. * ` {{apply_prep`}}
should be implicitly called on targets at least once in the plan.
* It should support a data format of resource declaration.
Observations: * must be an array so we can have manifest ordering * having type and title together on one line is preferable * Test that a type called type works
{noformat} --- steps:
# Allows resources to be easily scannable. # Similar to step syntax where the step type or resource type is stored by the presence of a key.
# Won't work with "parameters" type if one exists.