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

do not commit default volumes from container #699

Closed
wants to merge 1 commit into from

Conversation

baude
Copy link
Member

@baude baude commented Apr 30, 2018

when performing a container commit, we should not add the default list of volumes
for a container to the resulting image. it will cause the resulting image to crash
when run subsequently.

Signed-off-by: baude [email protected]

@@ -24,6 +25,8 @@ type ContainerCommitOptions struct {
Changes []string
}

var DefaultVolumeGroups = []string{"cgroup", "devpts", "mqueue", "proc", "shm", "sysfs", "tmpfs"}
Copy link
Member

Choose a reason for hiding this comment

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

This seems rather flimsy, and likely to break as new Default Volumes get added. Any way we can generate this list form the spec or from libcontainer?

Copy link
Member

Choose a reason for hiding this comment

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

@rhatdan We should be able to get the originals if we add them in cmd/podman because we do store the original create CLI

@baude baude force-pushed the dontcommitdefvolumes branch from 0cb7273 to c4bb0c7 Compare April 30, 2018 13:44
@@ -5,6 +5,7 @@ import (
"io"
"os"
"strings"
"encoding/json"
Copy link
Member

Choose a reason for hiding this comment

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

Gofmt is going to complain here

@mheon
Copy link
Member

mheon commented Apr 30, 2018

LGTM

@baude baude force-pushed the dontcommitdefvolumes branch 2 times, most recently from 119ab8e to f586b80 Compare April 30, 2018 15:01
Copy link
Member

@TomSweeneyRedHat TomSweeneyRedHat left a comment

Choose a reason for hiding this comment

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

One small suggestion for consideration.

artifact, err := ctr.GetArtifact("create-config")
if err == nil {
if err := json.Unmarshal(artifact, &createArtifact); err != nil {
return nil
Copy link
Member

Choose a reason for hiding this comment

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

any value to adding a log.debug to display more info on error?

Copy link
Member

Choose a reason for hiding this comment

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

Probably a good idea to drop a warning here, yeah

Copy link
Member Author

Choose a reason for hiding this comment

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

actually this is a hard failure ... adding return err

@baude baude force-pushed the dontcommitdefvolumes branch from f586b80 to 0258f64 Compare April 30, 2018 15:26
@@ -120,7 +121,17 @@ func commitCmd(c *cli.Context) error {
Changes: c.StringSlice("change"),
Author: c.String("author"),
}
newImage, err := ctr.Commit(getContext(), reference, options)
var createArtifact createConfig
artifact, err := ctr.GetArtifact("create-config")
Copy link
Member

Choose a reason for hiding this comment

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

If error is not nil on this, maybe a logrus.Info saying we can't retrieve information on volumes, command, entrypoint?

Copy link
Member Author

Choose a reason for hiding this comment

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

i prefer the hard fail... the user expects this to work, continuing without doing it should be a hard fail.

Copy link
Member

Choose a reason for hiding this comment

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

Right now, we only unmarshal the artifact if it exists - if err is not nil on this line, we do nothing. This could happen with CRI-O containers, where we don't have enough info saved right now to reliably commit.

Maybe we should start storing all of this in the DB after all... I have a PR open to add some related things to the DB already, maybe it should be extended to also add the full volumes, entrypoint, command from when the container was created, so we can reliably handle things like CRI-O containers?

@@ -74,11 +74,11 @@ func (c *Container) Commit(ctx context.Context, destImage string, options Contai
// add it to the resulting image.

// Entrypoint - always set this first or cmd will get wiped out
importBuilder.SetEntrypoint(c.Spec().Process.Args)
importBuilder.SetEntrypoint(entryPoint)
Copy link
Member

Choose a reason for hiding this comment

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

Should we check if entrypoint and command are not "" before we set them? We do for mounts, so it seems like it would make sense

Copy link
Member Author

Choose a reason for hiding this comment

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

i only do that because of the strings split.

Copy link
Member

Choose a reason for hiding this comment

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

Probably safest to ignore them if they're "", I think they might be in some cases where the user didn't set one or the other

Copy link
Member Author

Choose a reason for hiding this comment

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

fixed

when performing a container commit, we should not add the default list of volumes
for a container to the resulting image.  it will cause the resulting image to crash
when run subsequently.

Signed-off-by: baude <[email protected]>
@baude baude force-pushed the dontcommitdefvolumes branch from 0258f64 to f845757 Compare April 30, 2018 17:30
@baude
Copy link
Member Author

baude commented Apr 30, 2018

bot, retest this please

@rhatdan
Copy link
Member

rhatdan commented Apr 30, 2018

LGTM

@rhatdan
Copy link
Member

rhatdan commented Apr 30, 2018

@mheon @umohnani8 PTAL

@mheon
Copy link
Member

mheon commented Apr 30, 2018

LGTM. I have ideas for improving this, but they can come later.
@rh-atomic-bot r+

@rh-atomic-bot
Copy link
Collaborator

📌 Commit f845757 has been approved by mheon

@umohnani8
Copy link
Member

LGTM

@rhatdan
Copy link
Member

rhatdan commented Apr 30, 2018

@rh-atomic-bot retry

@mheon
Copy link
Member

mheon commented Apr 30, 2018

@rhatdan It's testing #691 now I think

@rh-atomic-bot
Copy link
Collaborator

⌛ Testing commit f845757 with merge 9924956...

@rh-atomic-bot
Copy link
Collaborator

☀️ Test successful - status-papr
Approved by: mheon
Pushing 9924956 to master...

@baude baude deleted the dontcommitdefvolumes branch December 22, 2019 18:49
@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 26, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 26, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
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.

6 participants