Null provider and failing early

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2013-08-27 2:44, Tim Penhey wrote:
> Hi William,
> 
> I've been thinking about the null provider.  There are two things
> that currently bother me about it.

...

> Secondly is the add machine problem.  The point of the null
> provider is that it will never start an instance.  The problem at
> this stage is that there is no way for the CLI (or API) at this
> stage to know whether or not it is possible to create a machine, so
> one will be added to state before the provider has got a chance to
> say yay or nay, as this comes during the provisioner task.
> 
> What would likely happen then is that a machine would get added to 
> state, and the provisioner would record an error against it as the 
> provider says "nah, not creating a machine for you".
> 
> Ideally we'd like to fail earlier, preferably at the "try to put
> this machine in state" phase.

I feel like this is a general case of trying to provide useful
feedback to users as soon as we can. I would break it down slightly into:

a) A request that I expect will never complete
b) A request that I cannot complete right now
c) A request that I don't understand, but looks like one I can ignore.


I feel like that breaks down into (a) => Error and Fail, (b) => Warn
but continue, (c) Log but continue


There is some problem in deciding whether a current failure is an (a)
or a (b) case.

To take your NullProvider example. If I do "juju deploy service" with
no machines available, it can't do it. However, if I follow that up
with "juju add-machine ssh:XY" it will now be able to complete it.
Which leads me to think it is a (b) case.


Stuff like provider-specific constraints (ec2-instance-type) fall into
type (c) on providers that don't support that constraint. We *really*
want it logged somewhere that a given request from the user isn't
being honored (so they can realize whether their request was wrong, or
intentionally not applicable). I don't know whether it needs to be in
the user's face every time they do it (constant nagging just gets
ignored, and causes you to ignore the important ones).


The one step further is to try and give user feedback as early as
possible. Today for class (b) failures, we only really have "juju
status" to let you know that your request was accepted, but we seem
unable to fulfill it. If we could move some of the class-(b) warnings
into being given at the time of the request, I would be very happy.

To take your null provider example, today you would deploy (error
free) and then have to run "juju status" to see that there was a
provisioning error.

However, if you ran:
  juju deploy foobar
  Warning: no machines available

That would give you a good hint that you should use "juju
add-machine". We could even put that into the warning message
(especially if coming from the null provider).


As for what this is implemented as, what about calling it
"SanityCheckConstraints". So it is clear that we aren't guaranteeing
things will work after checking them, but we do some obvious sanity
checks.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlIcSvQACgkQJdeBCYSNAAMAmACgicHOUdalw5LlI8YeiQnOr7PW
4O0An0a5f0VTrm5Ua9aS9LiF3NO/wouS
=vHuM
-----END PGP SIGNATURE-----