You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You can remove a cluster from your kubectl configuration by running kubectl config delete-cluster, and this will succeed even if a context referring to that cluster exists. kubectl will then continue to work normally, as long as you don't try to use that context, only then will it fail.
Skuber in comparison fails to parse the configuration file, even if you don't use that context. I think Skuber should, like kubectl, be more tolerant than this, and only fail when a user attempts to use that context. The simplest thing would probably be for it to just ignore contexts whose clusters or users don't exist, but ideally, if you tried to use the context, it would give a more meaningful error message, roughly like cluster "foo" not found for context "bar".
The text was updated successfully, but these errors were encountered:
[info] java.util.NoSuchElementException: None.get
[info] mat scala.None$.get(Option.scala:529) 0s
[info] at scala.None$.get(Option.scala:527)
[info] at skuber.api.Configuration$.$anonfun$parseKubeconfigStream$11(Configuration.scala:212)
[info] at scala.Option.map(Option.scala:230)
[info] at skuber.api.Configuration$.toK8SContext$1(Configuration.scala:211)
[info] at skuber.api.Configuration$.$anonfun$parseKubeconfigStream$18(Configuration.scala:221)
[info] at skuber.api.Configuration$.$anonfun$parseKubeconfigStream$6(Configuration.scala:153)
[info] at scala.collection.TraversableLike.$anonfun$map$1(TraversableLike.scala:238)
[info] at scala.collection.Iterator.foreach(Iterator.scala:941)
[info] at scala.collection.Iterator.foreach$(Iterator.scala:941)
[info] at scala.collection.AbstractIterator.foreach(Iterator.scala:1429)
[info] at scala.collection.IterableLike.foreach(IterableLike.scala:74)
[info] at scala.collection.IterableLike.foreach$(IterableLike.scala:73)
[info] at scala.collection.AbstractIterable.foreach(Iterable.scala:56)
[info] at scala.collection.TraversableLike.map(TraversableLike.scala:238)
[info] at scala.collection.TraversableLike.map$(TraversableLike.scala:231)
[info] at scala.collection.AbstractTraversable.map(Traversable.scala:108)
[info] at skuber.api.Configuration$.topLevelYamlToK8SConfigMap$1(Configuration.scala:153)
[info] at skuber.api.Configuration$.$anonfun$parseKubeconfigStream$1(Configuration.scala:221)
[info] at scala.util.Try$.apply(Try.scala:213)
[info] at skuber.api.Configuration$.parseKubeconfigStream(Configuration.scala:102)
[info] at skuber.api.Configuration$.$anonfun$parseKubeconfigFile$2(Configuration.scala:93)
[info] at scala.util.Success.flatMap(Try.scala:251)
[info] at skuber.api.Configuration$.parseKubeconfigFile(Configuration.scala:92)
You can remove a cluster from your kubectl configuration by running
kubectl config delete-cluster
, and this will succeed even if a context referring to that cluster exists. kubectl will then continue to work normally, as long as you don't try to use that context, only then will it fail.Skuber in comparison fails to parse the configuration file, even if you don't use that context. I think Skuber should, like kubectl, be more tolerant than this, and only fail when a user attempts to use that context. The simplest thing would probably be for it to just ignore contexts whose clusters or users don't exist, but ideally, if you tried to use the context, it would give a more meaningful error message, roughly like
cluster "foo" not found for context "bar"
.The text was updated successfully, but these errors were encountered: