Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

We are trying to bootstrap Juju onto another machine in the MAAS cloud but are getting a "ERROR could not access file *-provider-state gomaasapi: got error back from server: 403 forbidden." error.

When we run juju bootstrap a .jenv file is created and this error is returned with the * in the '*-provider-state' replaced by the Juju Agent Name of the MAAS node. When we delete the environment (by deleting the .jenv file), the same error is returned but filename just listed jsut as 'provider-state'. The node does not move into Allocated state even if the .jenv file is created. Running anything - juju bootstrap, juju status, juju destroy-environment, gives the same error.

Backstory: There used to be a bootstrapped Juju environment existing on this MAAS server previously. We had to change our network configurations, and couldn't get the allocated node to be deleted. So, we thought we could unistall juju and start over. Clearly, it didn't work and there are some links left of it still on our server. How do we get rid of it? We did get the allocated node deleted using the maas shell but this error still persists.

We are running MAAS 12.04 LTS, Juju 1.16.

share|improve this question

1 Answer 1

First off, deleting the .jenv file does not destroy the environment, it just makes it impossible to connect to it from you juju client. The .jenv file contains all the necessary information to connect to the environment, including juju API server addresses, SSL certificates, etc.

To destroy a juju environment, use: $ juju destroy-environment my-maas-env-name -y

This will properly deallocate the MAAS nodes, delete the storage entries, including the provider-state file.

Also, reinstalling juju on your client machine cannot solve your issue, because the environment and its allocated nodes are still there and to MAAS it appears as you're still using the environment.

To solve your specific issue, I'd do the following:

  • Your environment is no longer accessible because the .jenv file is gone, and since it's auto-generated you cannot regain access to the environment just by creating an empty .jenv file.
  • Delete the .jenv file if it's still there.
  • Login as the MAAS administrator in the MAAS web UI, go to "Nodes" and for each allocated node, click on the node and click "Stop node" on the node page. This will deallocate the node and bring it back to Ready.
  • Using the MAAS CLI, you can list all files in the environment storage: $ maas my-maas-session files list, and delete the provider-storage file: $ maas my-maas-session file delete XXXX-provider-storage (the exact file name you get from the files list, it will look like c4ba50c2-268c-4cf4-8be1-c0903982c8a8-provider-state; and my-maas-session corresponds to your CLI user session - it can be any string, created with e.g. $ maas login my-session-name http://192.168.50.2/MAAS/ <maas-api-key> - use the same key you specify with "maas-oauth" in environments.yaml)
  • Bootstrap again, once it's done it should work.

Hope this helps,

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.