wkozaczuk
commented
7 years ago All your code comments make sense so I will update accordingly.
However I have couple of concerns with your idea of combining with cloud-init.
Firstly the base image with combined cloud-init would implicitly contain httpserver-api and osv.bootstrap. This might not be desired in all cases (I am guessing that cloud-init would makes sense in most AWS deployments though) and kind od inconsistent with 'mike-loader' base image in terms what it represents and does.
Secondly and more importantly I think many would prefer AMIs to be immutable artifacts that can be used to instantiate corresponding EC2 instances with predefined bootcmd rather than rely on cloud-init passing right info. I would rather cloud-init be a mechanism to supply application configuration than set bootcmd. I might not be understanding how cloud init works with OSv.
Maybe my concerns are subjective and do not have much merit. I also realize that your approach does not require any OSv changes.
On Mon, Oct 23, 2017 at 2:48 AM, Miha Pleško notifications@github.com wrote:
@miha-plesko commented on this pull request.
@wkozaczuk https://github.com/wkozaczuk we are aware of the pain that one faces when uploading OSv unikernel to the AWS so we're thankful for your efforts towards resolving this. I really like your approach!
May I suggest that we combine your suggestion with the osv.cloud-init package for setting bootcmd? Basically we would require from user to prepare base image (the one that Capstan then connects to remotely) with osv.cloud-init package included and with bootcmd set to /bin/sleep.so -1. On the AWS user would then start it with following cloud-init data:
run:
- PUT: /app/ command: "/tools/cpiod.so --prefix /zfs/zfs; /zfs.so set compression=off osv"
The Capstan would then connect to this instance and upload the files, leaving the bootcommand intact i.e. /bin/sleep.so -1. When user then wants to actually run the new unikenrel, she would simply change the cloud-init file to match her needs:
run:
- PUT: /app/ command: {ARBITRARY-BOOTCMD}
What do you think @wkozaczuk https://github.com/wkozaczuk?
In capstan.go https://github.com/mikelangelo-project/capstan/pull/70#discussion_r146173849 :
@@ -423,6 +423,7 @@ func main() { cli.BoolFlag{Name: "pull-missing, p", Usage: "attempt to pull packages missing from a local repository"}, cli.StringFlag{Name: "boot", Usage: "specify default config_set name to boot unikernel with"}, cli.StringSliceFlag{Name: "env", Value: new(cli.StringSlice), Usage: "specify value of environment variable e.g. PORT=8000 (repeatable)"},
- cli.StringFlag{Name:"remote-guest-name",Usage:"specify hostname of remote guest"},
Perhaps using short name remote would do better? I think users will use IP more often than the hostname. Something like this:
$ capstan package compose --remote 189.16.0.5
In capstan.go https://github.com/mikelangelo-project/capstan/pull/70#discussion_r146173962 :
@@ -423,6 +423,7 @@ func main() { cli.BoolFlag{Name: "pull-missing, p", Usage: "attempt to pull packages missing from a local repository"}, cli.StringFlag{Name: "boot", Usage: "specify default config_set name to boot unikernel with"}, cli.StringSliceFlag{Name: "env", Value: new(cli.StringSlice), Usage: "specify value of environment variable e.g. PORT=8000 (repeatable)"},
- cli.StringFlag{Name:"remote-guest-name",Usage:"specify hostname of remote guest"}, }, Action: func(c *cli.Context) error { if len(c.Args()) != 1 {
This check shoul be updated so that when --remote is given, the argument image-name is no longer needed.
In cmd/compose.go https://github.com/mikelangelo-project/capstan/pull/70#discussion_r146174569 :
@@ -188,6 +188,57 @@ func UploadPackageContents(r *util.Repo, appImage string, uploadPaths map[string return newHashes, cmd.Wait() }
+func UploadPackageContentsToRemoteGuest(uploadPaths map[string]string, osvCmdline string, remoteGuestName string, verbose bool) error {
This function is more or less a copy-paste from the original UploadPackageContents function only it doesn't start the instance beforehead. May I suggest to extract common logic into a function, say:
func uploadFiles()
that both functions, UploadPackageContents and UploadPackageContentsToRemoteGuest, would use? The former would upload to localhost, the latter to the remote.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mikelangelo-project/capstan/pull/70#pullrequestreview-71077314, or mute the thread https://github.com/notifications/unsubscribe-auth/AFDSIZ0UP07_XCYypwEjuhhnRNOFVAtgks5svDbWgaJpZM4QCCGZ .
miha-plesko
This is more of a sketch of a proposal to demonstrate how this can be solved. I do not expect this to merged as is.
The motivation comes from the fact the creating AWS AMIs from OSv raw image is pretty time consuming task and is proportional to the size of the image. The idea is to have 'mike/osv-loader' EC2 instance running with cmdline '--norandom --nomount --noinit /tools/mkfs.so; /tools/cpiod.so --prefix /zfs/zfs; /zfs.so set compression=off osv' and use capstan with option --remote-guest-name to upload files that make up an image and set actual cmdline. To make it possible cpiod needs to slightly modified to allow setting cmdline.
I have tested this approach and it works and is faster than import raw image and EC2 snapshot/AMI.