Open Stack

On 03/11/2016 10:25 AM, Chris Hoge wrote:
> 
>> On Mar 11, 2016, at 6:36 AM, Jean-Daniel Bonnetot <jean-daniel.bonnetot at corp.ovh.com> wrote:
>>
>> Agree, we are doing a non-standard stuffs when it’s required and we have to do it.
>> I’m not saying we can’t manage it in a different way, I’m saying that with different constraints we often need to deal and choose between answering customers needs, make our infrastructure stable and scalable and being fully compliant.
>>
>> I need to be more precise on the things we corrected on our infrastructure. We raise a 409 error on instance deletion when task_state is image_pending_upload.
>> So the modification is on Nova side (my bad, I told about Glance).
>>
>> Anyway, the steps in tempest.api.compute.images.test_images.ImagesTestJSON.test_delete_saving_image are:
>> 1. Creating an instance
>> 2. Snapshotting the instance
>> 3. Deleting the image while the image is still uploading
>> 4. Deleting the instance while the instance is still snapshotting (here we have our hack on the API)
>>
>> So the capability compute-images-delete can’t passe because of a non-standard API answer on … DELETE /v2/{tenantid}/server/{serverid} in a particular case which is "task_state is image_pending_upload".
>>
>> What I’m trying to say is that I’m not sure this kind of strange situation serve the interop goal.
>> Interop capabilities defined compute-images-delete as a requirement and it’s good, but the workflow used to test it is a little bit overkill to answer this question I think.
> 
> I’m not a fan of throwing out a test because of a breaking downstream change.
> I understand your concern, but my preference is to have the vendor attempt to
> fix either the upstream problem, the downstream problem, or the test problem. This
> would indicate a commitment to interoperability rather than a desire to just pass
> a guideline to get a trademark.
> 
> This indicates a larger issue that keeps coming up, where operators are deploying
> Ceph as supporting storage infrastructure, and breaking interoperability in the
> process. To me this is an indication that we should consider adding a ceph-backed
> deployment to the integrated gate so we can catch these issues earlier rather than
> later.
> 
> Despite not being an OpenStack project, Ceph is an important part of the
> operating ecosystem.

We do test with Ceph, and are retooling the jobs to start voting again
soon. This test passes with that
http://logs.openstack.org/38/291138/1/check/gate-tempest-dsvm-full-devstack-plugin-ceph-nv/04e1f2b/console.html#_2016-03-10_12_37_57_674

DELETE is *always* supposed to work, by design, on all things. Delete is
often the Ctrl-C of the cloud. I did this thing... you know what, it's
taking too long, I want to get rid of that, never mind.

This item came up in a different context in the Nova channel this
morning about wanting to prevent DELETE on this saving state, and the
response is *no*, this is the API design. Very much because the user is
expected to always have the ability to kill off their resources. They
are getting billed for them, and need to always be able to have control
to stop that.

	-Sean

-- 
Sean Dague
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20160311/bd1b6cfd/attachment.pgp>