[Python-checkins] peps: PEP 474: More thoughts on overall infrastructure maintenance

[nick.coghlan]

https://hg.python.org/peps/rev/37be0a3708c9
changeset:   5725:37be0a3708c9
user:        Nick Coghlan <ncoghlan at gmail.com>
date:        Thu Mar 12 13:25:59 2015 +1000
summary:
  PEP 474: More thoughts on overall infrastructure maintenance

files:
  pep-0474.txt |  57 +++++++++++++++++++++++++++++++++++++++-
  1 files changed, 56 insertions(+), 1 deletions(-)


diff --git a/pep-0474.txt b/pep-0474.txt
--- a/pep-0474.txt
+++ b/pep-0474.txt
@@ -230,13 +230,68 @@
 of interesting technical concerns and challenges. This section covers several
 of the most significant ones.
 
+Service hosting
+---------------
+
+The default position of this PEP is that the new forge.python.org service
+will be integrated into the existing PSF Salt infrastructure and hosted on
+the PSF's Rackspace cloud infrastructure.
+
+However, other hosting options will also be considered, in particular,
+possible deployment as a `Kubernetes <http://kubernetes.io/>`__ hosted web
+service on either
+`Google Container Engine <https://cloud.google.com/container-engine/>`__ or
+the next generation of Red Hat's
+`OpenShift Online <http://www.openshift.org/>`__ service, by using either
+GCEPersistentDisk or the open source
+`GlusterFS distributed filesystem <http://www.emergingafrican.com/2015/02/configuring-kubernetes-to-use.html>`__
+to hold the source code repositories.
+
+
+Ongoing infrastructure maintenance
+----------------------------------
+
+Ongoing infrastructure maintenance is an area of concern within the PSF,
+as we currently lack a system administrator mentorship program equivalent to
+the `Fedora Infrastructure Apprentice
+<https://fedoraproject.org/wiki/Infrastructure/GettingStarted>`__ or
+`GNOME Infrastructure Apprentice <https://wiki.gnome.org/Sysadmin/Apprentices>`__
+programs.
+
+Instead, systems tend to be maintained largely by developers as a part time
+activity on top of their development related contributions, rather than
+seeking to recruit folks that are more interested in operations (i.e.
+keeping existing systems running well) than they are in development (i.e.
+making changes to the services to provide new features or a better user
+experience, or to address existing issues).
+
+While I'd personally like to see the PSF operating such a program at some
+point in the future, I don't consider setting one up to be a
+feasible near term goal. However, I do consider it feasible to continue
+laying the groundwork for such a program by extending the PSF's existing
+usage of modern infrastructure technologies like OpenStack and Salt to
+cover more services, as well as starting to explore the potential benefits of
+containers and container platforms when it comes to maintaining and enhancing
+PSF provided services.
+
+I also plan to look into the question of whether or not an open source cloud
+management platform like `ManageIQ <http://manageiq.org/>`__ may help us
+bring our emerging "cloud sprawl" problem across Rackspace, Google, Amazon
+and other services more under control.
+
+
 User account management
 -----------------------
 
 Ideally we'd like to be able to offer a single account that spans all
 python.org services, including Kallithea, Roundup/Rietveld, PyPI and the
 back end for the new python.org site, but actually implementing that would
-be a distinct infrastructure project, independent of this PEP.
+be a distinct infrastructure project, independent of this PEP. (It's also
+worth noting that the fine-grained control of ACLs offered by such a
+capability is a prerequisite for setting up an
+`effective system administrator mentorship program
+<https://www.dragonsreach.it/2015/01/28/the-gnome-infrastructure-apprentice-program/>`__)
+
 
 For the initial rollout of forge.python.org, we will likely create yet another
 identity silo within the PSF infrastructure. A potentially superior

-- 
Repository URL: https://hg.python.org/peps