I saw this thread on twitter and realized that the mkKubeClientConfig defaults to using the native tls client and provides no easy way of overriding it.

So, I propose we should just use http-client-openssl instead of http-client-tls for creating the client.

Regenerate the code using the latest swagger-codegen once swagger-api/swagger-codegen#7254 is merged.

Just like python client here and here, we need to support loading kubeconfig both in cluster and outside of the cluster.

Watch is a non-standard method that swagger-codegen does not support and we need to add support for it like other clients (e.g. python here)

In the Exec entry point

Command has to be supplied multiple times in the query string in order to pass parameters

(CoreV1.connectGetNamespacedPodExec (Accept MimeAny) name namespace) -&- 
                (Command "ls") -&- 
                (Command "/") -&- 
                (Stdout True) -&- 
                (Stderr True)

should result in a query string of
?command=ls&command=/&stdout=true&stderr=true

but actually results in a query string of
?command=/&stdout=true&stderr=true

https://blog.travis-ci.com/2017-10-26-running-kubernetes-on-travis-ci-with-minikube

I'd like to use this on my project, but I would need to update to a newer LTS. Would that be accepted upstream, assuming all else is well? I have never updated an LTS on a big project so I don't totally know what to do.

the commit a9d6705e8c57da1a336c3376b3a3f8765dc1bde2 does not compile with errors:

kubernetes-client> /tmp/stack-3159d292bc602efe/kubernetes-client-0.3.1.0/src/Kubernetes/Client/Auth/OIDC.hs:97:47: error:
kubernetes-client>     • Couldn't match expected type ‘Maybe Text’ with actual type ‘Text’
kubernetes-client>     • In the ‘oauthClientSecret’ field of a record
kubernetes-client>       In the expression:
kubernetes-client>         OAuth2
kubernetes-client>           {oauthClientId = clientID, oauthClientSecret = clientSecret,
kubernetes-client>            oauthAccessTokenEndpoint = tokenURI,
kubernetes-client>            oauthOAuthorizeEndpoint = tokenURI, oauthCallback = Nothing}
kubernetes-client>       In an equation for ‘oauth’:
kubernetes-client>           oauth
kubernetes-client>             = OAuth2
kubernetes-client>                 {oauthClientId = clientID, oauthClientSecret = clientSecret,
kubernetes-client>                  oauthAccessTokenEndpoint = tokenURI,
kubernetes-client>                  oauthOAuthorizeEndpoint = tokenURI, oauthCallback = Nothing}
kubernetes-client>    |
kubernetes-client> 97 |                         , oauthClientSecret = clientSecret

Hi,

Is there a plan to put this code up on Hackage?

Even if you don't think you're ready for a major release, having the code deployed to Hackage would be really helpful for a lot of people.

I'm not sure what's happened, but kubernetes-client 0.2.0.0 available on Hackage has a dependency on time ==1.8.*, which makes it difficult to build with GHC 8.8 (8.8.4 has time 1.9.3). I'm not completely sure why the generated Cabal file has that version bound though, because the package.yaml clearly states a dependency on time >=1.8.

I just ran hpack(version 0.34.2) manually on the package.yaml and the generated Cabal file is correct, i.e. a dependency on time >=1.8. So basically I'm confused about this...

Would someone please take pity on us Hackage users and adjust the dependency in the Cabal file?

This causes something as simple as getting a pod to fail. Here is the definition of V1ResourceRequirements from the code.

data V1ResourceRequirements = V1ResourceRequirements
  { v1ResourceRequirementsLimits :: !(Maybe (Map.Map String Quantity)) -- ^ "limits" - Limits describes the maximum amount of compute resources allowed. More info: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/
  , v1ResourceRequirementsRequests :: !(Maybe (Map.Map String Quantity)) -- ^ "requests" - Requests describes the minimum amount of compute resources required. If Requests is omitted for a container, it defaults to Limits if that is explicitly specified, otherwise to an implementation-defined value. More info: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/
  } deriving (P.Show, P.Eq, P.Typeable)

-- | FromJSON V1ResourceRequirements
instance A.FromJSON V1ResourceRequirements where
  parseJSON = A.withObject "V1ResourceRequirements" $ \o ->
    V1ResourceRequirements
      <$> (o .:? "limits")
      <*> (o .:? "requests")

The requests and limits are defined in terms of Quantity. And here is the definition of Quantity:

newtype Quantity = Quantity { unQuantity :: Text }
  deriving (Show, Eq, ToJSON, FromJSON, Typeable, Generic)

The YAML I get from the server looks like this:

...
      resources:
        requests:
          cpu: 100m
...

When I try to parse it, I get this error:

"Error in $.requests.cpu: expected unary record, encountered Boolean"

If I try to parse 100m as Quantity, I get the same error. However if I decode {"unQuantity": "100m"}, I get the proper quantity. So, I think we need to just change the FromJSON instance of Quantity to just expect a string.

I also see that Quantity is defined in CustomTypes module. I was wondering if I can just send a PR by writing FromJSON by hand, or should this be an issue with either the openapi-generator or the open-api spec itself.

The version on Hackage could use an update. Builds fine in stack pointing at the repo but version on Hackage is too old. Happy to help if desired.

In the type above, the return value says V1Status. I think it should be V1PersistentVolumeClaim; see the docs here:

https://kubernetes.io/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-claim-v1/#response-9

I noticed this because of a parsing error when running this command against my cluster. I'm not sure the right place to fix it. The swagger.json file in this repo also lists the return type as #/definitions/v1.Status.

Hi,

Thanks for the project! I'm trying it out, so far everything works smooth, except patchNamespacedCustomObject. I'm not sure why, but this example

import qualified Kubernetes.OpenAPI.API.CustomObjects as Dynamic

result <- dispatchMime
    manager
    kcfg
    (Dynamic.patchNamespacedCustomObject
        (Body patch)
        (Group "some_group")
        (Version "some_version")
        (Namespace "default")
        (Plural "some_plural")
        (Name "some_name"))

where patch looks like:

[{
    "op": "replace",
    "path": "/spec/some/path",
    "value": "some_value"
}]"

returns

{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {},
  "status": "Failure",
  "message": "Invalid JSON Patch",
  "code": 500
}

In the code above patch is just a Text, do I need to do something else with it? I've tried the same via kubectl patch, seems working, so I guess the payload itself is correct.

mimeError = "Error in $.items[39].status.images[11].names: parsing [] failed, expected Array, but encountered Null",

cat ~/error.json | jq '.items[39].status.images[11]'
{
  "names": null,
  "sizeBytes": 226150943
}

I just finished upgrading from 0.1.0.1 to 0.2.0.0 and I get the same error. Is there some way to get past it?

When i connect to the cluster using a kubeconfig file, I get a SSL error saying "name mismatch".

Is it possbile to change the signature of function mkKubeClientConfig from
OIDCCache -> KubeConfigSource -> IO (NH.Manager, K.KubernetesClientConfig) to mkKubeClientConfig :: OIDCCache -> KubeConfigSource -> (TLS.ClientParams -> TLS.ClientParams)-> IO (NH.Manager, K.KubernetesClientConfig),
so I could pass disableServerCertValidation to it?

Context: #7 (comment)

Once swagger-api/swagger-codegen#7254 is merged, we should re-generate the code using the latest swagger-codegen.

It would be awesome to have some simple examples, similar to the official python examples.

In my case some useful ones would be "create deployment from file" and "reconfigure a live replicaset".

If I manage to get some up and running, would you be open to a pull request? Otherwise, what is the best source to learn about the API?

It seems slightly overkill to read the automatically generated hackage docs.

assumes a DNS name or ipv4 address... it does not work correctly with an ipv6 address (the ipv6 host must be wrapped in brackets)

After trying this snippet (thanks to @akshaymankar for proving the functionality) and replacing it with my local kube configuration file I got the following error:

haskell-test-exe: HttpExceptionRequest Request {
  host                 = "172.24.59.88"
  port                 = 6443
  secure               = True
  requestHeaders       = [("User-Agent","kubernetes-client-core/0.1.0.0"),("accept","application/json")]
  path                 = "/api/v1/pods"
  queryString          = ""
  method               = "GET"
  proxy                = Nothing
  rawBody              = False
  redirectCount        = 10
  responseTimeout      = ResponseTimeoutDefault
  requestVersion       = HTTP/1.1
}
 (InternalException (HandshakeFailed (Error_Protocol ("certificate rejected: [NameMismatch \"172.24.59.88\"]",True,CertificateUnknown))))

I'm slightly out of my domain with managing certificates, but it seems that the underlying SSL library (#63?) can not find the needed certificates / does not trust them for some reason.

To set up helm it sufficed to point it to the kubernetes config file, so I'm not really sure what to do now.

Versions:

> kubectl version --short         
Client Version: v1.15.0
Server Version: v1.15.4
> stack --numeric-version         
1.9.3

Currently using the 95eb28b commit for both kubernetes-client and kubernetes-client-core.

Hey, this is a great package but I'm struggling to run it on newer versions of GHC (tried with 9.4.8 or higher) and it cannot resolve the dependencies because of constraints on the http-api-data package:

[__1] trying: kubernetes-client-0.3.2.0 (dependency of hask-k8s)
[__2] trying: kubernetes-client-core-0.3.1.0 (dependency of kubernetes-client)
[__3] next goal: http-api-data (dependency of kubernetes-client-core)
[__3] rejecting: http-api-data-0.6 (conflict: kubernetes-client-core =>
http-api-data>=0.3.4 && <0.5)
[__3] skipping: http-api-data-0.5.1, http-api-data-0.5 (has the same
characteristics that caused the previous version to fail: excluded by
constraint '>=0.3.4 && <0.5' from 'kubernetes-client-core')
[__3] trying: http-api-data-0.4.3
[__4] next goal: base (dependency of hask-k8s)
[__4] rejecting: base-4.17.2.1/installed-4.17.2.1 (conflict: http-api-data =>
base>=4.7 && <4.17) 

Has anyone had any luck using this package on GHC 9.4 or higher?

according to OpenAPITools/openapi-generator#3459, when generating request URIs, the generated code uses Query for the query type, which escapes characters like +, which should not escaped, for instance, for the Kubernetes API client.

In the Kubernetes API client, we should be able to generate queries like ?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29 (from https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#list-and-watch-filtering). Right now, the generated URIs URL-encode the plus signs, which the API server rejects.

Configure and package the client (Cabal?).

ref: kubernetes/community#1721

This repo is listed in sigs.yaml as belonging to sig-api-machinery, but it lacks an OWNERS file. Can you please add one with the appropriate list of approvers and reviewers? eg:

• robust example: approvers, reviewers, aliases
• simple example: only approvers, no aliases

For more information see the OWNERS docs

/sig api-machinery

/assign @lavalamp @deads2k
sig-api-machinery chairs

/assign @brendandburns @mbohlool
as folks who've been merging PR's recently

Several months ago, the folks at SmartBear (who own the repo for swagger-codegen [1] ) decided to do a re-write while moving from supporting the 2.0 openapi spec to 3.0.

However, in this process, they also changed the templating language from mustache to handlebars - invalidating existing languages - essentially existing work for each language would have to be re-built from scratch.

This caused a split in which the primary open-source contributors left, and forked swagger-codegen into a new repo "openapi-generator" [1] - which focuses on an incremental path to support of the openapi 3.0 spec, and not moving to handlebars templates or throwing out existing work on generators, and focusing more on backwards-compatibility.

I've included the haskell-http-client generator in the new openapi-generator, which has been merging my pull requests promptly, and in which i also have commit rights.

I've tried submitting PR's to swagger-codegen, but they have not been merging any PR's lately.

the upshot:

1. Continue to use swagger-codegen. For now, the breaking changes are only on the 3.0.0 branch and master still includes the old haskell-http-client. If they switch master to 3.0.0 at some point haskell-http-client probably won't be available there anymore. You could continue to target an existing commit for the generator, but probably not be able to get any changes made to the haskell-http-client generator very easily. So, If the current version of the generator is serving your needs adequately, then all is good.

2. Switch to openapi-generator. It's pretty much backwards compatible, but some cli arguments may be depricated. Also i'm not sure if the build process here supports targeting a different repo than swagger-codegen. If more features/changes in the generator are desired though, it would be much easier to make them in openapi-generator.

As of today, I haven't made extensive changes to the haskell-http-client generator, so there is not much difference in features from swagger-codegen vs. openapi-generator.

Question: Are there any ongoing/steady users of kubernetes-client/haskell ?

[1] https://github.com/swagger-api/swagger-codegen
[2] https://github.com/OpenAPITools/openapi-generator

When trying to create a a resource with DateTime field, kubernetes returns 400 with the following message:

[2019-09-29 14:27:11][Kubernetes.OpenAPI.Client][Info][manjaro-v01][PID 31826][ThreadId 11] REQ:POST 192.168.99.100/apis/coordination.k8s.io/v1/namespaces/default/leases
Left (MimeError {mimeError = "error statusCode: 400", mimeErrorResponse = Response {responseStatus = Status {statusCode = 400, statusMessage = "Bad Request"}, responseVersion = HTTP/1.1, responseHeaders = [("Content-Type","application/json"),("Date","Sun, 29 Sep 2019 14:27:11 GMT"),("Content-Length","562")], responseBody = "{\"kind\":\"Status\",\"apiVersion\":\"v1\",\"metadata\":{},\"status\":\"Failure\",\"message\":\"Lease in version \\\"v1\\\" cannot be handled as a Lease: v1.Lease.Spec: v1.LeaseSpec.HolderIdentity: AcquireTime: unmarshalerDecoder: parsing time \\\"2019-09-29T14:27:11.738Z\\\" as \\\"2006-01-02T15:04:05.000000Z07:00\\\": cannot parse \\\".738Z\\\" as \\\".000000\\\", error found in #10 byte of ...|7:11.738Z\\\",\\\"holderId|..., bigger context ...|itions\\\":1,\\\"acquireTime\\\":\\\"2019-09-29T14:27:11.738Z\\\",\\\"holderIdentity\\\":\\\"test_identity\\\",\\\"renewTime\\\":\\\"201|...\",\"reason\":\"BadRequest\",\"code\":400}\n", responseCookieJar = CJ {expose = []}, responseClose' = ResponseClose}})
[2019-09-29 14:27:11][Kubernetes.OpenAPI.Client][Info][manjaro-v01][PID 31826][ThreadId 11] RES:statusCode=400 (POST 192.168.99.100/apis/coordination.k8s.io/v1/namespaces/default/leases)
[2019-09-29 14:27:11][Kubernetes.OpenAPI.Client][Error][manjaro-v01][PID 31826][ThreadId 11] error statusCode: 400

Example code to reproduce:

{-# LANGUAGE OverloadedStrings #-}
-- module Main where

import           Data.Function                 ((&))
import           Kubernetes.Client           
import           Kubernetes.OpenAPI           
import Kubernetes.OpenAPI.API.CoordinationV1
import qualified Kubernetes.OpenAPI.API.CoreV1 as CoreV1
import           Network.TLS                   (credentialLoadX509)

import Kubernetes.OpenAPI.Model as M
import Data.Time.Clock (getCurrentTime)
import Control.Monad (forever)
import Control.Concurrent (threadDelay)
import System.Environment (getArgs, getEnv)
import Data.Text (pack)

main :: IO ()
main = do
    kcfg0 <-
        newConfig
        & fmap (setMasterURI "https://192.168.99.100:8443")
        & fmap disableValidateAuthMethods
    logContext <- stdoutLoggingContext $ configLogContext kcfg0
    let kcfg = kcfg0 { configLogContext = logContext}
    home <- getEnv "HOME"
    myCAStore <- loadPEMCerts $ home ++ "/.minikube/ca.crt"
    myCert <-
        credentialLoadX509 (home ++ "/.minikube/client.crt") (home ++ "/.minikube/client.key")
            >>= either error return
    tlsParams <-
        defaultTLSClientParams
        & fmap disableServerNameValidation
        & fmap disableServerCertValidation
        & fmap (setCAStore myCAStore)
        & fmap (setClientCert myCert)
    manager <- newManager tlsParams

    -- Create new lease
    acquireTime <- getCurrentTime
    result <- dispatchMime' manager kcfg $ createNamespacedLease (ContentType MimeJSON) (Accept MimeJSON) (newLease acquireTime) (Namespace "default")
    print result

    where
      newLease acquireTime = 
        mkV1Lease
          { v1LeaseMetadata = Just $ mkV1ObjectMeta 
            { v1ObjectMetaName = Just $ "testing"
            , v1ObjectMetaNamespace = Just $ "default"
            }
          , v1LeaseSpec = Just $ mkV1LeaseSpec
            { v1LeaseSpecAcquireTime = Just $ DateTime acquireTime
            , v1LeaseSpecHolderIdentity = Just $ "test_identity"
            , v1LeaseSpecLeaseDurationSeconds = Just $ 10
            , v1LeaseSpecRenewTime = Just $ DateTime acquireTime
            , v1LeaseSpecLeaseTransitions = Just 1
            }
          }

Currently the haskell-http-client OpenAPI generator selects one of katip or monad-logger when generating the client functions.

Perhaps this is too much additional complexity, but it seems like it wouldn't be too much extra effort for the upstream haskell-http-client to generate both {{baseModule}}.Logging.MonadLogger and {{baseModule}}.Logging.Katip, make {{baseModule}}.Logging a re-export of one of the two (based on some CPP directive), and add a flag to the cabal file that toggles the CPP directive and selects other-modules/exposed-modules.

I'm opening the issue to this tracket simply because this is the most active consumer of the haskell-http-client generator that I'm aware of, so I imagine peoples' opinions here would be the most informed.

Add some simple request (list Pods etc) examples to the README to help new users get started and how to authenticate etc.

A few PRs have been merged since the last (first!) release. I think we should make another one now.
With #60 and #51, we've changed the APIs significantly to make us bump major according to PVP.
Also, with #60 all the dependencies are on stackage, so we can also add both the packages to stackage.

Ref: OpenAPITools/openapi-generator#2362 (comment)

On my machine, using the latest commit of https://github.com/kubernetes-client/gen,
the client update produces this error:

$ ${GEN_REPO_BASE}/openapi/haskell.sh kubernetes settings
.
.
.
 => => naming to docker.io/library/kubernetes-haskell-http-client-client-gen-with-openapi-generator:v1     0.0s
--- Running generator inside container...
/source/openapi-generator /
/
--- Downloading and pre-processing OpenAPI spec
/usr/local/lib/python3.9/dist-packages/urllib3/connectionpool.py:842: 
InsecureRequestWarning: Unverified HTTPS request is being made. 
Adding certificate verification is strongly advised. 
See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
  warnings.warn((
Traceback (most recent call last):
  File "//preprocess_spec.py", line 549, in <module>
    sys.exit(main())
  File "//preprocess_spec.py", line 538, in main
    write_json(unprocessed_spec, in_spec)
  File "//preprocess_spec.py", line 490, in write_json
    with open(filename, 'w') as out:
PermissionError: [Errno 13] Permission denied: '/output_dir/swagger.json.unprocessed'

Using a commit of kubernetes-client/gen prior to kubernetes-client/gen@b32dcd6 results in a different error:

 => => naming to docker.io/library/kubernetes-haskell-http-client-client-gen-with-openapi-generator:v1                                                                 0.0s
--- Running generator inside container...
/source/openapi-generator /
fatal: detected dubious ownership in repository at '/source/openapi-generator'
To add an exception for this directory, call:

        git config --global --add safe.directory /source/openapi-generator

Exec and Attach class are non-standard calls that kubernetes API server uses to connect to a port of a pod/container or execute a command on them. It uses SPDY or WebSockets. Normal calls to these endpoints will result in an upgrade request from API server. We need to support WebSocket for this client (for those endpoints). This is python implementation of the same feature.

Comparing 0.3.0.0 and 3.1.0.0, the following instances have been removed from the newer version:

FromJSON a => MimeRender MimeStrategicMergePatchjson a
FromJSON a => MimeRender MimeMergePatchjson a
FromJSON a => MimeRender MimeJsonPatchjson a
...

While I'm unaware of the reasoning behind the removal, it does appear that calls such as patchNamespacedService and all other PATCH operations are borderline useless, as you're now required to assemble a read+patch to formulate an incremental atomic update. The only remaining instance that satisfies the PATCH operation's MimeRender contentType Body constraint is:

instance ToJSON a => MimeRender MimeJSON a

TL;DR: It appears that strategic patches are now unsupported in >= 3.1.0.0.

This option was introduced here: 541fb76.

I have been running commands using the pod "exec" endpoint, and some of my commands had plus signs in them. (Because of new-style Nix hashes, as it turns out.) I spent many hours scratching my head about why they weren't executing properly before I found this change.

I don't think it makes sense to set a global configQueryExtraUnreserved in the KubernetesClientConfig, because sometimes this kind of escaping needs to happen and sometimes it doesn't.

I was wondering if an alternative might be possible which is easier to use/more apparent when you're getting it wrong. I'm picturing a newtype called PartiallyUnescaped or UnescapePlusSigns or something, which can be wrapped around a normal query param, so you could do something like

let req = connectGetNamespacedPodExec (Accept MimeAny) (Name podName) namespace 
      -&- (UnescapePlusSigns (SomeFlag "environment+in"))

and then define the toQueryParam method of ToHttpApiData (UnescapePlusSigns a) accordingly.

I'm not married to any particular solution of course. CC @jonschoning

As per the email sent to kubernetes-dev[1], please create a SECURITY_CONTACTS
file.

The template for the file can be found in the kubernetes-template repository[2].
A description for the file is in the steering-committee docs[3], you might need
to search that page for "Security Contacts".

Please feel free to ping me on the PR when you make it, otherwise I will see when
you close this issue. :)

Thanks so much, let me know if you have any questions.

(This issue was generated from a tool, apologies for any weirdness.)

[1] https://groups.google.com/forum/#!topic/kubernetes-dev/codeiIoQ6QE
[2] https://github.com/kubernetes/kubernetes-template-project/blob/master/SECURITY_CONTACTS
[3] https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance-template-short.md

See kubernetes/kubernetes#70679

As specified here, client libraries can add badges to show capabilities and support level. After we resolve #2, the haskell client can be silver and beta.

Hey there @kubernetes-client/haskell-admins ,

One of the github-admins here. -- We have a longstanding issue on cleaning up outside collaborators, and are now actively planning on removing them on December 1st.

At this point, people that are actively contributing to the Kubernetes project should be promoted to org members, and any repo specific permissions should be managed through their associated configuration in kubernetes/org.

With that in mind, the following people are listed as outside collaborators:

• @guoshimin
• @jkachmar
• @jonschoning

All three are active, and I'd encourage applying for membership to the kubernetes-client org. 😄

Just a general reminder, not having direct permissions does not stop folk from contributing. It just means they'd have less permissions (would need /ok-to-test on PRs etc).

If you have any questions or comments, please don't hesitate to ask in here or feel free to poke me in slack 👍

Thanks!

assigning haskell admins:
/assign @brendandburns @mbohlool

/sig contributor-experience
/priority important-soon