av9ash/GitBugs huggingface dataset:
Bug: Push down Filter in case of filter having child as TypedFilter
Status: In Progress | Priority: Major | Resolution: 
Created: 06/Jul/21 15:03
Affects Version/s: 3.1.2

In case of Filter having child as TypedFilter, Pushdown of Filters does not take place

 
{code:java}
scala> def testUdfFunction(r: String): Boolean = {
 | r.equals("hello")
 | }
testUdfFunction: (r: String)Boolean

val df= spark.read.parquet("/testDir/testParquetSize/Parquetgzip/")
df: org.apache.spark.sql.DataFrame = [_1: string, _2: string ... 1 more field]
{code}
 

df.filter(x => testUdfFunction(x.getAs("_1"))).filter("_2<='id103855'").queryExecution.executedPlan

 
{code:java}
Filter (isnotnull(_2#1) AND (_2#1 <= id103855))
+- *(1) Filter $line20.$read$$iw$$iw$$iw$$iw$$iw$$iw$$iw$$iw$$Lambda$3184/1455948476@5ce4af92.apply
 +- *(1) ColumnarToRow
 +- FileScan parquet [_1#0,_2#1,_3#2] Batched: true, DataFilters: [], Format: Parquet, Location: InMemoryFileIndex[file:/testDir/testParquetSize/Parquetgzip], PartitionFilters: [], PushedFilters: [], ReadSchema: struct<_1:string,_2:string,_3:string>
 
{code}
df.filter(x => testUdfFunction(x.getAs("_1"))).filter("_2<='id103855'").queryExecution.optimizedPlan
{code:java}
Filter (isnotnull(_2#1) AND (_2#1 <= id103855))
+- TypedFilter $line22.$read$$iw$$iw$$iw$$iw$$iw$$iw$$iw$$iw$$Lambda$3191/320569017@37a2806c, interface org.apache.spark.sql.Row, [StructField(_1,StringType,true), StructField(_2,StringType,true), StructField(_3,StringType,true)], createexternalrow(_1#0.toString, _2#1.toString, _3#2.toString, StructField(_1,StringType,true), StructField(_2,StringType,true), StructField(_3,StringType,true))
 +- Relation[_1#0,_2#1,_3#2] parquet{code}
 

There is need to add this change to push down the filter for this scenario
Bug: Confusing error from casting a string to ANSI interval
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 05/Jul/21 20:01
Affects Version/s: 3.2.0

See the example:

{code:sql}
spark-sql> select interval '56:12' minute to second;
0 00:56:12.000000000
spark-sql> select cast('56:12' as interval minute to second);
21/07/05 22:58:03 ERROR SparkSQLDriver: Failed in [select cast('56:12' as interval minute to second)]
java.lang.IllegalArgumentException: Interval string does not match day-time format of `[+|-]h`, `INTERVAL [+|-]'[+|-]h' HOUR` when cast to interval minute to second: 56:12
	at org.apache.spark.sql.catalyst.util.IntervalUtils$.checkStringIntervalType$2(IntervalUtils.scala:287)
{code}
The error message from the second command confuses slightly. It mentions INTERVAL HOUR but how it relates to the input?
Bug: Make from_csv/to_csv to handle day-time intervals properly
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 02/Jul/21 19:42
Affects Version/s: 3.2.0

from_csv throws exception if day-time interval types are given.

{code}
spark-sql> select from_csv("interval '1 2:3:4' day to second", "a interval day to second");
21/07/03 04:39:13 ERROR SparkSQLDriver: Failed in [select from_csv("interval '1 2:3:4' day to second", "a interval day to second")]
java.lang.Exception: Unsupported type: interval day to second
 at org.apache.spark.sql.errors.QueryExecutionErrors$.unsupportedTypeError(QueryExecutionErrors.scala:775)
 at org.apache.spark.sql.catalyst.csv.UnivocityParser.makeConverter(UnivocityParser.scala:224)
 at org.apache.spark.sql.catalyst.csv.UnivocityParser.$anonfun$valueConverters$1(UnivocityParser.scala:134)
 {code}

Also, to_csv doesn't handle day-time interval types properly though any exception is thrown.
The result of to_csv for day-time interval types is not ANSI interval compliant form.

{code}
spark-sql> select to_csv(named_struct("a", interval '1 2:3:4' day to second));
93784000000
{code}

The result above should be INTERVAL '1 02:03:04' DAY TO SECOND.
Bug: Make from_csv/to_csv to handle year-month intervals properly
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 02/Jul/21 19:36
Affects Version/s: 3.2.0

from_csv throws exception if year-month interval types are given.
{code}
spark-sql> select from_csv("interval '1-2' year to month", "a interval year to month");
21/07/03 04:32:24 ERROR SparkSQLDriver: Failed in [select from_csv("interval '1-2' year to month", "a interval year to month")]
java.lang.Exception: Unsupported type: interval year to month
	at org.apache.spark.sql.errors.QueryExecutionErrors$.unsupportedTypeError(QueryExecutionErrors.scala:775)
	at org.apache.spark.sql.catalyst.csv.UnivocityParser.makeConverter(UnivocityParser.scala:224)
	at org.apache.spark.sql.catalyst.csv.UnivocityParser.$anonfun$valueConverters$1(UnivocityParser.scala:134)
{code}

Also, to_csv doesn't handle year-month interval types properly though any exception is thrown.
The result of to_csv for year-month interval types is not ANSI interval compliant form.

{code}
spark-sql> select to_csv(named_struct("a", interval '1-2' year to month));
14
{code}

The result above should be INTERVAL '1-2' YEAR TO MONTH.
Bug: The ANSI flags of Sum and Avg should be kept after being copied
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 02/Jul/21 09:00
Affects Version/s: 3.2.0

For Views and UDFs, it is important to show consistent results even the ANSI configuration is different in the running session. This is why many expressions like 'Add'/'Divide'/'CAST' making the ANSI flag part of its case class parameter list.
We should make it consistent for `Sum`/`Avg`
Bug: in spark3.1.2 version The canCast method of type of char/varchar needs to be consistent with StringType
Status: In Progress | Priority: Major | Resolution: 
Created: 03/Jul/21 03:41
Affects Version/s: 3.1.2

In https://github.com/apache/spark/pull/32109 this pr, we introduced the char/varchar type,

As described in this issue:

To be safe, this PR doesn't add char/varchar type to the query engine(expression input check, internal row framework, codegen framework, etc.). We will replace char/varchar type by string type with metadata (Attribute.metadata or StructField.metadata) that includes the original type string before it goes into the query engine. That said, the existing code will not see char/varchar type but only string type.


so The canCast method of type of char/varchar needs to be consistent with StringType
Bug: Make the pod prefix more readable and tallied with K8S DNS Label Names
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 01/Jul/21 08:36
Affects Version/s: 3.2.0

By default, the executor pod prefix is generated by the app name. It handles characters that match [^a-z0-9\\-] differently. The '.' and all whitespaces will be converted to '-', but other ones to empty string. Especially,  characters like '_', '|' are commonly used as a word separator in many languages.

According to the K8S DNS Label Names, see [https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#dns-label-names,] we can convert all special characters to `-`.

 
{code:scala}
scala> "time.is%the￥most$valuable_——————thing,it's about time.".replaceAll("[^a-z0-9\\-]", "-").replaceAll("-+", "-")
res9: String = time-is-the-most-valuable-thing-it-s-about-time-

scala> "time.is%the￥most$valuable_——————thing,it's about time.".replaceAll("\\s+", "-").replaceAll("\\.", "-").replaceAll("[^a-z0-9\\-]", "").replaceAll("-+", "-")
res10: String = time-isthemostvaluablethingits-about-time-

{code}
Bug: Allow predicate for pyspark.sql.functions.array_sort
Status: Open | Priority: Major | Resolution: 
Created: 01/Jul/21 08:43
Affects Version/s: 3.1.2

Currently, both the Python API and the Scala API for the SQL function `array_sort` do not take a predicate boolean function/lambda expression as a second argument. Hence, we have to resort to `expression` or `selectExpression` and use the DSL for the predicate function. It would be nice to allow this, just like all the higher-order functions.
Bug: Only use local shuffle reader when REBALANCE_PARTITIONS_BY_NONE without CustomShuffleReaderExec
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 01/Jul/21 03:18
Affects Version/s: 3.2.0

After [SPARK-35725](https://issues.apache.org/jira/browse/SPARK-35725), we might expand partition if that partition is skewed. So the partition number check `bytesByPartitionId.length == partitionSpecs.size` would be wrong if some partitions are coalesced and some partitions are splitted into smaller.
Note that, it's unlikely happened in real world since it used RoundRobin.

Otherhand, after [SPARK-34899](https://issues.apache.org/jira/browse/SPARK-34899), we use origin plan if can not coalesce partitions. So the assuming of that shuffle stage has `CustomShuffleReaderExec` with no effect is always false in `REBALANCE_PARTITIONS_BY_NONE` shuffle origin. That said, if no rule was efficient, there would be no `CustomShuffleReaderExec`.
Bug: Commit collision avoidance in dynamicPartitionOverwrite for non-Parquet formats
Status: Resolved | Priority: Minor | Resolution: Incomplete
Created: 16/Jul/21 22:31
Affects Version/s: 3.1.2

Hi, my question here is specifically about [PR #29000|https://github.com/apache/spark/pull/29000/files#r649580767] for SPARK-29302.

To my understanding, the PR is to introduce a different staging directory at job commit to avoid commit collision. In SQLHadoopMapReduceCommitProtocol, the new staging directory is only set when SQLConf.OUTPUT_COMMITTER_CLASS is not null: [code|https://github.com/apache/spark/blob/master/sql/core/src/main/scala/org/apache/spark/sql/execution/datasources/SQLHadoopMapReduceCommitProtocol.scala#L58], and in current Spark repo, OUTPUT_COMMITTER_CLASS seems set only for parquet formats: [code|https://github.com/apache/spark/blob/master/sql/core/src/main/scala/org/apache/spark/sql/execution/datasources/parquet/ParquetFileFormat.scala#L96].

However I didn't find similar behavior in Orc related code to set that config. If I understand it correctly, without setting SQLConf.OUTPUT_COMMITTER_CLASS properly (like for Orc format), SQLHadoopMapReduceCommitProtocol will still use the original staging directory, which may void the fix by the PR, in which case the commit collision may still happen, thus the fix is now only effective for Parquet, but not for non-Parquet files.

Could someone confirm if it is a potential problem, or not? Thanks!

[~duripeng] [~dagrawal3409]
Bug: Make 'spark.sql.sources.disabledJdbcConnProviderList' as a static conf (as documneted)
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 16/Jul/21 01:01
Affects Version/s: 3.3.0

{{spark.sql.sources.disabledJdbcConnProviderList}} is supposed to be a static config (it doesn't work runtime anyway) but it's currently placed as a runtime config
Bug: Upgrade SBT to 1.5.5
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 13/Jul/21 01:52
Affects Version/s: 3.3.0

SBT 1.5.5 was released, which includes 16 imrovements/bug fixes.
https://github.com/sbt/sbt/releases/tag/v1.5.5
Bug: YarnClusterSuite fails due to NoClassDefFoundError unless hadoop-3.2 profile is activated explicitly
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 09/Jul/21 04:33
Affects Version/s: 3.2.0

YarnClusterSuite will fails due to NoClassDefFoundError unless hadoop-3.2 profile is activated explicitly regardless of building with SBT or Maven.
{code:java}
build/sbt -Pyarn "yarn/testOnly org.apache.spark.deploy.yarn.YarnClusterSuite"
...
[info] YarnClusterSuite:
[info] org.apache.spark.deploy.yarn.YarnClusterSuite *** ABORTED *** (598 milliseconds)
[info]   java.lang.NoClassDefFoundError: org/bouncycastle/operator/OperatorCreationException
[info]   at org.apache.hadoop.yarn.server.resourcemanager.ResourceManager$RMActiveServices.serviceInit(ResourceManager.java:888)
[info]   at org.apache.hadoop.service.AbstractService.init(AbstractService.java:164)
[info]   at org.apache.hadoop.yarn.server.resourcemanager.ResourceManager.createAndInitActiveServices(ResourceManager.java:1410)
[info]   at org.apache.hadoop.yarn.server.resourcemanager.ResourceManager.serviceInit(ResourceManager.java:344)
[info]   at org.apache.hadoop.service.AbstractService.init(AbstractService.java:164)
[info]   at org.apache.hadoop.yarn.server.MiniYARNCluster.initResourceManager(MiniYARNCluster.java:359)
{code}
Bug: Failed to run benchmark in GA
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 03/Jul/21 09:32
Affects Version/s: 3.2.0

When I running the benchmark in GA, I met the below error.

[https://github.com/pingsutw/spark/runs/2867617238?check_suite_focus=true] 
{code:java}
java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:175)21/06/20 07:40:02 ERROR SparkContext: Error initializing SparkContext.java.lang.AssertionError: assertion failed: spark.test.home is not set! at scala.Predef$.assert(Predef.scala:223) at org.apache.spark.deploy.worker.Worker.<init>(Worker.scala:148) at org.apache.spark.deploy.worker.Worker$.startRpcEnvAndEndpoint(Worker.scala:954) at org.apache.spark.deploy.LocalSparkCluster.$anonfun$start$2(LocalSparkCluster.scala:68) at org.apache.spark.deploy.LocalSparkCluster.$anonfun$start$2$adapted(LocalSparkCluster.scala:65) at scala.collection.immutable.Range.foreach(Range.scala:158) at org.apache.spark.deploy.LocalSparkCluster.start(LocalSparkCluster.scala:65) at org.apache.spark.SparkContext$.org$apache$spark$SparkContext$$createTaskScheduler(SparkContext.scala:2954) at org.apache.spark.SparkContext.<init>(SparkContext.scala:559) at org.apache.spark.SparkContext.<init>(SparkContext.scala:137) at org.apache.spark.serializer.KryoSerializerBenchmark$.createSparkContext(KryoSerializerBenchmark.scala:86) at org.apache.spark.serializer.KryoSerializerBenchmark$.sc$lzycompute$1(KryoSerializerBenchmark.scala:58) at org.apache.spark.serializer.KryoSerializerBenchmark$.sc$1(KryoSerializerBenchmark.scala:58) at org.apache.spark.serializer.KryoSerializerBenchmark$.$anonfun$run$3(KryoSerializerBenchmark.scala:63){code}
Bug: Upgrade Dropwizard Metrics to 4.2.2
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 05/Jul/21 05:31
Affects Version/s: 3.2.0

Dropwizard 4.2.1 fixes a bug related to JMXReporter but 4.2.1 also contains a  bug. so upgrading to 4.2.2 seems better.
https://github.com/dropwizard/metrics/releases/tag/v4.2.1
https://github.com/dropwizard/metrics/releases/tag/v4.2.2
Bug: fix pyspark.rdd.RDD.histogram's buckets argument
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 02/Jul/21 08:25
Affects Version/s: 3.0.0

I originally opened an issue and created a PR in the [https://github.com/zero323/pyspark-stubs] repository.

Issue: [https://github.com/zero323/pyspark-stubs/issues/548]

PR: [https://github.com/zero323/pyspark-stubs/pull/549]

—

The type hint for {{pyspark.rdd.RDD.histogram}}'s {{buckets}} argument should be {{Union[int, List[T], Tuple[T, ...]]}}

From {{pyspark}} source:
{code:java}
if isinstance(buckets, int):
    ...
elif isinstance(buckets, (list, tuple)):
    ...
else:
    raise TypeError("buckets should be a list or tuple or number(int or long)")
{code}
Bug: Update API usage on pyspark pandas documents
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 26/Jul/21 11:03
Affects Version/s: 3.2.0

I found several warning messages when I tested around ported Spark Pandas API Documents (https://issues.apache.org/jira/browse/SPARK-34885).

1.  `spark.sql.execution.arrow.enabled` on Best Practice document
{code:java}
21/07/26 05:42:02 WARN SQLConf: The SQL config 'spark.sql.execution.arrow.enabled' has been deprecated in Spark v3.0 and may be removed in the future. Use 'spark.sql.execution.arrow.pyspark.enabled' instead of it.
{code}
 

2. `DataFrame.to_spark_io` on From/to other DBMSes document
{code:java}
/opt/spark/python/lib/pyspark.zip/pyspark/pandas/frame.py:4811: FutureWarning: Deprecated in 3.2, Use spark.to_spark_io instead. warnings.warn("Deprecated in 3.2, Use spark.to_spark_io instead.", FutureWarning)
{code}
 

At this time it worked but I think it's better to update API usage on those documents.
Bug: Move PruneFileSourcePartitionsSuite out of org.apache.spark.sql.hive
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 14/Jul/21 17:54
Affects Version/s: 3.2.0

Currently both {{PruneFileSourcePartitionsSuite}} and {{PrunePartitionSuiteBase}} are in {{org.apache.spark.sql.hive.execution}} which doesn't look right. They should belong to {{org.apache.spark.sql.execution.datasources}}.
Bug: Install coverage in Python 3.9 and PyPy 3 in GitHub Actions image
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 30/Jul/21 13:11
Affects Version/s: 3.3.0

SPARK-36092 requires coverage package to be installed in both Python 3.9 and PyPy. Currently this is being manually installed.

To save installtation time, it would be great to have them installed in the image we use.
Bug: Rename CustomShuffleReader and OptimizeLocalShuffleReader
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 20/Jul/21 02:21
Affects Version/s: 3.2.0

The name {{CustomShuffleReader}} is confusing and sounds like an API. This should just be something like {{AQEShuffleRead}}.
{{OptimizeLocalShuffleReader}} is also a name of a rule but it reads as a reader which is odds. We should also rename this to something else
Bug: OptimizeLocalShuffleReader support reading data of multiple mappers in one task
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 12/Jul/21 22:37
Affects Version/s: 3.1.2

Right now OptimizeLocalShuffleReader tries to match the parallelism of the total shuffle reader against the original parallelism of the shuffle partition number if no coalescing (i.e., a shuffle stage without CustomShuffleReaderExec) or coalesced shuffle number if with coalescing (i.e., a shuffle stage with CustomShuffleReaderExec on top), by calling equallyDivide.

This is based on the assumption that the target parallelism is bigger than the number of mappers, so equallyDivide will assign a range of reducer ids of the same mapper to each downstream task, and that is why PartialMapperPartitionSpec has a mapIndex together with a reducerStartIndex and a reducerEndIndex.

However, it is also possible that the target parallelism is smaller than the number of mappers, and in that case, we need to “coalesce” the mappers by assigning a range of mapper ids to each downstream task. For that purpose, we might need to introduce a new type of ShufflePartitionSpec, which has a mapStartIndex and mapEndIndex , with the implication that each task will read all reducer outputs from mapStartIndex(inclusive) to mapEndIndex(exclusive). Note that this is different from CoalescedPartitionSpec which reads all mapper outputs from reduceStartIndex to reduceEndIndex.
Bug: when the right side is small enough to use SingleColumn Null Aware Anti Join
Status: In Progress | Priority: Minor | Resolution: 
Created: 11/Jul/21 06:57
Affects Version/s: 3.1.3

NULL-aware ANTI join (https://issues.apache.org/jira/browse/SPARK-32290) will build right side into a HashMap.

code in SparkStrategy:

 
{code:java}
case j @ ExtractSingleColumnNullAwareAntiJoin(leftKeys, rightKeys) =>
  Seq(joins.BroadcastHashJoinExec(leftKeys, rightKeys, LeftAnti, BuildRight,
    None, planLater(j.left), planLater(j.right), isNullAwareAntiJoin = true)){code}
we should add the conditions and use this optimization when the size of the right side is small enough.
Bug: Separate partition filters and data filters in PushDownUtils
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 30/Jul/21 06:01
Affects Version/s: 3.3.0

Currently, DSv2 partition filters and data filters are separated in PruneFileSourcePartitions. It's better to separate these in PushDownUtils, where we do filter/aggregate push down and column pruning, so we can still push down aggregate for FileScan if the filers are only partition filters.
Bug: Spark sql creates staging dir inside database directory rather than creating inside table directory
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 28/Jul/21 08:50
Affects Version/s: 3.1.2

Spark sql creates staging dir inside database directory rather than creating inside table directory.

 

This arises only when viewfs:// is configured. When the location is hdfs://, it doesn't occur.

 

Based on further investigation in file *SaveAsHiveFile.scala*, I could see that the directory hierarchy has been not properly handled for viewFS condition.
Parent path(db path) is passed rather than passing the actual directory(table location).

{{
// Mostly copied from Context.java#getExternalTmpPath of Hive 1.2
private def newVersionExternalTempPath(
path: Path,
hadoopConf: Configuration,
stagingDir: String): Path = {
val extURI: URI = path.toUri
if (extURI.getScheme == "viewfs")

{ getExtTmpPathRelTo(path.getParent, hadoopConf, stagingDir) }

else

{ new Path(getExternalScratchDir(extURI, hadoopConf, stagingDir), "-ext-10000") }

}
}}

Please refer below lines

===============================
if (extURI.getScheme == "viewfs") {
getExtTmpPathRelTo(path.getParent, hadoopConf, stagingDir)
===============================
Bug: Comparison of identical values
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 23/Jul/21 10:24
Affects Version/s: 3.1.3

This PR fixes the use of the "o.appAttemptId" variable instead of the mistaken "appAttemptId" variable. The current situation is a comparison of identical values. Fix proposed on SPARK-36273 (https://github.com/apache/spark/pull/33493).
Bug: Omnibus Java code static analyzer warning fixes
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 30/Jul/21 17:20
Affects Version/s: 3.2.0

Inspired by a recent Java code touch-up, I wanted to fix in one pass several lingering non-trivial issues with the Java code that a static analyzer turns up. Only a few of these have material effects, but some do, and figured we could avoid taking N PRs over time to address these.

* Some int*int multiplications that widen to long maybe could overflow
* Unnecessarily non-static inner classes
* Some tests "catch (AssertionError)" and do nothing
* Manual array iteration vs very slightly faster/simpler foreach
* Incorrect generic types that just happen to not cause a runtime error
* Missed opportunities for try-close
* Mutable enums which shouldn't be
* .. and a few other minor things
Bug: Google Kubernetes Engine authentication fails
Status: Open | Priority: Minor | Resolution: 
Created: 30/Jul/21 22:53
Affects Version/s: 3.1.2

When connecting to a Google Kubernetes Engine, a command {{gcloud container clusters get-credentials}} is used that generates a {{~/.kube/config}} file. The distinctive trait in this config file is that it uses an {{auth-provider}} relying on {{gcloud}} to inject the keys {{expiry}} and {{access-token}} from the general Google SDK auth config, as seen here:
{code:json}
users:
- name: gke_my-project_my-region_my-cluster
  user:
    auth-provider:
      config:
        cmd-args: config config-helper --format=json
        cmd-path: /Users/user/google-cloud-sdk/bin/gcloud
        expiry-key: '{.credential.token_expiry}'
        token-key: '{.credential.access_token}'
{code}
{{kubectl}}, because it uses {{client-go}}, supports the auth-provider and fetches the token and expiry from the json returne by config-helper. As Spark is using the fabric8 client, this is yet to be supported, breaking when running spark-submit:
{code:java}
Exception in thread "main" io.fabric8.kubernetes.client.KubernetesClientException: Failure executing: POST at: https://my-endpoint/api/v1/namespaces/my-namespace/pods. Message: Forbidden! User gke_my-project_my-region_my-cluster doesn't have permission. pods is forbidden: User "system:anonymous" cannot create resource "pods" in API group "" in the namespace "my-namespace".
{code}