15 Commits

Author SHA1 Message Date
Clark Boylan
07c7f757d0 Add comments to manage-projects about project-config syncing
There were questions around project-config syncing and the way it is
done in manage-projects during our last project renaming. I've since
read through teh code to try and understand things better and have added
comments to manage-projects.yaml indicating the risks here and why we
approach it the way we do. There is no functional change only an attempt
at better understanding for the future.

Change-Id: I60aa58a36108edce3e00ecf2ac10be3dee7e8ea0
2021-10-21 11:44:02 -07:00
Ian Wienand
163d5b6133 Create review-staging group
Create a review-staging group so we can bring up a new server but
avoid running the project-management steps on it.

Change-Id: I93d2a36edcd58a48a36031f0692be3273a36f07c
2021-03-24 11:40:33 +11:00
Ian Wienand
9f11fc5c75 Remove references to review-dev
With our increased ability to test in the gate, there's not much use
for review-dev any more.  Remove references.

Change-Id: I97e9865e0b655cd157acf9ffa7d067b150e6fc72
2021-03-24 11:40:31 +11:00
Clark Boylan
8a9ed04cab Simplify gitea project creation control flow
Previously we set strategy: free and max_fail_percentage: 1 and this
probably made sense when we were using native ansible to do all of the
work to create projects. That was slow and broken down into many tasks.

Now however, we have a single task that calls out to a python module
that does all the work for each gitea host. That means we won't get any
additional parallelization from the free strategy. We also don't want to
stop the python module on all hosts if any of them fail, instead let
them all run to completion if they can. Then if any giteas fail we
should skip the play on review.

Change-Id: I1548e7946526b683d71fe4e905faabd1049f186c
2020-09-24 11:28:42 -07:00
Monty Taylor
e161767beb Stop running manage projects on review-test
This was originally left here because it seemed like a good thing
to test, but it's currently causing thigns to hang. Exclude it
until we know why.

Change-Id: Ibc6f001e1235e9f0d856cc350ed8099e52c706e9
2020-06-26 11:07:10 -05:00
Monty Taylor
ebae022d07 Use project-config from zuul instead of direct clones
We use project-config for gerrit, gitea and nodepool config. That's
cool, because can clone that from zuul too and make sure that each
prod run we're doing runs with the contents of the patch in question.

Introduce a flag file that can be touched in /home/zuulcd that will
block zuul from running prod playbooks. By default, if the file is
there, zuul will wait for an hour before giving up.

Rename zuulcd to zuul

To better align prod and test, name the zuul user zuul.

Change-Id: I83c38c9c430218059579f3763e02d6b9f40c7b89
2020-04-15 12:29:33 -05:00
Zuul
1059cb6121 Merge "Change manage-projects default args" 2020-03-31 23:19:07 +00:00
Zuul
6c5505a60d Merge "Log manage-projects to stdout" 2020-03-31 18:20:00 +00:00
Monty Taylor
3401c32c62 Change manage-projects default args
Just set them to -v, which we set as an override in the playbook
in the previous change.

Change-Id: Ie18c9bbd7dfa3d274ce283f9152e2c27905d9d08
2020-03-31 12:42:54 -05:00
Monty Taylor
eee201edd3 Don't run the review clone on connection local
connection: local is set on the first play. That means it's using
the local connection to try to clone on review - which just means
a second clone on bridge.

Change-Id: I11ff748617b405448697012759e2dab0314f6857
2020-03-31 09:53:41 -05:00
Monty Taylor
771e401001 Log manage-projects to stdout
If we're gonna run this from zuul instead of from cron, output to
stdout so that the output will be captured in zuul logs.

Change-Id: I7228cacfb47834a32b803031ebe104ba02d09c40
2020-03-30 15:57:50 -05:00
Monty Taylor
b94a2c5b96 Update project-config in manage-projects
If we're going to trigger this from project-config, we should
make sure it updates project-config as a first step. Currently
it's counting on having run after service-review in run_all.sh.

Change-Id: I14ce9b42af533c742128ce87cda8c8fb897632e4
2020-03-30 10:00:12 -05:00
Monty Taylor
cc1929d075 Add an image pull to manage-projects playbook
When we run manage-projects, we always want the latest image.

Add a task file to the gerrit role so that it can have access
to role default variables. Then call it from the playbook
with tasks_from.

Change-Id: I08bd10539d7f08e8759f1c22d66dea18821c9d42
2020-03-27 15:58:41 -05:00
Monty Taylor
5d79086350 Run manage-projects on gerrit servers
We have a wrapper script now that works on the gerrit servers.
Run it after we run the gitea repo creation.

Remove the -it since this is not an interactive run. Add net=host
so that localhost maps. And set the server to localhost.

Don't run manage-projects in gate jobs for run-review yet, because
we don't have a functioning enough gerrit. We can follow up with
that.

Change-Id: I8c0eb5d7973815ae21d4d5bc1be8d4bdfe56d7fc
2020-03-25 17:50:52 -05:00
Monty Taylor
86542eb9ba Split gitea and gerrit services from manage-projects
There are two different concerns here. One is configuring the gitea
and gerrit services. This is independent from the management of
projects running inside them.

Make a manage-projects playbook which currently runs gitea-git-repos
but will also get a gerrit-git-repos role in a bit. Make a
service-gitea playbook for deploying gitea itself and update
run_all to take all of that into account. This should make our
future world of turning these into zuul jobs easier.

Add several missing files to the files matchers for run-gitea
and run-review.

Also - nothing about this has anything to do with puppet.

Change-Id: I5eaf75129d76138c61013a3a7ed7c381d567bb8b
2020-03-21 11:34:19 -05:00