ICE Provisioning

Aspects of Avo Assure ICE Provisioning

Two types of ICE can be provisioned:

1. Normal (Ad-hoc) ICE ICE which is operated by manual users for Scraping, Debug, and Execution. This can also be used for Scheduling and Remote execution if needed.

2. CI/CD ICE ICE which is operated by Machines dedicated only to Remote Execution and Scheduling.

1. Log in as Admin User. Navigate to ICE Provisioning Section.

On-Click of ICE Provision Section

2. Select the type of ICE required and specify the required details [ICE Name and User (If ICE Type selected is ‘Normal’)].

ICE details are filled

Note:

• ICE Names cannot be changed or deleted.

• An individual user CAN have more than one ICE tagged to their username.

• An individual ICE CAN NOT be tagged to more than one user. (If the Admin tries to assign a user with an ICE that has already been tagged to another user or specifies an existing ice name, then on ‘Provisioning’ the Admin will be prompted as follows: "ICE Provision Failed! ICE Name or User already exists")

3. Click on ‘Provision’. The Admin will be prompted as follows:

ICE provisioning successful

4. Click on ‘Ok’. The encrypted ICE registration token will be generated and displayed. Copy and Download options are available for the token.

Registration Token and provisioned entries updated

5. The generated token should be saved until the completion of the ICE registration process. For more information, refer here.

ICE States and Actions

An ICE can have the following states:

1. Not registered: There is no token provisioned for the ICE. In this case, ICE will not be able to establish any connection with the server.

2. Provisioned: The token is generated (by the Admin) on the server for the ICE, but in the ICE client the token has not been specified. In this case, also, ICE will not be able to establish any connection with the server.

3. Registered: The token generated (by the Admin) is specified to the ICE when ICE is started. Connections can be established once the ICE is in this state.

Various states of ICEs

After a token has been successfully provisioned, the following actions can be performed by the Admin depending on the requirements specified for each case:

Case 1: Re-provisioning

If the token is lost before ICE registration, then the Admin should re-provision the token.

To ‘Reprovision’ if token is lost

Case 2: Reregistration

If, after successful ICE registration, the ICE crashes/ICE has to be registered again in the same machine or different machine, then the Admin should reregister the ICE.

To ‘Reregister’ if reregistration is required

Case 3: Deregistration

If a registered ICE is no longer required, then the Admin should deregister the ICE. The ICE client will then be deactivated. Connection requests from these ICE clients will not be served after deregistration.

To ‘Deregister’ if ICE should be deactivated

Server-side working

On ‘Reprovisioning’:

• Find the entry in “ice_tokens” with given ice_token, ice_type, and ice_name.

• Status remains the same as “provisioned”.

• Generate a new token and replace the existing token with a new one.

• ‘Provisionedon’ value changes to the current date.

On ‘Reregistration’:

• Find the entry in “ice_tokens” with given ice_token, ice_type, and ice_name.

• Status is changed from “registered” to “provisioned".

• Generate a new token and replace the existing token with a new one.

• ‘Provisionedon’ value changes to the current date.

On ‘Deregistration’:

• Find the entry in “ice_tokens” with given ice_token, ice_type, and ice_name.

• Status is changed from “registered” to “deregistered".

• Generate a new token and replace the existing token with a new one.

• ‘Deregisteredon’ key is added to DB and value set to current Date.