描述
Largely copied from my comment in #1425. Sorry if this is duplicate, I looked but couldn't see any issues that this should go into.
I was talking to @joshix about this recently, and was curious about the contract between the stage1 and the rkt CLI invocation being used.
Currently rkt run allows you to specify port forwards, different networks, multiple apps etc. However, not all of these configurations may apply to varying stage1's, such as the new fly stage1. It could be surprising to realize that if you change the underlying stage1 your existing rkt run command no longer works due to unimplemented functionality.
Just one example recently: https://github.com/coreos/rkt/issues/2064
And this comment from @jonboulle https://github.com/coreos/rkt/pull/1833#discussion_r48075247 also made me think this should get discussed some more.
I was looking around, and I was glad to see that rkt fly is still being planned to be added as it's own sub command, which then configures the command for the fly-stage1.aci. This means that command can have it's own set of flags and app handling which make sense for the fly stage1, which I think is a solid choice. However, I'm curious if there should be some way to actually define what a stage1 can do in the image in the future.
I was looking at https://github.com/coreos/rkt/pull/2035/files#diff-c2e93b5d997618cfe14f6ea88f78f0d3R367 and maybe part of the configuration of a stage1 defines the features it can provide, and eventually you can validate that at the CLI level, and commands could reject flags that your stage1 can't provide. For example, the fly1 stage1 configuration could include volumes as a feature it supports, but it wouldn't include the ability to run pods.
Another option is each stage1 gets it's own subcommand similar to rkt fly, and then providing a stage1 to rkt run could be deprecated/removed/considered experimental.