I need to get the oldest instance from an instance group. I am using the following command:
gcloud compute instance-groups managed list-instances "instance-group-name" --region "us-central1" --format="value(NAME,ZONE,CREATION_TIMESTAMP)" --sort-by='~CREATION_TIMESTAMP'
But it seems --sort-by is not working or I am using it a bit wrong.
Could you please suggest the right way.
It's probably creationTimestamp not CREATION_TIMESTAMP.
See: instances.list and the response body for the underlying field names.
It's slightly confusing but gcloud requires you to use the (field|property) names of the underlying request|response types not the output names.
Another way to more readily determine this is to add --format=yaml or --format=json to gcloud compute instances list (or any gcloud command) to get an idea of what's being returned so that you can begin filtering and formatting it.
Related
I have a set of clusters split between two projects, 1 and 2. Currently, need to use gcloud init to switch between the two projects. Is there any possibility of having both projects active under the single configuration? Or, is it possible to have two configurations simultaneously active? I would hate to have to use init every time to switch between the two. Thanks!
gcloud init should only be used to (re)initialize gcloud on a host. The only time I ever use it is when I install gcloud on a new machine.
gcloud uses a global config that can be manipulated with the gcloud config command. IMO (I've been using GCP for 9 years) the less you use gcloud config, the better for your experience.
I think you're much better placed specifying config explicitly with gcloud commands.
Every gcloud command can include e.g.:
--project=${PROJECT} to specify the project to use
--account=${ACCOUNT} to specify the gcloud auth'd account to use
--region=${REGION} or --zone=${ZONE} or --location=${LOCATION}
etc.
Using gcloud commands and explicitly setting flags to specific the project, account, location etc. makes it trivial to flip between these and often (though not always) in a more intentional way.
I am trying to filter a fleet of cloudsql instances based on if they have a recommendation using gcloud cli.
For example I want to list the all the instances that are nearing storage capacity.
I tried this but no luck:
➜ gcloud sql instances list --project <project-name> --filter='recommendations:on'
➜ gcloud sql instances list --project <project-name> --filter='recommendations:*'
WARNING: The following filter keys were not present in any resource : recommendations
Listed 0 items.
Any help please?
You can use the Recommender API through the gcloud CLI to work directly with these recommendations for your instances. In this case, try using the gcloud recommender recommendations list command and passing the --recommender=RECOMMENDER flag with any of the available Cloud SQL recommendations (including out of disk):
gcloud recommender recommendations list --project=PROJECT_ID --location=LOCATION --recommender=google.cloudsql.instance.RECOMMENDER
Adding more context for gcloud sql instances list, the available filters for any given gcloud command can be seen by sampling the YAML output (using --format=yaml), as noted in the documentation. I tried it, but recommendation data is not returned as an available property.
GceClusterConfig object has property internalIpOnly, but there is no clear documentation on how to specify that flag through gcloud command. Is there a way to pass that property?
That feature was first released in gcloud beta dataproc clusters create where you can use the --no-address flag to turn that on. The feature recently became General Availability, and should be making it into the main gcloud dataproc clusters create any moment now (it's possible if you run gcloud components update you'll get the flag in the non-beta branch even though the public documentation hasn't been updated to reflect it yet).
When executing gcloud rolling update list the following error is thrown :
gcloud alpha compute rolling-updates list --group some-group --zone us-east1-b
ERROR: (gcloud.alpha.compute.rolling-updates.list) Collection [replicapoolupdater.rollingUpdates] is not registered
Is there a way around this issue using gcloud ?
This alpha list command was broken sometime in March. The fix for it will be coming out most likely this Wednesday with release 115.0.0.
You can also grab very old gcloud (probably a version before 99.0.0) from https://storage.cloud.google.com/cloud-sdk-release.
Note that this command group will be deprecated as soon as replacement is place, and users are discouraged from using it.
I am trying to set an environment variable from a script added to an instance metadata. I added the metadata from file using the command:
gcloud compute instances add-metadata server-1 --metadata-from-file file=~/meta.sh
and the script is
#!/bin/sh
export SERVER="ide"
it seems is doing nothing when I reboot the server
The --metadata-from-file flag reads the values for the specified metadata keys from the specified files. In your example, you are assigning the contents of ~/meta.sh as the value for the metadata-data key 'file'.
In order to do something with 'file', you need to read its value from the instance (server-1) and act on it. There are some special metadata keys that are used by compute engine during certain times of the instance life-cycle. For example, 'startup-script' is a key that is read and executed during start-up. I think you intended to use this key. So, try this:
gcloud compute instances add-metadata "server-1" --metadata-from-file startup-script=~/meta.sh
For more details on metadata usage, run:
gcloud compute instances add-metadata --help
or go here:
https://cloud.google.com/compute/docs/metadata
6 years old question, but for future reference for myself and others:
Setting environment-variables in the startup-script doesn't seem to work, but what you can do is write them to your .bashrc - in my example, I set them like this:
gcloud compute instances add-metadata etl-pipelines --metadata startup-script='#! /bin/bash
echo "
export USER='${USER}'
export PASSWORD='${PASSWORD}'
" >> /home/USERNAME/.bashrc
better would of course be to check if that string is already inserted into the VM, but that wasn't relevant for me as I kill the VMs quite quickly anyway.
Alternatively, in this SO answer, it is described how to user curl to get the env-vars directly from the metadata, but I haven't looked further into it yet.