unit placement can only go to machine 0

[Paul Larson]

I have an bundle that will mostly be deployed to an openstack cloud environment, but one service needs to go to a maas system that will have to be manually added to the environment via juju add-machine.

My initial thought was to specify "to: ssh:ubuntu@maas-node-1" in my bundle but this was not possible. Failing that, I tried adding the machine, which got added as machine 1, and specifying "to: 1" but this generated an error as well. It looks like unit placement only allows machine 0.

Talking to hazmat on irc, he explained that this is because only machine 0 can be guaranteed to exist. The short-term recommendation was that there could be an option to disable this check and allow the user to target other machines.

[Brad Marshall (brad-marshall)]

This is particularly important when using HA for the bootstrap nodes - we can ensure, or at the very least assume, that there'll be 3 (or more) initial nodes, and without the ability to deploy to specific machine ids that aren't 0, it makes it very difficult to add extra things to these nodes.

I've worked around this by having to add a manual juju deploy and juju add-unit lines to our deployment here, but its definately suboptimal, I'd much prefer to be able to do the whole thing in juju-deployer.

Please let us know if you need any more details about this use case, or anything else.

[Kapil Thangavelu (hazmat)]

just to note that there are more placement options extant than just
machine, there's a fairly rich language for co-location of services and
containerization.

On Wed, Oct 1, 2014 at 1:19 AM, Brad Marshall <email address hidden>
wrote:

> ** Tags removed: canonical-is
> ** Tags added: canonical-bootstack
>
> --
> You received this bug notification because you are subscribed to juju-
> deployer.
> Matching subscriptions: deployer
> https://bugs.launchpad.net/bugs/1324129
>
> Title:
> unit placement can only go to machine 0
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju-deployer/+bug/1324129/+subscriptions
>

[JuanJo Ciarlante (jjo)]

> just to note that there are more placement options extant than just
> machine, there's a fairly rich language for co-location of services
> and containerization.

Thanks, we are using those indeed as:
#1 manual run:
  juju deploy local:trusty/ubuntu openstack-ha --to 0
  juju add-unit openstack-ha --to 1
  juju add-unit openstack-ha --to 2

#2 E.g. at deployer cfg:
  keystone:
    to: [ openstack-ha=0, openstack-ha=1, openstack-ha=2 ]
  (ditto other services)

FYI in above example, we'd want to avoid #1 manual step.

[Paul Collins (pjdc)]

I have a pair of extremely large machines for running postgres on bare metal, which I am manually provisioning into an openstack juju environment so that I can deploy ancillary services on openstack instances. Some assistance from juju-deployer with such scenarios would be welcome.

[Jorge Niedbalski (niedbalski)]

This patch https://code.launchpad.net/~makyo/juju-deployer/machines-and-placement/+merge/251857 landed support for v4 bundles, that explicitly allows you to place services into different machines or containers.

Subsequently this patch: https://code.launchpad.net/~niedbalski/juju-deployer/fix-lp1454720 added support for existing machines.

I think this bug must be marked as fix commited.