Docker Protocol Implementation #3565

josh-cain · 2016-11-29T22:58:50Z

See KEYCLOAK-3592.

tronicum · 2016-12-24T05:29:40Z

That sounds great

mstruk · 2017-03-08T10:25:08Z

@cainj13, any suggestion what I might be doing wrong setting up client with docker-v2 protocol here?

stianst · 2017-03-20T08:05:28Z

Docs PR: keycloak/keycloak-documentation#55

josh-cain · 2017-03-20T13:44:53Z

@mstruk I think it's not set up for HTTP Basic auth. I tried to flesh the instructions out a little on the keycloak-documentation PR #55. Did that help at all?

mstruk · 2017-03-20T15:31:35Z

@cainj13 I'll try again, and let you know.

mstruk · 2017-03-22T13:22:12Z

@cainj13 I got it working, but I'm seeing some issues, so maybe I didn't configure everything properly. See here for how exactly I configured it.

The issue I'm seeing now is when I authenticate as a non-existing user. If user exists but the password is incorrect everything works correctly - the server returns 401 Unauthorized.
If user does not exist, however, the server return 500 Internal Server Error, and there is a stacktrace on the server:

10:11:54,509 WARN  [org.keycloak.services] (default task-41) KC-SERVICES0013: Failed authentication: org.keycloak.authentication.AuthenticationFlowException
	at org.keycloak.authentication.DefaultAuthenticationFlow.processResult(DefaultAuthenticationFlow.java:249)
	at org.keycloak.authentication.DefaultAuthenticationFlow.processFlow(DefaultAuthenticationFlow.java:192)
	at org.keycloak.authentication.AuthenticationProcessor.authenticateOnly(AuthenticationProcessor.java:792)

mstruk · 2017-03-22T13:30:08Z

...c/main/java/org/keycloak/protocol/saml/profile/ecp/authenticator/HttpBasicAuthenticator.java

@@ -52,17 +53,24 @@ public String getDisplayType() {

    @Override
    public String getReferenceCategory() {
-        return null;
+        return "basic";
    }



@stianst If HttpBasicAuthenticator is usable beyond saml ecp protocol I suggest we move it to authentication/authenticators/browser

I'd be down for that, but looking at the error responses, I need to make some updates to this MR. With the implementation we've got running, we're sending back JSON responses specific to the docker client for display back to the user. I suppose we'd want to do that as well here, but that's probably going to mean having a docker-specific HTTP Basic authenticator since we'll be crafting custom error responses. Any other way to do that?

No idea. But I don't think there's a problem with having docker specific HTTP Basic Authenticator. Maybe we should just call it DockerAuthenticator to avoid any confusion as to what it's there for.

Sounds good, will add

mstruk · 2017-03-22T13:48:00Z

themes/src/main/resources/theme/base/admin/resources/partials/client-detail.html

@@ -37,7 +37,7 @@
                </div>
                <kc-tooltip>{{:: 'client.enabled.tooltip' | translate}}</kc-tooltip>
            </div>
-            <div class="form-group clearfix block">
+            <div class="form-group clearfix block" data-ng-show="protocol != 'docker-v2'">
                <label class="col-md-2 control-label" for="consentRequired">{{:: 'consent-required' | translate}}</label>
                <div class="col-sm-6">
                    <input ng-model="clientEdit.consentRequired" name="consentRequired" id="consentRequired" onoffswitch on-text="{{:: 'onText' | translate}}" off-text="{{:: 'offText' | translate}}"/>


Is there a way to sort Client Protocol list for #protocol select input in such a way that docker-v2 is the last one in the list - it makes more sense for it to be the last choice as it's reasonable to expect that it will be the least used option?

I can certainly look. I'd agree that it's probably going to be the least-used option.

So I took a look at this - other than one-off hacking the order (which I don't think we wanna do), this would require a pretty broad change to the data model for the serverInfo's ProviderRepresentation. Right now angular is just doing a naive sort:

$scope.protocols = Object.keys(serverInfo.providers['login-protocol'].providers).sort();

Could we perhaps create an issue and do that on a follow-up review? This one's already gotten pretty big, and I'd consider that a more general aesthetic fix. For instance, there is not a determinitive order in authenticator choices in the dropdown, etc. I think the angular models could use a widespread application of some kind of salience/display order.

I agree. If docker-v2 feature has to be enabled explicitly, then I think it's acceptable to have it like this for now.

Sorting is a problem present in multiple locations. If we wanted sorting control at db query layer that would require to model current unsorted collections as lists rather than sets, which is quite a disruptive upgrade in the model. Simple alphabetic sorting (ascending, descending by some field) at REST endpoint would already get us very far for a general case (performance-wise it would be better to do it at db layer), but here we even have a special case where we want specific entry to be at the end of the list. That would still best be done in REST endpoint rather than on the client. For example a special query parameter with special syntax using something like:

?reorder=authenticationProviders[-docker-v2]

might be used to move docker-v2 entry to the end of the collection (leading minus signifying 'move to the end'). We could implement that as part of a bigger REST API overhaul which would add facilities like that across the board in a generic way.

mstruk · 2017-03-22T13:57:05Z

...ain/java/org/keycloak/protocol/docker/installation/DockerQuickstartInstallationProvider.java

+    public String getDisplayType() {
+        return "Quickstart";
+    }
+


I think it would make more sense to call this 'Docker Machine YAML' rather than 'Quickstart'. There is a Keycloak Quickstarts repository, and it would make more sense to create a submodule 'docker' there and move all the quickstart related documentation there.

I meant 'Docker Compose YAML' ...

Done. I think it leaves out the fact that it generates certs for you to mount for your registry, but no name is perfect. Two hard things.

mstruk · 2017-03-22T14:04:30Z

wildfly/server-subsystem/src/main/config/default-server-subsys-config.properties

@@ -67,4 +67,7 @@ keycloak.server.subsys.default.config=\
              </properties>\
        </provider>\
    </spi>\
+    <spi name="login-protocol">\
+        <provider name="docker-v2" enabled="false"/>\
+    </spi>\


Profiles should be used to control activation of this feature. See here.

@stianst I guess we have a policy in place that all features are enabled by default, but users can disable them?

mstruk · 2017-03-22T14:07:46Z

services/src/main/java/org/keycloak/protocol/AuthorizationEndpointBase.java

 import org.keycloak.events.EventBuilder;
 import org.keycloak.models.AuthenticationFlowModel;
 import org.keycloak.models.ClientSessionModel;
 import org.keycloak.models.KeycloakSession;
 import org.keycloak.models.RealmModel;
 import org.keycloak.protocol.LoginProtocol.Error;
+import org.keycloak.services.ErrorPageException;
 import org.keycloak.services.ServicesLogger;


Looks like a redundant import.

Fixed. did an import organization on all docker stuff as well.

mstruk · 2017-03-22T14:11:12Z

services/src/main/java/org/keycloak/protocol/docker/DockerAuthV2Protocol.java

+    private KeycloakSession session;
+    private RealmModel realm;
+    private UriInfo uriInfo;
+    private HttpHeaders headers;


Fields uriInfo and headers seem redundant - assigned, but never used.

They're part of the setters defined in LoginProtocol. Docker protocol doesn't need them, can make those no-op setters if you prefer.

No, it's better as it is. I just pointed out what IDEA was telling me. Maybe that part of implementation was still incomplete.

mstruk · 2017-03-22T14:15:02Z

.../src/main/java/org/keycloak/protocol/docker/installation/quickstart/DockerCertFileUtils.java

+    }
+
+    public static String formatPublicKeyContents(final PublicKey publicKey) {
+        return encodeAndPrettify(BEGIN_CERT, publicKey.getEncoded(), END_CERT);


CERTIFICATE is not exactly the same as PUBLIC KEY. For public key for example 'openssl' CLI tool uses '-----BEGIN PUBLIC KEY-----' and '-----END PUBLIC KEY-----'.

Sure. Was just testing with compatibility with a docker registry since that's what's going to be consuming it. Want me to make the switch and see how docker likes it?

mstruk · 2017-03-22T14:22:18Z

...ices/src/test/java/org/keycloak/procotol/docker/installation/QuickstartInstallationTest.java

+    public void writeToRealZip() throws IOException {
+        final Response response = fireInstallationProvider();
+        final byte[] responseBytes = (byte[]) response.getEntity();
+        FileUtils.writeByteArrayToFile(new File("target/docker-quickstart-install.zip"), responseBytes);


Test makes no assertion. It should probably check that what was returned is a zip file.

Was for smoke testing only - so I could validate locally without having to spin up a server. Have marked as ignored, but can remove if you'd like.

mstruk · 2017-03-22T14:25:41Z

...ices/src/test/java/org/keycloak/procotol/docker/installation/QuickstartInstallationTest.java

+import static org.keycloak.protocol.docker.installation.DockerQuickstartInstallationProvider.QUICKSTART_ROOT_DIR;
+
+public class QuickstartInstallationTest {
+


Ideally we would just have one test that unpacks returned zip and checks if everything is there as it should be.
Our testsuite performance is not the best, so we should try skip unnecessary processing, especially when it's trivial to achieve.

Done. Should be a single zip operation now.

mstruk · 2017-03-22T15:48:29Z

I've noticed another UI issue. When clicking around different clients in Admin Console, it now displays 'docker-v2' protocol for every client.

josh-cain · 2017-03-30T21:10:28Z

@mstruk The non-existent user problem should be fixed now. I subclassed the HttpBasic authenticator and made it return Docker error tokens as described in the docs. Now localized docker messages should appear.

I took some liberties in the getMessageForKey() method to try to resolve message bundles. Generally this happens in the Freemarker section, but we're operating outside of a LoginFormsProvider for this protocol. Can you give that a once-over and make sure it's OK?

There also was an issue where the SAML ECP profile didn't seem to check for disabled users. I added the check, but can easily pull it out of the base class if that's not desired behavior.

Also, I couldn't observe a clear pattern between the use of singletons and instantiating a new provider every time (I.E. the cookie provider and ECP HTTP basic provider differ). I went with instantiating one each time, but if there is a preference for the opposite just let me know.

josh-cain · 2017-03-31T20:41:15Z

I've noticed another UI issue. When clicking around different clients in Admin Console, it now displays 'docker-v2' protocol for every client.

Yeah.... so turns out that those clients are being created with a 'null' protocol. They happened to look right previously since OIDC was the first protocol alphabetically sorted, but they have a null 'Protocol' column on creation in the DB. Should probably do something about that...

josh-cain · 2017-03-31T21:18:37Z

I've noticed another UI issue. When clicking around different clients in Admin Console, it now displays 'docker-v2' protocol for every client.

Yeah.... so turns out that those clients are being created with a 'null' protocol. They happened to look right previously since OIDC was the first protocol alphabetically sorted, but they have a null 'Protocol' column on creation in the DB. Should probably do something about that...

Opened #3998 to deal with this.

mstruk · 2017-04-03T13:35:37Z

services/src/main/java/org/keycloak/services/DefaultKeycloakSessionFactory.java

-import java.util.List;
-import java.util.Map;
-import java.util.Set;
+import org.keycloak.provider.*;


Imports should not be folded like this. Default IDEA setting is bad.

yeah... just updated and started from a fresh IDEA instance. Haven't taken the time to tune all the things back yet. Fixed now.

mstruk · 2017-04-03T13:37:56Z

services/src/main/java/org/keycloak/services/DefaultKeycloakSessionFactory.java

+        if (factory instanceof FeatureDependentProviderFactory) {
+            return Optional.ofNullable(((FeatureDependentProviderFactory) factory).getRequiredFeatures()).orElse(Collections.emptySet())
+                    .stream().allMatch(requiredFeature -> Profile.isFeatureEnabled(requiredFeature));
+        }


@stianst Is it ok to merge this additional feature in common services into this PR, or should it be a separate PR (addition of FeatureDependentProviderFactory, and its handling here)?

We already have EnvironmentDependentProviderFactory#isSupported which covers this and there is no need to introduce yet another way to do it. It's nice and simple to use and is also flexible beyond just profiles. Look at:

https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/authentication/authenticators/browser/ScriptBasedAuthenticatorFactory.java#L155

@stianst @mstruk Done. Just a thought - 'EnvironmentDepndent' becomes a bit of a misnomer here. Perhaps something like 'ConditionalProviderFactory' going forward? Two hard things.

Yes. I agree conditional would be a much better name. However, renaming it breaks backwards compatibility so that's not an option and I don't like alternatives so it is what it is ;)

mstruk · 2017-04-03T14:25:09Z

Authentication seems to work fine now.

One little thing I noticed in UI still is client settings - after creating a new client of type docker-v2, the 'Valid Redirect URIs' field is reported as required. If this information is not used at all maybe 'Root URL', 'Valid Redirect URIs' and 'Base URL' should simply be hidden from the form?

At the minimum it seems the field 'Valid Redirect URIs' should not be marked required, if there's a reason it should stay displayed on the form.

mstruk · 2017-04-03T14:47:10Z

...c/main/java/org/keycloak/protocol/saml/profile/ecp/authenticator/HttpBasicAuthenticator.java

+                        context.success();
+                    } else {
+                        userDisabledFailure(context, realm, user);
+                    }


Yes, I believe this should be in a separate PR.
@pedroigor Can you confirm the way this should fail for disabled users is a proper fix?

OK - so I updated the userDisabledFailure to do what it was doing before in the HttpBasicAuthenticator: letting users in. Otherwise, the refactoring in place is just to expose various action components to the Docker child class. Will that fly?

mstruk · 2017-04-03T15:09:18Z

services/src/main/java/org/keycloak/protocol/docker/DockerAuthenticator.java

+    @Override
+    protected void authFailure(final AuthenticationFlowContext context, final RealmModel realm, final UserModel user) {
+        invalidUserAction(context, realm, user.getUsername(), context.getSession().getContext().resolveLocale(user));
+    }


It seems to me that by resolving locale for error messages for existing user we may give away the information that the attempted user is in fact a valid user. For example, if I try 'bob':'1234' I get back "Unknown user or invalid password", but if I try 'jacques':'1234' I may get back something like 'Utilisateur inconnu ou mot de passe invalide'. Now I know jacques is a valid username.

Localisation should only take into account passed language value - extra query parameter in auth request, or a cookie - if docker-v2 protocol supports that.

But then, won't the result of 'docker login' then be something like:

Error response from daemon: Get https://localhost:5000/v2/: unauthorized: Utilisateur inconnu ou mot de passe invalide.

Why even bother with such a halfway solution? I would keep it simple - just return all messages in english.

Valid point. Just assumed that l10n would be a requirement for userspace mssages, but I see what you're saying, and agree that said issue could be used to enumerate at least some of the users. Has been removed, to my knowledge there is no support for that in the docker auth v2 login protocol.

josh-cain · 2017-04-05T15:36:16Z

@mstruk - Display settings for client information has been updated per your comments.

Anything else here or are we good?

mstruk · 2017-04-05T17:34:36Z

Almost :)

We also need to add some integration tests under testsuite/integration-arquillian as was discussed. Let's assume docker tools are installed on the system. Instructions for preparing the test run should be added to HOW-TO-RUN.md

Maybe @pdrozd or @stianst can chime in with any more specific suggestions.

Finally, there is one big thing that needs to be done before we can merge this PR, and that is - it needs to be squashed into a single commit. Current remerging from master into your branch makes it impossible to clearly see the changes, and makes it messy to undo merge should there be some issue. The simplest way that I see to do this is to simply backup your branch, hard reset it to latest remotes/upstream/master and then cherry-pick into it from your backup branch, resolving conflicts as you move along. Finally, squash it into one commit, and force push it over current branch to update the PR.

josh-cain · 2017-04-20T19:39:58Z

@stianst So I think I have a reasonably sound test harness. It requires a working docker binary on the host machine, and will just skip if one is not found. The docker client and registry are spun up and configured with some custom settings in containers and the existing arquillian/junit framework is used to stand up a test docker realm.

Will address the idea of an entirely new flow for docker auth shortly.

mstruk · 2017-06-15T13:53:01Z

@vmuzikar I've set up a Fedora 25 in VirtualBox to try and find a way to support both Fedora, and macOS. Looks like I found a way: mstruk@2bce514

Could you check, and see if that works for you? See HOW-TO-RUN.md

I had quite a few problems fighting through it. Seems there's an issue with error reporting. At least some of error details seems to be suppressed. For example I don't see AssumptionViolatedExceptions from @BeforeClass logged anywhere. That requires working with source code to debug why the test was skipped for example.

vmuzikar · 2017-06-16T14:39:52Z

@mstruk Thanks for the update!

Seems it fixed the iptables problems in CI (RHEL 7.3). However, it still persists on my Fedora 25 installations (both on my machine and a virtual one which is a clean fresh installation).
So it seems like some distros/flavors just have more enforcing default iptables rules.

So, I've updated the HOW-TO-RUN accordingly.
Also, I've changed the Fedora instructions a bit so the test wouldn't require root permissions (which would also require to have Keycloak build under root, not just the test).
Could you please check it out? vmuzikar@32be113

One last thing before we are good to go.
The test seems more unstable after the recent changes. Sometimes it happens that the test doesn't wait for the Client container to spin up and proceeds with the testing leading to failing test.
This happened multiple times, both on my local machine, on virtual machine and in the CI as well.
Is it just me again or is it happening for you as well?

mstruk · 2017-06-19T14:48:05Z

@vmuzikar I tried your instructions and they work for me.

WRT intermittent failures I think I have experienced that a few times. I have not seen that often, and assumed it was some config change of mine that caused it.

josh-cain · 2017-06-19T15:15:03Z

@vmuzikar, @mstruk I think is what you're looking for:

.waitingFor(new HttpWaitStrategy().forStatusCode(200).forPath("/auth"))

Just encountered the same problem on another project. I'll update PR for appropriate wait checks later today.

josh-cain · 2017-06-21T04:50:28Z

@vmuzikar - Just updated with a wait to validate that the docker daemon is up and running. Is that what you're after?

Also merged in changes from you and Marek.

vmuzikar · 2017-06-21T14:02:49Z

@cainj13 Thanks for the update. Unfortunately, it didn't seem to fix the issue.

I've done some research and I've found 2 problems:

validateDockerStarted used stdout instead of stderr where 'Cannot connect ...' message is sent
when it failed, it actually failed right on the systemctl call so the docker service wasn't started at all (just waiting for docker to start wasn't enough)

I hope I fixed both problems in vmuzikar@9334803
Could you please check it?

Also I've created KEYCLOAK-5079 so we wouldn't forget to update testcontainers once the new version with fixed SELinux is released.

So if my changes are ok and you'll merge them, I believe we are finally ready to merge! :)
The only glitch is the potential problems with default iptables rules, but since this affects only some distros/flavors (RHEL seems to work fine without any modifications) I think we can live with that.

I'm sorry it took too long and perhaps even got a bit frustrating. :) I needed to be sure that the test is ok and working fine before merging so we could start testing it in the CI right away.

josh-cain · 2017-06-21T17:11:28Z

@vmuzikar sounds great! Totally understand that this needs to be pretty stable before allowing it into the base. I appreciate the work you, @stianst, and @mposolda have put into this.

It looks like testcontainers-java #334 was actually merged today, so hopefully that'll find its way to a release fairly quickly.

Finally, Travis looks to be having some issues with failing tests. Dare I ask what's up with those? They appear to be unrelated, but I've not had massive Travis failures like this before...

stianst · 2017-06-26T10:37:46Z

Are we ready to go? One last rebase/squash of commits and this can be merged from my POV.

vmuzikar · 2017-06-26T11:49:32Z

Yes yes - from QE POV we are good to go.

josh-cain · 2017-06-26T22:28:49Z

@stianst @vmuzikar attempted to squash this monstrosity of a PR into a commit. Of course there were plenty of conflicts - I think I resolved them correctly, but would just like to call out that the likelihood of error on those is growing with the size/duration.

Will keep an eye on the builds tonight and see of the results go well.

stianst · 2017-06-27T09:32:51Z

Looks like something went rather wrong and all tests are broken now :(

vmuzikar · 2017-06-27T09:34:46Z

@cainj13 Hmm... it seems like the test is now failing for me with:
java.lang.RuntimeException: Could not create new instance of class org.jboss.arquillian.test.impl.EventTestRunnerAdaptor Caused by: java.lang.reflect.InvocationTargetException Caused by: org.jboss.shrinkwrap.descriptor.api.DescriptorImportException: Could not import XML from stream Caused by: org.xml.sax.SAXParseException: The content of elements must consist of well-formed character data or markup.

Also, I quickly glanced at the test and it seems like it's not the latest version - there are missing e.g. my changes (waiting for the container - the while loop). Perhaps something more is missing too.

josh-cain · 2017-06-27T12:44:06Z

Sorry guys, I'll get to it when I can. Already sunk a ton of time into the PR process (far more time than it took to actually write the implementation), and I've got some other high priority tasking atm. I knew better than to attempt a rebase of this size without a backup, so see dockerProtocolJustInCase branch if you want a snapshot of a pre-rebase version.

stianst · 2017-06-27T13:55:19Z

@cainj13 I'm sorry about the lengthy time it's taken to get this PR accepted. I'm partially to blame as I should have given it more love early on. Sorry for that. We're almost at the goal line now though so don't give up hope :)

I'm holding of the 3.2 release until we can get this merged and it's one of the last things we're waiting for now.

stianst · 2017-06-28T11:22:14Z

@cainj13 I'm trying to squash it now. Hopefully I can get this sorted.

stianst · 2017-06-28T11:41:49Z

Trying to squash this was a disaster in it's own right. So I took a different strategy and uses "git reset" then added a new commit. This looses the author, but I mentioned you as the author in the commit instead. Hope that's OK. After that it was fairly simple to rebase on master, only a few minor merge conflicts to sort out.

https://github.com/stianst/keycloak/tree/docker-rebase-master

Going to run tests and check it out now.

stianst · 2017-06-28T11:42:34Z

Opened a new PR here #4267. If it passes tests and I can run the Docker tests locally I'll merge that.

josh-cain · 2017-06-28T13:10:27Z

@stianst I pulled in your changes - minus trimming of a bit of whitespace in a couple files these branches should now be identical.

I'll examine the tests, still have failures :(

vmuzikar · 2017-06-28T13:23:53Z

I've just run the test in the CI with the Stian's branch and it passed.
Looks good to me.

@cainj13 What's it failing on for you?

josh-cain · 2017-06-28T13:26:25Z

@vmuzikar I was referring to https://travis-ci.org/keycloak/keycloak/builds/247906586 - had failures.

We'll see what Travis does here ^ I suppose...

josh-cain · 2017-06-28T14:08:45Z

@stianst @vmuzikar failures are around stuff like this:

UndertowDemoServletsAdapterTest>AbstractDemoServletsAdapterTest.testTokenMinTTL:524 URL expected to begin with:http://localhost:8180/auth/realms/demo/protocol/openid-connect/auth; actual URL: http://0.0.0.0:8180/auth/realms/demo/protocol/openid-connect/auth?response_type=code&client_id=token-min-ttl&redirect_uri=http%3A%2F%2F0.0.0.0%3A8180%2Ftoken-min-ttl&state=76082516-a9f9-4bf1-8868-eeaf57008281&login=true&scope=openid

Looks like changing the bind settings from 'localhost' to '0.0.0.0' made some tests unhappy.

stianst · 2017-06-29T05:24:26Z

Fixed the issue with the tests and all tests are now passing with auth-server-wildfly and on Travis:
https://github.com/keycloak/keycloak/pull/4269/files#diff-aef353c345932786727b146e60b1f3a9R63

PR merged here #4269

stianst · 2017-06-29T05:24:44Z

@cainj13 We got there in the end! Thanks for all the work :)

josh-cain · 2017-06-29T13:04:11Z

w00t w00t! Glad we got there!

Thanks to y'all as well @stianst, @mposolda, and @vmuzikar! I'll keep my eyes out for bugs, and help where I can as far as mailing list/articles go.

stianst added the 3.x label Nov 30, 2016

stianst assigned mstruk Mar 7, 2017

mstruk reviewed Mar 22, 2017

View reviewed changes

mstruk reviewed Apr 3, 2017

View reviewed changes

stianst self-assigned this Apr 19, 2017

josh-cain force-pushed the dockerProtocolNew branch from 479f645 to 048ccc8 Compare June 21, 2017 03:25

josh-cain force-pushed the dockerProtocolNew branch from 7baafe7 to aaeb1cc Compare June 26, 2017 22:25

Docker auth implementation

c6e8c07

josh-cain force-pushed the dockerProtocolNew branch from aaeb1cc to c6e8c07 Compare June 28, 2017 13:09

stianst closed this Jun 29, 2017

vmuzikar mentioned this pull request Sep 22, 2017

Update TestContainers to 1.4.2 to remove some hacks #4355

Closed

		import static org.keycloak.protocol.docker.installation.DockerQuickstartInstallationProvider.QUICKSTART_ROOT_DIR;

		public class QuickstartInstallationTest {

Docker Protocol Implementation #3565

Docker Protocol Implementation #3565

Conversation

josh-cain commented Nov 29, 2016

tronicum commented Dec 24, 2016

mstruk commented Mar 8, 2017

stianst commented Mar 20, 2017

josh-cain commented Mar 20, 2017

mstruk commented Mar 20, 2017

mstruk commented Mar 22, 2017

mstruk Mar 22, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mstruk commented Mar 22, 2017

josh-cain commented Mar 30, 2017

josh-cain commented Mar 31, 2017

josh-cain commented Mar 31, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

josh-cain Apr 4, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mstruk commented Apr 3, 2017

mstruk Apr 3, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

josh-cain commented Apr 5, 2017

mstruk commented Apr 5, 2017 • edited

josh-cain commented Apr 20, 2017

mstruk commented Jun 15, 2017

vmuzikar commented Jun 16, 2017

mstruk commented Jun 19, 2017

josh-cain commented Jun 19, 2017

josh-cain commented Jun 21, 2017

vmuzikar commented Jun 21, 2017

josh-cain commented Jun 21, 2017

stianst commented Jun 26, 2017

vmuzikar commented Jun 26, 2017

josh-cain commented Jun 26, 2017

stianst commented Jun 27, 2017

vmuzikar commented Jun 27, 2017

josh-cain commented Jun 27, 2017

stianst commented Jun 27, 2017

stianst commented Jun 28, 2017

stianst commented Jun 28, 2017

stianst commented Jun 28, 2017

josh-cain commented Jun 28, 2017

vmuzikar commented Jun 28, 2017

josh-cain commented Jun 28, 2017

josh-cain commented Jun 28, 2017

stianst commented Jun 29, 2017

stianst commented Jun 29, 2017

josh-cain commented Jun 29, 2017

mstruk Mar 22, 2017 •

edited

josh-cain Apr 4, 2017 •

edited

mstruk Apr 3, 2017 •

edited

mstruk commented Apr 5, 2017 •

edited