ensure-availability (aka HA) should work with manual provider

[Kapil Thangavelu]

ensure-availability seems to think it has to create new machines even if there are pristine machines in the environment. on manual provider it suggests unhelpfully to provision more machines, even though it will never use them. i suggest it at least scan for pristine machines matching constraints before allocating new ones.

ie. I have a new three machine manual provider environment

$ juju status
environment: ocean
machines:
  "0":
    agent-state: started
    agent-version: 1.21-alpha1.1
    dns-name: 162.243.123.121
    instance-id: 'manual:'
    series: trusty
    hardware: arch=amd64 cpu-cores=2 mem=2001M
    state-server-member-status: has-vote
  "1":
    agent-state: started
    agent-version: 1.21-alpha1.1
    dns-name: 162.243.51.21
    instance-id: manual:162.243.51.21
    series: trusty
    hardware: arch=amd64 cpu-cores=2 mem=2001M
  "2":
    agent-state: started
    agent-version: 1.21-alpha1.1
    dns-name: 104.131.201.155
    instance-id: manual:104.131.201.155
    series: trusty
    hardware: arch=amd64 cpu-cores=2 mem=2001M
services: {}

I'd like to set things up for ha mode

$ juju ensure-availability --debug
2014-08-16 17:56:36 INFO juju.cmd supercommand.go:37 running juju [1.21-alpha1-trusty-amd64 gc]
2014-08-16 17:56:36 DEBUG juju.api api.go:151 trying cached API connection settings
2014-08-16 17:56:36 INFO juju.api api.go:234 connecting to API addresses: [162.243.123.121:17070 10.128.231.71:17070]
2014-08-16 17:56:36 INFO juju.state.api apiclient.go:252 dialing "wss://162.243.123.121:17070/environment/0e03bafc-ddd0-4a18-8d5b-159f9d7c6441/api"
2014-08-16 17:56:36 INFO juju.state.api apiclient.go:252 dialing "wss://10.128.231.71:17070/environment/0e03bafc-ddd0-4a18-8d5b-159f9d7c6441/api"
2014-08-16 17:56:36 INFO juju.state.api apiclient.go:175 connection established to "wss://162.243.123.121:17070/environment/0e03bafc-ddd0-4a18-8d5b-159f9d7c6441/api"
2014-08-16 17:56:36 ERROR juju.cmd supercommand.go:323 failed to create new state server machines: use "juju add-machine ssh:[user@]<host>" to provision machines

[Kapil Thangavelu (hazmat)]

unfortunately the implementation of ha and core machine job management is
going to need significant reworking to support this :-(

On Fri, Jan 16, 2015 at 8:55 AM, Dean Henrichsmeyer <
<email address hidden>> wrote:

> ** Tags added: cloud-installer landscape
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1357760
>
> Title:
> ensure-availability (aka HA) should work with manual provider
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju-core/+bug/1357760/+subscriptions
>

[Blake Rouse (blake-rouse)]

Dang it I would really like to see this fixed. I am trying to setup Juju in a HA configuration using the manual provider for deploying MAAS 2.0 in HA configuration. Here is the setup I am trying to do for this configuration.

The following would be done using the manual provider.

physical-0 (bootstrap)
  machine-1 (lxc, postgres)
  machine-2 (lxc, maas-region)

physical-1 (enable-ha)
  machine-3 (lxc, postgres)
  machine-4 (lxc, maas-region)

physical-2 (enable-ha)
  machine-5 (lxc, postgres)
  machine-6 (lxc, maas-region)

With juju in HA and MAAS in HA then the same Juju could be pointed at the deployed MAAS. So you use Juju to deploy MAAS, then you use the same Juju to deploy OpenStack on MAAS, then you use the same Juju to deploy workloads on that OpenStack.

Not supporting the manual provider in this kinda hurts as with deploying MAAS you will most likely use the manual provider as you have nothing to start with for Juju to connect. I have Juju deploying MAAS in HA, I am only missing this "enable-ha" for Juju.

Here is the output for Juju using 2.0-beta5:

blake@blake-ubnt-desktop:~/Code$ juju status
[Services]
NAME STATUS EXPOSED CHARM

[Units]
ID WORKLOAD-STATUS JUJU-STATUS VERSION MACHINE PORTS PUBLIC-ADDRESS MESSAGE

[Machines]
ID STATE DNS INS-ID SERIES AZ
0 started 192.168.122.2 manual: xenial
1 started 192.168.122.3 manual:192.168.122.3 xenial
2 started 192.168.122.4 manual:192.168.122.4 xenial

blake@blake-ubnt-desktop:~/Code$ juju enable-ha --debug
2016-04-26 01:53:18 INFO juju.cmd supercommand.go:60 running juju [2.0-beta5 gc go1.6.1]
2016-04-26 01:53:18 INFO juju.juju api.go:213 connecting to API addresses: [192.168.122.2:17070 192.168.122.3:17070 192.168.122.4:17070]
2016-04-26 01:53:18 INFO juju.api apiclient.go:494 dialing "wss://192.168.122.2:17070/model/8177eb7c-c21d-4449-89e9-deff1a925aea/api"
2016-04-26 01:53:18 INFO juju.provider.manual provider.go:159 enable-os-refresh-update was not defined. Defaulting to true.
2016-04-26 01:53:18 INFO juju.provider.manual provider.go:159 enable-os-upgrade was not defined. Defaulting to false.
2016-04-26 01:53:18 INFO juju.api apiclient.go:271 connection established to "wss://192.168.122.2:17070/model/8177eb7c-c21d-4449-89e9-deff1a925aea/api"
2016-04-26 01:53:18 DEBUG juju.juju api.go:362 API hostnames unchanged - not resolving
2016-04-26 01:53:18 DEBUG juju.juju api.go:147 failed to connect via bootstrap config: aborted
2016-04-26 01:53:18 DEBUG juju.api apiclient.go:520 health ping failed: connection is shut down
2016-04-26 01:53:18 ERROR cmd supercommand.go:448 failed to create new controller machines: use "juju add-machine ssh:[user@]<host>" to provision machines

[Gary Franz (garyf-1)]

I am attempting a similar setup to Blake Rouse's description, using juju 2.0.1, and getting similar results, in that I can not get an HA set to work using the manual provider. I am keenly disappointed that enable-ha is not possible using the manual provider.

One of the bugs marked as a duplicate, https://bugs.launchpad.net/juju/+bug/1617884 indicates that this may not be answered until Juju 2.1.0 - is there usually any kind of status for bugs like this, now that this has been marked as Low priority?

The absence of high-availability for this kind of management makes it much harder to advocate for expanding use of Juju to manage MAAS deployments in more than test-environment cases.

[Anastasia (anastasia-macmood)]

Marking this bug as a 'won't fix' for Juju 1.x as it is not a critical bug.

[Gary Franz (garyf-1)]

Is there a separate bug for Juju 2.0, or is fix status being tracked here? I'm happy to register my interest wherever the fix status for Juju 2.0 will be tracked, as a functional "enable-ha" process would be very useful.

[Anastasia (anastasia-macmood)]

The bug for Juju 2.0 is tracked here. The project we use for these bugs is "juju" and it's marked as an affect project in the bug's top section.

[Pedro Guimarães (pguimaraes)]

I am facing a similar issue, but I am trying to run:

juju enable-ha -n 1 --to 1 (where 1 is a machine I manually added to controller model)

I've filed a separate bug for this:
https://bugs.launchpad.net/juju/+bug/1832393

[Tim Penhey (thumper)]

This bug has been fixed for some time when the placement directives were added to enable-ha. Not sure exactly when this was.

@pguimaraes the command you are typing there is invalid, and we should give better error messages.