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
_______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx
