Null provider and failing early

[David Cheney]

The canonical use case for provider specific constraints is

'I want to make sure all my units are not in the same availability zone'

but the larger use case for Juju is

'you can describe your environment, then we can reconstruct that
entire environment on a different provider'

this is key to the cloud benchmarking story where we can deploy the
same environment on multiple providers.

That said, if provider specific constraints were not ignored, this
would break the Juju promise of portability between cloud providers.

The other part of this argument is, if constraints are ignored for a
specific provider they should not be discarded, the round trip from
ec2 -> maas -> openstack -> ec2 must not loose information along the
way.

On Tue, Aug 27, 2013 at 11:43 AM, Tim Penhey <tim.penhey at canonical.com> wrote:
> On 27/08/13 13:41, David Cheney wrote:
>> I think they should be ignored, but preserved.
>
> What is your thinking on this?  Why would we want to ignore them?
>
> I have my ideas why, but I'm wondering what others think.
>
> These are obviously the two choices we have:
>  * Fail
>  * Ignore
>
> Tim
>
>>
>> On Tue, Aug 27, 2013 at 11:40 AM, Tim Penhey <tim.penhey at canonical.com> wrote:
>>> On 27/08/13 11:50, Andrew Wilkins wrote:
>>>> On Tue, Aug 27, 2013 at 8:44 AM, Tim Penhey <tim.penhey at canonical.com
>>>> <mailto:tim.penhey at canonical.com>> wrote:
>>>>
>>>>     Perhaps we should have a sanity-check type callback into the provider
>>>>     with the constraints at the time we want to add a machine.  This would
>>>>     give the null provider the early fail mechanism, and could also allow
>>>>     other providers to error if people as asking for constraints that really
>>>>     don't make sense.
>>>>
>>>>
>>>> I'm sort of thinking out aloud here: maybe this could used for checking
>>>> environment-specific constraints too? Some kind of
>>>> "VerifyMachineConstraints" method that will ensure your add-machine/--to
>>>> constraints are valid for the current provider/environment. In this case
>>>> constraints may be nil, but the null provider would just always return
>>>> false.
>>>
>>> This is exactly what I'm thinking as well, but I had forgotten about the
>>> provider specific constraints.
>>>
>>> It does raise the question of what should happen if a provider specific
>>> constraint is passed to a provider that can't handle it.  My suggestion
>>> is we fail.
>>>
>>> Tim
>>>
>>> --
>>> Juju-dev mailing list
>>> Juju-dev at lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
>