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
Webserver
As discussed with @manics during testing of his PR, I have major problems with the development server starting every time as a default option in omego.
The solution would be --skipweb=TRUE, but it is hard to remember to pass this flag every time.
This is convoluted with the fact that I am using a development webserver. This is being passed in my config (see below about the config passing).
My, development webserver, starts every time I use omego without the --skipweb flag (=very often), and then it is not possible to stop it using bin/omero web stop - it has to be stopped "manually", killing the processes one by one -> very annoying.
Suggestions for Webserver:
Was told by @manics , the production web server would really restart during omego upgrade, which makes me doubt about my original suggestion to make --skipweb=TRUE a default option.
I would still opt for --skipweb=TRUE to be a default when omego install is run - with an appropriate output on the cmd line of course, saying "please sort yourself out, check all is fine with your server, check your config, then start the bin/omero web start from appropriate folder" - just a suggestion.
Config:
I find it often very confusing to figure out what config will be actually used in this or that case. This might be even dangerous, in case the --upgradedb flag is used (I might upgrade the db to a version I did not intend -> no downgrade -> problem.
There is a --cfg ./config.xml option, which works, but then you have to take care of the config.xml file beforehand - not very nice.
Suggestions for config:
make it very easy to check your config using omego (remember that when using omego, you are in a parent directory to the one where your bin/omero… commands can be executed from - not very straightforward to jump from one dir to another just to check your present config.
make it very clear what config will be used when the omego commands are going ahead with installs, upgrades etc. - maybe even a compulsory question at the start, saying - for dbupgrade this and that config will be used, for the init this and that config, for the upgraded server this and that config - yes, you do not have the exact config variables at hand before the command is executed, but you can inform the user FROM WHERE will the configs be taken from. A simple question then follows: Are you happy to proceed ? y n. I am sure an admin would rather like to stop and ponder for 1 min before blowing up the DB of the whole institute using hidden omego configs.
The text was updated successfully, but these errors were encountered:
Webserver
As discussed with @manics during testing of his PR, I have major problems with the development server starting every time as a default option in omego.
The solution would be
--skipweb=TRUE
, but it is hard to remember to pass this flag every time.This is convoluted with the fact that I am using a development webserver. This is being passed in my config (see below about the config passing).
My, development webserver, starts every time I use omego without the
--skipweb
flag (=very often), and then it is not possible to stop it using bin/omero web stop - it has to be stopped "manually", killing the processes one by one -> very annoying.Suggestions for Webserver:
omego upgrade
, which makes me doubt about my original suggestion to make--skipweb=TRUE
a default option.--skipweb=TRUE
to be a default whenomego install
is run - with an appropriate output on the cmd line of course, saying "please sort yourself out, check all is fine with your server, check your config, then start the bin/omero web start from appropriate folder" - just a suggestion.Config:
I find it often very confusing to figure out what config will be actually used in this or that case. This might be even dangerous, in case the
--upgradedb
flag is used (I might upgrade the db to a version I did not intend -> no downgrade -> problem.There is a --cfg ./config.xml option, which works, but then you have to take care of the config.xml file beforehand - not very nice.
Suggestions for config:
Are you happy to proceed ? y n
. I am sure an admin would rather like to stop and ponder for 1 min before blowing up the DB of the whole institute using hidden omego configs.The text was updated successfully, but these errors were encountered: