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 mandreou@redhat.com
 designates 209.132.183.28 as permitted sender)
Message-ID: <50C8A801.3090804@redhat.com>
Date: Wed, 12 Dec 2012 17:51:29 +0200
From: "marios@redhat.com" <mandreou@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: dev@deltacloud.apache.org
CC: jvlcek <jvlcek@redhat.com>, 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> <50C893B1.9020403@redhat.com>
In-Reply-To: <50C893B1.9020403@redhat.com>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

On 12/12/12 16:24, jvlcek wrote:
> 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.
>>>
> 
> Thank you David,
> 
>> 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.
> 
> My intention was to clearly show credit to Marios for the work he had done.
> Collapsing the patches into one would have made it appear that the
> entire solution was only my doing. That said I fully agree with your
> point about the one patch alone leading to issues.

hey - thanks Joe - just for future reference, this really wouldn't have
been a problem :) - though I appreciate the notion all the same. Plus,
my 'solution' was basically what you had come up with in the first place,

cheers, marios

> 
>>
>> 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)
> 
> OK will do in the future.
> 
>>
>> 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.
> 
> I'm  working another Jira for exactly the same issue on an
> Openstack template. https://issues.apache.org/jira/browse/DTACLOUD-346
> 
> I'll add this issue to that work.
> 
> 
> Thanks for the feedback!
> 
>   Joe
>