<commit_before># A sample on developing and testing a reliable Orleans cluster locally

This sample shows how one can develop, test and deploy a cluster in reliable configuration locally.

Orleans is a building block to develop smart, resilient software-intensive cyber-physical systems. Such software systems do not exist in isolation and can fail in many ways, sometimes for technical reasons, because of reasons of the business context in which they operate or even due to socio-economic reasons. The purpose of this sample is to show one way of building a system that allows the developing team to build, debug, test and learn, even "feel" in controlled, everyday working way how their system as a whole functions and behaves and learn its logical limits. This should increase confidence within the team that they understand the limits and can pin-point and solve problems quickly when they eventually emerge. Consequently this enhances the communication with the stakeholders and increase the probability of success of a given projects or via enhanced learning the future projects.

Cyber-physical systems are often large, complex and dynamic, need to cope with external threats and optimize their behaviour and the software reflects this reality. It is likely cost and time prohibitive to asses risk of components in separation if possible at all. Also it is not possible to prepare and prevent foreseeable events, but it is possible to build resilience in systems and to the teams building such systems so they can quickly recover by locating faults and adapting. This should in turn instil confidence to communications when faced with time limits or address [cross-cutting concerns](https://en.wikipedia.org/wiki/Cross-cutting_concern) and consequently increase project success factor. Actor systems such as Orleans can make this easier.

There are excellent general resources about complex systems development in Internet. Prominent examples are [How Complex Systems Fail](https://www.youtube.com/watch?v=2S0k12uZR14) by **<NAME>**, [Antics, drift, and chaos](https://www.youtube.com/watch?v=SM2uXpmyJmA) by **<NAME>** and articles such as [Simple testing can prevent most critical failures](https://blog.acolyer.org/2016/10/06/simple-testing-can-prevent-most-critical-failures/) by **Yuan et al. OSDI 2014** (via **<NAME>**). Other worthwhile resources are [Entities, Identities & Registries: Gaps in Corporate and IoT Identity](https://ssimeetup.org/gaps-corporate-iot-identity-heather-vescent-webinar-35/) by **<NAME>** and Ethics in Action: The IEEE Global Initiative of Ethics of Autonomous and Intelligent Systems, the P7000™ titled standards, at [Ethics in Action](https://ethicsinaction.ieee.org/) and [IPSO Smart Objects](https://www.omaspecworks.org/develop-with-oma-specworks/ipso-smart-objects/) for identities, [STELLA: report from the SNAFU-catchers workshop on coping with complexity](https://blog.acolyer.org/2020/01/20/stella-coping-with-complexity-2/) on humans within complex (agent) systems and [Challenges of real-world reinforcement learning](https://blog.acolyer.org/2020/01/13/challenges-of-real-world-rl/) [Assurance Monitoring of Cyber-Physical Systems with Machine Learning Components](https://deepai.org/publication/assurance-monitoring-of-cyber-physical-systems-with-machine-learning-components) what comes to using AI methods in cyber-physical, human-in-the-loop kind of systems and [Systems Thinking for Safety: Ten Principles](https://www.skybrary.aero/index.php/Toolkit:Systems_Thinking_for_Safety:_Ten_Principles) as a supplemental to core safety principles and [POTs: Protective Optimization Technologies](https://arxiv.org/abs/1806.02711) as a broad, general study.

As for this sample and a concrete case, consider an API can record `string` fields to database which have `NVARCHAR(MAX)` as their SQL Server type. This can lead to high resource consumption on the API but it can also quickly add to storage costs. If the number of rows increase rapidly, query times are probably affected as well. Mitigation likely involves limiting data field size, frequency of calls as well as database column constraints and perhaps sanitation measures. One should take measures to also protect against other systems under own administration in case they malfunction.

The sample shows a way to test the API together with storage on a developer machine, the tests could use a fuzzing library such as [SharpFuzz](https://github.com/Metalnem/sharpfuzz). This is also an opportunity to add a test to check no cross-site script (XSS) attacks exist, or even add [trusted types](https://github.com/WICG/trusted-types) to a web front-end and test its existence. The tests can also collect logs from the system and assert on them as part of normal testing, maybe to meet particular [SIEM process](https://en.wikipedia.org/wiki/Security_information_and_event_management) requirements. When these problems are found, they are the very least known and tested and can be mitigated. Also problematic inputs in production can be used as input in tests and debugged locally.

## Development, debugging and testing cycle

The development idea is that the developer can reset the development databases in case of relational database by either running the database project or publishing to it. Otherwise the tests make a differential backup in the beginning and restore it in the end. This way the developer can arrange data as per development and check using tests if they still pass, this allows for developing with data and even do exploratory testing as part of the development cycle. On the continuous integration server this is likely the opposite, one may want to restore the test database from a backup or a snapshot. Then when changes to other developers, continuous integration or even production are desired, they can be done on the `.sqlproj` and reviewed as per normal development flow, e.g. _reviewed in pull requets_.

At any time the database can be reset or snapshots deleted. There shouldn't be any snapshots visible unless the tests have been cancelled abruptly so that the test dispose haven't had the time to clean them off. In this case the tests do will fail unless the snapshots are deleted.

## Setting up the SQL Server Database

0. (_optional_) If you are using Visual Studio 2019 Community Edition, you need to edit the `OneBoxDeployment.Database.sqlproj` file, and set the `ArtifactReference` and `HintPath` to point to `Community`, instead of `Enterprise`.

1. This needs to be done only the first time<commit_msg>Improves adaptive and complex systems literature (#6454)<commit_after># A sample on developing and testing a reliable Orleans cluster locally

This sample shows how one can develop, test and deploy a cluster in reliable configuration locally.

Orleans is a building block to develop smart, resilient software-intensive cyber-physical systems. Such software systems do not exist in isolation and can fail in many ways, sometimes for technical reasons, because of reasons of the business context in which they operate or even due to socio-economic reasons. The purpose of this sample is to show one way of building a system that allows the developing team to build, debug, test and learn, even "feel" in controlled, everyday working way how their system as a whole functions and behaves and learn its logical limits. This should increase confidence within the team that they understand the limits and can pin-point and solve problems quickly when they eventually emerge. Consequently this enhances the communication with the stakeholders and increase the probability of success of a given projects or via enhanced learning the future projects.

Cyber-physical systems are often large, complex and dynamic, need to cope with external threats and optimize their behaviour and the software reflects this reality. It is likely cost and time prohibitive to asses risk of components in separation if possible at all. Also it is not possible to prepare and prevent foreseeable events, but it is possible to build resilience in systems and to the teams building such systems so they can quickly recover by locating faults and adapting. This should in turn instil confidence to communications when faced with time limits or address [cross-cutting concerns](https://en.wikipedia.org/wiki/Cross-cutting_concern) and consequently increase project success factor. Actor systems such as Orleans can make this easier.

There are excellent general resources about complex systems development in Internet. Prominent examples are [Resilience In Complex Adaptive Systems](https://www.youtube.com/watch?v=PGLYEDpNu60) [How Complex Systems Fail](https://www.youtube.com/watch?v=2S0k12uZR14) and associated paper [https://web.mit.edu/2.75/resources/random/How%20Complex%20Systems%20Fail.pdf (pdf)](https://web.mit.edu/2.75/resources/random/How%20Complex%20Systems%20Fail.pdf) by **<NAME>**, [Antics, drift, and chaos](https://www.youtube.com/watch?v=SM2uXpmyJmA) by **<NAME>** and articles such as [Simple testing can prevent most critical failures](https://blog.acolyer.org/2016/10/06/simple-testing-can-prevent-most-critical-failures/) by **Yuan et al. OSDI 2014** (via **<NAME>**). Other worthwhile resources are [Entities, Identities & Registries: Gaps in Corporate and IoT Identity](https://ssimeetup.org/gaps-corporate-iot-identity-heather-vescent-webinar-35/) by **<NAME>** and Ethics in Action: The IEEE Global Initiative of Ethics of Autonomous and Intelligent Systems, the P7000™ titled standards, at [Ethics in Action](https://ethicsinaction.ieee.org/) and [IPSO Smart Objects](https://www.omaspecworks.org/develop-with-oma-specworks/ipso-smart-objects/) for identities, [STELLA: report from the SNAFU-catchers workshop on coping with complexity](https://blog.acolyer.org/2020/01/20/stella-coping-with-complexity-2/) on humans within complex (agent) systems and [Challenges of real-world reinforcement learning](https://blog.acolyer.org/2020/01/13/challenges-of-real-world-rl/) [Assurance Monitoring of Cyber-Physical Systems with Machine Learning Components](https://deepai.org/publication/assurance-monitoring-of-cyber-physical-systems-with-machine-learning-components) what comes to using AI methods in cyber-physical, human-in-the-loop kind of systems and [Systems Thinking for Safety: Ten Principles](https://www.skybrary.aero/index.php/Toolkit:Systems_Thinking_for_Safety:_Ten_Principles) as a supplemental to core safety principles and [POTs: Protective Optimization Technologies](https://arxiv.org/abs/1806.02711) as a broad, general study.

As for this sample and a concrete case, consider an API can record `string` fields to database which have `NVARCHAR(MAX)` as their SQL Server type. This can lead to high resource consumption on the API but it can also quickly add to storage costs. If the number of rows increase rapidly, query times are probably affected as well. Mitigation likely involves limiting data field size, frequency of calls as well as database column constraints and perhaps sanitation measures. One should take measures to also protect against other systems under own administration in case they malfunction.

The sample shows a way to test the API together with storage on a developer machine, the tests could use a fuzzing library such as [SharpFuzz](https://github.com/Metalnem/sharpfuzz). This is also an opportunity to add a test to check no cross-site script (XSS) attacks exist, or even add [trusted types](https://github.com/WICG/trusted-types) to a web front-end and test its existence. The tests can also collect logs from the system and assert on them as part of normal testing, maybe to meet particular [SIEM process](https://en.wikipedia.org/wiki/Security_information_and_event_management) requirements. When these problems are found, they are the very least known and tested and can be mitigated. Also problematic inputs in production can be used as input in tests and debugged locally.

## Development, debugging and testing cycle

The development idea is that the developer can reset the development databases in case of relational database by either running the database project or publishing to it. Otherwise the tests make a differential backup in the beginning and restore it in the end. This way the developer can arrange data as per development and check using tests if they still pass, this allows for developing with data and even do exploratory testing as part of the development cycle. On the continuous integration server this is likely the opposite, one may want to restore the test database from a backup or a snapshot. Then when changes to other developers, continuous integration or even production are desired, they can be done on the `.sqlproj` and reviewed as per normal development flow, e.g. _reviewed in pull requets_.

At any time the database can be reset or snapshots deleted. There shouldn't be any snapshots visible unless the tests have been cancelled abruptly so that the test dispose haven't had the time to clean them off. In this case the tests do will fail unless the snapshots are deleted.

## Setting up the SQL Server Database

0. (_optional_) If you are using Visual Studio 2019 Community Edition, you need to edit the `OneBoxDeployment.Database.sqlproj` file, and set the `ArtifactReference` and `HintPath` to point to `Community`, instead of `Enterprise`.

1. This needs to be done only the first time
{'fraction_non_alphanumeric': 0.05978705978705979, 'fraction_numerical': 0.01027473754746482, 'mean_word_length': 5.09437386569873, 'pattern_counts': {'":': 0, '<': 11, '<?xml version=': 0, '>': 11, 'https://': 33, 'lorem ipsum': 0, 'www.': 9, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6065107', 'n_tokens_mistral': 3368, 'n_tokens_neox': 3130, 'n_words': 1775}