Skip to content
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

Conversation

jmguzik
Copy link
Contributor

@jmguzik jmguzik commented Feb 19, 2021

No header info for systemd generation: --no-header parameter
Fixes #8880
Closes #8880

@openshift-ci-robot openshift-ci-robot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Feb 19, 2021
@jmguzik jmguzik force-pushed the no-header-info-for-systemd-generation branch from f68f46f to f7a60a2 Compare February 19, 2021 23:35
Copy link
Member

@vrothberg vrothberg left a 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?

cmd/podman/generate/systemd.go Outdated Show resolved Hide resolved
docs/source/markdown/podman-generate-systemd.1.md Outdated Show resolved Hide resolved
@@ -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
Copy link
Member

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
`

Copy link
Contributor Author

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

Copy link
Contributor Author

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.

@jmguzik
Copy link
Contributor Author

jmguzik commented Feb 20, 2021

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?

@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?

@vrothberg
Copy link
Member

@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?

Both take arguments such as ./bin/podman generate systemd --no-header=false --new=false $CTR. Setting it false in the tests would just make sure that this value behaves as expected. I don't think we test that yet for --new=false though.

@jmguzik jmguzik force-pushed the no-header-info-for-systemd-generation branch 3 times, most recently from 65eac05 to 9d5d20d Compare February 21, 2021 00:24
@@ -31,10 +31,12 @@ func validateRestartPolicy(restart string) error {
}

const headerTemplate = `# {{{{.ServiceName}}}}.service
Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Member

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.

Copy link
Member

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.

Copy link
Contributor Author

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!

@jmguzik jmguzik force-pushed the no-header-info-for-systemd-generation branch 3 times, most recently from e0bb17d to 4595512 Compare February 21, 2021 13:39
@jmguzik
Copy link
Contributor Author

jmguzik commented Feb 22, 2021

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 ?

@Luap99
Copy link
Member

Luap99 commented Feb 22, 2021

For remote you have to add the option here:

type SystemdOptions struct {
and run make generate-bindings afterwards. Lastly, you have to add: WithNoHeaders here
options.WithPodPrefix(opts.PodPrefix).WithRestartPolicy(opts.RestartPolicy).WithSeparator(opts.Separator)

@vrothberg
Copy link
Member

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 pkg/api/*. So to make remote work, we also need to;

  • Add the new noHeader remote parameter to the docs in pkg/api/server/register_generate.go.
  • Supported the new parameter in the handler in pkg/api/handlers/libpod/generate.go.

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 (pkg/domain/infra/abi) and another one for the remote clients (pkg/domain/infra/tunnel). The remote code is itself using the go-bindings we maintain directly in this repository in pkg/bindings.

@Luap99's comments cover the remote-client side. Mine above cover the server part.

@jmguzik
Copy link
Contributor Author

jmguzik commented Feb 22, 2021

@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.

@jmguzik jmguzik changed the title [WIP] No header info for systemd generation No header info for systemd generation Feb 22, 2021
@jmguzik jmguzik marked this pull request as ready for review February 22, 2021 12:32
@openshift-ci-robot openshift-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Feb 22, 2021
@vrothberg
Copy link
Member

@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?

@vrothberg
Copy link
Member

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 :)

@jmguzik jmguzik force-pushed the no-header-info-for-systemd-generation branch from f1e5f0f to d2f3098 Compare February 22, 2021 13:49
@jmguzik
Copy link
Contributor Author

jmguzik commented Feb 22, 2021

LGTM. Can you squash the four commits into one?

Squashed :)

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 :)

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.

Copy link
Member

@Luap99 Luap99 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@openshift-ci-robot
Copy link
Collaborator

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Feb 22, 2021
@Luap99
Copy link
Member

Luap99 commented Feb 22, 2021

/lgtm
/hold

@openshift-ci-robot openshift-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Feb 22, 2021
@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Feb 22, 2021
@Luap99
Copy link
Member

Luap99 commented Feb 22, 2021

/hold cancel

@openshift-ci-robot openshift-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Feb 22, 2021
@openshift-merge-robot openshift-merge-robot merged commit a6e7d19 into containers:master Feb 22, 2021
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 23, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add the --generate-timestamp option to podman generate systemd
6 participants