Re: [PATCH] meta_header option

On 12/10/2012 5:10 p.m., Alex Rousskov wrote:
> On 10/11/2012 07:32 PM, Amos Jeffries wrote:
>> On 12/10/2012 4:05 a.m., Alex Rousskov wrote:
>>> On 10/11/2012 05:21 AM, Amos Jeffries wrote:
>>>> If you can avoid calling the
>>>> list of key:pair entries *headers* it would be less confusing.
>>> Here are a few other naming options to consider, from the ones I like
>>> the most to the ones I like the least:
>>>
>>> 1a) annotation key value ...
>>> logformat ... %{key}annotation ...
>>>
>>> 1b) note key value ...
>>> logformat ... %{key}note ...
>>>
>>> 2a) marker key value ...
>>> logformat ... %{key}marker ...
>>>
>>> 2b) mark key value ...
>>> logformat ... %{key}mark ...
>>>
>>> 3) stamp key value ...
>>> logformat ... %{key}stamp ...
>>>
>>> 4) label key value ...
>>> logformat ... %{key}label
>>>
>>> 5) info key value ...
>>> logformat ... %{key}info
>>>
>>>
>>> All of which can be prefixed with "meta_", "xaction_", or "master_"
>>> prefixes (with varying degree of appropriateness).
>
>> Of the above I like "label" or "note".
> If there are no other opinions, I suggest "note" (short for annotation).
>
>
>> I got a request to implement stacked tags in external ACL the other day.
>> It would seem they are suited well for combining with this feature. How
>> about "tag" or "meta_tag" ?
> I assume stacked tags are key:value pairs. Today, tags are essentially
> anonymous or valueless annotations (values without keys or keys without
> values). Please correct me if I am wrong.

You are correct. I consider them as a key of "tag" and a value since
they arrive from the helper as "tag=X". The no-replace semantics from
secondary helpers or tags given is a small problem, which we will need
to work around. But that can remain isolated to external ACL code for
now until people are used to the.
  I was going to use these meta-X items as stacked tags and allow the
admin to pick their own arbitrary key name.

All the rest of the components you mention can search for a meta-X item
of name "tag" and use its value. When we figure out a good upgrade to
safely use multiple "tag=X" meta pairs.

> The reason I did not include "tag" in the above names is because I was
> worried that preserving compatibility with the existing tags will create
> a mess. Here are a few potentially messy areas:

I'm not so worried. Elsewhere the concept of tagging things is common.
Squid is the weird case where we only allow one tag per transaction (so
far).

> * The existing tag ACL syntax is not easily extensible to something that
> works with key:value pairs. If we make the first argument after the
> "tag" type a key name, old configs with multiple tags will continue to
> work (but will work incorrectly). Most likely, we will need a new ACL
> type name anyway.

If they supply key-pair "tag=X tag=Y" I would expect that ACL to match
either X or Y, and ignore any other key-pair not called "tag" eg
"group=X group=Y tag=X".

We need a new ACL type to match meta_* taking both key name and value.
Like we do for type external, taking the helper config file label and
values. tag type ACL becoming a (deprecated?) special-case version of that.

> * I am not sure how to deal with "class 5" delay pools grouping if tags
> have keys and values. Group by keys only? Group by both keys and values?
> May have to be configurable.

I would say they only apply to meta with name of "tag" to retain behaviour.

Long term I want to erase the class concept of delay pools and have:
  * each client transaction assigned a whole set of pools.
  * ALL pools assigned to a transaction are deducted when bandwidth is used
  * when determining how much to write the min available from any single
pool is permitted (guaranteeing that amount is able to safely be
deducted from ALL pools)

Initially the class 1 would map to one aggregate pool (each bucket
shared-ptr by all client using it), class 3 three (individual, network,
aggregate) pools and a user or tag pool for class 4/5.
When this is all done the "tag" documented for class 5 could be an
arbitrary meta key name set in the config file.

>
> * Old tag ACLs in existing configs may suddenly and unexpectedly start
> matching new annotations, especially if those new annotations have empty
> values.
>
> * Some admins do not want annotations to appear in ICAP and eCAP
> requests without their explicit control. The proposed implementation
> takes care of that because annotations are only added after adaptation
> is completed (and there is adaptation_meta for the opposite cases). If
> old tags become annotations, we would need to preserve that status quo
> for now. (Eventually, I am sure that somebody will need to send some
> tags/annotations to adaptation services, creating more problems.)

We can work out some form of filtering I'm sure.

>
> Overall, I agree that it would be nice to have one name/concept for all
> annotations, but reusing "tag"s may create a mess that will either
> significantly delay the new feature acceptance (folks will keep asking
> for new ways to resolve conflicts with the old tags) or will cause
> upgrade problems. It may be better to leave "tag"s to old configs and
> standardize on new "note"s going forward (e.g., add them to external
> ACLs). What do you think?

I think its not as bad as you think. But agree to avoid it for now.

Just had another idea. "key" or "keys".

Amos
Received on Fri Oct 12 2012 - 07:07:31 MDT