Tag Info

New answers tagged

0

The reason was, that when ive started to mess with the update, i switched to root user. And then, still as root, i did the $juju status and other commands.. Once im back at my user, it works fine. uf. A massive rock felt from my heart. It might be useful for somebody else in future.


0

I faced the same issue. the problem was node was getting Ip from the other DHCP server. which is on another network.


1

You could try using juju bootstrap --upload-tools as a workaround. It should avoid the need for Juju to go out to the internet for getting the tools.


4

The best thing todo is to wait until this Thursday (23rd October) and then upgrade to the latest release of OpenStack Charms, which support console configuration options using spice or vnc via the charm itself, rather than you having to hack stuff into you environment directly: juju set nova-cloud-controller console-access-protocol=spice should then just ...


1

Before you start playing with Juju, check your MAAS correct function. Each time you add a new node in MAAS GUI and hit commision node, it should automaticaly boot the machine (node), run the commisioning scripts and then it will turn off the node with Ready state. You can do this as many times as you want and this way you can check that MAAS is able to ...


1

It is missing the dependency - python-crochet. Had similar problem and it was solved by doing this. More on the solution can be found on https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1311765.


1

In my case I had wakeonlan as power mode and had to power-up my box to pxe mode after issuing the juju bootstrap command. On bootstrap, Juju will acquire the node in Maas and deploy the OS based on the type Debian or Fast which you have configured for the node - this install time takes long and not within 10mins. So you should update your environment.yaml ...


0

Looks like the "got insecure response" is the issue. Found this solution from StackOverflow: http://stackoverflow.com/a/14923549/1692452 This is related to the new DNSSEC feature which is now enabled by default. This might indicate the DNS resolvers/forwarders you are using does not support DNSSEC so the response appear to be insecure to your server. ...


1

I just discovered that MAAS uses either Etherwake or Wakeonlan to boot the nodes, if using power type wake-on-lan. Those are not installed by default, and are not dependencies of MAAS. Just install Etherwake or Wakeonlan from the standard Ubuntu repo apt-get install etherwake or apt-get install wakeonlan Then, when you manually add a node using MAAS, ...


2

It isn't possible just yet. I'm working on a bunch of user commands right now that I'm hoping will get into the 1.21 release. One of which will allow you to change the password.


1

I think I solved it. I incorrectly understood how MAAS worked, and unfortunately the documentation is not very clear about it. "Ready" only means that the node can be used, it does NOT mean that there is already an OS on it at that point. I just went on into the documentation and bootstrapped Juju, et voila, when I started my nodes, one of them PXE-booted ...


0

The problem was fixed by setting the time zone of the machine/n to be same as MAAS server


0

No, ip address was set correctly. This issue was resolved afted upgrading juju to 1.20.8. With MAAS 1.5.2 it works.


1

If you can access the internet from your MAAS server with the two NICs, and also enabled IP forwarding and NAT, you only need to make sure the MAAS cluster controller manages DNS and DHCP for its intranet NIC, and you set the "Router IP" to the same value as the NIC's IP. This will set all nodes' default gateway to that IP in they should be able to access ...


1

If you've deleted your $HOME/.juju/ directory, which contains all the SSH keys and certificates juju has generated, without also destroying your juju environment, you won't be able to access the environment from juju anymore, as the credentials and keys are lost. What I'd recommend is to bootstrap a new environment on your MAAS, using correctly commissioned ...


1

According to this related question and answer - http://askubuntu.com/a/437151/207309, this might be due to a DNS issue. If you can double-check your MAAS cluster controller (in the MAAS web UI) is set to manage DNS and DHCP on the its network interfaces? You might need to also go into your MAAS settings page and add a backup DNS, like 8.8.8.8 and see if it ...


0

Your no-proxy setting has incorrect format. It should be a comma-delimited list of IP addresses, not a CIDR range. Take a look at this related question: http://unix.stackexchange.com/questions/23452/set-a-network-range-in-the-no-proxy-environment-variable I'd recommend you set no-proxy: 127.0.0.1,172.19.202.71 instead and try again. If it does not work, ...


0

When you say "i started at first the maas server, then the node where juju was bootstrapped " do you mean you've started the node juju was using by powering it on or by using the MAAS web UI to start it? If it's the latter, then the node will get recomissioned (that's by design, as you're essentially telling MAAS "I don't want to use this node anymore as ...


0

According to the cloud-init log output you might have an incorrect maas-server setting in your $HOME/.juju/environments.yaml. Can you double-check you have something like this in your environments.yaml file: maas-server: 'http://localhost:80/MAAS' instead of: maas-server: 'http://{localhost}:80/MAAS' The specified URL in the maas-server setting must be a ...


1

It's possible that it was finding the precise versions of juju-gui and puppermaster. You could try the following commands to force getting the precise charms: juju deploy cs:precise/mysql juju deploy cs:precise/rabbitmq-server


2

This is answering the question independent of Blender 3D, assuming rendering in general. (The answer was started before an edit of the question adding the reference to Blender 3D) MAAS is a system to manage a cluster in a dynamic way. It is helpful if you often change your cluster hardware, or the services deployed on it, or the instances running on ...


0

After setting the private subnets that I wanted to allow access to the Squid proxy in /etc/squid=deb-proxy/allowed-networks-src.acl liek so I still had this issue; # private networks 192.168.1.0/24 I added the following to my /etc/squid-deb-proxy/squid-deb-proxy.conf: cache_peer proxy.domain.com parent 8080 0 no-query default login=anonymous:password ...


1

A MAAS cluster is for mass-deploying individual nodes that you deploy services onto, there is no compute sharing between MAAS nodes.


0

Probably you want non-linux virtual machines on top of OpenStack. Remember MAAS handles the hardware and is a Ubuntu solution. Once you have MAAS you install JUJU for orchestration and building of OpenStack. OpenStack + the hypervisor of your choice (KVM i.e.) make it feasible to install VMs similar to VMware. Of course you could use SaaS (Service as a ...


0

I recommend you wait for maas 1.6 to be merged into the trusty default ppa. Running the upgrade with ppa:maas-maintainers/stable, it appeared to work initially. I have found a number of migration issues such as maas being unable to match nodes to pre-existing tags.


1

I don't think this kind of management is within MAAS's scope. That sounds like a job for other tools, the ones that come to mind are Landscape (https://landscape.canonical.com/), puppet and chef. That said, if all your nodes are deployed with MAAS, they will be quite homogeneous, so you can use tools like dsh to execute the same command on multiple nodes, ...


0

Have a look in /var/log/nova/nova-scheduler.log. You should find some hints there why the scheduler could not deploy the node.


0

MAAS is run by your webserver, try sudo /etc/init.d/apache2 restart. If you use another webserver, you need to restart that.



Top 50 recent answers are included