Reading this and knowing the dependencies that node apps tend to
have, I
wonder
if using containers with a very strict dependency list isn't the best
middle
ground.
I was thinking along those lines too. In Python there's "pip freeze" that
lets you extract precise versions, I sure there's an equivalent in NodeJS,
although I haven't looked at that yet.
- Aurélien, Ryan, Sayan: do you know if it is doable to build/run
hubs in a
container? (if do you know up hand if it is *not* possible to do it?)
It should be possible, since the development setup includes a Vagrant VM.
But I'm not very fluent in container-speech so I don't know exactly what
the hurdles could be.
Hubs is basically composed of the following parts:
- a SQL database (no external access)
- a Redis database (no external access)
- a Mongo database (no external access)
- a Flask-based HTTP backend that talks to the DBs and to the client, and
makes external HTTP requests.
- a JS-based UI that is compiled at build-time and served by the Flask
backend.
- a Twisted-based backend that listens to Fedmsg and talks to the DBs and
makes external HTTP requests.
I don't think I'm missing a component.
The strict dependency list brings in another question/issue: how to track
the
updates? Who would be responsible for this?
Who should change <req>==<version1> to <req>==<version2>?
Probably the devs and the security people if there's an emergency.
Who will track that <version1> doesn't have a security
issue that was
reported?
Well, that's one of the main issues I think. How do we manage that for the
packages we maintain in Fedora and in the Infra repo? It should be a
similar process.
- Ryan, Aurélien, Sayan: how have you been updating that dependency
list[1] so
far?
Currently the list isn't strict, it allows whichever "compatible" version
(as defined in semver). So we have upgraded the versions only when we
needed the major new features (and for compatibility).
Aurélien