bcgov / greenlight Goto Github PK
View Code? Open in Web Editor NEWA demonstration of the verifiable organization network showing a new restaurant gathering the permits necessary to open.
License: Apache License 2.0
A demonstration of the verifiable organization network showing a new restaurant gathering the permits necessary to open.
License: Apache License 2.0
The latest bcgovimages/von-image set (-9
series) use a single wallet for all roles if more than one is being used. Update deployment configurations to align with this new approach. One one, key, seed, and did are needed for the wallet credentials.
Refs:
Update Environments:
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.
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.
Migrate Jenkins pipeline scripts over to using the OpenShift Client Jenkins Plugin
Much, if not all, of the OpenShift Pipeline Plugin will not be supported against OpenShift API Servers later than v3.11.
Reference:
Right now, the default value for THE_ORG_BOOK_BASE_URL is https://django-devex-von-dev.pathfinder.gov.bc.ca/api/v1.
Is this proper / acceptable behavior for use by random people trying out your demo? Will that mess with your test environment?
If not, what is the process for setting it up locally?
Switch to an s2i base image and build process.
Environments to update:
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:
================================================================================
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?
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.
Link to TOB opens TOB but not on the expected credential. Andrew provided how to fix.
Once the Permitify test
environment has been migrated to the new BCovrin test
Ledger (http://138.197.138.255/), delete the old BCovrin test
Ledger (http://159.89.125.134/) and its associated proxies.
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...
Permitify currently shows the caddy "You are here!" page when you hit http://localhost:5000. Please update the caddy config to have that URL redirect to the start of the demo - same as http://localhost:5000/demo.
I'm working on making a new issuer based on the example services, and they include a configuration line like the following:
How does one authorize a seed on the ledger?
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:
real bc registries data from prod:
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.
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.
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.
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.
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.
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.
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.
Add additional dependency (e.g. Worksafe or another workshop participants) and rerun (build, start) in permitify to show the dynamic nature of permitify.
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.
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.
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.
Upgrade von-network, the-org-book, permitify to use von-agent 1.1.1
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.
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.
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":
Is there something else I'm supposed to do to get the wallet to work?
Stephen, just assigning you for visibility. Feel free to remove.
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 fielddata
")"))
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 fielddata
")")))
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 fielddata
")
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
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!
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.
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.
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...
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
The *.orgbook.gov.bc.ca
DNS records have been created. Update the domain names in the configurations.
Permitify/dflow:
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
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
When running the local permitify demo, TOB is working and we can add credentials and entities to TOB. However, once added, the counts are not updated and the autocomplete does not work. Solr related?
Please update the deployment(?) in docker so that works.
Looks like response format from the org book may have changed.
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
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.
New ledger address:
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:
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".
Move the generated test data from TOB into permitify and under the control of permitify.
As previously discussed, we need to rename the permitify
repositoryusing its new nomenclature
dflow`.
The tasks include:
devex-von-permitify-tools
still workWe'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:
Document the list and perhaps some ideas for tools we could use for the data entry of each.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.