You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Before the hypervisor and visor binaries were merged it was possible to explicitly start either a visor or hypervisor instance.
When this change happened, the systemd service for the hypervisor was removed from skybian.
In the AUR and debian packages of skywire which I maintain, I sought to preserve the two modes of operation by having systemd services which referenced a configuration file which was defined as either a visor or hypervisor configuration.
Now it seems there is some objection by @jdknives to supporting config generation which by default creates a file with a name which is differentiated based on the presence of a hypervisor configuration or remote hypervisors being set.
Another solution I have posited is to have a hypervisor instance started by a flag provided to skywire-visor. this would rmove the configuration for a local hypervisor out of the config file and basically generate this configuration with that flag 'on the fly' and run the local hypervisor UI instance when the visor is started.
Is your feature request related to a problem? Please describe.
this is a request to return a removed feature, in one sense.
Describe the solution you'd like
I have already completed the multi-config approach with corresponding systemd services and it is currently used in the packages. I would ask for reconsideration from @jdknives on this, and I would take another different flag if the -p flag needs to serve other purposes.
Describe alternatives you've considered
a flag for skywire-visor to explicitly start the hypervisor UI with the visor
The text was updated successfully, but these errors were encountered:
jdknives
changed the title
on-demand modes of operation - multiconfig support OR start hypervisor with flag
Start hypervisor with default values via flag
Nov 15, 2021
@0pcom we can have a flag to generate and use default values for the hypervisor for sure. We need to keep the current way of running and configuring the hypervisor via config file but having another flag does not hurt. I dont personally mind re-running the skywire-cli config gen again to generate a default hypervisor config and append it to the existing config but if its desirable for you we can do that.
Before the hypervisor and visor binaries were merged it was possible to explicitly start either a visor or hypervisor instance.
When this change happened, the systemd service for the hypervisor was removed from skybian.
In the AUR and debian packages of skywire which I maintain, I sought to preserve the two modes of operation by having systemd services which referenced a configuration file which was defined as either a visor or hypervisor configuration.
Now it seems there is some objection by @jdknives to supporting config generation which by default creates a file with a name which is differentiated based on the presence of a hypervisor configuration or remote hypervisors being set.
Another solution I have posited is to have a hypervisor instance started by a flag provided to skywire-visor. this would rmove the configuration for a local hypervisor out of the config file and basically generate this configuration with that flag 'on the fly' and run the local hypervisor UI instance when the visor is started.
Is your feature request related to a problem? Please describe.
this is a request to return a removed feature, in one sense.
Describe the solution you'd like
I have already completed the multi-config approach with corresponding systemd services and it is currently used in the packages. I would ask for reconsideration from @jdknives on this, and I would take another different flag if the -p flag needs to serve other purposes.
Describe alternatives you've considered
a flag for skywire-visor to explicitly start the hypervisor UI with the visor
The text was updated successfully, but these errors were encountered: