The Manual cloud and Juju

List of supported clouds > Manual

This document describes details specific to using the Manual (manual) cloud with Juju.

The Manual (manual) cloud is a cloud you create with Juju from existing machines.

The purpose of the Manual cloud is to cater to the situation where you have machines (of any nature) at your disposal and you want to create a backing cloud out of them.

If this collection of machines is composed solely of bare metal you might opt for a MAAS cloud. However, recall that such machines would also require IPMI hardware and a MAAS infrastructure. In contrast, the Manual cloud can make use of a collection of disparate hardware as well as of machines of varying natures (bare metal or virtual), all without any extra overhead/infrastructure.

When using the Manual cloud with Juju, it is important to keep in mind that it is a (1) machine cloud and (2) not some other cloud.

See more: Cloud differences in Juju

As the differences related to (1) are already documented generically in our Tutorial, How-to guides, and Reference docs, here we record just those that follow from (2).

Juju points of variation Notes for the Manual cloud
setup (chronological order):
CLOUD
supported versions: N/A
requirements: - At least two pre-existing machines (one for the controller and one where charms will be deployed).
- The machines must be running on Ubuntu.
- The machines must be accessible over SSH from the terminal you’re running the Juju client from using public key authentication (in whichever way you want to make that possible using generic Linux mechanisms).

(sudo rights will suffice if this provides root access. If a password is required for sudo, juju will ask for it on the command line.)

- The machines must be able to ping one another.

definition: You will need to supply a name you wish to call your cloud and the ssh connection string for the controller, the username@, or the .
- name: user-defined
- type: manual
- authentication types: No preset auth-types. Just make sure you can SSH into the controller machine.
- regions: [TO BE ADDED]
- cloud-specific model configuration keys: N/A
CREDENTIAL
definition: Credentials should already have been set up via SSH. Nothing to do!
CONTROLLER
notes on bootstrap: The machine that will be allocated to run the controller on is the one specified during the add-cloud step.

If you encounter an error of the form “initializing ubuntu user: subprocess encountered error code 255 (ubuntu@{IP}: Permission denied (publickey).)”:
Edit your ~/.ssh/config to include the following:
Host <TARGET_IP_ADDRESS>     
    IdentityFile ~/.ssh/id_ed25519
     ControlMaster no
See more: Bug #2030507 “[juju 3.1 - manual provider] strict confinement b...” : Bugs : Canonical Juju

other (alphabetical order:)
CONSTRAINT
conflicting:
supported?
- allocate-public-ip :x:
- arch :white_check_mark:
Valid values: For controller: [host arch]. For other machines: arch from machine hardware.
- container :white_check_mark:
- cores :white_check_mark:
- cpu-power :x:
- image-id :x:
- instance-role :x:
- instance-type :x:
- mem :white_check_mark:
- root-disk :white_check_mark:
- root-disk-source :x:
- spaces :x:
- tags :x:
- virt-type :x:
- zones :white_check_mark:
PLACEMENT DIRECTIVE
<machine> TBA
subnet=... :x:
system-id=... :x:
zone=... TBA
MACHINE With any other cloud, the Juju client can trigger the creation of a backing machine (e.g. a cloud instance) as they become necessary. In addition, the client can also cause charmed operators to be deployed automatically onto those newly-created machines. However, with a Manual cloud the machines must pre-exist and they must also be specifically targeted during charmed operator deployment.

(Note: A MAAS cloud must also have pre-existing backing machines. However, Juju, by default, can deploy charmed operators onto those machines, or add a machine to its pool of managed machines, without any extra effort.)

Machines must be added manually, unless they are LXD. Example:

juju add-machine ssh:bob@10.55.60.93
juju add-machine lxd -n 2

Further notes:
- Juju machines are always managed on a per-model basis. With a Manual cloud the add-machine process will need to be repeated if the model hosting those machines is destroyed.
- To improve the performance of provisioning newly-added machines consider running an APT proxy or an APT mirror. See more: Offline mode strategies.

RESOURCE (cloud)

Consistent naming, tagging, and the ability to add user-controlled tags to created instances.

N/A

Contributors: @swalladge , @whershberger, @hmlanigan

For the tables of constraints and placement directives, could we use emojis that are less similar for supported and not supported? Maybe :x: for not supported for example?

Currently the table is difficult to quickly scan, because at first glance they all appear to be green squares.

1 Like

Hi!

The “requirements” section is unclear about which ssh key needs to be authorized on the machines in the cloud. I initially took “contactable over SSH with public key authentication” to mean “accessible with a key located in the standard ~/.ssh/ dir”; It looks like it actually means "accessible over SSH with ~/.local/share/juju/ssh/juju_id_rsa.pub".

1 Like

Updated the doc, thanks! PS Also added you as a contributor to this doc – thanks again for your contribution!

1 Like

Having looked into this a little bit more with @hmlanigan , I’ve reverted the change in the docs. As @hmlanigan clarified, ~/.local/share/juju/ssh/juju_id_rsa.pub is used by Juju automatically for Juju machines, after provisioning.

As a general rule, if as a Linux user

  • you are able to do ssh ubuntu@x.x.x.x, then you don’t have to specify a key.

  • you have to do ssh -i <path-to-ssh-key> ubuntu@x.x.x.x, then you’ll have to provide a key. You can do so with the --private-key flag of the juju add-machine command.

You’re right; I spun a reproducer this afternoon and checked auth.log after bootstrapping the manual cloud. The key signatures are the ones I expect, not the ones from ~/.local/share/juju.

That said, I’m still not able to bootstrap a manual cloud based on the information on this page. I opened a new topic with more details.

I think it would still be good to call out public-key authentication in the doc here, passwords won’t work: “…must be accessible over SSH from the terminal you’re running the Juju client from using public key authentication”

1 Like

@whershberger Thanks for continuing to try and make it work. I’ll keep an eye on the other issue and update the docs accordingly, when I know how.