RFC: podman generate systemd --custom-header

[vrothberg]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind feature

Description

It seems to be common among automation tools (e.g., Ansible) to inject custom headers into files under their control. It would hence be a useful addition for podman generate systemd to allow for specifying a custom header (e.g., a string slice such as --custom-header "line 1" --custom-header "line 2").

I think that --no-header should not impact --custom-header which will append to the standard header, see examples below:

$ podman generate systemd $CTR
# container-d2356db4841d554f87f82110b1bfad87a4cfa92064df8128514baa0bcf9b8e7f.service
# autogenerated by Podman 4.0.3
# Mon May  2 14:48:02 CEST 2022
[...]

$ podman generate systemd $CTR --custom-header "fooo" --custom-header "baaaar"
# container-d2356db4841d554f87f82110b1bfad87a4cfa92064df8128514baa0bcf9b8e7f.service
# autogenerated by Podman 4.0.3
# Mon May  2 14:48:02 CEST 2022
# fooo
# baaaar
[...]

$ podman generate systemd $CTR --custom-header "fooo" --custom-header "baaaar" --no-header
# fooo
# baaaar
[...]

@richm @containers/podman-maintainers WDYT?

[Luap99]

What benefit does this offer to ansible?

If this only adds lines to the beginning the caller could add them easily too. I do not see why podman has to do this.

[vrothberg]

What benefit does this offer to ansible?

It makes generating and managing the units slightly easier.

If this only adds lines to the beginning the caller could add them easily too.

That's what Ansible will be doing for now.

I do not see why podman has to do this.

I consider it part of improving the user experience.

[Luap99]

I am missing the context here. What headers are we talking about?

The --no-header option was a request from ansible users too since it was not possible to compare if a unit changed since there is always a different timestamp in it. I understand that this is also useful for other user who are not interested in this information.

However I do not really see how adding comments improve the user experience. I do not expect any users beside this specific ansible script and implementing on the ansible side should be easy.

I just think at some point we have to draw the line with what podman generate systemd should do. If we allow adding comments what is the next request? Overwriting Exec lines? Adding other unit attributes? Do we want to go in that direction? For me personally podman generate systemd is a best effort generation and customization should be done by users.

[vrothberg]

I am missing the context here. What headers are we talking about?

The commented lines at the top of the unit. See the examples above.

The --no-header option was a request from ansible users too since it was not possible to compare if a unit changed since there is always a different timestamp in it. I understand that this is also useful for other user who are not interested in this information.

Comparing such files is usually not done via diff but by computing semantic hashes. The reasoning for that is to keep such headers.

However I do not really see how adding comments improve the user experience. I do not expect any users beside this specific ansible script and implementing on the ansible side should be easy.

Nobody said it's hard to prepend text. It's avoiding an extra step and it seems like a fairly common feature among automation tools.

I just think at some point we have to draw the line with what podman generate systemd should do. If we allow adding comments what is the next request? Overwriting Exec lines? Adding other unit attributes? Do we want to go in that direction?

Sarcasm will certainly not help decide which features to add or not. Supporting custom headers has absolutely no functional impact, so I do not think the projections to custom exec lines etc. hold.

I refrain from predicting a direction since most features are request driven. But I would be surprised if the units would look drastically different 5 years from now.

[Luap99]

I am missing the context here. What headers are we talking about?

The commented lines at the top of the unit. See the examples above.

I mean actual examples of headers ansible is adding. I want to understand what they are doing?

I just think at some point we have to draw the line with what podman generate systemd should do. If we allow adding comments what is the next request? Overwriting Exec lines? Adding other unit attributes? Do we want to go in that direction?

Sarcasm will certainly not help decide which features to add or not. Supporting custom headers has absolutely no functional impact, so I do not think the projections to custom exec lines etc. hold.

This is not sarcasim. I want to clarify what path we want to take. Because if we want to allow more customisation with generate systemd I do not think adding more cli options such as --comment is good. I think it could make more sense to directly expose the internal go template so users could change this instead.

[vrothberg]

I mean actual examples of headers ansible is adding. I want to understand what they are doing?

I forgot the exact string but something similar to: "This file is managed by Ansible". This way, it is easy to figure out which files are managed by Anisble by, for instance, grepping through /etc.

I want to clarify what path we want to take. Because if we want to allow more customisation with generate systemd I do not think adding more cli options such as --comment is good. I think it could make more sense to directly expose the internal go template so users could change this instead.

As mentioned above. I cannot predict future requests. Exposing the entire template based on this simple requests seems overkill to me.

[Luap99]

The problem with a simple --comment is that it is very limited. Where should the comment be added? Before the podman commend or after? Your issue says after which is fine but what if we get a second request where a users says they need it before?

I know that adding this is simple. I am just afraid that we end up with more and more cli options which make the user interface worse IMO.

[vrothberg]

The problem with a simple --comment is that it is very limited. Where should the comment be added? Before the podman commend or after? Your issue says after which is fine but what if we get a second request where a users says they need it before?

Note that I am asking for --custom-header not --comment. I personally don't care if it's before or after the standard header and Ansible will not care either. It's just important to allow for --no-header --custom-header="fooo" to work.

I know that adding this is simple. I am just afraid that we end up with more and more cli options which make the user interface worse IMO.

I appreciate the feedback and I think it's worth keeping the CLI options manageable. I am not worried about generate systemd though. But I'd feel strongly against customizing the Exec* fields and such as it'd be a nightmare to support.

[Luap99]

Note that I am asking for --custom-header not --comment. I personally don't care if it's before or after the standard header and Ansible will not care either. It's just important to allow for --no-header --custom-header="fooo" to work.

Yes sorry I meant --custom-header. I also do not care where it is just saying one day someone might.

But I'd feel strongly against customizing the Exec* fields and such as it'd be a nightmare to support.

I agree.

[richm]

This is the use case - Ansible users provide a custom value for ansible_managed which is then inserted, commented, into each file managed by Ansible. https://docs.ansible.com/ansible/2.9/user_guide/playbooks_filters.html#comment-filter

e.g. podman generate systemd --custom-header "{{ ansible_managed | comment }}"

if the value of ansible_managed is something like

DO NOT EDIT THIS FILE
This file managed with Ansible
Your changes will be removed
For questions, please contact IT it@example.com

which should be written to the systemd unit file like this:

# DO NOT EDIT THIS FILE
# This file managed with Ansible
# Your changes will be removed
# For questions, please contact IT it@example.com
[Unit]
...

[rhatdan]

I am fine with this change, although I would prefer just using --header. Not a big fan of options with "-" embedded in them. Also shorter options better then longer options.

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

This would seem to be an easy issue to deal with. Anyone have the time to look at it?

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.

[vrothberg]

With Quadlet being around the corner, I don't think the feature is needed anymore. Yet we can kick https://github.com/containers/podman/pull/15291 over the finish line.