| | 406 | == Change Set Q: Support changing users and keys on existing compute slivers == |
| | 407 | |
| | 408 | Experimenters often want to change the users and/or SSH keys installed on existing running compute nodes, in a way that is persistent and consistent with any aggregate manager controlled processes. This is theoretically possible through the use of `Update()`, but the semantics are not clear there. |
| | 409 | |
| | 410 | This change set proposes a way to do this using `PerformOperationalAction()` and also proposes the semantics of providing a new set of users/keys to the `Provision()` call after a call to `Update()`. |
| | 411 | |
| | 412 | This change set may be implemented as part of an aggregate's AM API v3 implementation. |
| | 413 | |
| | 414 | === Specifying users and keys === |
| | 415 | Users to be installed and SSH keys to be installed for those users are specified using the `geni_users[]` struct as specified [wiki:GAPI_AM_API_V3/CommonConcepts#geni_users in AM API v3]. |
| | 416 | |
| | 417 | When applied to an existing sliver (through a new operational action or through a call to `Update()` and `Provision()`): |
| | 418 | - This same user struct is to be used |
| | 419 | - New users may be added |
| | 420 | - Omitting a user means there will be no change to the keys installed for that user. It does ''not'' mean the user should be removed. |
| | 421 | - Existing users will have all SSH keys replaced by the new set. Note that a user may have an empty list of SSH keys specified, effectively preventing the user from accessing the node. |
| | 422 | |
| | 423 | === Semantics with `Update` === |
| | 424 | After a call to `Update()`, users must call `Provision()` to commit the change. `Provision()` takes the `geni_users[]` struct. When called after `Update()`, the `geni_users[]` struct will have the add/replace semantics described above for any existing nodes; new nodes will treat all the users/keys as additions as normal. |
| | 425 | |
| | 426 | === Changing users/keys through an operational action === |
| | 427 | |
| | 428 | Users and SSH keys can be changed using 2 new operational actions (through `PerformOperationalAction()`): |
| | 429 | |
| | 430 | 1. `geni_update_users`: The `credentials[]` argument must include credentials over the slice as usual. The `options` struct must include the `geni_users` option as specified [wiki:GAPI_AM_API_V3/CommonConcepts#geni_users in AM API v3] and with the semantics described above. This action is only legal on slivers in the `geni_ready` operational state. This action immediately moves all such slivers to a new `geni_updating_users` operational state. Slivers stays in that state until the aggregate completes the needed changes, at which time the slivers change back to the `geni_ready` operational state. Slivers may be in the `geni_updating_users` state for several minutes; during this time no other operational actions can be taken on the slivers. |
| | 431 | |
| | 432 | Besides the usual return error codes, the `PerformOperationalAction` method with this action may return `REFUSED` if the sliver is in the wrong operational state. |
| | 433 | |
| | 434 | Note that as described [wiki:GAPI_AM_API_V3/CommonConcepts#SliverOperationalActions here], aggregates supporting this action and operational state will advertise this fact in their advertisement RSpec. |
| | 435 | |
| | 436 | 2. `geni_updating_users_cancel`: This action requires no options. It cancels any pending `geni_update_users` action on the named slivers, returning those slivers to the `geni_ready` operational state. This action is only legal on slivers in the `geni_updating_users` operational state. This action may be used on slivers which fail to complete the `geni_update_users` action. After a successful `geni_updating_users_cancel`, the sliver(s) should have the same users/keys as they had prior to beginning the `geni_update_users` action. |
| | 437 | |
| | 438 | Besides the usual return error codes, the `PerformOperationalAction` method with this action may return `REFUSED` if the sliver is in the wrong operational state. |
| | 439 | |
