Open Stack

Hi Sean,

Interesting feedback. The following discussion will probably be out of the target of this mailing list but the case should be considered.

The issue we had wit Ceph was Nova accepted to DELETE the instance even if task_state was image_pending_upload but the Ceph ressources wasn’t deleted (from Ceph point of view).
On the Ceph integration test, do you check this kind of situation?

Do not hesitate to redirect me on an other mailing list if you think it’s more appropriate.


—
Jean-Daniel Bonnetot
http://www.ovh.com
@pilgrimstack




> Le 12 mars 2016 à 01:37, Sean Dague <sean at dague.net> a écrit :
> 
> 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
> 
> _______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee