Yes I'm fine with you proceeding with flipt.io while getting feedback I think any 'wasted' implementation will likely be minimal since this is a pluggable architecture and anything you lean while trying to implement will likely be of much greater value than any time lost to rework that might come up.

@e_forbes my primary feedback here is that we try and keep decisions flexible for new choices in the future and focus on things we absolutely need today. Anything we do should integrate easily into caproni and local development, I don't want to do anything that would make using LaunchDarkly a hard no but I feel like a simple self-hosted solution that we can start using in dev on day 1 would fit better.

You seem to have several good options that I suspect will work and all should meet our flexibility due to the OpenFeature foundation. Flipt from your chart above seems very reasonable at first glance to me.

@e_forbes Last I heard 'on/off' was sufficient for AR likely all the way to GA. Unless they have a driving need for something more complicated, I'm only hesitant to add friction for something we don't yet understand the full use case for. For example, LaunchDarkly wouldn't be used for Dev/CI right? This is just to enable production flagging (so dotcom only)?

I would tend to lean toward something a bit more light weight (flagd for example) that we could run in dev/ci/staging and production and if we find that we want something much more complete and turn key in production we could then switch to it specifically for production. But I don't feel strongly about this if you see a good reason for LaunchDarkly and can address how we cover dev through production I'm open to reviewing it and the costs.

Chris Sanders (fa19fde1) at 12 Mar 18:21

I want to caution us against reaching for bash scripts to wrap kubectl for configuration. If this is simply what's available right now to unblock and move forward I understand we'll need some of that. However, if that is the case do we have some discussions across teams about how to better handle this sort of configuration? Bash scripts ultimately don't scale from dev to ci and various production environments and that is our ultimate goal across the platform.

As an example of a solution (that is not complete): https://gitlab.com/gitlab-com/gl-infra/platform/runway/runwayctl/-/blob/feat/gitlab-chart-generation/deploy-test/README.md?ref_type=heads

In this setup there are no bash scripts or kubectl commands to scrape secrets and pass them into other services. The caproni.yaml file is very simple: https://gitlab.com/gitlab-com/gl-infra/platform/runway/runwayctl/-/blob/feat/gitlab-chart-generation/deploy-test/caproni.yaml?ref_type=heads

An environment.yaml specifies the databases and other external dependencies: https://gitlab.com/gitlab-com/gl-infra/platform/runway/runwayctl/-/blob/feat/gitlab-chart-generation/deploy-test/runway/environment.yaml?ref_type=heads

Ultimately a helmfile sync command is sufficient to stand up the local environment. That file is not checked in you would have to run it yourself to generate it and see that in action. Again this is not a complete implementaiton it's exploratory to help communicate the concepts.

Importantly this could be moved from bitnami to CNPG by editing only the environment file and not needing to find and update bash scripts with kubectl exec commands.

@fforster understanding how we enable this caproni->ci->self-manged->dedicated->dotcom flow without manual bash scripts is, to me, one of the biggest wins we could achieve with self managed runway.

@fforster the automatic summary picks up this task and lists it as blocking AWS adoption (https://gitlab.com/groups/gitlab-operating-model/-/epics/685#note_3136536930). I was under the impression this work was specifically in support of addressing self-managed. Can you clarify for me which is true?

The documents state the gRPC support does work in AWS but maybe I'm missing a detail here.

@jdrpereira, yes that was my intention too. @amyphillips is organizing an initial discussion with our team this week.

Chris Sanders (f4a8960a) at 25 Feb 23:00

I think we should expand our expectations for Caproni to be the development environment for Cloud Native and Modular Feature development, including OAK scenarios.

From my perspective, there shouldn't be a meaningful difference for a Modular Feature talking to the monolith whether those services are running in or outside of Kubernetes. If we need to support both patterns (and I believe we do), Caproni should be able to provide that in the development environment since it's something any Cloud Native / Modular feature would need to develop and test against.

The first implementation may require some manual steps in a Readme to prove out the concept, but the end state I'm envisioning is that Caproni automates this so developers have a spec to test/develop against Omnibus, confirm how their OAK support works, and catch edge cases.

To your point that "Caproni is not focused on replicating the OAK deployment environment" I'd actually push us toward not thinking of OAK as a separate deployment environment at all. If OAK is a Kubernetes environment with Omnibus configuration and routing, that should be a configuration of the same environment, not a distinct one. I recognize the routing differences you raised (Omnibus NGINX as entrypoint, cluster node exposure) are real details we'll need to work through, and your experience building against these patterns will be valuable as we figure out the right abstractions. But architecturally, I want us heading toward one environment that can represent multiple configurations rather than multiple environments.

Is there anything blocking you or feeling awkward in Caproni today when you think about OAK scenarios?

Is the goal here specifically to develop with Rails running outside of Kubernetes and Container Registry inside Kubernetes? Otherwise why not just use Caproni with everything running in Kubernetes?

The idea was it should work both ways, I think Rails outside of k8s is likely to provide the most surprise edge cases.

If running the monolith outside is a hard requirement, then we should consider running GDK + Caproni for Container Registry only.

That's an option, but long term I'd like to see if we can just use Caproni when a Modular service wants to develop and test against Rails in/out of K8s. I'm only a little concerned if we start with GDK we'll fall into a habit of expanding GDK and I'd like to not do that.