New design for basefs. #1909
New design for basefs. #1909
Conversation
Signed-off-by: huaiyou <[email protected]>
Codecov ReportBase: 21.11% // Head: 21.70% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #1909 +/- ##
==========================================
+ Coverage 21.11% 21.70% +0.58%
==========================================
Files 74 78 +4
Lines 6762 7055 +293
==========================================
+ Hits 1428 1531 +103
- Misses 5148 5322 +174
- Partials 186 202 +16
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
Signed-off-by: huaiyou <[email protected]>
Signed-off-by: huaiyou <[email protected]>
| │ ├── runc | ||
| │ └── vpnkit | ||
| ├── etc | ||
| ├── etc # configs will be put into all nodes' sealer-rootfs |
There was a problem hiding this comment.
What does sealer-rootfs? Could you help to define that? Since there are quite a lot of rootfs in sealer's concept. @VinceCui
| @@ -4,7 +4,7 @@ cloud rootfs will package all the dependencies refers to the kubernetes cluster | |||
|
|
|||
| ```shell script | |||
| . | |||
| ├── bin | |||
| ├── bin # binaries will be installed at all nodes' /usr/local/bin | |||
There was a problem hiding this comment.
If we only store binaries in this directory, I am wondering whether it is proper to container scripts here, like containerd-rootless-setuptool.sh, containerd-rootless.sh and kubelet-pre-start.sh.
In addition, binary may not be compatible with plarforms(x86, arm). Then in the design, we make a ClusterImage to be compatible to all arch platforms or different ClusterImage compatible to different platforms.
It could be better that we have a top-down through design, I think. 🐱
There was a problem hiding this comment.
Agree with that. It's weird to have a bunch of shell scripts in a directory called bin
| ├── plugins # plugins can run on some hooks, such as pre-init-host, post-install, see more in the plugins documentation | ||
| │ └── disk_init_shell_plugin.yaml | ||
| ├── scripts # scripts can use all ClusterFile's env as Linux env variables | ||
| │ ├── init-kube.sh # initialize kube* binaries on target hosts |
There was a problem hiding this comment.
Could you please add more information to the scripts, including input, output, and functions should be included?
It can be described in a separate section.
| @@ -13,44 +13,28 @@ cloud rootfs will package all the dependencies refers to the kubernetes cluster | |||
| │ ├── kubectl | |||
| │ ├── kubelet | |||
| │ ├── nerdctl | |||
| │ ├── kubelet-pre-start.sh | |||
| │ ├── helm | |||
There was a problem hiding this comment.
What if a dual-architecture cluster image, such as support for both amd64 and arm64?
I think we should have a relatively complete example.
| @@ -4,7 +4,7 @@ cloud rootfs will package all the dependencies refers to the kubernetes cluster | |||
|
|
|||
| ```shell script | |||
| . | |||
| ├── bin | |||
| ├── bin # binaries will be installed at all nodes' /usr/local/bin | |||
There was a problem hiding this comment.
In my opinion, the binaries should be installed at the system PATH of all nodes, and the specific path should be compatible with the operating system which is determined by the installation script.
Signed-off-by: huaiyou [email protected]
Describe what this PR does / why we need it
In order to facilitate the use of basic image creators, we need to standardize the definition of sealer's rootfs.
Does this pull request fix one issue?
Describe how you did it
I mainly made the following designs:
Describe how to verify it
Special notes for reviews
为了方便基础镜像制作者的使用，我们需要标准化sealer的rootfs的定义。
我主要做了以下设计：