1

This is my default app.yaml file:

runtime: custom
env: flex
service: api

runtime_config:
   jdk: openjdk8

handlers:
- url: /.*
  script: this field is required, but ignored

automatic_scaling:
  min_num_instances: 1
  max_num_instances: 10

When I deploy with my updated app.yaml file, the file is just reset to the previous, default one. This is what I try:

runtime: custom
env: flex
service: api

runtime_config:
   jdk: openjdk8

handlers:
- url: /.*
  script: this field is required, but ignored

automatic_scaling:
  max_num_instances: 1

resources:
  core: 1

UPDATED BELOW:

OK so I got this one above to work now. It seemed the api-service had two app.yaml files and I had to change in both. This now has a config on the GCP web interface that looks like the one I deployed: min 1 and max 3. BUT, even so, it sometimes creates 4-5 instances. :S

NOW, to my other application, scheduler, this is what I put in the app.yaml file:

runtime: java8
service: 'scheduler'
inbound_services:
- warmup
derived_file_type:
- java_precompiled
threadsafe: True
auto_id_policy: default
api_version: '1.0'
handlers:
- url: (/.*)
  static_files: __static__\1
  upload: __NOT_USED__
  require_matching_file: True
  login: optional
  secure: optional
- url: /
  script: unused
  login: optional
  secure: optional
- url: /.*/
  script: unused
  login: optional
  secure: optional
- url: /_ah/.*
  script: unused
  login: optional
  secure: optional
- url: /cron/v1/simulations
  script: unused
  login: optional
  secure: optional
resources:
  cpu: 1
  memory_gb: 1
  disk_size_gb: 1
  volumes:
  - name: ramdisk1
    volume_type: tmpfs
    size_gb: 0.5
automatic_scaling:
  min_num_instances: 1
  max_num_instances: 2
  cool_down_period_sec: 180
  cpu_utilization:
    target_utilization: 0.6

And when it's deployed, on GCP its config looks like this:

runtime: java8
api_version: '1.0'
env: standard
threadsafe: true
instance_class: F1
inbound_services:
  - warmup
handlers:
  - url: '(/.*)'
    application_readable: false
    static_files: "__static__\\1"
    require_matching_file: true
    upload: __NOT_USED__
  - url: /
    script: unused
  - url: '/.*/'
    script: unused
  - url: '/_ah/.*'
    script: unused
  - url: /cron/v1/simulations
    script: unused
automatic_scaling:
  min_idle_instances: automatic
  max_idle_instances: automatic
  min_pending_latency: automatic
  max_pending_latency: automatic

And here's a screenshot of the result:

enter image description here

Very confusing.

Dan Cornilescu
  • 327
  • 4
  • 10

1 Answers1

1

There are some options mixed from configurations for two different runtimes.

Every option for runtime: custom is described in here. handlers: and runtime_config: are not mentioned for the custom runtime because they are part of the Java runtime here.

core: 1 doesn't exist in any of previously mentioned configurations and I suspect you wanted to use cpu: 1 instead, which can be used in both configurations. Plus, when trying to deploy second app.yaml I get an error saying that core: doesn't exist, so your configuration shouldn't be deployed in the first place.

Updated:

In the article that describes instance managment and mentions that

You will be billed only for idle instances up to the number of maximum idle instances that you set for each service.

Which implies that at some point you may have more idle instances than what you have set as a maximum but they will be not billed. And the graphic on that image supports that claim.

A.Queue
  • 166
  • 5
  • core was a misspell from my part, since I didn't copy that part of the code. You're right, it's CPU. Thanks for your answer, I'll look into it. – djokerndthief Mar 07 '18 at 12:51
  • OK, so I tried to make some changes and still have issues. Please look at my updated post above. – djokerndthief Mar 07 '18 at 14:13
  • Here's a screenshot to show how rididulous this is: https://imgur.com/a/OWJK7 – djokerndthief Mar 07 '18 at 15:44
  • Thank you for another update. OK, I get that answer, but the fact is still that our billing sum has gone up threefold since I noticed these changes in creations of instances. And I have no clue as to why the simple program that scheduler is would create, now, 12(!) instances when it only uses 1 and never more. Also, looking at the config from the GCP web, the scheduler's max instances is set to automatic - which means we should be billable for more than 0 instances? I mean, obviously I didn't manage to set a maximum idle instance number, but should still be billable I assume. – djokerndthief Mar 08 '18 at 16:25