| 2020-08-07 08:11:32 |
Bogdan Dobrelya |
bug |
|
|
added bug |
| 2020-08-07 08:23:49 |
Bogdan Dobrelya |
tripleo: importance |
Undecided |
Medium |
|
| 2020-08-07 08:23:51 |
Bogdan Dobrelya |
tripleo: milestone |
|
victoria-3 |
|
| 2020-08-07 08:26:07 |
Bogdan Dobrelya |
summary |
Allow per service configuration option to keep its systemd service unmanaged |
Allow per service configuration option to keep its systemd service unmanaged by tripleo-container-manager |
|
| 2020-08-07 08:26:57 |
Bogdan Dobrelya |
description |
It may be a good idea to create a facility to ignore unmanned systemd units for service containers. While keeping its corresponding containers under configuration, no service nor the container should be started/enabled in that mode.
That would allow users to manually disable some non-A/A or non H/A services in systemd, like cinder-volume with some 3rd party drivers, but still have its containers up to date and be ready for enablement, once the time comes.
That could be a service-specific config option in containers config, like 'managed: true' by default, and controlled via a corresponding Heat parameter, e.g. CinderVolumeUnmanaged, or role based perhaps. |
It may be a good idea to create a facility to ignore unmanned systemd units for service containers. While keeping its corresponding containers under configuration (the json configs and image up to date), no service nor the container should be started/enabled in that mode.
That would allow users to manually disable some non-A/A or non H/A services in systemd, like cinder-volume with some 3rd party drivers, but still have its containers up to date and be ready for enablement, once the time comes.
That could be a service-specific config option in containers config, like 'managed: true' by default, and controlled via a corresponding Heat parameter, e.g. CinderVolumeUnmanaged, or role based perhaps. |
|
| 2020-08-07 08:27:33 |
Bogdan Dobrelya |
description |
It may be a good idea to create a facility to ignore unmanned systemd units for service containers. While keeping its corresponding containers under configuration (the json configs and image up to date), no service nor the container should be started/enabled in that mode.
That would allow users to manually disable some non-A/A or non H/A services in systemd, like cinder-volume with some 3rd party drivers, but still have its containers up to date and be ready for enablement, once the time comes.
That could be a service-specific config option in containers config, like 'managed: true' by default, and controlled via a corresponding Heat parameter, e.g. CinderVolumeUnmanaged, or role based perhaps. |
It may be a good idea to create a facility to ignore unmanned systemd units for service containers. While keeping its corresponding containers under configuration (the json/*.conf files and its image up to date), no service nor the container should be started/enabled in that mode.
That would allow users to manually disable some non-A/A or non H/A services in systemd, like cinder-volume with some 3rd party drivers, but still have its containers up to date and be ready for enablement, once the time comes.
That could be a service-specific config option in containers config, like 'managed: true' by default, and controlled via a corresponding Heat parameter, e.g. CinderVolumeUnmanaged, or role based perhaps. |
|
| 2020-08-07 08:28:08 |
Bogdan Dobrelya |
description |
It may be a good idea to create a facility to ignore unmanned systemd units for service containers. While keeping its corresponding containers under configuration (the json/*.conf files and its image up to date), no service nor the container should be started/enabled in that mode.
That would allow users to manually disable some non-A/A or non H/A services in systemd, like cinder-volume with some 3rd party drivers, but still have its containers up to date and be ready for enablement, once the time comes.
That could be a service-specific config option in containers config, like 'managed: true' by default, and controlled via a corresponding Heat parameter, e.g. CinderVolumeUnmanaged, or role based perhaps. |
It may be a good idea to create a facility to ignore unmanned systemd units for service containers. While keeping its corresponding containers under configuration (the json/*.conf files and its image up to date), no the service unit nor the container itself should be started/enabled in that mode.
That would allow users to manually disable some non-A/A or non H/A services in systemd, like cinder-volume with some 3rd party drivers, but still have its containers up to date and be ready for enablement, once the time comes.
That could be a service-specific config option in containers config, like 'managed: true' by default, and controlled via a corresponding Heat parameter, e.g. CinderVolumeUnmanaged, or role based perhaps. |
|
| 2020-08-07 08:28:58 |
Bogdan Dobrelya |
description |
It may be a good idea to create a facility to ignore unmanned systemd units for service containers. While keeping its corresponding containers under configuration (the json/*.conf files and its image up to date), no the service unit nor the container itself should be started/enabled in that mode.
That would allow users to manually disable some non-A/A or non H/A services in systemd, like cinder-volume with some 3rd party drivers, but still have its containers up to date and be ready for enablement, once the time comes.
That could be a service-specific config option in containers config, like 'managed: true' by default, and controlled via a corresponding Heat parameter, e.g. CinderVolumeUnmanaged, or role based perhaps. |
It may be a good idea to create a facility to ignore unmanned systemd units for service containers. While keeping its corresponding containers under configuration (the json/*.conf files and its image up to date), no the service unit nor the container itself should be started/enabled in that mode.
That would allow users to manually manage some non-A/A or non H/A services in systemd, like cinder-volume with some 3rd party drivers, but still have its containers up to date and be ready for enablement, once the time comes.
That could be a service-specific config option in containers config, like 'managed: true' by default, and controlled via a corresponding Heat parameter, e.g. CinderVolumeUnmanaged, or role based perhaps. |
|
| 2020-08-07 08:32:08 |
Bogdan Dobrelya |
description |
It may be a good idea to create a facility to ignore unmanned systemd units for service containers. While keeping its corresponding containers under configuration (the json/*.conf files and its image up to date), no the service unit nor the container itself should be started/enabled in that mode.
That would allow users to manually manage some non-A/A or non H/A services in systemd, like cinder-volume with some 3rd party drivers, but still have its containers up to date and be ready for enablement, once the time comes.
That could be a service-specific config option in containers config, like 'managed: true' by default, and controlled via a corresponding Heat parameter, e.g. CinderVolumeUnmanaged, or role based perhaps. |
It may be a good idea to create a facility to ignore unmanned systemd units for service containers. While keeping its corresponding containers under configuration, no service nor the container should be started/enabled in that mode.
That would allow users to manually disable some non-A/A or non H/A services in systemd, like cinder-volume with some 3rd party drivers, or just putting individual services into maintenance without touching the full node. And still having its containers configs/images up to date and be ready for enablement, once the time comes.
That could be a service-specific config option in containers config, like 'managed: true' by default, and controlled via a corresponding Heat parameter, e.g. CinderVolumeUnmanaged, or role based perhaps. |
|
| 2020-08-07 08:33:16 |
Bogdan Dobrelya |
tripleo: importance |
Medium |
Wishlist |
|
| 2020-08-12 10:22:54 |
Bogdan Dobrelya |
tags |
|
queens-backport-potential train-backport-potential ussuri-backport-potential |
|
| 2020-08-12 10:26:12 |
Bogdan Dobrelya |
tripleo: status |
New |
In Progress |
|
| 2020-08-12 10:26:14 |
Bogdan Dobrelya |
tripleo: assignee |
|
Bogdan Dobrelya (bogdando) |
|
| 2020-08-13 09:08:49 |
Bogdan Dobrelya |
tags |
queens-backport-potential train-backport-potential ussuri-backport-potential |
train-backport-potential ussuri-backport-potential |
|
| 2020-08-21 18:56:00 |
OpenStack Infra |
tags |
train-backport-potential ussuri-backport-potential |
in-stable-ussuri train-backport-potential ussuri-backport-potential |
|
| 2020-11-03 11:56:01 |
Marios Andreou |
tripleo: milestone |
victoria-3 |
wallaby-1 |
|
| 2020-11-06 14:16:13 |
Bogdan Dobrelya |
tripleo: status |
In Progress |
Opinion |
|
