I've been using GCE and gcloud for a few weeks now. A new set of VPN tools were released in alpha last Dec. 3rd (https://cloud.google.com/compute/docs/vpn), and I need to start testing with them.
The problem is that gcloud doesn't seem to recognise this new set of tools, and I get errors like:
$ gcloud compute target-vpn-gateways create --region us-central1 --network default vpn1
ERROR: (gcloud.compute) Invalid choice: 'target-vpn-gateways'.
$ gcloud compute vpn-tunnels describe
ERROR: (gcloud.compute) Invalid choice: 'vpn-tunnels'
target-vpn-gateways and vpn-tunnels are just not part of the command groups.
So, I though of updating the core and compute components, but they're all up to date. This seems so new that there's no information at this time in Google Cloud documentation about updating the SDK to be able to use these VPN tools.
Any ideas? I'm using OSX in case it matters.
Thanks a lot in advance!
EDIT:
As of March 2015, the documentation has been updated and it's now in beta stage:
https://cloud.google.com/compute/docs/vpn
So, to answer my own question according to this update, beta VPN functionality can be accessed by updating components this way:
$ gcloud components update beta
Sorry about the confusion here. Google Cloud Platform support is still in limited preview state. What this means is that the API calls only work for specially whitelisted projects and that the normal gcloud build doesn't yet include VPN support. (Because it would be potentially confusing if the gcloud command existed but would always fail do the API not being enabled yet.)
As I understand it your best bet for getting your project whitelisted is to go through the GCP sales office:
https://cloud.google.com/contact/
I'm going to try to get the docs updated so that the situation is more clear.
It was announced in GCP Live that VPN will be available in Q1, 2015; that means Beta and GA is likely to happen between Jan- Mar.
the updates i have been receiving is the beta launch is likely around end Feb 2015.
Related
I am currently creating and deploying a function to be executed periodically in the Cloud Functions for Firebase scheduler as shown below.
The key point is that I want it to be executed every day at 0:05 Japan time as .timeZone('Asia/Tokyo').
The deploy itself is working fine, but when I look at the content in GCP's Cloud Scheduler, the Time Zone is set to (America/LosAngeles) as shown in the image below, and the actual execution time is off from Japan time.
I manually changed the time zone to Japan time in the Cloud Scheduler function management screen and confirmed that the desired behavior was achieved, but when I deploy the function again, it is still set to (America/LosAngeles).
I thought it might be affected by the region of GCP itself, and that I would have to change the region of GCP, but I haven't found where I can change it from.
However, I thought that I should be able to specify the .timeZone for each function from the code. I'm at a loss.
I don't know how to solve this problem, and I'm wondering if anyone can help me.
exports.XXX = functions.pubsub
.schedule('every day 0:05')
.timeZone('Asia/Tokyo')
.onRun((context) => {
///省略
});
Thank you in advance.
I have experienced the same problem too. There's also a similar question asked here and the solution to downgrade the firebase-tools works for me.
This could be related to your CLI version, Make sure it is updated and if you keep experiencing issues, you should contact firebase support to submit a bug request HERE.
Another solution is that the region could be set as undefined inside your Google Cloud Platform (GCP) resource location.
Just be warned that setting the GCP location isn't recommended unless you know what you are doing and you want to set all your default locations.
Reference: default-cloud-location
firebaser here
It looks like there is a bug in version 9.12 of firebase-tools that forces all Cloud Functions to be deployed in pacific timezone, regardless of the timezone you set in the code.
Upgrading to version 9.12.1 should fix the problem. For further details on the problem, see this issue on the Github repo.
Since the tns-plugin-firebase update to version 15. When doing sidekick cloud builds I receive the message:
Unable to find a specification for Firebase/Core -> 5.5
I followed the intructions fron the community which basically tells to do pods repo update, I even rm -rf the .cocoapods folder and reinstall it.
When building locally it works, but when doing cloud builds with sidekick I received the abve mentioned message.
Is possibl that the pods repo update has to be done in the sidekick server too?, because if not I don´t have a clue why this is happening!!!
Thanks for ideas or hints.
Javier
The issue is indeed related to the Sidekick cloud build service. The pods management is done entirely on the cloud machines, even when you build from a macOS system.
Having said that, the pod is now updated to the latest available version and after a couple of hours (time needed to propagate the changes to the entire infrastructure), you should no longer experience the "Unable to find a specification for Firebase/Core -> 5.5" error while building for iOS in the cloud.
I installed the firebase command line tool and logged in successfully. I type
firebase init
in terminal, within my project directory, and I get the option to choose Database, Functions, or Hosting. I use the arrows and space bar to select Functions, press enter, and am presented with a list of projects. From this point forward I cannot do anything in terminal. I have to quit terminal in order to use it again. I am running OSX El Capitan, 10.11.6. I contacted Apple Support and they recommended talking with Firebase first, who in turn recommends asking stack overflow first. Any idea what the problem may be?
See the comment above, Node v8.0 and 8.1 both had regressions that broke the Firebase CLI. I upgraded my version of Node from 8.1.0 to 8.1.3, and everything works fine.
I wanted to launch an instance with high availability with out having risk factor i.e, an instance will be launched in multiple regions(zones) that to sync the state like database(master-slave). When some applications got installed, same should reflect in another region/zone also(mostly image format). Can we do that?.
I have checked some links based on this. I got a confusion after reading all the docs.
Host-aggregate/Cell in openstack
Nova evacuate command
Buildbot tool
Exactly what is the difference among. VM replication & syncing is possiblein Openstack?
To the best of my knowledge, Open Stack does not support VM replication for now.
There is a component called Remus under the Xen project, which could potentially used by manual configuration as Open Stack supports Xen (https://www.xenproject.org/directory/directory/projects/70-remus.html). But it seems to be slow and unstable.
The newest approach is called reversed virtual machine replication (http://dl.acm.org/citation.cfm?id=2996894&CFID=918229768&CFTOKEN=85577813), this one seems to be very interesting and some critical problems in VM replication is well defined and elegantly solved. However, I did not find the open source project for it.
Do we have any cli/api to check openstack development version..i mean whether my system installed havana or grizzly.I searched the openstack cli/api docs but i don't find any relevant.
OpenStack has a number of elements if you want to verify state.
Each of the component projects and each of the python-client api bindings have their own versions. Then there are configurable options for addressing API versions in REST queries.
I took a crack at building an API for the very purpose of verifying this data as well as all python dependencies a while back with the aim of cross verifying that against a vulnerability database but I simply haven't had the time to bring it to completion.
This would be a very useful feature I think.
You might look at your pip requires if you installed from source. Alternatively you can follow the debian package version chain from dependencies and that should provide good insight into what is installed on your system though it's not exactly verified.