Create Spec: Decouple System/Service Configuration from System Inventory
stx-config project sysinv currently consists of Inventory and Configuration components. Inventory includes Host Management. This creates the spec to decouple Inventory components from System, Storage, Service Configuration and management. Story: 2002950 Task: 22952 Change-Id: I1a4d3b4e2191a14a7919425efe4fcec58de096b3 Signed-off-by: John Kung <john.kung@windriver.com>
This commit is contained in:
parent
8317f38ade
commit
7569733926
|
@ -0,0 +1,425 @@
|
||||||
|
.. This work is licensed under a Creative Commons Attribution 3.0 Unported License. http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
||||||
|
===================================================
|
||||||
|
Decouple System Configuration from System Inventory
|
||||||
|
===================================================
|
||||||
|
|
||||||
|
Storyboard: https://storyboard.openstack.org/#!/story/2002950
|
||||||
|
|
||||||
|
This story decouples System Configuration from System Host
|
||||||
|
Management and Inventory.
|
||||||
|
|
||||||
|
|
||||||
|
Problem description
|
||||||
|
===================
|
||||||
|
|
||||||
|
SysInv currently consists of Inventory and Configuration components.
|
||||||
|
|
||||||
|
The Inventory component performs Host management and physical inventory
|
||||||
|
discovery. The Inventory component interacts with stx-metal and stx-nfv
|
||||||
|
components for host management.
|
||||||
|
|
||||||
|
The Configuration component performs System, Storage configuration and
|
||||||
|
management, and generation of configuration data, such as for puppet
|
||||||
|
hierdata or helm charts.
|
||||||
|
|
||||||
|
Currently, the inventory resources are coupled to configuration resources
|
||||||
|
via its relational data model and does not allow external configuration
|
||||||
|
services.
|
||||||
|
|
||||||
|
|
||||||
|
Use Cases
|
||||||
|
=========
|
||||||
|
|
||||||
|
The decoupled system provides the same functional capabilities as the
|
||||||
|
coupled SysInv. The physical and logical resource management are
|
||||||
|
decoupled for a focused metal management and a more flexible logical
|
||||||
|
resource management framework.
|
||||||
|
|
||||||
|
Allow Inventory Host Management component to interact with the plugin
|
||||||
|
Configuration to create the required configuration. The plugin
|
||||||
|
allows the bind in of abstract configuration methods required for the
|
||||||
|
Inventory host management operations. This increases flexibility to
|
||||||
|
provide alternative logical configuration drivers.
|
||||||
|
|
||||||
|
Configuration obtains Inventory data via GET request on the
|
||||||
|
Inventory REST API resources. This allows Configuration to develop
|
||||||
|
with a published API.
|
||||||
|
|
||||||
|
Upversion to oslo standard libraries to facilitate Developer integration
|
||||||
|
of components.
|
||||||
|
|
||||||
|
Allow move of Inventory component to stx-metal from stx-config for
|
||||||
|
architectural alignment of bare metal management.
|
||||||
|
inventory depends on interfaces with stx-metal; systemconfig does
|
||||||
|
not depend upon stx-metal.
|
||||||
|
stx-metal is thus focused on physical inventory and bare metal management.
|
||||||
|
|
||||||
|
|
||||||
|
Proposed change
|
||||||
|
===============
|
||||||
|
|
||||||
|
Create separate Inventory database, and Inventory services for REST api,
|
||||||
|
conductor and agent. The configuration driver is developed as a plugin
|
||||||
|
to Inventory for configuration.
|
||||||
|
|
||||||
|
Update Inventory python client to support sessions. This facilitates
|
||||||
|
keystone token management, for consumers such as SystemConfiguration
|
||||||
|
and Distributed Cloud.
|
||||||
|
|
||||||
|
Create separate Configuration database, and Configuration services for api,
|
||||||
|
conductor, and agent.
|
||||||
|
The high availability aspect of the api and conductor services are managed
|
||||||
|
by stx-ha; and agent by stx-metal pmon.
|
||||||
|
|
||||||
|
Update datamodels to decouple Inventory from Configuration.
|
||||||
|
Relationships between Inventory and Configuration database tables are removed
|
||||||
|
and referenced externally via each resource's globally unique identifier.
|
||||||
|
Information required between services are obtained via the service's REST API.
|
||||||
|
|
||||||
|
Update infrastructure to reference the oslo standard libraries.
|
||||||
|
|
||||||
|
|
||||||
|
Alternatives
|
||||||
|
============
|
||||||
|
|
||||||
|
Alternatively, maintain SysInv as combined Inventory and Config with its
|
||||||
|
current built-in puppet and helm configuration drivers. Update to allow plugin
|
||||||
|
of alternative Configuration drivers based upon its Sysinv service
|
||||||
|
configuration.
|
||||||
|
|
||||||
|
Advantages:
|
||||||
|
* Facilitates access to data required for configuration without
|
||||||
|
requiring an external REST API, since internal database reference.
|
||||||
|
* Maintains referential integrity when inventory updates without requiring
|
||||||
|
external notification or audit.
|
||||||
|
* Upgrades: database is not split across different services.
|
||||||
|
* Lower development cost as a separate API, service is not created and
|
||||||
|
data model split could still have some interdependencies.
|
||||||
|
|
||||||
|
Disadvantages:
|
||||||
|
* Interdependencies between inventory and configuration hinder
|
||||||
|
introduction of alternative configuration drivers, and raise risk of
|
||||||
|
introducing additional dependencies between the physical inventory and
|
||||||
|
baremetal management and logical configuration management.
|
||||||
|
* Referential integrity only applies to internal configuration
|
||||||
|
implementation with access to data model. Formal contract for API is
|
||||||
|
still required when introducing flexibility of an external
|
||||||
|
configuration driver.
|
||||||
|
* Coupling physical and logical configuration resources lessens flexibility
|
||||||
|
of each component to evolve independently.
|
||||||
|
* The Inventory and Host bare-metal management component remains
|
||||||
|
within stx-config.
|
||||||
|
* Configuration Resources which are populated could result in changes to
|
||||||
|
Inventory Resource data; thus the datamodel split would
|
||||||
|
still be required.
|
||||||
|
|
||||||
|
|
||||||
|
Data model impact
|
||||||
|
=================
|
||||||
|
|
||||||
|
The current datamodel relations which reference the split Inventory into
|
||||||
|
Configuration component needs to be removed from the service.
|
||||||
|
Configuration will obtain the required reference based upon the resource uuid
|
||||||
|
which it GETs from the Inventory API.
|
||||||
|
|
||||||
|
The SysInv datamodels are split according to:
|
||||||
|
|
||||||
|
Inventory:
|
||||||
|
* Host
|
||||||
|
* System - (Inventory reference) - uuid
|
||||||
|
* Ports
|
||||||
|
* Lldp
|
||||||
|
* Pci_devices
|
||||||
|
* Disks
|
||||||
|
* Cpus
|
||||||
|
* Memory
|
||||||
|
* Sensors,
|
||||||
|
* SensorGroups
|
||||||
|
|
||||||
|
Configuration:
|
||||||
|
* System
|
||||||
|
* Host, for configuration host info such as config_status
|
||||||
|
* Interfaces
|
||||||
|
* Networks
|
||||||
|
* Interface_Networks
|
||||||
|
* Addresses
|
||||||
|
* AddressPools
|
||||||
|
* Routes
|
||||||
|
* Helm_overrides
|
||||||
|
* Certificates
|
||||||
|
* Community
|
||||||
|
* ControllerFS
|
||||||
|
* DNS
|
||||||
|
* DRBDConfig
|
||||||
|
* NTP
|
||||||
|
* PTP
|
||||||
|
* RemoteLogging
|
||||||
|
* ServiceParameter
|
||||||
|
* Storage: lvgs, pvs, clusters, peers, partition, ceph_mon, journal
|
||||||
|
* Storage: storage_backend, _ceph, _external, _lvm, _file, _tiers,
|
||||||
|
* TpmConfig, Tpmdevices
|
||||||
|
* User
|
||||||
|
|
||||||
|
|
||||||
|
REST API impact
|
||||||
|
===============
|
||||||
|
|
||||||
|
Existing APIs from SysInv are migrated to Inventory or Configuration.
|
||||||
|
* New Configuration APIs are introduced and migrated APIs from Inventory
|
||||||
|
are deprecated.
|
||||||
|
* Remove the ‘i’ prefix in URL resource, where applicable.
|
||||||
|
|
||||||
|
There are no policy changes. admin was required to access the SysInv API,
|
||||||
|
and is required for the Inventory and Configuration APIs.
|
||||||
|
|
||||||
|
New Configuration APIs to support the generation of configuration for the host:
|
||||||
|
PUT v1/hosts/<host_uuid>/<action>
|
||||||
|
The following actions are required:
|
||||||
|
* configure
|
||||||
|
* configure_check
|
||||||
|
* check whether config is sufficient (e.g. for host-unlock)
|
||||||
|
* update_operational
|
||||||
|
* For storage host, config performs update_add_ceph_state
|
||||||
|
disable_check
|
||||||
|
* Determines whether host config may be disabled
|
||||||
|
(i.e. pre host-lock)
|
||||||
|
|
||||||
|
|
||||||
|
Security impact
|
||||||
|
===============
|
||||||
|
|
||||||
|
Security of the new Configuration service is equivalent to Sysinv:
|
||||||
|
* systemconfig-api REST API service with keystone authentication and
|
||||||
|
haproxy for https configured oam interface.
|
||||||
|
* api service requires admin keystone policy and runs under
|
||||||
|
systemconfig user privilege.
|
||||||
|
* database, amqp/rabbit access are protected by username and password.
|
||||||
|
|
||||||
|
|
||||||
|
Other end user impact
|
||||||
|
=====================
|
||||||
|
|
||||||
|
A new python-client, python-systemconfigclient is introduced for the
|
||||||
|
Configuration component. The systemconfig cli will retain 'system',
|
||||||
|
whereas the inventory cli will be under 'inventory'.
|
||||||
|
|
||||||
|
The interface will no longer be automatically created. Previously, in the
|
||||||
|
case of AE config, interfaces need to be configured to 'none' before being
|
||||||
|
configured again. This transition is no longer required in this case.
|
||||||
|
|
||||||
|
|
||||||
|
Performance Impact
|
||||||
|
==================
|
||||||
|
|
||||||
|
With Sysinv Decoupling, additional REST API calls are required between the
|
||||||
|
independent Inventory and Configuration components.
|
||||||
|
|
||||||
|
In particular, the following additional REST API interactions:
|
||||||
|
* Inventory notifies Configuration via REST API to perform
|
||||||
|
host configuration action
|
||||||
|
* Configuration requests up-to-date view on configuration action,
|
||||||
|
the scope is generally limited to the amount of data to be transferred
|
||||||
|
for the host inventory resource.
|
||||||
|
* Periodic audits from system config is required to ensure the Inventory
|
||||||
|
Hosts view is accurate and up-to-date.
|
||||||
|
|
||||||
|
|
||||||
|
Other deployer impact
|
||||||
|
=====================
|
||||||
|
|
||||||
|
Initial Bootstrap (config_controller) now initializes both Inventory and
|
||||||
|
Configuration services and populates the services with the required host
|
||||||
|
and configuration data. This will be transparent to the users.
|
||||||
|
|
||||||
|
The association of interfaces to ethernet_ports was performed by default
|
||||||
|
to a single interface previously. With the separation of the ports and
|
||||||
|
interfaces data model, the admin must now associate the interface to
|
||||||
|
the port as required (ie. via the system host-if-add).
|
||||||
|
|
||||||
|
Support for profiles is removed. The current implementation requires
|
||||||
|
reference between inventory and configuration resources.
|
||||||
|
|
||||||
|
|
||||||
|
Developer impact
|
||||||
|
=================
|
||||||
|
|
||||||
|
* A new driver API for Configuration is introduced.
|
||||||
|
|
||||||
|
|
||||||
|
Upgrade impact
|
||||||
|
===============
|
||||||
|
|
||||||
|
Upgrades from N-1 are not supported for this update.
|
||||||
|
|
||||||
|
|
||||||
|
Implementation
|
||||||
|
==============
|
||||||
|
|
||||||
|
Assignee(s)
|
||||||
|
===========
|
||||||
|
|
||||||
|
Primary assignee:
|
||||||
|
john.kung@windriver.com
|
||||||
|
louie.kwan@windriver.com
|
||||||
|
|
||||||
|
Other contributors:
|
||||||
|
|
||||||
|
|
||||||
|
Repos Impacted
|
||||||
|
==============
|
||||||
|
|
||||||
|
stx-config: systemconfig
|
||||||
|
python-systemconfigclient
|
||||||
|
stx-metal pmon is configured to manage systemconfig-agent.
|
||||||
|
|
||||||
|
stx-ha: SM management of systemconfig and inventory.
|
||||||
|
|
||||||
|
stx-metal: mtce integration
|
||||||
|
wrsroot user update via systemconfig-api rather than
|
||||||
|
inventory-api.
|
||||||
|
|
||||||
|
stx-nfv: vim interacts with the inventory and configuration components
|
||||||
|
and will need a new client to access the host information
|
||||||
|
from both the inventory and configuration components
|
||||||
|
|
||||||
|
distributedcloud:
|
||||||
|
update to api-proxy, dcorch engine to bind to systemconfig
|
||||||
|
optional: simplify framework to utilize keystone sessions
|
||||||
|
as per other resources managed by dcorch.
|
||||||
|
|
||||||
|
stx-gui: update to reference inventory and configuration apis.
|
||||||
|
datamodels within api/sysinv.py need to be refactored to
|
||||||
|
fill in the data from the respective service.
|
||||||
|
|
||||||
|
stx-clients: add python-systemconfigclient to remoteclients
|
||||||
|
|
||||||
|
stx-integ: ceph-manager deprecate
|
||||||
|
restapi-doc updates
|
||||||
|
|
||||||
|
|
||||||
|
Work Items
|
||||||
|
==========
|
||||||
|
|
||||||
|
Phase 1: Create new configuration services and update required
|
||||||
|
infrastructure
|
||||||
|
|
||||||
|
* systemconfig:
|
||||||
|
* data model: decouple from internal inventory resource references
|
||||||
|
* create systemconfig-api
|
||||||
|
* REST API for new config actions (see REST API section)
|
||||||
|
* propagate sysinv-api to systemconfig-api
|
||||||
|
* obtain inventory resources as required from inventory api
|
||||||
|
* remove 'i' prefix from URL
|
||||||
|
* create systemconfig-conductor
|
||||||
|
* update framework to use standard libraries rather than the internal
|
||||||
|
libraries in sysinv (e.g. openstack.common is migrated to oslo_service,
|
||||||
|
paste, keystoneauth1, oslo_db, oslo_messaging, oslo_log)
|
||||||
|
|
||||||
|
* sysinv:
|
||||||
|
* data model: decouple from configuration resource references
|
||||||
|
* update REST API
|
||||||
|
|
||||||
|
* ha management:
|
||||||
|
* stx-ha service-management of systemconfig-api, systemconfig-conductor
|
||||||
|
* stx-metal pmon service management of systemconfig-agent(via configuration
|
||||||
|
* implemented in stx-config)
|
||||||
|
|
||||||
|
* vim:
|
||||||
|
* update VIM to handle sysinv API changes
|
||||||
|
|
||||||
|
* update config_controller bootstrap to systemconfig. Startup services,
|
||||||
|
populate initial configuration.
|
||||||
|
|
||||||
|
* python-sysinvclient:
|
||||||
|
* update CLI and client to include keystone session support
|
||||||
|
for token management.
|
||||||
|
|
||||||
|
* python-systemconfigclient:
|
||||||
|
* create CLI and client
|
||||||
|
|
||||||
|
|
||||||
|
Phase 2: Decouple Major focus areas
|
||||||
|
|
||||||
|
Major decoupling focus areas:
|
||||||
|
* interface decoupling
|
||||||
|
ethernet_ports in inventory and interfaces in systemconfig
|
||||||
|
|
||||||
|
* remove interface_id from ports table in inventory
|
||||||
|
* remove autoprovisioning of interfaces in systemconfig
|
||||||
|
|
||||||
|
* storage decoupling
|
||||||
|
|
||||||
|
* disk in inventory and partition/lvg/stor in config
|
||||||
|
* ceph_manager
|
||||||
|
* deprecate ceph-manager: move rpc endpoint functionality into
|
||||||
|
systemconfig-conductor, ceph-manger-audit to config-audit,
|
||||||
|
and alarm monitoring into collectd plugin.
|
||||||
|
|
||||||
|
Create plugin model in Inventory for configuration. The plugin is
|
||||||
|
implemented as a stevedore driver and selection of driver is driven by
|
||||||
|
config. The plugin allows the bind in of abstract configuration methods
|
||||||
|
required for the Inventory host management operations.
|
||||||
|
|
||||||
|
Phase 3: Decoupling of remaining resources and Integration
|
||||||
|
|
||||||
|
* decouple remaining configuration resources from sysinv
|
||||||
|
|
||||||
|
* distributedcloud
|
||||||
|
* proxy SystemController systemconfig-api requests into dcorch-engine
|
||||||
|
* dcorch-engine to interface systemconfig-api for configuration
|
||||||
|
* dcmananger-api to interface with python-systemconfigclient
|
||||||
|
(network list, address_pools, routes)
|
||||||
|
|
||||||
|
* stx-gui inventory dashboard updated to reference the inventory and
|
||||||
|
configuration REST APIs
|
||||||
|
|
||||||
|
* tox unit tests (this could be started earlier, however initial focus
|
||||||
|
is verification in lab)
|
||||||
|
|
||||||
|
|
||||||
|
Dependencies
|
||||||
|
============
|
||||||
|
|
||||||
|
2002827 Decouple Service Management REST API from sysinv
|
||||||
|
https://storyboard.openstack.org/#!/story/2002827
|
||||||
|
|
||||||
|
2002828 Decouple Fault Management from stx-config
|
||||||
|
https://storyboard.openstack.org/#!/story/2002828
|
||||||
|
|
||||||
|
|
||||||
|
Testing
|
||||||
|
=======
|
||||||
|
|
||||||
|
* Bootstrap Initialization and Configuration
|
||||||
|
* Host Configuration and Management
|
||||||
|
* Interface Configuration
|
||||||
|
* Storage Configuration
|
||||||
|
* Service Parameter Configuration
|
||||||
|
* HA verification
|
||||||
|
* Distributed Cloud Verification
|
||||||
|
* Horizon GUI
|
||||||
|
* Devstack
|
||||||
|
|
||||||
|
|
||||||
|
Documentation Impact
|
||||||
|
====================
|
||||||
|
|
||||||
|
systemconfig and sysinv REST API documentation
|
||||||
|
End User Guide: installation and configuration
|
||||||
|
|
||||||
|
|
||||||
|
References
|
||||||
|
==========
|
||||||
|
|
||||||
|
|
||||||
|
History
|
||||||
|
=======
|
||||||
|
|
||||||
|
.. list-table:: Revisions
|
||||||
|
:header-rows: 1
|
||||||
|
|
||||||
|
* - Release Name
|
||||||
|
- Description
|
||||||
|
* - 2019.03
|
||||||
|
- Introduced
|
Loading…
Reference in New Issue