Development pickup no-remove location

[myroslav]

It would be great to have some location in Quickstart cluster preconfigured for rapid development. Saving file there would distribute file just like server{1,2}/pickup-dir does, but won't remove it. That would let opening the file with editor, and just saving it, making it possible to see changes to service almost instantly after save, without the need for copying the file to pickup-dir.

[dsuch]

Seeing as it's for development only, here's an idea

• a 'pickup_delete_input' flag will be introduced in server.conf -> defaults to True
• if it's False, a file won't be deleted after it's been saved in a pickup dir but still will be hot-deployed

What do you think? This should be quite easy to implement (for 1.2). The only thing to remember will be not to save out a file while the previous deployment is still in progress.

[myroslav]

In case flag is True while developer thinks it's False, file is saved with exit from editor, and file contains syntax error would result in file loss.

I would still prefer something dedicated to development.

On Sat, Jun 1, 2013 at 1:14 AM, Dariusz Suchojad notifications@github.comwrote:

Seeing as it's for development only, here's an idea

• a 'pickup_delete_input' flag will be introduced in server.conf -> defaults to True
• if it's False, a file won't be deleted after it's been saved in a pickup dir but still will be hot-deployed

What do you think? This should be quite easy to implement (for 1.2). The only thing to remember will be not to save out a file while the previous deployment is still in progress.

— Reply to this email directly or view it on GitHubhttps://github.com/zatosource/zato/issues/52#issuecomment-18774509 .

.................................................................................................................................... Myroslav Opyr ▪ CTO ▪ Quintagroup ▪ +1.917.475.4725 ▪ http://quintagroup.com ˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙

[dsuch]

Right.. I'm just wondering how realistic it is.

Using this flag it could be added to Zato quickly, while introducing another directory means we're dealing with someone who mis-configures a server, does a lot of coding without ever saving a file (so the fact that the server is badly configured doesn't become obvious the first time the file is saved) and then thinks the file is lost because it was (seemingly) deleted during the deployment.. This just doesn't seem something to guard against.

Myself, I'd notice the server isn't configured properly the moment I created and saved an empty file and I think you would too :-)

But even then, the file is still there, it's kept in two places:

• in ODB -> deployment_package.payload
• in ./work/hot-deploy/current [1]

See, the file is first added to the ODB so whatever happens next, the code is never lost. Then, it's copied over to a new location off of which Zato won't import it, that's true. But failing to import a module doesn't mean the module will be deleted.

Try it out yourself - hot deploy a testsyntax.py module with a SyntaxError in there and you'll see that it will be in ./work/hot-deploy/current.

So we never really lose anything. And the edge case doesn't seem something too common. So as long as we document it prominently, I think we're OK. Some will people /will/ lose 2 or 5 lines of code but is there really anyone who writes code without saving it on disk as often as possible?

[1] https://zato.io/docs/admin/guide/install-config/config-server.html#hot-deploy-work-dir

[dsuch]

OK, it's done - I've just added and documented a new server.conf's flag - hot_deploy.delete_after_pick_up. Thanks @myroslav, this is a very good feature indeed!