Mailing-List: contact dev-help@deltacloud.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@deltacloud.apache.org
Received-SPF: pass (athena.apache.org: domain of jvlcek@redhat.com designates
 209.132.183.28 as permitted sender)
Message-ID: <50F86EDA.5030600@redhat.com>
Date: Thu, 17 Jan 2013 16:36:26 -0500
From: jvlcek <jvlcek@redhat.com>
Reply-To: jvlcek@redhat.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: dev@deltacloud.apache.org
CC: David Lutterkort <lutter@redhat.com>
Subject: Re: DTACLOUD-379 using Marios's 409 solution.
References: <1355264833-1154-1-git-send-email-jvlcek@redhat.com>
 <1355270726.25895.29.camel@avon.watzmann.net>
In-Reply-To: <1355270726.25895.29.camel@avon.watzmann.net>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

On 12/11/2012 07:05 PM, David Lutterkort wrote:
> On Tue, 2012-12-11 at 17:27 -0500, jvlcek@redhat.com wrote:
>> DTACLOUD-379 using Marios's 409 solution.
>>
> ACK to this; stylistically, the two patches should be squashed into one,
> since after applying 1/2 triggering this error will cause a server error
> because of a missing template.
>
> Also, the commit message is way too terse; it should contain a sentence
> on what the problem was (RHEV-M does not allow deletion of templates
> that are in use) and what the fix was (propagating the error cleanly)
>
> Related to this: looking at the XML template for image, we generate
> links for 'create_instance' and 'delete_image' unconditionally. That
> probably needs to be changed so we only create links for actions that
> can currently be performed.
>
> David
>
>


David,

Regarding the last paragraph in the above email. It's not clear
to me what conditions Deltacloud should be checking prior to
creating the links for image 'create_instance' and 'delete_image'.

I think it's back end specific. I know EC2 allows the deletion of
an in use AMI but RHEVm doesn't.

Can you please explain what you have in mind?

Thanks,
  Joe