v2 - replacing array elements with PATCH results in 400 error

This is what works for me:

[{"path": "/tags", "value": ["test"], "op": "replace"}]

That might be the case, but the fact still stands that

[{"path": "/tags/0", "value": "test", "op": "replace"}]

is a valid PATCH document, which is currently being rejected by the API. If Glance v2 supports the JSON patch standard (rfc6902), surely it should support all of it?

See this also:

https://github.com/json-patch/json-patch-tests/blob/master/tests.json#L155-L173

In v2. image tags has its API : v2/images/image_id/tags/tag_value (PUT or DELETE).

I'm not sure image-update is the right way.

here are two way to fix IMO:

1. support "PATCH" "tags/0"

2.stop use PATCH to update tags.

I agree with the two options:

1. Implement JSON PATCH properly, allowing array elements to be updated individually. Perhaps you could use a library like https://github.com/stefankoegl/python-json-patch to do the heavy lifting for you?

2. Disable updating tags via PATCH. You would need to add `"readOnly": true` for that property in the schema. You'd also have to hope that there will never be arrays that can be updated for that object in the future.

My personal opinion is for #1. Partially implementing an IETF standard doesn't make sense to me.

I think the confusion is because there is no sub place for tags. Its like the name attribute you would not expect to do "/name/2" to get the second letter of the name.

This is the same with tags, it is a flat namespace. Therefore you can't get a sub part of a tag as it is all defined on the same level.

I'm not sure what you mean by "sub place" or "flat namespace" -- I think they're irrelevant terms here.

Yes, you would not access the name attribute with "/name/2" because it is not an array. The "tags" attribute, however, is -- so you would definitely expect to do that. It really shouldn't matter how Glance handles the array logic -- if you implement a standard, you should implement all of it or make the attribute `"readOnly": true` in the schema.

I've reviewed this and I have to agree with Jamie. The problem with option 2, however, is backwards compatibility. We wouldn't be able to just shut that off entirely at the moment (not until we start working on API v3). That leaves me fairly certain that we need to either implement the entirety of JSON PATCH ourselves, or introduce a library which does this for us so we don't have to do that work.

I'll leave that decision to whomever decides to take this on.

This is an historical note.

Glance has never supported JSON patch. It supports a "useful and compatible subset of the functionality" of JSON patch [0].

Additionally, it does not support full JSON pointers.

The problem may be that at some point the API reference doc was rewritten with reference to JSON patch and JSON pointers, not with reference to what Glance actually supports.

That being said, it would be better if Glance fully supported RFC6092, using a standard library (as Glare is doing). But I think that would require a spec.

[0] http://specs.openstack.org/openstack/glance-specs/specs/api/v2/http-patch-image-api-v2.html

Well, if I'm being completely honest, it was not compatible. I don't understand why a project would want to implement a subset because a cognitive burden is placed on end-users to not only understand JSON PATCH (which is very complicated to begin with), but also on the delta between what's in the spec and what Glance pick and mixes for its codebase.

Because things don't work as expected, and because of this cognitive burden, I didn't extract any value out of the implementation (it certainly wasn't useful for me). I think that if projects want to use JSON PATCH, that's fine, but they must implement it wholly. Otherwise you're introducing a great deal of uncertainty and complexity into something just for implementation reasons, which is irrelevant to end-users.

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