Gentoo Infrastructure - Revision history

Tiziano: /* File mirror host requirements */

2014-08-21T11:18:34Z

File mirror host requirements

← Older revision		Revision as of 13:18, 21 August 2014
Line 125:		Line 125:
	== File mirror host requirements ==		== File mirror host requirements ==

	see [[Mirror Server]]		see [[Mirror Server#Requirements]]

	== Puppet requirements ==		== Puppet requirements ==

Tiziano: /* File mirror host requirements */

2014-08-21T11:17:52Z

File mirror host requirements

← Older revision		Revision as of 13:17, 21 August 2014
Line 124:		Line 124:

	== File mirror host requirements ==		== File mirror host requirements ==
	* Hosts all the files required to build a package (<code>GENTOO_MIRRORS=mirror.example.com/public/gentoo/distfiles</code>)
	** Acts as a caching mirror for already downloaded packages from an official mirror, example caching mirror URL https://mirror.example.com/mirror		see [[Mirror Server]]
	** Serves fetch-restricted files (<code>dev-java/oracle-jdk-bin</code> for example), to authorized clients
	* Files are served via HTTPS
	* Distinguishes between three groups of files
	** '''public''': Files which are available to all clients (theoretically even to the entire internet, added to clients via GENTOO_MIRRORS)
	** '''site-local''': Files which are only available to authenticated clients belonging to the same infrastructure (for example those which would put us into [http://www.bettercallsaul.com/ legal troubles] if available to the public, used by clients via a ''local'' entry in <code>/etc/portage/mirrors</code>)
	*** A subdirectory named after a site will be created below <code>site-local</code>, for example <code>site-local/example-site</code>.
	** '''stack-local''': Files which are only available to authenticated clients belonging to the same infrastructure and the software stack group (private files of a specific customer, used by clients via a ''local'' entry in <code>/etc/portage/mirrors</code>)
	*** A subdirectory per stack will be created below <code>stack-local</code>, for example <code>stack-local/secret-stack</code>.
	* Provides an easy way to let an administrator manually upload new files, for example via WebDAV-CGI, SFTP or a similar mechanism.
	* Possibility to authenticate clients either via HTTP basic auth or client certificates.
	* Old or no longer supported files will be removed automatically
	* Can be implemented on the [[~~#Build_host_requirements\|build host~~]]

	== Puppet requirements ==		== Puppet requirements ==

Michael: /* Package host requirements */

2014-08-13T14:56:41Z

Package host requirements

← Older revision		Revision as of 16:56, 13 August 2014
Line 116:		Line 116:
	* Serving files via HTTPS		* Serving files via HTTPS
	** Binary packages for all the clients (<code>PORTAGE_BINHOST</code>), which were built by the [[#Build_host_requirements\|build host]]		** Binary packages for all the clients (<code>PORTAGE_BINHOST</code>), which were built by the [[#Build_host_requirements\|build host]]
	*** Binary packages will be accessible via a HTTP URL such as <code>https://packages.example.com/gentoo/ARCH/BUILD-PROFILE-NAME/~~ENVIRONMENT~~</code>. This is a symlink to the current snapshot <code>https://packages.example.com/gentoo/ARCH/BUILD-PROFILE-NAME/YYYY-MM-DD</code>		*** Binary packages will be accessible via a HTTP URL such as <code>https://packages.example.com/gentoo/ENVIRONMENT/ARCH/BUILD-PROFILE-NAME/latest</code>. This is a symlink to the current snapshot <code>https://packages.example.com/gentoo/ENVIRONMENT/ARCH/BUILD-PROFILE-NAME/YYYY-MM-DD</code>
	*** Clients will have <code>PORTAGE_BINHOST="https://packages.example.com/gentoo/ARCH/BUILD-PROFILE-NAME~~/ENVIRONMENT~~ https://packages.example.com/gentoo/ARCH/APP-STACK-PROFILE-NAME~~/ENVIRONMENT~~ ..."</code> set in their <code>/etc/portage/make.conf</code>.		*** Clients will have <code>PORTAGE_BINHOST="https://packages.example.com/gentoo/ARCH/ENVIRONMENT/BUILD-PROFILE-NAME https://packages.example.com/gentoo/ENVIRONMENT/ARCH/APP-STACK-PROFILE-NAME ..."</code> set in their <code>/etc/portage/make.conf</code>.
	* Support for all three environments (development, staging and production)		* Support for all three environments (development, staging and production)
	* Possibility to authenticate clients either via HTTP basic auth or client certificates.		* Possibility to authenticate clients either via HTTP basic auth or client certificates.

Michael: /* Package host requirements */

2014-08-13T14:06:25Z

Package host requirements

← Older revision		Revision as of 16:06, 13 August 2014
Line 116:		Line 116:
	* Serving files via HTTPS		* Serving files via HTTPS
	** Binary packages for all the clients (<code>PORTAGE_BINHOST</code>), which were built by the [[#Build_host_requirements\|build host]]		** Binary packages for all the clients (<code>PORTAGE_BINHOST</code>), which were built by the [[#Build_host_requirements\|build host]]
	*** Binary packages will be accessible via a HTTP URL such as <code>https://packages.example.com/ENVIRONMENT/gentoo/ARCH/BUILD-PROFILE-NAME</code>.		*** Binary packages will be accessible via a HTTP URL such as <code>https://packages.example.com/gentoo/ARCH/BUILD-PROFILE-NAME/ENVIRONMENT</code>. This is a symlink to the current snapshot <code>https://packages.example.com/gentoo/ARCH/BUILD-PROFILE-NAME/YYYY-MM-DD</code>
	*** Clients will have <code>PORTAGE_BINHOST="https://packages.example.com~~/ENVIRONMENT~~/gentoo/ARCH/~~SYSTEM~~-PROFILE-NAME https://packages.example.com~~/ENVIRONMENT~~/gentoo/ARCH/APP-STACK-PROFILE-NAME ..."</code> set in their <code>/etc/portage/make.conf</code>.		*** Clients will have <code>PORTAGE_BINHOST="https://packages.example.com/gentoo/ARCH/BUILD-PROFILE-NAME/ENVIRONMENT https://packages.example.com/gentoo/ARCH/APP-STACK-PROFILE-NAME/ENVIRONMENT ..."</code> set in their <code>/etc/portage/make.conf</code>.
	* Support for all three environments (development, staging and production)		* Support for all three environments (development, staging and production)
	* Possibility to authenticate clients either via HTTP basic auth or client certificates.		* Possibility to authenticate clients either via HTTP basic auth or client certificates.

Tiziano: /* File mirror host requirements */

2014-03-20T15:28:36Z

File mirror host requirements

← Older revision		Revision as of 17:28, 20 March 2014
Line 129:		Line 129:
	* Files are served via HTTPS		* Files are served via HTTPS
	* Distinguishes between three groups of files		* Distinguishes between three groups of files
	** '''public''': Files which are available to all clients (theoretically even to the entire internet)		** '''public''': Files which are available to all clients (theoretically even to the entire internet, added to clients via GENTOO_MIRRORS)
	** '''site-local''': Files which are only available to authenticated clients belonging to the same infrastructure (for example those which would put us into [http://www.bettercallsaul.com/ legal troubles] if available to the public)		** '''site-local''': Files which are only available to authenticated clients belonging to the same infrastructure (for example those which would put us into [http://www.bettercallsaul.com/ legal troubles] if available to the public, used by clients via a ''local'' entry in <code>/etc/portage/mirrors</code>)
	*** A subdirectory named after a site will be created below <code>site-local</code>, for example <code>site-local/example-site</code>.		*** A subdirectory named after a site will be created below <code>site-local</code>, for example <code>site-local/example-site</code>.
	** '''stack-local''': Files which are only available to authenticated clients belonging to the same infrastructure and the software stack group (private files of a specific customer)		** '''stack-local''': Files which are only available to authenticated clients belonging to the same infrastructure and the software stack group (private files of a specific customer, used by clients via a ''local'' entry in <code>/etc/portage/mirrors</code>)
	*** A subdirectory per stack will be created below <code>stack-local</code>, for example <code>stack-local/secret-stack</code>.		*** A subdirectory per stack will be created below <code>stack-local</code>, for example <code>stack-local/secret-stack</code>.
	* Provides an easy way to let an administrator manually upload new files, for example via WebDAV-CGI, SFTP or a similar mechanism.		* Provides an easy way to let an administrator manually upload new files, for example via WebDAV-CGI, SFTP or a similar mechanism.

Chrigu: /* File mirror host requirements */

2014-03-13T14:03:15Z

File mirror host requirements

← Older revision		Revision as of 16:03, 13 March 2014
Line 125:		Line 125:
	== File mirror host requirements ==		== File mirror host requirements ==
	* Hosts all the files required to build a package (<code>GENTOO_MIRRORS=mirror.example.com/public/gentoo/distfiles</code>)		* Hosts all the files required to build a package (<code>GENTOO_MIRRORS=mirror.example.com/public/gentoo/distfiles</code>)
	** Acts as a caching mirror for already downloaded packages from an official mirror		** Acts as a caching mirror for already downloaded packages from an official mirror, example caching mirror URL https://mirror.example.com/mirror
	** Serves fetch-restricted files (<code>dev-java/oracle-jdk-bin</code> for example), to authorized clients		** Serves fetch-restricted files (<code>dev-java/oracle-jdk-bin</code> for example), to authorized clients
	* Files are served via HTTPS		* Files are served via HTTPS

Chrigu: /* File mirror host requirements */

2014-03-13T13:58:38Z

File mirror host requirements

← Older revision		Revision as of 15:58, 13 March 2014
Line 131:		Line 131:
	** '''public''': Files which are available to all clients (theoretically even to the entire internet)		** '''public''': Files which are available to all clients (theoretically even to the entire internet)
	** '''site-local''': Files which are only available to authenticated clients belonging to the same infrastructure (for example those which would put us into [http://www.bettercallsaul.com/ legal troubles] if available to the public)		** '''site-local''': Files which are only available to authenticated clients belonging to the same infrastructure (for example those which would put us into [http://www.bettercallsaul.com/ legal troubles] if available to the public)
	** '''stack-local''': Files which are only available to authenticated clients belonging to the same infrastructure and the software stack group (private files of a specific customer)		*** A subdirectory named after a site will be created below <code>site-local</code>, for example <code>site-local/example-site</code>.
			** '''stack-local''': Files which are only available to authenticated clients belonging to the same infrastructure and the software stack group (private files of a specific customer)
			*** A subdirectory per stack will be created below <code>stack-local</code>, for example <code>stack-local/secret-stack</code>.
	* Provides an easy way to let an administrator manually upload new files, for example via WebDAV-CGI, SFTP or a similar mechanism.		* Provides an easy way to let an administrator manually upload new files, for example via WebDAV-CGI, SFTP or a similar mechanism.
	* Possibility to authenticate clients either via HTTP basic auth or client certificates.		* Possibility to authenticate clients either via HTTP basic auth or client certificates.

Lucas: /* build orchestration */

2014-02-06T17:27:05Z

build orchestration

← Older revision		Revision as of 19:27, 6 February 2014
Line 237:		Line 237:

	==== build orchestration ====		==== build orchestration ====
			* [http://mesos.apache.org/ Apache Mesos] cluster manager that provides efficient resource isolation and sharing across distributed applications, or frameworks. Can run for instance Jenkins.

	==== package building ====		==== package building ====

Lucas: /* Build farm proposal */

2014-01-31T20:09:17Z

Build farm proposal

← Older revision		Revision as of 22:09, 31 January 2014
Line 231:		Line 231:
	** puppet report data		** puppet report data
	** test results and code analysis results		** test results and code analysis results
	* When we come to continuos deployment the jenkins master will also be able to trigger puppet when merges to master happen. ~~Thus rolling~~ out releases to the sub-system that was signed off by a merge to a master branch.		* When we come to continuos deployment the jenkins master will also be able to trigger puppet when merges to master happen.
			* This rolls out releases to the sub-system that was signed off by a merge to a master branch (see branching strategy in git proposal).

	=== Links ===		=== Links ===

Lucas: /* Build farm proposal */

2014-01-31T20:07:04Z

Build farm proposal

@@ Line 213: / Line 213: @@
 = Implementation proposal =
 == Build farm proposal ==
-The build farm consists out of a system of multiple vms to build binary packages for multiple environments, architectures and build profiles.
+The build farm consists of a system of multiple vms to build binary packages for multiple environments, architectures and build profiles.
 === Links ===