-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Complete several of the utility documents for Jupyter #32
Changes from 1 commit
2deee49
f6e4ce8
36031e6
b8fafb6
07ed0f4
5387179
c80e594
f87a3e4
f6e2604
0c3d620
03501a6
089a458
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -13,64 +13,15 @@ | |
# --- | ||
|
||
# %% [markdown] | ||
# # Getting Started | ||
# # Managing the PDO Environment | ||
# | ||
# This document provides an overview for preparing to work with PDO contracts through the contract | ||
# docker container. It will walk through the necessary steps to set up a functional | ||
# configuration. It does assume that the reader is familiar with | ||
# This notebook provides an aggregate interface for preparing to work with PDO contracts through the | ||
# necessary steps to set up a functional configuration. It assumes that the reader is familiar with | ||
# [basic operation of Jupyter notebooks](https://jupytext.readthedocs.io/en/latest/). | ||
# | ||
# %% [markdown] | ||
# ## How Contracts Use Jupyter | ||
# | ||
# Many of the PDO contract families provide Jupyter notebooks to simplify interaction with contract | ||
# objects. Commonly, the notebooks provide a factory for instantiating a notebook for each new | ||
# contract from one of the contract specific templates. The templates provided generally include five | ||
# common sections: | ||
# | ||
# * Configure the Contract Object | ||
# * Initialize the Jupyter Interpreter and the PDO Environment | ||
# * Initialize the Contract Object Context | ||
# * Operate on the Contract | ||
# * View Contract Metadata | ||
# | ||
# *Configure the Contract Object*: Each notebook either loads an existing contract object from a | ||
# file (see the PDO documentation on contract collections) or creates a new contract object based on | ||
# an initial set of parameters. To create a new contract object, a factory will collect input that | ||
# is used to instantiate a template notebook with the set of required parameters. | ||
# | ||
# *Initialize the Jupyter Interpreter and PDO Environment*: To initialize the Jupyter interpreter, | ||
# the notebook loads the Juptyer helper module. This module imports all of the relevant PDO and | ||
# Jupyter IPython modules to simplify code in the notebook. It also defines several procedures that | ||
# are useful for initializing and interacting with the PDO environment. | ||
# | ||
# In addition, the Jupyter interpreter initialization configures an IPython extension that makes it | ||
# easier to provide code for multiple types of operations that can be performed on the contract | ||
# object. Specifically, the extension defines a magic keyword, `skip`, that takes a value or | ||
# expression that, if it evaluates to True, causes the code section to be skipped during notebook | ||
# execution. | ||
# | ||
# *Initialize the Contract Object Context*: The next section in the notebook creates a PDO context | ||
# for the contract object (see the PDO documentation for more information on contexts). The context | ||
# includes all information necessary to create the contract object (and its dependencies) based on | ||
# the initial set of parameters provided by the factory notebook. Beyond the initial parameters, the | ||
# context allows for fine-grained customization of the contract object, though the defaults are | ||
# usually sufficient. | ||
# | ||
# *Operate on the Contract*: The contract object may be used once it has been created and | ||
# initialized. In general, cells in this section of the notebook are turned off by default; that is, | ||
# `%%skip True` is added at the top of the cell. To perform an operation, change the top line to | ||
# `%%skip False` and evaluate the cell. | ||
# | ||
# *View Contract Metadata*: For the curious (and those debugging contract behavior), the final | ||
# section of most notebooks includes a section to examine the metadata associated with a contract. | ||
|
||
# %% [markdown] | ||
# ## Configure the PDO Environment | ||
# | ||
# The remainder of this notebook helps to setup and verify the PDO environment in which the | ||
# notebooks operate. If you have started the Jupyter Lab server through the docker test interface, a | ||
# basic environment has already been created that is sufficient for working with the notebooks. | ||
# This notebook helps to setup and verify the PDO environment in which the notebooks operate. If you | ||
# have started the Jupyter Lab server through the PDO contracts docker test interface, a basic | ||
# environment has already been created that is sufficient for working with the notebooks. | ||
# Otherwise, you may use the sections of this notebook to create or import signing keys for | ||
# transactions, configure PDO services (e.g. by importing a PDO `site.toml` file), and configure | ||
# service groups to simplify contract creation. | ||
|
@@ -101,18 +52,25 @@ | |
# Additional management of keys is provided by the [Key Manager Notebook](key_manager.ipynb). | ||
# | ||
# %% | ||
from pdo.contracts.keys import PrivateKeyListWidget, GenerateKeyWidget | ||
from pdo.contracts.keys import PrivateKeyListWidget | ||
from pdo.contracts.keys import PublicKeyListWidget | ||
from pdo.contracts.keys import GenerateKeyWidget | ||
from pdo.contracts.keys import UploadKeyWidget | ||
|
||
key_list = PrivateKeyListWidget(state, bindings) | ||
key_gen = GenerateKeyWidget(state, bindings) | ||
ip_display.display(ipywidgets.VBox([key_list, key_gen])) | ||
private_key_list = PrivateKeyListWidget(state, bindings) | ||
public_key_list = PublicKeyListWidget(state, bindings) | ||
key_generate = GenerateKeyWidget(state, bindings) | ||
key_import = UploadKeyWidget(state, bindings) | ||
|
||
children = [public_key_list, private_key_list, key_generate, key_import] | ||
titles = ['Public Key List', 'Private Key List', 'Generate Key Pair', 'Import Keys'] | ||
ip_display.display(ipywidgets.Tab(children=children, titles=titles)) | ||
# %% [markdown] | ||
# ## Import Site Information | ||
# | ||
# PDO clients require information about the services that will be used for contracts. Typically, a | ||
# service provider will create a site description file (often called `site.toml`) that can be used | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What are the assumptions about where PDO clients can obtain site.toml files to import? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. we have none per se. for the moment, my preference is to keep that "out of band". There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Alright, that's fine. I always like to make assumptions like these explicit (if they aren't already somewhere) to avoid any confusion. |
||
# to import information about a number of services. | ||
# to import information about services offered by a site. | ||
# | ||
# The widget below contains information about the currently created service groups and a form | ||
# for uploading a new site file. Additional management of service information is provided by the | ||
|
@@ -124,31 +82,40 @@ | |
from pdo.contracts.services import service_labels | ||
|
||
children = map(lambda stype : ServiceListWidget(state, bindings, stype), service_labels.keys()) | ||
service_list = ipywidgets.Tab(children=list(children), titles=list(service_labels.values())) | ||
titles = service_labels.values() | ||
service_list = ipywidgets.Tab(children=list(children), titles=list(titles)) | ||
ip_display.display(ipywidgets.VBox([service_list, ServiceUploadWidget(state, bindings)])) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. looks like you assume that by default there are services deployed on localhost? What if there all services are located on remote only? I see that there is an option to upload the site.toml file, but the option is presented only after a default setting on localhost is executed. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. where do you see localhost? there are no assumptions. yes, test_jupyter sets up a localhost site (that's where the services are located). but you can load any site file. i do this often for other "permanent" services. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ok, when I ran the notebook, my observation was the I get the option to upload the site.toml only after executing the cell; but while executing the cell that it also first showed the existence of a default localhost based group. My question was what happens if such a default localhost group does not exist. I have no way to test it now, until I deploy a more elaborate set up. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yes. we had already loaded that site.toml for the localhost test files. to be clear... if you run start_jupyter.sh you will not have any information pre-loaded. if you run the tests we intentionally load the local site.toml (which for the test configuration comes from the services running on localhost). so YES, the test environment pre-configures groups for localhost as expected. but that is not the case for a "running system". |
||
|
||
# %% [markdown] | ||
# ## Create Service Groups | ||
# ## Service Groups | ||
# | ||
# Service groups are a shortcut for configuration of collections of enclave, storage, and | ||
# provisioning services used to create and provision a PDO contract object. Each type of | ||
# service will have its own service groups. PDO requires that each type of service have a | ||
# service group named "default" that will be used when no groups have been specified. | ||
# | ||
# The widget below contains a list of service groups for each type of service and a widget for | ||
# creating new services of each type. If there is no default service group, please create one. | ||
# | ||
# Additional management of service group information is provided by the [Service Groups Manager | ||
# Notebook](service_groups_manager.ipynb) | ||
# %% | ||
from pdo.contracts.groups import ServiceGroupListWidget | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Given that there is special emphasis on the service db and serivce groups, would be better if "contract context specification" includes an option for the contract author to specify which service group to use to deploy the contract. The Issuer notebook only specifies the service host where the contract objects will be created; what seems more meaningful is to rather specify the service groups (even if it is default) where the contract will be deployed. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. that change is coming in the contracts. i have a PR ready to go that updates all of those in the exchange cf. to be clear... you will not specify a "host" but rather will specify a group. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. thanks, looking forward to that PR. |
||
from pdo.contracts.groups import EnclaveServiceGroupCreateWidget | ||
from pdo.contracts.groups import ProvisioningServiceGroupCreateWidget | ||
from pdo.contracts.groups import StorageServiceGroupCreateWidget | ||
|
||
# %% [markdown] | ||
# ### List Service Groups | ||
# | ||
# The widget below contains a list of service groups for each type of service. | ||
# %% | ||
children = map(lambda stype : ServiceGroupListWidget(state, bindings, stype), service_labels.keys()) | ||
ip_display.display(ipywidgets.Tab(children=list(children), titles=list(service_labels.values()))) | ||
titles = service_labels.values() | ||
ip_display.display(ipywidgets.Tab(children=list(children), titles=list(titles))) | ||
|
||
# %% [markdown] | ||
# ### Create Service Groups | ||
# | ||
# The widget below enables creation of new service groups of each type. If there is no default | ||
# service group, please create one. | ||
# %% | ||
children = [ | ||
EnclaveServiceGroupCreateWidget(state, bindings), | ||
ProvisioningServiceGroupCreateWidget(state, bindings), | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The first sentence is a little convoluted.