Hi,

I found all org, spaces and applications information were lost after I upgraded my CF env from v197 to v230. After checked the postgres node, I found there were two directory under /var/vcap/store. One is “postgres” and the other is “postgres-9.4.5”. I guess the reason why all information got lost is data from previous postgresql database(9.0.3) was not migrated to new postgresql database(9.4.5). I found two related releases.

V211

Postgres Job Upgrade
The Postgres Job will upgrade the postgres database to version 9.4.2. Postgres will be unavailable during this upgrade.

V229

In support of work in progress to enable developers to specify application ports when mapping routes, cf-release v229 introduces a database migration for CCDB. For deployments that use a PostgreSQL database for CCDB that is NOT the PostreSQL job that comes with cf-release, v229 introduces the following requirements. These requirements are applicable for subsequent releases. If you are using the PostgreSQL job that comes with cf-release, or if you are using MySQL as the backing db for CC, no action is necessary.
◦PostgreSQL 9.1 is required at a minimum
◦For versions 9.1-9.3, operators must first install the extension uuid-ossp
◦For versions 9.4 and newer, operators must first install the extension pgcrypto

So does it mean I have to upgrade v197 to v211 and then upgrade to v230 after installing pgcrypto? Any help would be appreciated.

Thanks,
Maggie

Awesome. Thank you, Nicholas.

John

On Mon, Apr 18, 2016 at 1:51 PM, Nicholas Calugar <ncalugar(a)pivotal.io>
wrote:

Hi John,

An application's guid will never change. If you delete an app, and push
the code again, you are creating a new app with another guid.


Thanks,

Nick

On Mon, Apr 18, 2016 at 9:53 AM, John Wong <gokoproject(a)gmail.com> wrote:

Based on my brief testing and observation, the guid of an app sticks
around for as long as the app remains running (whether we restart or
restage). But removing the app, then cf push a new guid is generated.

Is this a true statement?

Thanks.

John

I think if we can get some consensus on the .profile script support (AKA Runtime Hooks), we should move forward with that. Jan has already separated that work into a separate PR, so it could be merged independently.

https://github.com/cloudfoundry-incubator/buildpack_app_lifecycle/pull/14

For the staging hooks, we can potentially implement the proposed functionality in pre-staging and post-staging *buildpacks* in conjunction with the multi-buildpacks support Mike mentions above. This is a little more work for the user, but avoids the need to expand the Heroku buildpack contract. I'm not totally convinced that the original proposal actually breaks buildpack compatibility, but moving staging hooks into their own auxiliary buildpacks should remove any remaining points of contention and would not require any merges into buildpack_app_lifecycle.

I think you've convinced me (separate discussion) that things like db initialization are best done in Tasks.

TT

Hi Nick, Hi Daniel,
The app push using the CLI works. I haven’t had the chance to check the cloud controller logs yet—that’s the next thing on my plate.

Best Regards,
Abhik

From: Nicholas Calugar [mailto:ncalugar(a)pivotal.io]
Sent: Tuesday, April 19, 2016 2:31 AM
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org>
Subject: [cf-dev] Re: Re: CF Job Failure

Hi Abhik,

Another bit of information that would be interesting is whether or not you can push your app using the CLI.


Thanks,

Nick

On Mon, Apr 18, 2016 at 6:13 AM, Daniel Mikusa <dmikusa(a)pivotal.io<mailto:dmikusa(a)pivotal.io>> wrote:
On Mon, Apr 18, 2016 at 7:10 AM, Gupta, Abhik <abhik.gupta(a)sap.com<mailto:abhik.gupta(a)sap.com>> wrote:
Hi,
We are trying to push a node.js application using the Cloud Controller REST APIs. The flow that we follow is similar to the flow followed by CF CLI:

Create Application Metadata > Create Route Metadata > Associate Route with Application > Get cached resources from Cloud Foundry using the Resource Match API > Upload the bits (sending the fingerprints + application.zip) asynchronously > Poll for the Job Status

This flow works perfectly fine till the last step but the polling for the job status gives back an error response like:

{
"metadata": {
"guid": "cd5bf18d-249b-4f00-9ee9-6328081d3d77",
"created_at": "2016-04-18T10:55:29Z",
"url": "/v2/jobs/cd5bf18d-249b-4f00-9ee9-6328081d3d77"
},
"entity": {
"guid": "cd5bf18d-249b-4f00-9ee9-6328081d3d77",
"status": "failed",
"error": "Use of entity>error is deprecated in favor of entity>error_details.",
"error_details": {
"error_code": "UnknownError",
"description": "An unknown error occurred.",
"code": 10001
}
}
}

Does the app actually push and get started? i.e. if you run `cf apps` after you get this message is the app up and running? Also, do you see similar issues when you push with `cf push`?


Apparently, this error is also pretty well-known because it’s documented in the API documentation as well here: http://apidocs.cloudfoundry.org/228/jobs/retrieve_job_with_unknown_failure.html
What could be the reason for this error from the Controller?

Take a look at the cloud controller logs, `/var/vcap/sys/log/cloud_controller_ng`. There should be more information about the problem there.

Dan

We have had a few use cases where users have requested to stay on nodejs
version 4 (LTS), while taking advantage of npm 3's new flat dependency
tree. Node 4 by default bundles witn npm 2. Node 5 defaults to npm 3.
In all of these use cases we are using online buildpacks. I would say this
use case isn't as common, but we definitely get requests for it.

Hi Abhik,

Another bit of information that would be interesting is whether or not you
can push your app using the CLI.


Thanks,

Nick

hi, I am pushing jboss/drools-workbench-showcase docker image to cloudfoundry
from my CLI.
This is the command,

cf push workbench -o jboss/drools-workbench-showcase:6.2.0.Final
But I get an error
Failed to talk to docker registry: Get http://registry-1.docker.io/v2/:
net/http: request canceled while waiting for connection.

How to add docker insecure registry to cloud foundry.

This image works fine in my local



--
View this message in context: http://cf-dev.70369.x6.nabble.com/pushing-docker-image-to-CF-tp4649.html
Sent from the CF Dev mailing list archive at Nabble.com.

Hi John,

An application's guid will never change. If you delete an app, and push the
code again, you are creating a new app with another guid.


Thanks,

Nick

Based on my brief testing and observation, the guid of an app sticks around
for as long as the app remains running (whether we restart or restage). But
removing the app, then cf push a new guid is generated.

Is this a true statement?

Thanks.

John

On Mon, Apr 18, 2016 at 7:10 AM, Gupta, Abhik <abhik.gupta(a)sap.com> wrote:

Hi,

We are trying to push a node.js application using the Cloud Controller
REST APIs. The flow that we follow is similar to the flow followed by CF
CLI:



Create Application Metadata > Create Route Metadata > Associate Route with
Application > Get cached resources from Cloud Foundry using the Resource
Match API > Upload the bits (sending the fingerprints + application.zip)
asynchronously > Poll for the Job Status



This flow works perfectly fine till the last step but the polling for the
job status gives back an error response like:



{

"metadata": {

"guid": "cd5bf18d-249b-4f00-9ee9-6328081d3d77",

"created_at": "2016-04-18T10:55:29Z",

"url": "/v2/jobs/cd5bf18d-249b-4f00-9ee9-6328081d3d77"

},

"entity": {

"guid": "cd5bf18d-249b-4f00-9ee9-6328081d3d77",

"status": "failed",

"error": "Use of entity>error is deprecated in favor of
entity>error_details.",

"error_details": {

"error_code": "UnknownError",

"description": "An unknown error occurred.",

"code": 10001

}

}

}

Does the app actually push and get started? i.e. if you run `cf apps`
after you get this message is the app up and running? Also, do you see
similar issues when you push with `cf push`?

Apparently, this error is also pretty well-known because it’s documented
in the API documentation as well here:
http://apidocs.cloudfoundry.org/228/jobs/retrieve_job_with_unknown_failure.html

What could be the reason for this error from the Controller?

Take a look at the cloud controller logs,
`/var/vcap/sys/log/cloud_controller_ng`. There should be more information
about the problem there.

Dan

On Sat, Apr 16, 2016 at 11:30 PM, Josh Long <starbuxman(a)gmail.com> wrote:

I'm not sure if this is the right forum. I doubt it.

* you could achieve what you want by forking the buildpack used. If you're
using the Java buildpack then it's
https://github.com/cloudfoundry/java-buildpack. the `cf push` command
supports providing an override URL for the buildpack.

As an experiment, I created a build pack that would do this. It hasn't
been updated in a while, I don't plan to update it and it was never very
solid to begin with. It was more to just see if I could make it work. It
did, but the benefit was very small. I wouldn't recommend using it, but
it's there if you want to look at it.

https://github.com/dmikusa-pivotal/cf-maven-buildpack

* that said, this is a TERRIBLE idea. Instead, prefer that one build be
promoted from development to staging, QA, and production. Ideally, that
promotion should be automatic, the result of a continuous delivery pipeline
that sees code committed to version control, then run through continuous
integration, then pushed to a testing environment where it's certified and
smoke-tested, validated by QA, and ultimately promoted to production. You
can support this process with continuous integration tools like Jenkins,
Travis, Spinnaker, or Concourse.CI, which will monitor version control and
can be scripted to package and cf push code..

+1 - It's also worth mentioning that when you `cf push` something, your
platform will cache any resources that are larger than 65k (default
threshold, your platform's actual value may differ). The cache is global
so it's not just per app or per user. Once any user pushes a file, it will
be cached. This helps a ton with Java apps since JAR files are generally
over the threshold and the same JAR files are used across many users &
apps. Long story short, when you go to push your app you likely won't need
to upload as much data as you think.

Hope that helps!

Dan

On Sat, Apr 16, 2016 at 7:15 PM Matthew Tyson <matthewcarltyson(a)gmail.com>
wrote:

Please let me know if there is a more appropriate forum for this type of
question.

I read "Overview of the Loggregator System " - https://docs.cloudfoundry.org/loggregator/architecture.html

In that document, metron_agent can forward metrics or logs to N doppler.

But i don't know how to do it.

Would you let me know how to configure it at cf.yml.

Thanks & Regards

Hi,
We are trying to push a node.js application using the Cloud Controller REST APIs. The flow that we follow is similar to the flow followed by CF CLI:

Create Application Metadata > Create Route Metadata > Associate Route with Application > Get cached resources from Cloud Foundry using the Resource Match API > Upload the bits (sending the fingerprints + application.zip) asynchronously > Poll for the Job Status

This flow works perfectly fine till the last step but the polling for the job status gives back an error response like:

{
"metadata": {
"guid": "cd5bf18d-249b-4f00-9ee9-6328081d3d77",
"created_at": "2016-04-18T10:55:29Z",
"url": "/v2/jobs/cd5bf18d-249b-4f00-9ee9-6328081d3d77"
},
"entity": {
"guid": "cd5bf18d-249b-4f00-9ee9-6328081d3d77",
"status": "failed",
"error": "Use of entity>error is deprecated in favor of entity>error_details.",
"error_details": {
"error_code": "UnknownError",
"description": "An unknown error occurred.",
"code": 10001
}
}
}

Apparently, this error is also pretty well-known because it's documented in the API documentation as well here: http://apidocs.cloudfoundry.org/228/jobs/retrieve_job_with_unknown_failure.html
What could be the reason for this error from the Controller?

Thanks & Regards
Abhik

Hi Amit,

Am 17.04.2016 um 21:10 schrieb Amit Gupta:

Hi Stefan, Mike,

For real applications, would you want a common 503 page for all
applications on the platform, or would your different applications have
different custom domains, with custom 503 pages for each domain.

For my current use case we need the 503 page as a catch-all for stopped
applications in all application domains. It displays a "nice" generic
message and tries not to break marketings seo efforts :-)
For more specific customer information (down till monday hh:mm) we can
deploy another staticfile application and map the application domain to it.

If the latter, then you probably wouldn't have the wildcard route on the
same domain as the default app domain used in the smoke tests.

If the former, then what sort of assertion do you think the smoke tests
should make to assert that the app has been cleaned up and is no longer
routable (without introducing false positives where the app is still
routable but returning a bad response code for some other reason)?
Thinking about the smoke tests in isolation, you might think to make the
response-code-check injectible as configuration to the smoke tests. But
from the perspective of the operator setting up the whole system and
maybe deciding whether or not to run smoke tests, they might not even
have deployed CF yet, let alone set up a 503 page, so it would be
awkward to have the operator decide and configure up front what
output/response code the smoke tests look for.

Not sure what the optimal answer is here, any thoughts?

I'm thinking about a correct answer since I've read the source code last
friday. Regardless of my preference of a 503 service unavailable to a
404 file not found - having a feature (wildcard for default application
domain) breaking a general smoke tests feels wrong.

At the moment I like the idea how some applications do domain
validation: they require you to put a file with some kind of key or uuid
onto your webserver or into a dns txt record. For cloud foundry we could
use something similar: deploy a file containing a specific id. If we try
to fetch the content of this url and it doesn't contain this id the
application is gone. It is basically like a negated version of the
current test. Instead of expecting a specific string when the
application is deleted (404) we expect a specific string (0xdeadbeef?)
not to be in the response string.

Amit

On Sun, Apr 17, 2016 at 11:43 AM, Stefan Mayr <stefan(a)mayr-stefan.de
<mailto:stefan(a)mayr-stefan.de>> wrote:

Hi,

Am 14.04.2016 um 18:14 schrieb Mike Youngstrom:

We passed the smoke tests by:

* Only returning a 503 if the requested route exists.
* Embed the old 404 page text in a comment of the returned html.

Mike


I verified this today: only the the text "404" is required to pass
the smoke tests. So I created a 503 service unavailable page
containing an html comment: <!-- CF: 404 -->

Good enough as a temporary workaround. I'd still consider this as a
bug in the smoke tests. When you use wildcard routes for real
applications this won't work.

Regards,

Stefan Mayr

Hi Stefan, Mike,

For real applications, would you want a common 503 page for all
applications on the platform, or would your different applications have
different custom domains, with custom 503 pages for each domain.

If the latter, then you probably wouldn't have the wildcard route on the
same domain as the default app domain used in the smoke tests.

If the former, then what sort of assertion do you think the smoke tests
should make to assert that the app has been cleaned up and is no longer
routable (without introducing false positives where the app is still
routable but returning a bad response code for some other reason)?
Thinking about the smoke tests in isolation, you might think to make the
response-code-check injectible as configuration to the smoke tests. But
from the perspective of the operator setting up the whole system and maybe
deciding whether or not to run smoke tests, they might not even have
deployed CF yet, let alone set up a 503 page, so it would be awkward to
have the operator decide and configure up front what output/response code
the smoke tests look for.

Not sure what the optimal answer is here, any thoughts?

Amit

Hi,

Am 14.04.2016 um 18:14 schrieb Mike Youngstrom:

We passed the smoke tests by:

* Only returning a 503 if the requested route exists.
* Embed the old 404 page text in a comment of the returned html.

Mike

I verified this today: only the the text "404" is required to pass the
smoke tests. So I created a 503 service unavailable page containing an
html comment: <!-- CF: 404 -->

Good enough as a temporary workaround. I'd still consider this as a bug
in the smoke tests. When you use wildcard routes for real applications
this won't work.

Regards,

Stefan

I'm not sure if this is the right forum. I doubt it.

* you could achieve what you want by forking the buildpack used. If you're
using the Java buildpack then it's
https://github.com/cloudfoundry/java-buildpack. the `cf push` command
supports providing an override URL for the buildpack.
* that said, this is a TERRIBLE idea. Instead, prefer that one build be
promoted from development to staging, QA, and production. Ideally, that
promotion should be automatic, the result of a continuous delivery pipeline
that sees code committed to version control, then run through continuous
integration, then pushed to a testing environment where it's certified and
smoke-tested, validated by QA, and ultimately promoted to production. You
can support this process with continuous integration tools like Jenkins,
Travis, Spinnaker, or Concourse.CI, which will monitor version control and
can be scripted to package and cf push code..

On Sat, Apr 16, 2016 at 7:15 PM Matthew Tyson <matthewcarltyson(a)gmail.com>
wrote:

Please let me know if there is a more appropriate forum for this type of
question.

Please let me know if there is a more appropriate forum for this type of question.

Is anyone aware of a way to deploy a maven application via cloud foundry that will:

1) Take only the application bits and upload them

2) Run the maven build based on the pom.xml

3) pull down the defined dependencies on the platform

Thereby NOT uploading the dependencies from the client to the platform?

Hello Cloud Foundry Experts -

As you may know, the Cloud Foundry Foundation is working on building a
certification program for professionals who use Cloud Foundry. Initially
we are tackling a CF Developer certification, and a bit later will be
tackling a CF Operator certification. Thanks to the contributors who helped
us define the scope, domains and tasks, we know what we want to cover in
the exam. The next step in our process is taking the tasks and turning them
into good test questions.

We need your help in with item writing! We are looking for pairs of Cloud
Foundry contributors to help us develop the test. Specifically, we need
help in building out test questions - taking an initial summary of a task
and creating a specific question, with associated pre-requisites and final
correct answers. Some questions will have a coding component, as we also
need some sample (very simple) applications as part of the question.

We expect this activity to require roughly one full day per question, and
we’d like to have volunteers work on 2-4 of the questions. (If you plan to
take the test, you’ll need to limit the number of questions you work on -
let us know in advance!) So the ideal pair of volunteers would have 3-4
days in May to dedicate to this task, and we’d like to all work on it
together so we can get it done quickly. We’ll start out with a 2 hour
training session to explain how to write scorable test questions.

Are you someone that could help us with this important task? At this point
we are looking for interested and knowledgeable volunteers who likely can
help, and we’ll work together to detail the logistics of specifically how
and when we work together on the effort. So simply reply to this email
(and perhaps share your specialty in CF if you have one) and we’ll take it
from there...

Thanks in advance to those that can help!

Tim and Stormy

--
Tim Harris | Director of Certification Programs
Cloud Foundry Foundation
(415) 518-6807