Home / ubuntu / Questions / 365734
Accepted
Riccardo Magrini
Asked: 2013-10-26 09:09:09 +0800 CST

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

  • 772

following the official guide:

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"
juju

5 Answers

  1. Best Answer

    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.

    • 3

  2. 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.

    • 1

  3. 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.

    • 1

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

    • 1

  5. It asks credentials of cloud servers. If you like to test in your local use following command

    sudo apt-get install juju-local
    • 0