related to bp create-role-with-nailgun-api Change-Id: I677dd82c7e3a64c7dc88a7e5a5690b0493fa45da
4.5 KiB
Provide programable API to work with Fuel node roles
Problem description
Current state of nailgun only allows to create roles by inserting them in nailgun/fixtures/openstack.yaml and create entities based on this description.
Such approach can not be considered as extensible and imposes difficulties when user wants to move certain services on to separate nodes (the closest example is ceph-mon which is always installed on controller).
Proposed change
Current spec proposes to allow user create/update/delete roles by nailgun rest-api and fuel client.
Alternatives
Allow creation of new roles only as a plugin entity. But such approach imposes bad UX experience for anyone who want to solve certain business problems right on environment.
Data model impact
Current data model will be reused, as it is sufficient for needs of this specification.
REST API impact
Object can be described by next schema, but not limited to this schema, it will also contain limitations, conflicts and range of other parameters.
$schema: http://json-schema.org/draft-04/schema#
description: Serialized Role object
required: [name, meta, volumes]
title: Role
type: object
properties:
id: {type: integer}
meta:
description: {description: Short description of role functionality,
type: string}
properties:
name: {description: Name that will be shown on UI, type: string}
required: [name, description]
type: object
name: {type: string}
volumes_roles_mapping:
items:
description: Volume allocations for role
properties:
allocate_size:
id: {type: string}
type:
enum: [all, min, full-disk]
required: [allocate_size, id]
type: object
minItems: 1
type: array
volumes_roles_mapping will be used for partitioning of this roles, the same way it is described in openstack.yaml
This object will be served on URIs
PUT/GET/DELETE /releases/(?P<release_id>\d+)/roles/(?P<role_name>\w+)/
POST/GET /releases/(?P<release_id>\d+)/roles/
It is common practice to create multiple endpoints for nested resources, but in case of role - root URI (/roles/) doesnt make much sense because role is isolated per release entity.
Upgrade impact
In case database will be migrated into new state - added roles should be migrated as well. Given that all data will be covered by schema - the only possible limitation is that we need to be smart with code in migration and assume that conditional expression can be changed.
Security impact
No impact
Notifications impact
No impact
Other end user impact
CLI commands will be added to work with API:
Get list of all roles:
fuel role --rel 1
name | id | release_id
controller | 1 | 1
Save full role information to file
fuel role --rel 1 --role controller --file some
Create role from file. Role data is stored in file.
fuel role --rel 1 --create --file some
Update role description. Role data is stored in file.
fuel role --rel 1 --update --file some
Delete role
fuel role --rel 1 --delete --role controller
Performance Impact
No impact
Plugin impact
Maybe in future described schema will be reused for role entity in plugin.
Other deployer impact
Will allow to easily create new role and attach any tasks to it for deployment.
Developer impact
No impact
Implementation
Assignee(s)
- Primary assignee:
-
dshulyak
Work Items
- Implement REST Api for roles
- Implement CLI commands
- Write documentation on added REST Api and CLI command
Dependencies
No dependencies
Testing
Unit tests coverage, and manual tests.
Optionally system test can be implemented that will deploy ceph-mon, or neutron l3 agent as separate role, but it depends on library state of things
Documentation Impact
Documentation will be improved to contain
References
No references