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

[CI:DOCS] Spec proposal #5082

Merged
merged 2 commits into from
Feb 4, 2020
Merged

Conversation

baude
Copy link
Member

@baude baude commented Feb 4, 2020

warning: the naming of this might change as well as the location.

this is a build on a PR from mheon from last year that proposes a shift from our current approach of creating containers based on the arbitrarily made createconfig. the new approach would be to have a specification that is detached from the podman cli. the spec could then be generated and used to make a container. this theoretically is the beginning of a long-needed refactor involving how we get from the cli -> libpod | apiv2 -> libpod with code re-use and less duplication.

the intent is to build the apiv2 container creation based on this approach only. wiring to the podman cli will happen after the fact.

The current Libpod pkg/spec has become a victim of the better
part of three years of development that tied it extremely closely
to the current Podman CLI. Defaults are spread across multiple
places, there is no easy way to produce a CreateConfig that will
actually produce a valid container, and the logic for generating
configs has sprawled across at least three packages.

This is an initial pass at a package that generates OCI specs
that will supersede large parts of the current pkg/spec. The
CreateConfig will still exist, but will effectively turn into a
parsed CLI. This will be compiled down into the new SpecGenerator
struct, which will generate the OCI spec and Libpod create
options.

The preferred integration point for plugging into Podman's Go API
to create containers will be the new CreateConfig, as it's less
tied to Podman's command line. CRI-O, for example, will likely
tie in here.

Signed-off-by: Matthew Heon <[email protected]>
// ContainerHealthCheckConfig describes a container healthcheck with attributes
// like command, retries, interval, start period, and timeout.
type ContainerHealthCheckConfig struct {
manifest.Schema2HealthConfig `json:"healthcheck,omitempty"`
Copy link
Member

Choose a reason for hiding this comment

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

Do we want to give this a name? In case we add extra fields related to healthchecks at some point?

Copy link
Member Author

Choose a reason for hiding this comment

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

@mheon i couldnt think of a name that wasnt redundant. you?

Copy link
Member

Choose a reason for hiding this comment

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

...HealthConfig? Maybe?

@openshift-ci-robot
Copy link
Collaborator

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: baude

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 4, 2020
warning: the naming of this might change as well as the location.

this is a build on a PR from mheon from last year that proposes a shift from our current approach of creating containers based on the arbitrarily made createconfig.  the new approach would be to have a specification that is detached from the podman cli.  the spec could then be generated and used to make a container.  this theoretically is the beginning of a long-needed refactor involving how we get from the cli -> libpod | apiv2 -> libpod with code re-use and less duplication.

the intent is to build the apiv2 container creation based on this approach only.  wiring to the podman cli will happen after the fact.

Signed-off-by: Brent Baude <[email protected]>
@baude
Copy link
Member Author

baude commented Feb 4, 2020

updated

@mheon
Copy link
Member

mheon commented Feb 4, 2020

Current version LGTM, we can discuss further details as the implementation comes together

@rhatdan
Copy link
Member

rhatdan commented Feb 4, 2020

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Feb 4, 2020
@openshift-merge-robot openshift-merge-robot merged commit fac8318 into containers:master Feb 4, 2020
@baude baude deleted the spec branch May 18, 2022 15:22
@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 21, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 21, 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.

5 participants