<div dir="ltr"><div>That would be really nice indeed ! <br></div>But are the markers files not enough, instead of also having a table in the DB ?<br> <br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 9, 2015 at 1:20 PM, Stian Thorgersen <span dir="ltr"><<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Currently we support importing a complete realm definition using the import/export feature. Issues with the current approach is:<div><br></div><div>* Only complete realm - not possible to add to an existing realm</div><div>* No good feedback if import was successful or not</div><div>* Use of system properties to initiate the import is not very user friendly</div><div>* Not very elegant for provisioning. For example a Docker image that want's to bundle some initial setup ends up always running the import of a realm, which is skipped if realm exists</div><div><br></div><div>To solve this I've come up with the following proposal:</div><div><br></div><div>Allow dropping representations to be imported into 'standalone/import'. This should support creating a new realm as well as importing into an existing realm. When importing into an existing realm we will have an import strategy that is used to configure what happens if a resource exists (user, role, identity provider, user federtation provider). The import strategies are:</div><div><br></div><div>* Skip - existing resources are skipped,</div><div>* Fail - if any resource exists nothing is imported</div><div>* Overwrite - any existing resources are deleted.</div><div><br></div><div>The directory will be scanned at startup, but there will also be an option to monitor this directory at runtime.</div><div><br></div><div>To prevent a file being imported multiple times (also to make sure only one node in a cluster imports) we will have a table in the database that contains what files was imported, from what node, date and result (including a list of what resources where imported, which was not, and stack trace if applicable). The primary key will be the checksum of the file. We will also add marker files (<json file>.imported or <json file>.failed). The contents of the marker files will be a json object with date imported, outcome (including stack trace if applicable) as well as a complete list of what resources was successfully imported, what where not.</div><div><br></div><div>The files will also allow resolving system properties and environment variables. For example:</div><div><br></div><div>{</div><div> "secret": "${env.MYCLIENT_SECRET}"</div><div>}</div><div><br></div><div>This will be very convenient for example with Docker as it would be very easy to create a Docker image that extends ours to add a few clients and users.</div><div><br></div><div>It will also be convenient for examples as it will make it possible to add the required clients and users to an existing realm.</div><div><br></div><div><br></div></div>
<br>_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br></blockquote></div><br></div>