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
The repository server is currently a very strange thing, is something that lives in the Lago environment but:
It isn't mentioned in the LagoInitFile
Its not started on lago start
Its not stopped on lago stop
It can be left behind even after lago destroy
lago ovirt serve is the only lago command that creates a long lived Lago process.
The above had been causing several issues:
Users frequently forget to run lago ovirt serve
Whet cleanup steps fail, lago ovirt serve can keep runing and prevent the same command from being run in a new lago environment on the same host
What needs to be done IMO:
The code for running the local server should be changed so that instead of assuming the server will always be started and stopped within the same python process, the server will be double forked to a new daemon process whose PID will be tracked with a file in the prefix.
A new syntax will be added to the LagoInitFile to specify that a local repo server should be available in the environment (It could be expanded in the future to enable running multiple servers and specifying that reposync should run at deploy, but lets not spend time on enhancements ATM)
lago start needs to be changed to start the server if asked for, lago stop to stop it etc.
lago status should show the status of the repo server. To do that, it should have a special URL defined that will return some status JSON. To be robust the status command should probably always try to check if the server process is up before trying to query it over HTTP.
The lago ovirt serve command should be converted into a noop showing a deprecation warning with some instructions on how to add the server to the LagoIniFile.
Also it might be useful to move the server code to its own separate Python file so that we don't have to have the whole Lago code base in memory just to serve some files over HTTP.
The text was updated successfully, but these errors were encountered:
The repository server is currently a very strange thing, is something that lives in the Lago environment but:
LagoInitFile
lago start
lago stop
lago destroy
lago ovirt serve
is the only lago command that creates a long lived Lago process.The above had been causing several issues:
lago ovirt serve
lago ovirt serve
can keep runing and prevent the same command from being run in a new lago environment on the same hostWhat needs to be done IMO:
LagoInitFile
to specify that a local repo server should be available in the environment (It could be expanded in the future to enable running multiple servers and specifying thatreposync
should run at deploy, but lets not spend time on enhancements ATM)lago start
needs to be changed to start the server if asked for,lago stop
to stop it etc.lago status
should show the status of the repo server. To do that, it should have a special URL defined that will return some status JSON. To be robust the status command should probably always try to check if the server process is up before trying to query it over HTTP.lago ovirt serve
command should be converted into a noop showing a deprecation warning with some instructions on how to add the server to theLagoIniFile
.Also it might be useful to move the server code to its own separate Python file so that we don't have to have the whole Lago code base in memory just to serve some files over HTTP.
The text was updated successfully, but these errors were encountered: