OpenShift container provisioning

Developers
#1

With the work of https://github.com/ManageIQ/manageiq/pull/10737 we can instantiate an OpenShift container template from ManageIQ. Next we need to support OpenShift provisioning through automate.

A typical ManageIQ provisioning automate has pre-provsioning, provisioning, check-provisioned, and post-provisioning steps. The provisioning step connects to a provider to create resources. The check-provisioned step periodically polls from the provider the status of the creation until it finishes, and refreshes the provider afterward.

The OpenShift container template instantiation process creates multiple objects. It is however not a trivial task to implement logic to monitor the overall status of the instantiation if not impossible. There is no single handle to identify the instantiation. We need to monitor the status of all created objects, and way to determine whether an object creation is completed can be different.

After some discussion we suggest not to monitor and wait for the completion of the instantiation. An OpenShift provisioning is consider completed once the instantiate method returns. The provisioning can fail if the method raise errors. The resulting objects will be refreshed and collected in ManageIQ db through OpenShift events. Since each template can create many objects, there may be an impact on the refresh performance if every object triggers a full refresh. We can research whether a target refresh can apply here.

In order to automate the OpenShift template provisioning we need to add a new type to catalog items. Each OpenShift template needs a dedicated service dialog that allows the user to fill in answers to parameters required by the template. Parameters for a template are well defined, so we can have a tool to automatically generate the corresponding service dialog. However the dialog needs to be created in advance through a manual UI operation.

1 Like
#2

During today’s meeting we considered some options that still need to be discussed:

  • Synchronous/Asynchronous operations:
    With the current implementation, the container template instantiation is done synchronously, meaning that we first process a template and wait for openshift response - the processed template including the template parameters (but one should note that nothing is created during this processing). Then, for each of the template objects we send a request to openshift to create this object, and wait for openshift response. However, we do not wait for these objects to be up and running - so if we consider this state as the completion of the instantiation we might relate the current implementation as asynchronous and acceptable from the service catalog point of view. @bill I think we were not clear enough regarding this point so it might be a good start if you clarify it.

  • Using a worker:
    One suggestion is to wrap the template instantiation with a worker operation using MiqQueue. In such a case we still need to decide how exactly we will notify the user regarding the completion status (SUCCEEDED/PARTIAL/FAILED).

  • Partial success - rollback:
    In case that some of the the objects were created successfully but others were not, besides notifying the user regarding this status, we may want to clear up those created objects and actually cancel the template instantiation, so the user would not have to do it manually. We were wondering if openshift already supports this kind of feature - still need to be researched.

#3

If we consider this state as the completion of the instantiation we might relate the current implementation as asynchronous and acceptable from the service catalog point of view. @bill I think we were not clear enough regarding this point so it might be a good start if you clarify it.

We were pretty clear on this in the previous meeting. In fact in the original message:

After some discussion we suggest not to monitor and wait for the completion of the instantiation. An OpenShift provisioning is consider completed once the instantiate method returns.

One suggestion is to wrap the template instantiation with a worker operation using MiqQueue. In such a case we still need to decide how exactly we will notify the user regarding the completion status (SUCCEEDED/PARTIAL/FAILED).

Wrapping the instantiation with a Task is already what the automation framework does. No need to worry on our side.

We were wondering if openshift already supports this kind of feature - still need to be researched.

Of course it’s not supported by OpenShift, the instantiation is on the client side so if we want to rollback we must keep a list of entities that were already created and delete them if we fail at some point.

#4

We talked about using a worker through MiqQueue to do instantiation because we thought it was a synchronous call which returned after all objects were created. This could take a long time and cause our automate timeout. Since @zakiva clarified that we don’t wait for these objects to be up and running, I assume the call actually does not take very long and hence does not need another worker. Still I suggest to send create requests to OpenShift in a multi-thread way to further speed up the instantiation.

It is important that we can report what objects are created by this provisioning. The first step is to refactor the create_objects method to return object type and ID from the provider, even though we do not know their statuses nor they are collected in ManageIQ.

The best will be to wait until the objects are in ManageIQ, then we can properly report them and do post-provisioning tasks. One way to achieve might be though OpenShift events. It is a challenge to add the capability for the automate to listen to and filter events because such implementation never exists.

We need @loicavenel to decide whether it is OK at least for the first round we implement the provisioning as suggested in the original post.