A recent devstack change  has dropped all KEYSTONE_AUTH_* variables except KEYSTONE_AUTH_URI. Use KEYSTONE_SERVICE_* variables instead. Another change  switched off the creation of an admin endpoint for keystone, which we need. Get or create it again until we update Fenix to stop using it. Update service name/type and endpoint URLs accordingly.  https://review.opendev.org/c/openstack/devstack/+/735472  https://review.opendev.org/c/openstack/devstack/+/777345 Change-Id: I3c876344b4d29d3de536910f2997a57ab1d2d320
|4 weeks ago|
|devstack||4 weeks ago|
|doc||4 weeks ago|
|fenix||2 years ago|
|releasenotes||3 years ago|
|.coveragerc||3 years ago|
|.gitignore||3 years ago|
|.gitreview||3 years ago|
|.mailmap||3 years ago|
|.stestr.conf||3 years ago|
|.zuul.yaml||4 weeks ago|
|CONTRIBUTING.rst||2 years ago|
|HACKING.rst||3 years ago|
|LICENSE||3 years ago|
|README.rst||2 years ago|
|babel.cfg||3 years ago|
|lower-constraints.txt||4 weeks ago|
|requirements.txt||4 weeks ago|
|setup.cfg||2 years ago|
|setup.py||3 years ago|
|test-requirements.txt||4 weeks ago|
|tox.ini||2 years ago|
OpenStack host maintenance and upgrade in interaction with the application
Fenix implements rolling infrastructure maintenance and upgrade in interaction with the application on top of it. In Telco world we talk about VNFM, but one can implement his own simple manager for any application.
Infrastructure admin can call Fenix API to start a maintenance workflow session. This session will make needed maintenance and upgrade operations to infrastructure in interaction with the application manager to guarantee zero downtime for its service. Interaction gives the ability for the application manager to know about new capabilities coming over maintenance to make his own upgrade. The application can have a time window to finish what he is doing, make own action to re-instantiate his instance or have Fenix to make the migration. Also scaling applications or retirement will be possible.
As Fenix has project-specific messaging with information about instances affected towards the application manager, it will also have admin-level messaging. This messaging can tell what host is down for maintenance, back in use, added or retired. Any infrastructure component can catch this information as needed.
Fenix also works with "one-click". Infrastructure admin just creates the workflow session he wants and all needed software changes are automatically downloaded, the workflow is run to wanted hosts according to the request and depending on how the used workflow plug-in and action plug-ins are implemented.
In the NFV Fenix needs to be supported by infrastructure admin UI, VNFM and VNF implementation. Fenix itself should be integrated into infrastructure to be used it the infrastructure maintenance, upgrade, scaling and life-cycle operations.
- Free software: Apache license
- Documentation: https://fenix.readthedocs.io/en/latest/index.html
- Developer Documentation: https://wiki.openstack.org/wiki/Fenix
- Source: https://opendev.org/x/fenix
- Running sample workflows: https://opendev.org/x/fenix/src/branch/master/fenix/tools/README.md
- Bug tracking and Blueprints: https://storyboard.openstack.org/#!/project/x/fenix
- How to contribute: https://docs.openstack.org/infra/manual/developers.html
- Fenix Specifications