Closed Bug 1493687 Opened 3 years ago Closed 3 years ago

rewrite crontabber using django models and commands

Categories

(Socorro :: Webapp, task, P3)

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: willkg, Assigned: willkg)

References

Details

Attachments

(7 files)

In bug #1478080, I pulled the code for the crontabber library (which itself was extracted out of Socorro years ago) back into Socorro. The next step for that is to convert it into a Django app.

Converting it into a Django app involves some or all of the following:

1. building Django models for the crontabber and crontabber_log tables
2. adding a django admin view for those tables
3. writing Django commands for the crontabber subcommands
4. reworking the existing crontabber jobs to work in this new context

This bug covers that work.
Making this a P2. It's something we want to do soon and it blocks the postgres cleanup work.
Blocks: 1361394
Priority: -- → P2
I'm going to generate the models and tweak the existing crontabber code to use them.

Step 2 will be a rewrite of the code.
Assignee: nobody → willkg
Status: NEW → ASSIGNED
Commits pushed to master at https://github.com/mozilla-services/socorro

https://github.com/mozilla-services/socorro/commit/22dbb93d1702841bbff5cc49f6eca97887b50b4b
bug 1493687: fix /crontabber-state

This nixes the CrontabberState middleware in favor of one that uses the
Django model.

This also removes the dependency visualization on the /crontabber-state
page. It doesn't like it when there are no dependencies and I figured
it's time to remove it.

Since it's the only use of d3-sankey, I removed that, too.

One minor irritant is that the depends_on field was a text[] in the
old models and a text (comma-separated string) in the new one. That's
causing some problems, so I hard-coded things. In the rewrite we won't
be redoing the depends_on, so it's not long for this world anyhow.

https://github.com/mozilla-services/socorro/commit/5fa797addebf8e8a6e98e364cc2f3a072c4dd215
Merge pull request #4669 from willkg/1493687-crontabber-state

bug 1493687: fix /crontabber-state
Commits pushed to master at https://github.com/mozilla-services/socorro

https://github.com/mozilla-services/socorro/commit/6c3cb4b2f562e0e8e3b09c3ef9a34e5773f1db81
bug 1493687: remove /api/CrontabberState and /crontabber-state

This removes the CrontabberState API endpoint and the /crontabber-state
view. We no longer support depends_on relationships between jobs, so
we don't need /crontabber-state anymore. This rewrites the one view
that looks at crontabber jobs to look at the database directly, so
we no longer need the API endpoint, either.

This also fixes the API tests to use a new NoOpMiddleware for testing
API infrastructure. That saves me the effort of rewriting those tests
every time I remove another API endpoint.

https://github.com/mozilla-services/socorro/commit/dc0137d1077c09176de23c3374c978235436fcdc
Merge pull request #4707 from willkg/1493687-crontabberstate

bug 1493687: remove /api/CrontabberState and /crontabber-state
Maybe instead of doing this, we rewrite the jobs using Huey:

https://huey.readthedocs.io/en/latest/

That probably requires Redis, but maybe we could write a Django-ORM storage backend:

https://huey.readthedocs.io/en/latest/contrib.html#sqlite-storage

Anyhow, definitely worth looking into and if we don't use it, there are some interesting API things that would be handy.

Making this a P3 and pushing it off a while.

Priority: P2 → P3

For the record, I reimplemented crontabber using Django commands. It's slimmed down and has additional tests. "Jobs" will be implemented as Django commands and then added to the JOBS schedule. It should work well and it means that "jobs" can be run as normal Django commands when testing and debugging without dealing with locking and schedules.

One of the tests is failing intermittently:

___________ crashstats/cron/tests/test_utils.py::test_time_to_run _____________
Traceback (most recent call last):
  File "/app/webapp-django/crashstats/cron/tests/test_utils.py", line 82, in test_time_to_run
    assert time_to_run(job_spec, job) is False
  File "/app/webapp-django/crashstats/cron/utils.py", line 87, in time_to_run
    hh, mm = convert_time(time_)
  File "/app/webapp-django/crashstats/cron/utils.py", line 61, in convert_time
    raise TimeDefinitionError("Invalid definition of time %r" % value)
crashstats.cron.TimeDefinitionError: Invalid definition of time '24:06'
==================== 1 failed, 285 passed in 60.34 seconds =====================

Pushed this to prod just now. Will wait a little until I can verify it's working.

It ran in prod and produced LogEntries and IT IS GLORIOUS! Marking as FIXED.

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.