https://linen.dev logo
Join Slack
Powered by
# support
  • g
    @mysterious-appointment-61638 it's a very valid question 🙂 We don't want to demotivate open-source version at all. We are not like other open-source projects which later became commercial entities and hence have to push the commercial entity. We took a deliberate choice of being open-source as well as running the commercial-entity together from day -1 because we believe open-source is very important for the success of this. Re: your specific question, our GitHub releases are not as frequent as our docker releases (which comes from a separate branch). If you don't want to use the latest tag, you can still use the corresponding named tags
  • g
  • g
    latest is same as 30112020.*
  • m
    thnkas @glamorous-shoe-15731 but how I know that magic number is the "stable/recommended release" it seems to me like a nightly one
  • m
  • m
    this is your latest release in github
  • m
    using "latest" tag in docker/kubernetes is dangerous and compatibility can break at any moment, also you never know which release you are running, as "latest" get cached
  • m
    also how I know which combination of rudder-server goes with rudder-trasnformer? if I use "latest" for server and transformer, it may happen the server one is from 1week ago (because got cached) and the transfomer one is from today, that is a a cry for trouble
  • g
    Yes, we haven't been marking releases on github primarily because we have been asking people to use docker/kubernetes on prod. The way our release process works is All code commit to master -> Pull into a branch called rudder-saas -> Build docker image and push to docker hub latest should be stable but @narrow-rain-89253 can you confirm?
  • m
    but by definition kubernetes cache every "latest" tag for a undetermined period of time, so it should never be used for kubernete releases, it may happen one image cache expire earlier than another because of timing, and cause all kind of issues
  • n
    In the helm charts, imagePullPolicy is deliberately set to 
    always
    so that if you are using the latest image tag, it will pull the image again skipping the cache always
  • n
    Reg. the server-transformer compatibility most version combinations are compatible. In case of incompatibility, the server throws an error on start specifying the minimum version of transformer that is needed
  • m
  • m
    that is a screenshot from kubernetes official docs @orange-barista-16311, in mostly managed kubernetes services the images are pulled from a internal cache, not the internet, so even if you specify "always" it will pull the image from the internal cache
  • m
    " In case of incompatibility, the server throws an error on start specifying the minimum version of transformer that is needed" yep,exactly, but as the software versions does not correspond to container versions, its impossible to fix withotu lot of try an error and forcing to clean internal caches adn this affects every service in the cluster
  • n
    You are right. Using 
    latest
    image tag in production might not be ideal but we felt its a rather good default image tag for people trying out the project.
  • n
    Adding multiple tags to the images might be a good idea so that some of the images can be marked as stable as you have mentioned
  • m
    maybe "stable" is nto the word, but at least to make sfotware and container version the same, what I suually do is to trigger the docker build on master tags, so the container has same version as one specific tag in the code
  • m
    this even can be automatic by reading a version ins the code itself, this tag can be a build date 
    20201202
    or can be a specific commit sha, any reference is good enough if it is explained somewhere
    👍 1
  • m
    you cannot imagine how many hours I spent this morngin tryign to figure out why rudder logs were complaining about an incompatibility, until I didn't clean the cluster image cache and redeploy rudder with latest, it wasn't fixed
  • m
    I tend to try new tools in a kubernetes namesapce for few weeks before deciding to really use it or not in prod, I guess for a quick trial this is not important but for a longer one can cause issues
  • m
    thanks for your time @narrow-rain-89253 I really appreciate what you re trying to do with rudder as I build an internal tool quite similar and I understand all the possible problems you can find
    👍 1
  • m
    hello, how do I know which sources are supported by posthog destination?
  • m
    I tried several but alwass get same error: 
    ERROR    [POSTHOG Router] :: userId 202225a4-6c0b-40fb-9dcc-079d1d123018 failed for the first time adding to map
  • g
    Is that in the transformer?
  • m
    server
  • m
    in transformer I get: 
    Error: server side identify is not on
  • m
    but I cannot see where I can enable such option
  • m
    I am not using custom trasnformers
  • g
    @lemon-megabyte-87173 may have a better idea of what’s happening here
1...456...127Latest