carols10cents/gcloud-feedback.md Secret

## gcloud-feedback.md

      
    Raw
  

              gcloud-feedback.md
            
          
    Google Cloud Feedback

I tried to write down all the thoughts I was having as I had them, with enough detail for someone else to have a bit of a chance to understand what I was doing and what I meant. Which apparently means I wrote a LOT. I hope this is useful! Please let me know if you have any followup questions!
Background

I'm a Ruby/Rails developer and I'm extremely familiar with heroku's infrastructure and way of doing things. That most certainly has colored my experience with Google Cloud.
I decided to try out Google Cloud with an open source rails app that I have worked on in the past, rstat.us: https://github.com/hotsh/rstat.us It's a little bit old at this point, but not ridiculously so-- Ruby 2.1, Rails 3.2, mongo.
tl;dr

Google Cloud seems more powerful than heroku; it seems like you have a lot more control over your configuration and setup, which is definitely a plus when managing production apps that get lots of traffic. However, I wasn't able to find documentation that explained simply some of the things that seem super easy to do with heroku, namely adding a database and using environment variables to tell rails how to connect to that database. If I was doing this for work and getting paid for my time, I would definitely invest more time and effort to understand how Google Cloud does things, but for hobby projects that I'm working on in my free time and want to get up and running quickly, I'd go back to heroku.
I gave up and didn't get my app up and running with the database; if someone can point me to docs about how to find the mongo connection string for a mongo instance launched with Cloud Launcher and then how to set an env var in my Rails app VM so that Rails knows how to connect to that instance, I'd be happy to try again, but I failed to find anything that would explain a simple way to make that happen.
Things that I liked:


The gcloud CLI auth process was smooth and easy
Even though I didn't get to try it out, I like that the concept of deploying to a secret instance first and then promoting to the live URL was baked into the process.

Annoyances/Confusions (there are more throughout my narrative below but these were the ones that were most annoying that I think could be fixed easily):


The gcloud CLI asked me to confirm that my project was a ruby project at every turn (This looks like a Ruby application. Proceed to configure deployment for Ruby? (Y/n)?); couldn't it remember that after the first time?
In the generated custom Dockerfile, I'd make this change:

-# If you need to install any additional packages needed by your gems,
-# insert an "apt-get update" and "apt-get install" here.
+# If you need to install any additional packages needed by your gems,
+# uncomment the following two lines and specify your packages here.
+
+# RUN apt-get update
+# RUN apt-get -y install # ... specify your packages

I felt like I couldn't easily see what was going on with all my stuff and why. It could just be my unfamiliarity with the navigation of the google cloud UI or unfamiliarity with the google cloud jargon, but I also feel like error messages and status pages didn't have the information I expected them to have (examples of this are throughout the long story below).

The long story


When I first created my account, I see that I have one project called "API Project". I don't really know why I have it though-- what API? Am I supposed to change this one or is it just an example? What does it do? Can I make it go away? Should I make it go away? I'm just going to ignore it for now, since I don't have the answers to these questions.


I created a new project and made sure to enable billing as directed by the instructions. I wanted to make sure I did it right, so I looked on the Billing Overview page and at the bottom under "Projects linked to this billing account", it has one project with the project name "Project 23674473863" and project ID "23674473863". This is, in fact, the project I just created, but it was hard to tell this because I don't recognize the name or ID; neither of their values are the name I picked when I created the project ("rstatus-1337").


The gcloud init auth process is seamless and worked great 👍


After logging in with the gcloud CLI, it said "Enter project id you would like to use:". I entered "rstatus-1337" even though the billing overview page said the Project ID was "23674473863" (see above). I felt unsure about this but proceeded with what I would want to enter here.


Then it said "Your current project has been set to: [rstatus-1337].", cool, sounds like it worked.


Next:


[compute project-info describe] has failed
Not setting default zone/region.
Make sure Compute Engine API is enabled for your project.

Could not retrieve list of repos via [gcloud alpha source repos list]
Perhaps alpha commands are not enabled or the repos list command failed.

Hmmmm, that sounds like it didn't work. Or the CLI is expecting an existing project to live there, and I haven't created anything yet. I'm going to do the suggested "Make sure Compute Engine API is enabled for your project." in a minute, but it seems like that should be part of the setup instructions or done automatically for new projects if it's required.

Ok then:

Generally projects have a repository named [default]. Would you like
to try clone it? (Y/n)?  Y

This confused me. I don't know anything about google cloud platform or what my project has yet, so do I have a repository named [default]? It says generally projects do, sooooo let's try Y.

Next:

Where would you like to clone [default] repository to
[/Users/carolnichols]:
Cloning into '/Users/carolnichols/default'...
warning: You appear to have cloned an empty repository.
Checking connectivity... done.

Git repository has been cloned to [/Users/carolnichols/default]

Great. Guess my project had an empty repository named default! And now I have an empty default dir! Not the worst thing that's happened when I've guessed an answer to a question ;) Rming it and moving on.

So now:

gcloud has now been configured!
You can use [gcloud config] to change more gcloud settings.

Your current configuration is: [default]

[app]
use_appengine_api = True
[core]
account = carol.nichols@gmail.com
disable_usage_reporting = False
project = rstatus-1337
[meta]
active_config = default

Hmmmm, under [app] now it says "use_appengine_api = True"? Is that the same thing the message "Make sure Compute Engine API is enabled for your project." was talking about? If so, is it enabled now? If not, what's the difference?


I'm going to try to "Make sure Compute Engine API is enabled for your project" now. On the dashboard for my project, there is a nice thing that says "Enable APIs", that sounds relevant. Clicking on that gives a list of APIs to enable, and under Google Cloud APIs, Compute Engine API is first, so I clicked on that, then clicked the "Enable API" button at the top. (shrug) guess that's enabled now.


Back to the instructions, now running gcloud components update app. That worked fine. I like the ascii progress bar/separator showing what's in progress and what has been done when gcloud is doing a bunch of things :)


Ok, I think I'm ready to deploy an existing app. I'm using a rails project I've been involved with, rstat.us, instead of the sample sinatra app, because I like a challenge :) I've already cloned it, cd'd into the dir, and bundled, so now running gcloud preview app gen-config.


It correctly detected a Ruby application, yay! The desire in me to find the limits of systems wonders the criteria being used to decide this (I'm guessing looking for certain files like .ruby-version or Gemfile) and wonders what it would do if it saw indications of multiple languages, like a Gemfile and a Gruntfile.coffee and a package.json. I might try that in a bit.


When it said:


Please enter the command to run this Ruby app in production, or leave
blank to accept the default:
[foreman start web -p 8080]

So this project does have a Procfile, but it doesn't use foreman directly-- heroku makes that kind of transparent. I only have one process type defined in the Procfile, so I changed the command to what is in the Procfile (bundle exec puma -C config/puma.rb). If I had accepted the default foreman start, I wonder if it would have worked or not because this project does not have foreman in its gemfile; heroku just provides it. I wonder if yinz should do the same sort of thing that heroku does as far as installing foreman for you (or are you already and I'll never know because I changed the command)? Maybe i'll try putting this back to foreman start and seeing what happens later.


I kinda feel like I should commit the generated app.yaml before running gcloud preview app deploy app.yaml, but nothing says I should, sooooo I'm going to try not and see what happens ;)


Ok I get a wall of text:


WARNING: Soon, deployments will set the deployed version to receive all traffic by
default.

To keep the current behavior (where new deployments do not receive any traffic),
use the `--no-promote` flag or run the following command:

  $ gcloud config set app/promote_by_default false

To adopt the new behavior early, use the `--promote` flag or run the following
command:

  $ gcloud config set app/promote_by_default true

Either passing one of the new flags or setting one of these properties will
silence this message.

You are about to deploy the following modules:
 - rstatus-1337/default (from [/Users/carolnichols/Ruby/rstat.us/app.yaml])
     Deployed URL: [https://20151122t130537-dot-rstatus-1337.appspot.com]
     (add --promote if you also want to make this module available from
     [https://rstatus-1337.appspot.com])

This is a lot of text to read when I thought I was deploying, but I totally understand having important things to tell people that they should be aware of and not having a great time/place to tell them.
After reading this, ooooo!!! Is this for zero-downtime-deploys with an automatic "preview" version that you can check out first before going live-live?!?! If so, that is pretty cool!!!!! I was momentarily sad when I first saw "Deployed URL: [https://20151122t130537-dot-rstatus-1337.appspot.com]", ewww that is an ugly URL why is all that extra stuff in there, but then I kept reading through "(add --promote if you also want to make this module available from [https://rstatus-1337.appspot.com])" and reread and came to the conclusion that this is the secret "preview" URL where I can check that it works in production before making it live with --promote. This is really neat!!

Reading on:

Beginning deployment...
This looks like a Ruby application.

Proceed to configure deployment for Ruby? (Y/n)?

Wait, didn't I do this already as part of gcloud preview app gen-config? Whatever, we'll do it again. Oh, maybe this is for the server and the gen-config was for my local env? (shrug)


Thought while it's doing stuff: I should compare the time it takes to deploy to GCP and the time it takes to deploy to heroku


https://www.youtube.com/watch?v=O0wOD9TWynM


gem install -q --no-rdoc --no-ri foreman --version 0.78.0 Oh hey! it IS installing foreman automatically! Well then-- I think instead of asking for confirmation of a foreman start command to run in prod, it should say "We've detected a Procfile. Should we use that to run your app in production?" IMO. Since heroku does this totally transparently, I don't even know what command they run, so I would be unsure about confirming a command I've never actually seen. But "use detected Procfile" would be something I'd definitely feel confident approving.


Ok, first major roadblock/error!! Can't install nokogiri:


Installing nokogiri 1.5.11 with native extensions

Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

    /rbenv/versions/2.1.7/bin/ruby extconf.rb
checking for libxml/parser.h... yes
checking for libxslt/xslt.h... no
-----
libxslt is missing.  please visit http://nokogiri.org/tutorials/installing_nokogiri.html for help with installing dependencies.
-----
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.

Provided configuration options:
	--with-opt-dir
	--without-opt-dir
	--with-opt-include
	--without-opt-include=${opt-dir}/include
	--with-opt-lib
	--without-opt-lib=${opt-dir}/lib
	--with-make-prog
	--without-make-prog
	--srcdir=.
	--curdir
	--ruby=/rbenv/versions/2.1.7/bin/ruby
	--with-zlib-dir
	--without-zlib-dir
	--with-zlib-include
	--without-zlib-include=${zlib-dir}/include
	--with-zlib-lib
	--without-zlib-lib=${zlib-dir}/lib
	--with-iconv-dir
	--without-iconv-dir
	--with-iconv-include
	--without-iconv-include=${iconv-dir}/include
	--with-iconv-lib
	--without-iconv-lib=${iconv-dir}/lib
	--with-xml2-dir
	--without-xml2-dir
	--with-xml2-include
	--without-xml2-include=${xml2-dir}/include
	--with-xml2-lib
	--without-xml2-lib=${xml2-dir}/lib
	--with-xslt-dir
	--without-xslt-dir
	--with-xslt-include
	--without-xslt-include=${xslt-dir}/include
	--with-xslt-lib
	--without-xslt-lib=${xslt-dir}/lib
	--with-libxslt-config
	--without-libxslt-config
	--with-pkg-config
	--without-pkg-config
	--with-libxml-2.0-config
	--without-libxml-2.0-config
	--with-pkg-config
	--without-pkg-config
	--with-libiconv-config
	--without-libiconv-config
	--with-pkg-config
	--without-pkg-config

extconf failed, exit code 1

Gem files will remain installed in /rbenv/versions/2.1.7/lib/ruby/gems/2.1.0/gems/nokogiri-1.5.11 for inspection.
Results logged to /rbenv/versions/2.1.7/lib/ruby/gems/2.1.0/extensions/x86_64-linux/2.1.0-static/nokogiri-1.5.11/gem_make.out
An error occurred while installing nokogiri (1.5.11), and Bundler cannot
continue.
Make sure that `gem install nokogiri -v '1.5.11'` succeeds before bundling.
The command '/bin/sh -c bundle install && rbenv rehash' returned a non-zero code: 5
The command '/bin/sh -c bundle install && rbenv rehash' returned a non-zero code: 5
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

ERROR: (gcloud.preview.app.deploy) Docker build aborted: The command '/bin/sh -c bundle install && rbenv rehash' returned a non-zero code: 5
Deleted [https://www.googleapis.com/compute/v1/projects/rstatus-1337/zones/us-central1-f/instances/gae-builder-vm-20151122t130537].


One comment before I dig into trying to fix that: In addition to the app.yaml file that I haven't committed, I also have changes to my Gemfile and .ruby-version file (I updated to be at the latest ruby 2.1 version, this app is a bit old) that I have not committed with git. It looks like gcloud is deploying the current state of my files and not looking at git at all. I actually don't want it to do that, because then what I've got running in production doesn't match anything that git knows about. I'd prefer it to either warn or fail to deploy if there are uncommitted changes, because in the way I work, it's almost always a mistake if I'm doing that.


Ok nokogiri. Let's go. I see the "Customizing the image" section in the docs about apt-getting things-- I think I'm going to go down that route as opposed to upgrading nokogiri to 1.6 (that comes with libxml2 and libxslt), so that I can try out more of GCP and pretend I'm in a situation where I can't upgrade nokogiri (it happens).


So. Running gcloud preview app gen-config --custom:


This looks like a Ruby application.

Proceed to configure deployment for Ruby? (Y/n)?  Y

YES IT IS STILL A RUBY APPLICATION LIKE IT WAS THE LAST TWO TIMES YOU ASKED ME THIS GEEZ um uh I mean, it'd be nice if gcloud saved what kind of project this was somewhere so that it didn't have to keep asking me this all the time ;)
You've generated a Dockerfile that may be customized for your application.  To use this Dockerfile, please change the runtime field in [/Users/carolnichols/Ruby/rstat.us/app.yaml] to custom.

Can't you change that for me? I am teh lazy. You made the app.yaml file, you update it, gcloud.
(It may seem like I'm getting frustrated, and I am a little, but yinz asked for feedback so I'm noting everything I'm thinking about, even minor annoyances that really aren't that bad.)


FULL DISCLOSURE I haven't used Docker before, so apologies if I do something wrong. I'll try to separate out docker feedback from gcloud feedback ;)


So I notice that the Dockerfile now has hardcoded the ruby version I specified in my .ruby-version and Gemfile; which means when I update Ruby, I'll have to remember to update it in the Dockerfile as well. Is there a way to dynamically specify this in the Dockerfile so that it always reads from .ruby-version/Gemfile? I don't really know what's possible, but if this was possible, it would be nice to not have to give up that automatic config when switching to a custom Dockerfile. Again, minor.


Ok, I'm adding apt-get install libxslt-dev to the Dockerfile where directed, and adding an apt-get update before that as directed by the comment. I'd personally write this as:


# If you need to install any additional packages needed by your gems,
# uncomment the "apt-get update" and "apt-get install" lines and specify
# your packages here.

# apt-get update
# apt-get install # ... specify your packages

to make customization a tiny bit easier.

Running gcloud preview app deploy app.yaml again.

This looks like a Ruby application.

Proceed to configure deployment for Ruby? (Y/n)?  Y

ಠ_ಠ
Using Ruby 2.1.7 as requested in the Gemfile. I'm pretty sure that's a lie now, unlesssss I should have said "n" to the ruby question since i'm now "custom", but I definitely changed my app.yaml to be custom, shouldn't it be reading it from there? especially since the command I ran specified "app.yaml"? I'm kinda confused...
Oh hey:
Step 4 : APT-GET
Unknown instruction: APT-GET
Unknown instruction: APT-GET
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

ERROR: (gcloud.preview.app.deploy) Docker build aborted: Unknown instruction: APT-GET

Welp. This might fall under being new to docker. But I followed the instructions in that comment, and my Dockerfile looked like:
# If you need to install any additional packages needed by your gems,
# insert an "apt-get update" and "apt-get install" here.

apt-get update
apt-get install libxslt-dev

I happened to have someone more familiar with Docker sitting right next to me, who quickly pointed out that I needed to have RUN in front of those lines. So helping out people unfamiliar with docker is another advantage rearranging that comment would give you! Now I think it should be:
# If you need to install any additional packages needed by your gems,
# uncomment the following two lines and specify your packages here.

# RUN apt-get update
# RUN apt-get install # ... specify your packages


Here we go again: gcloud preview app deploy app.yaml

Step 5 : RUN apt-get install libxslt-dev
---> Running in de020991262c
Reading package lists...

Building dependency tree...

Reading state information...

The following extra packages will be installed:
libxslt1.1
The following NEW packages will be installed:
libxslt1-dev libxslt1.1
0 upgraded, 2 newly installed, 0 to remove and 16 not upgraded.
Need to get 935 kB of archives.
After this operation, 2920 kB of additional disk space will be used.
Do you want to continue [Y/n]?
Abort.

Sigh. Ok, my new recommendation is to make the comment in the Dockerfile say:
# If you need to install any additional packages needed by your gems,
# uncomment the following two lines and specify your packages here.

# RUN apt-get update
# RUN apt-get -y install # ... specify your packages


No whammies no whammies: gcloud preview app deploy app.yaml


ZOMG IT INSTALLED NOKOGIRI!!!! :yey: :yey: :yey:


ZOMG IT'S TAKING LONGER NOW SINCE IT'S ACTUALLY DOING STUFF


https://www.youtube.com/watch?v=O0wOD9TWynM


Welp:


Copying files to Google Cloud Storage...
Synchronizing files to [gs://staging.rstatus-1337.appspot.com/].
Updating module [default].../Deleted [https://www.googleapis.com/compute/v1/projects/rstatus-1337/zones/us-central1-f/instances/gae-builder-vm-20151122t142300].
Updating module [default]...failed.
ERROR: (gcloud.preview.app.deploy) Error Response: [13] Not enough VMs ready (0/2 ready, 2 still deploying). Version: 20151122t142300.388753752948606876

There's not really any information with this error message to know what I should do about this... are those VMs still deploying? Or did everything get shut down? If they're still going, how do I tell when they're done? What took so long-- is it something I did or something gcloud did? Can I increase this timeout?
I decided to go look at the project dashboard and see if that said anything... I see:
App engine
0 instances

Compute engine
1 instance

Cloud storage
3 buckets

which doesn't really tell me anything. Do these correspond to the 2 VMs referenced in the error message? Does this mean 1 succeeded and 1 failed? Am I supposed to have 1 app engine instance? (shrug)


So now I decided to try the Activity page instead of the Dashboard. Wowww there's a lot of Create VM Delete VM events. None of them look any different than any others though; I kind of hoped that there would be failed/succeeded/in progress statuses here. Clicking on the latest "Create VM" listing, that doesn't tell me either.


I clicked on the Name link in the expanded information for the latest create vm event. What I gleaned from this is that it's using CPU, but I don't know for what. I scrolled down, didn't see anything else useful like status, logs, list of running processes, or anything that would help me understand what state the VM is in and what it's doing. Near the bottom, I noticed a "Serial console output" link, which sounded potentially useful, I might be able to figure something out from console output, but when I click on it, I got a page that had the header and the sidebar but in the middle of the page just had a red exclamation mark and next to it, said "Failed to load". I have no idea whether this means my VM failed to load or the page that was providing the console output failed to load (aka is this my fault or gcloud's fault). I tried turning on firebug and reloading to try and figure that out, and heeyyy now it loads so I guess it was gcloud's fault!


And now I have LOTS of logs!! All the logs I could ever want. After much scrolling:


[7] Puma starting in cluster mode...

[7] * Version 2.9.0 (ruby 2.1.7-p400), codename: Team High Five

[7] * Min threads: 1, max threads: 1

[7] * Environment: production

[7] * Process workers: 3

[7] * Preloading application

syck has been removed, psych is used instead

[7] ! Unable to load application

/rbenv/versions/2.1.7/lib/ruby/gems/2.1.0/gems/mongo-1.9.2/lib/mongo/mongo_client.rb:486:in `connect': Failed to connect to a master node at 127.0.0.1:27017 (Mongo::ConnectionFailure)


Side note: in some of the logs I saw some terminal color codes:

2m ok �[39;49m�8�[?25h�[?0c.

it'd be nice to either not have those in there or interpret them for display in the web interface.


Sooooo yeah guess I need to figure out how to add mongo, I was wondering when I'd get to that ;) It would have been nice to see these logs in my terminal as output of the deploy command so that I wouldn't have to go looking for them.


Maybe there was something in the CLI that I missed. gcloud --help Ooohh components, that sounds like what I need to get mongo! I'm going to stop worrying about the logs and give that a try.


gcloud components list Hmmmm, this looks like components for gcloud, not components for my app like I guessed. To the web interface!


Let's try Enable APIs, even though I wouldn't call mongo an API really, search for mongo... nada. Ok that must not be it. Back to the dashboard


Deploy a prebuild solution? Aha, this looks more like it. Let's see if there's a mongo "solution" (that's not what I'd call it either but whatevs) Yay there is! Click click click


Estimated costs: $342.25/month WTFFFFFF wow that seems expensive. Compose.io is currently quoting me $18/mo/GB (https://app.compose.io/signup/svelte/mongodb). Whatever, I've got free trial money to burn.... Launch on Compute Engine.


Got a bunch of choices, ooo maybe I can make this cheaper. I don't care about replication so 1 node, bump down the machine specs, bump down the disk space, no arbiter, deploy.


"Your MongoDB deployment is ready" Cool, now how do I set the ENV vars to what to tell my rails app about this? The doc links at the bottom are to the main mongo docs, not to gcloud mongo docs.


Going back to the initial instructions, that recommends https://cloud.google.com/ruby/. Ok, samples, cool, let's take a look at the hello world sample app and see if it's too simple.


https://cloud.google.com/ruby/getting-started/hello-world copypasta:


Clone the Hello World app

Copy the Bookshelf sample app to your local machine:

$ git clone https://github.com/GoogleCloudPlatform/getting-started-ruby.git -b 1-hello-world 1-hello-world

Looks like a spot that should say "Hello World sample app" instead of "Bookshelf sample app"?


Ok yeah hello world doesn't use any sort of database. Let's try the Bookshelf example.


Scan scroll click scan, this tutorial supports Google Cloud SQL, Postgres, Google Cloud Datastore... datastore sounds closest to mongo since it's NoSQL, let's try that.


https://cloud.google.com/ruby/getting-started/using-cloud-datastore


Cloud Datastore represents just one of many storage options on Cloud Platform. This sample app supports multiple databases including Cloud Datastore and PostgreSQL.

Shouldn't that say "Cloud SQL and PostgreSQL" since I'm looking at the Cloud Datastore docs?

Configure settings section:

For example, suppose your project ID is my-project-1234: Then the development and production sections of your database.yml file would look like this:

development:
  dataset_id: my-project-1234

production:
  dataset_id: my-project-1234

Hmmm so we have a config/mongo.yml file instead of a database.yml file, and I don't think mongo has a dataset_id, that must be a Cloud Datastore thing.... I just need a URL to the mongo thing I just deployed and a way to set an ENV var where my app is running :(

I skimmed the tutorials-- saw the section about logging that I might go back to.
I decided to go back to my app's dashboard to look for anything I've missed... and my dashboard now says

Compute engine
3 instances

where it used to say 1. What? I thought I just added 1 mongo instance? What's the other additional thing? I clicked on Compute engine and it listed 2 gae-default things and one named rstatus-instance-1, I think that last one is my mongo instance but it doesn't say mongo anywhere so idk.


I can SSH to that instance from the browser, which is cool i guess, but I don't need to ssh to it, I just need the connection URL and need to tell it to rails :( :( :(


Maybe the setting of the env var has happened automatically, like happens in heroku when you enable an add-on. Let's try this web devshell thing and see if that can tell me. Ok, this is kind of neat, but also really slow and painful to type into with the lag compared to the typical experience of typing into ssh in the terminal... I probably would get frustrated trying to use this for anything nontrivial. Annnnd export doesn't seem to have anything about mongo.


I think I'm going to call it quits at this point. I've looked around, searched for "env vars" in the online help which led me to https://cloud.google.com/deployment-manager/step-by-step-guide/using-template-and-environment-variables , but I'm not sure if I'm even using deployment manager/templates/this kind of env var? What's Jinja2? What is all this? I just want to set one env var :(
Additionally, I can't tell if I'm spending money right now, and if I need to shut down things if I don't want to spend money. The estimated charges this month still says $0, but is that in the past or projected in the future based on what I have running right now? I remembered seeing something about cleaning up in the ruby tutorials, so I went back to that and learned how to stop everything. It'd be nice to have one way to stop all VMs for all versions in a project, including the default, without having to click into every VM.
I'm very familiar with Heroku and the way things are set up with Heroku, and gcloud is clearly different but I'm having trouble finding the corresponding concepts and procedures to do what I know how to do in Heroku in gcloud.