This repository has been archived by the owner on Jan 5, 2019. It is now read-only.
bosh-init uses template name as job name #87
Comments
mtekel
added a commit
to alphagov/paas-cf
that referenced
this issue
Jul 18, 2016
Because bosh-init currently uses template name as job name, it renders collectd config to say BOSH host is called `collectd`. Add a prefix that explicitly contains `.bosh.` so that we can see which host are metrics coming from. For more derails see cloudfoundry-attic/bosh-init#87
mtekel
added a commit
to alphagov/paas-cf
that referenced
this issue
Jul 18, 2016
Because bosh-init currently uses template name as job name, it renders collectd config to say concourse host is called `collectd`. Add a prefix that explicitly contains `.concourse.` so that we can see which host are metrics coming from. For more derails see cloudfoundry-attic/bosh-init#87
henrytk
pushed a commit
to alphagov/paas-cf
that referenced
this issue
Jul 18, 2016
Because bosh-init currently uses template name as job name, it renders collectd config to say BOSH host is called `collectd`. Add a prefix that explicitly contains `.bosh.` so that we can see which host are metrics coming from. For more derails see cloudfoundry-attic/bosh-init#87
henrytk
pushed a commit
to alphagov/paas-cf
that referenced
this issue
Jul 18, 2016
Because bosh-init currently uses template name as job name, it renders collectd config to say concourse host is called `collectd`. Add a prefix that explicitly contains `.concourse.` so that we can see which host are metrics coming from. For more derails see cloudfoundry-attic/bosh-init#87
mtekel
added a commit
to alphagov/paas-cf
that referenced
this issue
Jul 19, 2016
Because bosh-init currently uses template name as job name, it renders collectd config to say BOSH host is called `collectd`. Add a prefix that explicitly contains `.bosh.` so that we can see which host are metrics coming from. For more derails see cloudfoundry-attic/bosh-init#87
mtekel
added a commit
to alphagov/paas-cf
that referenced
this issue
Jul 19, 2016
Because bosh-init currently uses template name as job name, it renders collectd config to say concourse host is called `collectd`. Add a prefix that explicitly contains `.concourse.` so that we can see which host are metrics coming from. For more derails see cloudfoundry-attic/bosh-init#87
mtekel
added a commit
to alphagov/paas-cf
that referenced
this issue
Jul 19, 2016
Because bosh-init currently uses template name as job name, it renders collectd config to say BOSH host is called `collectd`. Add a prefix that explicitly contains `.bosh.` so that we can see which host are metrics coming from. For more derails see cloudfoundry-attic/bosh-init#87
mtekel
added a commit
to alphagov/paas-cf
that referenced
this issue
Jul 19, 2016
Because bosh-init currently uses template name as job name, it renders collectd config to say concourse host is called `collectd`. Add a prefix that explicitly contains `.concourse.` so that we can see which host are metrics coming from. For more derails see cloudfoundry-attic/bosh-init#87
|
@mtekel yup looks like a bug. should be instance group's name. |
henrytk
pushed a commit
to alphagov/paas-cf
that referenced
this issue
Jul 20, 2016
Add 0.4 release of our paas-collectd-boshrelease to BOSH. Send metrics to shared deployment graphite server. The initial reason why we used fork was that we could add custom tags and pin our deployment to these tags. Now, because bosh-init can only consume tarballs (you can't upload a release to bosh-init like you can to BOSH), I had to create a dev-release tarbal (using standard bosh-cli way bosh create release --with-tarball --force --version 0.4, more documentation about bosh releases: https://bosh.io/docs/create-release.html#dev-release-release). I have created the tarballs from the same code as is tagged. That is, 0.4 release is created from code that's tagged as 0.4. It seemed to me that a good place to put the release tarball was in github release. This practice is also used in some CF repositories (e.g. diego). We have a spike to analyse our situation with releases completely, but we did not want to block this story on it (#115142265 - see comments in the story). In the future, we can easily move the release location to elsewhere and we can change the way to build the releases. Because bosh-init currently uses template name as job name[1], it renders collectd config to say BOSH host is called `collectd`. Add a prefix that explicitly contains `bosh_` so that we can see which host are metrics coming from. [1] cloudfoundry-attic/bosh-init#87
henrytk
pushed a commit
to alphagov/paas-cf
that referenced
this issue
Jul 20, 2016
Add 0.4 release of our paas-collectd-boshrelease to BOSH. Send metrics to shared deployment graphite server. The initial reason why we used fork was that we could add custom tags and pin our deployment to these tags. Now, because bosh-init can only consume tarballs (you can't upload a release to bosh-init like you can to BOSH), I had to create a dev-release tarbal (using standard bosh-cli way bosh create release --with-tarball --force --version 0.4, more documentation about bosh releases: https://bosh.io/docs/create-release.html#dev-release-release). I have created the tarballs from the same code as is tagged. That is, 0.4 release is created from code that's tagged as 0.4. It seemed to me that a good place to put the release tarball was in github release. This practice is also used in some CF repositories (e.g. diego). We have a spike to analyse our situation with releases completely, but we did not want to block this story on it (#115142265 - see comments in the story). In the future, we can easily move the release location to elsewhere and we can change the way to build the releases. Because bosh-init currently uses template name as job name[1], it renders collectd config to say BOSH host is called `collectd`. Add a prefix that explicitly contains `bosh_` so that we can see which host are metrics coming from. [1] cloudfoundry-attic/bosh-init#87
henrytk
pushed a commit
to alphagov/paas-cf
that referenced
this issue
Jul 20, 2016
Add 0.4 release of our paas-collectd-boshrelease to BOSH. Send metrics to shared deployment graphite server. The initial reason why we used fork was that we could add custom tags and pin our deployment to these tags. Now, because bosh-init can only consume tarballs (you can't upload a release to bosh-init like you can to BOSH), I had to create a dev-release tarbal (using standard bosh-cli way bosh create release --with-tarball --force --version 0.4, more documentation about bosh releases: https://bosh.io/docs/create-release.html#dev-release-release). I have created the tarballs from the same code as is tagged. That is, 0.4 release is created from code that's tagged as 0.4. It seemed to me that a good place to put the release tarball was in github release. This practice is also used in some CF repositories (e.g. diego). We have a spike to analyse our situation with releases completely, but we did not want to block this story on it (#115142265 - see comments in the story). In the future, we can easily move the release location to elsewhere and we can change the way to build the releases. Because bosh-init currently uses template name as job name[1], it renders collectd config to say BOSH host is called `collectd`. Add a prefix that explicitly contains `bosh_` so that we can see which host are metrics coming from. [1] cloudfoundry-attic/bosh-init#87
henrytk
added a commit
to alphagov/paas-cf
that referenced
this issue
Jul 20, 2016
Add 0.4 release of our paas-collectd-boshrelease collectd to concourse. This version contains fixes required to be able to run on concourse. The initial reason why we used fork was that we could add custom tags and pin our deployment to these tags. Now, because bosh-init can only consume tarballs (you can't upload a release to bosh-init like you can to BOSH), I had to create a dev-release tarbal (using standard bosh-cli way bosh create release --with-tarball --force --version 0.4, more documentation about bosh releases: https://bosh.io/docs/create-release.html#dev-release-release). I have created the tarballs from the same code as is tagged. That is, 0.4 release is created from code that's tagged as 0.4. It seemed to me that a good place to put the release tarball was in github release. This practice is also used in some CF repositories (e.g. diego). We have a spike to analyse our situation with releases completely, but we did not want to block this story on it (#115142265 - see comments in the story). In the future, we can easily move the release location to elsewhere and we can change the way to build the releases. Because bosh-init currently uses template name as job name[1], it renders collectd config to say Concourse host is called `collectd`. Add a prefix that explicitly contains `concourse_` so that we can see which host are metrics coming from. [1] cloudfoundry-attic/bosh-init#87
henrytk
pushed a commit
to alphagov/paas-cf
that referenced
this issue
Jul 20, 2016
Add 0.4 release of our paas-collectd-boshrelease to BOSH. Send metrics to shared deployment graphite server. The initial reason why we used fork was that we could add custom tags and pin our deployment to these tags. Now, because bosh-init can only consume tarballs (you can't upload a release to bosh-init like you can to BOSH), I had to create a dev-release tarbal (using standard bosh-cli way bosh create release --with-tarball --force --version 0.4, more documentation about bosh releases: https://bosh.io/docs/create-release.html#dev-release-release). I have created the tarballs from the same code as is tagged. That is, 0.4 release is created from code that's tagged as 0.4. It seemed to me that a good place to put the release tarball was in github release. This practice is also used in some CF repositories (e.g. diego). We have a spike to analyse our situation with releases completely, but we did not want to block this story on it (#115142265 - see comments in the story). In the future, we can easily move the release location to elsewhere and we can change the way to build the releases. Because bosh-init currently uses template name as job name[1], it renders collectd config to say BOSH host is called `collectd`. Add a prefix that explicitly contains `bosh_` so that we can see which host are metrics coming from. [1] cloudfoundry-attic/bosh-init#87
henrytk
added a commit
to alphagov/paas-cf
that referenced
this issue
Jul 20, 2016
Add 0.4 release of our paas-collectd-boshrelease collectd to concourse. This version contains fixes required to be able to run on concourse. The initial reason why we used fork was that we could add custom tags and pin our deployment to these tags. Now, because bosh-init can only consume tarballs (you can't upload a release to bosh-init like you can to BOSH), I had to create a dev-release tarbal (using standard bosh-cli way bosh create release --with-tarball --force --version 0.4, more documentation about bosh releases: https://bosh.io/docs/create-release.html#dev-release-release). I have created the tarballs from the same code as is tagged. That is, 0.4 release is created from code that's tagged as 0.4. It seemed to me that a good place to put the release tarball was in github release. This practice is also used in some CF repositories (e.g. diego). We have a spike to analyse our situation with releases completely, but we did not want to block this story on it (#115142265 - see comments in the story). In the future, we can easily move the release location to elsewhere and we can change the way to build the releases. Because bosh-init currently uses template name as job name[1], it renders collectd config to say Concourse host is called `collectd`. Add a prefix that explicitly contains `concourse_` so that we can see which host are metrics coming from. [1] cloudfoundry-attic/bosh-init#87
henrytk
pushed a commit
to alphagov/paas-cf
that referenced
this issue
Jul 20, 2016
Add 0.4 release of our paas-collectd-boshrelease to BOSH. Send metrics to shared deployment graphite server. The initial reason why we used fork was that we could add custom tags and pin our deployment to these tags. Now, because bosh-init can only consume tarballs (you can't upload a release to bosh-init like you can to BOSH), I had to create a dev-release tarbal (using standard bosh-cli way bosh create release --with-tarball --force --version 0.4, more documentation about bosh releases: https://bosh.io/docs/create-release.html#dev-release-release). I have created the tarballs from the same code as is tagged. That is, 0.4 release is created from code that's tagged as 0.4. It seemed to me that a good place to put the release tarball was in github release. This practice is also used in some CF repositories (e.g. diego). We have a spike to analyse our situation with releases completely, but we did not want to block this story on it (#115142265 - see comments in the story). In the future, we can easily move the release location to elsewhere and we can change the way to build the releases. Because bosh-init currently uses template name as job name[1], it renders collectd config to say BOSH host is called `collectd`. Add a prefix that explicitly contains `bosh_` so that we can see which host are metrics coming from. [1] cloudfoundry-attic/bosh-init#87
henrytk
added a commit
to alphagov/paas-cf
that referenced
this issue
Jul 20, 2016
Add 0.4 release of our paas-collectd-boshrelease collectd to concourse. This version contains fixes required to be able to run on concourse. The initial reason why we used fork was that we could add custom tags and pin our deployment to these tags. Now, because bosh-init can only consume tarballs (you can't upload a release to bosh-init like you can to BOSH), I had to create a dev-release tarbal (using standard bosh-cli way bosh create release --with-tarball --force --version 0.4, more documentation about bosh releases: https://bosh.io/docs/create-release.html#dev-release-release). I have created the tarballs from the same code as is tagged. That is, 0.4 release is created from code that's tagged as 0.4. It seemed to me that a good place to put the release tarball was in github release. This practice is also used in some CF repositories (e.g. diego). We have a spike to analyse our situation with releases completely, but we did not want to block this story on it (#115142265 - see comments in the story). In the future, we can easily move the release location to elsewhere and we can change the way to build the releases. Because bosh-init currently uses template name as job name[1], it renders collectd config to say Concourse host is called `collectd`. Add a prefix that explicitly contains `concourse_` so that we can see which host are metrics coming from. [1] cloudfoundry-attic/bosh-init#87
henrytk
pushed a commit
to alphagov/paas-cf
that referenced
this issue
Jul 20, 2016
Add 0.4 release of our paas-collectd-boshrelease to BOSH. Send metrics to shared deployment graphite server. The initial reason why we used fork was that we could add custom tags and pin our deployment to these tags. Now, because bosh-init can only consume tarballs (you can't upload a release to bosh-init like you can to BOSH), I had to create a dev-release tarbal (using standard bosh-cli way bosh create release --with-tarball --force --version 0.4, more documentation about bosh releases: https://bosh.io/docs/create-release.html#dev-release-release). I have created the tarballs from the same code as is tagged. That is, 0.4 release is created from code that's tagged as 0.4. It seemed to me that a good place to put the release tarball was in github release. This practice is also used in some CF repositories (e.g. diego). We have a spike to analyse our situation with releases completely, but we did not want to block this story on it (#115142265 - see comments in the story). In the future, we can easily move the release location to elsewhere and we can change the way to build the releases. Because bosh-init currently uses template name as job name[1], it renders collectd config to say BOSH host is called `collectd`. Add a prefix that explicitly contains `bosh_` so that we can see which host are metrics coming from. [1] cloudfoundry-attic/bosh-init#87
henrytk
added a commit
to alphagov/paas-cf
that referenced
this issue
Jul 20, 2016
Add 0.4 release of our paas-collectd-boshrelease collectd to concourse. This version contains fixes required to be able to run on concourse. The initial reason why we used fork was that we could add custom tags and pin our deployment to these tags. Now, because bosh-init can only consume tarballs (you can't upload a release to bosh-init like you can to BOSH), I had to create a dev-release tarbal (using standard bosh-cli way bosh create release --with-tarball --force --version 0.4, more documentation about bosh releases: https://bosh.io/docs/create-release.html#dev-release-release). I have created the tarballs from the same code as is tagged. That is, 0.4 release is created from code that's tagged as 0.4. It seemed to me that a good place to put the release tarball was in github release. This practice is also used in some CF repositories (e.g. diego). We have a spike to analyse our situation with releases completely, but we did not want to block this story on it (#115142265 - see comments in the story). In the future, we can easily move the release location to elsewhere and we can change the way to build the releases. Because bosh-init currently uses template name as job name[1], it renders collectd config to say Concourse host is called `collectd`. Add a prefix that explicitly contains `concourse_` so that we can see which host are metrics coming from. [1] cloudfoundry-attic/bosh-init#87
henrytk
pushed a commit
to alphagov/paas-cf
that referenced
this issue
Jul 20, 2016
Add 0.4 release of our paas-collectd-boshrelease to BOSH. Send metrics to shared deployment graphite server. The initial reason why we used fork was that we could add custom tags and pin our deployment to these tags. Now, because bosh-init can only consume tarballs (you can't upload a release to bosh-init like you can to BOSH), I had to create a dev-release tarbal (using standard bosh-cli way bosh create release --with-tarball --force --version 0.4, more documentation about bosh releases: https://bosh.io/docs/create-release.html#dev-release-release). I have created the tarballs from the same code as is tagged. That is, 0.4 release is created from code that's tagged as 0.4. It seemed to me that a good place to put the release tarball was in github release. This practice is also used in some CF repositories (e.g. diego). We have a spike to analyse our situation with releases completely, but we did not want to block this story on it (#115142265 - see comments in the story). In the future, we can easily move the release location to elsewhere and we can change the way to build the releases. Because bosh-init currently uses template name as job name[1], it renders collectd config to say BOSH host is called `collectd`. Add a prefix that explicitly contains `bosh_` so that we can see which host are metrics coming from. [1] cloudfoundry-attic/bosh-init#87
henrytk
added a commit
to alphagov/paas-cf
that referenced
this issue
Jul 20, 2016
Add 0.4 release of our paas-collectd-boshrelease collectd to concourse. This version contains fixes required to be able to run on concourse. The initial reason why we used fork was that we could add custom tags and pin our deployment to these tags. Now, because bosh-init can only consume tarballs (you can't upload a release to bosh-init like you can to BOSH), I had to create a dev-release tarbal (using standard bosh-cli way bosh create release --with-tarball --force --version 0.4, more documentation about bosh releases: https://bosh.io/docs/create-release.html#dev-release-release). I have created the tarballs from the same code as is tagged. That is, 0.4 release is created from code that's tagged as 0.4. It seemed to me that a good place to put the release tarball was in github release. This practice is also used in some CF repositories (e.g. diego). We have a spike to analyse our situation with releases completely, but we did not want to block this story on it (#115142265 - see comments in the story). In the future, we can easily move the release location to elsewhere and we can change the way to build the releases. Because bosh-init currently uses template name as job name[1], it renders collectd config to say Concourse host is called `collectd`. Add a prefix that explicitly contains `concourse_` so that we can see which host are metrics coming from. [1] cloudfoundry-attic/bosh-init#87
henrytk
pushed a commit
to alphagov/paas-cf
that referenced
this issue
Jul 20, 2016
Add 0.4 release of our paas-collectd-boshrelease to BOSH. Send metrics to shared deployment graphite server. The initial reason why we used fork was that we could add custom tags and pin our deployment to these tags. Now, because bosh-init can only consume tarballs (you can't upload a release to bosh-init like you can to BOSH), I had to create a dev-release tarbal (using standard bosh-cli way bosh create release --with-tarball --force --version 0.4, more documentation about bosh releases: https://bosh.io/docs/create-release.html#dev-release-release). I have created the tarballs from the same code as is tagged. That is, 0.4 release is created from code that's tagged as 0.4. It seemed to me that a good place to put the release tarball was in github release. This practice is also used in some CF repositories (e.g. diego). We have a spike to analyse our situation with releases completely, but we did not want to block this story on it (#115142265 - see comments in the story). In the future, we can easily move the release location to elsewhere and we can change the way to build the releases. Because bosh-init currently uses template name as job name[1], it renders collectd config to say BOSH host is called `collectd`. Add a prefix that explicitly contains `bosh_` so that we can see which host are metrics coming from. [1] cloudfoundry-attic/bosh-init#87
henrytk
added a commit
to alphagov/paas-cf
that referenced
this issue
Jul 20, 2016
Add 0.4 release of our paas-collectd-boshrelease collectd to concourse. This version contains fixes required to be able to run on concourse. The initial reason why we used fork was that we could add custom tags and pin our deployment to these tags. Now, because bosh-init can only consume tarballs (you can't upload a release to bosh-init like you can to BOSH), I had to create a dev-release tarbal (using standard bosh-cli way bosh create release --with-tarball --force --version 0.4, more documentation about bosh releases: https://bosh.io/docs/create-release.html#dev-release-release). I have created the tarballs from the same code as is tagged. That is, 0.4 release is created from code that's tagged as 0.4. It seemed to me that a good place to put the release tarball was in github release. This practice is also used in some CF repositories (e.g. diego). We have a spike to analyse our situation with releases completely, but we did not want to block this story on it (#115142265 - see comments in the story). In the future, we can easily move the release location to elsewhere and we can change the way to build the releases. Because bosh-init currently uses template name as job name[1], it renders collectd config to say Concourse host is called `collectd`. Add a prefix that explicitly contains `concourse_` so that we can see which host are metrics coming from. [1] cloudfoundry-attic/bosh-init#87
mtekel
added a commit
to alphagov/paas-cf
that referenced
this issue
Jul 20, 2016
Add 0.4 release of our paas-collectd-boshrelease to BOSH. Send metrics to shared deployment graphite server. The initial reason why we used fork was that we could add custom tags and pin our deployment to these tags. Now, because bosh-init can only consume tarballs (you can't upload a release to bosh-init like you can to BOSH), I had to create a dev-release tarbal (using standard bosh-cli way bosh create release --with-tarball --force --version 0.4, more documentation about bosh releases: https://bosh.io/docs/create-release.html#dev-release-release). I have created the tarballs from the same code as is tagged. That is, 0.4 release is created from code that's tagged as 0.4. It seemed to me that a good place to put the release tarball was in github release. This practice is also used in some CF repositories (e.g. diego). We have a spike to analyse our situation with releases completely, but we did not want to block this story on it (#115142265 - see comments in the story). In the future, we can easily move the release location to elsewhere and we can change the way to build the releases. Because bosh-init currently uses template name as job name[1], it renders collectd config to say BOSH host is called `collectd`. Add a prefix that explicitly contains `bosh_` so that we can see which host are metrics coming from. [1] cloudfoundry-attic/bosh-init#87
mtekel
pushed a commit
to alphagov/paas-cf
that referenced
this issue
Jul 20, 2016
Add 0.4 release of our paas-collectd-boshrelease collectd to concourse. This version contains fixes required to be able to run on concourse. The initial reason why we used fork was that we could add custom tags and pin our deployment to these tags. Now, because bosh-init can only consume tarballs (you can't upload a release to bosh-init like you can to BOSH), I had to create a dev-release tarbal (using standard bosh-cli way bosh create release --with-tarball --force --version 0.4, more documentation about bosh releases: https://bosh.io/docs/create-release.html#dev-release-release). I have created the tarballs from the same code as is tagged. That is, 0.4 release is created from code that's tagged as 0.4. It seemed to me that a good place to put the release tarball was in github release. This practice is also used in some CF repositories (e.g. diego). We have a spike to analyse our situation with releases completely, but we did not want to block this story on it (#115142265 - see comments in the story). In the future, we can easily move the release location to elsewhere and we can change the way to build the releases. Because bosh-init currently uses template name as job name[1], it renders collectd config to say Concourse host is called `collectd`. Add a prefix that explicitly contains `concourse_` so that we can see which host are metrics coming from. [1] cloudfoundry-attic/bosh-init#87
mtekel
added a commit
to alphagov/paas-cf
that referenced
this issue
Jul 20, 2016
Add 0.4 release of our paas-collectd-boshrelease to BOSH. Send metrics to shared deployment graphite server. The initial reason why we used fork was that we could add custom tags and pin our deployment to these tags. Now, because bosh-init can only consume tarballs (you can't upload a release to bosh-init like you can to BOSH), I had to create a dev-release tarbal (using standard bosh-cli way bosh create release --with-tarball --force --version 0.4, more documentation about bosh releases: https://bosh.io/docs/create-release.html#dev-release-release). I have created the tarballs from the same code as is tagged. That is, 0.4 release is created from code that's tagged as 0.4. It seemed to me that a good place to put the release tarball was in github release. This practice is also used in some CF repositories (e.g. diego). We have a spike to analyse our situation with releases completely, but we did not want to block this story on it (#115142265 - see comments in the story). In the future, we can easily move the release location to elsewhere and we can change the way to build the releases. Because bosh-init currently uses template name as job name[1], it renders collectd config to say BOSH host is called `collectd`. Add a prefix that explicitly contains `bosh_` so that we can see which host are metrics coming from. [1] cloudfoundry-attic/bosh-init#87
mtekel
pushed a commit
to alphagov/paas-cf
that referenced
this issue
Jul 20, 2016
Add 0.4 release of our paas-collectd-boshrelease collectd to concourse. This version contains fixes required to be able to run on concourse. The initial reason why we used fork was that we could add custom tags and pin our deployment to these tags. Now, because bosh-init can only consume tarballs (you can't upload a release to bosh-init like you can to BOSH), I had to create a dev-release tarbal (using standard bosh-cli way bosh create release --with-tarball --force --version 0.4, more documentation about bosh releases: https://bosh.io/docs/create-release.html#dev-release-release). I have created the tarballs from the same code as is tagged. That is, 0.4 release is created from code that's tagged as 0.4. It seemed to me that a good place to put the release tarball was in github release. This practice is also used in some CF repositories (e.g. diego). We have a spike to analyse our situation with releases completely, but we did not want to block this story on it (#115142265 - see comments in the story). In the future, we can easily move the release location to elsewhere and we can change the way to build the releases. Because bosh-init currently uses template name as job name[1], it renders collectd config to say Concourse host is called `collectd`. Add a prefix that explicitly contains `concourse_` so that we can see which host are metrics coming from. [1] cloudfoundry-attic/bosh-init#87
henrytk
pushed a commit
to alphagov/paas-cf
that referenced
this issue
Jul 21, 2016
Add 0.4 release of our paas-collectd-boshrelease to BOSH. Send metrics to shared deployment graphite server. The initial reason why we used fork was that we could add custom tags and pin our deployment to these tags. Now, because bosh-init can only consume tarballs (you can't upload a release to bosh-init like you can to BOSH), I had to create a dev-release tarbal (using standard bosh-cli way bosh create release --with-tarball --force --version 0.4, more documentation about bosh releases: https://bosh.io/docs/create-release.html#dev-release-release). I have created the tarballs from the same code as is tagged. That is, 0.4 release is created from code that's tagged as 0.4. It seemed to me that a good place to put the release tarball was in github release. This practice is also used in some CF repositories (e.g. diego). We have a spike to analyse our situation with releases completely, but we did not want to block this story on it (#115142265 - see comments in the story). In the future, we can easily move the release location to elsewhere and we can change the way to build the releases. Because bosh-init currently uses template name as job name[1], it renders collectd config to say BOSH host is called `collectd`. Add a prefix that explicitly contains `bosh_` so that we can see which host are metrics coming from. [1] cloudfoundry-attic/bosh-init#87
henrytk
added a commit
to alphagov/paas-cf
that referenced
this issue
Jul 21, 2016
Add 0.4 release of our paas-collectd-boshrelease collectd to concourse. This version contains fixes required to be able to run on concourse. The initial reason why we used fork was that we could add custom tags and pin our deployment to these tags. Now, because bosh-init can only consume tarballs (you can't upload a release to bosh-init like you can to BOSH), I had to create a dev-release tarbal (using standard bosh-cli way bosh create release --with-tarball --force --version 0.4, more documentation about bosh releases: https://bosh.io/docs/create-release.html#dev-release-release). I have created the tarballs from the same code as is tagged. That is, 0.4 release is created from code that's tagged as 0.4. It seemed to me that a good place to put the release tarball was in github release. This practice is also used in some CF repositories (e.g. diego). We have a spike to analyse our situation with releases completely, but we did not want to block this story on it (#115142265 - see comments in the story). In the future, we can easily move the release location to elsewhere and we can change the way to build the releases. Because bosh-init currently uses template name as job name[1], it renders collectd config to say Concourse host is called `collectd`. Add a prefix that explicitly contains `concourse_` so that we can see which host are metrics coming from. [1] cloudfoundry-attic/bosh-init#87
|
I'd guess |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
When you define
Then
<%= name %>in erb template of the mypackage will bemypackageinstead ofmyjob. For example in case of collectd, your VM will send metrics ascollectdinstead ofmyjob. This is quite confusing, especially if you deploy multiple servers with bosh-init and they all end up with same name in their job configs...bosh-init versions 0.0.95 and 0.0.80 - both have this behaviour.
The text was updated successfully, but these errors were encountered: