Open Stack

Vipul, agreed.

Trove server side could store a mapping of available log files and their
paths per datastore.
Also i agreed with ingoring DBLog model since it's really useless in term
of future manipulations.
And deployer would be able to define which logs could be available for user
by setting allowing parameter per each log type.

Example:
 allow_commit_log = True, allow_bin_log = False - each of parameter sets
are custom per datastore.
mapping = {}
if allow_bin_log: mapping.update({'bin_log': path})



2013/12/20 Vipul Sabhaya <vipuls at gmail.com>

> Yep agreed, this is a great idea.
>
> We really only need two API calls to get this going:
> - List available logs to ‘save’
> - Save a log (to swift)
>
> Some additional points to consider:
> - We don’t need to create a record of every Log ‘saved’ in Trove.  These
> entries, treated as a Trove resource aren’t useful, since you don’t
> actually manipulate that resource.
> - Deletes of Logs shouldn’t be part of the Trove API, if the user wants to
> delete them, just use Swift.
> - A deployer should be able to choose which logs can be ‘saved’ by their
> users
>
>
> On Wed, Dec 18, 2013 at 2:02 PM, Michael Basnight <mbasnight at gmail.com>wrote:
>
>> I think this is a good idea and I support it. In todays meeting [1] there
>> were some questions, and I encourage them to get brought up here. My only
>> question is in regard to the "tail" of a file we discussed in irc. After
>> talking about it w/ other trovesters, I think it doesnt make sense to tail
>> the log for most datstores. I cant imagine finding anything useful in say,
>> a java, applications last 100 lines (especially if a stack trace was
>> present). But I dont want to derail, so lets try to focus on the "deliver
>> to swift" first option.
>>
>> [1]
>> http://eavesdrop.openstack.org/meetings/trove/2013/trove.2013-12-18-18.13.log.txt
>>
>> On Wed, Dec 18, 2013 at 5:24 AM, Denis Makogon <dmakogon at mirantis.com>wrote:
>>
>>>     Greetings, OpenStack DBaaS community.
>>>
>>>     I'd like to start discussion around a new feature in Trove. The
>>> feature I would like to propose covers manipulating  database log files.
>>>
>>>
>>
>>>     Main idea. Give user an ability to retrieve database log file for
>>> any purposes.
>>>
>>>     Goals to achieve. Suppose we have an application (binary
>>> application, without source code) which requires a DB connection to perform
>>> data manipulations and a user would like to perform development, debbuging
>>> of an application, also logs would be useful for audit process. Trove
>>> itself provides access only for CRUD operations inside of database, so the
>>> user cannot access the instance directly and analyze its log files.
>>> Therefore, Trove should be able to provide ways to allow a user to download
>>> the database log for analysis.
>>>
>>>
>>>     Log manipulations are designed to let user perform log
>>> investigations. Since Trove is a PaaS - level project, its user cannot
>>> interact with the compute instance directly, only with database through the
>>> provided API (database operations).
>>>
>>> I would like to propose the following API operations:
>>>
>>>    1.
>>>
>>>    Create DBLog entries.
>>>    2.
>>>
>>>    Delete DBLog entries.
>>>    3.
>>>
>>>    List DBLog entries.
>>>
>>> Possible API, models, server, and guest configurations are described at
>>> wiki page. [1]
>>>
>>> [1] https://wiki.openstack.org/wiki/TroveDBInstanceLogOperation
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Michael Basnight
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131220/c51038b7/attachment-0001.html>