since the causality query is so expensive, it makes sense to give
cluster admins the ability to disable the endpoints and page view.
this is the first time we introduced the idea of feature flags to the
frontend. my solution is to include the current state of the feature
flags in the `/api/v1/info` endpoint, this can then be parsed by the
frontend and stored in `session` making it available to any elm code
that might require it.
if resource causality is disabled (default), the `view all` buttons in
the expended resource version will not show up and trying to navigate to
the causality pages directly via url will result in a standard 404 not
found page.
another change is the stauts code for the causality endpoint will be 403
Forbidden if causality is disabled, and 422 UnprocessableEntity if the
graph is too large.
Signed-off-by: Bohan Chen <bochen@pivotal.io>
Setting the default value of --runtime to containerd. No longer need to set the
value explicitly in the docker-compose.yml.
concourse/concourse#7106
Signed-off-by: Muntasir Chowdhury <mchowdhury@pivotal.io>
since we're going to default to using containerd in 7.1.0, we should
probably be developing against it!
this commit uses the containerd runtime by default, and replaces the
containerd override with a guardian one
Signed-off-by: Aidan Oldershaw <aoldershaw@pivotal.io>
overloading the outer docker-compose.yml for both dev and test started
to feel more confusing than just keeping them separate.
namely, it's impossible to un-set 'build:' in an override file, so I
split that out into a docker-compose.override.yml file, symlinked under
hack/overrides/ to keep ./hack/dc working, but then having the tests
*not* use it, even though they use the docker-compose.yml right next to
it, and even though it's normally respected by 'docker-compose'
commands.
Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
* rather than generating keys in the 'Dockerfile', which is slow and
makes the image behave differently from the dev or shipped images,
just check them in. (obviously do not use these - or any of this
workflow - in production.)
* same for vault certs, to make vault testing easier.
* move port mappings and '.' mapping to hack/overrides/dev.yml, which is
now symlinked to docker-compose.override.yml to maintain the previous
'docker-compose up' dev workflow.
this will make it easier to re-use docker-compose.yml for dev images and
for testing against final images. the aim here is to avoid ha
Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
When the feature is disabled, the flag is only hidden in the 'fly set-pipeline'
command, but the api will error if a instance-vars was specified.
Also, the set_pipeline step will error on validation if instance_vars are specified.
concourse/concourse#5808
Signed-off-by: Mathieu Ouellet <mathieu.ouellet@energumen.io>
The `CONCOURSE_GARDEN_DNS_PROXY_ENABLE` flag was taken out of the dev
image in db8c43e565
In order for local docker-compose DNS to work with latest concourse/dev
image we need to renable it. Since Guardian is still the default in
docker-compose.yml it makes sense to use it there and unset it in the
containerd override.
Signed-off-by: Andy Paine <andy.paine@engineerbetter.com>
This way, the across step can only be added to a pipeline if the
`--enable-across-step` flag is provided. The flag does not prevent
across steps from running if the pipeline is already set with an across
step.
Signed-off-by: Aidan Oldershaw <aoldershaw@pivotal.io>
The RFC for archiving pipelines has been merged, therefore we can remove
the feature flag.
Signed-off-by: Taylor Silva <tsilva@pivotal.io>
Co-authored-by: Bohan Chen <bochen@pivotal.io>
this breaks downgrade tests; the worker can't unregister in time, since
the web node just goes away immediately, and workers give up when all
web nodes are unreachable, assuming the cluster is being destroyed.
as a result, the check container ends up sticking around on a stalled
worker, and the check eventually times out. a better solution might be
to have checking not attempt to use a container that's on a stalled
worker, but let's not block the pipeline on that in the meantime.
This reverts commit 3a5690d3bb.
this results in constantly recreating/restarting the worker when it's
really not necessary for web config changes
Signed-off-by: Alex Suraci <asuraci@pivotal.io>
docker-compose still works as usual and pulling latest postgres image.
if providing "POSTGRES_TAG=9.5" with docker-compose, it will pull
postgres 9.5 instead
Signed-off-by: Rui Yang <ryang@pivotal.io>
it seems like postgres by default might need to resize the amount of
shared memory that it uses for performing parallel work.
i've hit this when making 100's of concurrent requests to certain api
endpoints:
could not resize shared memory segment "/PostgreSQL.<..>"
to $N bytes: No space left on device
after applying the change (which makes docker go from 64MB to 1GB), , I
can then execute those requests w/ no problems.
Signed-off-by: Ciro S. Costa <cscosta@pivotal.io>
* explicitly generate keys; this allows them to be shared between
upgrades and downgrades
* don't use the dev Dockerfile and don't perform any building
* use an override file to swap out the image for upgrade/downgrade;
don't use Quickstart
* stop using ephemeral workers, since this caused the workers to
disappear under load
* set `stop_signal: SIGUSR2` so that workers retire during
upgrade/downgrade
* pass the latest final concourse image as an input to upgrade/downgrade
Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
* extract tasks to their own task files
* simplify task dependencies so this can be run more easily with `fly
execute`
* download fly from the ATC instead of building old and new binaries
* rename 'uber' to upgrade-downgrade
* don't do yarn build, just use the dev-test Dockerfile so we can use
the prebuilt assets
* load dev and postgres images as inputs rather than fetching during
`docker-compose up`
Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
we were setting a timeout and interval in the eventually
but the `Wait()` uses the default 1sec timeout
Signed-off-by: Topher Bullock <cbullock@pivotal.io>
Adds a server process to the worker command so that
we can have an endpoint to be reached to healthchecking
the worker.
Internally, such endpoint makes a request to both
`garden` and `baggageclaim`, ensuring that both of
them are up.
It also Includes k8s deployment script for testing
concourse/concourse#2753
Signed-off-by: Topher Bullock <cbullock@pivotal.io>
eh, might be better to just build the dev image and extend it to also do
the yarny bits, and then pass *that* along so we don't need to run the
make task
This reverts commit 8fb4141f37.
also moved web/package.json and web/Makefile to the top, which is a bit
easier to grok.
and cleared out the dev db password so it's a bit easier to connect to.
* fetch mirror resource via multi-stage build; shortens local feedback
loop when working on mirror resource
* create keys in Dockerfile; now you can just 'docker-compose up' and
everything should "just work"!
* only fetch mirror resource; we should be able to omit the rest for
testflight. we can maybe add the rest later or figure out how to
support them when kicking the tires.
note: this is not quite working yet since it relies on (as of yet
uncommitted) changes to the 'concourse' binary to run with the 'gdn'
executable, and support loading resources from a directory
advantages:
* sane process monitoring
* low risk of polluting dev workstation with stuff from running the
worker
* builds everything locally, rather than running concourse-rc, so it
supports iterating on the worker stuff even while developing on OS X
* fewer dev dependencies; uses off-the-shelf postgres image rather than
requiring postgres to be installed
disadvantages:
* not quite as fast as just running 'concourse web' if you're working on
something like the web UI where fast feedback loops are desired
* not sure if cross-compiling 'concourse' is a good strategy, going to
soon look into doing all that in the 'Dockerfile'
Taylor Silva