juju bootstrap doesn't report result of zookeepr install

[Francis J. Lacoste]

While developping the MaaS provider, we found out during testing that a juju bootstrap would succed, but the juju deploy would fail with Juju not being able to connect to zookeeper.

On closer examination, it appears that zookeeper isn't installed on the node which is something we need to fix on our side. But it would be nice if bootstrap made sure that everything is setup properly with zookeeper. Reporting errors early makes things easier to debug.

[Clint Byrum (clint-fewbar)]

There's been some discussion in the past of this idea.. that bootstrap should poll and wait for the instance to come up before it returns. I agree with this, but the concern of others was that users would think juju was slow when in actuality EC2, ubuntu mirrors, or the slowness of the install on bare metal would all contribute to the process taking a long time.

One way to combat this misconception would be to instrument more stages of the process. So we could poll the provider to see if the machine state is known yet, and make it clear in the messages.. "Waiting for machine to be provisioned by [maas|ec2|etc]" makes it clear that juju is at a point where it can't do anything else.

[Julian Edwards (julian-edwards)]

On Tuesday 13 Mar 2012 19:27:44 you wrote:
> There's been some discussion in the past of this idea.. that bootstrap
> should poll and wait for the instance to come up before it returns. I
> agree with this, but the concern of others was that users would think
> juju was slow when in actuality EC2, ubuntu mirrors, or the slowness of
> the install on bare metal would all contribute to the process taking a
> long time.
>
> One way to combat this misconception would be to instrument more stages
> of the process. So we could poll the provider to see if the machine
> state is known yet, and make it clear in the messages.. "Waiting for
> machine to be provisioned by [maas|ec2|etc]" makes it clear that juju is
> at a point where it can't do anything else.

A thousand times yes to more instrumentation. While experimenting myself I've
been sat there wondering what it's doing when it waits for things during
deployment and the only way to see what's going on is to get a debug log.

[Kapil Thangavelu (hazmat)]

So effectively bootstrap failed because the provider was still in development, and this seems to be about two things, recovering from a failed bootstrap, and notifying the user that the bootstrap failed.

[Clint Byrum (clint-fewbar)]

Whether Zookeeper or the new mongodb, it seems like it would be pretty simple to drop something in the object storage indicating success or failure of this critical service, then juju status on an in-progress bootstrap can show a pending state.

[Kapil Thangavelu (hazmat)]

juju can't access object store till provider credentials are sync'd which
pre-supposes successful installation.

On Sat, Oct 20, 2012 at 12:11 PM, Clint Byrum <email address hidden> wrote:

> Whether Zookeeper or the new mongodb, it seems like it would be pretty
> simple to drop something in the object storage indicating success or
> failure of this critical service, then juju status on an in-progress
> bootstrap can show a pending state.
>
> ** Changed in: juju
> Status: New => Triaged
>
> ** Changed in: juju
> Importance: Undecided => Wishlist
>
> ** Summary changed:
>
> - juju bootstrap doesn't ensure zookeeper is installed
> + juju bootstrap doesn't report result of zookeepr install
>
> --
> You received this bug notification because you are subscribed to juju.
> https://bugs.launchpad.net/bugs/954350
>
> Title:
> juju bootstrap doesn't report result of zookeepr install
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/954350/+subscriptions
>