GVP/Current/GVPPEGuide/Provision - Revision history

WikiSysop at 06:45, September 30, 2022

2022-09-30T06:45:49Z

Karl abraham.abel@genesys.com: Published

2021-09-30T18:59:43Z

Published

Karl abraham.abel@genesys.com: Published

2021-07-13T10:58:31Z

Published

Karl abraham.abel@genesys.com: Published

2021-06-30T19:04:58Z

Published

New page

{{Article
|Standalone=No
|DisplayName=Provision Genesys Voice Platform
|Context=Learn how to provision Genesys Voice Platform.
|ComingSoon=No
|Role=Administrator
|Section={{Section
|alignment=Vertical
|Status=No
}}{{Section
|sectionHeading=Tenant provisioning
|alignment=Vertical
|structuredtext=GVP Service Discovery ('''SD''') container is used for provisioning tenant object in GVP Configuration Server and creating application objects for - Configuration Server, Media Control Platform app objects under Resource Manager logical resource group.

===Overview===
GVP Service Discovery ('''SD''') container (running in '''K8s''') does the following:

#Runs a timer that gets invoked every '''<code>1 min</code>''' by default (this is configurable).
#Checks '''Consul''' for the registered MCPs and then checks '''GVP Configuration Server (CS)''' for the MCPs present there and does the necessary addition/removal of MCPs from CS to sync with Consul data.
#Checks the '''<code>tenant-inventory</code>''' configmap in the '''<code>gvp</code>''' namespace of the '''K8s cluster''' and, if configmap is updated from the last run, then based on the new data creates/updates tenant information.
#Note that SD processes <u>one tenant at a time</u>.

The following '''objects''' are created in CS as part of GVP Tenant creation, and unless specified SD uses default values for those objects:

*The '''Tenant''' object itself with properties set in the '''Annex''' section
*The following '''IVR Profiles''':
**IVRAppDefault
**conference
**cpd
**record
**media
*The following '''Transactions''' object (used by '''Recording Uploader'''):
**hybrid_integration

For Tenant creation, the following parameters '''SHOULD''' be specified:

*As part of Tenant provisioning, the tenant is registered to '''GWS''' and you get a '''GWS-CCID'''. This parameter is '''mandatory''' for GVP tenant creation.
*The '''id''' for the tenant is a '''mandatory''' parameter. This can be arbitrary string, but the preferable value is the '''last 4-digits of the GWS-CCID'''.
*The tenant '''name''' parameter is '''preferred''' to be populated.
*The '''default-application''' parameter should be set to '''IVRAppDefault''' always.
*The provisioned parameter should be set to 'true', unless the git pipeline workflow does that.

===Use Case 1 - Deploy New Tenant===

*As mentioned above, deploying a new tenant with SD and CS simply boils down to creating a configmap in your K8s cluster under gvp namespace.

'''Note''': SD doesn't support creating multiple tenants in bulk, so you need to provide one JSON data file per tenant and repeat the process for multiple tenants.

*A bare minimum JSON should contain the minimal set of parameters mentioned above:

{{{!}} class="wikitable" data-macro-name="code" data-macro-id="28a0eb5b-1ec2-4165-84c8-a0b44acf2bb1" data-macro-parameters="language=yml{{!}}title=tenant-2026.json" data-macro-schema-version="1" data-macro-body-type="PLAIN_TEXT"
{{!}} class="wysiwyg-macro-body"{{!}}
{
"name": "CustomerX",
"id": "2026",
"gws-ccid": "285bd12f-5e4a-4c76-ad93-752ee1a82026",
"default-application": "IVRAppDefault"
}
{{!}}}

*Delete the existing '''tenant-inventory''' configmap if any: '''<code>kubectl -n gvp delete configmap tenant-inventory --ignore-not-found</code>'''
*Create the configmap with your JSON file: '''<code>kubectl -n gvp create configmap tenant-inventory --from-file tenant-2026.json</code>'''
*This configmap is mounted as a '''volume''' in SD - so the new JSON is updated in the '''<code>/etc/config</code>''' folder of the SD container.

{{{!}} class="wikitable" data-macro-name="code" data-macro-id="d874fc0d-196f-44bf-836d-3de57a944970" data-macro-parameters="language=bash" data-macro-schema-version="1" data-macro-body-type="PLAIN_TEXT"
{{!}} class="wysiwyg-macro-body"{{!}}
[genesys@gvp-sd-bfcdd567f-8hrzm config]$ pwd
/etc/config
[genesys@gvp-sd-bfcdd567f-8hrzm config]$ ls -ls
total 0
0 lrwxrwxrwx 1 root root 27 May 5 12:59 tenant-2026.json > ..data/tenant 2026.json
{{!}}}

*In the '''next cycle''', SD will detect the new file and process it - thus creating/updating tenant and the associated objects.
*Once processed, SD '''ignores''' the file in subsequent cycles.

===Use Case 2 - Update Existing Tenant===
The mechanism for updating existing tenant is very similar to deploying new tenant. In this case, the existing JSON for the tenant needs to be updated with new parameters.

'''Note''': You MUST always keep the minimal set of parameters present in the JSON even if in the case of update.

====Example 1 - Recording destination provisioning for recording uploader====
WEM provisioning is supported through the '''hybrid_integration''' transactions object. Only change is to specify the additional '''WEM parameters''' in the '''Tenant JSON''' file. An example JSON file with the WEM parameters may look like the following:
{{{!}} class="wikitable" data-macro-name="code" data-macro-id="d6ac7e2e-82e1-4d56-82b4-ddc29d83f923" data-macro-parameters="language=yml" data-macro-schema-version="1" data-macro-body-type="PLAIN_TEXT"
{{!}} class="wysiwyg-macro-body"{{!}}
{
    "name": "CustomerX",
"id": "2026",
"gws-ccid": "285bd12f-5e4a-4c76-ad93-752ee1a82026",
"default-application": "IVRAppDefault",
"provisioned": "true",
    "transactions": {
        "name": "hybrid_integration",
        "recording-uploader.destFolder": {
            "destType": "Folder"
        },
        "recording-uploader.destFolder.mediaUpload": {
            "folder_path": "/rup/recordings"
        }
    }
}
{{!}}}
The rest of the steps are the same as above. Delete existing configmap and create new with updated JSON.
|Status=No
}}
|PEPageType=55cef4ff-9306-4313-8fd8-377282a38478
}}

@@ Line 45: / Line 45: @@
 *The tenant '''name''' parameter is '''preferred''' to be populated.
 *The '''default-application''' parameter should be set to '''IVRAppDefault''' always.
-*The provisioned parameter should be set to 'true', unless the git pipeline workflow does that.
+*The provisioned parameter should be set to 'true', unless the git pipeline workflow does that. Once this is set, then Service Discovery populates the tenant's contact center id (uuid) and the tenant's default IVR-Profile's dbid in Consul KV store.
 ===Use Case 1 - Deploy New Tenant===
@@ Line 115: / Line 130: @@
 |anchor=PNG
 |alignment=Vertical
-|structuredtext=You can provision Nexus in GVP. The following sections include information on provisioning Nexus:
+|structuredtext====Integrating MCP to Nexus for Dialogflow voicebot===
-*{{Link-AnywhereElse|product=GVP|version=Current|manual=GVPPEGuide|topic=Configure|anchor=MCPOHC}}
+===Integrating MCP to Nexus for Agent Assist===
-The second table in the section "Media Control Platform" includes the list of "mcpConfig.nexus" parameters. More information is available in the section "Configuring MCPs to connect to Nexus (for Bot use cases)" after the table.
+====Pre-requisites====
-* {{Link-SomewhereInThisVersion|manual=GVPPEGuide|topic=Deploy|anchor=GVPMCP}}
+#The Nexus Agent Assist endpoint URL. For example:
-The section "Install Helm chart", for MCP, includes the values.yaml information on Nexus client configuration.
+====Configuration====
-*{{Link-SomewhereInThisVersion|manual=GVPPEGuide|topic=Metrics|anchor=GVPMCP}}
+#Create a new Kubernetes secret:
-The MCP metrics section includes the following Nexus-related triggers:
+====Validation====
 {{{!}} class="wikitable"
 {{!}}MCP_WEBSOCKET_CLIENT_OPEN_ERROR

← Older revision		Revision as of 10:58, July 13, 2021
Line 76:		Line 76:

	===Use Case 2 - Update Existing Tenant===		===Use Case 2 - Update Existing Tenant===
		+	'''Note''': Service Discovery cannot change/update configuration for Environment tenant. This limitation will be addressed in future release.
		+
	The mechanism for updating existing tenant is very similar to deploying new tenant. In this case, the existing JSON for the tenant needs to be updated with new parameters.		The mechanism for updating existing tenant is very similar to deploying new tenant. In this case, the existing JSON for the tenant needs to be updated with new parameters.

@@ Line 7: / Line 7: @@
 |Section={{Section
 |alignment=Vertical
 |Status=No
 }}{{Section
 |sectionHeading=Tenant provisioning
 |alignment=Vertical
 |structuredtext=GVP Service Discovery ('''SD''') container is used for provisioning tenant object in GVP Configuration Server and creating application objects for - Configuration Server, Media Control Platform app objects under Resource Manager logical resource group.
@@ Line 104: / Line 110: @@
 {{!}}}
 The rest of the steps are the same as above. Delete existing configmap and create new with updated JSON.
 |Status=No
 }}
 |PEPageType=55cef4ff-9306-4313-8fd8-377282a38478
 }}