vania-janet/multiturn-rag-retrieval-data huggingface dataset:
How does App Configuration work? 

Learn how App Configuration works under normal operation or when something goes wrong.



 Normal operation 

During normal operation, the App Configuration SDK (#2 in Figure 1) handles the automatic delivery of the appropriate flag state or property value into your application from the IBM Cloud App Configuration instance (#1 in Figure 1). During initialization, the SDK connects to the App Configuration API and fetches the specified collections, segment rules, and targeting rules (#3 in Figure 1), and then evaluates the rules against attribute values that are programmed into your application to select the correct [segment](https://cloud.ibm.com/docs/app-configuration?topic=app-configuration-ac-segments) and target values. Attributes upon which the rules operate are stored locally, and not in the IBM Cloud App Configuration service on the cloud. Therefore, if you need to evaluate against attributes that are confidential, for example a social security number, the values never leave the local application environment.

After initialization, the application receives updated values in two ways depending on whether you are using server-side or client-side SDKs. Server-side SDKs connect to the App Configuration service through a web socket, and modified values are delivered your application in real time. Client-side SDKs pull values from the App Configuration service upon a lifecycle change such being opened or brought to the foreground.

During normal operation, various metrics are sent back to the AC cloud service (#6 in Figure 1) so that the service can operate properly and so that you can monitor its operation.

Zoom

![Overview](https://cloud.ibm.com/docs-content/v1/content/f3dada89f147af3b88388a2218ddbf64b3c41e5f/app-configuration/images/ac-how-it-works.png)

Figure 1. How App Configuration works





 Operation when something goes wrong 

As with any application or cloud service, sometimes things go wrong, but IBM Cloud App Configuration continues to provide configurations even if the IBM Cloud App Configuration service is not available to your app.



 Lost connection
Understanding your responsibilities when using App Configuration 

Learn about the management responsibilities and terms and conditions that you have when you use IBM Cloud App Configuration. For a high-level view of the service types in IBM Cloud and the breakdown of responsibilities between the customer and IBM for each type, see [Shared responsibilities for IBM Cloud offerings](https://cloud.ibm.com/docs/overview?topic=overview-shared-responsibilities).

Review the following sections for the specific responsibilities for you and for IBM when you use IBM Cloud IBM Cloud App Configuration. For the overall terms of use, see [IBM Cloud® Terms and Notices](https://cloud.ibm.com/docs/overview/terms-of-use?topic=overview-terms).



 Incident and operations management 

You and IBM share responsibilities for the set-up and maintenance of your IBM Cloud App Configuration instance.

You are responsible for incident and operations management of your application and application data.



Table 1. Responsibilities for incident and operations

 Task IBM Responsibilities Your Responsibilities 

 Incidents Provide notifications for planned maintenance, security bulletins, or unplanned outages. Set preferences to receive emails about platform notifications, and monitor the IBM Cloud status page for general announcements. 







 Change management 

You and IBM share responsibilities for keeping IBM Cloud App Configuration service components at the latest version.

You are responsible for change management of your application and application data.



Table 2. Responsibilities for change management

 Task IBM Responsibilities Your Responsibilities 

 Applications Provide infrastructure operating system (OS), version, and security updates. Use the API, SDK, CLI, or console tools to apply the provided updates for the local entities (app code, CLI, and SDK). 







 Identity and access management 

You and IBM share responsibilities for controlling access to your IBM Cloud App Configuration instances and resources.

You are responsible for identity and access management to your application and application data.



Table 3. Responsibilities for identity and access management

 Task IBM Responsibilities Your Responsibilities 

 Applications Restrict access to resources. Depending on your needs, restrict access to resources and service functions by using Cloud IAM access policies.
Code Bundle: cr://icr.io/ce--1a1a1-11c22def3rhz/function-myfunction:12345678-1111-dexla
Main: main()







 ibmcloud ce function list 

List all functions in a project.

ibmcloud ce function list [--output OUTPUT] [--quiet] [--sort-by SORT_BY]



 Command Options 

--output, -o
: Specifies the format of the command output. Valid values are json, yaml, jsonpath=JSONPATH_EXPRESSION, and jsonpath-as-json=JSONPATH_EXPRESSION. Use jsonpath to specify the path to an element of the JSON output. This value is optional.

--quiet, -q
: Specify this option to reduce the output of the command. This value is optional. The default value is false.

--sort-by, -s
: Specifies the column by which to sort the list. Valid values are name and age. This value is optional. The default value is name.





 Example 

ibmcloud ce fn delete --name myfunction





 Example output 

Name Status URL CPU Memory Age
hellofunction Ready https://hellofunction.4svg40kna19.us-south.codeengine.appdomain.cloud 0.25 500M 25h
myfunction Ready https://myfun1.4svg40kna19.us-south.codeengine.appdomain.cloud 0.25 1G 8d
helloworld Ready https://myfunction1.4svg40kna19.us-south.codeengine.appdomain.cloud 0.25 1G 16d
myfunction1 Ready https://myfunction111.4svg40kna19.us-south.codeengine.appdomain.cloud 0.25 500M 25h
What is Cloud Foundry? 

IBM® Cloud Foundry is deprecated and no longer supported as of 1 June 2023. For more information, see the [deprecation details](https://cloud.ibm.com/docs/cloud-foundry-public?topic=cloud-foundry-public-deprecationdep_details).

[Cloud Foundry](https://www.cloudfoundry.org/) is the premier industry standard Platform-as-a-Service (PaaS) that ensures the fastest, easiest, and most reliable deployment of cloud-native apps. Cloud Foundry ensures that the build and deploy aspects of coding remain carefully coordinated with any attached services; resulting in quick, consistent, and reliable iterating of apps.

Check out the following [video](https://www.youtube.com/watch?v=lH6EY761wgc) to learn more about all the compute options available on IBM Cloud.



  Benefits of Cloud Foundry 

Choose your own language - IBM Cloud® Foundry includes runtimes for Java™, Node.js, PHP, Python, Ruby, Swift, and Go. Cloud Foundry community build packs are also available. Combined with DevOps services, the app runtimes enable a delivery pipeline that automates much of the iterative development process.

Fault tolerant - Runtimes facilitate developing apps as stateless processes that quickly: start and stop, replicate if an instance fails, and duplicate if sustained or increased performance requires.

Extend apps with services - Runtimes link IBM Cloud services to apps as endpoints, giving any instance of an app embedded knowledge of how to manage relevant calls and data. In fact, runtimes manage all linked resources this way: SDKs, APIs (whether made available as cloud services or exposed from within a traditional enterprise as custom services), and also apps themselves when used as resources by other apps.

Access control - Fine grain assignment/dispensing of compute capacity to development teams.

Automatic placement - Apps are automatically placed across multiple data-center PODs for maximum reliability.

Automatic health management - Crashing apps restart automatically.

Automatic routing - Internet reachable routes are automatically created for your apps.

High availability - Supports full high availability for high app availability.

Automatic deployment scaling - The Auto-Scaling for IBM Cloud service automatically increases or decreases the compute capacity of your app, to rapidly adjust to dynamic loading needs.
Operations FAQs for App Configuration 

FAQs for App Configuration provides answers to common operations issues for App Configuration.



  Can I get more evaluation behavior details with App Configuration SDKs? 

Yes. Debugging can be enabled for App Configuration SDK. As an example, use code client.setDebug(true) to enable more traces for Node.js SDK. Refer to [SDK](https://cloud.ibm.com/docs/app-configuration?topic=app-configuration-ac-sdks) documentation for specific SDKs.





  How can I get real-time updates of feature flag or properties in my application? 

Any update is pushed to the application in real time by the App Configuration service. To listen to the changes, implement the following code in your Node.js application:

client.emitter.on('configurationUpdate', () => {
// add your code
})
Configure bound services 

IBM® Cloud Foundry is deprecated and no longer supported as of 1 June 2023. For more information, see the [deprecation details](https://cloud.ibm.com/docs/cloud-foundry-public?topic=cloud-foundry-public-deprecationdep_details).

You can bind various services to your Liberty for Java app. Services can be container-managed, app-managed, or both, depending on what the developer wants.

An app-managed service is a service that is managed entirely by the app, without any assistance from Liberty. The app typically reads VCAP_SERVICES to obtain information about the bound service and accesses the service directly. The app provides all necessary client access code. There is no dependency on Liberty features or the server.xml file configuration. The Liberty buildpack automatic configuration does not apply to services of this type.

A container-managed service is a service that is managed by the Liberty runtime. In some cases, the app might look up the bound service in JNDI, while in others the service is used directly by Liberty itself. The Liberty buildpack reads VCAP_SERVICES to obtain information about the bound services. For each container-managed service, the buildpack performs three functions.



* Generates [cloud variables](https://cloud.ibm.com/docs/cloud-foundry-public?topic=cloud-foundry-public-options_for_pushingaccessing_info_of_bound_services) for the bound service.
* Installs Liberty features and client access codes that are required to access the bound service.
* Generates or updates server.xml file stanzas that are required by the service.



This process is referred to as automatic configuration.

The Liberty buildpack provides automatic configuration for the following service types:



* [ClearDB MySQL Database](https://w2.cleardb.net/developers/)
* [IBM Cloudant](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-getting-started-with-cloudant)
Binding a service instance to an app, job, or function workload 

You can integrate an IBM Cloud service instance to resources in an IBM Cloud® Code Engine project by using service bindings.

After determining the service instance that you want to bind to your Code Engine workload, and ensuring that you have configured [access for service bindings](https://cloud.ibm.com/docs/codeengine?topic=codeengine-configure-bindaccess), you are ready to bind the service instance to your Code Engine app, job, or function workload.

Before you begin



* [Create a project](https://cloud.ibm.com/docs/codeengine?topic=codeengine-manage-project).
* Create a Code Engine workload to bind to your service instance. The workload that you want to bind to the service instance must exist.



* [Create an app](https://cloud.ibm.com/docs/codeengine?topic=codeengine-deploy-appdeploy-app-console)
* [Create a job](https://cloud.ibm.com/docs/codeengine?topic=codeengine-create-jobcreate-job-ui)
* [Create a function](https://cloud.ibm.com/docs/codeengine?topic=codeengine-fun-create-inlinecode)



* Create the service instance that you want to bind to your Code Engine app or job.
* [Configure access for service bindings](https://cloud.ibm.com/docs/codeengine?topic=codeengine-configure-bindaccess).



Access for service bindings must be configured before you can bind a service instance to a Code Engine app, job or function workload. [Configure access for service bindings](https://cloud.ibm.com/docs/codeengine?topic=codeengine-configure-bindaccess) based on whether you want Code Engine to automatically create and manage the service ID for you or whether you want to use a service ID that you manage.
* The Monitoring and Analytics service integration was fixed to work with [Diego](https://docs.cloudfoundry.org/concepts/diego/diego-architecture.html).
* The [Dynatrace](https://cloud.ibm.com/docs/cloud-foundry-public?topic=cloud-foundry-public-using_dynatrace) service integrations were updated to work better with the Dynatrace service offerings.
* The [auto-configuration](https://cloud.ibm.com/docs/cloud-foundry-public?topic=cloud-foundry-public-auto_config) support for PostgreSQL and MySQL type of services was improved to work better when deploying a server directory or packaged server.
* The Node.js runtime that is used by the [devconsole and shell App Management utilities](https://cloud.ibm.com/docs/cloud-foundry-public?topic=cloud-foundry-public-app_management) was updated to the latest 0.12.17 version.
* [Security fixes](https://www.ibm.com/support/pages/node/286257) for the Liberty runtime are included.







 17 November 2016 

Updated Node.js buildpack v3.9
: This release of the buildpack supports IBM SDK for Node.js runtime versions: 0.10.47, 0.10.48, 0.12.16, 0.12.17, 4.6.1, 4.6.2, 6.7.0, and 6.9.1. The default is now 4.6.2.

Note that Node.js v6 was promoted to LTS status on October 18, 2016 and will soon become the buildpack's default runtime. Node.js v0.10 reached end of life on October 31, 2016 and will soon no longer be included in the buildpack.
* Replace role with the [IAM role](https://cloud.ibm.com/docs/account?topic=account-userroles) you want to assign to your Cloud Functions namespace.
* (Optional) Include the --resource-type bucket and --resource <bucket-name> flags to limit access to a specific bucket. If you do not include these flags, access is granted at the service level.
* Replace <bucket-name>. with the name of your bucket.



You still need to pass the bucket name and endpoint during action invocation. You can avoid having to pass these values each time by binding them to the cloud-object-storage package or to a specific action in the package. To do this, see [Setting default parameters for a package or an action](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-pkg_obstoragepkg_obstorage_param_bind).





 Creating service credentials for accessing your IBM Cloud Object Storage instance 

If you plan to use the client-get-signed-url action, you must create [service credentials](https://cloud.ibm.com/docs/cloud-object-storage/iam?topic=cloud-object-storage-service-credentials). You can then [bind service credentials](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-pkg_obstoragepkg_obstorage_sc_bind) to the cloud-object-storagepackage.





 Binding your IBM Cloud Object Storage service credentials to the package or actions. 

To use the client-get-signed-url action in the cloud-object-storage package, you must bind your IBM Cloud Object Storage service credentials to the action.



* To bind service credentials to all actions in the package, use the service bind command in the CLI.
* To bind service credentials to individual actions, complete the following steps in the console.







 Binding service credentials in the console 



1. From the [Actions page](https://cloud.ibm.com/functions/actions), click cloud-object-storage package.
* [Logging](https://cloud.ibm.com/docs/codeengine?topic=codeengine-cefunctionsfunctions-logging)
* [Runtimes](https://cloud.ibm.com/docs/codeengine?topic=codeengine-cefunctionsfunctions-runtime)
* [Running Functions](https://cloud.ibm.com/docs/codeengine?topic=codeengine-cefunctionscefun-runfun)
* [Security](https://cloud.ibm.com/docs/codeengine?topic=codeengine-cefunctionscefun-security)
* [Invocation concurrency and scaling of Function instances](https://cloud.ibm.com/docs/codeengine?topic=codeengine-cefunctionsfunctions-concur-ce)
* [Packaging your source code for a Function](https://cloud.ibm.com/docs/codeengine?topic=codeengine-cefunctionsfunctions-packaging)



* [How can I get started with Functions?](https://cloud.ibm.com/docs/codeengine?topic=codeengine-cefunctionscefun-getstart)







 Release notes 

[Release notes](https://cloud.ibm.com/docs/codeengine?topic=codeengine-codeengine-relnotescodeengine-relnotes)



* [July 2023](https://cloud.ibm.com/docs/codeengine?topic=codeengine-codeengine-relnotescodeengine-jul23)



* Review the release notes for July 2023.
* [06 July 2023](https://cloud.ibm.com/docs/codeengine?topic=codeengine-codeengine-relnotescodeengine-jul0623)



* Updated Code Engine getting started information to include functions
* Added information comparing Code Engine apps, jobs, and functions
* Updated versions for buildpacks
If you are using Cloud Functions that are based on whisk.system actions, you can export your whisk.system action with the [ibmcloud fn action get](https://cloud.ibm.com/docs/openwhisk?topic=cloud-functions-cli-plugin-functions-clicli_action_get) command and including the --save option. The output contains the source code and references to required libraries. Then, [create a Code Engine Function](https://cloud.ibm.com/docs/codeengine?topic=codeengine-fun-create-local), based on the exported source artifacts. While a certain level of artifact compatibility is retained, you cannot export the Action metadata directly into Code Engine Functions.





 Can I bind my function to service credentials? 

Yes, service binds are supported! See [Working with service bindings to integrate IBM Cloud services with Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-service-binding).





 Where can I find information about my in progress and finished Code Engine Function runs? 

If you created your Function from source code, you can [view build logs](https://cloud.ibm.com/docs/codeengine?topic=codeengine-view-logsview-build-cli).

Otherwise, you can use [set up IBM Log Analysis](https://cloud.ibm.com/docs/codeengine?topic=codeengine-view-logsview-funlogs-ui) to view Platform logs, which contain information about your Function invocation (meta information) as well as log messages emitted by the Function code.
* [Action executions](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-limitslimits_exec)



* [Activation record](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-limitslimits_activation)







 Error handing for Cloud Functions 

[Error handing for Cloud Functions](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-error-handing-functionserror-handing-functions)





 CLI reference 

[CLI version history](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-cli_versionscli_versions)





 Regions 

[Regions](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-cloudfunctions_regionscloudfunctions_regions)



* [Cloud Functions endpoints](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-cloudfunctions_regionscloudfunctions_endpoints)
* [Cloud Functions web action endpoints](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-cloudfunctions_regionscloudfunctions_webaction_endpoints)







 Understanding high availability and disaster recovery for Cloud Functions 

[Understanding high availability and disaster recovery for Cloud Functions](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-ha_drha_dr)



* [High availability](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-ha_drhigh-availability)
* [Disaster recovery](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-ha_drdisaster-recovery)
This involves creating a service-to-service [authorization](https://cloud.ibm.com/docs/account?topic=account-serviceauth), and uses the new [Notifications Manager](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-pkg_obstoragepkg_obstorage_auth) IAM role.
2. Then, create a [trigger](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-pkg_obstoragepkg_obstorage_ev_trig_ui) to respond to the changes feed.
3. Then use the [IBM Cloud Object Storage package](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-pkg_obstoragepkg_obstorage_actions) to bind credentials and easily script common tasks.



For more information about using Cloud Functions with IBM Cloud Object Storage, see the Functions [documentation](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-pkg_obstorage).

It is not possible to use a bucket with a firewall [enabled](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-setting-a-firewall) as an event source for IBM Cloud® Functions actions.





 Next Steps 

Be sure to identify the appropriate [region and endpoint](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-cloudfunctions_regions) for your service. Then, verify your operations with specific [testing](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-test).
* The inclusion of a cached runtime for IBM SDK for Node.js v4.2.3.0, v4.2.2.0, v1.2.0.8 and v1.2.0.7, which are based on community versions Node.js v4.2.3, v4.2.2, v0.12.9 and v0.12.8.
* In addition, in v3.0beta the default Node.js runtime is changed to v4.2.3.



IBM Node.js buildpack v3.0beta is now released as a non-default buildpack on IBM Cloud with Node.js v4.2.3 as the default runtime. To ensure that your apps and services will continue to work on IBM Cloud, push your app with the beta version of the buildpack. After 30 days or longer, v3 will be made the default buildpack.

To push your app with v3.0beta:



* Use "-b" option in your ibmcloud cf push command:

ibmcloud cf push -b sdk-for-nodejs-v3beta
* Or use the "buildpack" option in your manifest.yml file:

buildpack: sdk-for-nodejs-v3beta



This change to the default runtime will not affect your app if you configured a specific version of Node.js in your app's package.json.

You can always specify the version of Node.js to run your app by using the engines.node entry in your package.json as explained in [Available versions](https://cloud.ibm.com/docs/cloud-foundry-public?topic=cloud-foundry-public-available_versions).





 23 November 2015 

Updated Liberty buildpack v2.2-20151119-1720
Setting access policies 

Access to IBM Cloud® Functions service instances for users in your account is controlled by IBM Cloud Identity and Access Management (IAM). For Cloud Functions, your Cloud Functions namespace is considered to be your service instance. Every user that accesses Cloud Functions entities in your namespace must be assigned an access policy with an IAM role defined. The policy determines what actions a user can perform within the context of the namespace that you select. The actions are then mapped to IAM user roles. If you created the namespace, then you do not need to set any IAM policies to view or work with your Cloud Functions entities.

Cloud Functions uses both the Platform and Service management roles. You can set policies about who can create namespaces at the platform level, and use the service roles to manage interaction with the namespaces themselves.



 How do I set IAM policies so that others can work with my namespace? 

In order for others to work with entities in your namespace, you must to set the appropriate [IAM policies in the console](https://cloud.ibm.com/iam/overview) or [with the CLI](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-iamcli-set).

The minimum Platform level access is Viewer. The minimum Service level access is Reader. For more information about Platform and Service level access roles, see [Platform management roles](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-iamiam_platform_roles) and [Service-specific roles](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-iamservice_specific_roles).

Want to learn more about IAM key concepts? Check out [the IAM overview](https://cloud.ibm.com/docs/account?topic=account-iamoverview) or the [Best practices for assigning access](https://cloud.ibm.com/docs/account?topic=account-account_setup).