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
Regarding #7 need to get rid /etc/superdesk.sh and /opt/superdesk/env.sh and start to use only settings.py for server related configurations.
Get rid of supervisord
There are some reasons for that.
supervisord don't have support for python3, so it needs python2 just for run it.
It sounds good to switch totally to systemd (default init system in Ubuntu 16.04), but our system engineers are using one systemd service with honcho and they are going to use it for a while yet, so seems it's good also to use the same setup to be closer to our production instances.
Also it'll simplify the installation a bit, because supervisor and systemd configs are more verbose, so probably it'll be simpler to run two instances of superdesk in the same container for development and for unit tests.
Combine build and deploy steps
It was desirable splitting, for repeating steps from production and for optimization in CI (the build step takes 3+ minutes, and redeployment takes only 1-2 minutes and this's good). But it adds complicity in installation and administration of such instances. After combining these steps, upgrade process will be simpler and more understandable for users.
The text was updated successfully, but these errors were encountered:
In general there is still separate build and deploy steps, but grunt build is now running during deploy step, so all env variables are available already, so it's also kind of simplification, developers often use env variables in superdesk-client-core and liveblog too, so I don't need to keep and modify config.json file in fireq repository. Should be easy to maintain fireq.
Get rid of supervisord
So now we have systemd service file with honcho inside, looks better, also it's possible to create another systemd service for testing purposes (like running e2e tests).
Use only settings.py for server configuration
I gave up this idea, because we have too many different projects with different settings.py and moving them to fireq repository is just crazy. Anyway it still needs some env variables declared somewhere, for client SUPERDESK_URL, SUPERDESK_WS_URL are needed, PYTHONUNBUFFERED=1 and C_FORCE_ROOT=1 for honcho, etc. So for simplification (from user perspective) we now have one /opt/superdesk/activate.sh where we load virtualenv and declare some env variables, there is optional /opt/superdesk/env.sh which uses in CI and loads in activate.sh script.
There is also new build&deploy templates tpl/superdesk-new without main superdesk repo and with minimal set of files to run superdesk using just cores. It was created mainly for inspiration in regards of #8 (rethink main repo), union /opt/superdesk/activate.sh script came from this attempt... It can be used for user installations in future.
Use
settings.py
Regarding #7 need to get rid
/etc/superdesk.sh
and/opt/superdesk/env.sh
and start to use onlysettings.py
for server related configurations.Get rid of
supervisord
There are some reasons for that.
supervisord
don't have support forpython3
, so it needspython2
just for run it.It sounds good to switch totally to
systemd
(default init system in Ubuntu 16.04), but our system engineers are using one systemd service with honcho and they are going to use it for a while yet, so seems it's good also to use the same setup to be closer to our production instances.Also it'll simplify the installation a bit, because
supervisor
andsystemd
configs are more verbose, so probably it'll be simpler to run two instances ofsuperdesk
in the same container for development and for unit tests.Combine
build
anddeploy
stepsIt was desirable splitting, for repeating steps from production and for optimization in CI (the build step takes 3+ minutes, and redeployment takes only 1-2 minutes and this's good). But it adds complicity in installation and administration of such instances. After combining these steps, upgrade process will be simpler and more understandable for users.
The text was updated successfully, but these errors were encountered: