Date   

Re: Failed to login to Cloud Foundry after upgrading from cfv212 to cfv218

王小锋 <zzuwxf at gmail.com...>
 

Yes,

I added route_registrar and colocated it with cloud_controller_ng, uaa,
hm9000, and loggregator_trafficcontroller jobs.

I login to uaa VM and compare uaa_cf-registrar_ctl located under
/var/vcap/jobs/uaa/bin,
and found that " --register-with-router \" was missed. After added this
line back to uaa_cf-registrar_ctl and restarted uaa using monit, I am able
to login to cf.

Not sure why "--register-with-router " was removed after cf 218 was
deployed using bosh. Any hints?

2016-03-18 13:26 GMT+08:00 Amit Gupta <agupta(a)pivotal.io>:

The UAA component should serve the login.example.com route. Did you
check out the release notes for 218? The first bullet in the important
section mentions how to configure and colocate the route registrar with the
UAA so that it gets the login route.

On Thu, Mar 17, 2016 at 8:33 PM, 王小锋 <zzuwxf(a)gmail.com> wrote:

Hi, there

I am using bosh to upgrade Cloud Foundry from cfv212 to cfv218. The
bosh deployment was successful, but when I try to login to cf, I met the
following error:

the detailed error info is as below, " login.exmaple.com " returns 404
error.

Could this be caused by "login" template removed from the deployment? how
to debug for this kind of error? your help is greatly appreciated, thanks!

ip-10-10-0-118:~/micro$ cf login

VERSION:
6.12.1-56792aa

API endpoint: https://api.example.com

REQUEST: [2016-03-18T03:16:54Z]
GET /v2/info HTTP/1.1
Host: api.example.com
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.12.1-56792aa / linux



RESPONSE: [2016-03-18T03:16:55Z]
HTTP/1.1 200 OK
Content-Length: 496
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Date: Fri, 18 Mar 2016 03:16:59 GMT
Server: nginx
X-Cf-Requestid: 5036d843-0d67-45fa-6f82-ee7eda8825db
X-Content-Type-Options: nosniff
X-Vcap-Request-Id:
6169465d-a01e-4187-4863-d814e1d9131e::a42227d6-9e5e-4411-92e0-48d1dfa75019

{"name":"vcap","build":"2222","support":"http://support.cloudfoundry.com","version":2,"description":"Cloud
Foundry sponsored by Pivotal","authorization_endpoint":"
http://login.example.com","token_endpoint":"https://uaa.example.com
","min_cli_version":null,"min_recommended_cli_version":null,"api_version":"2.36.0","app_ssh_endpoint":"
ssh.example.com:2222
","app_ssh_host_key_fingerprint":null,"logging_endpoint":"wss://
loggregator.example.com:4443","doppler_logging_endpoint":"wss://
doppler.example.com:443"}

REQUEST: [2016-03-18T03:16:55Z]
GET /login HTTP/1.1
Host: login.example.com
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.12.1-56792aa / linux



RESPONSE: [2016-03-18T03:16:55Z]
HTTP/1.1 404 Not Found
Content-Length: 67
Connection: keep-alive
Content-Type: text/plain; charset=utf-8
Date: Fri, 18 Mar 2016 03:17:03 GMT
X-Cf-Requestid: 74e7c059-2735-4553-5d74-6c85d3a6c626
X-Cf-Routererror: unknown_route

404 Not Found: Requested route ('login.example.com') does not exist.

FAILED
Server error, status code: 404, error code: , message:
FAILED
Server error, status code: 404, error code: , message:


Re: [cf-bosh] Re: CF Summit code for Contributors

Amit Kumar Gupta
 

Hey Chip,

Sounds like you're saying we should hold off on signing up as a contributor
if we've submitted a talk and are waiting to hear back on whether it's
accepted. Is there a risk that all the free contributor passes will be
gone by the time the talk acceptance announcements have gone out? If
someone's talk gets rejected *and* they're too late to use the contributor
pass, that'd be unfortunate.

Amit

On Thu, Mar 17, 2016 at 1:58 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

Great! Any info on the rumored post Summit Bosh event?

Mike

On Thu, Mar 17, 2016 at 2:23 PM, Chip Childers <cchilders(a)cloudfoundry.org
wrote:
Hi all,

Registration is open for the upcoming CF Summit North America, and we
have a limited number of free passes for contributors to the project.

This code can be used by anyone that is a contributor to a Cloud Foundry
or BOSH project. We consider contributions to be project leads, dedicated
committers or even if you have sent in a pull request to one of the
projects.

Keep in mind that speakers will get a free pass as well (although speaker
notifications have not gone out yet), so if you submitted and are also a
contributor, hold off until that is done please.

Also - please only register if you do intend to come to the event.

Use of the code is on the honor system...


https://www.cloudfoundry.org/community/summits/program/about/?summitId=10016

Code: CFCONT16
Feel free to reach out to me or to events(a)cloudfoundry.org if you have
any questions.

See you there!

Chip Childers | VP Technology | Cloud Foundry Foundation


Re: Failed to login to Cloud Foundry after upgrading from cfv212 to cfv218

Amit Kumar Gupta
 

The UAA component should serve the login.example.com route. Did you check
out the release notes for 218? The first bullet in the important section
mentions how to configure and colocate the route registrar with the UAA so
that it gets the login route.

On Thu, Mar 17, 2016 at 8:33 PM, 王小锋 <zzuwxf(a)gmail.com> wrote:

Hi, there

I am using bosh to upgrade Cloud Foundry from cfv212 to cfv218. The bosh
deployment was successful, but when I try to login to cf, I met the
following error:

the detailed error info is as below, " login.exmaple.com " returns 404
error.

Could this be caused by "login" template removed from the deployment? how
to debug for this kind of error? your help is greatly appreciated, thanks!

ip-10-10-0-118:~/micro$ cf login

VERSION:
6.12.1-56792aa

API endpoint: https://api.example.com

REQUEST: [2016-03-18T03:16:54Z]
GET /v2/info HTTP/1.1
Host: api.example.com
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.12.1-56792aa / linux



RESPONSE: [2016-03-18T03:16:55Z]
HTTP/1.1 200 OK
Content-Length: 496
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Date: Fri, 18 Mar 2016 03:16:59 GMT
Server: nginx
X-Cf-Requestid: 5036d843-0d67-45fa-6f82-ee7eda8825db
X-Content-Type-Options: nosniff
X-Vcap-Request-Id:
6169465d-a01e-4187-4863-d814e1d9131e::a42227d6-9e5e-4411-92e0-48d1dfa75019

{"name":"vcap","build":"2222","support":"http://support.cloudfoundry.com","version":2,"description":"Cloud
Foundry sponsored by Pivotal","authorization_endpoint":"
http://login.example.com","token_endpoint":"https://uaa.example.com
","min_cli_version":null,"min_recommended_cli_version":null,"api_version":"2.36.0","app_ssh_endpoint":"
ssh.example.com:2222
","app_ssh_host_key_fingerprint":null,"logging_endpoint":"wss://
loggregator.example.com:4443","doppler_logging_endpoint":"wss://
doppler.example.com:443"}

REQUEST: [2016-03-18T03:16:55Z]
GET /login HTTP/1.1
Host: login.example.com
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.12.1-56792aa / linux



RESPONSE: [2016-03-18T03:16:55Z]
HTTP/1.1 404 Not Found
Content-Length: 67
Connection: keep-alive
Content-Type: text/plain; charset=utf-8
Date: Fri, 18 Mar 2016 03:17:03 GMT
X-Cf-Requestid: 74e7c059-2735-4553-5d74-6c85d3a6c626
X-Cf-Routererror: unknown_route

404 Not Found: Requested route ('login.example.com') does not exist.

FAILED
Server error, status code: 404, error code: , message:
FAILED
Server error, status code: 404, error code: , message:


Failed to login to Cloud Foundry after upgrading from cfv212 to cfv218

王小锋 <zzuwxf at gmail.com...>
 

Hi, there

I am using bosh to upgrade Cloud Foundry from cfv212 to cfv218. The bosh
deployment was successful, but when I try to login to cf, I met the
following error:

the detailed error info is as below, " login.exmaple.com " returns 404
error.

Could this be caused by "login" template removed from the deployment? how
to debug for this kind of error? your help is greatly appreciated, thanks!

ip-10-10-0-118:~/micro$ cf login

VERSION:
6.12.1-56792aa

API endpoint: https://api.example.com

REQUEST: [2016-03-18T03:16:54Z]
GET /v2/info HTTP/1.1
Host: api.example.com
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.12.1-56792aa / linux



RESPONSE: [2016-03-18T03:16:55Z]
HTTP/1.1 200 OK
Content-Length: 496
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Date: Fri, 18 Mar 2016 03:16:59 GMT
Server: nginx
X-Cf-Requestid: 5036d843-0d67-45fa-6f82-ee7eda8825db
X-Content-Type-Options: nosniff
X-Vcap-Request-Id:
6169465d-a01e-4187-4863-d814e1d9131e::a42227d6-9e5e-4411-92e0-48d1dfa75019

{"name":"vcap","build":"2222","support":"http://support.cloudfoundry.com","version":2,"description":"Cloud
Foundry sponsored by Pivotal","authorization_endpoint":"
http://login.example.com","token_endpoint":"https://uaa.example.com
","min_cli_version":null,"min_recommended_cli_version":null,"api_version":"2.36.0","app_ssh_endpoint":"
ssh.example.com:2222
","app_ssh_host_key_fingerprint":null,"logging_endpoint":"wss://
loggregator.example.com:4443","doppler_logging_endpoint":"wss://
doppler.example.com:443"}

REQUEST: [2016-03-18T03:16:55Z]
GET /login HTTP/1.1
Host: login.example.com
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.12.1-56792aa / linux



RESPONSE: [2016-03-18T03:16:55Z]
HTTP/1.1 404 Not Found
Content-Length: 67
Connection: keep-alive
Content-Type: text/plain; charset=utf-8
Date: Fri, 18 Mar 2016 03:17:03 GMT
X-Cf-Requestid: 74e7c059-2735-4553-5d74-6c85d3a6c626
X-Cf-Routererror: unknown_route

404 Not Found: Requested route ('login.example.com') does not exist.

FAILED
Server error, status code: 404, error code: , message:
FAILED
Server error, status code: 404, error code: , message:


Re: cf push "stack: unknown"

Daniel Mikusa
 

On Wed, Mar 16, 2016 at 12:38 PM, Sunil Babu <placid.babu(a)gmail.com> wrote:

Hi Dan

Check with the bosh cli options rgd the vms and status check.

On Wed, Mar 16, 2016 at 9:35 PM, Eric Malm <emalm(a)pivotal.io> wrote:

Hi, Dan,

It may be a regression in the CF CLI: in my check against one of the
Diego team environments, that stack field is consistently absent after the
initial push with CLI 6.16.1+924508c-2016-02-26, but
consistently present with 6.14.1+dc6adf6-2015-12-22 (the other version I
had at hand on my system).

Thanks,
Eric

On Wed, Mar 16, 2016 at 8:44 AM, Edward Mikuszewski <
emikuszewski(a)pivotal.io> wrote:

Great question, Dan. I'm curious to this as well - I just assumed it
took some time to report back the status.

On Wed, Mar 16, 2016 at 10:28 AM, Daniel Mikusa <dmikusa(a)pivotal.io>
wrote:

Quick question, when I push an app to CF I get this output at the
bottom after the app starts.

```
requested state: started
instances: 1/1
usage: 256M x 1 instances
urls: sinatra-test-dan.cfapps.io
last uploaded: Wed Mar 16 14:54:50 UTC 2016
stack: unknown
buildpack: https://github.com/cloudfoundry/ruby-buildpack#v1.6.5

state since cpu memory disk
details
#0 running 2016-03-16 10:55:12 AM 0.1% 21M of 256M 68.3M of 1G
```

Anyone know why the stack always reports "unknown"? If I run `cf app`
right after, it will report the stack properly. It only shows up this way
on the initial push.

Versions:
- cf version 6.16.1+924508c-2016-02-26
- cf v231
- diego 0.1454.0
- garden 0.333.0

Thanks,

Dan


--
Ed Mikuszewski *| * <http://www.pivotal.io> *|* Mobile: 646-628-2872
*| *Email: emikuszewski(a)pivotal.io


Re: Reg the upgrade from cf-205 to cf-231

Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM@Cisco) <ngnanase at cisco.com...>
 

Hi Amit

Thanks for your quick reply. Pls let me know in which Vm , should I login to see the compilation logs..

Previously when I did the upgrade, it dint compile the individual packages. Logs below.
Kindly let me know why is it trying to compile individual package now.

---------------------------------------------------------------------------------------
Started preparing package compilation > Finding packages to compile. Done (00:00:00)

Started preparing dns > Binding DNS. Done (00:00:00)



Regards
Nithiyasri

From: Amit Gupta [mailto:agupta(a)pivotal.io]
Sent: Friday, March 18, 2016 5:36 AM
To: Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com>
Cc: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org>; Jayarajan Ramapurath Kozhummal (jayark) <jayark(a)cisco.com>
Subject: Re: Reg the upgrade from cf-205 to cf-231

I'm not sure why it's taking >40 mins to compile some simple go binaries. You may have network issues (compilation jobs taking a long time to download dependencies from BOSH director blobstore, or upload compiled resulting artifacts) or you may need more CPU on your compilation machines. You can try to SSH into the compilation VMs while they're running to see what they're doing over those 40 minutes.

On Thu, Mar 17, 2016 at 7:06 AM, Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>> wrote:
Hi Amit

I was able to do an upgrade of deployment from cf-205 to cf-231 multiple times.
But now, I am getting timeout errors while compiling buildpacks once in rootfs or in buildpack_java or in nginx..
Could you pls help us resolve this error..

Following is the one:

Done compiling packages > buildpack_java/d65c2d20fc067c9995c18d195e0ff117ea9202c0 (00:24:23)
Done compiling packages > rtr/2d7de4f6fc25938c21c5be87174f95583feb14b5 (00:38:22)
Failed compiling packages > rootfs_cflinuxfs2/ac0ba35f1106af81cb735eb56360c6cc924af83a: Timed out waiting for Server `3c04cecc-1308-4da f-8dc5-b9c1924004c3' to be active (00:41:23)
Failed compiling packages > nginx/bf3af6163e13887aacd230bbbc5eff90213ac6af: Timed out waiting for Server `fbbb8647-1415-46d9-92de-d030f 4164b6b' to be active (00:43:31)



Failed compiling packages > cli/b61b75716312df9f4f7c81a17f3a7de456efce71: Timed out waiting for Server `223ec673-b66d-4362-8e27-0859805 2ebe5' to be active (00:44:49)

Error 100: Timed out waiting for Server `3c04cecc-1308-4daf-8dc5-b9c1924004c3' to be active


Regards
Nithiyasri


Re: Using swift as a blobstore in cloud foundry with keystone v3

Gwenn Etourneau
 

This can be nice ! As Bosh support V3 it can be nice that the CC do the
same.
To be able to fully use v3.

On Thu, Mar 17, 2016 at 6:30 PM, Voelz, Marco <marco.voelz(a)sap.com> wrote:

Dear Nicholas,

if desired, we can also do a PR for allowing the CC to connect to Swift
using Keystone v3. A couple of months ago we did the same thing in the
OpenStack CPI. We also have some test envs available where we can validate
the change. What do you think?

Warm regards
Marco

On 16/03/16 18:13, "Nicholas Calugar" <ncalugar(a)pivotal.io> wrote:

Hi Muhammad,

Unfortunately, we don't have an environment using keystone v3. We are
passing the configuration to fog as-is. There are several fixes that have
been made in later releases of fog, for example:

https://github.com/fog/fog/pull/3806

I'll get a story prioritized to upgrade fog to v1.37.0

Thanks,

Nick

On Sun, Mar 13, 2016 at 11:58 PM Altaf, Muhammad <
Muhammada(a)fast.au.fujitsu.com> wrote:

Hi All,

I am trying to configure cloud foundry to use swift on OpenStack. I have
followed the instructions at
https://docs.cloudfoundry.org/deploying/openstack/using_swift_blobstore.html

When used keystone v2, I am able to start my apps on DEA which is good.
However when using keystone V3, I am not able to start my apps. The error I
am getting is:



“FAILED

Server error, status code: 400, error code: 170001, message: Staging
error: failed to stage application:

Error downloading: HTTP status: 401”



Tried to debug by adding some ‘puts’ statements in openstack/core.rb file
and it looks like tokens are being generated successfully so there is no
problem with the authentication. The generated response to auth request
shows that the user has “ResellerAdmin” role as well.



When I look into runner_z1/0 /var/vcap/data/dea_next/tmp/
app-package-download.tgz2016*, I find error saying: “401 Unauthorized:
Temp URL invalid xxxxx”



/var/vcap/sys/log/dea_next/dea_next.log shows some download URLs, and if
I curl those URLs, I get exact same error message. Below are the
fog_connection settings in cloud foundry manifest:



fog_connection: &fog_connection

provider: 'OpenStack'

openstack_username: 'cf-admin2'

openstack_tenant: 'cf2'

openstack_project_name: 'cf2'

openstack_api_key: 'passw0rd'

openstack_auth_url: 'http://<OPENSTACK_IP>:5000/v3/auth/tokens'

openstack_domain_name: 'cf_domain'

openstack_user_domain_name: 'cf_domain'

openstack_temp_url_key: 'b3968d0207b54ece87cccc06515a89d4'





Account has a valid temp_url_key configured. Please see below:

curl -v -X GET
http://SWIFT_IP:SWIFT_PORT/v2/Auth_b34a51e551ec4796a461168c886c734f -H
"X-Auth-Token: TOKEN"

* Hostname was NOT found in DNS cache

* Trying SWIFT_IP...

* Connected to SWIFT_IP (SWIFT_IP) port SWIFT_PORT (#0)

GET /v2/Auth_b34a51e551ec4796a461168c886c734f HTTP/1.1
User-Agent: curl/7.35.0
Host: SWIFT_IP:SWIFT_PORT
Accept: */*
X-Auth-Token: TOKEN
< HTTP/1.1 204 No Content

< Content-Length: 0

< X-Account-Object-Count: 0

< X-Timestamp: 1457918518.21777

< X-Account-Meta-Temp-Url-Key: *b3968d0207b54ece87cccc06515a89d4*

< X-Account-Bytes-Used: 0

< X-Account-Container-Count: 0

< Content-Type: text/plain; charset=utf-8

< Accept-Ranges: bytes

< X-Trans-Id: txfc362c27bdda4355a942a-0056e65d93

< Date: Mon, 14 Mar 2016 06:43:31 GMT

<

* Connection #0 to host SWIFT_IP left intact



Also, I can see that the containers are created on swift, so obviously it
is able to authenticate.

$ openstack container list

+---------------+

| Name |

+---------------+

| cc-buildpacks |

| cc-droplets |

| cc-packages |

| cc-resources |

+---------------+



I would appreciate if someone can help me fixing this issue.



Regards,




*Muhammad Altaf Software Development Engineer Fujitsu Australia Software
Technology Pty Ltd*
14 Rodborough Road, Frenchs Forest NSW 2086, Australia
*T* +61 2 9452 9067 *F* +61 2 9975 2899
Muhammada(a)fast.au.fujitsu.com
fastware.com.au

[image: image001.jpg]
[image: image002.jpg]

Disclaimer

The information in this e-mail is confidential and may contain content
that is subject to copyright and/or is commercial-in-confidence and is
intended only for the use of the above named addressee. If you are not the
intended recipient, you are hereby notified that dissemination, copying or
use of the information is strictly prohibited. If you have received this
e-mail in error, please telephone Fujitsu Australia Software Technology Pty
Ltd on + 61 2 9452 9000 or by reply e-mail to the sender and delete the
document and all copies thereof.

Whereas Fujitsu Australia Software Technology Pty Ltd would not knowingly
transmit a virus within an email communication, it is the receiver’s
responsibility to scan all communication and any files attached for
computer viruses and other defects. Fujitsu Australia Software Technology
Pty Ltd does not accept liability for any loss or damage (whether direct,
indirect, consequential or economic) however caused, and whether by
negligence or otherwise, which may result directly or indirectly from this
communication or any files attached.

If you do not wish to receive commercial and/or marketing email messages
from Fujitsu Australia Software Technology Pty Ltd, please email
unsubscribe(a)fast.au.fujitsu.com


Re: Upcoming extraction of cflinuxfs2 rootfs release from diego-release

Gwenn Etourneau
 

That's nice.
Thanks Eric.

On Fri, Mar 18, 2016 at 8:01 AM, Eric Malm <emalm(a)pivotal.io> wrote:

Dear CF Community,

Over the next few weeks, the Diego and Buildpacks teams will be working
together to extract a new BOSH release for the cflinuxfs2 rootfs/stack out
of the Diego BOSH release. The Buildpacks team has been doing an amazing
job of publishing new rootfs images in response to CVEs, and this
separation will make it easier for all Diego deployment operators to update
to those latest rootfs images without having to update their other
releases. We've already taken advantage of the same kind of separation
between Garden-Linux and Diego when addressing some recent Garden CVEs, and
we're looking forward to having that flexibility with the rootfs image as
well.

Once completed, the release extraction will mean a couple of minor changes
for Diego deployment operators:

- You'll have one more release to upload alongside the Diego,
Garden-Linux, and etcd BOSH releases to deploy your Diego cluster. The
Diego release tarball itself will be much smaller, as it will no longer
include the rootfs image that accounts for about 70% of its current size.
- If you use the spiff-based manifest-generation script in the
diego-release repo to produce your manifest, that's all you'll have to do!
If you're hand-rolling your manifests, you will have one or two BOSH
properties to add or move, and an entry to change in the list of job
templates on the Diego Cell VMs.

We'll call out these changes explicitly in the Diego release notes on
GitHub when the time comes.

Just as we do with the Garden-Linux and etcd releases today, the Diego
team will also attach a recent final cflinuxfs2-rootfs release tarball to
each final Diego release we publish on GitHub, so it will be easy for
consumers to get a validated set of default 'batteries' to plug into Diego.
We'll also work with the CF Release Integration team to make sure that when
the most recent rootfs image passes tests against Diego in their
integration environments, its release version is recorded in the Diego/CF
compatibility record, at
https://github.com/cloudfoundry-incubator/diego-cf-compatibility/blob/master/compatibility-v2.csv
.

If you would like to track our progress, please follow the
'cflinuxfs2-release-extraction' epic in the Diego tracker (
https://www.pivotaltracker.com/epic/show/2395419) and the 'bosh-release'
label in the Buildpacks tracker (
https://www.pivotaltracker.com/n/projects/1042066/search?q=label%3A%22bosh-release%22
).

Thanks,
Eric Malm, CF Runtime Diego PM


Re: Reg the upgrade from cf-205 to cf-231

Amit Kumar Gupta
 

I'm not sure why it's taking >40 mins to compile some simple go binaries.
You may have network issues (compilation jobs taking a long time to
download dependencies from BOSH director blobstore, or upload compiled
resulting artifacts) or you may need more CPU on your compilation
machines. You can try to SSH into the compilation VMs while they're
running to see what they're doing over those 40 minutes.

On Thu, Mar 17, 2016 at 7:06 AM, Nithiyasri Gnanasekaran -X (ngnanase -
TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com> wrote:

Hi Amit



I was able to do an upgrade of deployment from cf-205 to cf-231 multiple
times.

But now, I am getting timeout errors while compiling buildpacks once in
rootfs or in buildpack_java or in nginx..

Could you pls help us resolve this error..



Following is the one:



Done compiling packages >
buildpack_java/d65c2d20fc067c9995c18d195e0ff117ea9202c0 (00:24:23)

Done compiling packages >
rtr/2d7de4f6fc25938c21c5be87174f95583feb14b5 (00:38:22)

Failed compiling packages >
rootfs_cflinuxfs2/ac0ba35f1106af81cb735eb56360c6cc924af83a: Timed out
waiting for Server `3c04cecc-1308-4da
f-8dc5-b9c1924004c3' to be active (00:41:23)

Failed compiling packages >
nginx/bf3af6163e13887aacd230bbbc5eff90213ac6af: Timed out waiting for
Server `fbbb8647-1415-46d9-92de-d030f 4164b6b'
to be active (00:43:31)







Failed compiling packages >
cli/b61b75716312df9f4f7c81a17f3a7de456efce71: Timed out waiting for Server
`223ec673-b66d-4362-8e27-0859805 2ebe5' to be
active (00:44:49)



Error 100: Timed out waiting for Server
`3c04cecc-1308-4daf-8dc5-b9c1924004c3' to be active





Regards

Nithiyasri


Upcoming extraction of cflinuxfs2 rootfs release from diego-release

Eric Malm <emalm@...>
 

Dear CF Community,

Over the next few weeks, the Diego and Buildpacks teams will be working
together to extract a new BOSH release for the cflinuxfs2 rootfs/stack out
of the Diego BOSH release. The Buildpacks team has been doing an amazing
job of publishing new rootfs images in response to CVEs, and this
separation will make it easier for all Diego deployment operators to update
to those latest rootfs images without having to update their other
releases. We've already taken advantage of the same kind of separation
between Garden-Linux and Diego when addressing some recent Garden CVEs, and
we're looking forward to having that flexibility with the rootfs image as
well.

Once completed, the release extraction will mean a couple of minor changes
for Diego deployment operators:

- You'll have one more release to upload alongside the Diego, Garden-Linux,
and etcd BOSH releases to deploy your Diego cluster. The Diego release
tarball itself will be much smaller, as it will no longer include the
rootfs image that accounts for about 70% of its current size.
- If you use the spiff-based manifest-generation script in the
diego-release repo to produce your manifest, that's all you'll have to do!
If you're hand-rolling your manifests, you will have one or two BOSH
properties to add or move, and an entry to change in the list of job
templates on the Diego Cell VMs.

We'll call out these changes explicitly in the Diego release notes on
GitHub when the time comes.

Just as we do with the Garden-Linux and etcd releases today, the Diego team
will also attach a recent final cflinuxfs2-rootfs release tarball to each
final Diego release we publish on GitHub, so it will be easy for consumers
to get a validated set of default 'batteries' to plug into Diego. We'll
also work with the CF Release Integration team to make sure that when the
most recent rootfs image passes tests against Diego in their integration
environments, its release version is recorded in the Diego/CF compatibility
record, at
https://github.com/cloudfoundry-incubator/diego-cf-compatibility/blob/master/compatibility-v2.csv
.

If you would like to track our progress, please follow the
'cflinuxfs2-release-extraction' epic in the Diego tracker (
https://www.pivotaltracker.com/epic/show/2395419) and the 'bosh-release'
label in the Buildpacks tracker (
https://www.pivotaltracker.com/n/projects/1042066/search?q=label%3A%22bosh-release%22
).

Thanks,
Eric Malm, CF Runtime Diego PM


Re: [cf-bosh] CF Summit code for Contributors

Mike Youngstrom
 

Great! Any info on the rumored post Summit Bosh event?

Mike

On Thu, Mar 17, 2016 at 2:23 PM, Chip Childers <cchilders(a)cloudfoundry.org>
wrote:

Hi all,

Registration is open for the upcoming CF Summit North America, and we have
a limited number of free passes for contributors to the project.

This code can be used by anyone that is a contributor to a Cloud Foundry
or BOSH project. We consider contributions to be project leads, dedicated
committers or even if you have sent in a pull request to one of the
projects.

Keep in mind that speakers will get a free pass as well (although speaker
notifications have not gone out yet), so if you submitted and are also a
contributor, hold off until that is done please.

Also - please only register if you do intend to come to the event.

Use of the code is on the honor system...


https://www.cloudfoundry.org/community/summits/program/about/?summitId=10016

Code: CFCONT16
Feel free to reach out to me or to events(a)cloudfoundry.org if you have
any questions.

See you there!

Chip Childers | VP Technology | Cloud Foundry Foundation


CF Summit code for Contributors

Chip Childers <cchilders@...>
 

Hi all,

Registration is open for the upcoming CF Summit North America, and we have
a limited number of free passes for contributors to the project.

This code can be used by anyone that is a contributor to a Cloud Foundry or
BOSH project. We consider contributions to be project leads, dedicated
committers or even if you have sent in a pull request to one of the
projects.

Keep in mind that speakers will get a free pass as well (although speaker
notifications have not gone out yet), so if you submitted and are also a
contributor, hold off until that is done please.

Also - please only register if you do intend to come to the event.

Use of the code is on the honor system...

https://www.cloudfoundry.org/community/summits/program/about/?summitId=10016

Code: CFCONT16
Feel free to reach out to me or to events(a)cloudfoundry.org if you have any
questions.

See you there!

Chip Childers | VP Technology | Cloud Foundry Foundation


Re: Consul on DEA runner machines

Michael Fraenkel <michael.fraenkel@...>
 

Its to support https from CC to DEAs for staging and starting instead of
relying on NATs.

- Michael

On 3/17/16 1:22 PM, Long Nguyen wrote:
Anyone know why consul is running on dea runner machine? it looks like
its for a healthcheck
(https://github.com/cloudfoundry/dea-hm-workspace/blob/c64ee724c68aec04d572d0bfa89703baaf908675/jobs/dea_next/templates/dns_health_check.erb
) but script just exits 0


Re: Consul on DEA runner machines

Amulya Sharma <amulya.sharma@...>
 

Good question Long, I am wondering the same .. also its creating trouble in
resolv.conf

Thanks and Regards
Amulya Sharma


On Thu, Mar 17, 2016 at 10:22 AM, Long Nguyen <long.nguyen11288(a)gmail.com>
wrote:

Anyone know why consul is running on dea runner machine? it looks like its
for a healthcheck (
https://github.com/cloudfoundry/dea-hm-workspace/blob/c64ee724c68aec04d572d0bfa89703baaf908675/jobs/dea_next/templates/dns_health_check.erb
) but script just exits 0


Consul on DEA runner machines

Long Nguyen
 

Anyone know why consul is running on dea runner machine? it looks like its
for a healthcheck (
https://github.com/cloudfoundry/dea-hm-workspace/blob/c64ee724c68aec04d572d0bfa89703baaf908675/jobs/dea_next/templates/dns_health_check.erb
) but script just exits 0


Regarding S3 storage in CF

purushottam hegde
 

Hi,

New to CF. I need to store some large objects in S3 storage. When i bind S3 storage to an app, it gave following binding System ENV.


1. host

2. AccessKey

3. SecretKey


AWS API,Credentials.class has AccessKey and SecretKey, how to set hostname?

If i only set accesskey and Secretkey, it is failing.

pls help


Re: How to minimize VMs used in cf/diego

Eric Malm <emalm@...>
 

Hi, Stanley,

If you're looking to reduce the Diego VM footprint in a dev deployment, you
could consider using the 'colocated_vN' (N=1,2,3) jobs in the manifests
generated by the spiff-based scripts in diego-release. They pack all the
jobs in diego-release (and garden and etcd) onto a single VM, so you could
deploy with 1 instance of colocated_z1 and 0 instances of all other jobs.
If you need more container capacity in that deployment, you can then
increase the instance count of the cell jobs from 0 (you will have one cell
already via the existing colocated job instance).

Also, as a warning, the Diego team doesn't regularly test the colocated-VM
deployment configuration, so it's possible that it may accidentally break
in the future (or even that it's broken now!). So I wouldn't recommend its
use in a production deployment.

I can't speak to the current state of colocatability of the jobs in
cf-release, or to the status of the community cf-boshworkspace project.

Best,
Eric, CF Runtime Diego PM

On Wed, Mar 16, 2016 at 8:33 PM, Stanley Shen <meteorping(a)gmail.com> wrote:

Hello, all

By default, there are about 20 VMs will be used in cf/diego installation.
I am trying to minimize the VM size.

I tried to follow
https://github.com/cloudfoundry-community/cf-boshworkspace but got some
problem.
I create an issue for it but got no response, is this still maintained?

If there are any other documentation about it, or any experience on it?



Reg the upgrade from cf-205 to cf-231

Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM@Cisco) <ngnanase at cisco.com...>
 

Hi Amit

I was able to do an upgrade of deployment from cf-205 to cf-231 multiple times.
But now, I am getting timeout errors while compiling buildpacks once in rootfs or in buildpack_java or in nginx..
Could you pls help us resolve this error..

Following is the one:

Done compiling packages > buildpack_java/d65c2d20fc067c9995c18d195e0ff117ea9202c0 (00:24:23)
Done compiling packages > rtr/2d7de4f6fc25938c21c5be87174f95583feb14b5 (00:38:22)
Failed compiling packages > rootfs_cflinuxfs2/ac0ba35f1106af81cb735eb56360c6cc924af83a: Timed out waiting for Server `3c04cecc-1308-4da f-8dc5-b9c1924004c3' to be active (00:41:23)
Failed compiling packages > nginx/bf3af6163e13887aacd230bbbc5eff90213ac6af: Timed out waiting for Server `fbbb8647-1415-46d9-92de-d030f 4164b6b' to be active (00:43:31)



Failed compiling packages > cli/b61b75716312df9f4f7c81a17f3a7de456efce71: Timed out waiting for Server `223ec673-b66d-4362-8e27-0859805 2ebe5' to be active (00:44:49)

Error 100: Timed out waiting for Server `3c04cecc-1308-4daf-8dc5-b9c1924004c3' to be active


Regards
Nithiyasri


Re: Using swift as a blobstore in cloud foundry with keystone v3

Marco Voelz
 

Dear Nicholas,

if desired, we can also do a PR for allowing the CC to connect to Swift using Keystone v3. A couple of months ago we did the same thing in the OpenStack CPI. We also have some test envs available where we can validate the change. What do you think?

Warm regards
Marco

On 16/03/16 18:13, "Nicholas Calugar" <ncalugar(a)pivotal.io<mailto:ncalugar(a)pivotal.io>> wrote:

Hi Muhammad,

Unfortunately, we don't have an environment using keystone v3. We are passing the configuration to fog as-is. There are several fixes that have been made in later releases of fog, for example:

https://github.com/fog/fog/pull/3806

I'll get a story prioritized to upgrade fog to v1.37.0

Thanks,

Nick

On Sun, Mar 13, 2016 at 11:58 PM Altaf, Muhammad <Muhammada(a)fast.au.fujitsu.com<mailto:Muhammada(a)fast.au.fujitsu.com>> wrote:
Hi All,
I am trying to configure cloud foundry to use swift on OpenStack. I have followed the instructions at https://docs.cloudfoundry.org/deploying/openstack/using_swift_blobstore.html
When used keystone v2, I am able to start my apps on DEA which is good. However when using keystone V3, I am not able to start my apps. The error I am getting is:

“FAILED
Server error, status code: 400, error code: 170001, message: Staging error: failed to stage application:
Error downloading: HTTP status: 401”

Tried to debug by adding some ‘puts’ statements in openstack/core.rb file and it looks like tokens are being generated successfully so there is no problem with the authentication. The generated response to auth request shows that the user has “ResellerAdmin” role as well.

When I look into runner_z1/0 /var/vcap/data/dea_next/tmp/ app-package-download.tgz2016*, I find error saying: “401 Unauthorized: Temp URL invalid xxxxx”

/var/vcap/sys/log/dea_next/dea_next.log shows some download URLs, and if I curl those URLs, I get exact same error message. Below are the fog_connection settings in cloud foundry manifest:

fog_connection: &fog_connection
provider: 'OpenStack'
openstack_username: 'cf-admin2'
openstack_tenant: 'cf2'
openstack_project_name: 'cf2'
openstack_api_key: 'passw0rd'
openstack_auth_url: 'http://<OPENSTACK_IP>:5000/v3/auth/tokens'
openstack_domain_name: 'cf_domain'
openstack_user_domain_name: 'cf_domain'
openstack_temp_url_key: 'b3968d0207b54ece87cccc06515a89d4'


Account has a valid temp_url_key configured. Please see below:
curl -v -X GET http://SWIFT_IP:SWIFT_PORT/v2/Auth_b34a51e551ec4796a461168c886c734f -H "X-Auth-Token: TOKEN"
* Hostname was NOT found in DNS cache
* Trying SWIFT_IP...
* Connected to SWIFT_IP (SWIFT_IP) port SWIFT_PORT (#0)
GET /v2/Auth_b34a51e551ec4796a461168c886c734f HTTP/1.1
User-Agent: curl/7.35.0
Host: SWIFT_IP:SWIFT_PORT
Accept: */*
X-Auth-Token: TOKEN
< HTTP/1.1 204 No Content
< Content-Length: 0
< X-Account-Object-Count: 0
< X-Timestamp: 1457918518.21777
< X-Account-Meta-Temp-Url-Key: b3968d0207b54ece87cccc06515a89d4
< X-Account-Bytes-Used: 0
< X-Account-Container-Count: 0
< Content-Type: text/plain; charset=utf-8
< Accept-Ranges: bytes
< X-Trans-Id: txfc362c27bdda4355a942a-0056e65d93
< Date: Mon, 14 Mar 2016 06:43:31 GMT
<
* Connection #0 to host SWIFT_IP left intact

Also, I can see that the containers are created on swift, so obviously it is able to authenticate.
$ openstack container list
+---------------+
| Name |
+---------------+
| cc-buildpacks |
| cc-droplets |
| cc-packages |
| cc-resources |
+---------------+

I would appreciate if someone can help me fixing this issue.

Regards,
Muhammad Altaf
Software Development Engineer

Fujitsu Australia Software Technology Pty Ltd
14 Rodborough Road, Frenchs Forest NSW 2086, Australia
T +61 2 9452 9067 F +61 2 9975 2899
Muhammada(a)fast.au.fujitsu.com<mailto:Muhammada(a)fast.au.fujitsu.com>
fastware.com.au<http://fastware.com.au>

[image001.jpg]
[image002.jpg]

Disclaimer

The information in this e-mail is confidential and may contain content that is subject to copyright and/or is commercial-in-confidence and is intended only for the use of the above named addressee. If you are not the intended recipient, you are hereby notified that dissemination, copying or use of the information is strictly prohibited. If you have received this e-mail in error, please telephone Fujitsu Australia Software Technology Pty Ltd on + 61 2 9452 9000 or by reply e-mail to the sender and delete the document and all copies thereof.


Whereas Fujitsu Australia Software Technology Pty Ltd would not knowingly transmit a virus within an email communication, it is the receiver’s responsibility to scan all communication and any files attached for computer viruses and other defects. Fujitsu Australia Software Technology Pty Ltd does not accept liability for any loss or damage (whether direct, indirect, consequential or economic) however caused, and whether by negligence or otherwise, which may result directly or indirectly from this communication or any files attached.


If you do not wish to receive commercial and/or marketing email messages from Fujitsu Australia Software Technology Pty Ltd, please email unsubscribe(a)fast.au.fujitsu.com<mailto:unsubscribe(a)fast.au.fujitsu.com>


Re: cloud_connector_ng not starting on cf 231

Christian Schwerdtfeger
 

after a lot of investigation, we found out, that it was simply a "duplicate domain" problem cause we set system_domain and domain to the same value. so this is solved.

5181 - 5200 of 9421