We had a hiccup in our CI pipeline regarding this feature. Will update as soon we have it.

Sent from my iPhone

Any update on this?

We have submitted a pull request to resolve this issue. Seems the vSphere manifest generation is lagging a bit. https://github.com/cloudfoundry/cf-release/pull/795

Yes it currently uses outside ruby to generate ERB templates for the jobs.
Not all CPIs include a ruby so we cannot rely on included one.

On Wed, Sep 23, 2015 at 9:51 AM, Dr Nic Williams <drnicwilliams(a)gmail.com>
wrote:

To confirm: bosh-init has a dependency outside of its own binary and
dependencies inside cpi releases?




On Wed, Sep 23, 2015 at 9:45 AM, Lomov Alexander <
alexander.lomov(a)altoros.com> wrote:

Hi, all.

I think that you should know this problem: you shouldn’t run bosh-init
with Ruby 1.9.3 installed on your VM. The problem is that bosh-init uses
host ruby to render era templates from bosh releases that are designed to
run with Ruby 2.0+.

I have created a PR with detailed description for this issue:
https://github.com/cloudfoundry/bosh-init/pull/46

Best wishes,
Alex L.

To confirm: bosh-init has a dependency outside of its own binary and dependencies inside cpi releases?

On Wed, Sep 23, 2015 at 9:45 AM, Lomov Alexander
<alexander.lomov(a)altoros.com> wrote:

Hi, all.
I think that you should know this problem: you shouldn’t run bosh-init with Ruby 1.9.3 installed on your VM. The problem is that bosh-init uses host ruby to render era templates from bosh releases that are designed to run with Ruby 2.0+.
I have created a PR with detailed description for this issue: https://github.com/cloudfoundry/bosh-init/pull/46
Best wishes,
Alex L.

Hi, all.

I think that you should know this problem: you shouldn’t run bosh-init with Ruby 1.9.3 installed on your VM. The problem is that bosh-init uses host ruby to render era templates from bosh releases that are designed to run with Ruby 2.0+.

I have created a PR with detailed description for this issue: https://github.com/cloudfoundry/bosh-init/pull/46

Best wishes,
Alex L.

FYI...we have since upgraded to v217 as well.

We made a little more progress on this and have been able to get a successful deployment with the drs_rules section in our manifest, but the rules are not being applied on the VMWare side. Here is our current resource_pool configuration:

https://raw.githubusercontent.com/coryjett/Cloud-Foundry-DRS/master/RPConfig.MD

```
- cloud_properties:
cpu: 2
disk: 32768
ram: 16384
datacenters:
- name: DC2
clusters:
- 'PaaS POC': {resource_pool: Resources}
drs_rules:
- name: separate-dea-nodes-rule
type: separate_vms
env:
bosh:
password: REDACTED
name: runner_z2
network: cf2
stemcell:
name: bosh-vsphere-esxi-ubuntu-trusty-go_agent
version: latest
```

We recently accepted PR that had some unintentional stricter verification.
To properly fix the issue we are pushing
https://www.pivotaltracker.com/story/show/102530088 through the CI. This
story will allow bosh ssh to trust expected host public key automatically.
Older CLI should continue to behave as it did while the fix goes through
the CI.

Are bosh-lite users supposed to be bringing custom SSL certs into

bosh-lite?

This features relates to SSH, not SSL.

On Mon, Sep 21, 2015 at 3:05 PM, Jim Park <spark(a)pivotal.io> wrote:

It's this commit:
https://github.com/cloudfoundry/bosh/commit/34eb5dce581167082af43d69c0bf38a1e263cd7b

This was put in as a precursor to later allow Director to supply host
fingerprints for validation.

For now, it causes extra burden.

CloudOps gets around it by using this:

○ → type bosh
bosh is a function
bosh ()
{
if [ "$1" = ssh ]; then
shift;
set ssh --strict_host_key_checking no "$@";
fi;
command bosh "$@"
}

This is a stand in until the full checking behavior is implemented.


Jim

On Mon, Sep 21, 2015 at 2:36 PM Dr Nic Williams <drnic(a)starkandwayne.com>
wrote:

When I deploy microbosh now & bosh-lite, no longer does `bosh ssh` just
work. Instead you get:

No ECDSA host key is known for 10.10.1.11 and you have requested strict
checking.


But I didn't "requested strict checking" at all. How do I use `bosh ssh`
without requiring the `--strict_host_key_checking no` flag?

Are bosh-lite users supposed to be bringing custom SSL certs into
bosh-lite? Doesn't sounds like a common use case - can `bosh ssh` please go
back to "just working" if the bosh doesn't have custom SSL installed?

Or at least remove "you have requested strict checking" from the error as
I didn't request it :)


Nic

--
Dr Nic Williams
Stark & Wayne LLC - consultancy for Cloud Foundry users
http://drnicwilliams.com
http://starkandwayne.com
cell +1 (415) 860-2185
twitter @drnic

It's this commit:
https://github.com/cloudfoundry/bosh/commit/34eb5dce581167082af43d69c0bf38a1e263cd7b

This was put in as a precursor to later allow Director to supply host
fingerprints for validation.

For now, it causes extra burden.

CloudOps gets around it by using this:

○ → type bosh
bosh is a function
bosh ()
{
if [ "$1" = ssh ]; then
shift;
set ssh --strict_host_key_checking no "$@";
fi;
command bosh "$@"
}

This is a stand in until the full checking behavior is implemented.


Jim

On Mon, Sep 21, 2015 at 2:36 PM Dr Nic Williams <drnic(a)starkandwayne.com>
wrote:

When I deploy microbosh now & bosh-lite, no longer does `bosh ssh` just
work. Instead you get:

No ECDSA host key is known for 10.10.1.11 and you have requested strict
checking.


But I didn't "requested strict checking" at all. How do I use `bosh ssh`
without requiring the `--strict_host_key_checking no` flag?

Are bosh-lite users supposed to be bringing custom SSL certs into
bosh-lite? Doesn't sounds like a common use case - can `bosh ssh` please go
back to "just working" if the bosh doesn't have custom SSL installed?

Or at least remove "you have requested strict checking" from the error as
I didn't request it :)


Nic

--
Dr Nic Williams
Stark & Wayne LLC - consultancy for Cloud Foundry users
http://drnicwilliams.com
http://starkandwayne.com
cell +1 (415) 860-2185
twitter @drnic

When I deploy microbosh now & bosh-lite, no longer does `bosh ssh` just
work. Instead you get:

No ECDSA host key is known for 10.10.1.11 and you have requested strict
checking.


But I didn't "requested strict checking" at all. How do I use `bosh ssh`
without requiring the `--strict_host_key_checking no` flag?

Are bosh-lite users supposed to be bringing custom SSL certs into
bosh-lite? Doesn't sounds like a common use case - can `bosh ssh` please go
back to "just working" if the bosh doesn't have custom SSL installed?

Or at least remove "you have requested strict checking" from the error as I
didn't request it :)


Nic

--
Dr Nic Williams
Stark & Wayne LLC - consultancy for Cloud Foundry users
http://drnicwilliams.com
http://starkandwayne.com
cell +1 (415) 860-2185
twitter @drnic

Sorry again.

Forget all about this problem. I was using an outdated version of bosh workspace and this did not checkout the latest release into releases directory. Instead it did remain in v5 state. After update of bosh workspace to v 0.9.2 everything works fine.

Regards,
Stephan


Von: Stephan Klevenz
Antworten an: "Discussions about the Cloud Foundry BOSH project."
Datum: Montag, 21. September 2015 09:44
An: "Discussions about the Cloud Foundry BOSH project."
Betreff: [cf-bosh] Re: Re: Upload of admin ui new boshrelease to S3

Sorry for confusing message.

I mean this:

https://admin-ui-boshrelease.s3.amazonaws.com/boshrelease-admin-ui-5.tgz (HTTP 200)
https://admin-ui-boshrelease.s3.amazonaws.com/boshrelease-admin-ui-6.tgz (HTTP 403)

I am deploying the admin UI using bosh workspaces [1]. Version 5 works fine, but if I call 'bosh prepare deployment' for version 6 then it fails. I assume v6 is not available in S3.

Regards,
Stephan

[1] https://github.com/cloudfoundry-incubator/bosh-workspace


Von: Dmitriy Kalinin
Antworten an: "Discussions about the Cloud Foundry BOSH project."
Datum: Freitag, 18. September 2015 18:28
An: "Discussions about the Cloud Foundry BOSH project."
Betreff: [cf-bosh] Re: Upload of admin ui new boshrelease to S3

It would be nice to have this release also available in S3 as documented here [2]

I am not sure what you mean by that. If bosh.io<http://bosh.io> picked it up that means everything that was needed was uploaded to correct places.



On Fri, Sep 18, 2015 at 5:05 AM, Klevenz, Stephan <stephan.klevenz(a)sap.com<mailto:stephan.klevenz(a)sap.com>> wrote:
Hi,

The admin-ui boshrelease has created a new version (v6) which can be manual downloaded from here: [1]

It would be nice to have this release also available in S3 as documented here [2]. I don't have credentials and want ask someone else for doing this.

Thanks and Regards,
Stephan


[1] https://bosh.io/d/github.com/cloudfoundry-community/admin-ui-boshrelease
[2] https://github.com/cloudfoundry-community/admin-ui-boshrelease#create-new-final-release

Sorry for confusing message.

I mean this:

https://admin-ui-boshrelease.s3.amazonaws.com/boshrelease-admin-ui-5.tgz (HTTP 200)
https://admin-ui-boshrelease.s3.amazonaws.com/boshrelease-admin-ui-6.tgz (HTTP 403)

I am deploying the admin UI using bosh workspaces [1]. Version 5 works fine, but if I call 'bosh prepare deployment' for version 6 then it fails. I assume v6 is not available in S3.

Regards,
Stephan

[1] https://github.com/cloudfoundry-incubator/bosh-workspace


Von: Dmitriy Kalinin
Antworten an: "Discussions about the Cloud Foundry BOSH project."
Datum: Freitag, 18. September 2015 18:28
An: "Discussions about the Cloud Foundry BOSH project."
Betreff: [cf-bosh] Re: Upload of admin ui new boshrelease to S3

It would be nice to have this release also available in S3 as documented here [2]

I am not sure what you mean by that. If bosh.io<http://bosh.io> picked it up that means everything that was needed was uploaded to correct places.



On Fri, Sep 18, 2015 at 5:05 AM, Klevenz, Stephan <stephan.klevenz(a)sap.com<mailto:stephan.klevenz(a)sap.com>> wrote:
Hi,

The admin-ui boshrelease has created a new version (v6) which can be manual downloaded from here: [1]

It would be nice to have this release also available in S3 as documented here [2]. I don't have credentials and want ask someone else for doing this.

Thanks and Regards,
Stephan


[1] https://bosh.io/d/github.com/cloudfoundry-community/admin-ui-boshrelease
[2] https://github.com/cloudfoundry-community/admin-ui-boshrelease#create-new-final-release

There was a change recently merged in and is going through the CI which adds support for IAM instance profiles. This allows CPI to retrieve credentials automatically when necessary. I'll update this thread when it's available to use (next week I believe).

Sent from my iPhone

Inline

Sent from my iPhone

On Sep 19, 2015, at 3:07 PM, Christopher Ferris <chris.ferris(a)gmail.com> wrote:

Dmitri wrote: "When we do get to a point when it becomes a priority we will definitely share a proposal on bosh-notes with a community."

We aren't asking for giggles.

That quote is about *replacing* monit with something else, not about upgrading monit, which is what PR includes.

As Matt said, in comments, we are running into issues that need to be worked around. Hence, it is a priority for us, and likely for those who have submitted PRs and issues.

Well understood, so I'm asking for help to confirm in a real environment if monit 5.2.5 solves your problem. There is no way for us to know if new updates solve your problem and I'd like to avoid bumping this dependency without knowing that it will actually fix the problem. If you need help building a stemcell with updated monit, I can help with that.

AGPL can indeed be problematic, but I don't think we should discount it out of hand. The way monit is exposed and used in CF/BOSH with GPL was and is fine, so, copy-left isn't affecting the CF developed code/licensing. I suspect the same could be said for AGPL. Also, unless we or a user of BOSH changes the monit code, there's also no issue.

I suggest that we engage real lawyers to figure a way out of this issue; because as Matt has indicated, it is a problem/priority for some of us.

Matt has been trying to get the issue some attention. What do we need to do to get the priority discussion going in the BOSH PMC?

As mentioned in the thread once it's confirmed which version of monit resolves your problem (and hopefully doesn't introduce other problems) we can upgrade. If it's 5.2.5 great, if it's higher we'll have to involve CFF legal to give us thumbs up.

Thanks,

Chris

Sent from my iPhone

On Sep 19, 2015, at 3:11 PM, Dmitriy Kalinin <dkalinin(a)pivotal.io> wrote:

inline

Sent from my iPhone

On Sep 19, 2015, at 7:59 AM, Matthew Sykes <matthew.sykes(a)gmail.com> wrote:

The monit used in the standard stem cells is ancient and there are two PRs to update it opened against bosh. I've been trying to understand what's going on by making comments on one of the PRs but I think a discussion would be easier here.

Can someone please explain why we a bump to monit 5.2.5 is not something that can just be done and tested through the existing bosh pipeline?

Existing bosh pipeline does very minimal testing of monit interoperability, partly because there is no dedicated test suite that test all kinds of cases. With changes that may affect all releases in unexpected ways, we typically try to get different teams to test the change before it's pulled into bosh. (Example: when we tried to properly wait for monit to stop, we didn't pull in that change because cf-release jobs started failing when nfs client was used. We will pull that change eventually when nfs is removed as a default from cf-release.)

It would be nice to have a test suite that just runs all kinds of releases against bosh for similar cases but we have not invested time in that yet.

What I suggested in one of the PR is for the team that's seeing an issue with monit 5.2.4 to build a stemcell with 5.2.5 and confirm that the issue is gone and doesn't cause any other side effects running in that environment. We don't see that issue in our environments so we cannot verify that bump would help. Since update to monit may introduce unrelated problems imho this is the quickest way to verify that bump is helpful.

Can someone please explain why moving beyond 5.2.5 is not possible? The only thing I've seen referenced is "license issues"; quite nebulous. I believe there was a move from GPLv3 to AGPL somewhere along the way but I'm not sure of the significance of that given how monit is used.

Agpl as I understand is on a lot of companies blacklists. If 5.2.5 update doesn't help the issue seen in that environment, we can spend time with CF Foundation figuring out if having monit being agpl is acceptable.

Finally, there were comments on PR #937 implying that Bosh wants to replace monit with something home grown. I have no issues with this but if it's going to be used as a reason not to stay current with software (the monit we're using is 4 years old), I feel like a proposal should at least be floated so outside contributors are aware. It's hard to help when the direction is not communicated.

Monit replacement ideas are just a hallway conversations.

We are not planning to replace monit any time soon due to other competing priorities like links, azs, stemcell hardening, backup, etc. When we do get to a point when it becomes a priority we will definitely share a proposal on bosh-notes with a community.

We are being conservative in how we bump monit since typically it affects all releases and figuring intricacies of monit especially when it's different versions is not a fun/productive activity.

Thanks.

--
Matthew Sykes
matthew.sykes(a)gmail.com

Dmitri wrote: "When we do get to a point when it becomes a priority we will definitely share a proposal on bosh-notes with a community."

We aren't asking for giggles.

As Matt said, in comments, we are running into issues that need to be worked around. Hence, it is a priority for us, and likely for those who have submitted PRs and issues.

AGPL can indeed be problematic, but I don't think we should discount it out of hand. The way monit is exposed and used in CF/BOSH with GPL was and is fine, so, copy-left isn't affecting the CF developed code/licensing. I suspect the same could be said for AGPL. Also, unless we or a user of BOSH changes the monit code, there's also no issue.

I suggest that we engage real lawyers to figure a way out of this issue; because as Matt has indicated, it is a problem/priority for some of us.

Matt has been trying to get the issue some attention. What do we need to do to get the priority discussion going in the BOSH PMC?

Thanks,

Chris



Sent from my iPhone

inline

Sent from my iPhone

On Sep 19, 2015, at 7:59 AM, Matthew Sykes <matthew.sykes(a)gmail.com> wrote:

The monit used in the standard stem cells is ancient and there are two PRs to update it opened against bosh. I've been trying to understand what's going on by making comments on one of the PRs but I think a discussion would be easier here.

Can someone please explain why we a bump to monit 5.2.5 is not something that can just be done and tested through the existing bosh pipeline?

Existing bosh pipeline does very minimal testing of monit interoperability, partly because there is no dedicated test suite that test all kinds of cases. With changes that may affect all releases in unexpected ways, we typically try to get different teams to test the change before it's pulled into bosh. (Example: when we tried to properly wait for monit to stop, we didn't pull in that change because cf-release jobs started failing when nfs client was used. We will pull that change eventually when nfs is removed as a default from cf-release.)

It would be nice to have a test suite that just runs all kinds of releases against bosh for similar cases but we have not invested time in that yet.

What I suggested in one of the PR is for the team that's seeing an issue with monit 5.2.4 to build a stemcell with 5.2.5 and confirm that the issue is gone and doesn't cause any other side effects running in that environment. We don't see that issue in our environments so we cannot verify that bump would help. Since update to monit may introduce unrelated problems imho this is the quickest way to verify that bump is helpful.

Can someone please explain why moving beyond 5.2.5 is not possible? The only thing I've seen referenced is "license issues"; quite nebulous. I believe there was a move from GPLv3 to AGPL somewhere along the way but I'm not sure of the significance of that given how monit is used.

Agpl as I understand is on a lot of companies blacklists. If 5.2.5 update doesn't help the issue seen in that environment, we can spend time with CF Foundation figuring out if having monit being agpl is acceptable.

Finally, there were comments on PR #937 implying that Bosh wants to replace monit with something home grown. I have no issues with this but if it's going to be used as a reason not to stay current with software (the monit we're using is 4 years old), I feel like a proposal should at least be floated so outside contributors are aware. It's hard to help when the direction is not communicated.

Monit replacement ideas are just a hallway conversations.

We are not planning to replace monit any time soon due to other competing priorities like links, azs, stemcell hardening, backup, etc. When we do get to a point when it becomes a priority we will definitely share a proposal on bosh-notes with a community.

We are being conservative in how we bump monit since typically it affects all releases and figuring intricacies of monit especially when it's different versions is not a fun/productive activity.

Thanks.

--
Matthew Sykes
matthew.sykes(a)gmail.com

The monit used in the standard stem cells is ancient and there are two PRs
to update it opened against bosh. I've been trying to understand what's
going on by making comments on one of the PRs but I think a discussion
would be easier here.

Can someone please explain why we a bump to monit 5.2.5 is not something
that can just be done and tested through the existing bosh pipeline?

Can someone please explain why moving beyond 5.2.5 is not possible? The
only thing I've seen referenced is "license issues"; quite nebulous. I
believe there was a move from GPLv3 to AGPL somewhere along the way but I'm
not sure of the significance of that given how monit is used.

Finally, there were comments on PR #937 implying that Bosh wants to replace
monit with something home grown. I have no issues with this but if it's
going to be used as a reason not to stay current with software (the monit
we're using is 4 years old), I feel like a proposal should at least be
floated so outside contributors are aware. It's hard to help when the
direction is not communicated.

Thanks.

--
Matthew Sykes
matthew.sykes(a)gmail.com

Hi,

How can AWS temporary security credentials be used with bosh in place of the access_key_id and secret_access_key? Reviewing manifests and documentation, I find no mention of aws_session_token. How would bosh refresh the token? Does an IAM role on the instance make it work?
I'm just diving into the AWS identity and access area. A kickstart in the right direction, much appreciated.

(I've successfully deployed bosh/cf in an AWS regular account. I am now switching to a federated and temporary security creds environment.)

I got this working. I had to do several things:

1. I had to change the default security groups assigned to the server vm so that it could be accessed by the client vm. Seems a bit odd to me that I couldn't figure out a way to just "add to" the list of security groups that are automatically applied, I had to explicitly specify all of them plus my additions.

2. When setting the property to use on the client, I had to use the hostname that was allocated via Elastic IP, not the ip address. This leveraged the fact that the public hostname created via AWS Elastic IP actually resolves to the internal ip address inside AWS. This way I didn't have to open my subnet to the outside world.