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

Dmitry Iakunchikov diakunchikov at mirantis.com
Mon Jan 20 11:29:20 UTC 2014


David,

You're completely right,

The main problem is that ceilometer has possibility to create samples, but
not to delete. Because of that there is no possibility to remove OSTF
created data.

Actually another way is to use time_to_live, but as you sad "As an
operator, I’d expect that my data is retained even for items that have been
removed"(c)


2014/1/17 David Easter <deaster at mirantis.com>

> I’d like to make sure I understand the question.  Is this the scenario?
>
>    - A user installs Mirantis OpenStack
>    - The user runs the Mirantis OpenStack Health Check (OSTF) against
>    Ceilometer
>    - The Health Check creates a VM against which ceilometer can collect
>    data
>    - Ceilometer collects the data from this VM for an amount of time and
>    stores the data in mySQL
>    - The Health Check then ends the test, removing the VM
>    - The data collected about this sample VM is retained in mySQL and is
>    not removed.
>
> Is this basically correct?
>
> If so, I’d ask if Ceilometer removes data from VM’s or nodes that have
> been deleted from OpenStack during normal operation or if the data is
> retained in the run-time scenarios as well?  If so, wouldn’t this be a
> general requirement to remove data about entities that no longer exist in
> the environment vs. an issue specific to Health Check (OSTF)?
>
> As an operator, I’d expect that my data is retained even for items that
> have been removed, but I agree that there should be a way for an operator
> to make a decision to remove stale data – either based on time or as a
> manually executed operation.  Removing data automatically right away could
> lead to a loss of historical information that could be used for longer term
> analysis and billing.
>
> Or am I misinterpreting the situation and Ceilometer already allows for
> deletion of data – and the question is just whether we should remove the
> data collected during the test?  If that is the only question, then yes –
> we should remove the data after the test is done.
>
> Thanks,
>
> -Dave Easter
>
> From: Dmitry Iakunchikov <diakunchikov at mirantis.com>
> Date: Friday, January 17, 2014 at 5:10 AM
> To: Nadya Privalova <nprivalova at mirantis.com>, "OpenStack Development
> Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>,
> Dmitry Iakunchikov <diakunchikov at mirantis.com>, Mike Scherbakov <
> mscherbakov at mirantis.com>, Vladimir Kuklin <vkuklin at mirantis.com>, "
> fuel-dev at lists.launchpad.net" <fuel-dev at lists.launchpad.net>
> Subject: Re: [Fuel-dev] [openstack-dev] [OSTF][Ceilometer] ceilometer
> meters and samples delete
>
> For now in Fuel we keep samples forever
>
> In case if we will use time_to_live, how long we should keep this data?
>
>
> 2014/1/17 Julien Danjou <julien at danjou.info>
>
>> 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
>>
>
>
>
> --
> With Best Regards
> QA engineer Dmitry Iakunchikov
>  -- Mailing list: https://launchpad.net/~fuel-dev Post to :
> fuel-dev at lists.launchpad.net Unsubscribe : https://launchpad.net/~fuel-devMore help :
> https://help.launchpad.net/ListHelp
>



-- 
With Best Regards
QA engineer Dmitry Iakunchikov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140120/ca3d2d8d/attachment.html>


More information about the OpenStack-dev mailing list