Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation: add doc describing v2 changes #664

Merged
merged 1 commit into from
Nov 5, 2016

Conversation

ericchiang
Copy link
Contributor

@ericchiang ericchiang commented Nov 3, 2016

updates #655

(still need to do an update to the README)

cc @ElijahCaine

Copy link
Contributor

@pop pop left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @ericchiang This looks really good. I've got some flow suggestions, but all the content is solid.


## More storage backends

Dex's internal storage interface has been cleaned up and simplified, allowing dex to use more backing databases to store its state. A notable addition uses the Kubernetes API (a key value store) to store state, allowing dex to run natively on top of Kubernetes clusters.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would reword this section to be as follows:

Dex's internal storage interface has been improved to support multiple backing databases including Postgres, SQLite3, and the Kubernetes API. The Kubernetes API, a [key value store][link-to-k8s-api-docs], allows dex to be run natively on top of a Kubernetes cluster. Starting with support for multiple storage backends should ensure that the Dex storage interface is actually pluggable.

A more in depth discussion on existing storage options and how to add new ones can be found in the [storage documentation][storage-docs].


## Rethinking registration

Dex v1 performed well when it could manage users. It provided features such as registration, email invites, password resets, administrative abilities, etc. However, login flows and APIs remain tightly coupled with concepts like registration and admin users even when v1 federated to an upstream identity provider (IDP) where it likely only had read only access.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[...] where it likely only had read access to the <name of thing it had read access to>.


## Removed features

It's important to note that dex v2 lacks certain features present in v1. For the most part __we aim at adding these features back into the project__, but in a way that installations have to opt into the additional configuration instead of making them on by default.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's important to note that Dex v2 lacks many features present in v1. We aim to add most of these features back into v2 in a way that forces installations to opt in to a feature instead of opt out as it was before.

Copy link
Contributor Author

@ericchiang ericchiang Nov 4, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there was no opt out before.

Going to go with

but in a way that installations have to opt in to a feature instead of burdening every deployment with extra configuration.

@ericchiang
Copy link
Contributor Author

@ElijahCaine thanks for the feedback! Updated and going to merge a little later.

@ericchiang ericchiang merged commit 7f24ebb into dexidp:dev Nov 5, 2016
@ericchiang ericchiang deleted the dev-docs-v2 branch November 22, 2016 20:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants