Closed m-kat closed 1 year ago
Hmm, I have doubts on this change to be honest. With the interactive
flag we would require the user to specify if the registered application runs interactive or not. This would be a major drawback because there are app registrations which can be interactive or not depending on its caller arguments.
While reading your code changes I realized that we could apply the same mechanism you used in the pilot instead of the sci launcher. Launching firecracker as a background process and waiting for the child to finish also keeps the console of the running program blocked and finishes when there is no data to read rather than when the program exits. Therefore I implemented this concept in the firecracker-pilot
implementation, see #94 for details and tested it.
For me this worked fine. For testing I used the command: rpm -qa --changes
in the provided leap image. Would be great if you can give the following a test:
flake-ctl firecracker pull --name leap --kis-image https://download.opensuse.org/repositories/home:/marcus.schaefer:/delta_containers/images/firecracker-basesystem.x86_64.tar.xz
flake-ctl firecracker register --vm leap --app /usr/bin/myrpm --target /bin/rpm --overlay-size 20g
flake-ctl firecracker register --vm leap --app /usr/bin/mybash --target /bin/bash --overlay-size 20g
myrpm -qa --changes
mybash
$ rpm -qa --changes
$ exit
If you compare the two outputs there should be no difference
If you agree that the solution in the pilot is acceptable I believe we can close this one without merging
Thoughts ?
Thanks much for the pointers, it opened some gismos in my brain :)
Added interactive boot argument, when set to false(default value) sci will grab the whole output of the command and wait until all data from the console will be read to provide to the user. The interactive option shall be set to true for all applications where we don't want to grab the output such as bash or python interpreter etc. This solves #82