[openstack-dev] [Fuel-dev] [OSTF][Ceilometer] ceilometer meters and samples delete

Ildikó Váncsa ildiko.vancsa at ericsson.com
Fri Jan 17 13:05:43 UTC 2014


Hi,

In my opinion it would be better to let the user to define a ttl value for his/her own samples. I do not see the use case, where it is needed to delete samples, also if the user is able to randomly delete some data, then the statistics functions will not generate a valid output for that data set, which was affected by the deletion. As the original question was about testing, I do not have a deeper knowledge about how testing works now regarding to generating and storing the samples. Maybe if there is a need for deleting data there, it can be considered that how we can handle that particular case.

How would we identify the samples, which should be deleted? If it is allowed to delete any samples from the system via the API, it does not sound good either. So if it is an all or nothing situation, I would say nothing.

Best Regards,
Ildiko

-----Original Message-----
From: Julien Danjou [mailto:julien at danjou.info] 
Sent: Friday, January 17, 2014 1:35 PM
To: Nadya Privalova
Cc: fuel-dev at lists.launchpad.net; OpenStack Development Mailing List (not for usage questions); Vladimir Kuklin
Subject: Re: [openstack-dev] [Fuel-dev] [OSTF][Ceilometer] ceilometer meters and samples delete

On Fri, Jan 17 2014, Nadya Privalova wrote:

> I would ask in another way.
> Ceilometer has a mechanism to add a sample through POST. So it looks 
> not consistent not to allow user to delete a sample.
> IMHO, insertion and deletion through REST looks a little bit hacky: 
> user always has an ability to fake data collected from OpenStack 
> services. But maybe I don't see any valuable usecases.
> Anyway, it seems reasonable to have both add_sample and delete_sample 
> in API or not to have neither.

>From the user PoV, that totally makes sense, agreed.

--
Julien Danjou
# Free Software hacker # independent consultant # http://julien.danjou.info



More information about the OpenStack-dev mailing list