optimizely / agent Goto Github PK

I'm on macOS 10.15.7. I installed Golang version 1.16, cloned the repo, cd'ed into the directory and ran "make setup". I got the following:

mbp2a95:agent kbecker$ make setup
golangci/golangci-lint info checking GitHub for tag 'v1.19.0'
golangci/golangci-lint info found version: 1.19.0 for v1.19.0/darwin/amd64
golangci/golangci-lint info installed /Users/kbecker/go/bin/golangci-lint
go: downloading github.com/rakyll/statik v0.1.7
"# runtime/cgo"
In file included from cgo-builtin-prolog:1:
/usr/local/include/stddef.h:40:10: fatal error: '__config' file not found
#include <__config>
^~~~~~~~~~
1 error generated.
make: *** [setup] Error 2

Does anyone know how to solve this issue? (I added quotes around the runtime/cgo line to prevent the formatting)

Kubernetes deployments of this agent should be a major use-case. Many similar open-source tools maintain a well documented Helm Chart that simplifies this process.

https://github.com/helm/charts/tree/master/stable

Getting a bare bones v0.1 into the incubator would help to encourage community contributions. I'm personally expecting to use this workflow to deploy out the agent within the next few weeks, I'd love to have a template to work from and contribute my modifications back.

https://github.com/helm/charts/tree/master/incubator

Is there an existing issue for this?

• I have searched the existing issues

Agent Version

2.7.0

Current Behavior

After an instance of PollingProjectConfigManager suffers a 403 error, the Agent will not be able to identify, nor recover from this bad state.

Expected Behavior

The Agent could identify and try a new authentication, or kill itself.

Steps To Reproduce

1. Begin by initializing the Agent with the correct SDK configurations.
2. Allow a few minutes for the PollingProjectConfigManager.SyncConfig() function to ensure that it successfully retrieves valid data.
3. In the Optimazelhy servers (recognizing that this scenario may be challenging to replicate but has occurred in a production environment), intentionally invalidate the Token associated with this specific Agent. Consequently, the Optimazely server will start returning HTTP 403 (Forbidden) responses for every subsequent attempt to execute PollingProjectConfigManager.SyncConfig().
4. At this stage, it's important to note that the Agent will be unable to retrieve new data, and recovery from this situation will be difficult or impossible.

Go Version

1.18

Link

No response

Logs

No response

Severity

Affecting users

Workaround/Solution

After we identify the error, we can restart the Agent to force a new authentication.

Recent Change

No response

Conflicts

No response

There is an issue with authentification using Issuer & Validator scheme since version 2.0.0

Issue description:
oauth/token endpoint is expecting Content-Type: application/json here, but auth service is expecting Content-Type: application/x-www-form-urlencoded here

To reproduce:

1. Not passing Context-Type header => returns 415 error code

#!/usr/bin/python3

import json
import requests
import sys

s = requests.Session()
s.headers.update({'X-Optimizely-SDK-Key': "mySDKkey"})

resp = s.post('http://localhost:8080/oauth/token', data={
    "grant_type": "client_credentials",
    "client_id":  "myclientID",
    "client_secret": "myclientSecret",
})

print(resp)

2. Passing Context-Type: application/json header => returns 400 error code

#!/usr/bin/python3

import json
import requests
import sys

s = requests.Session()
s.headers.update({'X-Optimizely-SDK-Key': "mySDKkey"})
s.headers.update({'Content-Type': 'application/json'})

resp = s.post('http://localhost:8080/oauth/token', data={
    "grant_type": "client_credentials",
    "client_id":  "myclientID",
    "client_secret": "myclientSecret",
})

print(resp)

We are using a custom build image with a workaround of removing contentTypeMiddleware from here

Could this be looked into please? :)

https://github.com/optimizely/sidedoor/blob/dc178605aaced7ed18c7529e35b6642736e5af35/Makefile#L2

when homebrew installs sidedoor from source, it checks out the sidedoor repo into a temporary directory (eg. /private/tmp/homebrew20190904-7814-1yka1aj)

now the Makefile is broken because $TARGET is expected to be sidedoor when it is used here: https://github.com/optimizely/sidedoor/blob/master/Makefile#L28

not sure what doing $PWD is a shortcut for but hardcoding TARGET=sidedoor will avoid the issue im encountering

Hey team,
I was wondering when the next release of the agent is planned? My team is eager to adopt UPS integration that was added a part of this #326.

(Opening this as a new issue rather than piggybacking off #167, because I don't know if anyone from Optimizely is still following that thread)

Hey Optimizely folk,

This morning I threw together https://github.com/kieranajp/optimizely-agent-helm and used it to host the agent on my workplace's K8s cluster. We'll be starting using this in production in the coming days.

As there's clearly some interest in Helm support for this chart - #167, #265 (that happens to be from exactly a year ago!) - I thought to reach out in case you're interested in either transitioning the repository over to your org, or linking to it as an unofficial chart.

If you're interested, then feel free to test it and suggest any changes - it's very early days for it yet but I will be making improvements to both the chart itself and the docs as we battle-test it a little in-house.

$ helm repo add optimizely-agent https://kieranajp.github.io/optimizely-agent-helm
$ helm install --debug optimizely-agent optimizely-agent/optimizely-agent

Cheers,
--Kieran