vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Customers are responsible for setting up additional users and security groups within each environment





 3.4 On Boarding Meeting 

IBM will schedule and provide an on-boarding meeting. This meeting serves as a brief introduction to IBM SRE services and covers the following details:



* Contacts, Support and Administration
* Client Environments (how to access)
* Support (How to get Help)
* Roles & Responsibilities
* Tools & Access Control
* Helpful Links



If you do not receive an invite for an onboarding meeting, please contact: [cdsonboarding@ibmserviceengage.com](mailto:cdsonboarding@ibmserviceengage.com)





 3.5 Case Ticket Submission 

At the onset of the project, Project manager(s) should determine who from their implementation team will be responsible for submitting case tickets to IBM. A single portal ([https://www.ibm.com/mysupport](https://www.ibm.com/mysupport)) is used to establish cases for both MAS environment related issues and product specific issues. It is generally advisable to have a limited number of individuals that can submit cases in order to prevent ticket duplication and better manage updates, followup and closure. Specific instructions on how to establish access to the IBM Support Community for case ticket submission can be found in the IBM SRE Services Support section.





 3.6 Back End Access 

Certain types of special back end access are usually needed at the beginning of projects for developers and/or consultants. It's important to note that this type of access can only be configured after environments have been provisioned and are accessible. Access of this type must be requested via case ticket submission

Common back-end access types for most MAS projects are:



* VPN



This is particularly important if integrations, data migration or custom reports are part of the implementation.



* Direct Database Access



This is usually required for report developers and those who need to run SQL statements against the database. Which users will need access? What kind of access is needed? Note: read/write access is allowed on non-production environments; read-only allowed on production environments if a database replica is ordered and configured.



* COS (Cloud Object Storage) access
(https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-faqibp-v2-faq-interoperability)



Planning for your network



* [Is IBM Blockchain Platform HIPAA ready?](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-faqibp-v2-faq-hippa)
* [What ports are used by the IBM Blockchain Platform?](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-faqibp-v2-ports)
* [How can I estimate the IBM Blockchain Platform sizing requirements for my development, test, and production environments?](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-faqibp-v2-faq-sizing)
* [How does pricing work on IBM Blockchain Platform for IBM Cloud?](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-faqibp-v2-faq-cloud-pricing)
* [What are the limitations of the free IBM Blockchain Platform using the IBM Cloud Kubernetes Service free cluster?](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-faqibp-v2-faq-free-cluster)
* [What regions or locations are available for the IBM Blockchain Platform for IBM Cloud?](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-faqibp-v2-faq-v2-IBP-Overview-1-9)
* [What persistent file storage does IBM Blockchain Platform for IBM Cloud use by default?]
Identification and Authentication (IA) [IA-5 Authenticator Management](https://cloud.ibm.com/docs/framework-financial-services-controls?topic=framework-financial-services-controls-ia-5) <br>[IA-5 (1) Authenticator Management | Password-Based Authentication](https://cloud.ibm.com/docs/framework-financial-services-controls?topic=framework-financial-services-controls-ia-5.1) 







 5. Use and maintain non-production environments for development and testing 

Requirement: Do not put anything into production that has not been tested in an equivalent non-production environment. Put non-production environments in a separate IBM Cloud account. Treat all non-production environments as if they were for production environments by following all of the best practices and IBM Cloud Framework for Financial Services controls for each environment you create.

Purpose & value: Non-production environments (all environments that your service uses for development, testing, or demonstration) are as critical to the security of your service as production environments. Security weaknesses must be detected and mitigated in development environments by enforcing all the same controls and security testing as production. As security weaknesses in development environments may be more likely than production, separation of these environments from production is required.

It is permissible to run a "pre-production" environment in your production account to be used only for final verification and sniff testing before promotion to production -- but, only if the set of operators is the same for both environments. However, all changes still need to be developed and tested first in a non-production environment in a separate account.

Implementation guidance:



1. Ensure all controls in the IBM Cloud Framework for Financial Services are followed for each new environment you create, whether for production or not.
2. Create and manage production environments using an IBM Cloud account separate from the one you are using for non-production environments.



Most Relevant Controls:



Table 4. Related controls for non-production environments

 Family Control
Development environments must be separated from production environments as they have different accounting, resource utilization, access, availability, networking, and compliance requirements. However, at the same time development environments should be kept in sync with production environments so that users testing in development can be confident that the application will behave similarly in production.

This recommendation creates a clean separation between development and production environments, but uses infrastructure as code to ensure that development and production are aligned.



 Related controls in IBM Cloud Framework for Financial Services 

The following [IBM Cloud Framework for Financial Services controls](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-aboutframework-control-requirements) are most related to this guidance. However, in addition to following the guidance here, do your own due diligence to ensure you meet the requirements.



Table 2. IBM Cloud Framework for Financial Services controls

 Family Control 

 Configuration Management (CM) [CM-3 (2) Configuration Change Control | Testing, Validation, and Documentation Of Changes](https://cloud.ibm.com/docs/framework-financial-services-controls?topic=framework-financial-services-controls-cm-3.2) 
 [CM-4 (1) Impact Analyses | Separate Test Environments](https://cloud.ibm.com/docs/framework-financial-services-controls?topic=framework-financial-services-controls-cm-4.1) 
 System and Services Acquisition (SA) [SA-10 Developer Configuration Management](https://cloud.ibm.com/docs/framework-financial-services-controls?topic=framework-financial-services-controls-sa-10) 
 [SA-15 (9) Development Process, Standards, and Tools | Use of Live Data](https://cloud.ibm.com/docs/framework-financial-services-controls?topic=framework-financial-services-controls-sa-15.9) 
 System and Communications Protection (SC) [SC-2 Application Partitioning](https://cloud.ibm.com/docs/framework-financial-services-controls?topic=framework-financial-services-controls-sc-2)
What is Infrastructure as Code? 

In simple terms, Infrastructure as Code (IaC) is using code to manage and provision infrastructure (networks, virtual machines, load-balancers, clusters, services and connection topology) in a descriptive model instead of manual processes.

With IaC, configuration files define your infrastructure, which also makes it easier to edit, share, and reuse configurations. By codifying your infrastructure, you provision the same environment every time avoiding undocumented, ad hoc configuration changes.

Schematics utilizes open-source Ansible and Terraform to provide a powerful set of IaC tools as a service to program your cloud infrastructure. With Schematics you can use this rich set of IaC automation capabilities to build stacks of cloud resources, manage their lifecycle, manage changes in their configurations, deploy your app workloads, and perform day-2 operations.



 Benefits of Infrastructure as Code 

Adopting an IaC approach to infrastructure deployment solves many common problems with provisioning infrastructure and delivers several benefits. Schematics enables you to realize these benefits without the need to install, run, and manage your own IaC tooling.



* Reliability and Consistency: New environments or infrastructure are provisioned reliably. Manual processes result in mistakes. With IaC the same configurations are deployed over and over, repeatedly without differences. IaC improves consistency across environments and deployments.
* Speed: IaC enables you to quickly set up your complete infrastructure through automation. You apply it to every environment, from development to production, staging, QA, and more. This can lead to lower costs as the time to deploy, manage, and maintain environments decreases.
* Tracking and accountability: Changes to existing infrastructure are made in code, and the changes are tracked. Like any source code file, you have full traceability of the changes made to a configuration.
* Detect and correct environment drift: If a part of the infrastructure is modified manually outside of the code, it can be brought back in line with the desired state on the next run. [Drift detection](https://cloud.ibm.com/docs/schematics?topic=schematics-drift-note) is a feature of Schematics Workspaces.







 Best Practices
What is API Connect Reserved? 

API Connect V10 Reserved lets you create and manage APIs directly in IBM Cloud.



 Managing the API lifecycle in API Connect 

API Connect enables you to manage the lifecyle of your APIs with a set of integrated features. Use the API Connect Reserved plan to host your APIs in the cloud and easily complete the tasks needed for all phases of an API's life:



* Develop APIs, bundle them into consumable products, and deploy them to production environments.
* Administer API publication and security with development catalogs, access gateways, OAuth, and execution policies to control access to your APIs and back-end systems.
* Manage API products with a Developer Portal where you can make them available to application developers, and a robust set of analytics so you can monitor API usage and performance.







 Who does what in API Connect? 

In API Connect, users are grouped into provider organizations, and are assigned permissions that control access to resources based on the job that each person typically performs.

Jobs can be assigned to people based on their expertise; for example, administering users, developing APIs, and monitoring event analytics. In a small company, one or two people might perform all of the work in creating and managing APIs. In a large company, a different person (or even multiple people) might be assigned to each job. When you read the API Connect, you'll see that information about tasks and features is often organized based on the following jobs that people are typically assigned to perform:



* API Connect Administrator

Everyone who has administrator privileges in your company's IBM Cloud account is automatically assigned the role of API Connect Administrator. The Administrator provisions and manages your company's API Connect Reserved plan. The Admin adds users to API Connect and configures services such as the gateways that control customer access to your APIs.

One of the Admin's main jobs is to set up provider organizations and add users. A provider organization is a group of people who use the API Manager component of API Connect. Members of the provider organization create and manage APIs, products, and related assets. API Connect Admins create the provider organizations, add members, and define the roles that control user access.
* API Developer
Deploying your assistant 

IBM Cloud

Watson Assistant routes your customer's questions and requests to the correct resolution source. However, before your assistant can properly route requests, you must complete the following steps:



1. Write content for your assistant
2. Publish the content
3. Connect an integration to your assistant
4. Deploy the assistant to a channel



After you connect an integration and deploy to a channel, you make your assistant available to your customers. You can find an overview visual of your progress toward completing these steps on the Live environment page:

![Image of the Live environment page](https://cloud.ibm.com/docs-content/v1/content/ca9232b3702768f24bb897f48f10778fcda28718/watson-assistant/images/live-environment-page.png)



 Reviewing your connected channels 

Channels represent the locations or communication platforms where your assistant interacts with your users. Common examples of channels include the phone, a website, or Slack. If you do not connect your assistant to a channel, your users are not able to access the assistant.

You can review your connected channels in your environments, for example:



* Draft environment: Channels that are connected to this environment are exposed only to your internal team for testing and not to your customers.
* Live environment: Channels that are connected to this environment represent the public-facing experience of your assistant and are exposed to your customers.
* Multiple enviroments: If you are using [multiple environments](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-multiple-environments), channels are exposed only to your internal team for testing and not to your customers.



For more information on environments, see [Environments](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-publish-overviewenvironments) and [Adding and using multiple environments](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-multiple-environments).
Does deleting a feature flag or property in an environment delete it across all environments? 

  What’s happening 

Deleting a feature flag or property in an environment deletes it for all environments.

  Why it’s happening 

Feature flag or property is available to all environments. Updates to values are per environment. Create and delete action executes across all environments.

  How to fix it 

Deletion of feature flag or property is across all environments.

If a flag is not required in a particular environment, disable the flag or set the values default. If a flag is not required in any environment, it can be deleted.
Inventory 

Learn about the inventory concepts such as inventory structure, content model, role, and purpose.



 Inventory structure and content 

The Inventory model tracks the following items:



* What artifact is deployed to which environment or region
* Where was an artifact that is built (pipeline run, commit sha)
* What is the signature of the built artifact



Based on this data, you can track evidence during artifact builds and deployments and help Change Management and Compliance audits.



 Branches 

The Inventory is implemented in a Git repository (repo). Git itself helps to track and audit changes.

Branches are used as environments. The main branch (master) is written and updated by the continuous integration pipeline. Other environments are updated from the master branch by using promotions. For more information about promotions, see the [Promotion](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-inventoryinventory-promotion) section.





 Content 

The Inventory contains an Inventory Entry for every artifact that participates in deployment. One Inventory Entry points to a single artifact. Inventory entries are JSON files that can be structured in folders and are named by using the entry name.

Inventory folders are part of the entry name.



 Example 

Use the following entry names for a service:



* auth/service
* auth/db
* ui/service
* main_service
* helm-charts/main_service



The content is implemented in the inventory by using the following structure:

/
├── auth
│ ├── service
│ └── db
├── ui
│ └── service
├── helm-charts
│ └── main_service
└ main_service









 Inventory entry format 

Although the Entry type represents the schema of the Inventory Entry by using typescript syntax, you can convert it to use JSON schema.

interface Entry {
repository_url: string;
artifact: string;
build_number: number;
commit_sha: string;
name: string;
pipeline_run_id: string;
version: string;

app_artifacts: {
This makes it easy to monitor that development and test infrastructure is aligned with production infrastructure by avoiding surprises as applications move through to production.
* Projects help with accounting and configuration management by ensuring that all resources that are associated with the project can be tracked back to the project by tagging and resource reports. Projects can also be tagged to provide a higher level of organization.







 Exploring popular use cases 

Projects help organize and secure the configurations that you create from an IaC deployable architecture as well as the resulting resources. If you are a large organization or enterprise, there are several advantages to using IBM Cloud projects. Explore these popular use cases to learn how you can adapt projects to your business needs.

Shift-left compliance and governance
: As you deploy and operate shared infrastructure, projects help to organize and bundle the related configurations and deployments in a single location - even across different environments. Projects run predeployment security and compliance checks to ensure that your IaC deployable architecture still meets its claimed compliance at the point of deployment. A separate project administrator or editor must review and approve changes, providing an additional layer of governance.

Automated deployment across accounts
: Projects can deploy to any account, which makes it much easier to isolate your environments in separate accounts. This enables you to organize and manage configurations across environments from a single view. Because projects deploy changes through automation, they reduce the chance of human error or deviations between environments. You can even lock down access to your most sensitive accounts and require changes to be made by using projects.

Tracking ongoing maintenance and updates
: Projects help you to manage architecture updates and maintain compliance. In addition to conducting continuous compliance scans, projects notify you of architecture version updates, validation failures, and required cluster updates. Because projects are integrated with IBM Cloud’s Event Notifications service, you can route project notifications to Slack, PagerDuty, and other third-party tools.

Building and sharing custom architectures by using private catalogs
: Deployable architectures are built to be modular and flexible. You can create custom deployable architectures and share them with your team by using private catalogs by adding the IaC to a new project.
Spreading the VSIs across the zones does address this risk but what about multiple VSIs that are in the same zone? For example, suppose you have 5 VSIs that are dedicated to your web tier and are spread across three zones; 2 of the 3 zones have 2 VSIs. You want to ensure that the zones that have 2 VSIs are set up for the best availability. Granted you have other zones to protect you against failure in a zone, but it would be better to ensure the 2 VSIs are created on different hypervisors. That way, if the system or hypervisor goes down, the impact is smaller than if the 2 VSIs that were placed on the same hypervisor.

To avoid placing VSIs on the same hypervisor, placement groups come into play. Placement groups guarantee a group of VSIs are not placed on the same hypervisor.

2 different placement algorithms are available for you to choose from:



* Hypervisor spread - Ensures the VSIs are distributed across different hypervisors. There can be up to 12 VSIs in the placement group.
* Power spread - Ensures the VSIs are placed not only different hypervisors but also the hypervisors are placed on different power and network, essentially on different racks. There can be up to 4 VSIs in the placement group.



Of the 2 options, the second option provides a better resiliency over the first option.

Zoom

![Placement Groups.](https://cloud.ibm.com/docs-content/v1/content/df269b100c3499f1efcbb7d030dce8dec25c539b/ha-infrastructure/images/placement_groups.svg)

Figure 1. Placement group algorithms

If you have several VSIs, such as the web or applications, then hypervisor spread is sufficient. If you have a smaller set of VSIs, such as a database, where there are multiple masters or read replicas in the same zone, then power spread a better choice.
[Workspace structure for IBM Cloud Schematics](https://cloud.ibm.com/docs-content/v1/content/ba89e173287b28d1453d2a327d8a1f74ae2f1662/schematics/images/workspace-structure.png)

Figure 1. workspace structure for IBM Cloud Schematics

Do not use one workspace to manage an entire staging or production environment. When you deploy all your IBM Cloud resources into a single workspace, it can become difficult for various teams to coordinate updates and manage access for these resources.





 How do I structure my Git repository to map my workspaces? 

Structure your Git repository so that you have one repository for all your Terraform configuration files that build your microservice, and use input variables in Schematics, or GitHub branches or directories to differentiate between your development, staging, and production environment.

Review the following table to find a list of options for how to structure your Git repository to map the different workspace environments.



Structure of the Git repository

 Option Description 

 One Git repo, use variables to distinguish between environments Create one Git repository where you store the Terraform configuration files that make up your microservice component. Make your Terraform configuration files as general as possible so that you can reuse the same configuration across your environments. To configure the specifics of your development, staging, and production environment, use [Terraform input variables](https://cloud.ibm.com/docs/schematics?topic=schematics-create-tf-configconfigure-variables) in your configuration files. Input variables are automatically loaded into IBM Cloud Schematics when you create your workspace. To customize your workspace, you enter the environment-specific values for your variables. This setup is useful if you have one team that manages the lifecycle of the microservice component and where the configuration of your environments does not differ drastically.