JUJU and ERROR environment has no access-key or secret-key

Question

following the official guide:

• https://jujucharms.com/docs/stable/clouds-maas

and considered that I've generated the ssh key (added it to UI of MAAS) and the API key, my environments.yaml file presents in this way:

environments:
  maas:
    type: maas
    maas-server: 'http://x.x.x.x/MAAS/'
    maas-oauth: 'NDPA86PsEzS7bFynSy:vqJLkyHUJbvYzbtY5Q:sXXXXXXXXXXXXXXXXXXXXXX
    admin-secret: 'nothing'
    default-series: precise
    authorized-keys-path: ~/.ssh/id_rsa.pub # or any file you want.

when I try to run the command:

juju bootstrap

receive the following error:

ERROR environment has no access-key or secret-key

Someone can explain me where is the wrong?

• MAAS and JUJU are installed using their ppa stable on an Ubuntu 12.04.3 Server
• I've already enlisted 2 machines on my Maas and they are in Commissioning status
• In the environments.yaml file the line "default" has as value "maas"

Solution 1

When nodes in MaaS are in the commissioning state, they are not available for Juju to use. When the nodes are ready for allocation, they will show in MaaS as the Ready state.

When you bootstrap using Juju, it creates a node that will queue future deploy and relation setting commands to be run at the correct time during the installation of the various services.

The gomaasapi: got error back from server: 409 CONFLICT error is a generic error meaning that Maas encountered and error while trying to fulfill your request. In your case, because all of your machines are in a commissioning state and not a ready state, MaaS has no nodes that Juju can use to set up the bootstrap machine on. Because of that, you get the 409 CONFLICT error.

When nodes are in the commissioning state, they should be booted up, running an image from the MaaS server that prepares them for use. You may want to check that the nodes that are supposedly commissioning are booted up and not stuck at some boot prompt or turned off. If they are running, try connecting a monitor to them and see what you can see.

If they are not running, check and see if you have the power setting set in MaaS correct -- MaaS may not be able to signal the machines to boot (using IPMI, WOL, etc) and therefore the commissioning image is never booted and run and the nodes are stuck in the commisioning state without human intervention. (If this is the case, you can get past this by manually (as in physically if the machines are physical, or by telling VirtualBox to start the VM if that is what you are using) powering on the nodes that are stuck in the commissioning state.)

If you are using virtual machines to test MaaS, let me know and I will update my answer -- there are some quirks to testing MaaS with virtual machines.

Solution 2

I was able to get it working by running the command juju switch local.

Solution 3

From the specified error, I can assume you're using juju-core and trying to use the EC2 provider somehow. Are you sure you don't have any other environments in your environments.yaml? You'll need to specify default: maas at the top-level of your environments.yaml, or alternatively use juju switch maas on the command line. It'll be helpful to post your complete environments.yaml, as well as more context from the command output (which command did you run?), by passing --show-log as an argument.

Solution 4

Richard, if you are still trying to test MAAS within a virtual environment I may be able to help you. I have MAAS successfully running on a Virtual Machine interacting with two other large VM Servers that have their own virtual machines. In my environment, the MAAS server controls and boots the VMs on my VM Servers. I have been able to successfully deploy Wordpress and a number of other small applications on my VM Servers (Virt-Manager, QEMU and KVM based). One of the key pieces of advice is to use MAAS 13.10; the code is very stable and there are a number of important fixes and features over 12.04 LTS. I found that using the "default:maas" at the beginning of my environments.yaml caused it to fail, I would advise you to use the -e switch with your bootstrap command if you are deploying to a cloud (e.g. Azure, AWS, HP Cloud).

You will need to edit /etc/maas/pserv.yaml to get PXE booting working. In the section on TFTP uncomment the line designating the "root", the line designating the "port" and the line defining the generator.

The "Fast Installer" did not work with my VM Servers, so if you are virtualised, maybe give that feature a miss in the first instance.

The "Charms" have their own built in definitions ("constraints") on the CPUs and Memory required to run them. It is not made clear within the documentation, but I found I got the 409 CONFLICT generic error attempting to deploy Wordpress and mysql on anything with less than 2048MB RAM, I think I also had to put 2 CPUs each on my VMs. It might be different for you this is just what I found.

View more solutions

Comments

[Riccardo Magrini]

I modified the default section and run again the juju command, this time the error is the following: ERROR cannot start bootstrap instance: cannot run instances: gomaasapi: got error back from server: 409 CONFLICT

[Michael Gundlach]

@RiccardoMagrini Do you have machines enlisted in your maas master?

[Riccardo Magrini]

@Marco Yes, I've already enlisted 2 machines on my Maas and they are in Commissioning status

[Riccardo Magrini]

thanks for your support and I' so sorry if I reply just now. To know how this system works I'm testing MaaS and Juju service in a Virtual enviroment (VirtualBox). If you can help me don't hesitate to answer. thanks a lot.

[Riccardo Magrini]

I want to upgrade about that, now all the nodes (virtual enviroment) are in ready status.