Coder Social home page Coder Social logo

bcgov / greenlight Goto Github PK

View Code? Open in Web Editor NEW
34.0 17.0 45.0 3.84 MB

A demonstration of the verifiable organization network showing a new restaurant gathering the permits necessary to open.

License: Apache License 2.0

Shell 24.82% Python 8.44% HTML 20.09% JavaScript 2.52% CSS 2.34% Dockerfile 0.86% TypeScript 38.21% SCSS 2.73%
von verifiable-claims hyperledger hyperledger-indy verifiable-organizations-network von-network verifiable-credentials citz

greenlight's Introduction

GreenLight

GreenLight (an instance of decentralized workFlow) demonstrates a basic application for deploying the VON-X library, in order to enable issuer registration, claims verification, and credential submission to TheOrgBook. It includes Docker tooling for deployment of the application behind a Caddy reverse proxy.

greenlight is being developed as part of the Verifiable Organizations Network (VON). For more information on VON see https://vonx.io. Even, better - join in with what we are doing and contribute to VON and the Indy community.

The GreenLight Business Scenario

The business problem addressed in this demo is a business trying to get Business Permits and Licences in their local municipality. Getting such authorizations are complicated processes, often requiring contacting multiple jurisdictions to acquire multiple credentials - licenses, permits, registrations, etc., each of which may require the presentation of previously acquired credentials from other sources. GreenLight simplifies the problem by:

  • Asking the user to select the business goal they are trying to achieve. For example, a Business Licence to open a restaurent, or a "Dog and Cat Breeder" permit.
  • Starting from the goal, evaluating the Hyperledger Indy prerequisite proof request to determine the credentials needed to acquire that credential.
  • Repeating that process for each pre-requisite credential until all the necessary licenses are determined
  • Presenting the user with a list of the credentials needed and the order of acquisition necessary to meet the prerequisites - e.g. starting from the credentials that have no prerequisites.
  • Laying over that the list of Credentials the business has already acquired.
  • Allowing the user to click from the list of needed credentials screen to either the application for that credential (if not yet acquired), or to TheOrgBook screen to see the already acquired credential.

Running a Complete VON Network

A quick start guide for running a complete local VON Network (including a local Indy Network, an instance of TheOrgBook and GreenLight) can be found in the VON Network Quick Start Guide.

Running Locally

Instructions for running just GreenLight locally can be found in the GreenLight docker folder.

Running a Shared Instance

GreenLight can be run on a server for multiple users. The docker folder provides guidance of what needs to be set up. Likewise, the openshift folder contains an example of deploying GreenLight to a Red Hat OpenShift instance.

Services

Services are defined using config files. See ./config folders for examples of the existing services.

Caveats

On dev machines

  • For Django's hot-reloading to work in development, the src directory needs to mounted as a volume. This only works when one "service" is defined in the docker-compose.yml since multiple services will clobber each other's config files that get copied in.

Adding a new issuing service to GreenLight

The steps below describe how to add and register a new issuer service to a GreenLight instance.

Prerequisites:

  • You have followed the OpenShift Scripts environment setup instructions to install and configure the scripts for use on your system (only for OpenShift deployments).

Create Configuration Files

First, create the configuration files for the new issuer service. For more information on creating and setting up the configuration files, please refer to the documentation in von-agent-template.

Update Caddy Configuration

Caddy needs to be configured to support proxying requests to the new agent. To do this, add the following proxy instructions to the Caddyfile, making sure to replace myorg with the mnemonic you previously picked.

proxy /myorg/health {%MYORG_AGENT_HOST%}:{%MYORG_AGENT_PORT%} {
    without /worksafe
}

proxy /myorg {%MYORG_AGENT_HOST%}:{%MYORG_AGENT_PORT%} {
    except /assets
    transparent
    fail_timeout 0
}

Update Docker Configuration

In docker-compose.yml:

  • add a section describing the new issuer service. Use the exisisting agents as example, and make sure to update any references to configuration files, etc.
    • remember to also add a volume for the agent, making sure the volume name and the environment variables match what is in the configuration.
...

myorg-agent:
    build:
      context: ..
      dockerfile: docker/agent/Dockerfile
    environment:
      DOCKERHOST: ${DOCKERHOST}
      APPLICATION_URL: ${APPLICATION_URL:-http://localhost:5000}
      ENDPOINT_URL: ${ENDPOINT_URL:-http://localhost:5000}
      CONFIG_ROOT: ../config/agri-agent
      ENVIRONMENT: ${ENVIRONMENT:-default}
      INDY_LEDGER_URL: ${LEDGER_URL:-http://localhost:9000}
      LOG_LEVEL: ${LOG_LEVEL:-}
      PYTHON_ENV: ${PYTHON_ENV:-development}
      TOB_API_URL: ${TOB_API_URL:-}
      TOB_APP_URL: ${TOB_APP_URL:-}
      POSTGRESQL_WALLET_HOST: ${POSTGRESQL_WALLET_HOST}
      POSTGRESQL_WALLET_PORT: ${POSTGRESQL_WALLET_PORT}
      POSTGRESQL_WALLET_USER: ${POSTGRESQL_USER}
      POSTGRESQL_WALLET_PASSWORD: ${POSTGRESQL_PASSWORD}
      POSTGRESQL_WALLET_ADMIN_PASSWORD: ${POSTGRESQL_ADMIN_PASSWORD}
      WALLET_ENCRYPTION_KEY: ${WALLET_ENCRYPTION_KEY}
      INDY_WALLET_TYPE: ${INDY_WALLET_TYPE}
      INDY_WALLET_SEED: ${MYORG_WALLET_SEED:-}
    networks:
      - orgbook
      - vonx
    depends_on:
      - agent-wallet-db
    volumes:
      - myorg-agent-wallet:/home/indy/.indy_client/wallet

...

volumes:
  myorg-agent-wallet:
  ...
  • add environment variables and dependencies referencing the new agent to the proxy-dev and caddy services
proxy-dev:
    image: "abiosoft/caddy:no-stats"
    environment:
      ...
      MYORG_AGENT_HOST: ${MYORG_AGENT_HOST}
      MYORG_AGENT_PORT: ${MYORG_AGENT_PORT}
      ...
    depends_on:
      ...
      - myorg-agent
      ...

...

caddy:
    image: greenlight
    environment:
      ...
      MYORG_AGENT_HOST: ${MYORG_AGENT_HOST}
      MYORG_AGENT_PORT: ${MYORG_AGENT_PORT}
      ...
    depends_on:
      - myorg-agent
      ...

In the manage script in the docker directory:

  • export the environment variables for the new agent. See how this is done for other agents in the configuration section related to "caddy".
export MYORG_AGENT_HOST=${MYORG_AGENT_HOST:-myorg-agent}
export MYORG_AGENT_PORT=${MYORG_AGENT_PORT:-8000}  
  • add the new agent to the DEFAULT_CONTAINERS list.
DEFAULT_CONTAINERS="agent-wallet-db myorg-agent bcreg-agent ministry-finance-agent city-surrey-agent fraser-valley-agent liquor-control-agent worksafe-agent"

Update OpenShift Configuration

If you use OpenShift, you will be interested in adding a new deployment configuration for the new agent, and updating the deployment configuration for GreenLight to correctly proxy requests.

  • In the openshift/agents folder, copy one of the existing agents deployment configurations and create a new one.
    • Make sure to update the name and all the variables in the deployment configuration to reflect the new agent mnemonic picked for the configuration files.
  • from within the openshift folder, run genParams.sh create the parameter files for the new deployment configuration.
  • create an .overrides.sh file for the new agent, following one of the other agents as example.

greenlight's People

Contributors

andrewwhitehead avatar benjsmi avatar brycecurtis avatar dependabot[bot] avatar eirikur avatar esune avatar ianco avatar jljordan42 avatar maherbouidani avatar nrempel avatar repo-mountie[bot] avatar swcurran avatar wadebarnes avatar weiiv avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

greenlight's Issues

USe credential-specific URLs for each step

dFlow i currently using the "general" issuer URL to wire up the action button to "enroll" with a specific issuer. It should instead use the credential-specific URL exposed by the credentialtype ToB API endpoint.

dFlow: make path selection generic

The current instance of dFlow (previously known as permitify) uses a hard-coded dependency structure to define the graph for the restaurant recipe.

We want to be able to pick one of the schemas currently published to the ledger, and generate the dependency structure dynamically, so that the graph and the steps to complete will change accordingly.

Update domain names

The *.orgbook.gov.bc.ca DNS records have been created. Update the domain names in the configurations.

Permitify/dflow:

  • dev-dflow.orgbook.gov.bc.ca
  • dflow.orgbook.gov.bc.ca

The OrgBook Demo:

  • dev-demo.orgbook.gov.bc.ca

  • dev-demo-api.orgbook.gov.bc.ca

  • demo.orgbook.gov.bc.ca

  • demo-api.orgbook.gov.bc.ca

Development mode for dFlow in Docker

The containerized version of dFlow does currently not support hot-reloading of the Angular app. This means that every time a change is made to the frontend, at least the whole Caddy/proxy container needs to be destroyed, build and restarted.

This is a tedious process and reduces the time and productivity when developing the frontend. Adding hot-reloading capabilities would be a big improvement for developers working on dFlow.

Investigate platforms for running a permitify-based demo

Investigate how best to run a Permitify-based demo in a workshop environment. Ideally, the platform would be browser-based so we would not have to pre-announce prerequisites for the workshop (like git, docker, etc). Investigate: learn.openshift.com and the platform provider that it use - katacoda.

In selecting a platform, define what we will have to put in place to run on the platform (e.g. shell scripts, browsers, etc.).

NOTE: git and github might be reasonable pre-requisites. Docker running locally is a harder one.

Add the "Dog and Cat Breeder Licence" Agent to dFlow

The configuration for the "Dog and Cat Breeder Licence" can be found in the temporary github repo - https://github.com/swcurran/DogAndCatBreeders. Please extract the VON-X Agent .yml files from there, add them to dFlow and a the Dog and Cat Breeders license to the set of dFlow agents.

In doing that, please document how to add new Agents to dFlow, so we can make this a simple process. Include docker steps and OpenShift steps for the process.

Thanks!

dFlow refactoring

After using the initial prototype of dFlow, some refactoring effort is required to address some of the "sharp edges" that were left on the product. This is a list of items that require checking, it is not complete and will be updated with new items. It will require breaking down and estimating work once ready to tackle it.

General
  • Theming support: is it required?
  • i18n: is it required?
  • types: define types for all the objects returned by API calls, and use them in the code.
  • tob.service: request to ToB API returns all the schemas, not only the latest versions. If a filter on the API is not the right/best solution, update the code to only display the latest version registered schemas.
  • error handling: add some minimal error handling to the application
  • handle paginated results when requesting data to the ToB API
Modules
  • create progress/spinner module that can be reused in other parts of dFlow, or migrated to other apps
Graph
  • investigate better angular integration: d3 and dagre-d3 are responsible for drawing the graph portion of dFlow and, while they work great, they cause the graph to be "disconnected" from the Angular framework. It would be great if they could merge seamlessly, allowing events and elements to be handled without issues.
  • data requests: investigate the possibility of optimizing the order and performance of the request to the API exposed by ToB.

Update von-agent-template and the workshop with a realistic business use case

With the first cut of the workshop successfully implemented and delivered (whoohoo!!), I'd like to take a cut at making it more of a realistic business case - a story. The workshop will be aimed both at other workshops, people running it independently and organizations onboarding, so that they understand the flow.

The following are the basic steps of the workshop. I'll revise this as I work through it, but the main idea is to focus on a realistic use case of a permit issuer and the configuration updates they make to trigger the features of TOB.

  1. Initialize von-agent, including building and start an agent that issues no credentials. May not be possible and if not, have a single credential. If there can be no credentials, the only actions will be to open the wallet, run the agent and show a 404 when hitting URL:5001.

Why no agent? Because if you have one and then change it, you have to up the schema version and you wind up with two entries in dFlow.

  1. Add (or revise if necessary) the permit credential - including updating the places about that Credential, it's attributes, form and single dependency - the Permitify dflow Registration (foundational credential). Build/Start and use the agent to issue credentials with form, permitify and curl. Go into TOB to look at the credentials.

  2. Add additional dependency (e.g. Worksafe or another workshop participants) and rerun (build, start) in permitify to show the dynamic nature of permitify.

  3. Add cardinality, and translation strings to show how to control presentation. Add any other features that alter the behaviour of TOB based on the Issuers configuration.

Included in this will be readme that walks through the setup and has the code to be cut'n'pasted into the yml files.

Will also update the init.sh script to handle both a local and Play With Docker run.

Add webhook for new pipeline

The is a new pipeline named "agent-pipeline" in devex-von-permitify-tools, that takes care of building the base image used by all of the issuers in dFlow.

There doesn't seem to be a Github webhook configured to trigger it when changed are merged to the master branch in the repo, so we need to configure one.

Renaming repository to dFlow

As previously discussed, we need to rename the permitify repositoryusing its new nomenclaturedflow`.

The tasks include:

  • renaming the github repository
  • update the repository references in the OpenShift builds and pipelines
  • ensuring the webhooks used by the OpenShift pipelines in devex-von-permitify-tools still work
  • determine whether additional action items are required for retro-compatibility: what happens when something sends a request to the old repo URL?

Error 306

================================================================================
person_1 | % Total % Received % Xferd Average Speed Time Time Time Current
person_1 | Dload Upload Total Spent Left Speed
100 173 100 130 100 43 34 11 0:00:03 0:00:03 --:--:-- 34{"seed":"bc_registries_000000000000000000","did":"7VkdE3erBDJnrQMVbEnRzg","verkey":"4YLsvyVBs7qLYwYoDy6bTmxujFf1Kdx5jGuNM7jhdKjd"}
person_1 | Starting server ...
person_1 | INFO 2018-10-07 15:36:47,616 agent 1 140107237312256 acquiring lock for Issuer
person_1 | INFO 2018-10-07 15:36:47,616 agent 1 140107237312256 acquired lock for Issuer
person_1 | WARNING 2018-10-07 15:36:49,166 libindy 1 140107237312256 _indy_loop_callback: Function returned error 306
person_1 | INFO 2018-10-07 15:36:49,167 nodepool 1 140107237312256 Pool ledger config for permitify-issuer already exists
person_1 | WARNING 2018-10-07 15:36:49,682 libindy 1 140107237312256 _indy_loop_callback: Function returned error 203
person_1 | INFO 2018-10-07 15:36:49,682 wallet 1 140107237312256 Opening existing wallet: Gov ID Issuer Wallet
person_1 | INFO 2018-10-07 15:36:49,876 wallet 1 140107237312256 Opened wallet Gov ID Issuer Wallet on handle 3
person_1 | INFO 2018-10-07 15:36:50,473 agent 1 140107237312256 Issuer releasing lock
person_1 | DEBUG 2018-10-07 15:36:50,486 schema 1 140107237312256
person_1 | ============================================================================

Can anyone help me solving this error please?

Implement a permitify service endpoint to enable the creation of dynamic recipes

Create a permitify endpoint that requests the prerequisite credential definitions for a given credential issued by the Service. Something like:

/api/credential/prerequisites?credential=<credDef>
Returns:
{
   "prerequisites" : [
        "prerequisite" : "<credDef>"
    ]
}

The endpoint would be called recursively from a goal credential to create a Permitify recipe.

Use that endpoint to dynamically generate a recipe page, including constructing a proof request that is passed to your wallet to determine which of the credentials you already have, and the ordering needed for getting the rest of the credentials.

`Casting error to ErrorCode: Wallet not found: Storage not found` - on agent start-up

This issue is most prevalent in dFlow due to the number of agents contained in the project, however the cause was identified during a debugging session with Ontario's onbis-x-agent were multiple instances were being spun up to perform an initial data load.

The issue occurs when there are a number of agents spinning up at the same time and connecting to the same wallet. The number of connections opened by the multiple agents exceeds the max connections of the database. New connections then fail, with the stated error, until previous ones are released. The other side affect of this is that the health check on the database container starts to fail because it can't connect due to the lack of available connections. As a result the database container will stop receiving requests, altogether, for a period of time.

Before we just go upping the number of connections on the wallet database we should have a look into the postgresql wallet plug-in's connection management.

indy.error.IndyError: ErrorCode.WalletNotFoundError

In your README you say "try incrementing the schema version and fully restarting the server" to resolve this error. However, where should the schema version be incremented?permitify/site_templates/bc_registries/schemas.json? That didn't seem to work when I tried it.

Also, why would that have any effect when the docker-compose.yml file sets the env var PYTHON_ENV: development, which in the code appears to set all of the schema versions to "0.0.0":

https://github.com/bcgov/permitify/blob/fd912a89f29fc67c5074dfd69717bce5ffbd4c9d/src/von_connector/schema.py#L37-L39

Is there something else I'm supposed to do to get the wallet to work?

Angularize Permitify

As we add new functionality to Permitify, it becomes more difficult to maintain a simple application composed of static assets (JS/HTML/CSS).

We should upgrade Permitify and and create a single-page app: this would make it easier to maintain, and add new functionality in the form of modules that can be reused.

indy.error.IndyError: ErrorCode.CommonInvalidState

I am following the quick start guide (https://github.com/bcgov/TheOrgBook/blob/master/docker/README.md#running-a-complete-provisional-von-network). I am receiving the following error (indy.error.IndyError: ErrorCode.CommonInvalidState) while starting the permitify. Below is the output:

bc@FRA1000013983:~/blockchain/indy/bcgov/permitify/docker$ ./manage start seed=issuer_service_00000000000000000 TOB_INDY_SEED=the_org_book_0000000000000000000
WARNING: The RUST_BACKTRACE variable is not set. Defaulting to a blank string.
permitify_redis_1 is up-to-date
Creating permitify_bc_registries_1 ...
Creating permitify_bc_registries_1 ... done
Attaching to permitify_bc_registries_1
bc_registries_1 | ==================================================================================
bc_registries_1 | Initializing issuer service.
bc_registries_1 | ----------------------------------------------------------------------------------
bc_registries_1 |
bc_registries_1 | TEMPLATE_NAME: bc_registries
bc_registries_1 | INDY_WALLET_SEED: issuer_service_00000000000000001
bc_registries_1 | INDY_WALLET_TYPE: virtual
bc_registries_1 | WEB_CONCURRENCY: 1
bc_registries_1 | DEBUG:
bc_registries_1 | Cmd: /usr/libexec/s2i/s2i_run
bc_registries_1 | ==================================================================================
bc_registries_1 |
bc_registries_1 | Copying template directory; /home/indy/site_templates/bc_registries ...
bc_registries_1 |
bc_registries_1 | Starting server ...
bc_registries_1 |
bc_registries_1 | ---> Serving application with gunicorn (wsgi) ...
bc_registries_1 | [2018-09-17 13:40:39 +0000] [1] [INFO] Starting gunicorn 19.7.1
bc_registries_1 | [2018-09-17 13:40:39 +0000] [1] [INFO] Listening at: http://0.0.0.0:8080 (1)
bc_registries_1 | [2018-09-17 13:40:39 +0000] [1] [INFO] Using worker: sync
bc_registries_1 | [2018-09-17 13:40:39 +0000] [78] [INFO] Booting worker with pid: 78
bc_registries_1 | ERROR 2018-09-17 13:40:40,319 apps 78 139664008779520 startup code ...
bc_registries_1 | DEBUG 2018-09-17 13:40:40,323 apps 78 139664008779520 running ...
bc_registries_1 | DEBUG 2018-09-17 13:40:40,323 apps 78 139664008779520 running in run ...
bc_registries_1 | DEBUG 2018-09-17 13:40:40,323 agent 78 139664008779520 Issuer init>>>
bc_registries_1 | INFO 2018-09-17 13:40:40,323 genesis 78 139664008779520 Using genesis transaction file from http://10.206.61.105:9000/genesis ...
bc_registries_1 | INFO 2018-09-17 13:40:40,328 genesis 78 139664008779520 Writing genesis transaction file to, /home/indy/genesis ...
bc_registries_1 | DEBUG 2018-09-17 13:40:40,330 agent 78 139664008779520 Using virtual Cfg: {'freshness_time': 0} Creds: {'key': '', 'virtual_wallet': None}
bc_registries_1 | DEBUG 2018-09-17 13:40:40,330 agent 78 139664008779520 Issuer init>>> create wallet virtual {'freshness_time': 0} {'key': '', 'virtual_wallet': None}
bc_registries_1 | DEBUG 2018-09-17 13:40:40,330 agent 78 139664008779520 Issuer init>>> done virtual {'freshness_time': 0} {'key': '', 'virtual_wallet': None}
bc_registries_1 | DEBUG 2018-09-17 13:40:40,330 agent 78 139664008779520 Issuer init>>> created VonIssuer
bc_registries_1 | DEBUG 2018-09-17 13:40:40,330 agent 78 139664008779520 Issuer aenter>>>
bc_registries_1 | INFO 2018-09-17 13:40:40,330 agent 78 139664008779520
bc_registries_1 |
bc_registries_1 |
bc_registries_1 | ==========await self.pool.open()==========
bc_registries_1 |
bc_registries_1 |
bc_registries_1 |
bc_registries_1 | INFO|command_executor | src/commands/mod.rs:68 | Worker thread started
bc_registries_1 | INFO|indy::commands | src/commands/mod.rs:99 | PoolCommand command received
bc_registries_1 | INFO|pool_command_executor | src/commands/pool.rs:56 | Create command received
bc_registries_1 | INFO|indy::commands | src/commands/mod.rs:99 | PoolCommand command received
bc_registries_1 | INFO|pool_command_executor | src/commands/pool.rs:64 | Open command received
bc_registries_1 | DEBUG|zmq |/home/indy/.cargo/registry/src/github.com-1ecc6299db9ec823/zmq-0.8.2/src/lib.rs:410 | context dropped
bc_registries_1 | ERROR|indy::services::pool | src/services/pool/mod.rs:426 | Pool worker thread finished with error CommonError(InvalidState("MerkleTree contains invalid data Syntax("missing field data")"))
bc_registries_1 | INFO|indy::commands | src/commands/mod.rs:99 | PoolCommand command received
bc_registries_1 | DEBUG|zmq |/home/indy/.cargo/registry/src/github.com-1ecc6299db9ec823/zmq-0.8.2/src/lib.rs:503 | socket dropped
bc_registries_1 | INFO|indy::commands::pool | src/commands/pool.rs:68 | OpenAck handle 1, pool_id 2, result Err(CommonError(InvalidState("MerkleTree contains invalid data Syntax("missing field data")")))
bc_registries_1 | ERROR|indy::errors::indy | src/errors/indy.rs:72 | Casting error to ErrorCode: Invalid library state: MerkleTree contains invalid data Syntax("missing field data")
bc_registries_1 | ERROR|indy::errors::indy | src/errors/indy.rs:74 | Backtrace: stack backtrace:
bc_registries_1 | 0: 0x7f06071c1cec - backtrace::backtrace::trace::hc0a4868e3bd2cdd4
bc_registries_1 | 1: 0x7f06071bea22 - backtrace::capture::Backtrace::new::he25e1ff8089ac60f
bc_registries_1 | 2: 0x7f0606db889a - <indy::errors::indy::IndyError as indy::errors::ToErrorCode>::to_error_code::hd9d063cbf277f48c
bc_registries_1 | 3: 0x7f0606dfe278 - indy::api::pool::indy_open_pool_ledger::{{closure}}::h7880ff50eecf7671
bc_registries_1 | 4: 0x7f0606c3e724 - indy::commands::pool::PoolCommandExecutor::execute::hbb366030b2f70f96
bc_registries_1 | 5: 0x7f0606dc5684 - std::sys_common::backtrace::__rust_begin_short_backtrace::h15a1dedfd882ab72
bc_registries_1 | 6: 0x7f0606c320c2 - std::panicking::try::do_call::h0b12810d744f34f6
bc_registries_1 | 7: 0x7f0607454c4e - __rust_maybe_catch_panic
bc_registries_1 | at libpanic_unwind/lib.rs:102
bc_registries_1 | 8: 0x7f0606dcf939 - <F as alloc::boxed::FnBox>::call_box::h8c0ad5d1fa7772ac
bc_registries_1 | 9: 0x7f060744bd77 - <alloc::boxed::Box<alloc::boxed::FnBox<A, Output$u3d$R$GT$$u20$$u2b$$u20$$u27$a$GT$$u20$as$u20$core..ops..function..FnOnce$LT$A$GT$$GT$::call_once::h3a46ab40d44ff8db
bc_registries_1 | at /checkout/src/liballoc/boxed.rs:794
bc_registries_1 | - std::sys_common::thread::start_thread::heca3dbba8ff4f46a
bc_registries_1 | at libstd/sys_common/thread.rs:24
bc_registries_1 | 10: 0x7f060741ae38 - std::sys::unix::thread::Thread::new::thread_start::ha1ecaaa6d3efa77d
bc_registries_1 | at libstd/sys/unix/thread.rs:90
bc_registries_1 | 11: 0x7f060f5e56b9 - start_thread
bc_registries_1 | 12: 0x7f060ec0b41c - clone
bc_registries_1 | 13: 0x0 -
bc_registries_1 | WARNING 2018-09-17 13:40:40,363 libindy 78 139664008779520 _indy_loop_callback: Function returned error 112
bc_registries_1 | [2018-09-17 13:40:40 +0000] [78] [ERROR] Exception in worker process
bc_registries_1 | Traceback (most recent call last):
bc_registries_1 | File "/home/indy/.pyenv/versions/3.6.3/lib/python3.6/site-packages/gunicorn/arbiter.py", line 578, in spawn_worker
bc_registries_1 | worker.init_process()
bc_registries_1 | File "/home/indy/.pyenv/versions/3.6.3/lib/python3.6/site-packages/gunicorn/workers/base.py", line 126, in init_process
bc_registries_1 | self.load_wsgi()
bc_registries_1 | File "/home/indy/.pyenv/versions/3.6.3/lib/python3.6/site-packages/gunicorn/workers/base.py", line 135, in load_wsgi
bc_registries_1 | self.wsgi = self.app.wsgi()
bc_registries_1 | File "/home/indy/.pyenv/versions/3.6.3/lib/python3.6/site-packages/gunicorn/app/base.py", line 67, in wsgi
bc_registries_1 | self.callable = self.load()
bc_registries_1 | File "/home/indy/.pyenv/versions/3.6.3/lib/python3.6/site-packages/gunicorn/app/wsgiapp.py", line 65, in load
bc_registries_1 | return self.load_wsgiapp()
bc_registries_1 | File "/home/indy/.pyenv/versions/3.6.3/lib/python3.6/site-packages/gunicorn/app/wsgiapp.py", line 52, in load_wsgiapp
bc_registries_1 | return util.import_app(self.app_uri)
bc_registries_1 | File "/home/indy/.pyenv/versions/3.6.3/lib/python3.6/site-packages/gunicorn/util.py", line 352, in import_app
bc_registries_1 | import(module)
bc_registries_1 | File "/home/indy/wsgi.py", line 16, in
bc_registries_1 | application = get_wsgi_application()
bc_registries_1 | File "/home/indy/.pyenv/versions/3.6.3/lib/python3.6/site-packages/django/core/wsgi.py", line 12, in get_wsgi_application
bc_registries_1 | django.setup(set_prefix=False)
bc_registries_1 | File "/home/indy/.pyenv/versions/3.6.3/lib/python3.6/site-packages/django/init.py", line 24, in setup
bc_registries_1 | apps.populate(settings.INSTALLED_APPS)
bc_registries_1 | File "/home/indy/.pyenv/versions/3.6.3/lib/python3.6/site-packages/django/apps/registry.py", line 120, in populate
bc_registries_1 | app_config.ready()
bc_registries_1 | File "/home/indy/von_connector/apps.py", line 134, in ready
bc_registries_1 | issuer_service_id = eventloop.do(run())
bc_registries_1 | File "/home/indy/von_connector/eventloop.py", line 24, in do
bc_registries_1 | return event_loop.run_until_complete(coro)
bc_registries_1 | File "/home/indy/.pyenv/versions/3.6.3/lib/python3.6/asyncio/base_events.py", line 467, in run_until_complete
bc_registries_1 | return future.result()
bc_registries_1 | File "/home/indy/von_connector/apps.py", line 76, in run
bc_registries_1 | async with Issuer() as agent:
bc_registries_1 | File "/home/indy/von_connector/agent.py", line 86, in aenter
bc_registries_1 | await self.pool.open()
bc_registries_1 | File "/home/indy/.pyenv/versions/3.6.3/lib/python3.6/site-packages/von_agent/nodepool.py", line 153, in open
bc_registries_1 | self._handle = await pool.open_pool_ledger(self.name, json.dumps(self.cfg))
bc_registries_1 | File "/home/indy/.pyenv/versions/3.6.3/lib/python3.6/site-packages/indy/pool.py", line 82, in open_pool_ledger
bc_registries_1 | open_pool_ledger.cb)
bc_registries_1 | indy.error.IndyError: ErrorCode.CommonInvalidState
bc_registries_1 | [2018-09-17 13:40:40 +0000] [78] [INFO] Worker exiting (pid: 78)
bc_registries_1 | [2018-09-17 13:40:40 +0000] [1] [INFO] Shutting down: Master
bc_registries_1 | [2018-09-17 13:40:40 +0000] [1] [INFO] Reason: Worker failed to boot.
permitify_bc_registries_1 exited with code 3

Add search functionality to start page

As a user, I want to be able to pick-up where I left once I start going through dFlow.

It is currently possible to enter a topic ID, but this mechanism is not easy to use.

A search functionality similar to the one in ToB is necessary to make this process more user-friendly and easy to use.

ministry_of_finance node pool error

Progressing gradually through the demo, my next error occurred while using the Ministry of Finance service at localhost:5002:

...
ministry_of_finance_1                  |  INFO|indy::commands                |                src/commands/mod.rs:107 | PoolCommand command received
ministry_of_finance_1                  |  INFO|pool_command_executor         |               src/commands/pool.rs:54  | Create command received
ministry_of_finance_1                  | ERROR|indy::errors::indy            |                 src/errors/indy.rs:63  | Casting error to ErrorCode: Pool ledger config already exists Pool ledger config file with 
name "permitify-verifier" already exists                                                                                                                                                                          
ministry_of_finance_1                  | WARNING 2018-01-31 20:15:34,151 libindy 28 140317762131712 _indy_loop_callback: Function returned error 306
ministry_of_finance_1                  | INFO 2018-01-31 20:15:34,152 nodepool 28 140317762131712 Pool config already exists.
ministry_of_finance_1                  |  INFO|indy::commands                |                src/commands/mod.rs:107 | PoolCommand command received
ministry_of_finance_1                  |  INFO|pool_command_executor         |               src/commands/pool.rs:62  | Open command received
ministry_of_finance_1                  | ERROR|indy::errors::indy            |                 src/errors/indy.rs:63  | Casting error to ErrorCode: Invalid Handle: Pool with same name already opened
ministry_of_finance_1                  | WARNING 2018-01-31 20:15:34,154 libindy 28 140317762131712 _indy_loop_callback: Function returned error 301
ministry_of_finance_1                  | WARNING 2018-01-31 20:15:34,154 libindy 28 140317762131712 _indy_loop_callback: Function returned error 301
ministry_of_finance_1                  | ERROR 2018-01-31 20:15:34,154 exception 28 140317762131712 Internal Server Error: /
Traceback:
...
ministry_of_finance_1                  |   File "/app/permitify/views.py", line 40, in index
ministry_of_finance_1                  |     'legal_entity_id': legal_entity_id
ministry_of_finance_1                  |   File "/app/von_connector/proof.py", line 79, in request_proof
ministry_of_finance_1                  |     return eventloop.do(run(filters))
ministry_of_finance_1                  |   File "/app/von_connector/eventloop.py", line 24, in do
ministry_of_finance_1                  |     return event_loop.run_until_complete(coro)
...
ministry_of_finance_1                  |   File "/app/von_connector/proof.py", line 42, in run
ministry_of_finance_1                  |     async with Verifier() as verifier:
ministry_of_finance_1                  |   File "/app/von_connector/agent.py", line 58, in __aenter__
ministry_of_finance_1                  |     await self.pool.open()
ministry_of_finance_1                  |   File "/usr/local/lib/python3.5/dist-packages/von_agent/nodepool.py", line 111, in open
ministry_of_finance_1                  |     self._handle = await pool.open_pool_ledger(self.name, None)
ministry_of_finance_1                  |   File "/usr/local/lib/python3.5/dist-packages/indy/pool.py", line 82, in open_pool_ledger
ministry_of_finance_1                  |     open_pool_ledger.cb)
...
ministry_of_finance_1                  | indy.error.IndyError: ErrorCode.PoolLedgerInvalidPoolHandle

(Traceback lines not in permitify code omitted)

It worked when I tried a second time though...

Update permitify schema and mapping to ensure TheOrgBook is being populated fully for the demo

TheOrgBook is populated from credentials using a mapping definition. Incoming credentials in TheOrgBook are parsed and the application database in TheOrgBook is updated.

The "foundational" credential is a credential is one that creates a "topic" in TheOrgBook. It also generates an organization page. Currently, the permitify uses a schema with a minimal set of attributes. It works, but some of the fields are left blank in TheOrgBook. See the following images:

permitify:
Screen Shot 2018-10-29 at 3.46.50 PM.png

real bc registries data from prod:
Screen Shot 2018-10-29 at 3.48.00 PM.png

You can use the real bc registries von-x configuration as a starting point.

The schema is here: https://github.com/ianco/von-bc-registries-agent/blob/master/bcreg-x/config/schemas.yml

the mapping is here: https://github.com/ianco/von-bc-registries-agent/blob/master/bcreg-x/config/services.yml#L50

I recommend starting by trying to copy over the schema and mapping and changing only what is required if there are any problems.

Workshop for implementing Permitify Services

Create a workshop suitable for completion in three hours about Permitify that involves deploying TheOrgBook, some Permitify services and a recipe, and then generate a new service that integrates with the existing model.

Re-Factor Permitify to use VON-X

The code aspect of the Permitify repo will be deprecated.
The re-factored repo will include documentation and configuration files necessary to create a multi-issuer/verifier <-> ToB demonstration ecosystem

von connector/agent

Just curious, but what is the relationship between the various versions and repositories containing von_connector and von_agent? They seem to exist in multiple places...

Update to `bcgovimages/von-image:1.6-ew-11*` images

Update to bcgovimages/von-image:1.6-ew-11* images to pick up von_anchor v1.6.37.

A necessary 256-bit compliant encoder has been added to von_anchor, affecting credentials. Unfortunately it is not backwardly compatible with older credentials so they will need to be reloaded.

Environments to update:

  • devex-von-permitify-dev
  • devex-von-permitify-test

Investigate the possibility of a multi-jurisdictional Permitify Recipe

Once we have upgraded the Permitify demonstration environment to be based on VON-X architecture.

Would be interesting to create a multi-jurisdictional recipe.

For example (to be determined and discussed)
Goal: Become an aboriginal supplier for GC to compete for a contract to supply food to a Corrections Canada BC based facility

Incorporate in ON -> Update ON ToB

Extra-Provinically Register in BC -> Update BC ToB (maybe ON ToB as well?)

Get a PST and Worksafe in BC -> Update BC ToB

Register in SRI as ON Legal entity -> Update PSPC ToB

Get PSAB status -> Update PSPC ToB

Create the (at least) static recipe page for Permitify

Recreate the static page of the old Permitify recipe. Change the UI for the page so that the recipe image contains the status of the Credential (needed, obtained - by text and colour) and the link to get or see (respectively) the Credential.

On the current "Start Demo" page, provide a (static initially) list of recipes, each of which link to a recipe. The first can be "City of Surrey - business license for a licensed restaurant", which links to the old Permitify recipe page.

Make it so that we can easily add new named recipes.

Additional tickets will be added about making the recipe page dynamic.

Define the Service specific elements of Permitify and define how to generate those elements

We'd like to create a tool (such as yeoman ) that will enable generation of a new Permitify-enabled service. Review Permitify and determine the steps for generating a new Permitify Service and the elements that one would manually tune for the specifics of the service. For example - defining the:

  • Proof Requests for verification
  • the credentials for issuance
  • the data entry form that simulates the application
  • the services.yml file for TOB integration
  • the icon for the service
  • perhaps a theme for the data entry form business

Document the list and perhaps some ideas for tools we could use for the data entry of each.

Performance/Load Testing Investigation

This is a placeholder for performance/load testing for dFlow and supporting environments (toB, Ledger).

We have noticed that the system tends to respond slowly to requests that involve querying data coming from the ledger and the agents. We need a way of testing performance, determining possible bottlenecks and addressing the root cause to increase usability.

Example: the call to the /get-credential-dependencies call (that can be issued against any of the running von-x agents), seems to often take more than 30 seconds to complete, incurring in the default timeout time for http requests. While it may be possible to increase the timeout, it would not be a good solution since taking a very long time to complete the request that will indicate the steps that are required to obtain a specific credential reduces the usability of the system.

In addition to ensuring requests are handled correctly in dFlow, we should investigate the underlying back-end layers (von-x, ToB, Ledger) and identify improvements.

Permitify 1.5 Epic - Deploy the current docker version of Permitify on OpenShift Dev and Test

Take the current docker version of Permitify and upgrade it to run on OpenShift Dev and then once it is operational, upgrade Test. In doing that:

  1. Make sure that either Dev or Test is ALWAYS available, and notify the team as the primary demo site is changed.
  2. As appropriate, update the pre-loaded organization data to credential process to match the new credentials.
  3. As appropriate, update or redeploy the BCovrin instance(s) that back the Permitify demo.

This effort will be called "Permitify 1.5" to avoid confusion with the work that Nick is doing that we're calling "Permitify 2.0".

Permission denied for copying config.toml when running './manage start'

I attempted to follow the basic instructions in the readme, but got the following error in the docker-compose output logs after the ./manage start step:

bc_registries_1 | Copying template directory; /app/site_templates/bc_registries ...                                                                                                     
bc_registries_1 | cp: cannot create regular file './config.toml': Permission denied                                                                                                     
bc_registries_1 | cp: cannot create regular file './schemas.json': Permission denied                                                                                                    
bc_registries_1 | Starting server ...
bc_registries_1 | ERROR 2018-01-30 20:04:53,626 config 1 140171157370624 Could not find config.toml. Exiting.                                                                           

Recipe is not coming up - js error

We're getting a JS error on the demo page for the recipe. This is because of a fix done in TOB for paging that has broken permitify. @CyWolf knows what the error is and is fixing.

Uncaught (in promise) TypeError: issuers is not iterable
    at getIssuerByDid (demo.js:127)
    at demo.js:188

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.