On Wed, May 29, 2013 at 6:31 PM, Pavan Sudheendra <[email protected]> wrote: > Cool. Also, do i need to consider multiple engines to collect metrics like > Folsom, Graphite or should i stick to only 1 (Folsom) ?
Once you have folsom you can easily plug on top of it others systems. For graphite it has already be done: https://github.com/campanja/folsomite Though a proper p/sub system could be added to folsom. - benoit > > Any idea on what metrics should be collected? The phrase 'Measure All the > Things.' given in the descriptions section of the bug is pretty vague i > feel. > > > > > On Wed, May 29, 2013 at 9:56 PM, Adam Kocoloski <[email protected]> wrote: > >> Great! I just left a note in that ticket about leveraging folsom as a >> metrics engine. Cheers, >> >> Adam >> >> On May 29, 2013, at 12:25 PM, Pavan Sudheendra <[email protected]> >> wrote: >> >> > Oh ok. >> > >> > I think i'll go forward with COUCHDB-1751. >> > I am to submit a draft or proposal on how i'll go forward with this >> > implementation as Dave suggested. >> > >> > I will send the proposal to the group by tomorrow or day after max. Do >> take >> > a look and suggest changes :) >> > >> > I'm very excited about contributing. >> > >> > Thanks Adam :) >> > >> > >> > On Wed, May 29, 2013 at 9:48 PM, Adam Kocoloski <[email protected]> >> wrote: >> > >> >> I think the aliasing feature might can moderately complicated, yes. I >> >> suspect the final implementation will be straightforward, but you have >> to >> >> wade pretty deep into core. >> >> >> >> COUCHDB-1751 is a great ticket. The challenges there are a) it needs to >> >> be very high-performance, and writing high-performance Erlang code can >> be >> >> tricky, and b) a number of folks have pretty strong opinions about how >> it >> >> should work. Don't want to discourage you from tackling it, though! >> It'd >> >> be great to export metrics more easily. >> >> >> >> Adam >> >> >> >> On May 29, 2013, at 11:52 AM, Pavan Sudheendra <[email protected]> >> >> wrote: >> >> >> >>> Hi Adam! >> >>> >> >>> Thanks for replying. Yes, i got a gist of it. Haven't read upon >> BigCouch. >> >>> Must do that now. >> >>> >> >>> Overall, do you think this feature addition is very complicated? I >> cannot >> >>> say i'm an expert in coding so making sure i don't take up a feature >> >> which >> >>> is very difficult to implement. >> >>> >> >>> Also, your thoughts on >> >> https://issues.apache.org/jira/browse/COUCHDB-1751 ? >> >>> >> >>> I believe giving some stats to third party application like Graphite >> >> etc,.? >> >>> >> >>> >> >>> On Wed, May 29, 2013 at 9:05 PM, Adam Kocoloski <[email protected]> >> >> wrote: >> >>> >> >>>> Hi Pavan! >> >>>> >> >>>> In my opinion COUCHDB-1735 is superseded by COUCHDB-1736. If we have >> an >> >>>> aliasing system then a rename can be something like an alias creation >> >> and >> >>>> deletion. >> >>>> >> >>>> In the description on COUCHDB-1735 Dave mentions that the BigCouch >> code >> >>>> may complicate this feature addition. I'm biased, but I actually >> think >> >> it >> >>>> provides a really nice place to implement it. In the BigCouch world >> >> every >> >>>> logical database has a "partition table" that lists the names and >> >> locations >> >>>> of the shard files that comprise it. That partition table is stored >> as >> >> a >> >>>> document in a special system DB which is replicated to every node in a >> >>>> cluster. >> >>>> >> >>>> I believe we can implement aliases as partition table documents that >> >>>> either point to the "canonical" partition table document for the DB >> (the >> >>>> "ln" option) or else list the original shard names explicitly (the >> "cp" >> >>>> option). >> >>>> >> >>>> Does that make sense? >> >>>> >> >>>> On May 29, 2013, at 11:23 AM, Pavan Sudheendra <[email protected]> >> >>>> wrote: >> >>>> >> >>>>> Hi all, >> >>>>> >> >>>>> I've been in constant touch with Dave and i'm all set to contribute >> in >> >>>> some >> >>>>> way or another :) >> >>>>> >> >>>>> I wanted to ask you all about this but couldn't attend the IRC meet >> >> today >> >>>>> for some reason. >> >>>>> >> >>>>> I need your input on these bugs. >> >>>>> >> >>>>> 1. https://issues.apache.org/jira/browse/COUCHDB-1736 Database >> >> Aliases. >> >>>>> >> >>>>> 2. https://issues.apache.org/jira/browse/COUCHDB-1735 Allow Database >> >>>>> renaming. >> >>>>> >> >>>>> Can you please explain what might be the issues i'd face if i took >> >> these >> >>>>> bugs on? >> >>>>> >> >>>>> Database renaming conceptually looks simple, move or copy all the >> >>>> documents >> >>>>> of the database into a seperate view and delete the previous >> database. >> >> Is >> >>>>> there something which i'm missing? I know there is a lot more to >> this. >> >>>>> Would be glad if someone explained to me how its going to be. >> >>>>> >> >>>>> What about Database Aliases? >> >>>>> >> >>>>> Any help will be greatly appreciated. >> >>>>> -- >> >>>>> Regards- >> >>>>> Pavan >> >>>> >> >>>> >> >>> >> >>> >> >>> -- >> >>> Regards- >> >>> Pavan >> >> >> >> >> > >> > >> > -- >> > Regards- >> > Pavan >> >> > > > -- > Regards- > Pavan
