iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 474: More thoughts on overall infrastructure maintenance

This commit is contained in:
Nick Coghlan 2015-03-12 13:25:59 +10:00
parent ce46615b2d
commit 9e4f6f2fa1
1 changed files with 56 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

57
pep-0474.txt
View File

@ -230,13 +230,68 @@ Introducing a new service into the CPython infrastructure presents a number
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