Questions/issues in using overrides

[vchan2002]

I am in the midst of testing overrides on 1.5.2, and I am running into issues where my attempts to do manual overrides are not working... I'm thinking of a use case where, rather than using the auto-discovery feature, I can have different fabio servers that will read from different consul k/vs on the same cluster, so each fabio picks up its own set of unique routes.....

a. If I tried to enter a override in the consul k/v of fabio/config (where I have it set as default)... it does not appear to do anything.....

My route overrides were going to be very simple... I tried two use cases. Neither does anything.

1. I have auto discovery find all routes, then I add an route del {servicename}
2. I turned off auto discovery by not adding the tags to the service, then I tried to do an route add {servicename} {path}

b. If I tried to enter in a override in the GUI, it complains on a server error, and a corresponding 403

Looking at the logs from Fabio. The 1st one is when I updated the consul k/v. It seemed to have acknowledged my k/v update, but it didn't do anything.

The 2nd one corresponds to the internal server error prompt that I get. As you see, it complains of a 403.

I'm still new on using Fabio, so any guidance on it would be much appreciated.

2017/10/13 16:50:25 [INFO] consul: Manual config changed to #26493793
2017/10/13 16:50:43 [ERROR] Unexpected response code: 403 (rpc error: rpc error: Permission denied)

[vchan2002]

Ok.... after going a bit further.... it's a consul ACL issue where I have my k/v s set to default deny with the anonymous token.... So I imagine either adding an ACL to the consul agent where fabio runs, or relaxing the ACL for the anon token, is an option....

It is interesting, however, that the 403 error only occurs if you tried to enter the override from the GUI, as it tries to write to the KV. However, it does not complain when it, at 1st, cannot read from the k/v.

Given that.... i am still trying the use case of basically having it add a service without doing a prefix tagging.... so I tried something like this on the config, where I want it to automatically find the service and route it to the destination, and now it is complaining that the syntax is invalid.

Is such a config currently supported?

route add {service} {path}

[magiconair]

You can have Fabio talk to a specific consul cluster or use different tag prefixes to separate name spaces. Can you explain more what you’re trying to do? My gut feel tells me that you’re trying to do smth that fabio wasn’t designed for. The auto-discovery is the whole point of its existence.

[vchan2002]

While I personally agree that the automatic discovery is the best way to go, my use case is that I will get pushback from other stakeholders of the different microservices that they may not want to 'share' the same set of fabio services for load balancing, while still using the same consul cluster for discovery.

I think the best workaround, in this case, is to use separate consul clusters just for that seperation.... But I was just wondering whether my use case is unique.. apparently it is....

[magiconair]

I think you can use different tag prefixes for that. fabio-a[123] uses tag.prefix `a-` instead of `urlprefix-`, fabio-b[123] uses `b-` and so forth. This way multiple fabio clusters can share the same consul server cluster. The services then need to register `a-/foo` and `b-/bar`. You still need to route inbound traffic to them though. Frank Schröder

…

On 16. Oct 2017, at 18:35, Victor Chan ***@***.***> wrote: While I personally agree that the automatic discovery is the best way to go, my use case is that I will get pushback from other stakeholders of the microservices that they may not want to 'share' the same set of fabio services for load balancing, while still using the same consul cluster for discovery. I think the best workaround, in this case, is to use seperate consul clusters just for that seperation.... But I was just wondering whether my use case is unique.. apparently it is.... — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[vchan2002]

Oh yeah... that's right... I see that it is something you can setup in fabio.properties.... I did not think about utilizing that.

That would definitely satisfy the use case that I have......