SOLR-16536 Replace OpenTracing instrumentation with OpenTelemetry

https://issues.apache.org/jira/browse/SOLR-16536

Description
Move all tracing code to OTEL.
Solution

Updated otel dependencies to 1.28.0.
OTEL tracing is 'always on' but the impls will be noops if OTEL is not enabled. this might need to be profiled more attentively to see if it adds much overhead.
Tried as much as possible to move all otel code to the TraceUtils utils class.

Code still in flux in some areas, because it was unclear what the expectations are:

TracerConfigurator - I don't think SpanThreadLocalProvider is still needed. happy to be shown otherwise, I would actually want to understand more where this was used.
V2HttpCall method that collects the span name. there are code paths that break when this is enabled, I am not sure how/if this works on main branch now(I am assuming it doesn't).
span attributes need a review
documentation needs an update probably
TestDistributedTracing - has some race problems. otel will not init properly. I am trying to avoid the globals but for now, it's still there.

Tests
Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem.
Checklist
Please review the following and check all that apply:

[x] I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
[x] I have created a Jira issue and added the issue ID to my pull request title.
[x] I have given Solr maintainers access to contribute to my PR branch. (optional but recommended)
[x] I have developed this patch against the main branch.
[x] I have run ./gradlew check.
[x] I have added tests for my changes.
[ ] I have added documentation for the Reference Guide

posting a screenshot from jaeger ui to demo what this data looks like for a query.

Hi, please connect this PR to SOLR-16536 instead (and not the umbrella issue).

Dependency analysis found issues.
usedUndeclaredArtifacts

io.opentelemetry:opentelemetry-api:1.28.0@jar
org.apache.solr:solrj:10.0.0-SNAPSHOT@
unusedDeclaredArtifacts
io.opentelemetry:opentelemetry-api-events:1.28.0-alpha@jar
io.opentelemetry:opentelemetry-sdk-trace:1.28.0@jar
io.opentelemetry:opentelemetry-sdk:1.28.0@jar
io.opentelemetry:opentelemetry-semconv:1.28.0-alpha@jar

This hits at changes needed in gradle build. There are permitUnusedDeclared keywords that can be used in build.gradle to tell the build that they are on purpose.

WARNING: there were unreferenced files under license folder:

/home/runner/work/solr/solr/solr/licenses/opentracing-api-LICENSE-ASL.txt
/home/runner/work/solr/solr/solr/licenses/opentracing-api-NOTICE.txt
/home/runner/work/solr/solr/solr/licenses/opentracing-mock-LICENSE-ASL.txt
/home/runner/work/solr/solr/solr/licenses/opentracing-mock-NOTICE.txt
/home/runner/work/solr/solr/solr/licenses/opentracing-noop-LICENSE-ASL.txt
/home/runner/work/solr/solr/solr/licenses/opentracing-noop-NOTICE.txt
/home/runner/work/solr/solr/solr/licenses/opentracing-util-LICENSE-ASL.txt
/home/runner/work/solr/solr/solr/licenses/opentracing-util-NOTICE.txt

These files from licenses/ folder can now be removed as we don't have opentracing as a dependency anymore.

Hi, please connect this PR to SOLR-16536 instead (and not the umbrella issue).

you are right. renamed the PR to reflect the correct issue

Thank you @janhoy for the review!
I think the biggest question was the removal of span.log. it felt strange to have logs mixed with spans. maybe I misunderstood the use. happy to look into otel alternatives
I am seeing some backup related tests failing on my local and on the crave build. will dig into those a bit more, I want to reach a stable state before making more changes.

sorry, had to do a rebase on top of main branch to fix some conflicts.

quick comparison of span data (exporting from jaeger on 9.3 vs this PR):

Query spans on this PR
{
    "data": [
        {
            "traceID": "b3e378158f072905b2920df7714ddd37",
            "spans": [
                {
                    "traceID": "b3e378158f072905b2920df7714ddd37",
                    "spanID": "86487341790e7776",
                    "operationName": "post:/{core}/select",
                    "references": [
                        {
                            "refType": "CHILD_OF",
                            "traceID": "b3e378158f072905b2920df7714ddd37",
                            "spanID": "bcf1836208e5a7a4"
                        }
                    ],
                    "startTime":<PHONE_NUMBER>595665,
                    "duration": 30937,
                    "tags": [
                        {
                            "key": "otel.library.name",
                            "type": "string",
                            "value": "solr"
                        },
                        {
                            "key": "http.method",
                            "type": "string",
                            "value": "POST"
                        },
                        {
                            "key": "http.url",
                            "type": "string",
                            "value": "http://localhost:8982/solr/test_shard2_replica_n1/select"
                        },
                        {
                            "key": "db.instance",
                            "type": "string",
                            "value": "test_shard2_replica_n1"
                        },
                        {
                            "key": "db.type",
                            "type": "string",
                            "value": "solr"
                        },
                        {
                            "key": "http.status",
                            "type": "int64",
                            "value": 200
                        },
                        {
                            "key": "span.kind",
                            "type": "string",
                            "value": "server"
                        },
                        {
                            "key": "internal.span.format",
                            "type": "string",
                            "value": "proto"
                        }
                    ],
                    "logs": [],
                    "processID": "p1",
                    "warnings": null
                },
                {
                    "traceID": "b3e378158f072905b2920df7714ddd37",
                    "spanID": "bcf1836208e5a7a4",
                    "operationName": "get:/{collection}/select",
                    "references": [],
                    "startTime":<PHONE_NUMBER>566962,
                    "duration": 63467,
                    "tags": [
                        {
                            "key": "otel.library.name",
                            "type": "string",
                            "value": "solr"
                        },
                        {
                            "key": "http.method",
                            "type": "string",
                            "value": "GET"
                        },
                        {
                            "key": "http.url",
                            "type": "string",
                            "value": "http://localhost:8983/solr/test/select"
                        },
                        {
                            "key": "db.instance",
                            "type": "string",
                            "value": "test"
                        },
                        {
                            "key": "db.type",
                            "type": "string",
                            "value": "solr"
                        },
                        {
                            "key": "http.status",
                            "type": "int64",
                            "value": 200
                        },
                        {
                            "key": "http.params",
                            "type": "string",
                            "value": "_=1692133666339\u0026indent=true\u0026q=*:*\u0026q.op=OR\u0026useParams="
                        },
                        {
                            "key": "span.kind",
                            "type": "string",
                            "value": "server"
                        },
                        {
                            "key": "internal.span.format",
                            "type": "string",
                            "value": "proto"
                        }
                    ],
                    "logs": [],
                    "processID": "p1",
                    "warnings": null
                },
                {
                    "traceID": "b3e378158f072905b2920df7714ddd37",
                    "spanID": "3a9142862158b626",
                    "operationName": "post:/{core}/select",
                    "references": [
                        {
                            "refType": "CHILD_OF",
                            "traceID": "b3e378158f072905b2920df7714ddd37",
                            "spanID": "bcf1836208e5a7a4"
                        }
                    ],
                    "startTime":<PHONE_NUMBER>595437,
                    "duration": 20848,
                    "tags": [
                        {
                            "key": "otel.library.name",
                            "type": "string",
                            "value": "solr"
                        },
                        {
                            "key": "http.method",
                            "type": "string",
                            "value": "POST"
                        },
                        {
                            "key": "http.url",
                            "type": "string",
                            "value": "http://localhost:8983/solr/test_shard1_replica_n2/select"
                        },
                        {
                            "key": "db.instance",
                            "type": "string",
                            "value": "test_shard1_replica_n2"
                        },
                        {
                            "key": "db.type",
                            "type": "string",
                            "value": "solr"
                        },
                        {
                            "key": "http.status",
                            "type": "int64",
                            "value": 200
                        },
                        {
                            "key": "span.kind",
                            "type": "string",
                            "value": "server"
                        },
                        {
                            "key": "internal.span.format",
                            "type": "string",
                            "value": "proto"
                        }
                    ],
                    "logs": [],
                    "processID": "p1",
                    "warnings": null
                }
            ],
            "processes": {
                "p1": {
                    "serviceName": "solr",
                    "tags": [
                        {
                            "key": "host.name",
                            "type": "string",
                            "value": "localhost"
                        },
                        {
                            "key": "telemetry.sdk.language",
                            "type": "string",
                            "value": "java"
                        },
                        {
                            "key": "telemetry.sdk.name",
                            "type": "string",
                            "value": "opentelemetry"
                        },
                        {
                            "key": "telemetry.sdk.version",
                            "type": "string",
                            "value": "1.28.0"
                        }
                    ]
                }
            },
            "warnings": null
        }
    ],
    "total": 0,
    "limit": 0,
    "offset": 0,
    "errors": null
}

vs

Query spans on this 9.3
{
    "data": [
        {
            "traceID": "36d81b003d238f7278c467132917ee3c",
            "spans": [
                {
                    "traceID": "36d81b003d238f7278c467132917ee3c",
                    "spanID": "0ea50951fdf8c5ed",
                    "operationName": "post:/{core}/select",
                    "references": [
                        {
                            "refType": "CHILD_OF",
                            "traceID": "36d81b003d238f7278c467132917ee3c",
                            "spanID": "9cf9b219437d234c"
                        },
                        {
                            "refType": "CHILD_OF",
                            "traceID": "36d81b003d238f7278c467132917ee3c",
                            "spanID": "9cf9b219437d234c"
                        }
                    ],
                    "startTime":<PHONE_NUMBER>573648,
                    "duration": 5985,
                    "tags": [
                        {
                            "key": "otel.library.name",
                            "type": "string",
                            "value": "opentracing-shim"
                        },
                        {
                            "key": "http.url",
                            "type": "string",
                            "value": "http://localhost:8982/solr/test_shard2_replica_n1/select"
                        },
                        {
                            "key": "http.status_code",
                            "type": "int64",
                            "value": 200
                        },
                        {
                            "key": "http.method",
                            "type": "string",
                            "value": "POST"
                        },
                        {
                            "key": "db.type",
                            "type": "string",
                            "value": "solr"
                        },
                        {
                            "key": "db.instance",
                            "type": "string",
                            "value": "test_shard2_replica_n1"
                        },
                        {
                            "key": "span.kind",
                            "type": "string",
                            "value": "server"
                        },
                        {
                            "key": "span.kind",
                            "type": "string",
                            "value": "internal"
                        },
                        {
                            "key": "internal.span.format",
                            "type": "string",
                            "value": "proto"
                        }
                    ],
                    "logs": [],
                    "processID": "p1",
                    "warnings": null
                },
                {
                    "traceID": "36d81b003d238f7278c467132917ee3c",
                    "spanID": "7d539974b1cf00bf",
                    "operationName": "post:/{core}/select",
                    "references": [
                        {
                            "refType": "CHILD_OF",
                            "traceID": "36d81b003d238f7278c467132917ee3c",
                            "spanID": "9cf9b219437d234c"
                        },
                        {
                            "refType": "CHILD_OF",
                            "traceID": "36d81b003d238f7278c467132917ee3c",
                            "spanID": "9cf9b219437d234c"
                        }
                    ],
                    "startTime":<PHONE_NUMBER>542767,
                    "duration": 26760,
                    "tags": [
                        {
                            "key": "otel.library.name",
                            "type": "string",
                            "value": "opentracing-shim"
                        },
                        {
                            "key": "http.url",
                            "type": "string",
                            "value": "http://localhost:8982/solr/test_shard2_replica_n1/select"
                        },
                        {
                            "key": "http.status_code",
                            "type": "int64",
                            "value": 200
                        },
                        {
                            "key": "http.method",
                            "type": "string",
                            "value": "POST"
                        },
                        {
                            "key": "db.type",
                            "type": "string",
                            "value": "solr"
                        },
                        {
                            "key": "db.instance",
                            "type": "string",
                            "value": "test_shard2_replica_n1"
                        },
                        {
                            "key": "span.kind",
                            "type": "string",
                            "value": "server"
                        },
                        {
                            "key": "span.kind",
                            "type": "string",
                            "value": "internal"
                        },
                        {
                            "key": "internal.span.format",
                            "type": "string",
                            "value": "proto"
                        }
                    ],
                    "logs": [],
                    "processID": "p1",
                    "warnings": null
                },
                {
                    "traceID": "36d81b003d238f7278c467132917ee3c",
                    "spanID": "9cf9b219437d234c",
                    "operationName": "get:/{collection}/select",
                    "references": [],
                    "startTime":<PHONE_NUMBER>508568,
                    "duration": 72193,
                    "tags": [
                        {
                            "key": "otel.library.name",
                            "type": "string",
                            "value": "opentracing-shim"
                        },
                        {
                            "key": "http.url",
                            "type": "string",
                            "value": "http://localhost:8983/solr/test/select"
                        },
                        {
                            "key": "http.status_code",
                            "type": "int64",
                            "value": 200
                        },
                        {
                            "key": "http.method",
                            "type": "string",
                            "value": "GET"
                        },
                        {
                            "key": "http.params",
                            "type": "string",
                            "value": "_=1692134966416\u0026indent=true\u0026q=*:*\u0026q.op=OR\u0026useParams="
                        },
                        {
                            "key": "db.type",
                            "type": "string",
                            "value": "solr"
                        },
                        {
                            "key": "db.instance",
                            "type": "string",
                            "value": "test"
                        },
                        {
                            "key": "span.kind",
                            "type": "string",
                            "value": "server"
                        },
                        {
                            "key": "span.kind",
                            "type": "string",
                            "value": "internal"
                        },
                        {
                            "key": "internal.span.format",
                            "type": "string",
                            "value": "proto"
                        }
                    ],
                    "logs": [],
                    "processID": "p1",
                    "warnings": null
                },
                {
                    "traceID": "36d81b003d238f7278c467132917ee3c",
                    "spanID": "4899cdb8a9e4200d",
                    "operationName": "post:/{core}/select",
                    "references": [
                        {
                            "refType": "CHILD_OF",
                            "traceID": "36d81b003d238f7278c467132917ee3c",
                            "spanID": "9cf9b219437d234c"
                        },
                        {
                            "refType": "CHILD_OF",
                            "traceID": "36d81b003d238f7278c467132917ee3c",
                            "spanID": "9cf9b219437d234c"
                        }
                    ],
                    "startTime":<PHONE_NUMBER>543674,
                    "duration": 14919,
                    "tags": [
                        {
                            "key": "otel.library.name",
                            "type": "string",
                            "value": "opentracing-shim"
                        },
                        {
                            "key": "http.url",
                            "type": "string",
                            "value": "http://localhost:8983/solr/test_shard1_replica_n2/select"
                        },
                        {
                            "key": "http.status_code",
                            "type": "int64",
                            "value": 200
                        },
                        {
                            "key": "http.method",
                            "type": "string",
                            "value": "POST"
                        },
                        {
                            "key": "db.type",
                            "type": "string",
                            "value": "solr"
                        },
                        {
                            "key": "db.instance",
                            "type": "string",
                            "value": "test_shard1_replica_n2"
                        },
                        {
                            "key": "span.kind",
                            "type": "string",
                            "value": "server"
                        },
                        {
                            "key": "span.kind",
                            "type": "string",
                            "value": "internal"
                        },
                        {
                            "key": "internal.span.format",
                            "type": "string",
                            "value": "proto"
                        }
                    ],
                    "logs": [],
                    "processID": "p1",
                    "warnings": null
                }
            ],
            "processes": {
                "p1": {
                    "serviceName": "solr",
                    "tags": [
                        {
                            "key": "host.name",
                            "type": "string",
                            "value": "localhost"
                        },
                        {
                            "key": "telemetry.sdk.language",
                            "type": "string",
                            "value": "java"
                        },
                        {
                            "key": "telemetry.sdk.name",
                            "type": "string",
                            "value": "opentelemetry"
                        },
                        {
                            "key": "telemetry.sdk.version",
                            "type": "string",
                            "value": "1.21.0"
                        }
                    ]
                }
            },
            "warnings": null
        }
    ],
    "total": 0,
    "limit": 0,
    "offset": 0,
    "errors": null
}

Diff:

9.3 every child has 2 entries under references but they are the same, this looks like a duplication problem with 9.3 data
9.3 every span entry has 2 span.kind entries one server and one internal vs. PR with a single entry server

quick comparison of Indexing span data (exporting from jaeger on 9.3 vs this PR):

Update spans on this PR
{
    "data": [
        {
            "traceID": "d0cd6efa699d993637bfc1f313742f1f",
            "spans": [
                {
                    "traceID": "d0cd6efa699d993637bfc1f313742f1f",
                    "spanID": "ac76ee5c9f41ceb6",
                    "operationName": "post:/{core}/update",
                    "references": [
                        {
                            "refType": "CHILD_OF",
                            "traceID": "d0cd6efa699d993637bfc1f313742f1f",
                            "spanID": "f9d87bf73cd5a669"
                        }
                    ],
                    "startTime":<PHONE_NUMBER>932096,
                    "duration": 222281,
                    "tags": [
                        {
                            "key": "otel.library.name",
                            "type": "string",
                            "value": "solr"
                        },
                        {
                            "key": "http.method",
                            "type": "string",
                            "value": "POST"
                        },
                        {
                            "key": "http.url",
                            "type": "string",
                            "value": "http://localhost:8982/solr/test_shard2_replica_n1/update"
                        },
                        {
                            "key": "db.instance",
                            "type": "string",
                            "value": "test_shard2_replica_n1"
                        },
                        {
                            "key": "db.type",
                            "type": "string",
                            "value": "solr"
                        },
                        {
                            "key": "http.status",
                            "type": "int64",
                            "value": 200
                        },
                        {
                            "key": "http.params",
                            "type": "string",
                            "value": "update.distrib=TOLEADER\u0026distrib.from=http%3A%2F%2Flocalhost%3A8983%2Fsolr%2Ftest_shard1_replica_n2%2F\u0026wt=javabin\u0026version=2"
                        },
                        {
                            "key": "span.kind",
                            "type": "string",
                            "value": "server"
                        },
                        {
                            "key": "internal.span.format",
                            "type": "string",
                            "value": "proto"
                        }
                    ],
                    "logs": [],
                    "processID": "p1",
                    "warnings": null
                },
                {
                    "traceID": "d0cd6efa699d993637bfc1f313742f1f",
                    "spanID": "f9d87bf73cd5a669",
                    "operationName": "post:/{collection}/update",
                    "references": [],
                    "startTime":<PHONE_NUMBER>686908,
                    "duration": 468961,
                    "tags": [
                        {
                            "key": "otel.library.name",
                            "type": "string",
                            "value": "solr"
                        },
                        {
                            "key": "http.method",
                            "type": "string",
                            "value": "POST"
                        },
                        {
                            "key": "http.url",
                            "type": "string",
                            "value": "http://localhost:8983/solr/test/update"
                        },
                        {
                            "key": "db.instance",
                            "type": "string",
                            "value": "test"
                        },
                        {
                            "key": "db.type",
                            "type": "string",
                            "value": "solr"
                        },
                        {
                            "key": "http.status",
                            "type": "int64",
                            "value": 200
                        },
                        {
                            "key": "http.params",
                            "type": "string",
                            "value": "_=1692133972530\u0026commitWithin=10\u0026overwrite=true\u0026wt=json"
                        },
                        {
                            "key": "span.kind",
                            "type": "string",
                            "value": "server"
                        },
                        {
                            "key": "internal.span.format",
                            "type": "string",
                            "value": "proto"
                        }
                    ],
                    "logs": [],
                    "processID": "p1",
                    "warnings": null
                }
            ],
            "processes": {
                "p1": {
                    "serviceName": "solr",
                    "tags": [
                        {
                            "key": "host.name",
                            "type": "string",
                            "value": "localhost"
                        },
                        {
                            "key": "telemetry.sdk.language",
                            "type": "string",
                            "value": "java"
                        },
                        {
                            "key": "telemetry.sdk.name",
                            "type": "string",
                            "value": "opentelemetry"
                        },
                        {
                            "key": "telemetry.sdk.version",
                            "type": "string",
                            "value": "1.28.0"
                        }
                    ]
                }
            },
            "warnings": null
        }
    ],
    "total": 0,
    "limit": 0,
    "offset": 0,
    "errors": null
}

Update spans on Solr 9.3 PR
{
    "data": [
        {
            "traceID": "49503807dd79f2bf5e20fddfabbca6b0",
            "spans": [
                {
                    "traceID": "49503807dd79f2bf5e20fddfabbca6b0",
                    "spanID": "e79354cfcc9a1c8d",
                    "operationName": "post:/{core}/update",
                    "references": [
                        {
                            "refType": "CHILD_OF",
                            "traceID": "49503807dd79f2bf5e20fddfabbca6b0",
                            "spanID": "3b5a75c06c661620"
                        },
                        {
                            "refType": "CHILD_OF",
                            "traceID": "49503807dd79f2bf5e20fddfabbca6b0",
                            "spanID": "3b5a75c06c661620"
                        }
                    ],
                    "startTime":<PHONE_NUMBER>803056,
                    "duration": 216899,
                    "tags": [
                        {
                            "key": "otel.library.name",
                            "type": "string",
                            "value": "opentracing-shim"
                        },
                        {
                            "key": "http.url",
                            "type": "string",
                            "value": "http://localhost:8982/solr/test_shard2_replica_n1/update"
                        },
                        {
                            "key": "http.status_code",
                            "type": "int64",
                            "value": 200
                        },
                        {
                            "key": "http.method",
                            "type": "string",
                            "value": "POST"
                        },
                        {
                            "key": "http.params",
                            "type": "string",
                            "value": "update.distrib=TOLEADER\u0026distrib.from=http%3A%2F%2Flocalhost%3A8983%2Fsolr%2Ftest_shard1_replica_n2%2F\u0026wt=javabin\u0026version=2"
                        },
                        {
                            "key": "db.type",
                            "type": "string",
                            "value": "solr"
                        },
                        {
                            "key": "db.instance",
                            "type": "string",
                            "value": "test_shard2_replica_n1"
                        },
                        {
                            "key": "span.kind",
                            "type": "string",
                            "value": "server"
                        },
                        {
                            "key": "span.kind",
                            "type": "string",
                            "value": "internal"
                        },
                        {
                            "key": "internal.span.format",
                            "type": "string",
                            "value": "proto"
                        }
                    ],
                    "logs": [],
                    "processID": "p1",
                    "warnings": null
                },
                {
                    "traceID": "49503807dd79f2bf5e20fddfabbca6b0",
                    "spanID": "3b5a75c06c661620",
                    "operationName": "post:/{collection}/update",
                    "references": [],
                    "startTime":<PHONE_NUMBER>529315,
                    "duration": 491930,
                    "tags": [
                        {
                            "key": "otel.library.name",
                            "type": "string",
                            "value": "opentracing-shim"
                        },
                        {
                            "key": "http.url",
                            "type": "string",
                            "value": "http://localhost:8983/solr/test/update"
                        },
                        {
                            "key": "http.status_code",
                            "type": "int64",
                            "value": 200
                        },
                        {
                            "key": "http.method",
                            "type": "string",
                            "value": "POST"
                        },
                        {
                            "key": "http.params",
                            "type": "string",
                            "value": "_=1692133972530\u0026commitWithin=10\u0026overwrite=true\u0026wt=json"
                        },
                        {
                            "key": "db.type",
                            "type": "string",
                            "value": "solr"
                        },
                        {
                            "key": "db.instance",
                            "type": "string",
                            "value": "test"
                        },
                        {
                            "key": "span.kind",
                            "type": "string",
                            "value": "server"
                        },
                        {
                            "key": "span.kind",
                            "type": "string",
                            "value": "internal"
                        },
                        {
                            "key": "internal.span.format",
                            "type": "string",
                            "value": "proto"
                        }
                    ],
                    "logs": [],
                    "processID": "p1",
                    "warnings": null
                }
            ],
            "processes": {
                "p1": {
                    "serviceName": "solr",
                    "tags": [
                        {
                            "key": "host.name",
                            "type": "string",
                            "value": "localhost"
                        },
                        {
                            "key": "telemetry.sdk.language",
                            "type": "string",
                            "value": "java"
                        },
                        {
                            "key": "telemetry.sdk.name",
                            "type": "string",
                            "value": "opentelemetry"
                        },
                        {
                            "key": "telemetry.sdk.version",
                            "type": "string",
                            "value": "1.21.0"
                        }
                    ]
                }
            },
            "warnings": null
        }
    ],
    "total": 0,
    "limit": 0,
    "offset": 0,
    "errors": null
}

Diff:

9.3 every child has 2 entries under references but they are the same, this looks like a duplication problem with 9.3 data (same as Query data)
9.3 every span entry has 2 span.kind entries one server and one internal vs. PR with a single entry server (same as Query data)
9.3 spans have http.status_code attrib, where PR has http.status (same as Query data)

9.3 spans have http.status_code attrib, where PR has http.status

Please consult the otel semantic conventions for what attribute names to use. The former correct tag was http.status_code, but last month the OTEL project adopted ECS (Elastic Common Schema) as the new standard, so those conventions will change and stabilize, thus the correct tag will be http.response.status_code.
Perhaps we should emit both for some versions, or implement the suggested env var OTEL_SEMCONV_STABILITY_OPT_IN?

Perhaps we should emit both for some versions, or implement the suggested env var OTEL_SEMCONV_STABILITY_OPT_IN?

if this is for 2 fields only (http.status_code => http.response.status_code and http.method => http.request.method) it feels like overkill to implement this mechanism. I would emit both attributes old and new for a while and then drop them. let me know if you feel differently.

if this is for 2 fields only (http.status_code => http.response.status_code and http.method => http.request.method) it feels like overkill to implement this mechanism. I would emit both attributes old and new for a while and then drop them. let me know if you feel differently.

I'm ok with duplicating tags. But we should probably (now or as a follow-up) review every tag name that we explicitly define in our code, to see how it aligns with the recommendations, to make sure we covered all of them.

Tests seem to fail with SEVERE: 9 threads leaked from SUITE scope at org.apache.solr.opentelemetry.TestDistributedTracing:. Cannot reproduce locally. Re-running crave tests.

I reproduced the thread leak locally, but it does not happen every time. Also, the new Crave test run was successful. Looks like there is a timing issue. @stillalex how is the tracer life cycle handled now that we don't explicitly shut down the tracer in CoreContainer?

Wrt documentation. As long as the user-facing config and env vars are the same, and the spans created are almost identical, I think the only Ref-guide documentation to add is in "Major changes" section of upgrade notes, we can mention the deprecation of http.status_code and friends. If we plan to keep sending both for the entire 10.x line then we're fine. But this is of course linked with whatever consumer of traces (Jaeger etc) the user has. If we stick to the ECS standard from Solr 11 on, users can always remain on solr 10 if they require the old tags...
Would you like to give the docs a shot @stillalex ? Also, please add a line to CHANGES.txt for version 10.0.
Thinking about it - if we this PR is purely getting rid of OpenTracing and we do not change configuration in any way, it could be canidate for backporting to 9.4 release?

quick smoke test on benchmarking side, I tried running the existing CloudIndexing benchmark and numbers seem pretty close (I am sure there are more opportunities for improvement but I did not spend much time on this):

5 threads indexing over 60 seconds

./jmh.sh -wi 1 -i 1 -r 60 CloudIndexing -t 5 -p nodeCount=1 -p numShards=1 -p numReplicas=1 -p useStringUtf8Over=0 -p directBuffer=true

PR

Benchmark                    (directBuffer)  (nodeCount)  (numReplicas)  (numShards)  (scale)  (useStringUtf8Over)   Mode  Cnt      Score   Error  Units
CloudIndexing.indexLargeDoc            true            1              1            1        1                    0  thrpt        1116.343          ops/s
CloudIndexing.indexSmallDoc            true            1              1            1        1                    0  thrpt       29966.343          ops/s

MAIN

Benchmark                    (directBuffer)  (nodeCount)  (numReplicas)  (numShards)  (scale)  (useStringUtf8Over)   Mode  Cnt      Score   Error  Units
CloudIndexing.indexLargeDoc            true            1              1            1        1                    0  thrpt        1419.507          ops/s
CloudIndexing.indexSmallDoc            true            1              1            1        1                    0  thrpt       30111.511          ops/s

Yes, splitting out the otel version upgrade is a good idea!

moved the simple otel update to https://github.com/apache/solr/pull/1846 will rebase once that is in

@janhoy otel upgrade split, merged and rebase completed. running checks now to verify if I missed anything.

PS: Did you do a broader review of tag name changes apart from the two we covered, or should we put it up as a new JIRA?

No review yet. I was thinking I could do one as part of SOLR-16935 because I wanted to add 2 more spans.


Fine-tune for summarization

For research purposes. https://huggingface.co/datasets/samsum
(env) arno@rippa:/nfs4/llm/h2ogpt(main)$ CUDA_VISIBLE_DEVICES=0,1 torchrun --nproc_per_node=2 finetune.py --base_model=h2oai/h2ogpt-oasst1-512-12b --data_path=samsum --micro_batch_size=1 --batch_size=8 --cutoff_len=512 --num_epochs=1 --val_set_size=0 --eval_steps=100000 --save_steps=6000 --prompt_type=summarize --data_col_dict="{'dialogue': 'input', 'summary': 'output'}" --save_code=True --train_8bit=False --run_id=summarize12b

30 mins later:
python generate.py --base_model=h2oai/h2ogpt-oasst1-512-12b --lora_weights=h2ogpt-oasst1-512-12b.samsum.1_epochs.dcb56affddc75e56d928ef6a8b81b13154c6fd5d.summarize12b --infer_devices=False --prompt_type=summarize

`A solar eclipse occurs when the Moon passes between Earth and the Sun, thereby obscuring the view of the Sun from a small part of the Earth, totally or partially. Such an alignment occurs approximately every six months, during the eclipse season in its new moon phase, when the Moon's orbital plane is closest to the plane of the Earth's orbit.[1] In a total eclipse, the disk of the Sun is fully obscured by the Moon. In partial and annular eclipses, only part of the Sun is obscured. Unlike a lunar eclipse, which may be viewed from anywhere on the night side of Earth, a solar eclipse can only be viewed from a relatively small area of the world. As such, although total solar eclipses occur somewhere on Earth every 18 months on average, they recur at any given place only once every 360 to 410 years.
If the Moon were in a perfectly circular orbit and in the same orbital plane as Earth, there would be total solar eclipses once a month, at every new moon. Instead, because the Moon's orbit is tilted at about 5 degrees to Earth's orbit, its shadow usually misses Earth. Solar (and lunar) eclipses therefore happen only during eclipse seasons, resulting in at least two, and up to five, solar eclipses each year, no more than two of which can be total.[2][3] Total eclipses are more rare because they require a more precise alignment between the centers of the Sun and Moon, and because the Moon's apparent size in the sky is sometimes too small to fully cover the Sun.
An eclipse is a natural phenomenon. In some ancient and modern cultures, solar eclipses were attributed to supernatural causes or regarded as bad omens. Astronomers' predictions of eclipses began in China as early as the 4th century BC; eclipses hundreds of years into the future may now be predicted with high accuracy.
Looking directly at the Sun can lead to permanent eye damage, so special eye protection or indirect viewing techniques are used when viewing a solar eclipse. Only the total phase of a total solar eclipse is safe to view without protection. Enthusiasts known as eclipse chasers or umbraphiles travel to remote locations to see solar eclipses.[4][5]
The symbol for an occultation, and especially a solar eclipse, is 🝵 (U+1F775 🝵).
Types
Partial and annular phases of the solar eclipse of May 20, 2012
There are four types of solar eclipses:
A total eclipse occurs when the dark silhouette of the Moon completely obscures the intensely bright light of the Sun, allowing the much fainter solar corona to be visible. During any one eclipse, totality occurs at best only in a narrow track on the surface of Earth.[6] This narrow track is called the path of totality.[7]
An annular eclipse occurs when the Sun and Moon are exactly in line with the Earth, but the apparent size of the Moon is smaller than that of the Sun. Hence the Sun appears as a very bright ring, or annulus, surrounding the dark disk of the Moon.[8]
A hybrid eclipse (also called annular/total eclipse) shifts between a total and annular eclipse. At certain points on the surface of Earth, it appears as a total eclipse, whereas at other points it appears as annular. Hybrid eclipses are comparatively rare.[8]
A partial eclipse occurs when the Sun and Moon are not exactly in line with the Earth and the Moon only partially obscures the Sun. This phenomenon can usually be seen from a large part of the Earth outside of the track of an annular or total eclipse. However, some eclipses can be seen only as a partial eclipse, because the umbra passes above the Earth's polar regions and never intersects the Earth's surface.[8] Partial eclipses are virtually unnoticeable in terms of the Sun's brightness, as it takes well over 90% coverage to notice any darkening at all. Even at 99%, it would be no darker than civil twilight.[9]
Comparison of minimum and maximum apparent sizes of the Sun and Moon (and planets). An annular eclipse can occur when the Sun has a larger apparent size than the Moon, whereas a total eclipse can occur when the Moon has a larger apparent size.
The Sun's distance from Earth is about 400 times the Moon's distance, and the Sun's diameter is about 400 times the Moon's diameter. Because these ratios are approximately the same, the Sun and the Moon as seen from Earth appear to be approximately the same size: about 0.5 degree of arc in angular measure.[8]
The Moon's orbit around the Earth is slightly elliptical, as is the Earth's orbit around the Sun. The apparent sizes of the Sun and Moon therefore vary.[10] The magnitude of an eclipse is the ratio of the apparent size of the Moon to the apparent size of the Sun during an eclipse. An eclipse that occurs when the Moon is near its closest distance to Earth (i.e., near its perigee) can be a total eclipse because the Moon will appear to be large enough to completely cover the Sun's bright disk or photosphere; a total eclipse has a magnitude greater than or equal to 1.000. Conversely, an eclipse that occurs when the Moon is near its farthest distance from Earth (i.e., near its apogee) can be only an annular eclipse because the Moon will appear to be slightly smaller than the Sun; the magnitude of an annular eclipse is less than 1.[11]
A hybrid eclipse occurs when the magnitude of an eclipse changes during the event from less to greater than one, so the eclipse appears to be total at locations nearer the midpoint, and annular at other locations nearer the beginning and end, since the sides of the Earth are slightly further away from the Moon. These eclipses are extremely narrow in their path width and relatively short in their duration at any point compared with fully total eclipses; the 2023 April 20 hybrid eclipse's totality is over a minute in duration at various points along the path of totality. Like a focal point, the width and duration of totality and annularity are near zero at the points where the changes between the two occur.[12]
Because the Earth's orbit around the Sun is also elliptical, the Earth's distance from the Sun similarly varies throughout the year. This affects the apparent size of the Sun in the same way, but not as much as does the Moon's varying distance from Earth.[8] When Earth approaches its farthest distance from the Sun in early July, a total eclipse is somewhat more likely, whereas conditions favour an annular eclipse when Earth approaches its closest distance to the Sun in early January.[13]`

summary, pretty good
- A solar eclipse occurs when the Moon passes between Earth and the Sun, thereby obscuring the view of the Sun from a small part of the Earth, totally or partially. Such an alignment occurs approximately every six months, during the eclipse season in its new moon phase, when the Moon’s orbital plane is closest to the plane of the Earth’s orbit.
- In a total eclipse, the disk of the Sun is fully obscured by the Moon. In partial and annular eclipses, only part of the Sun is obscured.
- Unlike a lunar eclipse, which may be viewed from anywhere on the night side of Earth, a solar eclipse can only be viewed from a relatively small area of the world. As such, although total solar eclipses occur somewhere on Earth every 18 months on average, they recur at any given place only once every 360 to 410 years.
- If the Moon were in a perfectly circular orbit and in the same orbital plane as Earth, there would be total solar eclipses once a month, at every new moon. Instead, because the Moon’s orbit is tilted at about 5 degrees to Earth’s orbit, its shadow usually misses Earth. Solar (and lunar) eclipses therefore happen only during eclipse seasons,

"IRS’s mission is to provide America’s taxpayers top-quality service by helping them to understand and meet their tax responsibilities and to enforce the law with integrity and fairness to all. During fiscal year 2015, IRS collected more than $3.3 trillion; processed more than 243 million tax returns and other forms; and issued more than $403 billion in tax refunds. IRS employs about 90,000 people in its Washington, D.C., headquarters and at more than 550 offices in all 50 states, U.S. territories, and some U.S. embassies and consulates. Each filing season IRS provides assistance to tens of millions of taxpayers over the phone, through written correspondence, online, and face-to-face. The scale of these operations alone presents challenges. In carrying out its mission, IRS relies extensively on computerized information systems, which it must effectively secure to protect sensitive financial and taxpayer data for the collection of taxes, processing of tax returns, and enforcement of federal tax laws. Accordingly, it is critical for IRS to effectively implement information security controls and an agency- wide information security program in accordance with federal law and guidance. Cyber incidents can adversely affect national security, damage public health and safety, and compromise sensitive information. Regarding IRS specifically, two recent incidents illustrate the impact on taxpayer and other sensitive information: In June 2015, the Commissioner of the IRS testified that unauthorized third parties had gained access to taxpayer information from its Get Transcript application. According to officials, criminals used taxpayer- specific data acquired from non-department sources to gain unauthorized access to information on approximately 100,000 tax accounts. These data included Social Security information, dates of birth, and street addresses. In an August 2015 update, IRS reported this number to be about 114,000, and that an additional 220,000 accounts had been inappropriately accessed. In a February 2016 update, the agency reported that an additional 390,000 accounts had been accessed. Thus, about 724,000 accounts were reportedly affected. The online Get Transcript service has been unavailable since May 2015. In March 2016, IRS stated that as part of its ongoing security review, it had temporarily suspended the Identity Protection Personal Identification Number (IP PIN) service on IRS.gov. The IP PIN is a single-use identification number provided to taxpayers who are victims of identity theft (IDT) to help prevent future IDT refund fraud. The service on IRS’s website allowed taxpayers to retrieve their IP PINs online by passing IRS’s authentication checks. These checks confirm taxpayer identity by asking for personal, financial and tax-related information. The IRS stated that it was conducting further review of the IP PIN service and is looking at further strengthening the security features before resuming service. As of April 7, the online service was still suspended. The Commissioner of Internal Revenue has overall responsibility for ensuring the confidentiality, integrity, and availability of the information and systems that support the agency and its operations. Within IRS, the senior agency official responsible for information security is the Associate CIO, who heads the IRS Information Technology Cybersecurity organization. As we reported in March 2016, IRS has implemented numerous controls over key financial and tax processing systems; however, it had not always effectively implemented access and other controls, including elements of its information security program. Access controls are intended to prevent, limit, and detect unauthorized access to computing resources, programs, information, and facilities. These controls include identification and authentication, authorization, cryptography, audit and monitoring, and physical security controls, among others. In our most recent review we found that IRS had improved access controls, but some weaknesses remain. Identifying and authenticating users—such as through user account-password combinations—provides the basis for establishing accountability and controlling access to a system. IRS established policies for identification and authentication, including requiring multifactor authentication for local and network access accounts and establishing password complexity and expiration requirements. It also improved identification and authentication controls by, for example, expanding the use of an automated mechanism to centrally manage, apply, and verify password requirements. However, weaknesses in identification and authentication controls remained. For example, the agency used easily guessable passwords on servers supporting key systems. Authorization controls limit what actions users are able to perform after being allowed into a system and should be based on the concept of “least privilege,” granting users the least amount of rights and privileges necessary to perform their duties. While IRS established policies for authorizing access to its systems, it continued to permit excessive access in some cases. For example, users were granted rights and permissions in excess of what they needed to perform their duties, including for an application used to process electronic tax payment information and a database on a human resources system. Cryptography controls protect sensitive data and computer programs by rendering data unintelligible to unauthorized users and protecting the integrity of transmitted or stored data. IRS policies require the use of encryption and it continued to expand its use of encryption to protect sensitive data. However, key systems we reviewed had not been configured to encrypt sensitive user authentication data. Audit and monitoring is the regular collection, review, and analysis of events on systems and networks in order to detect, respond to, and investigate unusual activity. IRS established policies and procedures for auditing and monitoring its systems and continued to enhance its capability by, for example, implementing an automated mechanism to log user activity on its access request and approval system. But it had not established logging for two key applications used to support the transfer of financial data and access and manage taxpayer accounts; nor was the agency consistently maintaining key system and application audit plans. Physical security controls, such as physical access cards, limit access to an organization’s overall facility and areas housing sensitive IT components. IRS established policies for physically protecting its computer resources and physical security controls at its enterprise computer centers, such as a dedicated guard force at each of its computer centers. However, the agency had yet to address weaknesses in its review of access lists for both employees and visitors to sensitive areas. IRS also had weaknesses in configuration management controls, which are intended to prevent unauthorized changes to information system resources (e.g., software and hardware) and provide assurance that systems are configured and operating securely. Specifically, while IRS developed policies for managing the configuration of its information technology (IT) systems and improved some configuration management controls, it did not, for example, ensure security patch updates were applied in a timely manner to databases supporting 2 key systems we reviewed, including a patch that had been available since August 2012. To its credit, IRS had established contingency plans for the systems we reviewed, which help ensure that when unexpected events occur, critical operations can continue without interruption or can be promptly resumed, and that information resources are protected. Specifically, IRS had established policies for developing contingency plans for its information systems and for testing those plans, as well as for implementing and enforcing backup procedures. Moreover, the agency had documented and tested contingency plans for its systems and improved continuity of operations controls for several systems. Nevertheless, the control weaknesses can be attributed in part to IRS’s inconsistent implementation of elements of its agency-wide information security program. The agency established a comprehensive framework for its program, including assessing risk for its systems, developing system security plans, and providing employees with security awareness and specialized training. However, IRS had not updated key mainframe policies and procedures to address issues such as comprehensively auditing and monitoring access. In addition, the agency had not fully addressed previously identified deficiencies or ensured that its corrective actions were effective. During our most recent review, IRS told us it had addressed 28 of our prior recommendations; however, we determined that 9 of these had not been effectively implemented. The collective effect of the deficiencies in information security from prior years that continued to exist in fiscal year 2015, along with the new deficiencies we identified, are serious enough to merit the attention of those charged with governance of IRS and therefore represented a significant deficiency in IRS’s internal control over financial reporting systems as of September 30, 2015. To assist IRS in fully implementing its agency-wide information security program, we made two new recommendations to more effectively implement security-related policies and plans. In addition, to assist IRS in strengthening security controls over the financial and tax processing systems we reviewed, we made 43 technical recommendations in a separate report with limited distribution to address 26 new weaknesses in access controls and configuration management. Implementing these recommendations—in addition to the 49 outstanding recommendations from previous audits—will help IRS improve its controls for identifying and authenticating users, limiting users’ access to the minimum necessary to perform their job-related functions, protecting sensitive data when they are stored or in transit, auditing and monitoring system activities, and physically securing its IT facilities and resources. Table 1 below provides the number of our prior recommendations to IRS that were not implemented at the beginning of our fiscal year 2015 audit, how many were resolved by the end of the audit, new recommendations, and the total number of outstanding recommendations at the conclusion of the audit. In commenting on drafts of our reports presenting the results of our fiscal year 2015 audit, the IRS Commissioner stated that while the agency agreed with our new recommendations, it will review them to ensure that its actions include sustainable fixes that implement appropriate security controls balanced against IT and human capital resource limitations. In addition, IRS can take steps to improve its response to data breaches. Specifically, in December 2013 we reported on the extent to which data breach policies at eight agencies, including IRS, adhered to requirements and guidance set forth by the Office of Management and Budget and the National Institute of Standards and Technology. While the agencies in our review generally had policies and procedures in place that reflected the major elements of an effective data breach response program, implementation of these policies and procedures was not consistent. With respect to IRS, we determined that its policies and procedures generally reflected key practices, although the agency did not require considering the number of affected individuals as a factor when determining if affected individuals should be notified of a suspected breach. In addition, IRS did not document lessons learned from periodic analyses of its breach response efforts. We recommended that IRS correct these weaknesses, but the agency has yet to fully address them. The importance of protecting taxpayer information is further highlighted by the billions of dollars that have been lost to IDT refund fraud, which continues to be an evolving threat. IRS develops estimates of the extent of IDT refund fraud to help direct its efforts to identify and prevent the crime. While its estimates have inherent uncertainty, IRS estimated that it prevented or recovered $22.5 billion in fraudulent IDT refunds in filing season 2014 (see figure 1). However, IRS also estimated, where data were available, that it paid $3.1 billion in fraudulent IDT refunds. Because of the difficulties in knowing the amount of undetectable fraud, the actual amount could differ from these estimates. IRS has taken steps to address IDT refund fraud; however, it remains a persistent and continually changing threat. IRS recognized the challenge of IDT refund fraud in its fiscal year 2014-2017 strategic plan and increased resources dedicated to combating IDT and other types of refund fraud. In fiscal year 2015, IRS reported that it staffed more than 4,000 full-time equivalents and spent about $470 million on all refund fraud and IDT activities. As described above, IRS received an additional $290 million for fiscal year 2016 to improve customer service, IDT identification and prevention, and cybersecurity efforts and the agency plans to use $16.1 million of this funding to help prevent IDT refund fraud, among other things. The administration requested an additional $90 million and an additional 491 full-time equivalents for fiscal year 2017 to help prevent IDT refund fraud and reduce other improper payments. IRS estimates that this $90 million investment in IDT refund fraud and other improper payment prevention would help it protect $612 million in revenue in fiscal year 2017, as well as protect revenue in future years. IRS has taken action to improve customer service related to IDT refund fraud. For example, between the 2011 and 2015 filing seasons, IRS experienced a 430 percent increase in the number of telephone calls to its Identity Theft Toll Free Line—as of March 19, 2016, IRS had received over 1.1 million calls to this line. Moreover, 77 percent of callers seeking assistance on this telephone line received it compared to 54 percent during the same period last year. Average wait times during the same period have also decreased—taxpayers are waiting an average of 14 minutes to talk to an assistor, a decrease from 27 minutes last year. IRS also works with third parties, such as tax preparation industry participants, states, and financial institutions to try to detect and prevent IDT refund fraud. In March 2015, the IRS Commissioner convened a Security Summit with industry and states to improve information sharing and authentication. IRS officials said that 40 state departments of revenue and 20 tax industry participants have officially signed a partnership agreement to enact recommendations developed and agreed to by summit participants. IRS plans to invest a portion of the $16.1 million it received in fiscal year 2016 into identity theft prevention and refund fraud mitigation actions from the Security Summit. These efforts include developing an Information Sharing and Analysis Center where IRS, states, and industry can share information to combat IDT refund fraud. Even though IRS has prioritized combating IDT refund fraud, fraudsters adapt their schemes to identify weaknesses in IDT defenses, such as gaining access to taxpayers’ tax return transcripts through IRS’s online Get Transcript service. According to IRS officials, with access to tax transcripts, fraudsters can create historically consistent returns that are hard to distinguish from a return filed by a legitimate taxpayer, potentially making it more difficult for IRS to identify and detect IDT refund fraud. Without additional action by IRS and Congress, the risk of issuing fraudulent IDT refunds could grow. We previously made recommendations to IRS to help it better combat IDT refund fraud: Authentication. In January 2015, we reported that IRS’s authentication tools have limitations and recommended that IRS assess the costs, benefits and risks of its authentication tools. For example, individuals can obtain an e-file PIN by providing their name, Social Security number, date of birth, address, and filing status for IRS’s e-file PIN application. Identity thieves can easily find this information, allowing them to bypass some, if not all, of IRS’s automatic checks, according to our analysis and interviews with tax software and return preparer associations and companies. After filing an IDT return using an e-file PIN, the fraudulent return would proceed through IRS’s normal return processing. In November 2015, IRS officials told us that the agency had developed guidance for its Identity Assurance Office to assess costs, benefits, and risk, and that its analysis will inform decision-making on authentication-related issues. IRS also noted that the methods of analysis for the authentication tools will vary depending on the different costs and other factors for authenticating taxpayers in different channels, such as online, phone, or in-person. In February 2016, IRS officials told us that the Identity Assurance Office plans to complete a strategic plan for taxpayer authentication across the agency in September 2016. While IRS is taking steps, it will still be vulnerable until it completes and uses the results of its analysis of costs, benefits, and risk to inform decision-making. Form W-2, Wage and Tax Statement (W-2) Pre-refund Matching. In August 2014 we reported that the wage information that employers report on Form W-2 is not available to IRS until after it issues most refunds, and that if IRS had access to W-2 data earlier, it could match such information to taxpayers’ returns and identify discrepancies before issuing billions of dollars of fraudulent IDT refunds. We recommended that IRS assess the costs and benefits of accelerating W-2 deadlines. In response to our recommendation, IRS provided us with a report in September 2015 discussing (1) adjustments to IRS systems and work processes needed to use accelerated W-2 information, (2) the potential impacts on internal and external stakeholders, and (3) other changes needed to match W-2 data to tax returns prior to issuing refunds, such as delaying refunds until W-2 data are available. In December 2015, the Consolidated Appropriations Act of 2016 amended the tax code to accelerate W-2 filing deadlines to January 31. IRS’s report will help IRS determine how to best implement pre- refund W-2 matching, given the new January 31st deadline for filing W-2s. Additionally, we suggested that Congress should consider providing the Secretary of the Treasury with the regulatory authority to lower the threshold for electronic filing of W-2s, which could make more W-2 information available to IRS earlier. External Leads. IRS partners with financial institutions and other external parties to obtain information about emerging IDT refund trends and fraudulent returns that have passed through IRS detection systems. In August 2014, we reported that IRS provides limited feedback to external parties on IDT external leads they submit and offers external parties limited general information on IDT refund fraud trends and recommended that IRS provide actionable feedback to all lead generating third parties. In November 2015, IRS reported that it had developed a database to track leads submitted by financial institutions and the results of those leads. IRS also stated that it had held two sessions with financial institutions to provide feedback on external leads provided to IRS. In December 2015, IRS officials stated that the agency sent a customer satisfaction survey asking financial institutions for feedback on the external leads process and was considering other ways to provide feedback to financial institutions. In April 2016, IRS officials stated they plan to analyze preliminary survey results by mid-April 2016. Additionally, IRS officials reported that the agency shared information with financial institutions in March 2016 and plans to do so on a quarterly basis, with the next information sharing session scheduled in June 2016. IRS and industry partners have characterized that returns processing and refund issuance during this filing season has been generally smooth. Through April 1, 2016, IRS had processed about 95 million returns and issued 76 million refunds totaling about $215 billion. While IRS experienced a major system failure in February that halted returns processing for about a day, the agency reported that it had minimal effect on overall processing of returns and refunds. In addition to filing returns, many taxpayers often call IRS for assistance. IRS’s telephone service has generally improved in 2016 over last year. From January 1 through March 19, 2016 IRS received about 35.4 million calls to its automated and live assistor telephone lines, about a 2 percent decrease compared to the same period last year. Of the 13.4 million calls seeking live assistance, IRS had answered 9.1 million calls—a 75 percent increase over the 5.2 million calls answered during the same period last year. IRS anticipated that 65 percent of callers seeking live assistance would receive it this filing season, which runs through April 18, and 47 percent of callers would receive live assistance through the entire 2016 fiscal year. As of March 19, 2016, 75 percent of callers had received live assistance, an increase from 38 percent during the same period last year. Further, the average wait time to speak to an assistor also decreased from 24 to 9 minutes. As we reported in March 2016, however, IRS’s telephone level of service for the full fiscal year has yet to reach the levels it had achieved in earlier years. IRS attributed this year’s service improvement to a number of factors. Of the additional $290 million IRS received in December 2015, it allocated $178.4 million (61.5 percent) for taxpayer services to make measurable improvements in its telephone level of service. With the funds, IRS hired 1,000 assistors who began answering taxpayer calls in March, in addition to the approximately 2,000 seasonal assistors it had hired in fall 2015. To help answer taxpayer calls before March, IRS officials told us that they detailed 275 staff from one of its compliance functions to answer telephone calls. IRS officials said they believe this step was necessary because the additional funding came too late in the year to hire and train assistors to fully cover the filing season. IRS also plans to use about 600 full-time equivalents of overtime for assistors to answer telephone calls and respond to correspondence in fiscal year 2016, compared to fewer than 60 full-time equivalents of overtime used in fiscal year 2015. In December 2014, we recommended that IRS systematically and periodically compare its telephone service to the best in business to identify gaps between actual and desired performance. IRS disagreed with this recommendation, noting that it is difficult to identify comparable organizations. We do not agree with IRS’s position; many organizations run call centers that would provide ample opportunities to benchmark IRS’s performance. In fall 2015, Department of the Treasury (Treasury) and IRS officials said they had no plans to develop a comprehensive customer service strategy or specific goals for telephone service tied to the best in the business and customer expectations. Without such a strategy, Treasury and IRS can neither measure nor effectively communicate to Congress the types and levels of customer service taxpayers should expect and the resources needed to reach those levels. Therefore, in December 2015 we suggested that Congress consider requiring that Treasury work with IRS to develop a comprehensive customer service strategy. In April 2016, IRS officials told us that the agency established a team to consider our prior work in developing this strategy or benchmarking its telephone service. In summary, while IRS has made progress in implementing information security controls, it needs to continue to address weaknesses in access controls and configuration management and consistently implement all elements of its information security program. The risks IRS and the public are exposed to have been illustrated by recent incidents involving public- facing applications, highlighting the importance of securing systems that contain sensitive taxpayer and financial data. In addition, fully implementing key elements of a breach response program will help ensure that when breaches of sensitive data do occur, their impact on affected individuals will be minimized. Weaknesses in information security can also increase the risk posed by identity theft refund fraud. IRS needs to establish an approach for addressing identity theft refund fraud that is informed by assessing the cost, benefits, and risks of IRS’s various authentication options and improving the reliability of fraud estimates. While this year’s tax filing season has generally gone smoothly and IRS has improved customer service, it still needs to develop a comprehensive approach to customer service that will meet the needs of taxpayers while ensuring that their sensitive information is adequately protected. Chairman Hatch, Ranking Member Wyden, and Members of the Committee, this concludes my statement. I look forward to answering any questions that you may have at this time. If you have any questions regarding this statement, please contact Gregory C. Wilshusen at<PHONE_NUMBER> or<EMAIL_ADDRESS>Nancy Kingsbury at<PHONE_NUMBER> or<EMAIL_ADDRESS>or James R. McTigue, Jr. at<PHONE_NUMBER> or<EMAIL_ADDRESS>or Jessica K. Lucas-Judy at<PHONE_NUMBER> or<EMAIL_ADDRESS>Other key contributors to this statement include Jeffrey Knott, Neil A. Pinney, and Joanna M. Stamatiades (assistant directors); Dawn E. Bidne; Mark Canter; James Cook; Shannon J. Finnegan; Lee McCracken; Justin Palk; J. Daniel Paulk; Erin Saunders Rath; and Daniel Swartz. This is a work of the U.S. government and is not subject to copyright protection in the United States. The published product may be reproduced and distributed in its entirety without further permission from GAO. However, because this work may contain copyrighted images or other material, permission from the copyright holder may be necessary if you wish to reproduce this material separately."

Summary:
IRS has made progress in implementing information security controls, but it needs to continue to address weaknesses in access controls and configuration management and consistently implement all elements of its information security program.

IRS and the public are exposed to risks associated with identity theft refund fraud. IRS needs to establish an approach for addressing identity theft refund fraud that is informed by assessing the cost, benefits, and risks of IRS’s various authentication options and improving the reliability of fraud estimates.

IRS needs to develop a comprehensive customer service strategy that meets the needs of taxpayers while ensuring that their sensitive information is adequately protected.

Supervised learning (SL) is a machine learning paradigm for problems where the available data consists of labeled examples, meaning that each data point contains features (covariates) and an associated label. The goal of supervised learning algorithms is learning a function that maps feature vectors (inputs) to labels (output), based on example input-output pairs.[1] It infers a function from labeled training data consisting of a set of training examples.[2] In supervised learning, each example is a pair consisting of an input object (typically a vector) and a desired output value (also called the supervisory signal). A supervised learning algorithm analyzes the training data and produces an inferred function, which can be used for mapping new examples. An optimal scenario will allow for the algorithm to correctly determine the class labels for unseen instances. This requires the learning algorithm to generalize from the training data to unseen situations in a "reasonable" way (see inductive bias). This statistical quality of an algorithm is measured through the so-called generalization error.
Steps to follow
To solve a given problem of supervised learning, one has to perform the following steps:
Determine the type of training examples. Before doing anything else, the user should decide what kind of data is to be used as a training set. In the case of handwriting analysis, for example, this might be a single handwritten character, an entire handwritten word, an entire sentence of handwriting or perhaps a full paragraph of handwriting.
Gather a training set. The training set needs to be representative of the real-world use of the function. Thus, a set of input objects is gathered and corresponding outputs are also gathered, either from human experts or from measurements.
Determine the input feature representation of the learned function. The accuracy of the learned function depends strongly on how the input object is represented. Typically, the input object is transformed into a feature vector, which contains a number of features that are descriptive of the object. The number of features should not be too large, because of the curse of dimensionality; but should contain enough information to accurately predict the output.
Determine the structure of the learned function and corresponding learning algorithm. For example, the engineer may choose to use support-vector machines or decision trees.
Complete the design. Run the learning algorithm on the gathered training set. Some supervised learning algorithms require the user to determine certain control parameters. These parameters may be adjusted by optimizing performance on a subset (called a validation set) of the training set, or via cross-validation.
Evaluate the accuracy of the learned function. After parameter adjustment and learning, the performance of the resulting function should be measured on a test set that is separate from the training set.
Algorithm choice
A wide range of supervised learning algorithms are available, each with its strengths and weaknesses. There is no single learning algorithm that works best on all supervised learning problems (see the No free lunch theorem).
There are four major issues to consider in supervised learning:
Bias-variance tradeoff
Main article: Bias-variance dilemma
A first issue is the tradeoff between bias and variance.[3] Imagine that we have available several different, but equally good, training data sets. A learning algorithm is biased for a particular input
�
x if, when trained on each of these data sets, it is systematically incorrect when predicting the correct output for
�
x. A learning algorithm has high variance for a particular input
�
x if it predicts different output values when trained on different training sets. The prediction error of a learned classifier is related to the sum of the bias and the variance of the learning algorithm.[4] Generally, there is a tradeoff between bias and variance. A learning algorithm with low bias must be "flexible" so that it can fit the data well. But if the learning algorithm is too flexible, it will fit each training data set differently, and hence have high variance. A key aspect of many supervised learning methods is that they are able to adjust this tradeoff between bias and variance (either automatically or by providing a bias/variance parameter that the user can adjust).
Function complexity and amount of training data
The second issue is of the amount of training data available relative to the complexity of the "true" function (classifier or regression function). If the true function is simple, then an "inflexible" learning algorithm with high bias and low variance will be able to learn it from a small amount of data. But if the true function is highly complex (e.g., because it involves complex interactions among many different input features and behaves differently in different parts of the input space), then the function will only be able to learn with a large amount of training data paired with a "flexible" learning algorithm with low bias and high variance.
Dimensionality of the input space
A third issue is the dimensionality of the input space. If the input feature vectors have large dimensions, learning the function can be difficult even if the true function only depends on a small number of those features. This is because the many "extra" dimensions can confuse the learning algorithm and cause it to have high variance. Hence, input data of large dimensions typically requires tuning the classifier to have low variance and high bias. In practice, if the engineer can manually remove irrelevant features from the input data, it will likely improve the accuracy of the learned function. In addition, there are many algorithms for feature selection that seek to identify the relevant features and discard the irrelevant ones. This is an instance of the more general strategy of dimensionality reduction, which seeks to map the input data into a lower-dimensional space prior to running the supervised learning algorithm.
Noise in the output values
A fourth issue is the degree of noise in the desired output values (the supervisory target variables). If the desired output values are often incorrect (because of human error or sensor errors), then the learning algorithm should not attempt to find a function that exactly matches the training examples. Attempting to fit the data too carefully leads to overfitting. You can overfit even when there are no measurement errors (stochastic noise) if the function you are trying to learn is too complex for your learning model. In such a situation, the part of the target function that cannot be modeled "corrupts" your training data - this phenomenon has been called deterministic noise. When either type of noise is present, it is better to go with a higher bias, lower variance estimator.
In practice, there are several approaches to alleviate noise in the output values such as early stopping to prevent overfitting as well as detecting and removing the noisy training examples prior to training the supervised learning algorithm. There are several algorithms that identify noisy training examples and removing the suspected noisy training examples prior to training has decreased generalization error with statistical significance.[5][6]

Eval: https://github.com/openai/openai-cookbook/blob/main/examples/evaluation/How_to_eval_abstractive_summarization.ipynb
How_to_eval_abstractive_summarization.ipynb.zip


Sierra county, California

Part of "finish California" sprint.

Via (src):

http://www.sierracounty.ca.gov/index.aspx?nid=249
<EMAIL_ADDRESS>
Acquiring SHAPE Files & Parcel Boundaries SHAPE files and parcel boundaries are available for purchase from the Sierra County Information Systems Department for $50. For information about purchasing the data, please contact the Assessor's Office via Email or by calling<PHONE_NUMBER>.

I've emailed them.

Emailed them again.

Heard back from Laura and paid via credit card using this confusing form (entering in a official fake APN number, of all things!). The fee wasn't too bad, $52 total purchase price.
Thank you for your email. Sierra does offer assessor parcel number and parcel
boundary shapefiles for sale for $50.00. You can choose to pay via website, however,
please note there is a fairly steep user fee. You can forward a payment via USPS mail
by sending to:

Sierra County MIS
P.O. Box 8
Downieville, CA 95936

We provide the shapefiles via CD sent through the mail, unless you have an .ftp site you prefer we upload to.

If you have additional questions, please contact me at your convenience.

Thank you,

Laura Marshall
Sierra County Assessor
Information Systems Manager
Solid Waste Fee Administrator
(530) 289-3283
<EMAIL_ADDRESS>

Received their DVD, but the parcel polygons only have APN identifiers.
I've emailed them back asking for a join table or a different version with the addresses.

https://s3.amazonaws.com/data.openaddresses.io/cache/uploads/nvkelso/515881/sierra_co_california_parcels.zip

Sounds like the assessor can query a report into Excel to include APN and Situs together and forward :)

Have you head back yet about an updated report?

Yep, thanks for the bump. Very simple XLS that I've converted to CSV for you:

https://s3.amazonaws.com/data.openaddresses.io/cache/uploads/nvkelso/2e0fef/Sierra-Calif-Situs-for-Kelso-Dec-2016.csv

Hi Nathaniel,

Sorry about the delay in getting this data to you. Attached is the information you noted you would
like to have in an Excel format. The planning department is the department responsible for situs
addresses—they merely exist on my file. On parcels where there are multiple situs addresses we
have entered them into the ‘community’ field in our records. Very few files will actually have the
‘city’ or ‘community’ noted. If you have questions regarding a situs address you will want to contact
the Planning Department at<PHONE_NUMBER>.

If you have any questions regarding the attached report, please contact me at your convenience.

Thank you,

Laura Marshall
Sierra County Assessor
Information Systems Manager
Solid Waste Fee Administrator
(530) 289-3283
<EMAIL_ADDRESS>


Camera Paramter

Hi, thanks for sharing this great job. I want to align the viewpoint of SMPL with the original image, so how can I find the correct camera parameter of SMPL? Or can we use other methods to align them?

Thanks. Current visualization code does not support this but you may considering aligning the model with the estimation from  the kinematics approaches.

Close as being inactive, feel free to open again.


Update documentation around checking in the Gemfile.lock

When Bundler first shipped, we gitignored the Gemfile.lock inside gems, following the advice given in this blog post.
Over time, however, it became clear that this practice forces the pain of broken dependencies onto new contributors, while leaving existing contributors potentially unaware of the problem. As a result, we have revised our guidance for gem authors to now recommend checking in the lock for gems. We have also removed Gemfile.lock from the gitignore file generated in new gems.
This is a tracking ticket for any further documentation changes needed to support gem developers in this new pattern of checking in Gemfile.lock to support new contributors, while continuing to run at least one CI build against the newest version of all dependencies, resolved from scratch at the time of the CI run.

I'd be happy to help out with documentation changes reflecting the new recommendation to check in the lock for gems.

This looks like it's been completed. Closing.

@colby-swandale I think this part has not yet been addressed:

while continuing to run at least one CI build against the newest version of all dependencies, resolved from scratch at the time of the CI run.

@mvz You're right, thanks for pointing that out.

@indirect @colby-swandale I'm happy to take this one on. I need help clarifying this, though: where do we want this:

while continuing to run at least one CI build against the newest version of all dependencies, resolved from scratch at the time of the CI run.

to be called out? In the bundle-install.ronn man page?

Maybe in https://bundler.io/v1.16/guides/creating_gem.html ?

@segiddins possibly. It's a how-to guide, though, and doesn't already make mention of CI. Here are the high-level sections:

Getting Started
Testing our gem
Using other gems
Testing a CLI
Crafting a CLI
Testing a generator
Writing a generator
Releasing the gem

At which point in that outline would it make most sense to call out CI builds? cc @indirect

Probably within testing our gem?

When Bundler first shipped, we gitignored the Gemfile.lock inside gems.  [...] Over time, it became clear that this practice forces the pain of broken dependencies onto new contributors, while leaving existing contributors potentially unaware of the problem

This block of text is very difficult for me to understand.  What is meant by "the pain of broken dependencies"?  What are the "contributors" contributing to, an app or a library (gem)?  And does "new contributors" mean "people who contribute new gems" or "people who make contributions to existing gems" (i.e. are we talking about 2 sets of developers and 1 gem or 2 sets of developers and 2 gems, or 2 sets of developers and an app and a gem, etc)?
One way I can interpret this is as follows:

When Bundler first shipped, we gitignored the Gemfile.lock inside gems.  In theory, as a very popular article in a blog suggests, this allows people to use your library with versions of its dependencies that are different from the ones you used to develop the gem.
In practice, however, it became clear that not all versions of dependencies can work with a given gem.  The dependencies worked when the code was initially contributed, so the original contributors may be unaware when they break.  Instead, new contributors will experience the broken dependencies -- and be least certain of how best to fix them.

Is that accurate?
The reason for my question is that I work in a DevOps role and am trying to work out what the best practices are for private gems within our organization -- there are no "new" or "existing" contributors, because we're all on the same team.  And if I want any builds suffering from broken dependencies to fail as early and as loudly as possible, am I better off with or without Gemfile.lock checked into version control?  What are the biggest risks of each option?

As I understand it, the tension is between:

Not having a broken build just because a new version of a dependency is released.
Learning about a new version of a dependency not working with your gem.

If you find 2. more important you should not check in your Gemfile.lock. For public gems, it makes sense to find 1. more important.
Ideally, you would have both: One build with a known good lockfile, and one with the most recent versions of the dependencies.

That’s a great summary. A checked in lock file is important so that new contributors and fresh checkouts of the repo aren’t broken. A build without a lock file is important to ensure that gem install is not broken. Ideally you’ll have both. 👍🏻

OK.  So the tradeoff is that by checking in Gemfile.lock, you ensure that fresh checkouts of the repo will always work -- by constricting the process of resolving dependencies.
On a practical level, this means that checking in Gemfile.lock requires you (the gem maintainer) to be proactive about testing the latest versions of your dependencies for compatibility.
I'd like to submit a paragraph of text that captures all these subtleties to replace what's currently listed at https://bundler.io/v2.0/guides/faq.html#committing-lockfiles-in-libraries
Where can I find that code for that page?  And/or is there any process I need to worry about besides opening a pull request in that repo?

Note that proactively testing against newest versions of dependencies is very easy nowadays with dependabot. You can even configure it to create PRs in realtime after new releases of your dependencies!

That's an interesting point but I want to stress that the thrust of my inquiry is how to evaluate what the best practices are (or should be) in a setting where the gems are private and/or the team is primarily static (i.e. no "new contributors").
I'm considering a few scenarios -- like I could check in the Gemfile.lock but delete it during certain CI or CD operations.  Is there any interaction between having / not having a Gemfile.lock file and using / not using the --deployment flag with bundle install?

@ianfixes the best practices are the same. check in the Gemfile.lock so new contributors who get a new computer will have a working environment, and either keep a CI build that removes the lockfile or add Dependabot to your repo so you get PRs for every new version of your dependencies.

I've attempted to faithfully summarize everyone's comments and incorprate them into the exsiting documentation: https://github.com/bundler/bundler-site/pull/487


Fail on unsuitable resolutions

I'm currently setting up a CI server. Part of the build consists of installing all bower packages with bower install --config.interactive=false.
Unfortunately, this causes bower to ignore unsuitable resolutions - it only prints bower resolution            Unsuitable resolution declared for [...] to the console, where this message will never be found.
Instead, I'd like to set a flag that bower should abort (causing the build to fail) when the resolution can not be applied.

Duplicate of #1362