Closed jdeppe-pivotal closed 8 years ago
Hi there!
We use Pivotal Tracker to provide visibility into what our team is working on. A story for this issue has been automatically created.
The current status is as follows:
This comment, as well as the labels on the issue, will be automatically updated as the status in Tracker changes.
Could you include the build plan that didn't work?
Sure:
- name: deploy-releases
serial: true
plan:
- put: gf1-lock
params:
acquire: true
- put: gf1-lock
params:
acquire: true
- aggregate:
- get: cf-gemfire-cli
trigger: true
passed:
- cli-unit-tests
- get: testing-release
trigger: true
passed:
- build-testing-release
- get: testing-release-version
passed:
- build-testing-release
- get: gemfire-release
trigger: true
passed:
- build-gemfire-release
- get: gemfire-release-version
passed:
- build-gemfire-release
- get: broker-release
trigger: true
passed:
- build-broker-release
- get: broker-release-version
trigger: true
passed:
- build-broker-release
- get: broker-registrar-release
trigger: true
passed:
- build-broker-registrar-release
- get: broker-registrar-release-version
passed:
- build-broker-registrar-release
- get: cf-gemfire-ci
- task: build
privileged: true
file: cf-gemfire-ci/concourse/cf-gemfire-testing/deploy-releases.yml
ensure:
do:
put: gf1-lock
params:
release: gf1-lock
put: gf1-lock
params:
release: gf1-lock
You'll run into problems with having the same step name multiple times. If you're getting the same lock twice you'll want to name them differently so you can release the individually acquired ones, like so:
- put: lock-1
resource: gf1-lock
params: {acquire: true}
- put: lock-2
resource: gf1-lock
params: {acquire: true}
# ...
- put: release-lock-1
resource: gf1-lock
params: {release: lock-1}
- put: release-lock-2
resource: gf1-lock
params: {release: lock-2}
This doesn't matter for the single-lock case since at that point there's no name conflict. Technically there's weirdness since the acquire
and release
steps often have the same name for terseness' sake, but it doesn't become an issue until you have multiple locks.
Thanks for that - it certainly improves the clarity. However, the problem still remains. Initially I had hoped that it would be fixed as I thought that each put
element would exist in its own container and thus there would be no conflicts. I guess that it's only the resource itself that exists in a separate (single) container regardless of how many times it my be referenced by uniquely named puts.
No, you're correct; each put is its own container. So it still failed with the config I suggested? Can you post more info (screenshots/pipeline config)? That should totally work.
On Mon, Sep 21, 2015, 9:18 AM Jens Deppe notifications@github.com wrote:
Thanks for that - it certainly improves the clarity. However, the problem still remains. Initially I had hoped that it would be fixed as I thought that each put element would exist in its own container and thus there would be no conflicts. I guess that it's only the resource itself that exists in a separate (single) container regardless of how many times it my be referenced by uniquely named puts.
— Reply to this email directly or view it on GitHub https://github.com/concourse/pool-resource/issues/6#issuecomment-142032275 .
Here is the job definition:
- name: deploy-releases
serial: true
plan:
- put: deploy-acquire-lock-1
resource: gf1-lock
params:
acquire: true
- put: deploy-acquire-lock-2
resource: gf1-lock
params:
acquire: true
- aggregate:
- get: cf-gemfire-cli
passed:
- cli-unit-tests
trigger: true
- get: gemfire-release
trigger: true
passed:
- build-gemfire-release
- get: gemfire-release-version
passed:
- build-gemfire-release
- get: broker-release
trigger: true
passed:
- build-broker-release
- get: broker-release-version
trigger: true
passed:
- build-broker-release
- get: broker-registrar-release
trigger: true
passed:
- build-broker-registrar-release
- get: broker-registrar-release-version
passed:
- build-broker-registrar-release
- get: cf-gemfire-ci
- task: build
privileged: true
file: cf-gemfire-ci/concourse/cf-gemfire-testing/deploy-releases.yml
ensure:
do:
- put: deploy-release-lock-1
resource: gf1-lock
params:
release: gf1-lock
- put: deploy-release-lock-2
resource: gf1-lock
params:
release: gf1-lock
The error for deploy-release-lock-1
is:
error releasing lock: open /tmp/build/put/gf1-lock/name: no such file or directory
Also attached is a screenshot for the acquire steps
Your release config needs to say release: deploy-acquire-lock-1
and release: deploy-acquire-lock-2
respectively, to refer to the locks acquired earlier on.
Of course! No surprise that it was EBCAK after all. It would be nice if the examples would be a little more verbose so as to leave less room for error :). Thanks for the help.
Updated the docs!
Hi,
I have a sequence of jobs in my pipeline say Job-1 and Job2. I was able to acquire two locks in Job1. I want to release the locks in job2. Getting the below error while releasing the lock.Could you please suggest how to resolve it. It works fine if aquire and release are part of one job.
error releasing lock: open /tmp/build/put/lock-1/name
Below is the pipeline
jobs:
Within a single task I'd like to be able to grab more than one lock from a pool. It seems that I am able to acquire multiple locks (say two), but when releasing them, the second one produces this error:
error releasing lock: open /tmp/build/put/gf1-lock/name: no such file or directory
. I'm assuming that the acquired locks also didn't work correctly and probably overwrote each other.