UNLEASH EDGE DAISY CHAIN ISSUE #463
Comments
|
I moved this issue to Unleash-edge rather than the Unleash repo. I can confirm this is correct. This is due to supporting multiple types of tokens, when Edge in offline mode is the endpoint for validating a token, it does not return the token type, and as such edge in daisy chain mode with the offline node as the terminus does not know that it can use the token (which was validated) to sync features. It relates back to being able to define both client and frontend tokens for edge in offline mode. |
|
An initial solution here would be to go into the validator endpoint and if we have no validator, assume all tokens we know about are client tokens. That would solve this for the short term, but would make it even harder to deal with ways of adding both client and frontend tokens to offline mode. |
|
I think the best approach here is to add |
|
@pi194046 Can I ask what you're trying to do here? To be honest, at the moment I'm leaning towards making daisy chaining against an offline instance an explicit failure rather |
|
I agree with @sighphyre here. I do not understand the use-case to daisy chain in offline mode, you should rather just horizontally chain. |
|
Hi,
Since edge instances is a high throughput instance , user case was that any
confirmation chain would be realized in offline mode
Editing the file via config map in Kubernetes gets reflected across all
other instances.
manually editing via UI or API in a containerized production environment
always poses a risk
and the idea was to have version-controlled files that could be served via
the offline instance without the requirement of unleash server
in production environment
Thanks and Regards,
Prashant Iyengar
Co-Founder/CTO Miko .
The information contained in this communication is intended solely for the
use of the individual or entity to whom it is addressed and others
authorized to receive it. It may contain confidential or legally privileged
information. If you are not the intended recipient you are hereby notified
that any disclosure, copying, distribution or taking any action in reliance
on the contents of this information is strictly prohibited and may be
unlawful. If you have received this communication in error, please notify
us immediately by responding to this email and then delete it from your
system. The recipient acknowledges that the views, opinions, conclusions
and other information expressed in this message are those of the individual
sender and shall be understood as neither given nor endorsed by RN
Chidakashi Technologies Pvt. Ltd., unless the sender does so expressly
with due authority of RN Chidakashi Technologies Pvt. Ltd. and RN
Chidakashi Technologies Pvt. Ltd. shall not be liable for any errors or
omissions in the context of this message. We are neither liable for the
proper and complete transmission of the information contained in this
communication nor for any delay in its receipt.
…On Thu, May 16, 2024 at 12:11 PM Ivar Conradi Østhus < ***@***.***> wrote:
I agree with @sighphyre <https://github.com/sighphyre> here. I do not
understand the use-case to daisy chain in offline mode, you should rather
just horizontally chain.
—
Reply to this email directly, view it on GitHub
<#463 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AO7DF5K62URPKPQFZFFELUDZCRIIPAVCNFSM6AAAAABHYD2SAWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJUGE3DENRQHE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Okay I think what you're trying to do make a lot of sense but I don't think daisy chaining Edge instances against an offline instance is the best way to solve that. Offline Edge has a lot of limitations with the way it handles tokens and responses, even without the limitation you're raising here. My suggestion would probably be to run all the Edge instances you need in offline mode and rather distribute the file you need to each of those instances |
Describe the bug
i created a unleash edge running in offline mode at port 3064
I created a unleash edge running in edge mode at port 3063 pointing to uleash edge offline instance port 3064
when I testing using the token and curl request , I am able to successfully make the API call on offline instance at port 3064 but using the same token on port 3063 is giving 403 Forbidden ie token is invalid
If I use the same approach and have unleash server running at port 4242, and I create a unleash edge running in edge mode at pointing to unleash server then the curl request is successful at both 4242 and port 3063
I had used the same token created on unleash server while configuring the unleash offline instance
Steps to reproduce the bug
Run the below command in one terminal
docker run --rm -e RUST_LOG="trace,unleash_edge=trace" -v
pwd/config:/tmp/config -p 3064:3063 unleashorg/unleash-edge offline -b /tmp/config/a.file -r 2 -t 'default:development.40df9a2423b500ad80b53f3f97153af8f6768df483e09aa712345678'please the a.file in the location in the config folder in the current directory
Run the below command in another terminal
docker run -p 3063:3063 -e RUST_LOG="trace,unleash_edge=trace" --rm unleashorg/unleash-edge edge -u http://your-domain.com:3064 -t 'default:development.40df9a2423b500ad80b53f3f97153af8f6768df483e09aa712345678' -f 10 --token-revalidation-interval-seconds 10
the below call is successful
curl -X GET http://your-domain.com:3064/api/client/features -H 'Accept: application/json' -H 'Authorization: default:development.40df9a2423b500ad80b53f3f97153af8f6768df483e09aa712345678' -v
the below call is a failure
curl -X GET http://your-domain.com:3063/api/client/features -H 'Accept: application/json' -H 'Authorization: default:development.40df9a2423b500ad80b53f3f97153af8f6768df483e09aa712345678' -v
Expected behavior
daily chaining unleash edge instances with edge instances pointing to an offline instance should work properly
Logs, error output, etc.
No response
Screenshots
No response
Additional context
No response
Unleash version
No response
Subscription type
None
Hosting type
Self-hosted
SDK information (language and version)
No response
The text was updated successfully, but these errors were encountered: