> 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. Kind regards, Daniel > > -K > _______________________________________________ > Patchwork mailing list > Patchwork@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/patchwork _______________________________________________ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
