Open Stack

+1 to @Aleksandr


On Tue, Jun 24, 2014 at 8:32 PM, Aleksandr Didenko <adidenko at mirantis.com>
wrote:

> Yes, of course, snapshot for all nodes at once (like currently) should
> also be available.
>
>
> On Tue, Jun 24, 2014 at 7:27 PM, Igor Kalnitsky <ikalnitsky at mirantis.com>
> wrote:
>
>> Hello,
>>
>> @Aleks, it's a good idea to make snapshot per environment, but I think
>> we can keep functionality to make snapshot for all nodes at once too.
>>
>> - Igor
>>
>>
>> On Tue, Jun 24, 2014 at 6:38 PM, Aleksandr Didenko <adidenko at mirantis.com
>> > wrote:
>>
>>> Yeah, I thought about diagnostic snapshot too. Maybe it would be better
>>> to implement per-environment diagnostic snapshots? I.e. add diagnostic
>>> snapshot generate/download buttons/links in the environment actions tab.
>>> Such snapshot would contain info/logs about Fuel master node and nodes
>>> assigned to the environment only.
>>>
>>>
>>> On Tue, Jun 24, 2014 at 6:27 PM, Igor Kalnitsky <ikalnitsky at mirantis.com
>>> > wrote:
>>>
>>>> Hi guys,
>>>>
>>>> What about our diagnostic snapshot?
>>>>
>>>> I mean we're going to make snapshot of entire /var/log and obviously
>>>> this old logs will be included in snapshot. Should we skip theem or
>>>> such situation is ok?
>>>>
>>>> - Igor
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Jun 24, 2014 at 5:57 PM, Aleksandr Didenko <
>>>> adidenko at mirantis.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> If user runs some experiments with creating/deleting clusters, then
>>>>> taking care of old logs is under user's responsibility, I suppose. Fuel
>>>>> configures log rotation with compression for remote logs, so old logs will
>>>>> be gzipped and will not take much space.
>>>>>
>>>>> In case of additional boolean parameter, the default value should be
>>>>> "0-don't touch old logs".
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Alex
>>>>>
>>>>>
>>>>> On Tue, Jun 24, 2014 at 4:07 PM, Vladimir Kozhukalov <
>>>>> vkozhukalov at mirantis.com> wrote:
>>>>>
>>>>>> Guys,
>>>>>>
>>>>>> What do you think of removing node logs on master node right after
>>>>>> removing node from cluster?
>>>>>>
>>>>>> The issue is when user do experiments he creates and deletes clusters
>>>>>> and old unused directories remain and take disk space. On the other hand,
>>>>>> it is not so hard to imaging the situation when user would like to be able
>>>>>> to take a look in old logs.
>>>>>>
>>>>>> My suggestion here is to add a boolean parameter into settings which
>>>>>> will manage this piece of logic (1-remove old logs, 0-don't touch old logs).
>>>>>>
>>>>>> Thanks for your opinions.
>>>>>>
>>>>>> Vladimir Kozhukalov
>>>>>>
>>>>>> _______________________________________________
>>>>>> OpenStack-dev mailing list
>>>>>> OpenStack-dev at lists.openstack.org
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Andrey Danin
adanin at mirantis.com
skype: gcon.monolake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140624/09c43c19/attachment-0001.html>