Metronome vs Chronos

1922 views
Skip to first unread message

Tomek Janiszewski

unread,
Aug 12, 2016, 6:12:01 AM8/12/16
to users
Hi

What's the state of Chronos and Metronome. Chronos is not actively developed and Metronome is still fresh.
Chronos development was planned to restart on June.

Are there any replacements for Chronos? Singilarity? Aurora? Are they easy to use with DCOS?


Best
Tomek

Cody Maloney

unread,
Aug 12, 2016, 8:02:55 AM8/12/16
to Tomek Janiszewski, users
Metronome is the replacement for Chronos inside of DC/OS. You can see it inside of the "1.8.1 EA", with 1.8 hopefully all your periodically scheduled jobs needs will be taken care of by Metronome. It shows up as "Jobs" in the new DC/OS UI.

--
You received this message because you are subscribed to the Google Groups "users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to users+un...@dcos.io.
To post to this group, send email to us...@dcos.io.
To view this discussion on the web visit https://groups.google.com/a/dcos.io/d/msgid/users/4e7c8da4-9977-417e-b882-c35831612685%40dcos.io.

John Omernik

unread,
Aug 12, 2016, 8:05:37 AM8/12/16
to Cody Maloney, Tomek Janiszewski, users
Will Metronome allow us to install "crons" per role like CHronos did? I.e. I I have a role created for a group, and I want them to be able to submit jobs to it with their own credentials, I'd like to have multiple instances of Metronome to do that... 

Tomek Janiszewski

unread,
Aug 12, 2016, 8:11:03 AM8/12/16
to Cody Maloney, users
@Cody So this means Chronos is no longer developed?
In addition to above question are there any Chronos-to-Metronome migration tutorial?

Cody Maloney

unread,
Aug 12, 2016, 8:16:33 AM8/12/16
to Tomek Janiszewski, users
@john omerik: No idea. I don't know it that well.

@tomek: The mesosphere focus is on metronome, which shares code with chronos, has a better API, etc.

As far as migration tutorial, there isn't one yet that I know of.

John Omernik

unread,
Aug 12, 2016, 8:28:23 AM8/12/16
to Cody Maloney, Tomek Janiszewski, users
So some thoughts here:

Chronos is/was/maybe still is an important part of Mesos clusters that have been deployed.  Now, I am not saying all Mesos clusters use Chronos, but for those clusters that DO use it, it's a critical component.  Chronos has been, neglected, not updated, etc.  And I am not trying to demand free maintenance on something like Chronos, but at the same time, while open sourced, its hard for some shops to have the dev skills to update it.  The analogy, if we will take the most common analogy is if Mesos is like the Linux Kernel, and DC/OS is like Ubuntu or CentOS, then obviously, Cron is like Chronos (which folks have already come to the conclusion on).  Well, to take that further, how many people work on Cron? I know Paul Vixie, and he's a great guy, but cron just isn't developed by "users" of Ubuntu... it doesn't happen.  Now, I know Mesosphere has limited resources, but a change has been made, please help us transition and understand! :) 

So some thoughts on Chronos -> Metronome

1. Please be clear about the roadmap here.  Metronome was included in DC/OS 1.8 as the "master" scheduler so it could unify the interface with the included Marathon.  Some posts on why, and how this integration happened would be very helpful to the community.
2. As has been asked, understanding the migration steps, would be very beneficial for those using Chronos already.  Given Chronos hasn't had much dev work, and now this new thing is there, it's going to be a natural question so when people are working with their clusters, they have a sense of understanding on how to switch, why they've switched and what the end result may look like. 
3.  Understanding the "multi-role" Chronos setup and being able to answer is would be very important for some users (*raises hand)  I see every tenant or role on my cluster having a Marathon and Chronos/Metronome instance that they can work with.  This question on Metronome also extends to Marathon, with Marathon now being assimilated into the DCOS interface, can we still install Marathon as a service for specific roles? 

I think when a change is made like the Chronos->Metronome transition, helping the community understand the plan can go a long way to easing the transition and getting support and assistance moving forward. 

Thanks,

John 



Judith

unread,
Aug 12, 2016, 11:30:57 AM8/12/16
to users, co...@mesosphere.io, jan...@gmail.com
@Tomek, Thanks for bringing up this issue. A migration guide is a great idea, and I'll ask around about getting one started.

@John, These are all really good points; thanks for bringing them up. About the community:
 
Now, I know Mesosphere has limited resources, but a change has been made, please help us transition and understand! :) 
 
Hi, I'm Mesosphere's new (as of this week) community manager! DC/OS is pretty young as an open source project, and we're just starting to get a sense for the most effective ways to allocate resources to help it thrive, which definitely include transparency on component changes! While I'll do my best to be proactive, input like this is aways really helpful; please keep it coming! And, nice to meet you :)

1. Please be clear about the roadmap here.  Metronome was included in DC/OS 1.8 as the "master" scheduler so it could unify the interface with the included Marathon.  Some posts on why, and how this integration happened would be very helpful to the community.

We will be making an effort to post design docs, especially to address this point. I'll see if I can track something down on metronome for you.

I think when a change is made like the Chronos->Metronome transition, helping the community understand the plan can go a long way to easing the transition and getting support and assistance moving forward.

Yes! Design docs and migration tutorials are great ideas. We'll be noodling on other tools too, and suggestions are always welcome! 

All the best! 
Judith 

Sunil Shah

unread,
Aug 12, 2016, 1:21:39 PM8/12/16
to Judith, users, Cody Maloney, jan...@gmail.com
John, I think it's worth pointing out that Chronos is not a Mesosphere project or product. Chronos ultimately had a number of structural and usability issues that made sense for it to be rewritten (the API and UI are a bit of a mess) - Metronome pulls in a lot of more mature scheduler code that is now in Marathon and should provide a much better experience than Chronos.

I definitely agree that better documentation and a migration guide would be useful! If you have any other suggestions, feel free to create issues in the DC/OS JIRA (or just report them here).

Karl Isenberg

unread,
Aug 12, 2016, 7:35:37 PM8/12/16
to Sunil Shah, Judith, users, Cody Maloney, jan...@gmail.com
Chronos is not a Mesosphere project or product

This is somewhat indelicate, but almost accurate. Chronos was initially developed at AirBnB by Flo (Mesosphere's CEO) and friends (http://nerds.airbnb.com/introducing-chronos/). Unlike Mesos and Spark, Chronos never became an official Apache project (http://www.apache.org/index.html#projects-list). Chronos was migrated to the Mesos github community organization shortly before Mesosphere Inc was founded in 2013. While there's no one official owner, Mesosphere definitely helped improve and maintain Chronos, including it in the "Mesosphere stack" that eventually evolved into DC/OS. That said, there hasn't been much in the way of active Chronos development since about Aug 2015.

There is an interesting question of "who gets to call an open source project EOL?" Open source projects tend to live for as long as they have committers willing to accept PRs and make releases. As a Mesos community project, I imagine if someone really wanted to keep Chronos on life support they could probably petition for commit access, but Mesosphere wrote Metronome as a replacement, partly to take advantage of lessons learned from Marathon and several of our data service frameworks and partly to integrate into DC/OS, which is itself fully open source. 

As with all open source, you don't have to buy it outright, but you still need to pay for it with engineering investment or support contracts if you want it to be mission critical to your business.

--
Karl Isenberg
Distributed Applications Engineer
Mesosphere

Thomas Rampelberg

unread,
Aug 15, 2016, 10:23:22 AM8/15/16
to John Omernik, Cody Maloney, Tomek Janiszewski, users
We haven’t been doing a good job of communicating, particularly around what's going on with Marathon and job scheduling in this latest release. This is something that almost everyone in the community has brought up, and we're working at getting better. Now, let's get some clarity on this!

In the latest release, we wanted to bring built-in job scheduling so that DC/OS had its own cron (just like Marathon provides the init system). After looking at the Chronos codebase, we realized that maintaining two completely separate code bases for long running tasks and scheduled tasks was going to be very difficult moving forward. As we add things like universal containerizer support to Marathon, we wanted it to be available for scheduled tasks without needing a massive amount of effort.

So, the decision was made to create a new framework based off the marathon codebase that lets you do scheduled tasks. We integrated it into the DC/OS UI as a base component and shipped it as part of the 1.8 EA release. Metronome is a core component of DC/OS and we will be clear about what the roadmap there is (along with all of DC/OS) moving forward. This has the added benefit of clearing up the question of development and support around Chronos (not developed or supported by the DC/OS community) and Metronome (both developed and supported by the DC/OS community).

Because you can run your own applications on DC/OS, you will always be able to run Chronos with DC/OS. It is going to be part of the universe for a very long time =)

Finally, let me address the numbered points directly:

1. Let's get a blog post together on this so that it isn't lost in the mailing list. I'll work on that for a while today. In the meantime, see above for the "why". For "how" - there's a pkgpanda package for metronome that runs on the masters. That surfaces an API through adminrouter that the UI then operates on. In DC/OS, the UI is pure client side javascript and all the APIs are open and exposed through adminrouter.

2. Great suggestion, this is fodder for another blog post. Metronome doesn't support some large chunks of Chronos functionality yet, so it'll be nice to make sure everyone knows what is part and what isn't.

3. You can run as many instances of marathon, metronome and chronos as you'd like. For marathon/metronome, you've got the built-in UI for the bundled instances and either the marathon UI or metronome API to interact with if you'd like to run extra instances. Obviously, with Chronos, you get that UI/API per instance. There is a lot of discussion going on about adding the functionality to be multi-role to mesos (and then marathon/metronome). That will take place on the mesos dev lists right now.

John Omernik

unread,
Aug 15, 2016, 11:36:33 AM8/15/16
to Thomas Rampelberg, Cody Maloney, Tomek Janiszewski, users
Thanks Thomas for the email.   As of now there isn't a specific UI for Metronome (if you wanted to run a per role instance of Metronome) but the API would be available...am I reading that right?   Basically, the reason I ask is I see the "cluster wide" init/cron... (Marathon/Metronome) being built into DC/OS, I like that, but I also want to be able to give teams the ability to play in their own sandboxes, which in turn means marathon/metronome instances in limited roles... In the short term, it sounds like Marathon/Chronos may be the best bet for a UI for each role, but I wanted to be clear on that. 

John


Thomas Rampelberg

unread,
Aug 15, 2016, 11:41:25 AM8/15/16
to John Omernik, Cody Maloney, Tomek Janiszewski, users
The API will always be available (as you're running a new instance of the scheduler, its full API will be available there).

If you want a UI for each role, marathon/chronos are going to be the short term best bet. Can you file an issue to track switching between instances of marathon? I'd like to make sure we're tracking it.

John Omernik

unread,
Aug 15, 2016, 11:47:34 AM8/15/16
to Thomas Rampelberg, Cody Maloney, Tomek Janiszewski, users
I am not following the "track switching between instances of marathon"  How I see it is we have the cluster wide Marathon that's built into DCOS, then we'd have other instances for other parties (Roles) we wouldn't give access to the cluster wide to the alternate instances... that wouldn't make sense... maybe I am mis-reading your post?

John


Thomas Rampelberg

unread,
Aug 15, 2016, 11:50:31 AM8/15/16
to John Omernik, Cody Maloney, Tomek Janiszewski, users
We've built the services UI into the DC/OS UI. That UI (services) can theoretically work with any backend instance of Marathon, whether it is the built-in version or an instance that you've provided to others. We should make it possible to switch what instance of Marathon the service UI is talking to, so that you can have a single UI for all the Marathons that you're running.

Karl Isenberg

unread,
Aug 15, 2016, 1:10:57 PM8/15/16
to Thomas Rampelberg, John Omernik, Cody Maloney, Tomek Janiszewski, users
My understanding is that multi-role frameworks and hierarchical role support are on the Mesos road map. So long term you shouldn't need a new instance of marathon or chronos to have individual/team sandboxes. The frameworks can instead be made more multitenant, using groups/namespaces, like Marathon does. Enterprise edition already supports fine grained access control for marathon groups. So that works now, if you don't need multiple resource roles. 

Multi-role frameworks are still a ways out tho. In the mean time it'd be nice to (as Thomas mentioned) have a switcher on the marathon/metronome UIs to allow them to control multiple backends. 


--

John Omernik

unread,
Aug 15, 2016, 2:27:55 PM8/15/16
to Karl Isenberg, Thomas Rampelberg, Cody Maloney, Tomek Janiszewski, users
Is the strategy to have one marathon/metronome to rule them all?  I guess from a sandboxing standpoint, I like the idea of multiple instances, per team, role, etc.   That way there is isolation from a instance standpoint, and an issue/bug on one doesn't need to allow for impact on other roles.  Especially as it pertains to upgrades etc. Being able to upgrade newer "high risk tolerant" areas (dev, etc)  to newer versions, while maintaining the status quo on more sensitive areas seems like a great way manage and spread around that risk.  Is the one ring to rule them strategy where DC/OS is going or is that still up for discussion?


Thomas Rampelberg

unread,
Aug 15, 2016, 3:15:47 PM8/15/16
to John Omernik, Karl Isenberg, Cody Maloney, Tomek Janiszewski, users
We need to have the ability to run multiple instances of every framework moving forward. Today, you want it for roles ... tomorrow it might be HA, configuration or the ability to run "unstable" versions. The end goal is to have it always be supported but reduce the need. Ideally, frameworks are multi-role and you don't *have* to separate that way. 

John Omernik

unread,
Aug 15, 2016, 3:24:16 PM8/15/16
to Thomas Rampelberg, Karl Isenberg, Cody Maloney, Tomek Janiszewski, users
Cool, thanks for the clarification. 
Reply all
Reply to author
Forward
0 new messages