On Thu, Jun 15, 2017 at 06:04 Marek Glinkowski <mglina67(a)gmail.com> wrote:

Hi :)

I need more help than request thread.
I just finish http://mariash.github.io/learn-bosh/#introduction tutorial.
I closed my Linux and when I back I have error :
Fetching info:
Performing request GET 'https://192.168.50.6:25555/info':
Performing GET request:
Retry: Get https://192.168.50.6:25555/info: dial tcp
192.168.50.6:25555: getsockopt: connection refused

Exit code 1

Could someone please help me what can I do with this error ? I am using
virtualbox-5.1

On 19.05.17, 15:57, "subin alex" <alexkutty19(a)gmail.com> wrote:

Hi Experts,

I am trying to deploy an enterprise application on Openstack instance jumpbox.I have BOSH and CloudFoundry already setup and is working fine.However ,while i am deploying my application services to BOSH,I am getting below error,

Failed: CPI error 'Bosh::Clouds::VMCreationFailed' with message 'VM creation with name 'ZZZZ' failed. Following network IDs are not existing or not accessible from this project: 'XXXX'. Make sure you do not use subnet IDs' in 'create_vm' CPI method (00:00:02)

From the error message,it looks likean issue wherein BOSH is prevented from creating VMs on configured floating IPs on the instance(with id 'XXXX').

But I am unable to narrow down as to where is the exact problem lying.

Can you guys please help me out on this?

Thanks & Regards,
Subin

On 31 May 2017 at 16:40:11, Chip Childers (cchilders(a)cloudfoundry.org)
wrote:

There is no facility to do that, although it would be largely ineffective
anyway. Your message went out to all subscribers on this mailing list
already.

On Wed, May 31, 2017 at 11:29 AM kieran robinson <kieran.robinson7(a)gmail.com>
wrote:

Hi guys,

I just recently made a post however I included a URL which I would like to
be deleted, can this please be done?

Do I have access to do this?

Thanks

--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815

On 5/31/17, 8:53 AM, "Kieran Robinson" <kieran.robinson7(a)gmail.com> wrote:

Hey Guys,

We have been having an issue when trying to deploy logsearch, all VM’s are running within CF and all instances running for log search except `logsearch-for-cloudfoundry` which is failing. We have been unable to figure out this issue after troubleshooting for a few days. I was wondering if anyone else ran into similar issues or would have any guidance on possible solutions.

I have included two logs below, one from the instance which is failing `logsearch-for-cloudfoundry` and the second from the log-api instance running in CF

From logsearch-for-cloudfoundry

```
Exception occurred! Message: Closing connection with traffic controller due to error Details: Error dialing trafficcontroller server: Unauthorized error: You are not authorized. Error: Invalid authorization.
```

From traffic controller

```
Error getting auth data: Post https://uaa.cf.prod-infra.gl1.allstate.com/check_token: remote error: tls: handshake failure
```

On Thu, May 25, 2017 at 7:08 PM, Danny Berger <dberger(a)pivotal.io> wrote:

I agree this could be a bit confusing to both newcomers and others. I'm
not sure renaming the `disk_types.cloud_properties.type` is the correct
solution though. The values in `cloud_properties` should be values which
make sense and are native to the IaaS, so they'll all follow slightly
different conventions and should probably be more consistent to the IaaS
context than a BOSH context. VM types could have a similar discussion.

The persistent_disk_type/disk_types/disk_pool confusion should hopefully
pass with time as everyone consolidates on cloud-config-type manifests.

As a compromise to at least help give the user a better hint, I wonder if
director could say something like `Persistent disk "default" not found
(expected "small", "large", "large_gp2")`.

On Thu, May 18, 2017 at 12:12 PM, Evan Farrar <evanfarrar(a)gmail.com>
wrote:

After helping a BOSH Bootloader user today with deploying a BOSH release
I've realized that there is a small pain point in the BOSH cloud-config
schema that could be resolved.

I suggest we disambiguate the schema and terminology used within BOSH
regarding disk types. There are three closely related things that all
re-use the term “type”: persistent_disk_type, disk_types, and
disk_types.cloud_properties.type. This is a recent issue, because
previously disk_pool was renamed to disk_type to clarify the
relationship between persistent_disk_type and disk_pool.

Problem: A user receives an error message like “Persistent disk
“default” not found.” She must consult her cloud-config for an
acceptable disk type to substitute and may be led to believe that “S4” or
“gp2” would be an acceptable value when in fact the persistent_disk_type
field requires a value from disk_types.name.

Solution: Renaming disk_types.cloud_properties.type to
disk_types.cloud_properties.storage. I have based this on the
terminology used on IaaS pricing documentation, where most use the term
“volume type” or “volume storage” for this piece of information.

I'm curious what others think of this proposal. Please add comments and
suggestions on this document
<https://docs.google.com/document/d/1VpWLtVWOF38Y65WY7Zpqd2qLKYfzE4CkdlufsqbLBbA/edit?usp=sharing>[1]
or via mailing list.


[1] https://docs.google.com/document/d/1VpWLtVWOF38Y65WY7Zpqd2qL
KYfzE4CkdlufsqbLBbA/edit?usp=sharing

--
Danny Berger