How do I troubleshoot Repose?
Please read our Troubleshooting page.
Why use Repose’s Client Authentication as opposed to Keystone, Cloud Auth, or Global Auth?
Respose’s Client Authentication component can be used to interface with Keystone, Cloud Auth, or Global Auth. Since rate limiting requires identification, this would be a way to do both in one place. However, it’s a valid model to authenticate without Repose, as long as the request headers passed to the Rate Limiting component adhere to the Rate Limiting contract.
The client authentication service filter enables the origin service to communicate with the authentication service implemented in its environment. It accomplishes this by delegating authentication requests to the authentication service and returning the results of those requests to the origin service.
Currently, Repose's Authentication component interfaces with Cloud Auth 1.1.
Repose's Authentication component also interfaces with Cloud Auth 2.0, which implements Keystone's Core API and some extensions (KSKEY, KSGRP, KSQA). There are a few Keystone calls not implemented in Cloud Auth 2.0, and a 501 HTTP status ('not implemented') will be returned. The contract is always followed, though Cloud Auth 2.0 could have some subtle functional differences from the Keystone base implementation.
Can I control the configuration via API calls rather than setting config files?
This is a backlog item that is not yet implemented.
Why use Repose’s Versioning component as opposed to versioning that is supported by the servlet container (e.g. Glassfish, Tomcat)?
Repose offers some features that servlet containers may not offer. For example: Repose supports permalinks in a cross-platform manner. Repose also supports describing and identifying versions (you can request a list of available versions or you can request a description of a single version). Repose’s versioning system operates at the proxy level, so versions can be deployed on separate boxes for better scalability and environment isolation.
How does rate limiting work when a user belongs to multiple groups?
Currently, the user will be rate-limited based on the first group they belong to.
We may revisit this in the future to cover a use case where a service can set a config variable that defines whether this should be handled as first-found, most-inclusive, most-restrictive, etc.
Does Repose provide load balancing functionality?
No. It assumes statelessness. However, we will consider a solution for load balancing.
Are you passing SWIFT objects?
Initially, Repose's focus is control APIs, not data APIs. We will add this to our backlog and consider our options. Feedback is welcome.
What other options did you consider? For example, HA Proxy or Zeus.
Yes. We considered varnish, yahoo traffic server and squid and service mix and mule.
Will this be a part of OpenStack?
Maybe. Our initial focus is to open source (available at github.com/rackerlabs/repose) our code. We will consider whether or not it makes sense to include with OS.
We started this project before the advent of OpenStack and the team tasked with the solution had experience in Java. With our implementation, we do want to provide multi-language support and that is in our backlog.
Is it a reverse proxy or a proxy?
Reverse proxy as it is focused on the service, not the client. Requests are sent to the proxy, not the server that the service lives on.
Do you publish the results of your SONAR analysis?
Yes. Here: http://184.108.40.206/dashboard/index/2122
With headers, is it acting like a true proxy (reverse proxy)?
How can I log my transaction information from Repose to Origin Service?