flight-delay-demo problem

[Mark Shuttleworth]

On 30/01/15 19:12, Samuel Cozannet wrote:
> Yeah, the bundle fails because there is a race condition happening. Instead
> of quickstarting it, use the deploy script (00-deploy.sh) and you should be
> alright.

Today, all you can see is that a charm has finished doing all the things
that it expected to have to do so far. That doesn't actually tell you
that the whole system is up, though, especially for complex systems of
many parts. For example, a dashboard might have been installed and
configured correctly, but without its backing database, it's not useful.
Worse, if one part needs to take advantage of another part in order to
bring itself up, you can get race conditions like the one you ran into.
Today, you have to (basically) wait and watch the whole system and use
your knowledge of what the parts do, to judge where you stand.

Shortly, however, the charms will have the ability to declare:

 * explicit status ("I'm up")
 * explicit blocking ("I need my config tweaked manually" or "I am
waiting for that database to come up")

In this way, when you deploy a whole lot of things at once (like a
bundle) the system can take care of chasing down all the sequencing and
dependencies and give you a systemic view of whether you are done.

For the moment, we tend to use rules of thumb to know when to proceed
(as in Sam's examples below). I bet the deploy.sh Sam referenced has
some waits and some handcrafted peeks into the details of status or
progress. That needs to be automatic, and will be, shortly. I believe
this is on track for April. It's particularly important for larger and
more complex bundles, or cases where you have
systems-that-depend-on-systems, like analytics-apps-depending-on-hadoop.

Mark

> The most important thing is that you need the Hadoop cluster up & running
> (YARN + 4 compute nodes) up and running before you start deploying PIG. By
> up and running, I mean everything green on the GUI, including relations.
> The script takes care of that as it checks and waits until this is done
> before it moves to the next stage.
>
> Note that the deployment takes ~75min to complete, and you need a LOT of
> resources (like 5x quad core, 16GB RAM machines). Better do that on a
> cloud.