Allow multiple segments in DockerImageReference #11173

legionus · 2016-09-30T13:10:03Z

add an integration tests
profit

legionus · 2016-09-30T13:15:36Z

liggitt · 2016-09-30T13:23:50Z

pkg/image/api/helper.go

+	stream, tag, id := parseRepositoryTag(spec)
+
+	repoParts := strings.Split(stream, "/")
+	if len(repoParts) < 4 {


explain the magic 4 in a comment?

Right now we can have maximum 3 part (registry/namespace/name). Multi-segment path means 4 or more. So, old behavior will be in case of < 4.

liggitt · 2016-09-30T13:24:54Z

pkg/image/api/helper.go

+
+	ref.Name = strings.Join(repoParts[2:], "/")
+	if len(ref.Name) == 0 {
+		return ref, fmt.Errorf("the docker pull spec %q must be more than three segments separated by slashes", spec)


"more than three" or "three or more"?

liggitt · 2016-09-30T13:26:45Z

pkg/image/api/helper_test.go

 	testCases := []struct {
 		From                               string
 		Registry, Namespace, Name, Tag, ID string
 		Err                                bool
+		MSegErr                            bool


this is hard to follow, just duplicate the cases and make the parsing function one of the inputs to the test

I wanted to make sure that all the tests pass by both functions except for some testcases and wanted to quickly find out which tests are different.

I agree with Jordan - more explicit tests are better. Use a common core array and add variant cases.

miminar · 2016-09-30T13:30:08Z

pkg/image/api/helper.go

+// ParseDockerImageReference parses a Docker pull spec string into a
+// DockerImageReference.
+func ParseDockerImageReference(spec string) (DockerImageReference, error) {
+	// TODO replace with docker version once docker/docker PR11109 is merged upstream


I think it's about time to resolve this. moby/moby#11109 was marched in March 2015.

Yes, but the parser is very different from what we do. I tried it.

If you think it's not worth it, just delete the comment. On the other hand, I'd like to have a way to easily turn our DockerImageReference into upstream's reference.Reference.

@miminar No, I mean that must be a completely different PR because we have some additional magic guessing (https://github.com/openshift/origin/blob/master/pkg/image/api/helper.go#L142-L156) and restriction how many components we can accept. So, we can't use reference.Reference without extra work anyway.

Please document the special behavior in the godoc for these methods - anything this fundamental should be documented well. Please include the official spec, and each point where we differ.

miminar · 2016-09-30T13:32:07Z

pkg/image/api/helper.go

+
+	// registry/namespace/name/namecomponent/namecomponent/...
+	if strings.HasSuffix(repoParts[0], ":") || IsRegistryDockerHub(repoParts[0]) {
+		return ref, fmt.Errorf("the docker pull spec %q must be two or three segments separated by slashes", spec)


The error message looks outdated.

No. This is the error message that was returned by ParseDockerImageReference in same case.

The error message contradicts a comment two lines above.

Will be OK if I put comment // http://registry/namespace/name inside if ?

I don't quite understand, why a function that is supposed to parse a reference with way more than 3 segments would ever return "the docker pull spec %q must be two or three segments separated by slashes". The error statement just isn't right.

@miminar because this case for http://example.com/namespace/name.

But I just realized that I can't act like that and in case of specifying of schema I need to parse the rest path. Thanks!

@miminar I was wrong again. We don't support schema in DockerImageReference:
https://github.com/openshift/origin/blob/master/pkg/image/api/helper_test.go#L290-L291
https://github.com/openshift/origin/blob/master/pkg/image/api/helper_test.go#L298-L299

miminar · 2016-09-30T13:33:51Z

pkg/image/api/helper.go

-// ParseDockerImageReference parses a Docker pull spec string into a
-// DockerImageReference.
-func ParseDockerImageReference(spec string) (DockerImageReference, error) {
+func parseDockerImageReference(repoParts []string, spec string) (DockerImageReference, error) {


Having two different functions with the same name looks suspicious or at least redundant.

OK. I will change it to something more common.

miminar · 2016-09-30T13:37:32Z

pkg/image/api/helper.go

+	}
+	ref.Registry = repoParts[0]
+
+	if len(repoParts[1]) == 0 {


Can this be applied to all the name components?

@miminar I'm not sure I understand.

I mean all the name components shall be not empty. Why not checking them all in a loop?

Yes, I miss check for ref.Registry. Thanks! I'll fix it.

miminar · 2016-09-30T13:43:05Z

pkg/image/api/validation/validation.go

@@ -56,7 +56,7 @@ func validateImage(image *api.Image, fldPath *field.Path) field.ErrorList {
 	if len(image.DockerImageReference) == 0 {
 		result = append(result, field.Required(fldPath.Child("dockerImageReference"), ""))
 	} else {
-		if _, err := api.ParseDockerImageReference(image.DockerImageReference); err != nil {
+		if _, err := api.ParseMultiSegmentsDockerImageReference(image.DockerImageReference); err != nil {


What about parsing docker image reference in ValidateImageStream().

@miminar ValidateImageStream must be unmodified.

Also this is a good candidate for a new unit test.

@miminar I'll do more tests when this approach will be approved by @liggitt, and @smarterclayton and you, because I'm not sure that we want to make these changes.

miminar · 2016-09-30T14:00:25Z

pkg/build/api/validation/validation.go

@@ -394,7 +394,7 @@ func validateFromImageReference(reference *kapi.ObjectReference, fldPath *field.
 		}
 		if len(name) == 0 {
 			allErrs = append(allErrs, field.Required(fldPath.Child("name"), ""))
-		} else if _, err := imageapi.ParseDockerImageReference(name); err != nil {
+		} else if _, err := imageapi.ParseMultiSegmentsDockerImageReference(name); err != nil {


It seems to me like we need to update validateToImageReference as well.

@miminar I was not sure about that. I will fix it.

miminar · 2016-09-30T14:22:55Z

Could this add an integration test which would launch a fake registry server serving manifests from multi-slash repositories which we would import?

smarterclayton · 2016-09-30T14:59:34Z

pkg/image/api/helper.go

+	return ref, err
+}
+
+func ParseMultiSegmentsDockerImageReference(spec string) (DockerImageReference, error) {


This should not be public - we should not have two DockerImageReferences in the system. IF something is using ParseDockerImageReference that is not a valid DockerImageReference, we should create a new method which is "ParseNotQuiteDockerImageReference" (name can be better) that other code should call. DockerImageReferences are multi segment by default, which means ParseDockerImageReference should support multi-segment.

ncdc · 2016-10-03T16:02:35Z

pkg/image/api/helper.go

+		// Handle multiple segments in form: registry/namespace/namesegment1/namesegment2/.../name
+		// but not this form: http://registry/namespace/name. We don't support using the schema in
+		// the DockerImageReference.
+		if len(repoParts) > 3 && !strings.HasSuffix(repoParts[0], ":") {


Isn't this going to miss validating myregistry.com:5000/a/b/c?

@ncdc No. This check only for suffix, not for substring.

Oh I see it now, thanks. Nevermind :-) But when would it have a suffix of :?

http://example.com/foo/bar

If you split it by / then first part (registry) will be http:.

That's not valid. We've never supported a scheme. Is that all you're testing the suffix for?

Also hostname can't have : at the end anyway.

Right... I guess this is ok if we actually have users putting in http:// at the front of their pull specs...

@ncdc We have a tests that verify this ban:

https://github.com/openshift/origin/blob/master/pkg/image/api/helper_test.go#L290-L291

https://github.com/openshift/origin/blob/master/pkg/image/api/helper_test.go#L298-L299

ncdc · 2016-10-03T16:03:49Z

pkg/image/api/helper.go

+			ref.Registry = repoParts[0]
+
+			if len(repoParts[1]) == 0 {
+				return ref, fmt.Errorf("the docker pull spec %q must contain non-empty namespace", spec)


Technically it's not a "namespace". It's just a "component". See https://github.com/docker/distribution/blob/744ae974a5bfc47c219320460eead041fc9f64f4/reference/reference.go#L7.

Yes, but the text of the error made in the context of DockerImageReference.
Should I write something like:
the docker pull spec %q must be three or more segments separated by slashes
?

it seemed to me that it's less obvious in this case.

I would prefer something that indicates that you can't have any empty segments/components. Also see my comment below about removing any specificity of number of segments.

Ok. I will change comment.

ncdc · 2016-10-03T16:03:59Z

pkg/image/api/helper.go

+
+			for i, part := range repoParts[2:] {
+				if len(part) == 0 {
+					continue


Shouldn't this error?

OK. I will change it.

ncdc · 2016-10-03T16:05:26Z

pkg/image/api/helper.go

+				ref.Name += part
+			}
+			if len(ref.Name) == 0 {
+				return ref, fmt.Errorf("the docker pull spec %q must be three or more segments separated by slashes", spec)


I don't think this error message is accurate. It does not have to be three or more segments. In fact, for all of the error messages we return from this function, wouldn't it make more sense to just say it's not a valid pull spec, and if we can, give a reason why it failed to parse (registry is missing, segment can't be empty, etc). I think it might be time to remove the error text saying it has to be some specific # of segments.

Please please please change the error text. I do not want it saying that it has to be three or more segments.

@ncdc Actually this if is useless because if have more than 3 parts in slice (repoParts), two of them are not empty (Registry and Namespace) and rest of them are not empty as well after check inside for. It means that Name can't be empty.
I will remove this check.

ncdc · 2016-10-03T16:10:02Z

pkg/image/api/helper_test.go

-			From: "bar/foo/baz/biz",
-			Err:  true,
+			From:      "bar/foo/baz/biz",
+			Registry:  "bar",


Technically, I think if the docker hub ever starts supporting multiple components, this would resolve to registry=docker.io, namespace=bar, name=foo/baz/biz.

That's right. See my above comment https://github.com/openshift/origin/pull/11173/files#r81712056

ncdc · 2016-10-03T16:10:31Z

pkg/build/api/validation/validation_test.go

@@ -1269,7 +1269,7 @@ func TestValidateCommonSpec(t *testing.T) {
 				Output: buildapi.BuildOutput{
 					To: &kapi.ObjectReference{
 						Kind: "DockerImage",
-						Name: "some/long/value/with/no/meaning",
+						Name: "index.docker.io/some/long/value/with/no/meaning",


Why these changes?

it's changing because this is now a valid image spec... only by pinning it to dockerhub can we trigger the invalid error?

Ah, right, at least for the hub. Although as I wrote in another comment, if/when the hub allows [user]/[one]/[or]/[more]/[segments], these tests won't be valid any more

But we use our parser, so these tests will be valid until we change it and allow mutliple segments for dockerhub. These tests we will change along with the parser.

The purpose of these tests is not the link itself but any invalid value will cause an error.

Why do we have to special case the docker.io? Docker client allows me to tag docker.io/miminiar/my/image/with/many/slashes without any warning. Even tab completion works with this name.

@miminar try to create such repository on docker.io

miminar · 2016-10-04T08:54:53Z

pkg/image/api/helper.go

@@ -184,7 +184,41 @@ func ParseDockerImageReference(spec string) (DockerImageReference, error) {
 		ref.ID = id
 		break
 	default:
-		// TODO: this is no longer true with V2


Regarding case 3: I feel like it's about time to recognize registry part based on special characters it contains. The same way upstream does it.

@miminar parser refactoring out of scope of PR. I can open following issue about it.

Ahh, I hate devcuts.

miminar · 2016-10-04T09:01:18Z

pkg/image/api/validation/validation_test.go

@@ -315,24 +315,6 @@ func TestValidateImageStreamMappingNotOK(t *testing.T) {
 			field.ErrorTypeRequired,
 			"image.metadata.name",
 		},
-		"invalid repository pull spec": {


Instead of removing, could you change the test to check this is a valid reference? Also could you add another case that would trigger ErrorTypeInvalid?

@miminar This test is called the TestValidateImageStreamMappingNotOK. So, this case can't be here anyway.

Ok, so at least change the repository to something like ///a/b/c/d to generate the ErrorTypeInvalid.

@miminar done

legionus · 2016-10-04T13:11:44Z

@miminar @ncdc PTAL again.

miminar · 2016-10-04T13:30:16Z

test/integration/imageimporter_test.go

@@ -316,6 +316,14 @@ func TestImageStreamImportOfV1ImageFromV2Repository(t *testing.T) {
 	}
 }

+func TestImageStreamImportOfV1ImageFromV2Repository(t *testing.T) {
+	testImageStreamImportWithPath(t, "/test/image")


Just a nit: repo name doesn't start with a slash.

This is a part of path.

@miminar I need to rename second argument ?

@miminar Done. / removed.

ncdc · 2016-10-04T13:47:30Z

pkg/image/api/helper.go

+		if len(repoParts) > 3 && !strings.HasSuffix(repoParts[0], ":") {
+			if IsRegistryDockerHub(repoParts[0]) {
+				// DockerHub doesn't support multiple segments.
+				return ref, fmt.Errorf("the docker pull spec %q must be two or three segments separated by slashes", spec)


I would reword as "the docker pull spec %q must be of the form / to be valid for the docker hub" or something like that

OK. I will use your message.

ncdc · 2016-10-04T14:21:51Z

I think we'll be best served by doing the following (which, yes, is a parser refactoring):

Use https://github.com/docker/distribution/blob/master/reference/reference.go#L150 to parse the initial pull spec string
Call https://github.com/docker/distribution/blob/master/reference/reference.go#L138 to get the registry hostname, if specified
Now that we have the reference from step 1 (and possibly a hostname from step 2):
1. Fill in ref.Registry from hostname
2. Extract name/tag/digest using type assertions against the distribution interfaces
3. Perform any additional validation we require

legionus · 2016-10-04T14:30:58Z

@ncdc devcut is tomorrow. We don't have enough time to make such refactoring.
@mfojtik @smarterclayton Are you agree to move this fix to the next release ?

ncdc · 2016-10-04T14:32:45Z

We should do it right. What release are you currently targeting?

legionus · 2016-10-04T14:33:54Z

@ncdc proposed-3.4

legionus · 2016-10-04T14:56:46Z

[test]

ncdc · 2016-10-04T15:16:52Z

Ok, I looked at the docker/distribution code. It doesn't cover everything we have ("case 2:" for repoParts). So we can proceed with this PR for now and hopefully switch to the upstream parser later.

ncdc · 2016-10-04T15:18:10Z

pkg/image/api/helper.go

+		if len(repoParts) > 3 && !strings.HasSuffix(repoParts[0], ":") {
+			if IsRegistryDockerHub(repoParts[0]) {
+				// DockerHub doesn't support multiple segments.
+				return ref, fmt.Errorf("the docker pull spec %q must be of the form / to be valid for the docker hub", spec)


Looks like something got lost in translation from my original suggestion. the docker pull spec %q must be of the form <username>/<repository> to be valid for the docker hub

It's not true. You can use docker.io/busybox. So, <username> not required.

Yeah, the fun of the implicit library. I'd personally prefer to remove this logic that makes a special case out of the hub, even though a hub spec with more than 2 segments isn't valid at the moment. WDYT? @liggitt @mfojtik @pweil- @smarterclayton

@ncdc How about invalid docker hub pull spec %q ?

Either that, or remove this logic if everyone else agrees

@ncdc I added this condition because we have previously banned more than 3 parts, and by this we banned docker.io/foo/bar/baz as well. I wanted to allow multiple segments only for custom docker/distribution servers.

If the hub moves to add more than 2 segments, then we'd have to refactor, rebuild, and put out a new release to support it. I'd rather avoid that if we can.

@ncdc error message changed.

@ncdc This check has been removed.

ncdc · 2016-10-04T15:19:44Z

pkg/image/api/helper.go

+				return ref, fmt.Errorf("the docker pull spec %q must be of the form / to be valid for the docker hub", spec)
+			}
+			if len(repoParts[0]) == 0 {
+				return ref, fmt.Errorf("the docker pull spec %q must contain non-empty registry name", spec)


I would either say you can't have empty segments, or you can't have 2 consecutive slashes (//). I'm really trying hard to avoid us telling a user that they have to have something when it's not necessarily required.

Or you could say "registry cannot be empty"; I could live with that 😄

But first segment here have to be registry. No? Why can't tell user that he miss and what we expect to see ?

If/when the hub supports multiple segments, no, the first segment doesn't have to be the registry. But today, yes, it has to be the registry. This is fine for now.

@ncdc the docker pull spec %q cannot have empty segments -- it's ok for you ?

That's fine, thanks.

@ncdc fixed.

ncdc · 2016-10-04T16:00:24Z

pkg/image/api/helper.go

+		// the DockerImageReference.
+		if len(repoParts) > 3 && !strings.HasSuffix(repoParts[0], ":") {
+			if len(repoParts[0]) == 0 {
+				return ref, fmt.Errorf("the docker pull spec %q cannot have empty segments", spec)


Make this error text consistent with the 2 below please

ncdc · 2016-10-04T16:03:50Z

pkg/image/api/helper.go

+			ref.Tag = tag
+			ref.ID = id
+			break
+		}
 		return ref, fmt.Errorf("the docker pull spec %q must be two or three segments separated by slashes", spec)


To get to this line of code, it means either:

len(repoParts) > 3 and repoparts[0] is a scheme (http: or https:)

len(repoParts) = 0

Either way, I don't think we should keep the error message as is, saying that it has to be two or three segments. I'm not sure what the best error message is, though.

@ncdc This error message describes the common requirements for the DockerImageReference. It seems to me that it is better to leave it as is. Otherwise we need to add much more checks to make it better.

You can leave it for now, to get this PR in, but I would like it fixed when we refactor parsing.

miminar · 2016-10-04T18:18:36Z

LGTM

miminar · 2016-10-04T18:52:42Z

pkg/image/api/helper_test.go

+			Err:  true,
+		},
+		{
+			From: "docker.io/library/foo/myapp",
 			Err:  true,


This should be a non-error. Confirmed by jenkins:

--- FAIL: TestParseDockerImageReference (0.00s) helper_test.go:328: docker.io/library/foo/myapp: unexpected non-error

ncdc · 2016-10-04T19:26:54Z

I'm pretty sure that should error

On Tuesday, October 4, 2016, Michal Minář notifications@github.com wrote:

@miminar commented on this pull request.

In pkg/image/api/helper_test.go
#11173 (review)
:
      From: "bar/foo/baz/biz",
    From:      "bar/foo/baz/biz",
    Registry:  "bar",
    Namespace: "foo",
    Name:      "baz/biz",
},
{
    From: "bar/foo/baz////biz",
    Err:  true,
},
{
    From: "//foo/baz/biz",
    Err:  true,
},
{
    From: "docker.io/library/foo/myapp",
  Err:  true,
This should be a non-error. Confirmed by jenkins:

--- FAIL: TestParseDockerImageReference (0.00s)
helper_test.go:328: docker.io/library/foo/myapp: unexpected non-error

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#11173 (review),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAABYunaUq0adS79xN5d3vB29L1HaweIks5qwqCEgaJpZM4KLEdX
.

ncdc · 2016-10-04T19:49:25Z

Heh, forgot that was removed

On Tuesday, October 4, 2016, Alexey Gladkov notifications@github.com
wrote:

@legionus commented on this pull request.

In pkg/image/api/helper_test.go
#11173:
      From: "bar/foo/baz/biz",
    From:      "bar/foo/baz/biz",
    Registry:  "bar",
    Namespace: "foo",
    Name:      "baz/biz",
},
{
    From: "bar/foo/baz////biz",
    Err:  true,
},
{
    From: "//foo/baz/biz",
    Err:  true,
},
{
    From: "docker.io/library/foo/myapp",
  Err:  true,
Sure.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#11173, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAABYhmlL-hcTCFceGdqMKR1Woy1P2WCks5qwqnQgaJpZM4KLEdX
.

We need to be able to handle a repository with more than one component in the name (separated by slash). This necessity follows from the fact that docker/distribution supports such names, but we can't parse them. https://bugzilla.redhat.com/show_bug.cgi?id=1373281 Signed-off-by: Gladkov Alexey <agladkov@redhat.com>

openshift-bot · 2016-10-05T09:12:22Z

Evaluated for origin test up to a5ce371

openshift-bot · 2016-10-05T11:36:18Z

continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/9647/)

legionus · 2016-10-05T11:37:41Z

@ncdc fixed and tested.
Looks good now ?

ncdc · 2016-10-05T13:59:15Z

Good enough... can't wait to see this refactored though.

mfojtik · 2016-10-05T14:03:41Z

[merge]

(bumped priority on follow up)

miminar · 2016-10-06T09:01:08Z

Flake #11240 in the merge job https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/9696/.

mfojtik · 2016-10-06T09:23:29Z

[merge]

openshift-bot · 2016-10-06T09:27:18Z

Evaluated for origin merge up to a5ce371

openshift-bot · 2016-10-06T10:57:31Z

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/9701/) (Image: devenv-rhel7_5139)

legionus force-pushed the support-more-slashes-in-image-names branch from 599eea9 to d5005ae Compare September 30, 2016 13:14

liggitt reviewed Sep 30, 2016

View reviewed changes

miminar reviewed Sep 30, 2016

View reviewed changes

smarterclayton reviewed Sep 30, 2016

View reviewed changes

legionus force-pushed the support-more-slashes-in-image-names branch 2 times, most recently from 67cb80e to 456e042 Compare October 3, 2016 13:11

legionus changed the title ~~Allow use multi-segment docker path for import and builds~~ Allow multiple segments in DockerImageReference Oct 3, 2016

legionus force-pushed the support-more-slashes-in-image-names branch from 456e042 to 1a43a2e Compare October 3, 2016 15:43

ncdc suggested changes Oct 3, 2016

View reviewed changes

miminar reviewed Oct 4, 2016

View reviewed changes

legionus force-pushed the support-more-slashes-in-image-names branch 2 times, most recently from aaab282 to bdc90d8 Compare October 4, 2016 13:10

miminar reviewed Oct 4, 2016

View reviewed changes

ncdc reviewed Oct 4, 2016

View reviewed changes

legionus force-pushed the support-more-slashes-in-image-names branch 2 times, most recently from b914a20 to 191f258 Compare October 4, 2016 14:12

legionus force-pushed the support-more-slashes-in-image-names branch from 191f258 to eeff969 Compare October 4, 2016 14:33

ncdc reviewed Oct 4, 2016

View reviewed changes

legionus mentioned this pull request Oct 4, 2016

Refactor ParseDockerImageReference #11211

Closed

legionus force-pushed the support-more-slashes-in-image-names branch 2 times, most recently from ad59728 to 37f2403 Compare October 4, 2016 15:57

ncdc reviewed Oct 4, 2016

View reviewed changes

miminar reviewed Oct 4, 2016

View reviewed changes

legionus force-pushed the support-more-slashes-in-image-names branch from 37f2403 to a5ce371 Compare October 5, 2016 09:11

ncdc approved these changes Oct 5, 2016

View reviewed changes

openshift-bot merged commit a4eebdd into openshift:master Oct 6, 2016

Allow multiple segments in DockerImageReference #11173

Allow multiple segments in DockerImageReference #11173

Conversation

legionus commented Sep 30, 2016 • edited by miminar Loading

legionus commented Sep 30, 2016

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

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

miminar commented Sep 30, 2016

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

legionus Oct 3, 2016 • edited Loading

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

ncdc Oct 3, 2016 • edited Loading

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

legionus commented Oct 4, 2016

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

legionus commented Sep 30, 2016 •

edited by miminar

Loading

legionus Oct 3, 2016 •

edited

Loading

ncdc Oct 3, 2016 •

edited

Loading