I try to create VM from machine image but I get an error:
"The resource 'projects/my-project/regions/europe-west4/resourcePolicies/instance-1' was not found"
Actually instance-1 is located in europe-central2-a zone and i need to clone in europe-west4 zone.
Maybe there are nuances that are not indicated in the documentation. Has anyone encountered such a problem? Any suggestions?
Many thanks
The problem is that for a few days now I cannot run the installation due to lack of resources in my zone and I need to move it to another zone.
I tried redundancy but there are no resources for it either.
Hi Evgeny Kim expecting that you have already created a multi-regional image and this is not related to image availability I'm providing this answer. resourcePolicies are not supported by machine images follow this doc for more information, instead of machine image you can create a boot disk and manually import it to your required location and relaunch the vm. follow this doc for more information.
Related
I have tried various ways which is available on stack overflow but not single one works .i was getting error everytime whenever i tried to register my gitlab runner everytime please provide descriptive answer
error: first path segment in URL cannot contain colon error
Since you did not provide a description of your setup, it is hard to pin down the problem. I'm also not an expert on GitLab and I just recently started tinkering around with my own local GitLab instance installed via Docker.
For me I wanted to connect a GitLab-Runner to my GitLab in the local network. That's where I tumbled upon the error you are mentioning. I am using a different port for the GitLab server, which was neccessary because some other services are already using the default ports. The solution for me was to add the prefix http:// in front of the ip. After that, the registration went flawlessly.
So instead of writing for example
123.456.789.XXX:YYYY
I had to write
http://123.456.789.XXX:YYYY
Of course the ip can be different according to your network.
If you provide more information, it would be easier to solve your problem.
And in case you solved it on your own, feel free to share your solution.
I'm currently trying to develop a cloud in my pc using virtual box. The idea is that I have 2 virtual machines, one which devstack installed (all in one) and the other with osm mano. Right now both have everything installed. Hence, I can log in to mano via user and password 'admin' as well as to devstack.
Current properties:
VM1 (devstack): IP (enp0s8) -> 192.168.56.101
Login to 192.168.56.101 -> correct
VM2 (mano): IP (enp0s8) -> 192.168.56.105
Login to 192.168.56.105 -> correct
As some of you may guess, I have 2 network interfaces in every vm, the first one being NAT (enp0s3 with 10.0.2.15 IP) and the second one being Host Only (192.168.56.x according to virtual box).
Needless to say, I can ping from one virtual machine to another without any problem.
Now, in the past I've being using devstack (ubuntu 18.04) in order to play with it a little bit, learn how to deploy instances, create groups and so on. Indeed, I developed a topology with an instance as a router and nagios as the monitoring tool system. It worked and I learnt a lot!
Anyway, what I want in this case is starting from scratch (scratch meaning having downloaded mano and devstack but without going further). So here I am, trying to integrate OSM with Devstack, making use of osm-vim command as it is:
osm vim-create --name openstack-site --user admin --password my_openstack_password --auth_url http://192.168.56.101:5000/v3 --tenant admin --account_type openstack
In this case, my openrc file (downloaded from horizon) resulted in my auth_url being:
export OS_AUTH_URL=http://192.168.56.101:5000/v3
What I'm trying to get my head into is how it's possible that this doesn't work, as whenever I log-in to mano web interface (after osm-vim command) I go to VIM accounts and operational state equals to "error".
Any kind of help would be much appreciated, as I've being struggling for a week now.
Thanks in advance!
I had the same problem. At the beginning I thought It was a network problem, but finally I found out It was due to a SSL problem. The most easy solution is to put a specific flag to avoid the SSL verification until the developers fix it. "--config '{insecure: True}'"
I also encountered this problem when I finished installing OSM-10 and OpenStack-Ussuri for Ubuntu18.04 some days ago. I solved this problem by change the url "--auth_url http//:192.168.23.18:5000/v3" to "-- auth_url http//:controller:5000/v3" and put "192.168.23.18 controller" in the ro container "/etc/hosts". The "controller" here is the host name where you install your openstack and which is used is your keystone authentication urls. Maybe you also have solved this problem but this problem is so troublesome and I hope more people do not be annoyed at this~
So I installed a single host Openshift OKD v3.11 cluster. I installed it on a VM running Centos 7.8.2003.
It seems to have installed ok except that it continually streams verbose logs to /var/log/messages. Around 5 logs per second and all seem to be about throttling requests. Example of a typical log message:
******Jun 13 15:49:13 centos7 journal: I0613 14:49:13.011402 1 request.go:485] Throttling request took 196.341689ms, request: GET:https://172.30.0.1:443/api/v1/namespaces/openshift-service-cert-signer/serviceaccounts/service-serving-cert-signer-sa*****
The only reference I have managed to find is a question here but the access to the discussion is only available to those with deep pockets.
https://access.redhat.com/solutions/3348921
I assume these logs are nothing to worry about and so my main question is what is the "best"/cleanest/simplest/easiest way to ensure the Openshift cluster doesn't continue to fill up /var/log/messages but will still log any important messages there?
I would recommend looking at the root cause for this behavior. These messages indicate that there are a lot of requests coming to your API. Typically this is due to some application performing calls in a tight loop leading to this many messages. In your case check your openshift-service-cert-signer if you can see any warnings or an abnormal amount of log messages.
If you want to get rid of the throttling messages, you can increase the amount of Queries per second (QPS) for the API server: Recommended Practices for OKD Master Hosts (lower part).
The only reference I have managed to find is a question here but the access to the discussion is only available to those with deep pockets. https://access.redhat.com/solutions/3348921
I do not understand why you're saying that, as I can access that document with my free Red Hat account without any subscriptions. Have you tried with a free account as it says on the site?
Simon's answer was helpful but I've finally got to the bottom of this.
The problem was simply that the version of Docker I had installed was old. At the time of writing the latest version of Centos is 7.8.2003 and if you install that and then simply run "yum install docker" hoping that you'll get something at least reasonably new and certainly compatible with the rest of the linux installation, you'll probably be making a mistake.
The right thing to do is to follow the simple steps here:
https://docs.docker.com/engine/install/centos/
The reason I found the problem was because excessive logging of my openshift cluster wasn't the only issue. I started seeing strange behaviour of other containers. A process of trial and error narrowed down the issue to the default Centos version of docker. Once I followed the page above all my problem vanished including the original problem of /var/log/message getting hammered by openshift containers.
The main reason I decided to answer my own question was because surely someone else is going to be as impatient/thick as me and simply install Centos7 then try "yum install docker" without knowing they're about to enter a world of pain.
I have an old Debian Compute Engine instance (created and running since December 2013) and got an email warning about the turndown of Legacy GCE and GKE metadata server endpoints (more details at https://cloud.google.com/compute/docs/migrating-to-v1-metadata-server).
I followed the directions for locating the process and found that the requests were coming from /usr/share/google/google_daemon/manage_addresses.py. The script seems to be the same as what's at https://github.com/gtt116/gce/blob/master/google_daemon/manage_addresses.py (also with what's in that directory).
I don't recall installing this, so I'm imaging it came with the provided Debian image I used in 2013.
Does anyone know what this manage_addresses.py script is, what it does, and what I should do with it now that the legacy metadata server endpoints are turning down? Is it safe to just stop running it? Or is there a new script I should replace it with? Or should I just try to update it myself to use the new endpoint?
I dug around and was able to trace /usr/share/google/google_daemon/manage_addresses.py as being installed by a package called google-compute-daemon. A search for that brought me to https://github.com/GoogleCloudPlatform/compute-image-packages#troubleshooting which explains that google-compute-daemon has been replaced with python-google-compute-engine. That led me to https://cloud.google.com/compute/docs/images/install-guest-environment . I followed the instructions there and manually installed the guest environment.
I noticed during installation that it said it was removing the google-compute-daemon package (and a packaged called google-startup-scripts), so this seems like the right thing. And I'm no longer seeing any requests to the legacy endpoints. So it seems like at some point the old guest environment failed to update.
TLDR; If you have this problem, follow the instructions at https://cloud.google.com/compute/docs/images/install-guest-environment#installing_guest_environment to manually update the guest environment.
Newbie to GCE. I created an VM instance. I successfully RDP'd to the instance and successfully retrieved metadata. I then created an image from this instance. Then created a new instance from my image. But I can't ping or RDP into the new instance. I deleted everything and performed these steps again but still have the same problem.
This is a Windows instance. I know that Windows instances can take a while to start up. I tried for well over half an hour just in case.
Any ideas what might be wrong ?
Thanks,
Peter
I seem to have found the issue. The problem occurred when I ran the standard sysprep command (windows\system32\Sysprep\sysprep.exe) to ready my disk for image creation. Once I tried gcesysprep instead, it worked. I found this command down in the snapshot help (https://cloud.google.com/compute/docs/disks#create-snapshot-windows).