We had encountered the same issue before. The “?” or “-1” doesn’t mean
the deployment fails. It only means CC could not get the status of running
instance. Most likely there is something wrong with your ETCD server or
HM9000 server. You should check the log files from those servers.



Thanks,

Maggie



*From:* cf-dev-bounces(a)lists.cloudfoundry.org [mailto:
cf-dev-bounces(a)lists.cloudfoundry.org] *On Behalf Of *Kris Kobylinski
*Sent:* 2015年7月23日 20:42
*To:* Discussions about Cloud Foundry projects and the system overall.
*Subject:* Re: [cf-dev] "running_instances": -1



If the deployment failed wouldn't that mean that no instances are running
? Shouldn't the running_instances be 0 in that case ?


Thank you,

Kris



On Thu, Jul 23, 2015 at 2:06 AM, Dieu Cao <dcao(a)pivotal.io> wrote:

-1 indicates that the state of the instances is unknown.

The CLI is purposefully converting the -1 to a ? to indicate that the
state is unknown.



On Wed, Jul 22, 2015 at 4:09 PM, Kris Kobylinski <kriskobylinski(a)gmail.com>
wrote:

After pushing an app which fails at buildpack support, the following
parameters are observed:
"state": "STARTED"

"running_instances":-1
"package_state": "FAILED"

It seems that the -1 for running instances is problematic for the CF CLI
which shows something like the following :
name requested state instances memory disk urls
app started ?/1 1G 1G app
URL

Shouldn't the running_instances be 0 ? What is the meaning of -1 ?

Thank you,

Kris




--

________________________________________
http://kriskobylinski.mybluemix.net/ <http://koby.acndirect.com>



_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev




_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev




--

________________________________________
http://kriskobylinski.mybluemix.net/ <http://koby.acndirect.com>

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

This morning on the Services PMC call, Abacus was accepted into incubation.

Thank you Max, and your colleagues at IBM, for your months of effort to
open source this project.

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Wed, Jul 15, 2015 at 8:40 AM, Chris Sterling <chris.sterling(a)gmail.com>
wrote:

This looks like a useful service. Thanks for the contribution!

Chris Sterling
chris.sterling(a)gmail.com
twitter: @csterwa
linkedin: http://www.linkedin.com/in/chrissterling

On Wed, Jul 15, 2015 at 8:37 AM, Duncan Johnston Watt <
duncan.johnstonwatt(a)cloudsoftcorp.com> wrote:

+1 this looks incredibly useful.

Best

Duncan Johnston-Watt
CEO | Cloudsoft Corporation

Twitter | @duncanjw
Mobile | +44 777 190 2653
Skype | duncan_johnstonwatt
Linkedin | www.linkedin.com/in/duncanjohnstonwatt

On 15 July 2015 at 15:07, James Bayer <jbayer(a)pivotal.io> wrote:

thanks to ibm for this proposal! we're excited to review this in more
depth.

what this means for service authors is that they would have a standard
system component and format for to track custom billing metrics for service
usage other than "how long was this service deployed". consider an email
service, you could track usage for every email sent or for a data service
you could track the amount of disk usage for data storage. it opens up a
lot of flexibility for how to do chargeback and showback.

for operators, in addition to apps, if the services provided on the
platform use this approach or are translated to this, it provides a
standard way to roll-up usage for a tenant across all of their platform
usage and present it nicely aggregated.

looking forward to the feedback,

james

On Tue, Jul 14, 2015 at 8:30 PM, Michael Maximilien <maxim(a)us.ibm.com>
wrote:

Hi,

This email is to introduce and propose project Abacus to the CF
community for incubation.

*What?*

The IBM Bluemix PaaS (based on CloudFoundry) includes a billing and
metering component such that users can project and drill down on the costs
they have incurred or will incur as they use the system.

Part of this component includes not only APIs that service brokers use
to provide usage data, but also, how to aggregate that information, as well
as a component to expose the aggregated data into a format (JSON) that can
be subsequently consumed by users — this is done via a drill down UI in
Bluemix.

Project Abacus is an extracted Open Source Software version (under
Apache 2.0 license) of the APIs, usage metering, and aggregation components
from the Bluemix feature.

Finally, it’s important to state that project Abacus uses a
micro-services architecture and is written in Node.js with CouchDB
compatible DBs as datastore and for map/reduce aggregations. Also, all
components can actually run as CF apps or be externalized. In Bluemix they
run as apps.

In other words, this is a bit different from other CF components,
however, we have reviewed Abacus with our colleagues from Pivotal and they
also believe it warrants incubation.

*When?*

Now.

Find the first self-contained release here:
https://github.com/jsdelfino/cf-abacus/archive/v0.0.1.tar.gz

There is a comprehensive README
<https://github.com/jsdelfino/cf-abacus/blob/master/README.md>that
can help you setup and try this first release. The team has included a fake
broker that can be used to generate usage data so you can try the whole
thing out of the box.

*How?*

We plan to introduce this as part of the CAB call discussion tomorrow
07/15 and field any questions.

The next step will be to get approval and become an incubation
project. Once this is done we will be staffing the project with a team
(many from the Bluemix engineers that created it) as well as a PM, and
follow the CFF guidelines for new projects.

We are ready to move on this with no delays and we welcome all
interested parties to try out the first release and to help us refine the
APIs and subsequent releases.

------
Best,

IBM CF team

dr.max
ibm cloud labs
silicon valley, ca

Sent from my iPhone

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

--
Thank you,

James Bayer

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP

This e-mail message is confidential and for use by the addressee only.
If the message is received by anyone other than the addressee, please
return the message to the sender by replying to it and then delete the
message from your computer. Internet e-mails are not necessarily secure.
Cloudsoft Corporation Limited does not accept responsibility for changes
made to this message after it was sent.

Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by Cloudsoft Corporation Limited in this regard and the recipient
should carry out such virus and other checks as it considers appropriate.
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

Well, from my point of view the customization is just adding the
flexibility of being able to annotate our logs with what we consider to be
important for our debugging purposes, a feature that is surely interesting
for other parties aswell. We are not interested in adding extra headers
into CF, just pulling headers from incoming requests(where the headers have
ben set elsewhere) to Gorouter into a doppler event. :)

On Wed, Jul 22, 2015 at 11:43 AM, Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

Simon I know what you want todo :) I am shinji62 lol
I am jsut afraid that you want to customize the platform and you will be
stuck with because other don't support custom header.

On Wed, Jul 22, 2015 at 6:36 PM, Simon Johansson <
simon(a)simonjohansson.com> wrote:

I feel that we are stearing this conversation into the wrong direction.

Gist it, I would like to with cf logs app / firehose-to-syslog see my
RTR-logs as

blurgh.dev.cf.private.domain.com - blablablab
vcap_request_id:1e58195a-cde6-4afd-7f03-43061c9ea91c
response_time:0.004927106 app_id:9784cd03-050d-4b74-9e90-5f17134a3f08
*{"X-Random-Header": "Once upon a midnight dreary, while I pondered weak
and weary", "Another-Header": "wryyyy"}*

By being able to tell Gorouter what headers Im interested in via the
manifest
logging:
add_extra_headers_if_available:
- X-Random-Header
- Another-Header
- This-header-will-only-be-in-1%-of-the-requests

Is this something you would be interested in mergin, I dont want to
implement it if there is no chance of it being merged.


On Wed, Jul 22, 2015 at 11:30 AM, Gwenn Etourneau <getourneau(a)pivotal.io

wrote:

So if you move to Heroku you will be able to change the platform ??? I
don't think so..
So you can put the new header from your app or at least the runtime
buildpack or docker.

Your application should be platform dependent that's why you need to
implement this header into your application to avoid any lock-in or forking
issue.

On Wed, Jul 22, 2015 at 6:27 PM, Simon Johansson <
simon(a)simonjohansson.com> wrote:

WAKAWAKA is just an example
But the difference is that WAKAWAKA is not platform specific whereas
X-Cf-Requestid is. If we want to move our app to Heroku, or a VM, or
whatewher we have platform specific implementation details in our
app(namely we rely on a header that is not there anymore). But that is not
the point of this thread.

The point is,

say we have an app that is fronted by a CDN, and the CDN sets the
X-Im-a-shark header with some value that we are interested to see in our
logs. The easiest way to achivie this without having to implement it into
our own apps is just to tell the Gorouter that it should append the value
of that header into the string that it logs so the event that flow via
Doppler and ultimately into cf logs/ELK will contain that value.

The reason why this would be such a valuable feature for us is that we
dont have to do anything. CF already provide the out of the box facility to
give us routing logs, so if we can piggy back on that for what we are
interested in we dont have to add libraries to our apps to log interesting
headers on the side.



On Wed, Jul 22, 2015 at 12:45 AM, Shannon Coen <scoen(a)pivotal.io>
wrote:

I don't see the difference between WAKAWAKA and X-Cf-Requestid.
Gorouter would have to add some header with a uuid for the request. Your
apps have to have logic to pass this header on, so that a log search
returns the original request as well as subsequent requests between apps.
Could you please clarify?

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Tue, Jul 21, 2015 at 11:09 AM, Simon Johansson <
simon(a)simonjohansson.com> wrote:

Sure that header can be used. But then we are adding CF specific
stuff into the implementation of our services, which is something we want
to avoid at all costs.
Also Im not entirely sure if all the libraries we use for Zipkin
supports using custom headers.

All our public apps are fronted by different CDNs, which sets
headers that we might want to store for debugging, so we still need a way
to pass those trough into the log.

On Tuesday, 21 July 2015, Shannon Coen <scoen(a)pivotal.io> wrote:

Hello Simon,

The X-Cf-Requestid header already provides a uuid. Couldn't app "a"
add the value of X-Cf-Requestid to a header of your choosing? Call it
WAKAWAKA or X-Random-Header, but it doesn't need to be a platform standard.
Wouldn't a search for the value of X-Cf-Requestid then provide the desired
results?

Thank you,
Shannon

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Tue, Jul 21, 2015 at 6:06 AM, Simon Johansson <
simon(a)simonjohansson.com> wrote:

Howdie!

We have some devs who want to be able to trace a request troughout
their applications.

user -> a -> b -> c
|
|-> d -> e

When a user makes a request to "a" uuid is generated inside the
app, and the request to "b" from "a" will set a header(call it WAKAWAKA to
uuid), "b"'s call will passthrough WAKAWAKA to "c" and "d", "d" will
passthrough WAKAWAKA to "e". Etc.

We aggregate all RTR logs into ELK so it would be super helpful to
them to be able to filter on WAKAWAKA and get all the access logs(and app
logs aswell, they mostly use GELF so its easy for them to add whatewher
field they want) from the services involved.

I had a quick peek at the gorouter(
https://github.com/cloudfoundry/gorouter/blob/76668f5818ea8c089ff52a14fcdfbf703c8e8767/access_log/access_log_record.go#L40)
and it seems like this should be a simple PR.

1. To gorouter.yml add
passthrough_headers:
- WAKAWAKA
- X-Random-Header

2. In makeRecord at the bottom add something like(in psuedo)

data = {}
for header in passthrough_headers:
header_val = r.FormatRequestHeader("X-Forwarded-For")
if header_val:
passthrough_headers[header] = header_val

if data:
fmt.Fprintf(b, data.to_stringified_json())

That would yield a log line like
blurgh.dev.cf.private.domain.com - [21/07/2015:10:17:05 +0000]
"GET
/statements?ascending=true&since=2015-06-30T14%3A10%3A03.078Z&skipStatementId=30a88204-0779-4385-9859-e4aabd30baf0
HTTP/1.1" 200 0 17 "-" "NING/1.0" 10.230.31.2:46204
x_forwarded_for:"-" vcap_request_id:1e58195a-cde6-4afd-7f03-43061c9ea91c
response_time:0.004927106 app_id:9784cd03-050d-4b74-9e90-5f17134a3f08
{"WAKAWAKA": "Space is the place", "X-Random-Header": "Once upon a midnight
dreary, while I pondered weak and weary"}

The reason for a stringified JSON is to make it easy to parse with
logstash or other loganalysis tools.

Before I spend time implementing, is this something you would
merge?

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

On behalf of the CAPI team I'm pleased to announce support for Arbitrary
Parameters and Service Instance Tags, two features which extend the
possibilities for Cloud Foundry Marketplace service offerings, and provide
developers with increased flexibility in how services are consumed by
applications.

Support for Arbitrary Parameters is introduced with cf-release v209 and
CLI v6.12.1. This features enables service providers to support
user-provided configuration options with the create, update, and bind
service instance operations, and the create service key operation (stay
tuned for a forthcoming announcement of support for Service Keys).
Previously, this could only be achieved by providing many plans to cover
various combinations of configuration options, or to provide a service
instance dashboard that users can SSO into and adjust configuration options
after creation. Although the platform and CLI now support the feature,
service broker authors must implement support for the feature as described
in the Service Broker API v2.5 specification
<http://docs.cloudfoundry.org/services/api.html>.

Support for Instance Tags is introduced with cf-release v211 and CLI
v6.12.1. Since v2.0 of the Service Broker API, broker authors have be able
to provide tags for a service offering in the /v2/catalog endpoint that
Cloud Foundry delivers to applications in the VCAP_SERVICES Environment
Variable
<http://docs.cloudfoundry.org/devguide/deploy-apps/environment-variable.html#VCAP-SERVICES>.
These tags provide developers with a more generic way for applications to
parse VCAP_SERVICES for credentials. Developers may now provide their own
tags when creating or updating a service instance by including a
comma-separated list of tags with the -t flag.

Documentation:

- http://docs.cloudfoundry.org/services/api.html

- http://docs.cloudfoundry.org/devguide/services/managing-services.html

Special thanks to the former CF Services API team and Shannon for their
hard work on these features.

-Dieu
CF CAPI PM

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

On behalf of the CAPI team I'm pleased to announce support for Arbitrary
Parameters and Service Instance Tags, two features which extend the
possibilities for Cloud Foundry Marketplace service offerings, and provide
developers with increased flexibility in how services are consumed by
applications.

Support for Arbitrary Parameters is introduced with cf-release v209 and
CLI v6.12.1. This features enables service providers to support
user-provided configuration options with the create, update, and bind
service instance operations, and the create service key operation (stay
tuned for a forthcoming announcement of support for Service Keys).
Previously, this could only be achieved by providing many plans to cover
various combinations of configuration options, or to provide a service
instance dashboard that users can SSO into and adjust configuration options
after creation. Although the platform and CLI now support the feature,
service broker authors must implement support for the feature as described
in the Service Broker API v2.5 specification
<http://docs.cloudfoundry.org/services/api.html>.

Support for Instance Tags is introduced with cf-release v211 and CLI
v6.12.1. Since v2.0 of the Service Broker API, broker authors have be able
to provide tags for a service offering in the /v2/catalog endpoint that
Cloud Foundry delivers to applications in the VCAP_SERVICES Environment
Variable
<http://docs.cloudfoundry.org/devguide/deploy-apps/environment-variable.html#VCAP-SERVICES>.
These tags provide developers with a more generic way for applications to
parse VCAP_SERVICES for credentials. Developers may now provide their own
tags when creating or updating a service instance by including a
comma-separated list of tags with the -t flag.

Documentation:

- http://docs.cloudfoundry.org/services/api.html

- http://docs.cloudfoundry.org/devguide/services/managing-services.html

Special thanks to the former CF Services API team and Shannon for their
hard work on these features.

-Dieu
CF CAPI PM

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev