On 8 January 2018 at 11:21, Aurelien Bompard <abompard@xxxxxxxxxxxxxxxxx> wrote: > >> 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. Well lets skip container speech at the moment because I think everyone has their own dialect anyway? Let us start with how we would do this 'normally' 1. We are putting this all on one box which talk to each other locally. 2. We are putting many of these on separate boxes which talk to each other. 3. We are putting many of these on separate boxes which don't talk outside of their zone to each other because some of the data is local only (aka say the caching server only cached certain contact for a session and then dropped it afterwords.. or some similar short term thing.) We can figure out the nomenclature of where things need to be 'frozen' and how they are to listen for things. So the existing services which this would need to talk to are: 1. FAS 2. Fedmsg 3. ??? [Look at this as a thought experiment.. if we stood this up in amazon.com cloud.. what does it need to talk to elsewhere to be useful?] > > 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 > -- Stephen J Smoogen. _______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx
