zpm throws an ambiguous error if a deploy target container does not exist

[larsbutler]

If you try to zpm deploy a zapp to a target container which doesn't exist, you get an error like this:

$ ./zpm deploy ../hello/hello.zapp blargle --execute
deploying ../hello/hello.zapp
Traceback (most recent call last):
  File "./zpm", line 29, in 
    args.func(args)
  File "/Users/lars/proj/zpm/zpmlib/commands.py", line 143, in deploy
    zpm.deploy_project(args)
  File "/Users/lars/proj/zpm/zpmlib/zpm.py", line 324, in deploy_project
    client.upload(path, gzip.open(args.zapp).read())
  File "/Users/lars/proj/zpm/zpmlib/miniswift.py", line 145, in upload
    % (path, r.status_code))
RuntimeError: uploading blargle/hello.zapp failed with status 404

We should do one of the following things instead:

• display a useful error message (Container 'foo' not found, like the python-swiftclient does) and then maybe give some hints on how to create the container
  OR
• just create the container if it doesn't exist, and then continue deploying

When using swift upload on a non-existent container, python-swiftclient will automatically create a container for you. So perhaps it's better to go with the second option. (If the container doesn't exist and needs to be created, we could log an INFO message stating that the container was created.)

Update: Since there are consistency problems with overwriting objects, here is another solution:

• deploy container targets must exist before deploying; else, error "Container 'foo' not found"
• if target container exists and is empty, deploy
• if target container exists and is not empty, error "Target container must be empty"

[pkit]

Hmm, I apologize for not looking into it earlier, but the "proper" way of handling it would be to even refuse a deploy for existing containers. Swift is very good at handling new objects but when you overwrite something the behavior is very different, let's say its consistency window is quite long, it can take a day (24 hours) or even more to have all the objects in the container to be consistently replaced.
Therefore I would like a user/deployer to know what is he/she doing when deploying an app to the existing container.

[larsbutler]

@pkit

Hmm, I apologize for not looking into it earlier, but the "proper" way of handling it would be to even refuse a deploy for existing containers. Swift is very good at handling new objects but when you overwrite something the behavior is very different, let's say its consistency window is quite long, it can take a day (24 hours) or even more to have all the objects in the container to be consistently replaced.
Therefore I would like a user/deployer to know what is he/she doing when deploying an app to the existing container.

Wow, that's surprising. So, do we want to make it a rule, then, that zpm always creates containers and doesn't deploy to existing ones? I understand the consistency problem, but such a rule seems extreme to me.

[pkit]

Dunno, maybe we need more people to step in and discuss. But when user is forced to manually delete things before deploying to an existing container, it will better reflect the actual steps that need to be done...
If for example you have deployed to an existing container, and then there was a consistency problem and one of the files did not update, what you will end up with is a very much a broken installation with a bug that will be very very hard to catch.