ungleich-public/cdist
ungleich-public
/
cdist
7
3
Fork 10
Code Issues 57 Pull Requests 12 Projects Releases Wiki Activity

Only apply certain types? #185

New Issue
Closed
opened 2021-11-20 15:20:59 +00:00 by ungleich-gitea · 7 comments
ungleich-gitea commented 2021-11-20 15:20:59 +00:00
Owner
Copy Link

Created by: toupeira

If you only want to re-apply a specific type on all servers, you have the choice of either doing a full config run (which can take a long time), or using --initial-manifest - to supply a manifest on stdin (which might apply the type on servers that don't define it in the real manifest).

It would be nice if cdist config had something like a --filter TYPE argument which would read the normal manifest, but only apply the given type(s). Not sure how much effort it would be to implement this, especially because of dependencies. If you give me some pointers where to look I'll try poking around the code myself for a bit.

*Created by: toupeira* If you only want to re-apply a specific type on all servers, you have the choice of either doing a full config run (which can take a long time), or using `--initial-manifest -` to supply a manifest on stdin (which might apply the type on servers that don't define it in the real manifest). It would be nice if `cdist config` had something like a `--filter TYPE` argument which would read the normal manifest, but only apply the given type(s). Not sure how much effort it would be to implement this, especially because of dependencies. If you give me some pointers where to look I'll try poking around the code myself for a bit.
ungleich-gitea added the
Stale
 label 2021-11-20 15:20:59 +00:00
ungleich-gitea commented 2021-11-20 15:46:39 +00:00
Author
Owner
Copy Link

closed

closed
ungleich-gitea commented 2021-11-20 15:46:41 +00:00
Author
Owner
Copy Link

Created by: telmich

I think we will introduce a command line switch for selecting a type that wraps around the initial manifest:

cdist config --to-be-defined "__my_type --with-my-args"

The tagging approach is related, but not the same. With tagging, the dependent types, which are not matched by the selection, would not be executed (useful for install case).

*Created by: telmich* I think we will introduce a command line switch for selecting a type that wraps around the initial manifest: cdist config --to-be-defined "__my_type --with-my-args" The tagging approach is related, but not the same. With tagging, the dependent types, which are not matched by the selection, would not be executed (useful for install case).
ungleich-gitea commented 2021-11-20 15:46:42 +00:00
Author
Owner
Copy Link

Created by: asteven

I mainly need the tag based approach, but I see the use case for just running certain types.
One open/unsolved question is how to handle dependencies. What if a tagged (or selected based on type) object creates other objects? How are those treated? Should tags be inherited. Same questions/problems also apply to a possible --only-type implementation.

*Created by: asteven* I mainly need the tag based approach, but I see the use case for just running certain types. One open/unsolved question is how to handle dependencies. What if a tagged (or selected based on type) object creates other objects? How are those treated? Should tags be inherited. Same questions/problems also apply to a possible --only-type implementation.
ungleich-gitea commented 2021-11-20 15:46:44 +00:00
Author
Owner
Copy Link

Created by: toupeira

I guess it can be slightly misleading since any dependent types will necessarily also have to be run, but to me that's fine.

*Created by: toupeira* I guess it can be slightly misleading since any dependent types will necessarily also have to be run, but to me that's fine.
ungleich-gitea commented 2021-11-20 15:46:45 +00:00
Author
Owner
Copy Link

Created by: telmich

I also think --only-type xyz makes sense.

Markus Koller [Wed, Feb 25, 2015 at 01:42:42AM -0800]:

Interesting, though for it to be usable in the way I'm thinking of, I would
need to add --tag params to pretty much every type call. How about treating
the type name as an implicit default tag, or maybe even add an --only-type
argument?

Something related I've been thinking about is integration with cinv tags,
so I could basically define the "role" a server has through cinv, and then
have a dynamic manifest that will call the relevant types, using further
cinv tags to overwrite cdist params (e.g. SSL certificate names).
On 25 Feb 2015 09:20, "Steven Armstrong" notifications@github.com wrote:

Hi toupeira
I am are working on this. The idea is to give types a way to set tags, and
cdist a way to filter/include/exclude objects based on those tags.
Something like this:

In some manifest

only apply these if cdist is run with tag install

__partition_disk --if-tag install

always apply this

__always_configure

do not apply this when cdist is run with tag install

__do_not_configure_during_install --not-if-tag install

Then when running cdist

only apply objects tagged with install

cdist config --only-tag install localhost

apply untagged objects and those tagged with install

cdist config --include-tag install localhost

apply all objects except those tagged with install

cdist config --exclude-tag install localhost

—
Reply to this email directly or view it on GitHub
https://github.com/telmich/cdist/issues/379#issuecomment-75922037.

Reply to this email directly or view it on GitHub:
https://github.com/telmich/cdist/issues/379#issuecomment-75931866

New PGP key: 659B 0D91 E86E 7E24 FD15 69D0 C729 21A1 293F 2D24

*Created by: telmich* I also think --only-type xyz makes sense. Markus Koller [Wed, Feb 25, 2015 at 01:42:42AM -0800]: > Interesting, though for it to be usable in the way I'm thinking of, I would > need to add --tag params to pretty much every type call. How about treating > the type name as an implicit default tag, or maybe even add an --only-type > argument? > > Something related I've been thinking about is integration with cinv tags, > so I could basically define the "role" a server has through cinv, and then > have a dynamic manifest that will call the relevant types, using further > cinv tags to overwrite cdist params (e.g. SSL certificate names). > On 25 Feb 2015 09:20, "Steven Armstrong" notifications@github.com wrote: > > > Hi toupeira > > I am are working on this. The idea is to give types a way to set tags, and > > cdist a way to filter/include/exclude objects based on those tags. > > Something like this: > > > > In some manifest > > > > # only apply these if cdist is run with tag install > > > > __partition_disk --if-tag install > > > > # always apply this > > > > __always_configure > > > > # do not apply this when cdist is run with tag install > > > > __do_not_configure_during_install --not-if-tag install > > > > Then when running cdist > > > > # only apply objects tagged with install > > > > cdist config --only-tag install localhost > > > > # apply untagged objects and those tagged with install > > > > cdist config --include-tag install localhost > > > > # apply all objects except those tagged with install > > > > cdist config --exclude-tag install localhost > > > > — > > Reply to this email directly or view it on GitHub > > https://github.com/telmich/cdist/issues/379#issuecomment-75922037. > > --- > > Reply to this email directly or view it on GitHub: > https://github.com/telmich/cdist/issues/379#issuecomment-75931866 ## New PGP key: 659B 0D91 E86E 7E24 FD15 69D0 C729 21A1 293F 2D24
ungleich-gitea commented 2021-11-20 15:46:46 +00:00
Author
Owner
Copy Link

Created by: toupeira

Interesting, though for it to be usable in the way I'm thinking of, I would
need to add --tag params to pretty much every type call. How about treating
the type name as an implicit default tag, or maybe even add an --only-type
argument?

Something related I've been thinking about is integration with cinv tags,
so I could basically define the "role" a server has through cinv, and then
have a dynamic manifest that will call the relevant types, using further
cinv tags to overwrite cdist params (e.g. SSL certificate names).
On 25 Feb 2015 09:20, "Steven Armstrong" notifications@github.com wrote:

Hi toupeira
I am are working on this. The idea is to give types a way to set tags, and
cdist a way to filter/include/exclude objects based on those tags.
Something like this:

In some manifest

only apply these if cdist is run with tag install

__partition_disk --if-tag install

always apply this

__always_configure

do not apply this when cdist is run with tag install

__do_not_configure_during_install --not-if-tag install

Then when running cdist

only apply objects tagged with install

cdist config --only-tag install localhost

apply untagged objects and those tagged with install

cdist config --include-tag install localhost

apply all objects except those tagged with install

cdist config --exclude-tag install localhost

—
Reply to this email directly or view it on GitHub
https://github.com/telmich/cdist/issues/379#issuecomment-75922037.

*Created by: toupeira* Interesting, though for it to be usable in the way I'm thinking of, I would need to add --tag params to pretty much every type call. How about treating the type name as an implicit default tag, or maybe even add an --only-type argument? Something related I've been thinking about is integration with cinv tags, so I could basically define the "role" a server has through cinv, and then have a dynamic manifest that will call the relevant types, using further cinv tags to overwrite cdist params (e.g. SSL certificate names). On 25 Feb 2015 09:20, "Steven Armstrong" notifications@github.com wrote: > Hi toupeira > I am are working on this. The idea is to give types a way to set tags, and > cdist a way to filter/include/exclude objects based on those tags. > Something like this: > > In some manifest > > # only apply these if cdist is run with tag install > > __partition_disk --if-tag install > > # always apply this > > __always_configure > > # do not apply this when cdist is run with tag install > > __do_not_configure_during_install --not-if-tag install > > Then when running cdist > > # only apply objects tagged with install > > cdist config --only-tag install localhost > > # apply untagged objects and those tagged with install > > cdist config --include-tag install localhost > > # apply all objects except those tagged with install > > cdist config --exclude-tag install localhost > > — > Reply to this email directly or view it on GitHub > https://github.com/telmich/cdist/issues/379#issuecomment-75922037.
ungleich-gitea commented 2021-11-20 15:46:48 +00:00
Author
Owner
Copy Link

Created by: asteven

Hi toupeira
I am are working on this. The idea is to give types a way to set tags, and cdist a way to filter/include/exclude objects based on those tags. Something like this:

In some manifest

# only apply these if cdist is run with tag install
__partition_disk --if-tag install
# always apply this
__always_configure
# do not apply this when cdist is run with tag install
__do_not_configure_during_install --not-if-tag install

Then when running cdist

# only apply objects tagged with install
cdist config --only-tag install localhost
# apply untagged objects and those tagged with install
cdist config --include-tag install localhost
# apply all objects except those tagged with install
cdist config --exclude-tag install localhost
*Created by: asteven* Hi toupeira I am are working on this. The idea is to give types a way to set tags, and cdist a way to filter/include/exclude objects based on those tags. Something like this: In some manifest ``` # only apply these if cdist is run with tag install __partition_disk --if-tag install # always apply this __always_configure # do not apply this when cdist is run with tag install __do_not_configure_during_install --not-if-tag install ``` Then when running cdist ``` # only apply objects tagged with install cdist config --only-tag install localhost # apply untagged objects and those tagged with install cdist config --include-tag install localhost # apply all objects except those tagged with install cdist config --exclude-tag install localhost ```
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
master
7.0
6.9
py3.10
ander/__package_apt_update_index
haproxy-dualstack
ander/__sed
beta
ander/os_version_debian_sid
evilham-compatibility-fixes
ander/__rsync
__snakeoil_cert
ander/update_readme
__download_improvements
feature/onchange
cleanup/string-formatting
feature/type-relationship-graph
cleanup/ssh-auth-keys-types
__letsencrypt_cert-fix-hooks
bugfix/preos-debug
bugfix/in-script-import
6.8
bugfix/sphinx-docs-build
6.7
cherry-pick-2f433a14
bugfix/make-code-consistent
6.6
regain-py3.2-support
6.5
bugfix/multiple-log-lines
matterbridge
coturn
alpinefix
matrix
new-type/network-interface
feature/process
6.4
feature/info-command
feature/libexec
6.3
preos-plugins-dir-opt
gitlab-ci
6.2
order-dep-fix
6.1
6.0
build/support-pip-from-git
feature/shell-lib
5.1
feature/support-type-deprecation
5.0
feature/python-types
4.11
4.10
shellcheck
4.9
4.8
freebsd-improvements
new-prometheus
key_value-onchange
feature/output_streams
AnotherKamila-patch-1
__letsencrypt_cert-fixes
letsencrypt-cron-fix
4.7
newtype-__letsencrypt_cert
os_explorer_devuan_fix
prometheus-exporter-fixes
daemontools-for-fbsd
type-prometheus-exporter-from-master
prometheus-more-fixes
4.6
4.5
fix-j
steven-backport
4.4
prometheus-fixes
grafana_dashboard
prometheus
daemontools
consul_improvements
feature/trigger
4.3
4.0-pre-not-stable
4.2
4.1
4.0
feature_install_and_preos
3.1
no-dot-cdist
random_dot_cdist
feature_yum_url
feature_files_export
3.0
2.3
2.2
2.1
ssh_callback
2.0
archive_shell_function_approach
1.7
1.6
1.5
1.4
1.3
1.2
1.1
1.0
7.0.0
6.9.8
6.9.7
6.9.6
6.9.5
6.9.4
6.9.3
6.9.2
6.9.1
6.9.0
6.8.0
6.7.0
6.6.0
6.5.6
6.5.5
6.5.4
6.5.3
6.5.2
6.5.1
6.5.0
6.4.0
6.3.0
6.2.0
6.1.1
6.1.0
6.0.4
6.0.3
6.0.2
6.0.1
6.0.0
5.1.3
5.1.2
5.1.1
5.1.0
5.0.2
5.0.1
5.0.0
4.11.1
4.11.0
4.10.11
4.10.10
4.10.9
4.10.8
4.10.7
4.10.6
4.10.5
4.10.4
4.10.3
4.10.2
4.10.1
4.10.0
4.9.1
4.9.0
4.8.4
4.8.3
4.8.2
4.8.1
4.8.0
4.7.3
4.7.2
4.7.1
4.7.0
4.6.1
4.6.0
4.5.0
4.4.4
4.4.3
4.4.2
4.4.1
4.4.0
4.3.2
4.3.1
4.3.0
4.2.2
4.2.1
4.2.0
4.1.0
4.0.0
3.1.13
tn1
3.1.12
3.1.11
3.1.10
3.1.9
3.1.8
3.1.7
3.1.6
4.0.0pre3
3.1.5
3.1.4
3.1.3
3.1.2
3.1.1
3.1.0
4.0.0pre2
3.0.9
3.0.8
3.0.7
3.0.6
3.0.5
3.0.4
3.0.3
4.0.0pre1
3.0.2
3.0.1
3.0.0
2.3.7
2.3.6
2.3.5
2.3.4
2.3.3
2.3.2
2.3.1
2.3.0
2.2.0
2.1.2
2.1.1
2.1.0
2.1.0pre8
2.1.0pre7
2.1.0pre6
2.0.15
2.1.0pre5
2.1.0pre4
2.1.0pre3
2.1.0pre2
2.1.0pre1
2.0.14
2.0.13
2.0.12
2.0.11
2.0.10
2.0.9
2.0.8
2.0.7
2.0.6
2.0.5
2.0.4
2.0.3
2.0.2
2.0.1
2.0.0
1.7.1
1.7.0
1.6.2
1.6.1
1.6.0
1.5.0
1.4.1
1.4.0
1.3.2
1.3.1
1.3.0
1.2.0
1.1.0
1.0.4
1.0.3
1.0.2
1.0.1
1.0.0
0.9.9
0.9.8
0.9.7
0.9.6
0.9.5
0.9.4
0.9.3
0.9.2
0.9.1
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
Labels
Clear labels   
bugfix

   
cleanup

   
discussion

   
documentation

   
doing

   
done

   
feature

   
improvement

   
packaging

   
Stale

   
testing

   
TODO
No Label
bugfix
cleanup
discussion
documentation
doing
done
feature
improvement
packaging
Stale
testing
TODO
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
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#185
No description provided.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?