getting rid of all-machines.log
Kapil Thangavelu
kapil.thangavelu at canonical.com
Thu Aug 14 20:47:05 UTC 2014
On Thu, Aug 14, 2014 at 2:14 PM, Nate Finch <nate.finch at canonical.com>
wrote:
> I didn't bring up 12 factor, it's irrelevant to my argument.
>
> I'm trying to make our product simpler and easier to maintain. That is
> all. If there's another cross-platform solution that we can use, I'd be
> happy to consider it. We have to change the code to support Windows. I'd
> rather the diff be +50 -150 than +75 -0. I don't know how to state it
> any simpler than that.
>
>
the abrogation of responsibility which is what ic you adocating for in this
thread, also makes our product quite a lot less usable imo... Our product
is a distributed system with emergent behavior. Having a debug log is one
of the most useful things you can have to observe the system and back in py
days was one of the most used features and it was just a simple dump to the
db with querying. Its unfortunate that ability to use it usefully didn't
land to core till recently and did so in broken fashion (still requiring
internal tag names for filtering).. or lots more people would be using it.
Gustavo's suggestion of storing the structured log data in mongo sounds
really good to me. Yes, features are work and require code but that sort of
implementation is also cross platform portable. The current implementation
and proposed alternatives I find somewhat ridicolous in that we basically
dump structured data into an unstructured format only to reparse it every
time we look at it (or ingest into logstash) given that we already have the
structured data. Asking people to setup one of those distributed log
aggregation systems systems and configure them is a huge task, and anyone
suggesting punting that to an end user or charm developer has never setup
one up themselves i suspect. ie. an analogy imo
http://xahlee.info/comp/i/fault-tolerance_NoSQL.png As for the operations
follks who do have them.. we can continue sending messages send to local
syslog and let them collect per their preference.
-k
>
> On Thu, Aug 14, 2014 at 1:35 PM, Gustavo Niemeyer <
> gustavo.niemeyer at canonical.com> wrote:
>
>> On Thu, Aug 14, 2014 at 1:35 PM, Nate Finch <nate.finch at canonical.com>
>> wrote:
>> > On Thu, Aug 14, 2014 at 12:24 PM, Gustavo Niemeyer
>> > <gustavo.niemeyer at canonical.com> wrote:
>> >>
>> >> > Why support two things when you can support just one?
>> >>
>> >> Just to be clear, you really mean "why support two existing and well
>> >> known things when I can implement a third thing", right?
>> >
>> > Yes, that is exactly what I mean.
>>
>> Okay, on that basis and without any better rationale than "12factor
>> says I can do anything" I'd be tempted to request further analysis on
>> the problem if the decision was on my hands. There are more
>> interesting problems to solve than redoing what already exists.
>>
>>
>> gustavo @ http://niemeyer.net
>>
>
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140814/724900ce/attachment-0001.html>
More information about the Juju-dev
mailing list