Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Graeme Coupar
    @obmarg
    Hmm, that’s odd. Can you share a gist or something?
    Zach Norris
    @znorris
    Sure thing. I'll post the struct and the code snippet.
    https://gist.github.com/znorris/1ac1937d380de82f43099524ba7113b3
    Graeme Coupar
    @obmarg
    Cool, thanks. Definitely my fault - will push a fix up in a couple of minutes
    Zach Norris
    @znorris
    Thanks for looking into it so quickly!
    Graeme Coupar
    @obmarg
    Latest master has hopefully fixed that
    Zach Norris
    @znorris
    That did the trick! Thanks again. I'm pretty excited to start using elixir for custom Kubernetes development.
    rodesousa
    @rodesousa

    Hi,

    i would like use your lib but i dont understand one thing in Kazan.Watcher part.

     Start a watcher using the request, and passing the initial resource version and a pid to which to send received messages.

Kazan.Watcher.start_link(request, resource_version: rv, send_to: self())

...

resource_version - The version from which to start watching.

    I don't understand what is resource version ?

    Do you have a example of an watcher ?

    Graeme Coupar
    @obmarg
    Hi @rodesousa - the resource version lets kubernetes know what version of the resource you last saw.
    For example if you got on a pod while it was at resource version 1, then changed that pod and did a watch with resource version 1, you should see an event for your change come through
    It’s intended to make sure you don’t miss changes on resources that are changing frequently
    Graeme Coupar
    @obmarg
    Likewise if you need to restart a watcher you can pass in the last resource version you saw to make sure you don’t miss anything
    If you don’t have a resource version it’s ok to leave that off and Kazan will figure it out for you
    rodesousa
    @rodesousa
    Ok i had not did the link with resource version of an kubernetes object. Ok thanks =)
    rodesousa
    @rodesousa
    Last things :/, i can not receive msgs from my watcher. After run Kazan.Watcher.start_link(I took the handle_infos from the doc) do i missed another thing ? GenServer conf ?
    Graeme Coupar
    @obmarg
    Are you able to share the watcher bit of your code on gist.github.com?
    A lot easier to diagnose when I can see what’s going on 🙂
    rodesousa
    @rodesousa
    yep https://gist.github.com/rodesousa/3d6ef8fd50d440c3eb82908ab92fa35d
    thks a lot :)
    Graeme Coupar
    @obmarg
    Ok, so a watcher that’s started with send_to: self will send messages to the current process. You’ve added a handle_info function, but handle_info only gets sent messages when it’s part of a GenServer. If you wanted to receive messages outside of a GenServer you could use a receive block instead
    So yeah, either make it a GenServer or add a receive block to handle the watcher messages
    rodesousa
    @rodesousa
    {:ok, pid} = GenServer.start_link(__MODULE__, %{})
    Kazan.Apis.Core.V1.watch_namespace_list!()
    |> Kazan.Watcher.start_link(server: server, send_to: pid, resource_version: version)
    like this ?
    Graeme Coupar
    @obmarg
    That’s part of it
    Give me a minute
    I'm afraid I don't have a GenServer example of using watcher to hand, and don't have enough time to put something together right now
    but i can share this non-gen server example: https://gist.github.com/obmarg/c31d91b61a0ef8aff4f0428f7412d3a4
    (though one gotcha : that example is using kazan 0.9, and a few things have changed in 0.10)
    Graeme Coupar
    @obmarg
    actually, seems I do have time to throw something together right now: https://gist.github.com/obmarg/1f25161cd72d219e906c6befbe23e0f0
    that's roughly what you'd want for a GenServer - haven't tested it mind you
    rodesousa
    @rodesousa
    It's works thks =) (with genserver)
    Graeme Coupar
    @obmarg
    Great 👍
    rodesousa
    @rodesousa

    Sometimes i have this

    23:45:10.897 [info]  Process lines: #PID<0.217.0>
23:45:10.899 [info]  Received 410: #PID<0.217.0> message: too old resource version: 37721391 (37754861).
23:45:10.899 [info]  gone

    It's not better to catch the newest resource version when it is too old ?

    Graeme Coupar
    @obmarg
    That is one of the edge cases with using watchers: I don’t know exactly what circumstances it happens under, but sometimes watchers get a message that says the resource they’re watching is gone
    When that happens I think the recommendation is to re-fetch the resource and restart the watch
    But I’ve not actually encountered this myself
    This was a bit of a bug up until recently, you might be able to find more info in the bug report: obmarg/kazan#45
    If not, I’d be happy to help tomorrow. It’s quite late here in the uk, so I have to head now
    rodesousa
    @rodesousa
    OK, thanks a lot for helping =)
    i will see the PR
    Akash
    @atomicnumber1
    HI everyone, I've a quick question about configuration for gke.
    You see, I previously had,
    config :kazan, :server, {:kubeconfig, "path/to/file"}
    and it worked fine,
    Now, for gke, it says that I've to use Kazan.Server.resolve_token/2 to resolve auth,
    doest that mean, now I've pass server to every Kazan.run?
    Graeme Coupar
    @obmarg
    Hey @atomicnumber1 - it kinda depends on how your gke is set up. If the kubeconfig option was working for you before it should continue to work
    The resolve token stuff is just for a particular config setup of gke that I assumed was the default
    But if kubeconfig was working before then your gke is probably set up differently
    Akash
    @atomicnumber1

    Hey @obmarg , I see, I was using the @smn's fork previously for the gcp and the config thing was working fine, as the pull requested was merge, I switched to the default kazan and I get resolve_auth errors. makes sense?

    P.S. Thanks for the reply. I'm very new to this stuff.

    Akash
    @atomicnumber1
    We've kazan setup as, in production it uses in_cluster config, and in development it uses local kubeconfig, now this happens only when we authenticate locally, right?
    I don't know how to approach this. sigh
    Graeme Coupar
    @obmarg
    Ah, I see, you were using smn’s fork
    That makes sense - the resolve auth call got added after that
    Graeme Coupar
    @obmarg
    So, it sounds like you’d like to be able to continue using the application config but also need GCP support locally?
    Don’t think that’s something we support right now, but if I was to provide an API something like this, would that work for you:
    Kazan.Server.from_app_env(:your_app) |> Kazan.Server.resolve_auth |> Kazan.Client.send