Parsing mail on a different system
dja at axtens.net
Wed Oct 28 11:31:49 AEDT 2020
> I think we may be oversetimating how many people out there run
> patchwork. :) My general concern was to make sure that parsemail doesn't
> do things like clear django data. If, to your knowledge, all it does is
> write to the database without interacting with the running process, then
> there's no reason why the feeder and the consumer can't live on
> different systems.
Yeah, Patchwork sits in this really weird space where there are not many
deployments, but still too many for us to deeply integrate with any
one site's infrastructure/setup. It also means that we don't have direct
access to a copy of any site's data, which regularly bites everyone when
we write inefficient migrations.
Anyway, parsemail and friends are a django management command under the
hood. They operate in a separate process. Nothing in the process should
mutate any data other than the database and potentially logs. There is
no explicit communication with any running patchwork process - no
signals or shared memory or mutating python files on disk. Indeed, I
have steadfastly resisted creating/using non-database data stores (like
file-system based locks) during the parsing process.
It is worth noting that depending on your logging setup you might get
mails on certain types of failures, so your parse-box would need to be
able to handle that if appropriate
All of which is a long wind-up to saying:
I don't believe there should be any issues with parsing mail on a
different system. If you have any issues with it, I would consider them
to be fairly significant bugs.
> Patchwork mailing list
> Patchwork at lists.ozlabs.org
More information about the Patchwork