Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    omnilinguist
    @omnilinguist
    i guess forge doesn't use supervisord so isn't affected by this issue
    Rafael Schloming
    @rhs
    yeah, forge users don't need to know python at all
    Richard Li
    @richarddli
    so since forge is a client-side program, we expect we'll stick with py2 for now (because of mac). but we've switched distribution systems so that forge is now a single static binary. so at this point, the fact that forge is written in python is basically an implementation detail.
    so if you install forge today, you'll see that we ask you to curl a binary from an s3 bucket
    omnilinguist
    @omnilinguist
    what about as it relates to a sort of "base microservice"
    Rafael Schloming
    @rhs
    forge just builds and deploys the microservice, it doesn't care what language the microservice is written in
    omnilinguist
    @omnilinguist
    i think i see what you're saying though - forge is deliberately unopinionated on what language ppl build on top of it
    Rafael Schloming
    @rhs
    yeah
    Richard Li
    @richarddli
    we actually are using forge to deploy our cloud service (kubernaut)
    and kubernaut is written in Kotlin
    omnilinguist
    @omnilinguist
    is that your "hello world" microservice?
    Richard Li
    @richarddli
    no, kubernaut is our on-demand ephemeral Kube cluster service
    omnilinguist
    @omnilinguist
    (that you maintain as a proof of concept usage of forge? if not, does such a repo exist?)
    Richard Li
    @richarddli
    we use it so we can get a Kube cluster instantly as part of our CI runs
    (and then the Kube cluster goes back into the pool)
    the example of Forge you probably are looking for is here: https://github.com/datawire/todo
    that consists of an API Gateway (built around envoy), a bunch of services, etc
    omnilinguist
    @omnilinguist
    hm, and these apps (at least the python ones) are still on py2
    Richard Li
    @richarddli
    yes, but for no real reason
    omnilinguist
    @omnilinguist
    was a py3 migration ever considered for those?
    Richard Li
    @richarddli
    it would be a trivial exercise to migrate to py3 for these apps
    omnilinguist
    @omnilinguist
    i think i may be barking up the wrong tree though with respect to this py3-supervisord compatibility issue
    Richard Li
    @richarddli
    yeah, i'm not sure i completely understand your question
    omnilinguist
    @omnilinguist
    let me try to summarize the overall issue

    py3 is great, and it looks like it is the way to go for all new python stuff. but unfortunately supervisord, a process management system that we use) is explicitly stated as still not py3 compatible, which we already spent a fair amount of time on thus far. so this would pose some major issues in our trying to jump on the py2=>py3 bandwagon for new microservices.

    however, it seems this may not be the right place to sort out this issue, as this particular situation is not one that that datawire ecosystem has needed to deal with :(

    Richard Li
    @richarddli
    OK, let me try to answer this in a couple parts
    1. Forge itself is completely language agnostic. Forge creates a language abstraction via Docker. So you can build a microservice in any language, create a Dockerfile, and then build a container containing that language and all the necessary runtimes.
    omnilinguist
    @omnilinguist
    yeah #1 makes sense to me
    Richard Li
    @richarddli
    1. I'm not super-familiar with supervisord but the docs reference DJB's daemontools which I'm familiar with. My thought on your py3 problem is that if you're writing a net-new microservice, you can build it in Py3, and adopt a different mechanism for supervisord that is Py3 compatible.
    And your existing services that run on Py2 can stick with Py2
    Because philosophically, we recommend a microservices migration to think about "append-only" versus "refactor/rewrite"
    since that tends to be really time consuming
    omnilinguist
    @omnilinguist
    ah ok to shed a bit more light
    Richard Li
    @richarddli
    so we'd pick a new feature that you have on your roadmap, implement it as an independent API service in Py3, and then have your existing services talk to the new service via that API
    omnilinguist
    @omnilinguist
    i was basically considering figuring that out if possible, or go the unfortunate route of continuing to have new ms use py2 due to the supervisord dependency
    or, i guess, delay the py2 => py3 prescription for MS default until a suitable py3 equivalent can be figured out
    Richard Li
    @richarddli
    sounds like you have two choices 1) py2+supervisord for new services or 2) py3+something else for process management
    and i think the answer is how much infra do you have around supervisord
    Rafael Schloming
    @rhs
    hmm, I'm not sure how to interpret that thread
    is there some reason you can't simply have python2 and python3 installed on the same system and user supervisord to manage a process that is written in python3?
    omnilinguist
    @omnilinguist
    hm, that may be possible, would need to look into it
    omnilinguist
    @omnilinguist
    alright, i now believe this issue is outside the datawire's primary scope. i will sort it out
    omnilinguist
    @omnilinguist
    at approximately what scale do most people migrate to multi-master k8s clusters? it seems like these have higher maintenance overhead
    Richard Li
    @richarddli
    i think if you need availability you'll probably want a multi-master, because if a master goes down, you have problems.
    (in the single master scenario)
    just saw that in my linkedin feed
    Richard Li
    @richarddli
    Not sure exactly what they are doing other than random interesting? Projects