openflagr / flagr-archived Goto Github PK

Any plans to support an image for arm?
I tried building it myself but frolvlad/alpine-glibc doesn't have support for arm images.

I tried replacing to similar images:
pingcap/alpine-glibc:alpine-3.14.3
zjingjie/alpine-glibc:alpine-3.10-arm64

The build works but there is a dependency missing:

/go/src/github.com/openflagr/flagr # ldd ./flagr
	/lib/ld-linux-aarch64.so.1 (0xffffb0e95000)
	libpthread.so.0 => /lib/ld-linux-aarch64.so.1 (0xffffb0e95000)
	libdl.so.2 => /lib/ld-linux-aarch64.so.1 (0xffffb0e95000)
	libc.so.6 => /lib/ld-linux-aarch64.so.1 (0xffffb0e95000)
Error relocating ./flagr: fcntl64: symbol not found

Any help would be much appreciated

Expected Behavior

Current Behavior

Possible Solution

Steps to Reproduce (for bugs)

Context

Your Environment

• Version used (flagr version):
• Server type and version:
• Operating System and version (uname -a):
• Link to your project:

litefs is a golang lib that makes SQLite in a clustered HA solution.

https://github.com/superfly/litefs

Support is excellent also.

changes to code base will be minimal because it runs along side the normal code.

Related issue: openflagr/flagr#440

@juanantoniocid

When we have a flag with several segments and we evaluate it, if no segment matches the constraints Flagr will return the latest segmentID instead of returning no segmentID.

Expected Behavior

If I have a flag with two segments, both of them with a specific constraint, and I evaluate a request whose value doesn't match any segment constraint, I want to get no segmentID.

Current Behavior

If I have a flag with two segments, both of them with a specific constraint, and I evaluate a request whose value doesn't match any segment constraint, I get the latest segmentID. But as expected, I get no variantID as nothing matched.

Possible Solution

Steps to Reproduce (for bugs)

1. Go to try-flagr.herokuapp.com

2. Create a new flag: i.e. "Returning invalid latest constraint".

3. Enable it.

4. Create "chocolate" and "cream" variants.

5. Create "Segment Spain" segment with 100% of rollout.

   • Add it the constraint country == "ES".
   • Create a distribution of 50/50 for it.

6. Create "Segment France" segment with 100% of rollout.

   • Add it the constraint country == "FR".
   • Create a distribution of 50/50 for it.

7. At the bottom of the page in "Debug Console" entry, set the entityContex value to "entityContext": { "country": "US" }.

8. Click in "POST /api/v1/evaluation" button and check the response.

   • Expected: No segmentID should be returned.
   • Actual: segmentID 3 is returned.

Context

Some teams were having problems because they got a segmentID for calls that were not matching any segment. We had to add a new segment, the last one, as a catch-all to handle it.

Your Environment

• I have checked it directly in try-flagr.herokuapp.com, version v1.1.12 on 2021-04-29.

TODO

Quite a lot of nice features and ctx support from gorm v2.

https://github.com/go-gorm/gorm/wiki/GORM-V2-Release-Note-Draft

There is a bunch of vulnerabilities in many of the node modules in browser/flagr-ui/package-lock.json

Expected Behavior

Dependabot vulnerability scanning is turned on, making it easier to manage

Current Behavior

Currently vulnerabilities in node and go package dependencies are not fixed.

Possible Solutions

1. We could open PR's for all of them, but i think its easier if dependabot does that.
2. Diverge our fork (which is not preferable)

Steps to Reproduce (for bugs)

1. Fork this repository
2. Enable dependabot vulnerability scanning
3. See the PR's created and the dependabot alerts

Context

1. Some of those vulnerbilities might be subject to real security concerns.
2. For enterprises that are under security compliance, its a benefit to have as many vulnerabilities fixed as possible.

Right now the closest thing we can get is setting FLAGR_DB_DBDRIVER=json_file, maybe we can extend the file support to other formats like YAML or TOML.

• support YAML
• support TOML
• support file validation
• support int id generation (or keep int id out-of-the-loop) if a file is used

It would be beneficial to implement a Flagr Client for .NET (probably in .NET Standard). Ideally, the repo would live here.

Expected Behavior

.NET Repo for Flagr exists in Openflagr org

Current Behavior

Does not exist

Possible Solution

Create the repo

Steps to Reproduce (for bugs)

N/a

Context

I made my own Flagr implementation, then realized this is all open source. Giving back to the community is create, so putting a client out there for us is even better under the openflagr name, instead of just my little user.

Your Environment

N/a

Related issue: openflagr/flagr#463

@fenriskiba

Evaluations sent through the Kafka Recorder are getting duplicated intermittently.

Expected Behavior

Each evaluation should have a single message sent to Kafka.

Current Behavior

Approximately 0.65% (sampled from roughly 6 million Kafka messages) of evaluations are recorded to Kafka 2 or more times.

Steps to Reproduce (for bugs)

1. Use Vegeta to produce about 2000 evaluations per second with randomly generated entity IDs for about 15 minutes
2. Use the Sarama example apps (with some minor formatting adjustments) to consume the generated messages in Kafka and pipe the results into a CSV
3. Identified multiple identical payload messages in the CSV

Context

Creates some confusion/misleading conclusions if someone doesn't know to dedup data when doing analysis on an AB Test.

Your Environment

• Flagr v1.1.12
• Kafka v2.3.1

Related issue: openflagr/flagr#438

@SaxJ

Hello. This is my first contribution to this project, and I thought I'll post a feature request here, and see if there is any interest in this idea before I go opening a PR. :)

Description

Different tags have different colours in the Flagr UI. This would be purely a Flagr UI change.

Why

A small quality of life improvement. Different tags colours allow a user to more easily see what flags have what tags when scanning through the tag list.

• It should support auto generation of the swagger YAML files
• It should support the CI/CD of their own integration tests

The uniqueness constraint of flag.key is a known part of flag. Validation errors that rely on client-logic (uniqueness of a field) is responsibility of the client to implement, thus the server should return a 400-ish (e.g.: 400 Bad Request, 406 Not Acceptable, ...) and not a 500 Internal Server Error, since that is not the case.

Using httpie to exemplify:

http POST :18000/api/v1/flags Description=Sweden key=SE

HTTP/1.1 200 OK
Content-Type: application/json

{
    "dataRecordsEnabled": false,
    "description": "Sweden",
    "enabled": false,
    "id": 4,
    "key": "SE",
    "segments": [],
    "tags": [],
    "updatedAt": "2021-10-02T16:41:28.191Z",
    "variants": []
}

If you try that again, you should get something like...

Expected Behavior

http POST :18000/api/v1/flags Description=Sweden key=SE
HTTP/1.1 400 Bad Request
Content-Type: application/json

{
    "message": "cannot create flag. a flag with key=SE already exists"
}

But you end up getting a 500:

Current Behavior

http POST :18000/api/v1/flags Description=Sweden key=SE
HTTP/1.1 500 Internal Server Error
Content-Type: application/json

{
    "message": "cannot create flag. UNIQUE constraint failed: flags.key"
}

Possible Solution

Intercept this uniqueness constraint error and fail gracefully

Steps to Reproduce (for bugs)

See above...

Context

Semantically, validations errors should be client errors, 400-ish, since the server doesn't fail, yet the client fails on trying to bypass the uniqueness of the field.

Your Environment

• Version used (flagr version): 1.1.13
• Server type and version: docker/macOS Big Sur 11.6 (20G165)
• Operating System and version (uname -a): Helsinki.local 20.6.0 Darwin Kernel Version 20.6.0: Mon Aug 30 06:12:21 PDT 2021; root:xnu-7195.141.6~3/RELEASE_X86_64 x86_64

Expected Behavior

Current Behavior

Possible Solution

Steps to Reproduce (for bugs)

Context

Your Environment

• Version used (flagr version):
• Server type and version:
• Operating System and version (uname -a):
• Link to your project:

Nats is a replacement for Kafka.
Is all golang
Supports clusters.

Currently, when we cut a new release, we need to follow these steps:

• Update browser/flagr-ui/package.json with the new version bump
• Update browser/flagr-ui/package-lock.json with the new version bump
• Update swagger/index.yaml with the new version
• Run make gen to update all the generated files (e.g. swagger_gen/*, docs/api_docs/*)

Updating enabled attribute through PUT /api/v1/flag/$id does NOT work.

It does not respect the flagr API definition:
https://github.com/openflagr/goflagr/blob/e97f63ad2c236783d4afa2f9f630c2aeb53a042d/model_put_flag_request.go#L12

For instance, creating a flag:

http POST :18000/api/v1/flags Description=Germany
HTTP/1.1 200 OK
Content-Type: application/json

{
    "dataRecordsEnabled": false,
    "description": "Germany",
    "enabled": false,
    "id": 8,
    "key": "kt8kfh38c19uqaeo3",
    "segments": [],
    "tags": [],
    "updatedAt": "2021-10-04T19:52:41.676Z",
    "variants": []
}

Notice the ID is 8 and the flag is disabled...

If one tries to edit enabled:

Expected Behavior

echo "{\"enabled\": true}" | http PUT :18000/api/v1/flags/8
HTTP/1.1 200 OK
Content-Type: application/json

{
    "dataRecordsEnabled": false,
    "description": "Deutschland",
    "enabled": true,
    "id": 8,
    "key": "kt8kfh38c19uqaeo3",
    "segments": [],
    "tags": [],
    "updatedAt": "2021-10-04T19:54:35.206Z",
    "variants": []
}

It doesn't do anything really...

Current Behavior

echo "{\"enabled\": true}" | http PUT :18000/api/v1/flags/8
HTTP/1.1 200 OK
Content-Type: application/json

{
    "dataRecordsEnabled": false,
    "description": "Deutschland",
    "enabled": false,
    "id": 8,
    "key": "kt8kfh38c19uqaeo3",
    "segments": [],
    "tags": [],
    "updatedAt": "2021-10-04T19:54:35.206Z",
    "variants": []
}

Possible Solution

Add the field here, similar to DataRecordsEnabled?
https://github.com/openflagr/flagr/blob/f6a8dd233467c793055ece212e9eb05610b9d0c3/pkg/handler/crud.go#L218-L220

Steps to Reproduce (for bugs)

See above

Your Environment

• Version used (flagr version): 1.1.13

Related issue: openflagr/flagr#417

@Zoltberg63

Hello.
Is it possible to add a property check to null?
Something like this:

Expected Behavior

DB Connection Fails after a period of time

DB connection should reset or application should be marked as failed.

Current Behavior

Currently we have flagr deployed to kubernetes cluster and connected to an Azure hosted postgres installation, will occasionally have connection issues with this message being shown:

{message: "cannot query all flags. write tcp 192.168.8.189:45216->172.21.56.12:5432: write: connection reset by peer"}

Once the container is restarted the connection is restored.

Possible Solution

Health check doesn't take into consideration this error and shows green status. If this error is known during health check I could restart the service

Your Environment

• v1.1.13

Related issue: openflagr/flagr#424

@cszczepaniak

Flag keys can be changed from the generated key to have a descriptive name. It would be nice to show the key in the UI.

Expected Behavior

Flag key should be displayed next to description.

Current Behavior

Flag key is not shown in the list of flags. Only description is shown.

Happy to do this work if you think it's worth adding.

Currently in order to reorder segments, one has to drag and drop the segment around. It's not a good UI experience, especially when there are a lot of segments in a flag.

Wondering if we can have "up"/"down" buttons inside each segment so that reordering can be more intuitive.

Related issue: openflagr/flagr#430

@vodzak

Expected Behavior

When calling the API with a flag ID and a variant, segment, etc. that does not exist on that flag, an error is returned and no action is taken.

Expect response similar to the error response given when PUT /flags/{flagID}/segments/{segmentID}/distributions is called with a variant that is not on the flag. The error that's returned is "message": "status_code: 400. error finding variantID 1 under this flag. expecting [4 5]".

Current Behavior

Currently, the API allows changes to elements that do not exist on the specified flag and no response is returned.

Steps to Reproduce

API calls that don't return an error and the action is taken:

• DELETE /flags/{flagID}/variants/{variantID}

  • where variantID is not on the flag

• DELETE /flags/{flagID}/segments/{segmentID}

  • where segmentID is not on the flag

• DELETE /flags/{flagID}/segments/{segmentID}/constraints/{constraintID}

  • where segmentID is on the flag, but constraintID is not
  • where segmentID and the constraintID are not on the flag

• POST /flags/{flagID}/segments/{segmentID}/constraints

  • where segmentID is not on the flag

• PUT /flags/{flagID}/segments/{segmentID}/distributions

  • where segmentID is not on the flag, and variantID in body is not on the flag

Your Environment

• Version 1.1.12 hosted in Red Hat OpenShift.

Teams need more visibility into how and when flags are updated. For example, Email or Slack notifications can be good channels.

Not sure if this feature is a good addon to the current Flagr setup. Maybe we can build it in Flagr, maybe we can expose Flagr webhooks and let other applications implement it.