From 756973392675b45bd8d501163ce13b92badaf4bd Mon Sep 17 00:00:00 2001 From: John Kung Date: Wed, 17 Oct 2018 10:14:34 -0400 Subject: [PATCH] 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 --- ...le-system-configuration-from-inventory.rst | 425 ++++++++++++++++++ 1 file changed, 425 insertions(+) create mode 100644 specs/2019.03/approved/sysinv_2002950-decouple-system-configuration-from-inventory.rst diff --git a/specs/2019.03/approved/sysinv_2002950-decouple-system-configuration-from-inventory.rst b/specs/2019.03/approved/sysinv_2002950-decouple-system-configuration-from-inventory.rst new file mode 100644 index 0000000..769e9be --- /dev/null +++ b/specs/2019.03/approved/sysinv_2002950-decouple-system-configuration-from-inventory.rst @@ -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// + 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