[RFC] conf: introduce lxc.rootfs.managed #2435
Conversation
|
|
|
Yeah, might be a good idea. |
brauner
force-pushed
the
2018-06-27/storage_managed
branch
2 times, most recently
from
6ba9434
to
d5bb5d1
Compare
|
@stgraber, updated. |
| @@ -2645,6 +2645,7 @@ struct lxc_conf *lxc_conf_init(void) | |||
| free(new); | |||
| return NULL; | |||
| } | |||
| new->rootfs.managed = true; | |||
There was a problem hiding this comment.
Shouldn't lxc_conf_init() set this to the same as the clear method?
There was a problem hiding this comment.
The other way around actually. The default should be that it's managed. So clear should set to true most likely.
There was a problem hiding this comment.
Unless that is to confusing?
There was a problem hiding this comment.
Whichever is less of a change to the previous behavior I guess?
There was a problem hiding this comment.
lxc.rootfs.managed is supposed to mean "the rootfs is managed by this lxc instance" so the default should be true.
There was a problem hiding this comment.
Would calling it lxc.rootfs.external and reversing the logic make it less confusing maybe?
There was a problem hiding this comment.
Yeah, but I like the managed part and external is harder to grasp. Usually the lxc.rootfs.managed config key will not be set anyway. It will only be set when set to false.
brauner
changed the title
brauner
force-pushed
the
2018-06-27/storage_managed
branch
from
d5bb5d1
to
97dc156
Compare
brauner
force-pushed
the
2018-06-27/storage_managed
branch
from
97dc156
to
4dd4131
Compare
|
Updated. |
This introduces a new config key lxc.rootfs.managed which can be used to indicate whether this LXC instance is managing the container storage. If LXC is not managing the storage then LXC will not modify the container storage. For example, an API call to c->destroy(c) will then run any destroy hooks but will not destroy the actual rootfs (Unless, of course, the hook does so behind LXC's back.). Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> CC: Wolfgang Bumiller <w.bumiller@proxmox.com> CC: Stéphane Graber <stgraber@ubuntu.com> CC: Serge Hallyn <serge@hallyn.com> CC: 2xsec <dh48.jeong@samsung.com>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
brauner
force-pushed
the
2018-06-27/storage_managed
branch
from
4dd4131
to
6e0045b
Compare
|
LGTM, the only question I have is what to do about (other) files in |
|
Yeah, my current idea is to basically treat the directory as a no-go area for destroy when |
This introduces a new config key lxc.rootfs.managed which can be used to
indicate whether this LXC instance is managing the container storage. If LXC is
not managing the storage then LXC will not modify the container storage.
For example, an API call to c->destroy(c) will then run any destroy hooks but
will not destroy the actual rootfs (Unless, of course, the hook does so behind
LXC's back.).
Signed-off-by: Christian Brauner christian.brauner@ubuntu.com
CC: Wolfgang Bumiller w.bumiller@proxmox.com
CC: Stéphane Graber stgraber@ubuntu.com
CC: Serge Hallyn serge@hallyn.com
CC: 2xsec dh48.jeong@samsung.com