*: expose application-level operations #2932
Conversation
| so that it is ready to be started by the stage1 supervisor (e.g. systemd for the default flavor). | ||
|
|
||
| For example the operations would be as follows for the default rkt stage1 flavor: | ||
| - Prepare the application rootfs and its service files given an application image/images. |
There was a problem hiding this comment.
This step is done by different stages:
- stage0: Prepare the application rootfs: it can be: direct rendering or mount overlayfs over the treestore
- stage1: Prepare the application service files given an application image/images.
tmrts
force-pushed
the
stage1/app-level-operations
branch
from
729a22f
to
78b37bd
Compare
|
@tmrts I putted some observation in the first commit. They are valid also for the updated commits. Should I recopy them? Additionally:
|
|
@sgotti thank you for the prompt review, I'm updating the proposal according to those. You don't have to copy the comments, they are not lost. Keep the constructive comments coming 😄 |
| ``` | ||
|
|
||
| ## rkt app eject | ||
| Ejects an application image into a running pod, meaning that the traces of it are removed from the pod. |
There was a problem hiding this comment.
What are traces concretely?
There was a problem hiding this comment.
It can be better reworded as leftover resources in the context of garbage collection
There was a problem hiding this comment.
So traces are removed during eject, or leftover during eject and require a separate GC? I don't quite follow
There was a problem hiding this comment.
- the app rootfs (in
/opt/stage/appname) - some mounts from volumes for the apps (such as in
/opt/stage/appname/data) - some other mounts (such as in
/opt/stage/appname/dev/null) - the systemd
.servicefiles (appname.service,reaper-appname.service) - some misc files (
/rkt/myapp.env,/rkt/status...) - anything else?
Those can be removed synchronously when running rkt app eject. We should not need a GC for apps.
There was a problem hiding this comment.
I'll update the document accordingly
|
|
||
| `coreos.com/rkt/stage1/app/inject` | ||
|
|
||
| 1. prepare the application intended for injection, its rootfs and service files or else. |
There was a problem hiding this comment.
The structure of this document is confusing; this section is ostensibly about entrypoints but this behaviour here is clearly pre-entrypoint. Can you just combine them for now, e.g. have one "app inject" section that describes what the stage0 and stage1 each do
There was a problem hiding this comment.
I tried to separate the implementation and the subcommand API, I'll make the boundary more visible
jonboulle
changed the title
| ``` | ||
|
|
||
| ## rkt app stop | ||
| Stops a running application gracefully. |
There was a problem hiding this comment.
What does it mean to stop it gracefully?
There was a problem hiding this comment.
oh, I think I found it below (such confusion could be mitigated by https://github.com/coreos/rkt/pull/2932/files#r70785013)
There was a problem hiding this comment.
I'll add a note pointing to the explanation
|
Since this is a significant change in pod architecture and lifecycle, I'd like to see some language around what it means for an app to be in a pod (e.g. is an injected pod identical as apps that are already in the pod, in terms of environment etc? do we expect semantic differences between them? how does it affect shutdown lifecycle of a pod?) |
| ``` | ||
|
|
||
| ## rkt app exec | ||
| Executes a command inside an application. |
There was a problem hiding this comment.
What does inside an application mean? (Can probably steal language from rkt exec for this - since AIUI this should be semantically identical)
There was a problem hiding this comment.
I was going to correct it as application container, did you mean to say rkt enter?
|
@jonboulle the plan is to have injected apps that are identical to the normal apps inside a pod and it shouldn't affect the shutdown workflow (but we might need to reconsider terminating empty pods) |
|
I addressed every comment so far PTAL @sgotti @jonboulle @alban |
tmrts
force-pushed
the
stage1/app-level-operations
branch
3 times, most recently
from
25041b3
to
713e7f8
Compare
| `coreos.com/rkt/stage1/app/add` | ||
|
|
||
| 1. Receive the rootfs, the manifest and the volumes of the prepared app. | ||
| 2. `coreos.com/rkt/stage1/add` entrypoint is resolved via annotations found within `/var/lib/rkt/pods/run/$uuid/stage1/manifest`. |
There was a problem hiding this comment.
I won't pass the app manifest to a pod but I'll maintain the current implementation where only the pod manifest is used (since you don't need the full app manifest but just the app part and this one is copied from the app manifest to the pod manifest by the stage0 prepare).
Also if a draft I think this is an important point to define and, as suggested by @alban here I'll go for updating (atomically) the pod manifest adding/removing the apps.
(This will also make things like #3039 working without making this proposal appc only)
There was a problem hiding this comment.
I agree with @alban on his comment, I must've missed it when reworking the proposal, thanks!
tmrts
force-pushed
the
stage1/app-level-operations
branch
from
f212098
to
0dee9c0
Compare
tmrts
force-pushed
the
stage1/app-level-operations
branch
from
0dee9c0
to
a642c6c
Compare
|
I also think this is in a good shape for starting the implementation. Many additional questions and changes will probably emerge during the development (for example how to handle atomic state transitions, handle failed/killed app prepare/rm, concurrent operations on the same app etc...). |
| **Note:** Not every pod will be injectable and it will be enabled through an option. | ||
|
|
||
| ## rkt app rm | ||
| Removes an application image into a running pod, meaning that the leftover resources are removed from the pod. |
There was a problem hiding this comment.
Does it require the app to be stopped before (with rkt app stop)?
There was a problem hiding this comment.
|
Thanks! I agree with the discussion above, the other additional questions can be addressed during the implementation. LGTM |
This adds a new subcommand `app init` to create an initial empty pod. Follows rkt#2932
This adds a new subcommand `app init` to create an initial empty pod. Follows rkt#2932
This adds a new subcommand `app init` to create an initial empty pod. Follows rkt#2932
This adds a new subcommand `app init` to create an initial empty pod. Follows rkt#2932
This adds a new subcommand `app sandbox` to create an initial empty pod. Follows rkt#2932
This adds a new subcommand `app sandbox` to create an initial empty pod. Follows rkt#2932
This adds a new subcommand `app sandbox` to create an initial empty pod. Follows rkt#2932
This adds a new subcommand `app sandbox` to create an initial empty pod. Follows rkt#2932
To facilitate kubernetes#25899, new API extensions are proposed after taking the feedback in #2867 into account.
cc @euank @yifan-gu @philips @jonboulle @coreos/rkt-maintainers