Re: "running_instances": -1
Matthew Sykes <matthew.sykes@...>
As Maggie and Dieu have said, the `running_instances` field from the
"summary" endpoint the cli is using reflects hm9k view of the world and the
`state` field represents the desired state of the app. The API is basically
stitching what the CC knows about the app with what the health manager
knows into a view.
While the '-1' does imply that hm9k doesn't know about the app, a stale
view is not the only cause.
The problem that you're hitting is that the summary endpoint isn't doing
the right thing when the app has not been correctly staged.
In particular, hm9k throws away information it receives about applications
that are not staged [1]. That means that when the CC asks hm9k for
information about the app [2], it has none and returns '-1' for instances
(and all other metrics).
Basically, it looks like the summary endpoint or `instances_reporter.rb`
[3] should be evaluating the package state a little more carefully so it
can present the correct information as hm9k will not have info on apps that
did not successfully stage.
[1]:
https://github.com/cloudfoundry/hm9000/blob/17b3830948ded967bd4052d4975683e107a43030/desiredstatefetcher/desired_state_fetcher.go#L162
[2]:
https://github.com/cloudfoundry/cloud_controller_ng/blob/4b23dd32b39174d5bf1c11170851c2ea99704272/app/controllers/runtime/app_summaries_controller.rb#L18
[3]:
https://github.com/cloudfoundry/cloud_controller_ng/blob/4b23dd32b39174d5bf1c11170851c2ea99704272/lib/cloud_controller/dea/instances_reporter.rb#L14-L17
On Thu, Jul 23, 2015 at 10:03 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com>
wrote:
--
Matthew Sykes
matthew.sykes(a)gmail.com
"summary" endpoint the cli is using reflects hm9k view of the world and the
`state` field represents the desired state of the app. The API is basically
stitching what the CC knows about the app with what the health manager
knows into a view.
While the '-1' does imply that hm9k doesn't know about the app, a stale
view is not the only cause.
The problem that you're hitting is that the summary endpoint isn't doing
the right thing when the app has not been correctly staged.
In particular, hm9k throws away information it receives about applications
that are not staged [1]. That means that when the CC asks hm9k for
information about the app [2], it has none and returns '-1' for instances
(and all other metrics).
Basically, it looks like the summary endpoint or `instances_reporter.rb`
[3] should be evaluating the package state a little more carefully so it
can present the correct information as hm9k will not have info on apps that
did not successfully stage.
[1]:
https://github.com/cloudfoundry/hm9000/blob/17b3830948ded967bd4052d4975683e107a43030/desiredstatefetcher/desired_state_fetcher.go#L162
[2]:
https://github.com/cloudfoundry/cloud_controller_ng/blob/4b23dd32b39174d5bf1c11170851c2ea99704272/app/controllers/runtime/app_summaries_controller.rb#L18
[3]:
https://github.com/cloudfoundry/cloud_controller_ng/blob/4b23dd32b39174d5bf1c11170851c2ea99704272/lib/cloud_controller/dea/instances_reporter.rb#L14-L17
On Thu, Jul 23, 2015 at 10:03 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com>
wrote:
Hi, Kris
I think it may be a CLI 6.0 issue to show the “requested_state” not the
real state. I remembered in CLI 5.0 it would show stopped if application
failed to start.
But the “-1” you get has nothing with the status of application. I got
this value even when my application starts and runs successfully. The “-1”
just indicates that CC could not get your application’s status. If your
hm900 server works well, you will see 0/0 if your application fails at
deployment or staging stage.
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月24日 9:53
*To:* Discussions about Cloud Foundry projects and the system overall.
*Subject:* Re: [cf-dev] "running_instances": -1
@Maggie -- you are probably right that -1 does not mean that the
deployment failed. But for my application the staging failed and I am
getting the following:
*"running_instances":-1,*
*"state": "STARTED"*,
*"package_state": "FAILED", "staging_failed_reason":
"BuildpackCompileFailed",*
It is very confusing. Why the app state is STARTED when the staging FAILED
? Also if the staging FAILED shouldn't the running_instances be 0 ?
What are all the scenarios where running_instances = -1 ?
Thank you,
Kris
On Thu, Jul 23, 2015 at 9:29 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com>
wrote:
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
--
________________________________________
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
--
Matthew Sykes
matthew.sykes(a)gmail.com