Refactor gateway kernel management to achieve a degree of consistency #483
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue #455 correctly points out an inconsistency between the
GatewayKernelManager
vs the otherMappingKernelManager
instances within the server in that itsget_kernel()
method doesn't return aKernelManager
instance, but rather a JSON object which corresponds to the model returned from the configured Gateway Server that corresponds the targeted kernel manager.This pull request introduces both a
GatewayKernelManager
(renaming the previous GKM toGatewayMappingKernelManager
) and aGatewayKernelClient
class that essentially proxy all requests (and responses) to (from) the configured Gateway Server instance.It should be noted that these proxy objects do not support the full functionality of regular
KernelManager
andKernelClient
instances but strive to address a certain degree of usability to accomplish a resemblance of consistency across kernel manager/client instances.Resolves #455
(Note: the renaming of the gateway mapping kernel manager is not a compatibility issue because subclassing is currently not supported.)