vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Git Repos and Issue Tracking 

Collaborate with your team and manage your source code with a Git repository (repo) and issue tracker that is hosted by IBM and built on [GitLab Community Edition](https://about.gitlab.com/). For more information about GitLab, see the [GitLab documentation](https://us-south.git.cloud.ibm.com/help).

Invite only people that you have a personal or business relationship with to collaborate on a project. Users that use an invitation to a Git repo for purposes other than to collaborate on a project might have their access to the service suspended or revoked.

Both GitHub and the Git command line are accessible alternatives to GitLab.

Don't store regulated data in files or issues within Git repos. The procedures for regulated data are currently not in place.

The [Git Repos and Issue Tracking tool integration](https://cloud.ibm.com/docs/services/ContinuousDelivery?topic=ContinuousDelivery-grit) supports teams to manage code and collaborate in many ways:



* Manage Git repos through fine-grained access controls that keep code secure
* Review code and enhance collaboration through merge requests
* Track issues and share ideas through the issue tracker
* Document projects on the wiki system



Because this tool integration is built on GitLab Community Edition and hosted by IBM on the IBM Cloud Platform, a few GitLab options are not available. For example, Delivery Pipeline provides continuous integration and continuous delivery for IBM Cloud; therefore, the continuous integration features in GitLab are not supported. In addition, the admin functions are not available because they are managed by IBM.



 Using Git Repos and Issue Tracking with toolchains 

You can use a template that contains either a Git Repos and Issue Tracking or GitHub tool integration as a starting point to create a toolchain that you can add Git repositories (repos) to. Alternatively, you can start with an empty toolchain and add either a Git Repos and Issue Tracking or GitHub tool integration to it.
3. If the operator uses a template with a build component that must pull an image from a private registry, the build might fail with an authentication error. To resolve this error, see [Build error due to image pull authentication](https://cloud.ibm.com/docs/openshift?topic=openshift-ts-app-build-img-pull).







 Disabling and mirroring OperatorHub catalog source images 

You can disable and mirror the OperatorHub catalog source images by following the [Operator Lifecycle Manager (OLM) on restricted networks documentation from Red Hat](https://docs.openshift.com/container-platform/4.6/operators/admin/olm-restricted-networks.html).

To understand why you might disable and mirror the catalog, consider the following scenarios.



* For private clusters: The Red Hat-provided OperatorHub source images require access to the registry.redhat.io and quay.io registries. If your cluster runs on a restricted network, such as in a VPC without a public gateway or classic worker nodes on only a private VLAN, these images are not accessible
* You want to restrict the catalog content that is available to your cluster users in OperatorHub.



Before you begin



* Make sure that you have the Manager service role to the cluster in all namespaces in IBM Cloud IAM.
* [Install the opm command-line interface](https://docs.openshift.com/container-platform/4.6/cli_reference/opm-cli.htmlopm-cli), including its prerequisite tools such as podman.
* Have a Red Hat account with credentials to pull images from the registry.redhat.io and quay.io registries, or use the [default global pull secret](https://cloud.ibm.com/docs/openshift?topic=openshift-registrycluster_global_pull_secret).



To disable and mirror the OperatorHub source images:



1.
In a restricted network environment, you must have administrator access to disable the default catalogs. You can then configure OperatorHub to use local catalog sources.

While logged into your bastion host, complete the following steps.



1. [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).
2. Disable the default remote OperatorHub sources.

oc patch operatorhub cluster --type json -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'







 Step 6: Log in to your container registries 



1. Log in to registry.redhat.io. If you don't have a Red Hat account, follow the steps to [create one](https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/auth?client_id=customer-portal&redirect_uri=https%3A%2F%2Faccess.redhat.com%2Fwebassets%2Favalon%2Fj%2Fincludes%2Fsession%2Fscribe%2F%3FredirectTo%3Dhttps%253A%252F%252Faccess.redhat.com%252Ftags%252Flogin&state=cb7a0391-a189-468d-b979-aaebc5344f26&nonce=1e7e5af7-0323-46da-8a69-54d204a182e8&response_mode=fragment&response_type=code&scope=openid).

podman login registry.redhat.io
2. Log in to IBM Cloud Container Registry with the username iamapikey.

podman login us.icr.io -u iamapikey -p IAM-API-KEY







 Step 7: Create a namespace in IBM Cloud Container Registry 



1.
[Pods](https://kubernetes.io/docs/concepts/workloads/pods/) or [ConfigMaps](https://kubernetes.io/docs/concepts/configuration/configmap/) may have points of variability (POV) that are not known at the time of writing the descriptors. These POVs may be represented as [templates](https://pkg.go.dev/text/template) and the values will be filled in at deployment time from information in the contract. We use [go templates](https://pkg.go.dev/text/template) as the templating syntax, which is the same as used for [helm charts](https://helm.sh/docs/chart_template_guide/getting_started/), so templates can easily be exchanged with k8s. We support the following Built-In objects:



* Environment: this object contains the environment variables as merged between the workload and the environment section. The object is available as {{ .Env }}.



Example:

workload:
type: workload
play:
templates:
- apiVersion: v1
kind: Pod
metadata:
name: busybox
spec:
containers:
- name: main
image: "{{ .Env.REGISTRY }}/hpse-docker-busybox-s390x@sha256:732efa374f1e6c964caeacab0bcb370385ee386041a14d4a32176462e3f75c7b"
command:
- printenv
envFrom:
- configMapRef:
name: contract.config.map
optional: false
restartPolicy: Never
env:
env:
REGISTRY: docker-eu-private.artifactory.swg-devops.com/sys-zaas-team-hpse-dev-docker-local/zaas
Show more
Why can't the ownership of the mount path be changed? 

Virtual Private Cloud

Classic infrastructure

  What’s happening 

You created a deployment that mounts an IBM Cloud Object Storage bucket to your app. During the deployment, you try to change the ownership of the volume mount path, but this action fails. You see error messages similar to the following:

chown: changing ownership of '<volume_mount_path>': Input/output error
chown: changing ownership of '<volume_mount_path>': Operation not permitted

  Why it’s happening 

When you create a bucket in IBM Cloud Object Storage, the bucket is managed by s3fs-fuse. The UID and GID that own the volume mount path are automatically set by Fuse when you mount the bucket to your app and can't be changed.

  How to fix it 

You can't change the ownership of the volume mount path. However, you can change the UID and GID for a file or a directory that is stored under your volume mount path. For more information, see [Object storage: Accessing files with a non-root user fails](https://cloud.ibm.com/docs/containers?topic=containers-cos_nonroot_access).
Multiple repositories must be configured during the guided setup, as described in the next sections.

For each repository, either clone the repository that's provided as a sample, or provide a URL to an existing IBM-hosted Git Repos and Issue Tracking repository that you own. The toolchain supports linking only to existing Git Repos and Issue Tracking repositories.



 Application 

The Application step that refers to the application source code repository is shown in the following image.

Zoom

![DevSecOps application repository](https://cloud.ibm.com/docs-content/v1/content/5eb88a2575e30e316dbb83829c7f4c8b1ddbc67c/devsecops/images/devsecops-ci-app-repo.png)

Figure 4. DevSecOps application repository

The recommended options are displayed by default, but you can click the Switch to advanced configuration toggle to see all of the configuration options available for the underlying Git integration. The default behavior of the toolchain is Use default sample application that clones the sample application as IBM-hosted Git Repos and Issue Tracking Repository.

Enter the name of the IBM-hosted Git Repos and Issue Tracking repository that was created by the toolchain as your application repository.

The region of the repository remains the same as the region of the toolchain.

If you want to link an existing Application Repository for the toolchain, select the Bring your own application option, and provide it as input to the Repository URL field. As noted earlier, the toolchain currently supports linking only to existing Git Repos and Issue Tracking repositories. If you want to know more about Bring your own application, see [Bringing your own app to DevSecOps](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-apps-byoa).



 Git integration 

To see the default method of authentication that is is used to access the Git provider, click Switch to advanced configuration. The default value of Auth Type is OAuth.
In the Location response, find the access_token, such as in the following example.

< HTTP/1.1 302 Found
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Expires: 0
< Expires: Fri, 01 Jan 1990 00:00:00 GMT
< Location: <token_endpoint>/oauth/token/implicitaccess_token=<access_token>&expires_in=86400&scope=user%3Afull&token_type=Bearer
...
5. Use your cluster master URL and the access token to access the Red Hat OpenShift API, such as to list all the pods in your cluster. For more information, see the [Red Hat OpenShift API documentation](https://docs.openshift.com/container-platform/4.11/rest_api/index.html).

Example curl request:

curl -H "Authorization: Bearer <access_token>" '<master_URL>/api/v1/pods'









 Using a service ID to log in to clusters 

You can create an IBM Cloud IAM service ID, make an API key for the service ID, and then use the API key to log in to a Red Hat OpenShift cluster. You might use service IDs so that apps that are hosted in other clusters or clouds can access your cluster's services. Because service IDs are not tied to a specific user, your apps can authenticate if individual users leave your account. For more information, see [Creating and working with service IDs](https://cloud.ibm.com/docs/account?topic=account-serviceids).



1. Create an IBM Cloud IAM service ID for your cluster that is used for the IAM policies and API key credentials. Be sure to give the service ID a description that helps you retrieve the service ID later, such as including the cluster name.
For more information, see [Choosing an app exposure service](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_network_planning). 
 App networking All pods that are deployed to a worker node are assigned a private IP address in the 172.30.0.0/16 range by default. You can avoid subnet conflicts with the network that you use to connect to your location by specifying a custom subnet CIDR that provides the private IP addresses for your pods. To expose an app, see [Exposing apps in Satellite clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-sat-expose-apps). 
 Storage Bring your own storage drivers or deploy one of the supported storage templates. For more information, see [Understanding Satellite storage](https://cloud.ibm.com/docs/satellite?topic=satellite-storage-template-ov). 
 User access You can use IBM Cloud IAM access policies to authorize users to create IBM Cloud infrastructure, manage your cluster, and access cluster resources. For more information, see [Managing access overview](https://cloud.ibm.com/docs/satellite?topic=satellite-iam). You can also further control access to your host infrastructure in policies provided by your infrastructure provider. 
 Integrations For cluster integrations, see [Supported IBM Cloud and third-party integrations](https://cloud.ibm.com/docs/openshift?topic=openshift-supported_integrations). For supported Satellite service integrations, see [Supported Satellite IBM Cloud services](https://cloud.ibm.com/docs/satellite?topic=satellite-managed-services). 
 Locations and versions Clusters are managed from one of the [supported IBM Cloud locations](https://cloud.ibm.com/docs/satellite?topic=satellite-sat-regions). However, you can deploy worker nodes to your own location, an IBM Cloud data center, or another cloud provider. For more information see [Understanding locations and hosts](https://cloud.ibm.com/docs/satellite?topic=satellite-location-host).
* [HPCS Router](https://cloud.ibm.com/docs/openshift?topic=openshift-hpcs-router-changelog)
* [Image Key Synchronizer](https://cloud.ibm.com/docs/openshift?topic=openshift-imagesencrypted-images)
* Deprecated: [Kubernetes web terminal](https://cloud.ibm.com/docs/containers?topic=containers-cli-install)
* [OpenShift Data Foundation](https://cloud.ibm.com/docs/openshift?topic=openshift-deploy-odf-vpc) (However, you can also use [Satellite storage templates](https://cloud.ibm.com/docs/satellite?topic=satellite-storage-odf-local) to consistently deploy ODF across clusters in your location.)
* [Static routes](https://cloud.ibm.com/docs/openshift?topic=openshift-static-routes)



The following list of add-ons for clusters are unsupported in Satellite locations.



* [ALB OAuth Proxy](https://cloud.ibm.com/docs/containers?topic=containers-comm-ingress-annotationsapp-id-auth)
* [Cluster Autoscaler](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-classic-vpc)
* [Istio](https://cloud.ibm.com/docs/containers?topic=containers-istio)
* [Block Storage for VPC](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-block)
The official s3fs documentation suggests using libcurl4-gnutls-dev instead of libcurl4-openssl-dev. Either work, but the OpenSSL version may result in better performance.

For macOS, you will need to build s3fs from source:

Ensure you have the following packages installed (all are available via [Homebrew](https://brew.sh)):



* macfuse
* automake
* gcc
* curl
* libxml2
* pkg-config
* openssl



And as noted in the output of the openssl install, you'll need to set these environment variables:

export LDFLAGS="-L/usr/local/opt/openssl@3/lib"
export CPPFLAGS="-I/usr/local/opt/openssl@3/include"
export PKG_CONFIG_PATH="/usr/local/opt/openssl@3/lib/pkgconfig"

Be aware that [macFUSE is closed-source software](https://osxfuse.github.io) containing a kernel extension, and may require a license for commercial use.

First clone the Github repository:

git clone https://github.com/s3fs-fuse/s3fs-fuse.git 

Then build s3fs:

cd s3fs-fuse
./autogen.sh
./configure
make

And install the binary:

sudo make install





 Configuration 

Store your credentials in a file containing either <access_key>:<secret_key> or :<api_key>. This file needs to have limited access so run:

chmod 0600 <credentials_file>



Now you can mount a bucket using:

s3fs <bucket> <mountpoint> -o url=http{s}://<endpoint> –o passwd_file=<credentials_file>
* CONTENT-SITE-POLICIES#RESTRICTIONS [golang.org/x/tools](https://proxy.golang.org/golang.org/x/tools/@v/v0.0.0-20201224043029-2b0845dc783e.zip), DOCS [docker/libtrust](https://proxy.golang.org/github.com/docker/libtrust/@v/v0.0.0-20160708172513-aabc10ec26b7.zip), GODOCS btoa (Not Required), GOPROXY-JQUERY-VERSION elazarl/goproxy(Not Required)
* WEBPAGECONTENTS-HTML/TESTDATA/GO1.HTML [github.com/hashicorp/go.net (Not Required)](https://proxy.golang.org/github.com/hashicorp/go.net/@v/v0.0.1.zip), GO1.HTML [github.com/hashicorp/go.net (Not Required)](https://proxy.golang.org/github.com/hashicorp/go.net/@v/v0.0.1.zip), [GODOC.HTML (no copyright)](https://proxy.golang.org/golang.org/x/tools/@v/v0.1.4.zip), PHP_MAN.HTML [elazarl/goproxy (Not Required)](https://proxy.golang.org/github.com/elazarl/goproxy/@v/v0.0.0-20170405201442-c4fc26588b6e.zip), GOLANG-ORG.YAML [github.com/dnaeon/go-vcr (Not Required)](https://proxy.golang.org/github.com/dnaeon/go-vcr/@v/v1.0.1.zip), [POLY-GEN.GO (no copyright
Leveraging automation to share to a private catalog 

The customization bundle has an automation directory that includes a couple of options for starter pipelines. These pipelines can be used to automate the lifecycle of your customized products that you share by using a private catalog on IBM Cloud. This includes managing the onboarding, validation, and sharing of the deployable architecture version to a private catalog. README files are included for each pipeline option that provide details on how to leverage it. For more information about each one, see [GitHub Actions](https://github.com/features/actions) and [Creating a toolchain](https://cloud.ibm.com/devops/setup/deploy?repository=https%3A%2F%2Fus-east.git.cloud.ibm.com%2Fopen-toolchain%2Fiac-compliance-ci-toolchain&env_id=ibm:yp:us-east).





 Next steps 

The scripts that are provided in the customization bundle help you to automate the onboarding process to a private catalog for sharing your product with other users. However, if you'd like to use the console or CLI to onboard your deployable architecture, see [onboarding your customized deployable architecture to a private catalog](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-onboard-custom) for step-by-step guidance. By using private catalogs, members of your enterprise are required to use approved architectures that they can deploy by using [projects](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-understanding-projects).
Finally, we add a custom static styles.css file from our pubic/stylesheets directory.

<title><%=title%></title>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">

<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css"
integrity="sha384-BVYiiSIFeK1dGmJRAkycuHAHRg32OmUcww7on3RYdg4Va+PmSTsz/K68vbdEjh4u"
crossorigin="anonymous">
<script src="https://code.jquery.com/jquery-3.1.1.min.js"
integrity="sha256-hVVnYaiADRTO2PzUGmuLJr8BLUSjGIZsDYGmIJLv2b8="
crossorigin="anonymous">
</script>
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js"
integrity="sha384-Tc5IQib027qvyjSMfHjOMaLkfuWVxZxUPnCJA7l2mCWNIpG9mGCD8wGNIcPD7Txa"
crossorigin="anonymous">
</script>

<link rel="stylesheet" href="stylesheets/style.css">

Show more

The body of the index view contains our bootstrap styled navigation tabs, and our upload form in a basic layout that is provided by the CSS styles included with bootstrap.

Consider these two specifications for our app:
You can integrate your own load balancer solution into clusters, such as [MetalLB](https://cloud.ibm.com/docs/openshift?topic=openshift-sat-expose-appssat-expose-metallb).<br> * The hosts that run the worker nodes for your cluster must meet the [host networking](https://cloud.ibm.com/docs/satellite?topic=satellite-reqs-host-network) and provider-specific requirements, such as for [AWS](https://cloud.ibm.com/docs/satellite?topic=satellite-aws), [Azure](https://cloud.ibm.com/docs/satellite?topic=satellite-azure), [GCP](https://cloud.ibm.com/docs/satellite?topic=satellite-gcp), and [IBM Cloud](https://cloud.ibm.com/docs/satellite?topic=satellite-ibm) (testing and demonstration purposes only).<br> * Because VXLAN encapsulation is required for traffic between pods that are on different worker nodes, data transfer speeds between pods on different worker nodes might be slower than the network capability of the hosts.<br><br><br> 
 Storage for worker node hosts See [Host storage and attached devices](https://cloud.ibm.com/docs/satellite?topic=satellite-reqs-host-storage). 
 Storage for apps No storage provider is installed in your Satellite clusters by default. Therefore, no pre-configured Kubernetes storage classes are set up by default in your clusters to store your application data in a Kubernetes persistent volume that is backed by storage device. For options to set up a storage provider, see [Understanding Satellite storage templates](https://cloud.ibm.com/docs/satellite?topic=satellite-storage-template-ov). 
 Worker nodes Worker nodes run on hosts in your own infrastructure environments.
Why can't non-root users access files? 

Virtual Private Cloud

Classic infrastructure

 What’s happening 

You uploaded files to your IBM Cloud Object Storage service instance by using the console or the REST API. When you try to access these files with a non-root user that you defined with runAsUser in your app deployment, access to the files is denied.

 Why it’s happening 

In Linux, a file or a directory has three access groups: Owner, Group, and Other. When you upload a file to IBM Cloud Object Storage by using the console or the REST API, the permissions for the Owner, Group, and Other are removed. The permission of each file looks as follows:

d--------- 1 root root 0 Jan 1 1970 <file_name>

When you upload a file by using the IBM Cloud Object Storage plug-in, the permissions for the file are preserved and not changed.

 How to fix it 

To access the file with a non-root user, the non-root user must have read and write permissions for the file. Changing the permission on a file as part of your pod deployment requires a write operation. IBM Cloud Object Storage is not designed for write workloads.

Updating permissions during the pod deployment might prevent your pod from getting into a Running state.

To resolve this issue, before you mount the PVC to your app pod, create another pod to set the correct permission for the non-root user.



1. To check the permissions of your files in your bucket, create a configuration file for your test-permission pod and name the file test-permission.yaml.

apiVersion: v1
kind: Pod
metadata:
name: test-permission
spec:
containers:
- name: test-permission
image: nginx
volumeMounts:
- name: cos-vol
mountPath: /test
volumes:
- name: cos-vol
persistentVolumeClaim:
claimName: <pvc_name>
2. Create the test-permission pod.

oc apply -f test-permission.yaml
3.
* You can't modify any Istio resources that are created for you in the istio-system namespace. If you need to customize the Istio installation, you can [edit the managed-istio-custom configmap resource](https://cloud.ibm.com/docs/containers?topic=containers-istiocustomize).
* The following features are not supported in the managed Istio add-on:



* [Any features by the community that are in alpha release stages](https://istio.io/latest/docs/releases/feature-stages/)
Each CC pipeline run with auto remediation enabled creates a new pull request or updates an existing one, if fixes are available. The CRA CLI scans the commit that is deployed to production so unless the fixes that are identified and fixed by CRA CLI are approved, merged, and deployed to production, a new and potentially identical PR is generated at each CC pipeline run.

The following repositories are supported:



* Enterprise GitHub
* GitLab





Table 1. Supported ecosystems

 Ecosystem Files modified by CRA auto remediation 

 Nodejs package.json and package-lock.json 
 Gradle build.gradle, gradle.lockfile, and buildscript-gradle.lockfile 
 Maven pom.xml 





Table 2. CC pipeline environment variables

 CC pipeline environment variables Description Required or optional 

 opt-in-cra-auto-remediation True or false. Set to false by default. Required 
 opt-in-cra-auto-remediation-force True or false. Set to false by default. Optional 
 opt-in-cra-auto-remediation-enabled-repos Comma-separated list of repository names. Not set by default. Optional