| 2017-08-04 02:55:50 |
Ruby Loo |
description |
Now that we have the rolling upgrades infrastructure in place, let's refine it! During a rolling upgrade, the new ironic-api and ironic-conductor services are pinned so that they use the same RPC vesions and IronicObject versions as the older service (thus allowing them to talk to each other without getting upset).
For the ironic-api service, we should also pin the API microversion. Pinning this would:
- make it easier for the new ironic-api services to know when/how to reject new features that the old ironic-api services cannot handle. They would return HTTP code 406 (Not Acceptable)
- change the response header so that the maximum API version would be the pinned version
The code changes to do this are fairly simple:
- change ironic.common.release_mappings.RELEASE_MAPPING[release]: add a new key 'api' to the dictionary; the value will be a string, the latest API version (e.g. '1.34'), that is supported by that release.
- in ironic/api/controllers/v1/utils.py, add a new method, something like:
from oslo_utils import versionutils
from ironic.common import release_mappings
def check_allow_api_version():
pin = CONF.pin_release_version
if not pin:
return
api_version = versionutils.convert_version_to_tuple(
release_mappings.RELEASE_MAPPING[pin]['api'])
if pecan.request.version.minor < api_version[1]:
raise exception.NotAcceptable()
- in ironic/api/controllers/v1/versions.py, change MAX_VERSION_STRING so that if pinned, it will be set to the pinned version. |
Now that we have the rolling upgrades infrastructure in place, let's refine it! During a rolling upgrade, the new ironic-api and ironic-conductor services are pinned so that they use the same RPC vesions and IronicObject versions as the older service (thus allowing them to talk to each other without getting upset).
For the ironic-api service, we should also pin the API microversion. Pinning this would:
- make it easier for the new ironic-api services to know when/how to reject new features that the old ironic-api services cannot handle. They would return HTTP code 406 (Not Acceptable)
- change the response header so that the maximum API version would be the pinned version |
|
| 2017-11-20 18:05:04 |
Ruby Loo |
description |
Now that we have the rolling upgrades infrastructure in place, let's refine it! During a rolling upgrade, the new ironic-api and ironic-conductor services are pinned so that they use the same RPC vesions and IronicObject versions as the older service (thus allowing them to talk to each other without getting upset).
For the ironic-api service, we should also pin the API microversion. Pinning this would:
- make it easier for the new ironic-api services to know when/how to reject new features that the old ironic-api services cannot handle. They would return HTTP code 406 (Not Acceptable)
- change the response header so that the maximum API version would be the pinned version |
Now that we have the rolling upgrades infrastructure in place, let's refine it! During a rolling upgrade, the new ironic-api and ironic-conductor services are pinned so that they use the same RPC vesions and IronicObject versions as the older service (thus allowing them to talk to each other without getting upset).
For the ironic-api service, we should also pin the API microversion. Pinning this would:
- make it easier for the new ironic-api services to know when/how to reject new features that the old ironic-api services cannot handle. They would return HTTP code 406 (Not Acceptable)
- change the response header so that the maximum API version would be the pinned version
This would take effect using the same [DEFAULT]pin_release_version configuration option, so no extra things for the operator to do .
Documentation will be updated to reflect this. |
|
