| | 361 | |
| | 362 | === Circles === |
| | 363 | |
| | 364 | Circles are groups of users used to share the contents of experiments and libraries among users. One can think of them as lightweight projects of collaborating researchers who are working together on related experiments. |
| | 365 | |
| | 366 | The key distinction between the two kinds of user groups is that a project confers access to the testbed resources in the large based on delegation of trust. A circle confers rights to specific experiments and libraries. Project membership is a prerequisite to accessing the testbed at all; circle memberships control access to specific abstraction instances inside the testbed. |
| | 367 | |
| | 368 | Once the testbed administration has palced their trust in a user through the project abstraction, they are free to collaborate without any further significant administrative oversight through the circles system. |
| | 369 | |
| | 370 | Projects and circles are related. Each project has a linked circle that contains all the users who are members of the project. The system keeps that circle and project membership synchronized. One can think of assigning the rights to manipulate experiments and libraries to projects as existing Emulab code does. Under the covers it is the linked circle that conveys the rights. |
| | 371 | |
| | 372 | Whenever a user is created, a circle, [wiki:SPIDocs#CircleNames named] ''userid'':''userid'', is also created containing only that user. One can use this circle to assign rights to a user and only that user. This circle behaves like all other circles, but may seem special because of the membership and [wiki:SPIDocs#CirclePermissions permissions] assigned to it. There is only the one member, and that member does not have the rights to modify the circle membership. The system removes this circle when and if the user is removed. |
| | 373 | |
| | 374 | ==== Circle Names ==== |
| | 375 | |
| | 376 | Every circle has a unique ''circleid'' that names it in the testbed. Circle names are scoped by either userids or projectids. A circleid has the form of either: |
| | 377 | |
| | 378 | * userid:local_name |
| | 379 | * projectid:local_name |
| | 380 | |
| | 381 | So there may be circles named `some_user:students` and `some_project:students`. They are distinct. |
| | 382 | |
| | 383 | That scoping serves 2 purposes: disambiguating common names and providing a way to distinguish certain names. We expect that many users will set up circles with local names like `test`, `students`, `assistants` and the like. The user interfaces built on the SPI can scope such names by the userid creating them and hide the prefix unless it is necessary to disambiguate. |
| | 384 | |
| | 385 | When a user creates a name in scoped by a project name, it is functionally equivalent to a userid-scpoed name, but applications may choose to distinguish them. One can easily imagine that `some_user:students` and `some_project:students` refer to different sets of users and that the project-prefixed circle is administered more carefully and used more widely. |
| | 386 | The right to create a circle in a project's name space - prefixed by the projectid - is controlled by [wiki:SPIDocs#ProjectPermissions project permissions]. |
| | 387 | |
| | 388 | ==== Circle Permissions ==== |
| | 389 | |
| | 390 | Like [wiki:SPIDocs#ProjectPermissions projects], each user in a circle may have one or more of the following permissions that define the operations that user can carry out on the circle itself. The permissions are: |
| | 391 | |
| | 392 | ||= Permission Name =||= Meaning =|| |
| | 393 | || ADD_USER || Request that a user be added to the project or confirm a request by a user to join the project || |
| | 394 | || REALIZE_EXPERIMENT ||Allocate resources to an experiment and carry it out so that it is accessible to the members of this circle || |
| | 395 | || REMOVE_USER || Remove a user from the project. Any objects they have created in the project's namespace remain || |
