-
Notifications
You must be signed in to change notification settings - Fork 10
Open
Labels
Description
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 serveis 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 servecan 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
LagoInitFileto 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 thatreposyncshould run at deploy, but lets not spend time on enhancements ATM) lago startneeds to be changed to start the server if asked for,lago stopto stop it etc.lago statusshould 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 servecommand 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.