Part of / blocker of T133300
Another blocker, and potentially a prerequisite, is publishing the generated documentation. From the drawing and https://www.mediawiki.org/wiki/Continuous_integration/Documentation_generation
[[ https://docs.google.com/drawings/d/15mIgdGn4QsLwg3Ewb9Wi0fHtFoWtojiYn1HeH4USXHU/edit | 201812 (was CI Target 2016) - Doc / coverage publishing (private) ]] gives an overview of the documentation flow.
As summarized by @thcipriani :
* Doc and coverage reports are generated on Jenkins Docker instances in Docker containers (and they have lot of build dependencies)
* The job on the instance runs rsync to a WMCS instance `integration-publisher02`
* A Jenkins job `publish-on-contint1001` is executing on `contint1001.wikimedia.org` to rsync the doc **from** the publisher instance.
We would need a space in production (Ganeti VM?) to host the material with PHP7 (some docs need that see T206046). It should most probably be isolated from the rest of the network, although code published there get Code-Reviewed +2 we never know.
We would need some intermediary system to have the CI building instances to push to (currently WMCS instance `integration-publishing02`).
* Doc and coverage reports are still generated on CI Docker instances
* Building instance push to a publisher system
** might reuse `integration-publisher02`
* Jenkins (or another system) runs a task that fetch from the publisher system to doc.wikimedia.org document root.
We need to find a target host on which to migrate documentation to. It would have Apache / PHP7 and run code as generated by the various code repositories that have doc/coverage enabled.
Flow originating from webhost
| Proto | source host | source IP | dest network | dest Host | dest IP | dest port | description
| TCP | webhost | ??? | WMCS project | integration-publishing02 | 172.16.4.5 | 873 | Jenkins job doing a `rsync` originating from Webhost to fetch material
WARNING: That is where the devil reside. Can a Ganeti instance be allowed to fetch from WMCS instance? That might require to add some routing and punch a hole in the firewall. Else maybe we can expose the rsync daemon on a public IP and restrict it to traffic from the Webhost Ganeti instance.
Flow going to webhost
| Proto | source network | source host | source IP | dest Host | dest port | description
| TCP | labs support hosts | contint1001.wikimedia.org | 184.108.40.206 | webhost | 22 | Jenkins master ssh connection
| TCP | production | misc varnish | - | webhost | 80 | Misc cache to Apache serving doc.wikimedia.org