Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ceres future / Maintainer needed ? #45

Open
deniszh opened this issue Mar 20, 2017 · 8 comments
Open

Ceres future / Maintainer needed ? #45

deniszh opened this issue Mar 20, 2017 · 8 comments
Labels

Comments

@deniszh
Copy link
Member

deniszh commented Mar 20, 2017

Hi all,

We need to discuss Ceres future. As far as I understand, it still requires megacarbon branch and it seems it's not intended to replace Whisper as the default storage format for Graphite anymore.
So, I see a couple of options here:

  1. find some active Ceres user, who can help with merging Ceres support to master and fix (or backport from an own branch) all fixes. (Maybe we can include Ceres as pluggable backend then?) 🚢
  2. Just admit current state and officially abandon that, clearly stating that in README and documentation. 🔥
  3. Do nothing and continue to confuse users. 🙄
    Let's discuss here.
    /cc @cbowman0 @iain-buclaw-sociomantic
    /cc @obfuscurity @DanCech @iksaif
    /cc @mleinart @SEJeff

If someone knows some Ceres' users - please show them this thread.

@iksaif
Copy link
Member

iksaif commented Mar 20, 2017

My highly biased opinion would be to deprecate Ceres in favor of BigGraphite.

@iain-buclaw-sociomantic
Copy link
Contributor

iain-buclaw-sociomantic commented Mar 20, 2017

Just to repeat what I said in #31 here.

  1. Carbon master has full ceres support - Cherry-pick TimeSeriesDatabase from megacarbon branch carbon#484, Remove remaining dependencies on whisper carbon#508, and Implement the Ceres storage backend against TimeSeriesDatabase carbon#596.

  2. Megacarbon has performance issues - it consumes about twice the CPU usage. As far as I'm concerned, megacarbon is dead, long live megacarbon! 🔥

  3. I think the confusion caused may be in part a fault of lack of PR (documentation, blog posts, etc). Probably not helped by that the patches I submitted to master were very much under the radar.

There's also been no release of carbon-master in over two years? This probably is not helping exposure either.

@deniszh
Copy link
Member Author

deniszh commented Mar 20, 2017

My highly biased opinion would be to deprecate Ceres in favor of BigGraphite.

I think it's not mutually exclusive tasks. IMO "Let a thousand flowers bloom". We need to implement proper plugging storage and finder support and let it live - if we have active users of it. And if we can find some maintainer ofc.

@deniszh
Copy link
Member Author

deniszh commented Mar 20, 2017

Megacarbon has performance issues - it consumes about twice the CPU usage. As far as I'm concerned, megacarbon is dead, long live megacarbon!

If Ceres working with current master - IMO we should kill megacarbon, indeed. If I'm not missing some other value there.

There's also been no release of carbon-master in over two years? This probably is not helping exposure either.

We'll fix it real soon, I hope. :)

@iksaif
Copy link
Member

iksaif commented Mar 21, 2017

If we don't have any maintainer for Ceres, maybe we should mark it clearly as un-maintained in the README / description ? That would make things less confusing

@deniszh
Copy link
Member Author

deniszh commented Mar 21, 2017

Yes, I changed my initial post. If we'll not find maintainer in near future I'm going to do exactly that.

@iain-buclaw-sociomantic
Copy link
Contributor

My highly biased opinion would be to deprecate Ceres in favor of BigGraphite.

I think my counter opinion would be that if carbon can be made more pluggable, that should be made to happen.

There for sure are benefits of using Ceres over Whisper despite the trade-off of having roll-up done as an offline operation (e.g: nightly cron). But there's probably nothing more that can be changed in Ceres to be improved upon on the database level. The space saving is nice, but I don't think it goes far enough in being a radical alternative.

The next place I'd like to be would be something along the lines of storing timestamps as delta of deltas. Then offload the "normalizing" of data to fixed intervals to graphite. However I'm sure there are already engines out there that do this, I just haven't discovered them yet. :-)

@iksaif
Copy link
Member

iksaif commented Apr 3, 2017

See #46

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants