av9ash/GitBugs huggingface dataset:
Bug: Function to format timestamp with time zone
Status: In Progress | Priority: Minor | Resolution: 
Created: 13/Feb/20 18:55
Affects Version/s: 3.1.0

Whenever timestamps are turned into strings (`Column.cast(StringType)`, `date_format(timestamp, format)`, `Dataset.show()`) the default time zone is used to format the string. This default time zone is either the java default zone `user.timezone`, the Spark default zone `spark.sql.session.timeZone` or the default DataFrameWriter zone `timeZone`. Currently there is no way to format a single column in a different timezone.
{code:java}
scala> spark.conf.set("spark.sql.session.timeZone", "Europe/London")
scala> spark.range(10). \
         select(concat(lit("2020-02-01 0"), $"id", lit(":00:00")).cast(TimestampType).as("time")). \
         select(
           $"time",
           date_format($"time", "uuuu-MM-dd HH:mm:ss ZZZZZ").as("local"),
           date_format_tz($"time", "uuuu-MM-dd HH:mm:ss ZZZZZ", "Europe/Berlin").as("Berlin")
         ). \
         show(false)
+-------------------+---------------------+--------------------------+
|time               |local                |Berlin                    |
+-------------------+---------------------+--------------------------+
|2020-02-01 00:00:00|2020-02-01 00:00:00 Z|2020-02-01 01:00:00 +01:00|
|2020-02-01 01:00:00|2020-02-01 01:00:00 Z|2020-02-01 02:00:00 +01:00|
|2020-02-01 02:00:00|2020-02-01 02:00:00 Z|2020-02-01 03:00:00 +01:00|
|2020-02-01 03:00:00|2020-02-01 03:00:00 Z|2020-02-01 04:00:00 +01:00|
|2020-02-01 04:00:00|2020-02-01 04:00:00 Z|2020-02-01 05:00:00 +01:00|
|2020-02-01 05:00:00|2020-02-01 05:00:00 Z|2020-02-01 06:00:00 +01:00|
|2020-02-01 06:00:00|2020-02-01 06:00:00 Z|2020-02-01 07:00:00 +01:00|
|2020-02-01 07:00:00|2020-02-01 07:00:00 Z|2020-02-01 08:00:00 +01:00|
|2020-02-01 08:00:00|2020-02-01 08:00:00 Z|2020-02-01 09:00:00 +01:00|
|2020-02-01 09:00:00|2020-02-01 09:00:00 Z|2020-02-01 10:00:00 +01:00|
+-------------------+---------------------+--------------------------+
{code}
Bug: Rename config for spark.<>.memoryOverhead
Status: Resolved | Priority: Minor | Resolution: Won't Fix
Created: 27/Feb/20 16:12
Affects Version/s: 2.4.5

The configuration for spark was changed recently and we have to keep the consistency in the code, so we need to rename the OverHeadMemory in the code to the new one: {{spark.executor.memoryOverhead}}
Bug: AQE should not issue a "not supported" warning for queries being by-passed
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 03/Feb/20 23:26
Affects Version/s: 3.0.0

This is a follow up for [https://github.com/apache/spark/pull/26813].

AQE bypasses queries that don't have exchanges or subqueries. This is not a limitation and it is different from queries that are not supported in AQE. Issuing a warning in this case can be confusing and annoying.

It would also be good to add an internal conf for this bypassing behavior.
Bug: Improve DOC for executor metrics
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 10/Feb/20 16:26
Affects Version/s: 3.1.0

This aims to improve the description of the executor metrics in the monitoring documentation. In particular by:

- adding reference to the Prometheus end point, as implemented in SPARK-29064

- extending the list and descripion of executor metrics, following up from the work in SPARK-27157
Bug: Pyspark queries fail if terminated with a semicolon
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 13/Feb/20 20:54
Affects Version/s: 3.0.0

When a user submits a directly executable SQL statement terminated with a semicolon, they receive a `org.apache.spark.sql.catalyst.parser.ParseException` of `mismatched input ";"`. SQL-92 describes a direct SQL statement as having the format of `<directly executable statement> <semicolon>` and the majority of SQL implementations either require the semicolon as a statement terminator, or make it optional (meaning not raising an exception when it's included, seemingly in recognition that it's a common behavior).
Bug: Update Xerces to 2.12.0
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 29/Feb/20 14:22
Affects Version/s: 2.4.5

To match HADOOP-16530 (https://issues.apache.org/jira/browse/HADOOP-16530) we should manage up the old version of Xerces it uses to 2.12.0. This picks up some bug and security fixes: https://www.xml.com/news/2018-05-apache-xerces-j-2120/
Bug: org.apache.spark.sql.AnalysisException: expression 'default.udfvalidation.`empname`' is neither present in the group by, nor is it an aggregate function. 
Status: Resolved | Priority: Minor | Resolution: Invalid
Created: 27/Feb/20 14:42
Affects Version/s: 2.4.2

I'm getting the following exception while executing the query in spark 2.4.2

!image-2020-02-27-20-07-03-701.png!

 

 

!image-2020-02-27-20-03-01-399.png!
Bug: Fix NPE in resolving k8s master url
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 27/Feb/20 09:34
Affects Version/s: 2.3.4

{code:java}
```
bin/spark-sql --master  k8s:///https://kubernetes.docker.internal:6443 --conf spark.kubernetes.container.image=yaooqinn/spark:v2.4.4
Exception in thread "main" java.lang.NullPointerException
	at org.apache.spark.util.Utils$.checkAndGetK8sMasterUrl(Utils.scala:2739)
	at org.apache.spark.deploy.SparkSubmit.prepareSubmitEnvironment(SparkSubmit.scala:261)
	at org.apache.spark.deploy.SparkSubmit.org$apache$spark$deploy$SparkSubmit$$runMain(SparkSubmit.scala:774)
	at org.apache.spark.deploy.SparkSubmit.doRunMain$1(SparkSubmit.scala:161)
	at org.apache.spark.deploy.SparkSubmit.submit(SparkSubmit.scala:184)
	at org.apache.spark.deploy.SparkSubmit.doSubmit(SparkSubmit.scala:86)
	at org.apache.spark.deploy.SparkSubmit$$anon$2.doSubmit(SparkSubmit.scala:920)
	at org.apache.spark.deploy.SparkSubmit$.main(SparkSubmit.scala:929)
	at org.apache.spark.deploy.SparkSubmit.main(SparkSubmit.scala)
```
{code}
Althrough k8s:///https://kubernetes.docker.internal:6443 is a wrong master url but should not throw npe
Bug: Preserve JVM information when executor heartbeat timeout
Status: Resolved | Priority: Minor | Resolution: Done
Created: 25/Feb/20 07:32
Affects Version/s: 2.3.0

In practice, it was found that executor has a gc loop state, which will cause gc to spend a lot of time. Usually, this situation does not cause OOM, but causes the connection driver to timeout.

First, we need to check the status of the gc loop,by calculating the cumulative time of GC abnormal state.By setting a reasonable threshold, save the JVM Heap before the executor heartbeat timeout


Of course, we can also detect the unhealthy state of the driver
Bug: BinaryClassificationMetrics optimization 
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 24/Feb/20 10:22
Affects Version/s: 3.1.0

{\{BinaryClassificationMetrics}} tend to fail when \{{grouping=count/numBins}} is too large, due to `Iterator.grouped(size: Int)` need to maintain a arraybuffer of size iterms, however, in \{{BinaryClassificationMetrics}} we do not need to maintain such a big array;
Bug: Use intercept instead of try-catch to assert failures in IntervalUtilsSuite
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 26/Feb/20 08:26
Affects Version/s: 3.0.0

Addressed the comment from https://github.com/apache/spark/pull/27672#discussion_r383719562 to use `intercept` instead of `try-catch` block to assert  failures in the IntervalUtilsSuite
Bug: The cache in StringRegexExpression is not initialized for foldable patterns
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 08/Feb/20 20:10
Affects Version/s: 1.6.3

In the case of foldable patterns, the cache in StringRegexExpression should be evaluated once but in fact it is compiled every time. Here is the example:
{code:sql}
SELECT '%SystemDrive%\Users\John' _FUNC_ '%SystemDrive%\\Users.*';
{code}
the code https://github.com/apache/spark/blob/8aebc80e0e67bcb1aa300b8c8b1a209159237632/sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/regexpExpressions.scala#L45-L48:
{code:scala}
  // try cache the pattern for Literal
  private lazy val cache: Pattern = pattern match {
    case Literal(value: String, StringType) => compile(value)
    case _ => null
  }
{code}
The attached screenshot shows that foldable expression doesn't fall to the first case.
Bug: Convert dates to/from timestamps in microseconds precision
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 18/Feb/20 19:07
Affects Version/s: 3.0.0

Currently, Spark converts dates to/from "timestamp" in millisecond precision but internally Catalyst's TimestampType values are stored as microseconds since epoch. When such conversion is needed in other date-timestamp functions like DateTimeUtils.monthsBetween, the function has to convert microseconds to milliseconds and then to days, see https://github.com/apache/spark/blob/06217cfded8d32962e7c54c315f8e684eb9f0999/sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/util/DateTimeUtils.scala#L577-L580 which just brings additional overhead w/o any benefits.

In later versions, it makes sense because milliseconds can be passed to TimeZone.getOffset but recently Spark switched to Java 8 time API and ZoneId. And supporting conversions to milliseconds are not needed any more.

The ticket aims to replace millisToDays by microsToDays, and daysToMillis by daysToMicros in DateTimeUtils.
Bug: [DOC] In streaming-kinesis-integration.md, the initialPosition method changed
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 20/Feb/20 14:17
Affects Version/s: 2.4.4

In Spark documentation : [https://spark.apache.org/docs/2.4.4/streaming-kinesis-integration.html#configuring-spark-streaming-application]

I find that here we still give exemple like: 

{{_".initialPositionInStream([initial position])"_}}

 

{{But in the code source of _spark-streaming-kinesis-asl_2.11-2.4.4_}}

I noticed:

_@deprecated("use initialPosition(initialPosition: KinesisInitialPosition)", "2.3.0")_
 _def initialPositionInStream(initialPosition: InitialPositionInStream): Builder_ 

 

{{So, I think that the doc here should be updated, to give an exemple like:}}

{{_".initialPosition([initial position])"_}}

 

 

And the same thing goes to the description below:

"_{{[initial position]}}: Can be either {{InitialPositionInStream.TRIM_HORIZON}} or {{InitialPositionInStream.LATEST}}_"

In fact, now we can use _{{KinesisInitialPositions.}}__{{TRIM_HORIZON KinesisInitialPositions.LATEST or *KinesisInitialPositions.AT_TIMESTAMP*}}_

{{(by using initialPosition in the place of initialPositionInStream)}}
Bug: Use Long instead of Int as argument type in Dataset limit method
Status: Resolved | Priority: Minor | Resolution: Won't Fix
Created: 17/Feb/20 10:37
Affects Version/s: 2.4.4

The Dataset limit method takes an input of type Int, which is a 32bit integer. The numerical upper limit of this type is 2,147,483,647. I found in my work to need to apply a limit to a Dataset higher than that which gives an error:

"py4j.Py4JException: Method limit([class java.lang.Long]) does not exist"

 

Could the input type of the limit method be changed to a Long (64bit)?
Bug: Revise the doc of spark.sql.sources.parallelPartitionDiscovery.threshold
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 19/Feb/20 21:41
Affects Version/s: 3.0.0

The doc of configuration "spark.sql.sources.parallelPartitionDiscovery.threshold" is not accurate on the part "This applies to Parquet, ORC, CSV, JSON and LibSVM data sources".

We should revise it as effective on all the file-based data sources.
Bug: Use Summarizer instead of MultivariateOnlineSummarizer in Aggregator test suite
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 12/Feb/20 21:53
Affects Version/s: 3.1.0

Similar to https://issues.apache.org/jira/browse/SPARK-29754, we can use Summarizer instead of MultivariateOnlineSummarizer in Aggregator test suite. Also, we should use common code to minimize code duplication.
Bug: Refactor BarrierTaskContext barrier method to use allGather directly
Status: Open | Priority: Minor | Resolution: 
Created: 12/Feb/20 18:47
Affects Version/s: 3.1.0

Issue is only present if this PR gets merged: [https://github.com/apache/spark/pull/27395]

 

Currently the `BarrierTaskContext.barrier` method and the `BarrierTaskContext.allGather` method both call the `BarrierTaskContext.runBarrier` method to perform the majority of the computation. A refactor to reduce complexity would be to change the `BarrierTaskContext.barrier` method to simply call `BarrierTaskContext.allGather` with an empty string as input and return `Unit` to the user, and move the `BarrierTaskContext.runBarrier` code into `BarrierTaskContext.allGather`. In this way, we can remove the `requestMethod` field from `RequestToSync` and do not have to case on `BarrierRequestToSync` and `AllGatherRequestToSync` in the `BarrierCoordinator` code.
Bug: Port `millisToDays` and `daysToMillis` on Java 8 time API
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 08/Feb/20 20:54
Affects Version/s: 3.0.0

Currently, the `millisToDays` and `daysToMillis` methods of DateTimeUtils use Java 7 (and earlier) time API. The implementation is based on combined calendar - Julian + Gregorian. To be consistent to other date-time function, need to port the methods on Java 8 time API.
Bug: Reuse results of floorDiv in calculations of floorMod in DateTimeUtils
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 07/Feb/20 09:57
Affects Version/s: 3.0.0

A couple methods in DateTimeUtils call Math.floorDiv and Math.floorMod with the same arguments. In this way, results of Math.floorDiv can be reused in calculation of Math.floorMod. For example, this optimization can be applied to the microsToInstant and truncDate.
Bug: Remove unnecessary changes in SPARK-30684 
Status: Resolved | Priority: Minor | Resolution: Duplicate
Created: 07/Feb/20 09:18
Affects Version/s: 3.0.0

In https://github.com/apache/spark/pull/27405 , the UI changes can be made without touching the `SparkPlanGraphNode`. Also, it seems that we don't need the function `adjustPositionOfOperationName` to adjust the position of operation name and mark as a operation-name class.
Bug: unable to turn off Hadoop's trash feature
Status: Resolved | Priority: Minor | Resolution: Workaround
Created: 05/Feb/20 16:01
Affects Version/s: 2.3.0

We're trying to turn off the `TrashPolicyDefault` in one of our Spark applications by setting `spark.hadoop.fs.trash.interval=0`, but it just stays `360` as configured in our cluster's `core-site.xml`.

Trying to debug it we managed to set `spark.hadoop.fs.trash.classname=OtherTrashPolicy` and it worked. the main difference seems to be that `spark.hadoop.fs.trash.classname` does not appear in any of the `*-site.xml` files.

when we print the conf that get initialized in `TrashPolicyDefault` we get:

```

Configuration: core-default.xml, core-site.xml, yarn-default.xml, yarn-site.xml, mapred-default.xml, mapred-site.xml, hdfs-default.xml, hdfs-site.xml, org.apache.hadoop.hive.conf.LoopingByteArrayInputStream@561f0431, file:/hadoop03/yarn/local/usercache/.../hive-site.xml

```

and:

`fs.trash.interval=360 [programatically]`

`fs.trash.classname=OtherTrashPolicy [programatically]`

 

any idea why `fs.trash.classname` works but `fs.trash.interval` doesn't?

this seems maybe related to: -SPARK-9825.-
Bug: Resource discovery should protect against user returing empty string for address
Status: Open | Priority: Minor | Resolution: 
Created: 05/Feb/20 22:01
Affects Version/s: 3.0.0

Using the resource discovery with custom resource scheduling, the user could return an empty string for an address.  Currently we allow this but it doesn't make sense.

We should protect against this and remove any empty strings.

To reproduce write a discoveryScript that returns valid json but one of the addresses is the empty string.
Bug: Bad signature for Spark 2.4.4
Status: Closed | Priority: Minor | Resolution: Invalid
Created: 04/Feb/20 11:35
Affects Version/s: 2.4.4

I downloaded the signatures files from the Apache Spark download page:
 * spark-2.4.4-bin-hadoop2.7.tgz.asc
 * spark-2.4.4-bin-hadoop2.7.tgz.sha512
 * KEYS

I ran the following commands:

gpg --import KEYS

gpg --verify spark-2.4.4-bin-hadoop2.7.tgz.asc spark-2.4.4-bin-hadoop2.7.tgz.sha512

For the KEYS command, I got:

{\{gpg: key 7B165D2A15E06093: "Andrew Or <andrewor14@gmail.com>" not changed gpg: key 6B32946082667DC1: "Xiangrui Meng (CODE SIGNING KEY) <meng@apache.org>" not changed gpg: key B1A91F0000799F7E: "Patrick Wendell <pwendell@gmail.com>" not changed gpg: key 7C6C105FFC8ED089: "Patrick Wendell <pwendell@gmail.com>" not changed gpg: key 5D951CFF87FD1A97: "Tathagata Das (CODE SIGNING KEY) <tdas@apache.org>" not changed gpg: key 548F5FEE9E4FE3AF: "Patrick Wendell <pwendell@gmail.com>" not changed gpg: key A70A1B29E90ADC5D: 1 signature not checked due to a missing key gpg: key A70A1B29E90ADC5D: "Holden Karau (CODE SIGNING KEY) <holden@apache.org>" not changed gpg: key B6C8B66085040118: "Felix Cheung (CODE SIGNING KEY) <felixcheung@apache.org>" not changed gpg: key DCE4BFD807461E96: "Sameer Agarwal (CODE SIGNING KEY) <sameerag@apache.org>" not changed gpg: key FD8FFD4C3A0D5564: 3 signatures not checked due to missing keys gpg: key FD8FFD4C3A0D5564: "Marcelo M. Vanzin <vanzin@apache.org>" not changed gpg: key DE4FBCCD81E6C76A: "Thomas Graves (CODE SIGNING KEY) <tgraves@apache.org>" not changed gpg: key DB0B21A012973FD0: "Saisai Shao (CODE SIGNING KEY) <jshao@apache.org>" not changed gpg: key 6BAC72894F4FDC8A: "Wenchen Fan (CODE SIGNING KEY) <wenchen@apache.org>" not changed gpg: key EDA00CE834F0FC5C: "Dongjoon Hyun (CODE SIGNING KEY) <dongjoon@apache.org>" not changed gpg: key 6EC5F1052DF08FF4: "Takeshi Yamamuro (CODE SIGNING KEY) <yamamuro@apache.org>" not changed gpg: key 42E5B25A8F7A82C1: "DB Tsai <dbtsai@dbtsai.com>" not changed gpg: key 96F72F76830C0D1B: "Xiao Li (CODE SIGNING KEY) <lixiao@apache.org>" not changed gpg: key E49A046C7F0FEF75: "Kazuaki Ishizaki (CODE SIGNING KEY) <kiszk@apache.org>" not changed gpg: key E1B7E0F25E4BF56B: "Xingbo Jiang (CODE SIGNING KEY) <jiangxb1987@apache.org>" not changed gpg: key 6E1B4122F6A3A338: "Yuming Wang <yumwang@apache.org>" not changed gpg: Total number processed: 20 gpg: unchanged: 20}}

For the verification, I got:

{{gpg: Signature made 08/27/19 22:30:32 GMT Daylight Time gpg: using RSA key EDA00CE834F0FC5C gpg: BAD signature from "Dongjoon Hyun (CODE SIGNING KEY) <dongjoon@apache.org>" [unknown]}}

 I have two questions:
 * why did this happen? I downloaded and installed Spark from one mirror and then the other, and still got the error. Also, the three files are the same in either case, so how does it tell which signature works?
 * I assume that when you get a bad signature error, that you should reinstall from another mirror. Is this true?
 * What is the signature verification doing?
Bug: Matrices.sprand mistakes in comments 
Status: Resolved | Priority: Trivial | Resolution: Fixed
Created: 13/Feb/20 15:03
Affects Version/s: 3.0.0

/**
 * Generate a `SparseMatrix` consisting of `i.i.d.` *gaussian random* numbers.

>> *should be "uniform random" here*

* @param numRows number of rows of the matrix
 * @param numCols number of columns of the matrix
 * @param density the desired density for the matrix
 * @param rng a random number generator
 * @return `Matrix` with size `numRows` x `numCols` and values in U(0, 1)
 */
 @Since("2.0.0")
 def sprand(numRows: Int, numCols: Int, density: Double, rng: Random): Matrix =
 SparseMatrix.sprand(numRows, numCols, density, rng)
Bug: Add missing pages to documentation index
Status: Resolved | Priority: Trivial | Resolution: Won't Fix
Created: 15/Feb/20 00:28
Affects Version/s: 3.0.0

There are a few pages tracked in `docs/` that are not linked to from the top navigation or from the index page. Seems unintentional.

To make these pages easier to discover, we should at least list them in the index and link to them from other pages as appropriate.
Bug: Improving writing performance by adding repartition based on columns to partitionBy for DataFrameWriter
Status: Resolved | Priority: Trivial | Resolution: Won't Fix
Created: 05/Feb/20 03:14
Affects Version/s: 3.1.0

h1. New functionality for {{partitionBy}}

To enhance performance using partitionBy , calling {{repartition}} method based on columns is much good before calling {{partitionBy}}. I added new function: {color:#0747a6}{{partitionBy(<True | False>, columns>}}{color} to {{partitionBy}}.

 
h2. Problems when not using {{repartition}} before {{partitionBy}}.

When using {{paritionBy}}, following problems happen because of specified columns in {{partitionBy}} are located separately.
 * The spark application which includes {{partitionBy}} takes much longer (for example, [[python - partitionBy taking too long while saving a dataset on S3 using Pyspark - Stack Overflow|https://stackoverflow.com/questions/56496387/partitionby-taking-too-long-while-saving-a-dataset-on-s3-using-pyspark]])]
 * When using {{partitionBy}}, memory usage increases much high compared with not using {{partitionBy}} (as follows I tested with Spark ver.2.4.3).
 * Additional information about memory usage affection by partitionBy: Please check the attachment (the left figure shows "using partitionBy", the other shows "not using partitionBy)".

h2. How to use?

It's very simple. If you want to use repartition method before {{partitionBy}}, just you specify {color:#0747a6}{{true}}{color} in {{partitionBy}}.

Example:
{code:java}
val df  = spark.read.format("csv").option("header", true).load(<INPUT_PATH>)
df.write.format("json").partitionBy(true, columns).save(<OUTPUT_PATH>){code}
Bug: Switch default index to distributed-sequence by default in pandas API on Spark
Status: Resolved | Priority: Critical | Resolution: Fixed
Created: 15/Dec/21 00:30
Affects Version/s: 3.3.0

pandas API on Spark currently sets {{compute.default_index_type}} to {{sequence}} which relies on sending all data to one executor that easily causes OOM.

We should better switch to {{distributed-sequence}} type that truly distributes the data.

With this change, we can now leverage https://issues.apache.org/jira/browse/SPARK-36559 and https://issues.apache.org/jira/browse/SPARK-36338 by default, and end users will benefit a lot of performance improvement.
Bug: Add PyArrow, pandas and plotly to release Docker image dependencies
Status: Resolved | Priority: Critical | Resolution: Fixed
Created: 06/Dec/21 02:50
Affects Version/s: 3.2.0

In order to build the PySpark documentation, it requires to run several jobs for pandas API on Spark to generate plots. See also https://github.com/apache/spark/blob/master/.github/workflows/build_and_test.yml#L501-L502
Bug: Cleanup direct usage of OkHttpClient
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 20/Dec/21 03:06
Affects Version/s: 3.3.0

- There are some problem (such as IPV6 based cluster support) on okhttpclient v3, but it's a little bit diffcult to upgrade to v4 [1]

- Kubernetes client are also consider to support other clients [2] rather than single okhttpclient.

- Kubernetes client add a abstract layer [3] to address supporting httpclient, okhttp client as one of supported http clients.

 

So, we better to consider to cleanup okhttpclient direct usage and use the httpclient which kubernetes client diret supported to reduce the potential risk in future upgrade.

 

See also:

[[1]https://github.com/fabric8io/kubernetes-client/issues/2632|https://github.com/fabric8io/kubernetes-client/issues/2632]

[2][https://github.com/fabric8io/kubernetes-client/issues/3663#issuecomment-997402993]

[3] [https://github.com/fabric8io/kubernetes-client/issues/3547]