Shelter是一个帮助用户管理docker registry的产品，为了做这个东西，有必要分析比较现有一些类似产品的核心模型，借鉴其优缺点
hub.docker.com
模型说明
模型图
补充说明
- organization与namespace对应，用户每添加一个organization，实际上就创建了一个同名的namespace
- user和organization类似，每个用户缺省会有一个同名的namespace
- 还有一个叫做team的概念，但是我一直没弄明白它的用法，而且这个team只能添加不能删除，很奇怪，所以这里就不写了
分析讨论
这个模型图本身看起来似乎没问题，但是从用户的角度看namespace会觉得很冗余，实际上，namespace在用户界面上只是一个偶尔被提到的概念，系统本来是可以不让用户知道的。然而设计者显然没有太注意这一点，而一旦添加了它，用户就需要理解namespace与organization和user的关系，结果大大增加了用户（所能感知）的模型复杂度。
Harbor
模型说明
模型图
补充说明
- project由用户管理，它就是registry所看到的namespace，另外，用户缺省是没有project的
- 在harbor的文档中，namespace下层的模型有时用repository，有时用image，怀疑harbor在这里有些地方没想清楚
分析讨论
harbor的模型是最简单的，但是project这个名字非常具有误导性。
一般的理解中，project通常是在一个时间段内进行的计划，一般是周或者月为单位，很少有跨年的，然而实际上模型中提供的是一个“公共namespace”机制，这是为了团队协作而产生的模型，其时效应该和团队相当，这里出现了模型的设计偏差。
在实践中也确实遇到了这样的问题，有的团队直接将自己的产品切割为很多个project，然而这些project其实只是一个团队做的同一个东西的不同组成部分，只是工作中需要有所区分而已。
另外，由于harbor的设计，用户在创建project时会认为这是当前用户所控制的范围，因此不会考虑和其他用户的project是否存在同名冲突，但实际上project名称需要保持全局唯一性，这给用户带来了不小的认知负担。
Portus
模型说明
模型图
补充说明
- team用来管理一群人，例如统一为多个人设定权限等
- namespace就是docker registry地址里面的namespace
- docker registry的镜像在这里被称为repository
分析讨论
Portus的模型是相对比较复杂而且有些僵化的，它在namespace之上添加了一个team的概念，使得用户创建namespace之前必须要创建一个team，这给管理员增加了麻烦。
这么做还有一个副作用，普通用户（非管理员）如果想管理自己临时做的镜像，需要添加一个namespace，并因此要先创建一个team，这个team实际上只有一个成员（就是用户自己），这会大大增加用户的心智成本，可能导致用户不愿意或者不习惯使用自建镜像做一些探索性工作。
github.com
模型说明
模型图
补充说明
- repository是以user或者organization名字进行分类组织的，但是github.com并没有抽出一个namespace的概念，当用户要创建repository的时候，系统会提示他选择owner，然后根据这个owner（可能是用户自己，也可能是organization）决定namespace
- github.com也有team的概念，它是在organization之下用来管理user的，由于它和repository无关，而且它对于github.com不是必要的核心模型，因此就不列出来了
设计讨论
github的模型相对比较简单，它对用户可见的模型只有三个，而且无论是user还是organization都是用户很容易理解的概念。对shelter来说，只有一个地方可能需要讨论，就是对于repository的命名。
github面对的是代码仓库的管理，而shelter管理的是registry里面的镜像，虽然我们期望它们一一对应，但实际上它们是不同的模型，如果混为一谈，可能对用户的理解也是不利的，另外，如果需要对于image和repository在commit id上进行映射，这可能也有问题。
最终的结论
经过上述的分析，目前比较认可github.com的模型，下面是原因。
显然，用户对于user和organization的概念是天生就能理解的，因此最好的对策是将namespace“隐藏”在这两个概念中，当用户创建organization或者user的时候，系统就产生了一个（且仅有一个）namespace与其对应。
这个做法有没有问题呢？需要考虑两个方面：
- 这种 user+organization 的结构是否足以支持研发团队本身的组织架构，或者说，复杂的研发组织是否可以通过本模型进行支持？
- 是否存在一个user（或者organization）需要多个namespace的情况？
对于问题1，坏消息是——不能，更深的研发组织层级是不能用这种模式进行完全支持的。
不过，还有一个好消息——其实，我们不必支持过于复杂的组织结构。
软件开发领域，多种管理风格共存，我们的软件不可能符合所有的管理风格，所以我们只服务相同理念风格的团队和组织，这个理念就是小团队和扁平化，我们认为这是未来的趋势，值得坚持走下去，而在这个思路指导下，现有模型在组织复杂度上是完全够用的。
那么，是否还可以再进一步简化？比如将user和organization合并，把后者看作一种特殊的前者？实际上我一开始也有这个考虑，但是后来发现是不合理的，关键在于user要承担一个身份识别的责任，简单说，它是用户用来登录的东西，而group在任何时候都不会有一个“登录”的行为，所以区分这两者还是有必要的。
接下来说问题2，我们会发现，对于user/organization之下建立多个namespace的情形，本质上是一种归类需要，而归类需求其实不需要这么僵硬的模型支持，namespace的重点应该registry上表现为一个授权单元，用户可以在这个粒度上进行权限控制。
归类需求是资源和信息管理的常见需要，不过现在很多管理方式都趋向于轻量级的思路。比如，简单场景下可以直接让用户自己约定前缀命名法，系统只要提供autocomplete search 就可以了；而如果是复杂场景，还可以用tag，都比僵化单一的分类目录要更方便
对于小团队和扁平化管理来说，授权的边界就是organization的边界（我们不需要在小团队内部再建立权限区分，而是应该鼓励他们作为一个整体完成任务和承担责任），所以namespace在本质上就应该和organization/user是一一对应的。
这样，在用户的视角看来，没有什么namespace，只有image按照管理者不同而进行的归类，有些属于个人，有些属于团队，如此而已。
最后再简单吐槽一下repository这个概念的命名，我认为目前大家的概念在这里有点混乱，github.com上管理的确实就是repository，起这个名字很合理，但是portus等系统就显得很奇怪了，它们管理的就是docker镜像，显然称为image更为合理。详细查看registry的api，发现这里也叫repository，文档中是这么说的：
Images are stored in collections, known as a repository
看来这个repository和代码仓库无关，是指image的存放之处，不过我觉得这个api命名很不好，因为repository这种概念完全是内部问题，对外统一叫image才符合用户理解，这样可以让镜像管理系统相对“干净”些，但是既然官方有这个命名，我们就先和它保持一致吧，最终模型就是github.com的图
