av9ash/GitBugs huggingface dataset:
Bug: Archive Spark Documentations in Apache Archives
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 12/Aug/24 08:59
Affects Version/s: 4.0.0


To address the issue of the Spark website repository size 
reaching the storage limit for GitHub-hosted runners [1], I suggest 
enhancing step [2] in our release process by relocating the 
documentation releases from the dev[3] directory to the release 
directory[4]. Then it would captured by the Apache Archives 
service[5] to create permanent links, which would be alternative 
endpoints for our documentation, like

https://dist.apache.org/repos/dist/dev/spark/v3.5.2-rc5-docs/_site/index.html 
for 
https://spark.apache.org/docs/3.5.2/index.html

Note that the previous example still uses the staging repository, 
which will become
https://archive.apache.org/dist/spark/docs/3.5.2/index.html.

For older releases hosted on the Spark website [6], we also need to
upload them via SVN manually.

After that, when we reach the threshold again, we can delete some of 
the old ones on page [6], and update their links on page [7] or use
redirection.

[1] https://lists.apache.org/thread/o0w4gqoks23xztdmjjj26jkp1yyg2bvq
[2] https://spark.apache.org/release-process.html#upload-to-apache-release-directory
[3] https://dist.apache.org/repos/dist/dev/spark/v3.5.2-rc5-docs/
[4] https://dist.apache.org/repos/dist/release/spark/docs/3.5.2
[5] https://archive.apache.org/dist/spark/
[6] https://github.com/apache/spark-website/tree/asf-site/site/docs
[7] https://spark.apache.org/documentation.html
Bug: Shutdown timeout thread while cleaning up SparkExecuteStatementOperation
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 21/Aug/24 08:57
Affects Version/s: 3.5.0


{noformat}
/apache/java17/bin/jmap  -histo 398 | grep SparkExecuteStatementOperation

 308:          4127        1122544  org.apache.spark.sql.hive.thriftserver.SparkExecuteStatementOperation
 563:          4127         363176  org.apache.spark.sql.hive.thriftserver.SparkExecuteStatementOperation$ErrRowCountType$
 876:          4127         132064  org.apache.spark.sql.hive.thriftserver.SparkExecuteStatementOperation$$anon$1
2101:           333           7992  org.apache.spark.sql.hive.thriftserver.SparkExecuteStatementOperation$$anon$5
3106:            32           1024  org.apache.spark.sql.hive.thriftserver.SparkExecuteStatementOperation$$anon$2
3303:            32            768  org.apache.spark.sql.hive.thriftserver.SparkExecuteStatementOperation$$Lambda$3755/0x00000008021fe800
3304:            32            768  org.apache.spark.sql.hive.thriftserver.SparkExecuteStatementOperation$$anon$2$$anon$3
3961:             9            360  org.apache.spark.sql.hive.thriftserver.SparkExecuteStatementOperation$$Lambda$5398/0x0000000802523900
3962:             9            360  org.apache.spark.sql.hive.thriftserver.SparkExecuteStatementOperation$$Lambda$5399/0x0000000802523bd8
20239:             1             16  org.apache.spark.sql.hive.thriftserver.SparkExecuteStatementOperation$
20240:             1             16  org.apache.spark.sql.hive.thriftserver.SparkExecuteStatementOperation$$$Lambda$5397/0x000000080251e180
20241:             1             16  org.apache.spark.sql.hive.thriftserver.SparkExecuteStatementOperation$$Lambda$11228/0x000000080306ba38
20242:             1             16  org.apache.spark.sql.hive.thriftserver.SparkExecuteStatementOperation$$Lambda$11230/0x00000008032962d8
20243:             1             16  org.apache.spark.sql.hive.thriftserver.SparkExecuteStatementOperation$$Lambda$11231/0x00000008032966b8
20244:             1             16  org.apache.spark.sql.hive.thriftserver.SparkExecuteStatementOperation$$Lambda$5363/0x0000000802509470
20245:             1             16  org.apache.spark.sql.hive.thriftserver.SparkExecuteStatementOperation$$Lambda$5367/0x000000080250a618
20246:             1             16  org.apache.spark.sql.hive.thriftserver.SparkExecuteStatementOperation$$Lambda$6475/0x00000008026fda40
20247:             1             16  org.apache.spark.sql.hive.thriftserver.SparkExecuteStatementOperation$$Lambda$7355/0x00000008028aa180
20248:             1             16  org.apache.spark.sql.hive.thriftserver.SparkExecuteStatementOperation$$Lambda$7356/0x00000008028aa560
{noformat}
Bug: Preempt low priority LCA internal error until the end of check analysis
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 20/Aug/24 05:04
Affects Version/s: 4.0.0

For queries like

 
{code:java}
          
            |WITH group_counts AS (
            |  SELECT id, count(*) as Freq, CASE WHEN Freq <= 10 THEN "1" ELSE "2" END AS Group
            |  FROM values (123) as data(id)
            |  GROUP BY id
            |)
            |SELECT Group, count(*) * 100.0 / (select count(*) from group_counts) AS Percentage
            |FROM group_counts
            |Group BY Group
            |ORDER BY Freq DESC;
{code}
The root cause error should be the 'Order By Freq', instead of the LCA internal error. The LCA error should be preempted if there are other higher priority errors occur.
Bug: Fix Hadoop delegation token leak when tokenRenewalInterval is not set.
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 19/Aug/24 08:31
Affects Version/s: 3.4.3

If tokenRenewalInterval is not set, HadoopFSDelegationTokenProvider#getTokenRenewalInterval will fetch some tokens and renew them to get a interval value. These tokens do not call cancel(), resulting in a large number of existing tokens on HDFS not being cleared in a timely manner, causing additional pressure on the HDFS server.
Bug: Revise `InstanceConfig` to `ExecutorInstanceConfig` class
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 21/Aug/24 04:07
Affects Version/s: kubernetes-operator-0.1.0

- Rename `InstanceConfig` to `ExecutorInstanceConfig` because we will add `WorkerInstanceConfig`
- Fix malformed Java docs
- Fix `long` type to `int` for `(init|min|max)Executors`.
- Refactor `ApplicastionSpecTest`
Bug: Improve performance and memory footprint of all VALUES clauses
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 16/Aug/24 21:44
Affects Version/s: 3.4.4

This is a continuation of the following performance improvement:

https://issues.apache.org/jira/browse/SPARK-48967

 

By pushing the early evaluation of `UnresolvedUnlineTables` into `LocalRelation (whenever possible) in `visitInlineTable` of the AstBuilder we can get the benefits of the aforementioned ticket not only in `INSERT INTO ... VALUES` statements but in every statement that can contain the `VALUES()` clause.
Bug: Caching observed dataframes blocks metric retrieval when the dataframe is empty
Status: Open | Priority: Major | Resolution: 
Created: 13/Aug/24 04:54
Affects Version/s: 3.5.0

Caching observed dataframes blocks metric retrieval when the dataframe is empty. This issue started in PySpark 3.5.0 and can be reproduced by running the following script, which does not complete:
{code:java}
from pyspark.sql import SparkSession, Observation, functions as F
spark = SparkSession.builder.getOrCreate()

df = spark.createDataFrame([], "f: double")
observation = Observation("count")
observed_df = df.observe(observation, F.count(F.lit(1))) 

observed_df.cache().collect()
print(observation.get){code}
 

The issue can also be reproduced when reading a CSV with 0 records, or when using additional select statements on the observed dataframe. Removing `cache()` or downgrading to Spark 3.4.3 prints the expected result: `"\{'count(1)': 0}"`.
Bug: TransformWithState doesn't set implicit grouping key when lazy iterators are used
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 06/Aug/24 21:58
Affects Version/s: 4.0.0

When a lazy iterator is used, the implicit key for state updates in TWS is not set properly. This is because the implicit key is set as a thread local only when `handleInputRows` is called, not when methods on the returned iterator are invoked. Both eager and lazy iterators should be supported.
Bug: Implement pipe operator syntax in Spark SQL
Status: Open | Priority: Major | Resolution: 
Created: 19/Aug/24 17:55
Affects Version/s: 4.0.0

This is based on the following paper: [https://research.google/pubs/sql-has-problems-we-can-fix-them-pipe-syntax-in-sql/]

Open-source ZetaSQL reference: [https://github.com/google/zetasql/blob/master/docs/pipe-syntax.md]
Bug: Reduce `spark-operator` fat jar size by excluding dependencies
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 19/Aug/24 06:08
Affects Version/s: kubernetes-operator-0.1.0

This issue aims to reduce the operator fat jar size from `227M` to `148M`. It's 35% reduction.

**BEFORE**
{code}
$ ls -alh spark-operator/build/libs/spark-kubernetes-operator-0.1.0-all.jar
-rw-r--r--  1 dongjoon  staff   227M Aug 18 23:09 spark-operator/build/libs/spark-kubernetes-operator-0.1.0-all.jar
{code}

**AFTER**
{code}
$ ls -alh spark-operator/build/libs/spark-kubernetes-operator-0.1.0-all.jar
-rw-r--r--  1 dongjoon  staff   148M Aug 18 23:03 spark-operator/build/libs/spark-kubernetes-operator-0.1.0-all.jar
{code}
Bug: Improve `gradlew` to support both `curl` and `wget`
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 16/Aug/24 22:18
Affects Version/s: kubernetes-operator-0.1.0

`curl` doesn't exist in some docker images like the following.
{code}
$ docker run -it --rm -v $PWD:/spark alpine/java:21-jdk -- sh
/ # cd /spark/
/spark # ./gradlew
./gradlew: line 90: curl: not found
Error: Could not find or load main class org.gradle.wrapper.GradleWrapperMain
Caused by: java.lang.ClassNotFoundException: org.gradle.wrapper.GradleWrapperMain
/spark #
{code}
Bug: CheckAnalysis with UnresolvedWindowExpression nested inside other expressions produces confusing error message
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 15/Aug/24 15:57
Affects Version/s: 4.0.0

Consider the following query: `SELECT (SUM(col1) OVER(unspecified_window) / 1) FROM VALUES (1)`. Currently the resolution produces `org.apache.spark.sql.catalyst.analysis.UnresolvedException: [INTERNAL_ERROR] Invalid call to dataType on unresolved object SQLSTATE: XX000`, which is confusing. We need to change it to `ExtendedAnalysisException: [MISSING_WINDOW_SPECIFICATION]`
Bug: (Tentitavely) Investigate Mima bug when checking Dataset APIs
Status: Open | Priority: Major | Resolution: 
Created: 02/Aug/24 14:31
Affects Version/s: 4.0.0

Mima check might complain the following Dataset rules does not filter any problem.
This is due to a potential bug in Mima that all methods in `class Dataset` are not being
checked for problems due to the presence of a private[sql] companion object.
Further investigation is needed.
Bug: Support customized log url for Spark UI and History server in Kubernetes environment
Status: Open | Priority: Major | Resolution: 
Created: 07/Aug/24 23:13
Affects Version/s: 4.0.0

Spark provides two configs to alternate the log url on the live UI and history server, `{{{}spark.ui.custom.executor.log.url{}}}` and `{{{}spark.history.custom.executor.log.url{}}}`. The configs support path variables which will be replaced at runtime, but currently this only works on Yarn. Running on k8s with the path variable doesn't work. Here's an example
{code:java}
./bin/spark-shell --conf spark.ui.custom.executor.log.url="URL_PREFIX?appId=APP_ID&execId=EXECUTOR_ID"{code}
The log column doesn't show up in the Spark UI, and Spark driver printing
{code:java}
24/08/07 17:23:45 INFO ExecutorLogUrlHandler: Fail to renew executor log urls: some of required attributes are missing in app's event log.. Required: Set(APP_ID, EXECUTOR_ID) / available: Set(). Falling back to s how app's original log urls.{code}
 the empty attribute `{{{}Set(){}}}` in the above log segment indicates the feature not supported in k8s environment, thus creating this ticket to add the support
Bug: Support OFFSET in correlated subquery
Status: Open | Priority: Major | Resolution: 
Created: 08/Aug/24 18:06
Affects Version/s: 4.0.0

Subqueries with correlation with OFFSET are not supported due to a correctness bug introduced before(https://issues.apache.org/jira/browse/SPARK-46446 )

Offset operator are not allowed in all types of correlated subqueries: scalar, lateral, IN, EXISTS.

The ticket aims to add support for offset in DecorrelateInnerQuery (the transformation is into a filter on row_number window function, similar to limit).
Bug: sbt compilation warning: `Regular tasks always evaluate task dependencies (.value) regardless of if expressions`
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 13/Aug/24 09:37
Affects Version/s: 4.0.0

{code:java}
[warn] /Users/yangjie01/SourceCode/git/spark-sbt/project/SparkBuild.scala:1554:77: value lookup of `/` inside an `if` expression
[warn] 
[warn] problem: `/.value` is inside an `if` expression of a regular task.
[warn]   Regular tasks always evaluate task dependencies (`.value`) regardless of `if` expressions.
[warn] solution:
[warn]   1. Use a conditional task `Def.taskIf(...)` to evaluate it when the `if` predicate is true or false.
[warn]   2. Or turn the task body into a single `if` expression; the task is then auto-converted to a conditional task. 
[warn]   3. Or make the static evaluation explicit by declaring `/.value` outside the `if` expression.
[warn]   4. If you still want to force the static lookup, you may annotate the task lookup with `@sbtUnchecked`, e.g. `(/.value: @sbtUnchecked)`.
[warn]   5. Add `import sbt.dsl.LinterLevel.Ignore` to your build file to disable all task linting.
[warn]     
[warn]         val replClasspathes = (LocalProject("connect-client-jvm") / Compile / dependencyClasspath)
 {code}
Bug: Use UnboundRowEncoders for ScalaUDF/ScalaUDAF inputs 
Status: Open | Priority: Major | Resolution: 
Created: 13/Aug/24 23:50
Affects Version/s: 4.0.0

We could leverage UnboundRowEncoder for ScalaUDF/UDAF inputs. This would allow us to do better input validation, and we could speed up conversions using ExpressionEncoders.
Bug: Fix to not log message context with explicitly LogEntry constructed when Structured Logging conf is off
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 13/Aug/24 03:53
Affects Version/s: 4.0.0

To use structured logging developers usually do
{code:java}
logInfo(log"Lost executor ${MDC(LogKeys.EXECUTOR_ID, "1")}."), {code}

When the structured logging conf is off, the context is not logged.
However if explicitly constructing the LogEntry and calling the public API,
{code:java}
logInfo(
  MessageWithContext(
    "Lost executor 1.",
    new java.util.HashMap[String, String] { put(LogKeys.EXECUTOR_ID.name, "1") }
  )
) {code}
the conf does not take effect and even when it is off, the context is still logged.

The behavior should be fixed.
Bug: Fix SplitPart one-to-many case mapping (UTF8_LCASE)
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 12/Aug/24 07:44
Affects Version/s: 4.0.0

Fix the following string expressions to handle one-to-many case mapping properly:
 * SplitPart
 * StringSplitSQL

 

Examples of incorrect results (under {{UTF8_LCASE}} collation):
{code:java}
SplitPart("Ai\u0307B", "İ", 2) // returns: "\u0307B" (incorrect), instead of: "B" (correct)
SplitPart("AİB", "i\u0307", 1) // returns: "AİB", instead of: "A", "B" (correct){code}
 
{code:java}
StringSplitSQL("Ai\u0307B", "İ") // returns: ["A", "\u0307B"] (incorrect), instead of: ["A", "B"] (correct)
StringSplitSQL("AİB", "i\u0307") // returns: ["AİB"] (incorrect), instead of: ["A", "B"] (correct){code}
Bug: Fix v2 multi bucketed inner joins throw AssertionError
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 09/Aug/24 07:52
Affects Version/s: 3.3.4


{code:java}
[info]   Cause: java.lang.AssertionError: assertion failed
[info]   at scala.Predef$.assert(Predef.scala:264)
[info]   at org.apache.spark.sql.execution.exchange.EnsureRequirements.createKeyGroupedShuffleSpec(EnsureRequirements.scala:642)
[info]   at org.apache.spark.sql.execution.exchange.EnsureRequirements.$anonfun$checkKeyGroupCompatible$1(EnsureRequirements.scala:385)
[info]   at scala.collection.immutable.List.map(List.scala:247)
[info]   at scala.collection.immutable.List.map(List.scala:79)
[info]   at org.apache.spark.sql.execution.exchange.EnsureRequirements.checkKeyGroupCompatible(EnsureRequirements.scala:382)
[info]   at org.apache.spark.sql.execution.exchange.EnsureRequirements.checkKeyGroupCompatible(EnsureRequirements.scala:364)
[info]   at org.apache.spark.sql.execution.exchange.EnsureRequirements.org$apache$spark$sql$execution$exchange$EnsureRequirements$$ensureDistributionAndOrdering(EnsureRequirements.scala:166)
[info]   at org.apache.spark.sql.execution.exchange.EnsureRequirements$$anonfun$1.applyOrElse(EnsureRequirements.scala:714)
[info]   at org.apache.spark.sql.execution.exchange.EnsureRequirements$$anonfun$1.applyOrElse(EnsureRequirements.scala:689)
[info]   at org.apache.spark.sql.catalyst.trees.TreeNode.$anonfun$transformUpWithPruning$4(TreeNode.scala:528)
[info]   at org.apache.spark.sql.catalyst.trees.CurrentOrigin$.withOrigin(origin.scala:84)
[info]   at org.apache.spark.sql.catalyst.trees.TreeNode.transformUpWithPruning(TreeNode.scala:528)
[info]   at org.apache.spark.sql.catalyst.trees.TreeNode.transformUp(TreeNode.scala:497)
[info]   at org.apache.spark.sql.execution.exchange.EnsureRequirements.apply(EnsureRequirements.scala:689)
[info]   at org.apache.spark.sql.execution.exchange.EnsureRequirements.apply(EnsureRequirements.scala:51)
[info]   at org.apache.spark.sql.execution.adaptive.AdaptiveSparkPlanExec$.$anonfun$applyPhysicalRules$2(AdaptiveSparkPlanExec.scala:882)
[in
{code}
Bug: UI: add column for 'total time across all tasks'
Status: Open | Priority: Major | Resolution: 
Created: 13/Aug/24 07:19
Affects Version/s: 3.5.2

The tables showing overview of stages (both in general 'stages' tab, as well as in job overview) show duration in wall time, but not the 'total time across all tasks' for a stage.

For performance analysis, it would help a lot if we could sort by the total time across tasks. Especially as for complex applications, it happens regularly that stages with a long/short wall time are not necessarily having a similarly long/short total task time.
Bug: Fix not NullSafeEqual in predicate of SQL query in JDBC Relation
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 08/Aug/24 15:01
Affects Version/s: 4.0.0

There is a bug in the evaluation of <=> (NullEqualSafe) in V2ExpressionSQLBuilder.scala. If there was a predicate like
where not str <=> 'abc' and if there are null values in the table, null tables are not returned even though they should. The issue is in how <=> is translated to SQL string therefore producing wrong results.
Bug: Internal error on concat_ws called on array of arrays of string
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 09/Aug/24 16:16
Affects Version/s: 4.0.0

Applying the following sequence of queries in *ANSI mode* (spark.sql.ansi.enabled=true):
{code:java}
create table test_table(dat array<string>) using parquet;
select concat_ws(',', collect_list(dat)) FROM test_table; {code}
yields an internal error:
{code:java}
org.apache.spark.SparkException: [INTERNAL_ERROR] The Spark SQL phase analysis failed with an internal error. You hit a bug in Spark or the Spark plugins you use. Please, report this bug to the corresponding communities or vendors, and provide the full stack trace. SQLSTATE: XX000
...
Caused by: java.lang.NullPointerException: Cannot invoke "org.apache.spark.sql.types.AbstractDataType.simpleString()" because "<local3>" is null
  at org.apache.spark.sql.errors.DataTypeErrorsBase.toSQLType(DataTypeErrorsBase.scala:55)
  at org.apache.spark.sql.errors.DataTypeErrorsBase.toSQLType$(DataTypeErrorsBase.scala:51)
  at org.apache.spark.sql.catalyst.expressions.Cast$.toSQLType(Cast.scala:44)
  at org.apache.spark.sql.catalyst.expressions.Cast$.typeCheckFailureMessage(Cast.scala:426)
  at org.apache.spark.sql.catalyst.expressions.Cast.typeCheckFailureInCast(Cast.scala:501)
  at org.apache.spark.sql.catalyst.expressions.Cast.checkInputDataTypes(Cast.scala:525)
  at org.apache.spark.sql.catalyst.expressions.Cast.resolved$lzycompute(Cast.scala:551)
  at org.apache.spark.sql.catalyst.expressions.Cast.resolved(Cast.scala:550)
... {code}
Bug: Cannot grow BufferHolder by size 86352 because the size after growing exceeds size limitation 2147483632
Status: Open | Priority: Major | Resolution: 
Created: 03/Aug/24 00:42
Affects Version/s: 3.4.1

java.lang.IllegalArgumentException: 
Cannot grow BufferHolder by size 86352 because the size after growing exceeds 
size limitation 2147483632
Bug: pyspark auto batching serialization leads to job crash
Status: Open | Priority: Major | Resolution: 
Created: 09/Aug/24 17:46
Affects Version/s: 3.2.0

the auto batching mechanism of serialzation leads to job crash in pyspark 

 

the logic is increasing batch size when it can [https://github.com/apache/spark/blob/master/python/pyspark/serializers.py#L269-L285]

 

however, this logic is vulnerable to the situation that the total size of objects is larger than 2G and as a result , we are hit by the issue that

```
File "/databricks/spark/python/pyspark/worker.py", line 1876, in main process()

File "/databricks/spark/python/pyspark/worker.py", line 1868, in process serializer.dump_stream(out_iter, outfile)

File "/databricks/spark/python/pyspark/serializers.py", line 308, in dump_stream self.serializer.dump_stream(self._batched(iterator), stream)

File "/databricks/spark/python/pyspark/serializers.py", line 158, in dump_stream self._write_with_length(obj, stream)

File "/databricks/spark/python/pyspark/serializers.py", line 172, in _write_with_length raise ValueError("can not serialize object larger than 2G")

ValueError: can not serialize object larger than 2G
```
Bug: Attempt to create table based on broken parquet partition data results in internal error
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 08/Aug/24 11:49
Affects Version/s: 4.0.0

Create an example parquet table with partitions and insert data in Spark:
{code:java}
create table t(col1 string, col2 string, col3 string) using parquet location 'some/path/parquet-test' partitioned by (col1, col2);
insert into t (col1, col2, col3) values ('a', 'b', 'c');{code}
Go into the parquet-test path in the filesystem and try to copy parquet data file from path col1=a/col2=b directory into col1=a. After that, try to create new table based on parquet data in Spark:
{code:java}
create table broken_table using parquet location 'some/path/parquet-test'; {code}
This query errors with internal error. Stack trace excerpts:
{code:java}
org.apache.spark.SparkException: [INTERNAL_ERROR] Eagerly executed command failed. You hit a bug in Spark or the Spark plugins you use. Please, report this bug to the corresponding communities or vendors, and provide the full stack trace. SQLSTATE: XX000
...
Caused by: java.lang.AssertionError: assertion failed: Conflicting partition column names detected:        Partition column name list #0: col1
        Partition column name list #1: col1, col2For partitioned table directories, data files should only live in leaf directories.
And directories at the same level should have the same partition column name.
Please check the following directories for unexpected files or inconsistent partition column names:        file:some/path/parquet-test/col1=a
        file:some/path/parquet-test/col1=a/col2=b
  at scala.Predef$.assert(Predef.scala:279)
  at org.apache.spark.sql.execution.datasources.PartitioningUtils$.resolvePartitions(PartitioningUtils.scala:391)
...{code}
Bug: Add `OpenContainers` Annotations to docker image
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 08/Aug/24 22:08
Affects Version/s: kubernetes-operator-0.1.0

{code:java}
LABEL org.opencontainers.image.authors="Apache Spark project <dev@spark.apache.org>"
LABEL org.opencontainers.image.licenses="Apache-2.0"
LABEL org.opencontainers.image.ref.name="Apache Spark Kubernetes Operator"
LABEL org.opencontainers.image.version="${APP_VERSION}" {code}