I did just try it again with the local provider, and I saw the same
behavior:
It is up, as I clearly wouldn't have anyone else to talk to:
$ juju status -e local
environment: local
machines:
"0":
agent-state: down
agent-state-info: (started)
agent-version: 1.19.4.1
dns-name: localhost
instance-id: localhost
series: trusty
state-server-member-status: has-vote
services: {}
But it doesn't actually think it is, because an ensure-availability call
later tries to remove it:
$ juju ensure-availability -e local --debug
2014-06-14 08:30:57 INFO juju.cmd supercommand.go:37 running juju
[1.19.4-trusty-amd64 gc]
$ juju status -e local
environment: local
machines:
"0":
agent-state: started
agent-version: 1.19.4.1
dns-name: localhost
instance-id: localhost
series: trusty
state-server-member-status: removing-vote
"1":
agent-state: pending
agent-version: 1.19.4.1
instance-id: jameinel-local-machine-1
series: trusty
hardware: arch=amd64
state-server-member-status: adding-vote
"2":
...
"3":
...
Note that none of those actually come up because I'm able to reproduce
Curtis's HA bug (with the local provider):
https://bugs.launchpad.net/juju-core/+bug/1329544
John
=:->
On Sat, Jun 14, 2014 at 8:41 AM, John Meinel <[email protected]> wrote:
> I just did "juju bootstrap" and then ran "juju status" afterwards. Note
> that this was manual, so it wasn't a "juju bootstrap && juju status"
> running it immediately after. However, I still saw:
> $ juju status -e amz-jam
> environment: amz-jam
> machines:
> "0":
> agent-state: down
> agent-state-info: (started)
>
> I thought we had landed a patch that fixed this (the one that made it
> refresh agent state as soon as Login completed).
>
> John
> =:->
>
>
--
Juju-dev mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
