DRAFT pulp_labels POC #5787
DRAFT pulp_labels POC #5787
Conversation
ggainey
force-pushed
the
label_content
branch
from
7219570
to
85b3c87
Compare
|
Note that RBAC support for set/unset-labels requires work in the plugins - see the pulp_file commit. Current issues:
|
ggainey
force-pushed
the
label_content
branch
from
85b3c87
to
c23fc71
Compare
ggainey
force-pushed
the
label_content
branch
from
c23fc71
to
988f062
Compare
| "You may also specify '*' as an entry to remove all content. This content is " | ||
| "removed before add_content_units are added." | ||
| "You may specify '*' as an entry to remove all content, or 'key=value' pairs " | ||
| "to remove content by-label. This content is removed before add_content_units " | ||
| "are added." |
There was a problem hiding this comment.
OK, I can see, that this is still unambiguous. But should we maybe go for a new remove_q field?
You may for example remove all files from a repository by their relative_path__startswith...
So the logic could start with remove_q="pulp_label_select='foo'" and later we add support for remove_q="pulp_label_select='foo' OR relative_path__startswith='/bar/'.
There was a problem hiding this comment.
Having said that, should we factor this part (advanced modify) into it's own PR? It would give us time to think this high level api design over.
Given that a user can filter content by labels, they can already compile the set of content hrefs locally to call modify with them.
There was a problem hiding this comment.
Given that a user can filter content by labels, they can already compile the set of content hrefs locally to call modify with them.
Yes - but the user-experience of calling an API with a list of possibly thousands of HREFs, for one label, is...suboptimal. And "remove all the units with a given build id" is the actual requirement we're being asked to respond to, it's the point for doing this at all.
I can see benefits to a more-general Q filter - but I'm not sure the extra flexibility is worth the extra complication?
| # Current: multiple labels, mixed with hrefs, only '=' | ||
| # "x=y" can happen multiple times, and means "all content with label x=y, pass k=v pair" | ||
| labels_specified = [s for s in value if "=" in s] |
There was a problem hiding this comment.
Technically you can have a label that is just a key, with no value. So we probably should assume anything that doesn't begin with a slash to be a proper label.
There was a problem hiding this comment.
Ooof, good point. Pushes us towards @mdellweg 's comment above, to have a remove_q=... construct.
No description provided.