On 02/05/2018 01:58 AM, Aurelien Bompard wrote: > Hey, sorry for the silence on this subject, I was experimenting with > deployment options. > So far, here's what I've come up with. > > Npm has a command called "shrinkwrap" which will list all the installed > dependencies and their versions recursively and dump that in a file. It's > pretty much like "pip freeze". Then all subsequent calls to "npm install" > will use those versions regardless of what the most current one is. > So I've generated and committed this version in git, and then I've cleaned > up the local dependencies dir, run "npm install" again, and tarred up this > big directory. I'm using this tarball as an additional source for the Hubs > RPM that I wrote, untar it in %prep, build the JS in %build, install the > resulting files in %install. > This adresses the issues of reproductible builds, and the "bundled" sources > (which are only bundled in the source RPM, not the binary one) are easily > re-generated on any machine with npm installed. It also means that the RPM > can build in mock because all dependencies are locally provided. > > Would this method of deployment work for you? > > Concerning services location (all local or split), I'm thinking on the > following layout: > - shared PostgreSQL > - everything else on the same host. > It's simple and it would be sufficient for a start because we're only going > to setup a few group hubs for "early adopter" teams (however anyone with a > FAS account can login and have their hub autocreated). Then if we need to > loadbalance we'll be able to split the services, that shouldn't be a > problem. > > What do you think? I think this could work ok, but you might run into problems with updates if the versions shift around... but I guess as long as you re 'shrinkwrap' on updates it should work. We don't have any way to track security issues for all the frozen set do we? How often do you see us updating that set? everytime the hubs rpm updates? Or just when we want to try and roll up to latest? > By the way, Ryan has open a RFR (with an ominous number): > https://pagure.io/fedora-infrastructure/issue/6666 > Is it missing any info? I don't think so off hand. Looks like pingou is listed as the sponsor so when things are ready he would be the one to tell you are a go for a staging instance(s) and all the other next steps (sops, playbooks, nagios monitoring, etc). kevin
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx
