[FLI-666] Add a new import flag to continue the import when an existing item is found

[jeremy-allocate]

Problem

When doing an import into an instance that has been imported into previously, you have to fully drop the DB with --drop to avoid conflicts. This is a painful, destructive step in that it also drops any API keys you've created, which then need to be recreated, resulting in a new value for the API key, which then needs to be updated in whatever clients communicate with this instance.

Ideal Solution

An "upsert" flag that causes the import process to update any existing flags/segments, and add new ones. This would override the default "error out on conflict" behavior and prevent the need to drop the DB before importing, thus eliminating the reason my local API key(s) get(s) wiped out when having to do an import.

Additional Context

I can't think of any additional context, but happy to answer any questions the team might have about this idea.

_FLI-666

[GeorgeMac]

Going to link in some comments from other issues, as we've danced around this idea a couple times.

• https://github.com/flipt-io/flipt/issues/1730#issuecomment-1598482037 (in particular the "Potential Future Changes For Flipt" section).
• https://github.com/flipt-io/flipt/issues/2086#issuecomment-1708802351 we talked about the benefits of having an idempotent, server-side implementation for import (currently it all works client side).

We also talked offline (or in a GH issue I cant remember where) with a user about the benefit of running imports server side. Having a more declarative, idempotent API for putting flag state would have benefits beyond just improving the import and export experience like you've described here. It could be leveraged by other automation and perhaps even provide an interface which could unify the relational backends with the filesystem ones.

For reference, the filesystem backends don't quite have this problem, because they depend on the import/export format as the source of truth and just track their state in Git or and object store (S3) https://www.flipt.io/docs/configuration/storage#filesystem. I don't know if these backends are suitable for your usecase in their current form.

Whats your goal @jeremy-allocate when you're importing and exporting flag state? e.g. are you:

• doing backup/restore process?
• replicating the state between different environments (e.g. prod <-> staging)?
• keeping the export format in version control?

[GeorgeMac]

I should've read your other issue first 😄 I see you've answered my question there.

https://github.com/flipt-io/flipt/issues/2113

I will write some suggestions in that issue for your consideration. As I think the local filesystem backend could be a perfect fit for your dev experience.

[phenax]

+1