Error code on putting container when update process to account fail

Fix proposed to branch: master
Review: https://review.openstack.org/87882

I guess, this is not a bug but a specification.

A container server returns 404 when db file unfortunately does not exist in the container for some reasons (e.g. device failure).
However an account server returns 404 only when db file has been deleted and not been allowed to override.
In addition, container server returns HTTPNotFound only when all updates for account fail with 404.
i.e. Because the account has gone, swift should not return a success code.

> However an account server returns 404 only when db file has been deleted and
> not been allowed to override.
In container PUT or DELETE, overriding account is not allowed,
so an account-server returns 404 when db file has been delete or gone.

> In addition, container server returns HTTPNotFound only when all updates for
> account fail with 404.
> i.e. Because the account has gone, swift should not return a success code.
I think it's not true.
In container PUT, container-servers share update processing for account between them,
and each server returns 404 if all assigned reporting fails with 404.

For example, when we set replica count 3, each container-server reports update for
only one account server.
So, when 2 of 3 account replicas are missed or placed in handoffs (swift doesn't check
handoffs in update processing), proxy-server receives two 404s from container-servers
and return 404 for container PUT.
In this situation, the account still exists in swift, but we cannot succeed
in putting container.

Do you mean PROXY SERVER returns a failure code when quorum number of container server fails at account_update? I mean container server returns HTTPNotFound only when all updates "assigned by proxy for the container" fail with 404.

Although I didn't notice is_deleted() call might return True when the db file path does not exist, I still believe swift should keep current semantics because 404 of account server means specified account HAVE BEEN DELETED. In current swift, an account server cannot know why the db file does not exist and regards it as "deleted". Even if a account server returns 201, it might be wrong because quorum of account server returns 404.

I guess, It is caused from a difference of DELETE operation semantics. If we have a permission for all operation of swift, anytime we are able to delete account but we cannot delete container when one and more objects exist in the container. i.e. object-sever expects the container server still has been existing but account server could not do so. That is why swift should deny PUT container for non-existing account. Moreover, when upper element (e.g. an account of a container, a container of an object) does not exist, swift should fail to make the specified element with 404 because swift has previous existing check in proxy server to deny such a bad request.

I don't know why object-server keep the object information whose container does not exist as async_pending even if object-updater will give up to update(and handle as succeeded) when container server fails returns 404. Anyways, we have to make the semantics to be clear if we could change the quorum of responses.

> Although I didn't notice is_deleted() call might return True when the db file path does not exist,
> I still believe swift should keep current semantics because 404 of account server means
> specified account HAVE BEEN DELETED.
I understand and agree with your idea that account server should return 404
if it has deleted account db file.

However, I still believe account server should not return 404 when db file is "missed,"
because this 404 for missing account causes following situation, for example.

1.
 Client puts account to swift cluster and gets 201, but the greater part of them are put at handoff devices
 because of temporary overload.
2.
 Client puts container to the account and gets 404, because the greater part of container severs
 get 404 from account-server because missing file and return 404 to proxy server.

In this situation, account is NOT deleted and still exists at handoff devices,
but client cannot put container to the account.

Change abandoned by John Dickinson (<email address hidden>) on branch: master
Review: https://review.openstack.org/87882
Reason: Abandoning due to lack of activity since the last negative review. You can restore the change if you want to keep working on it.

Change abandoned by John Dickinson (<email address hidden>) on branch: master
Review: https://review.openstack.org/87882
Reason: Abanoning based on the lack of activity since the last negative review. If you want to continue working on this, please reopen this patch.

Change abandoned by "Takashi Kajinami <email address hidden>" on branch: master
Review: https://review.opendev.org/c/openstack/swift/+/87882