-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No header info for systemd generation #9445
No header info for systemd generation #9445
Conversation
f68f46f
to
f7a60a2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for tackling it!
Just a couple of nits. Could you also add two tests to test/e2e/generate_systemd_test.go
that uses both --no-header=true
and --no-header=false
?
pkg/systemd/generate/common.go
Outdated
@@ -30,18 +30,23 @@ func validateRestartPolicy(restart string) error { | |||
return errors.Errorf("%s is not a valid restart policy", restart) | |||
} | |||
|
|||
const headerTemplate = `# {{{{.ServiceName}}}}.service | |||
# autogenerated by Podman {{{{.PodmanVersion}}}} | |||
const serviceTemplate = `# {{{{.ServiceName}}}}.service |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer to use a conditional, which is more template idiomatic:
const headerTemplate = `# {{{{.ServiceName}}}}.service
{{{- if.GenerateHeader}}}
# autogenerated by Podman {{{{.PodmanVersion}}}}
{{{{- if .TimeStamp}}}}
# {{{{.TimeStamp}}}}
{{{{- end}}}}
{{{{- end}}}}
[Unit]
Description=Podman {{{{.ServiceName}}}}.service
Documentation=man:podman-generate-systemd(1)
Wants=network.target
After=network-online.target
`
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm nice one, will see how it works
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works nicely, I admit didn't know about this (fairly new to go). However, I changed logic to GenerateNoHeader. Firstly, because the flag is called --no-header, and secondly because the default value will be false. Then, there is no need to add it to every structure and set explicitly true, as well as to tests. Hope it's ok for you.
@vrothberg --no-header currently similar to --new flag. It does not take =value. You just want to check what will happen or implement is as =value? If first, what results do you expect? Error? |
Both take arguments such as |
65eac05
to
9d5d20d
Compare
@@ -31,10 +31,12 @@ func validateRestartPolicy(restart string) error { | |||
} | |||
|
|||
const headerTemplate = `# {{{{.ServiceName}}}}.service |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about making this part of containers.conf and allowing users to edit it? Then we would not need to add all of the plumbing for a new option and users could just modify the default template however they wanted?
@vrothberg Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say it would be another feature - making this code useless.
It is architecture decision and you have to discuss this before I move further.
So @rhatdan , @vrothberg please let me know.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think supporting this kind of use case would be even more difficult. This would no longer allow us to do breaking changes to the template such as #9035.
I think adding a simple cli option is simple and intuitive for users.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about making this part of containers.conf and allowing users to edit it? Then we would not need to add all of the plumbing for a new option and users could just modify the default template however they wanted?
I think we always need a CLI counterpart for containers.conf options such that users can override defaults. I have not strong feeling whether it's a good candidate for containers.conf.
But, I think it's something orthogonal to this change and we can add that a later point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jmguzik feel free to continue working on it. It would not change the architecture or logic of this PR. If we want a counterpart in the containers.conf, we can add it separately.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vrothberg Ok, thanks for the clarification!
e0bb17d
to
4595512
Compare
Generally, this feature is ready but remote test cases are failing. I suspect that something (probably one, two lines) is missing to enable the remote. I can't find it though - not super familiar with the codebase. Could I ask for a little help to spot the place @Luap99 @vrothberg ? |
For remote you have to add the option here: podman/pkg/bindings/generate/types.go Line 12 in 4a6582b
make generate-bindings afterwards. Lastly, you have to add: WithNoHeaders here
|
In addition to what @Luap99 mentioned, there's a bit more to do. The Swagger documentation, the request routing and the handling of remote requests is all handled in
It's mostly plumbing work to wire in the new parameter. The Podman backend is largely structured into two implementations of the same interfaces. One for the native local Linux one ( @Luap99's comments cover the remote-client side. Mine above cover the server part. |
@vrothberg @Luap99 without help, it would take me some time to find this. Many thanks for the insights. From my perspective feature is ready to be reviewed. |
LGTM. Can you squash the four commits into one? |
Thanks for tackling it! If you're interested in contributing more, feel free to have a look at the open issue or reach out to us directly. There is always work :) |
Signed-off-by: Jakub Guzik <[email protected]>
f1e5f0f
to
d2f3098
Compare
Squashed :)
Sure :) My idea is to learn Go (my background is many years mainly C/C++). This is a good way. I will take a look in my free time, but I have still one PR open in buildah. I will try to finish this one first. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jmguzik, Luap99 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/lgtm |
/hold cancel |
No header info for systemd generation: --no-header parameter
Fixes #8880
Closes #8880