On Fri, May 13, 2016 at 4:19 PM, Kevin Fenzi <kevin@xxxxxxxxx> wrote: > On Tue, 10 May 2016 14:12:28 -0500 > Adam Miller <maxamillion@xxxxxxxxxxxxxxxxx> wrote: > >> On Mon, May 9, 2016 at 2:49 PM, Kevin Fenzi <kevin@xxxxxxxxx> wrote: >> > On Fri, 6 May 2016 17:30:18 -0500 >> > Adam Miller <maxamillion@xxxxxxxxxxxxxxxxx> wrote: >> > >> > ...snip... >> > >> >> >> >> Proposal: >> >> >> >> Pulp[1] + Crane[2] + MirrorManager[3] + Docker Distribution[4] >> > >> > Are all of these packaged up? For EPEL? >> > (aside mirrormanager). >> >> Yes packaged in Fedora, I would have to double check on EPEL. > > ok. Either will work, but epel is nicer from a sysadmin perspective... > > ...snip... > >> I was planning to have them in pulp and accessible to testers but >> wasn't sure if we publish testing stuff to the mirrors for rpms. If we >> do, then we could certainly follow suit here. > > We do. We push updates-testing rpms out about as often (if not more > so) than updates rpms. > >> This is all isolated inside of Pulp, nothing outside of pulp would >> need to interact with the message bus and from what I understand, Pulp >> is heavily tied to celery so getting rid of it is not really an >> option. > > ok. Fair enough. > > ...snip... > >> OSBS does not use mongo, why do you think that it does? > > https://infrastructure.fedoraproject.org/infra/ansible/files/openshift/mongodb.conf > > This is a leftover from some older version? Definitely yes, looking at the commit logs that file is from 2012. OpenShift Architecture v2 required MongoDB but wasn't docker or kubernetes based. OpenShift Architecture V3 which has been "current" upstream for almost 2 years now (iirc) was a complete rewrite and is built on top of kubernetes and docker and uses etcd instead of mongodb, but that's isolated to the OpenShift environment and is managed embedded as part of OpenShift. > >> The end users will hit https/443 and that should be the only open port >> we need, we can redirect port 80 to 443 if we like. > > Great. > >> Having 2 crane frontends would be great and I was planning on having >> two of them hiding behind haproxy. The other internal components are >> only needed to publish content for crane to serve but once published >> then they are no longer needed and can go up/down as we like. Crane >> just serves 302 redirects to where the content actually lives, which >> will be somewhere out in mirrormanager land. > > Excellent. Yes, we should make two frontends then. > >> > As far as backups of this, we would only need the pulp storage and >> > the mongodb? Or are there other parts that need backups to restore >> > the entire stack in case of doom? >> >> I haven't actually looked into that just yet. I'm not sure about >> disaster recovery for pulp or docker-distribution. Crane itself just >> needs the files backed up. > > ok. We should figure that out at some point, but it sounds like if we > have files and crane we can at least keep serving the data we already > are in the case of a disaster. The backup docs from upstream seems pretty straight forward, we'll likely need to evaluate some stuff once we have a PoC in place and get all the systems tied together. http://pulp.readthedocs.io/en/latest/user-guide/server.html -AdamM > > kevin > > _______________________________________________ > infrastructure mailing list > infrastructure@xxxxxxxxxxxxxxxxxxxxxxx > http://lists.fedoraproject.org/admin/lists/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
