app_collectd: type: tosca.nodes.SoftwareComponent.Collectd requirements: - host: app_server - collectd_endpoint: logstash interfaces: tosca.interfaces.relationship.Configure: pre_configure_target: implementation: python/logstash/configure_collectd.py interfaces: tosca.interfaces.node.lifecycle.Standard: create: scripts/collectd/create.sh configure: implementation: python/collectd/config.py input: logstash_ip: { get_attribute: [logstash_server, ip_address] } start: scripts/collectd/start.sh
app_rsyslog: type: tosca.nodes.SoftwareComponent.Rsyslog requirements: - host: app_server - rsyslog_endpoint: logstash interfaces: tosca.interfaces.relationship.Configure: pre_configure_target: implementation: python/logstash/configure_rsyslog.py interfaces: tosca.interfaces.node.lifecycle.Standard: create: scripts/rsyslog/create.sh configure: implementation: scripts/rsyslog/config.sh input: logstash_ip: { get_attribute: [logstash_server, ip_address] } start: scripts/rsyslog/start.sh
app_server: type: tosca.nodes.Compute capabilities: host: properties: *host_capabilities os: properties: *os_capabilities
mongo_server: type: tosca.nodes.Compute capabilities: host: properties: *host_capabilities os: properties: *os_capabilities
elasticsearch_server: type: tosca.nodes.Compute capabilities: host: properties: *host_capabilities os: properties: *os_capabilities
logstash_server: type: tosca.nodes.Compute capabilities: host: properties: *host_capabilities os: properties: *os_capabilities
kibana_server: type: tosca.nodes.Compute capabilities: host: properties: *host_capabilities os: properties: *os_capabilities
outputs: nodejs_url: description: URL for the nodejs server. value: { get_attribute: [ app_server, private_address ] } mongodb_url: description: URL for the mongodb server. value: { get_attribute: [ mongo_server, private_address ] } elasticsearch_url: description: URL for the elasticsearch server. value: { get_attribute: [ elasticsearch_server, private_address ] } logstash_url: description: URL for the logstash server. value: { get_attribute: [ logstash_server, private_address ] } kibana_url: description: URL for the kibana server. value: { get_attribute: [ kibana_server, private_address ] } |
Where the referenced implementation scripts in the example above would have the following contents
This use case shows a minimal description of two Container nodes (only) providing their Docker Requirements allowing platform (orchestrator) to select/provide the underlying Docker implementation (Capability). Specifically, wordpress and mysql Docker images are referenced from Docker Hub.
This use case also demonstrates:
· Abstract description of Requirements (i.e., Container and Docker) allowing platform to dynamically select the appropriate runtime Capabilities that match.
· Use of external repository (Docker Hub) to reference image artifact.
|
tosca_definitions_version: tosca_simple_yaml_1_3
description: > TOSCA simple profile with wordpress, web server and mysql on the same server.
# Repositories to retrieve code artifacts from repositories: docker_hub: https://registry.hub.docker.com/
topology_template:
inputs: wp_host_port: type: integer description: The host port that maps to port 80 of the WordPress container. db_root_pwd: type: string description: Root password for MySQL.
node_templates: # The MYSQL container based on official MySQL image in Docker hub mysql_container: type: tosca.nodes.Container.Application.Docker capabilities: # This is a capability that would mimic the Docker –link feature database_link: tosca.capabilities.Docker.Link artifacts: my_image: file: mysql type: tosca.artifacts.Deployment.Image.Container.Docker repository: docker_hub interfaces: Standard: create: implementation: my_image inputs: db_root_password: { get_input: db_root_pwd }
# The WordPress container based on official WordPress image in Docker hub wordpress_container: type: tosca.nodes.Container.Application.Docker requirements: - database_link: mysql_container artifacts: my_image: file: wordpress type: tosca.artifacts.Deployment.Image.Container.Docker repository: docker_hub <metadata-link> : <topology_artifact_name> # defined outside and linked to from here interfaces: Standard: create: implementation: my_image inputs: host_port: { get_input: wp_host_port } |
This use case illustrates how multiple artifacts can be associated with a node for different lifecycle operations of a node (create, terminate, configure, etc.)
|
tosca_definitions_version: tosca_simple_yaml_1_3 description: Sample tosca archive to illustrate use of a node with multiple artifacts for different life cycle operations of the node
topology_template :
node_templates : dbServer: type: tosca.nodes.Compute properties: name: dbServer description: artifacts: - sw_image: type: tosca.artifacts.Deployment.SwImage file: http://<IP_ADDRESS>/images/ubuntu-14.04.qcow2 name: ubuntu-14.04 version: 14.04 checksum: e5c1e205f62f3
- configuration: type: tosca.artifacts.Implementation.Ansible file: implementation/configuration/Ansible/configure.yml version: 2.0
- terminate: type: tosca.artifacts.Implementation.scripts file: implementation/configuration/scripts/terminate.sh version: 6.2
|
This section is non-normative and describes the approach TOSCA Simple Profile plans to take for policy description with TOSCA Service Templates. In addition, it explores how existing TOSCA Policy Types and definitions might be applied in the future to express operational policy use cases.
TOSCA Policies are a type of requirement that govern use or access to resources which can be expressed independently from specific applications (or their resources) and whose fulfillment is not discretely expressed in the application’s topology (i.e., via TOSCA Capabilities).
TOSCA deems it not desirable for a declarative model to encourage external intervention for resolving policy issues (i.e., via imperative mechanisms external to the Cloud). Instead, the Cloud provider is deemed to be in the best position to detect when policy conditions are triggered, analyze the affected resources and enforce the policy against the allowable actions declared within the policy itself.
· Natural language rules are not realistic, too much to represent in our specification; however, regular expressions can be used that include simple operations and operands that include symbolic names for TOSCA metamodel entities, properties and attributes.
· Complex rules can actually be directed to an external policy engine (to check for violation) returns true|false then policy says what to do (trigger or action).
· Actions/Triggers could be:
· Autonomic/Platform corrects against user-supplied criteria
· External monitoring service could be utilized to monitor policy rules/conditions against metrics, the monitoring service could coordinate corrective actions with external services (perhaps Workflow engines that can analyze the application and interact with the TOSCA instance model).
Policies typically address two major areas of concern for customer workloads:
· Access Control – assures user and service access to controlled resources are governed by rules which determine general access permission (i.e., allow or deny) and conditional access dependent on other considerations (e.g., organization role, time of day, geographic location, etc.).
· Placement – assures affinity (or anti-affinity) of deployed applications and their resources; that is, what is allowed to be placed where within a Cloud provider’s infrastructure.
· Quality-of-Service (and continuity) - assures performance of software components (perhaps captured as quantifiable, measure components within an SLA) along with consideration for scaling and failover.
Although TOSCA Policy definitions could be used to express and convey access control policies, definitions of policies in this area are out of scope for this specification. At this time, TOSCA encourages organizations that already have standards that express policy for access control to provide their own guidance on how to use their standard with TOSCA.
There must be control mechanisms in place that can be part of these patterns that accept governance policies that allow control expressions of what is allowed when placing, scaling and managing the applications that are enforceable and verifiable in Cloud.
These policies need to consider the following:
· Regulated industries need applications to control placement (deployment) of applications to different countries or regions (i.e., different logical geographical boundaries).
In general, companies and individuals have security concerns along with general “loss of control” issues when considering deploying and hosting their highly valued application and data to the Cloud. They want to control placement perhaps to ensure their applications are only placed in datacenter they trust or assure that their applications and data are not placed on shared resources (i.e., not co-tenanted).
In addition, companies that are related to highly regulated industries where compliance with government, industry and corporate policies is paramount. In these cases, having the ability to control placement of applications is an especially significant consideration and a prerequisite for automated orchestration.
Companies realize that their day-to-day business must continue on through unforeseen disasters that might disable instances of the applications and data at or on specific data centers, networks or servers. They need to be able to convey placement policies for their software applications and data that mitigate risk of disaster by assuring these cloud assets are deployed strategically in different physical locations. Such policies need to consider placement across geographic locations as wide as countries, regions, datacenters, as well as granular placement on a network, server or device within the same physical datacenter. Cloud providers must be able to not only enforce these policies but provide robust and seamless failover such that a disaster’s impact is never perceived by the end user.
Quality-of-Service (apart from failover placement considerations) typically assures that software applications and data are available and performant to the end users. This is usually something that is measurable in terms of end-user responsiveness (or response time) and often qualified in SLAs established between the Cloud provider and customer. These QoS aspects can be taken from SLAs and legal agreements and further encoded as performance policies associated with the actual applications and data when they are deployed. It is assumed that Cloud provider is able to detect high utilization (or usage load) on these applications and data that deviate from these performance policies and is able to bring them back into compliance.
· Performance policies can be related to scalability policies. Scalability policies tell the Cloud provider exactly how to scale applications and data when they detect an application’s performance policy is (or about to be) violated (or triggered).
· Scalability policies in turn are related to placement policies which govern where the application and data can be scaled to.
· There are general “tenant” considerations that restrict what resources are available to applications and data based upon the contract a customer has with the Cloud provider. This includes other constraints imposed by legal agreements or SLAs that are not encoded programmatically or associated directly with actual application or data..
This section includes some initial operation policy use cases that we wish to describe using the TOSCA metamodel. More policy work will be done in future versions of the TOSCA Simple Profile in YAML specification.
This use case shows a failover policy to keep at least 3 copies running in separate containers. In this simple case, the specific containers to use (or name is not important; the Cloud provider must assure placement separation (anti-affinity) in three physically separate containers.
This use case introduces the following policy features:
· Simple separation on different “compute” nodes (up to discretion of provider).
· Simple separation by region (a logical container type) using an allowed list of region names relative to the provider.
o Also, shows that set of allowed “regions” (containers) can be greater than the number of containers requested.
Sample YAML: Compute separation
|
failover_policy_1: type: tosca.policy.placement.Antilocate description: My placement policy for Compute node separation properties: # 3 diff target containers container_type: Compute container_number: 3 |
· There may be availability (constraints) considerations especially if these policies are applied to “clusters”.
· There may be future considerations for controlling max # of instances per container.
This use case demonstrates the use of named “containers” which could represent the following:
· Datacenter regions
· Geographic regions (e.g., cities, municipalities, states, countries, etc.)
· Commercial regions (e.g., North America, Eastern Europe, Asia Pacific, etc.)
This use case introduces the following policy features:
· Separation of resources (i.e., TOSCA nodes) by logical regions, or zones.
|
failover_policy_2: type: tosca.policy.placement description: My failover policy with allowed target regions (logical containers) properties: container_type: region container_number: 3 # If “containers” keyname is provided, they represent the allowed set # of target containers to use for placement for . containers: [ region1, region2, region3, region4 ] |
Nodes that need to be co-located to achieve optimal performance based upon access to similar Infrastructure (IaaS) resource types (i.e., Compute, Network and/or Storage).
This use case demonstrates the co-location based upon Compute resource affinity; however, the same approach could be taken for Network as or Storage affinity as well. :
This use case introduces the following policy features:
· Node placement based upon Compute resource affinity.
· The concept of placement based upon IaaS resource utilization is not future-thinking, as Cloud should guarantee equivalent performance of application performance regardless of placement. That is, all network access between application nodes and underlying Compute or Storage should have equivalent performance (e.g., network bandwidth, network or storage access time, CPU speed, etc.).
|
keep_together_policy: type: tosca.policy.placement.Colocate description: Keep associated nodes (groups of nodes) based upon Compute properties: affinity: Compute |
Start with X nodes and scale up to Y nodes, capability to do this from a dashboard for example.
This use case introduces the following policy features:
· Basic autoscaling policy
|
my_scaling_policy_1: type: tosca.policy.scaling description: Simple node autoscaling properties: min_instances: <integer> max_instances: <integer> default_instances: <integer> increment: <integer> |
· Assume horizontal scaling for this use case
o Horizontal scaling, implies “stack-level” control using Compute nodes to define a “stack” (i.e., The Compute node’s entire HostedOn relationship dependency graph is considered part of its “stack”)
· Assume Compute node has a SoftwareComponent that represents a VM application.
· Availability Zones (and Regions if not same) need to be considered in further use cases.
· If metrics are introduced, there is a control-loop (that monitors). Autoscaling is a special concept that includes these considerations.
· Mixed placement and scaling use cases need to be considered:
o Example: Compute1 and Compute2 are 2 node templates. Compute1 has 10 instances, 5 in one region 5 in other region.
TOSCA’s declarative modelling includes features that allow service designers to model abstract components without having to specify concrete implementations for these components. Declarative modeling is made possible through the use of standardized TOSCA types. Any TOSCA-compliant orchestrator is expected to know how to deploy these standard types. Declarative modeling ensures optimal portability of service templates, since any cloud-specific or technology specific implementation logic is provided by the TOSCA orchestrator, not by the service template.
The examples in the previous chapter also demonstrate how TOSCA allows service designers to extend built-in orchestrator behavior in a number of ways:
- Service designers can override or extend behavior of built-in types by supplying service-specific implementations of lifecycle interface operations in their node templates.
- Service designers can create entirely new types that define custom implementations of standard lifecycle interfaces.
Implementations of Interface operations are provided through artifacts. The examples in the previous chapter showed shell script artifacts, but many other types of artifacts can be used as well. The use of artifacts in TOSCA service templates breaks pure declarative behavior since artifacts effectively contain “imperative logic” that is opaque to the orchestrator. This introduces the risk of non-portable templates. Since some artifacts may have dependencies on specific technologies or infrastructure component, the use of artifacts could result in service templates that cannot be used on all cloud infrastructures.
The goal of this non-normative chapter is to ensure portable and interoperable use of artifacts by providing a detailed description of how TOSCA orchestrators process artifacts, by illustrating how a number of standard TOSCA artifact types are expected to be processed, and by describing TOSCA language features that allow artifact to provide metadata containing artifact-specific processing instructions. These metadata around the artifact allow the orchestrator to make descisions on the correct Artifact Processor and runtime(s) needed to execute. The sole purpose of this chapter is to show TOSCA template designers how to best leverage built-in TOSCA capabilities. It is not intended to recommend specific orchestrator implementations.
This section is non-normative and outlines various options to distribute artifacts to artifact processors as a part of CSAR on-boarding.
CSAR On-boarding refers to the process of
- Creating a CSAR and its contents
- Submitting the CSAR to the Orchestrator to be included in the catalogue
- Uploading CSAR to Orchestrator
- Processing of CSAR by the Orchestrator
CSAR on-boarding is achieved through the following steps:
1. Request for uploading a CSAR is received by the Orchestrator
2. Orchestrator verifies integrity of package
3. Orchestrator re-directs request with CSAR to Catalogue
4. Catalogue receives CSAR and reads the Package content
5. Catalogue validates the CSAR
The orchestrator distributes artifacts to artifact processors from Catalogue
Artifacts can be distributed to artifact processors through the following mechanisms:
1. Synchronous on-boarding: During onboarding, Orchestrator forcefully pushes artifacts to artifacts processor and waits for success response, marks onboarding operation as successful only after a success response is received from artifact processor.
2. Asynchronous on-boarding: Orchestrator notifies artifact processors and lets artifact processors pull artifacts
3. Do not distribute artifacts during onboarding, let artifact processors pull them from CSAR catalogue when they are called to execute the artifact
Note: Disabling artifact validation during onboarding opens up possibilities of failures during deployment of CSAR in to the cloud
On-boarding eases deployment and reduces the first time instantiation of cloud applications. It helps validation and detection of errors early, prior to deployment.
Artifacts represent the content needed to realize a deployment or implement a specific management action.
Artifacts can be of many different types. Artifacts could be executables (such as scripts or executable program files) or pieces of data required by those executables (e.g. configuration files, software libraries, license keys, etc). Implementations for some operations may require the use of multiple artifacts.
Different types of artifacts may require different mechanisms for processing the artifact. However, the sequence of steps taken by an orchestrator to process an artifcat is generally the same for all types of artifacts:
The first step is to identify an appropriate processor for the specified artifact. A processor is any executable that knows how to process the artifact in order to achieve the intended management operation. This processor could be an interpreter for executable shell scripts or scripts written in Python. It could be a tool such as Ansible, Puppet, or Chef for playbook, manifest, or recipe artifacts, or it could be a container management or cloud management system for image artifacts such as container images or virtual machine images.
TOSCA includes a number of standard artifact types. Standard-compliant TOSCA orchestrators are expected to include processors for each of these types. For each type, there is a correspondent Artifact Processor that is responsible for processing artifacts of that type.
Note that aside from selecting the proper artifact processor, it may also be important to use the proper version of the processor. For example, some python scripts may require Python 2.7 whereas other scripts may require Python 3.4. TOSCA provides metadata to describe service template-specific parameters for the Artifact Processor. In addition to specifying specific versions, those metadata could also identify repositories from which to retrieve the artifact processor.
Some templates may require the use of custom Artifact Processors, for example to process non-standard artifacts or to provide a custom Artifact Processor for standard artifact types. For such cases, TOSCA allows service template designers to define Application Processors in service templates as a top-level entity. Alternatively, service template designers can also provide their own artifact processor by providing wrapper artifacts of a supported type. These wrapper artifacts could be shell scripts, python scripts, or artifacts of any other standard type that know how process or invoke the custom artifact.
The second step is to identify or create a proper execution environment within which to run the artifact processor. There are generally three options for where to run artifact processors :
1. One option is to execute the artifact processor in the topology that is being orchestrated, for example on a Compute node created by the orchestrator.
2. A second option is to process the artifact in the same environment in which the orchestrator is running (although for security reasons, orchestrators may create sandboxes that shield the orchestrator from faulty or malicious artifacts).
3. The third option is to process the script in a management environment that is external to both the orchestrator and the topology being orchestrated. This might be the preferred option for scenarios where the environment already exists, but it is also possible for orchestrators to create external execution environments.
It is often possible for the orchestrator to determine the intended execution environment based on the type of the artifact as well as on the topology context in which the the artifact was specified. For example, shell script artifacts associated with software components typically contain the install script that needs to be executed on the software component’s host node in order to install that software component. However, other scripts may not need to be run inside the topology being orchestrated. For example, a script that creates a database on a database management system could run on the compute node that hosts the database management system, or it could run in the orchestrator environment and communicate with the DBMS across a management network connection.
Similarly, there may be multiple options for other types of artifacts as well. For example, puppet artifacts could get processed locally by a puppet agent running on a compute node in the topology, or they could get passed to a puppet master that is external to both the orchestrator and the topology.
Different orchestrators could make different decisions about the execution environments for various combinations of node types and artifact types. However, service template designers must have the ability to specify explicitly where artifacts are intended to be processed in those scneario where correct operation depends on using a specific execution environment.
Need discussion on how this is done.
An artifact processor may need to run using a specific user account in the execution environment to ensure that the processor has the proper permissions to execute the required actions. Depending on the artifact, existing user accounts might get used, or the orchestrator might have to create a new user account specifically for the artifact processor. If new user accounts are needed, the orchestrator may also have to create a home directory for those users.
Depending on the security mechanisms used in the execution environment, it may also be necessary to add user accounts to specific groups, or to assign specific roles to the user account.
Once the orchestrator has identified the artifact processor as well as the execution environment, it must make sure that the artifact processor is deployed in the execution environment:
· If the orchestrator’s own environment acts as the execution environment for the artifact processor, orchestrator implementors can make sure that a standard set of artifact processors is pre-installed in that environment, and nothing further may need to be done.
· When a Compute node in the orchestrated topology is selected as the execution environment, typically only the most basic processors (such as bash shells) are pre-installed on that compute node. All other execution processors need to be installed on that compute node by the orchestrator.
· When an external execution environment is specified, the orchestrator must at the very least be able to verify that the proper artifact processor is present in the external execution environment and generate an error if it isn’t. Ideally, the orchestrator should be able to install the processor if necessary.
The orchestrator may also take the necessary steps to make sure the processor is run as a specific user in the execution environment.
The imperative logic contained in artifacts may in turn install or configure software components that are not part of the service topology, and as a result are opaque to the orchestrator. This means that the orchestrator cannot reflect these components in an instance model, which also means they cannot be managed by the orchestrator.
It is best practice to avoid this situation by explicitly modeling any dependent components that are required by an artifact processor. When deploying the artifact processor, the orchestrator can then deploy or configure these dependencies in the execution environment and reflect them in an instance model as appropriate.
For artifacts that require dependencies to to be installed, TOSCA provides a generic way in which to describe those dependencies, which will avoid the use of monolithic scripts.
Examples of dependent components include the following :
· Some executables may have dependencies on software libraries. For tools like Python, required libraries might be specified in a requirements.txt file and deployed into a virtual environment.
· Environment variables may need to be set.
· Configuration files may need to be created with proper settings for the artifact processor. For example, configuration settings could include DNS names (or IP addresses) for contacting a Puppet Master or Chef Server.
· Artifact processors may require valid software licenses in order to run.
· Other artifacts specified in the template may need to be deposited into the execution environment.
Orchestrators must pass information to the artifact processor that properly identifies the target for each artifact being processed.
· In many cases, the target is the Compute node that acts as the host for the node being created or configured. If that Compute node also acts as the execution environment for the artifact processor, the target for the artifacts being processed is the Compute node itself. If that scenario, there is no need for the orchestrator to pass additional target information aside from specifying that all actions are intended to be applied locally.
· When artifact processors run externally to the topology being deployed, they must establish a connection across a management network to the target. In TOSCA, such targets are identified using Endpoint capabilities that contain the necessary addressing information. This addressing information must be passed to the artifact processor
Note that in addition to endpoint information about the target, orchestrators may also need to pass information about the protocol that must be used to connect to the target. For example, some networking devices only accept CLI commands across a SSH connection, but others could also accept REST API calls. Different python scripts could be used to configure such devices: one that uses the CLI, and one that executes REST calls. The artifact must include metadata about which connection mechanism is intended to be used, and orchestrators must pass on this information to the artifact processor.
Finally, artifact processor may need proper credentials to connect to target endpoints. Orchestrators must pass those credentials to the artifact processor before the artifact can be processed.
Orchestrators must pass any required inputs to the artifact processor. Some processors could take inputs through environment variables, but others may prefer command line arguments. Named or positional command line arguments could be used. TOSCA must be very specific about the mechanism for passing input data to processors for each type of artifact.
Similarly, artifact processors must also pass results from operations back to orchestrators so that results values can be reflected as appropriate in node properties and attributes. If the operation fails, error codes may need to be returned as well. TOSCA must be very specific about the mechanism for returning results and error codes for each type of artifact.
After the artifact has been processed by the artifact processor, the orchestrator could perform optional cleanup:
· If an artifact processor was deployed within the topology that is being orchestrated, the orchestrator could decide to remove the artifact processor (and all its deployed dependencies) from the topology with the goal of not leaving behind any components that are not explicitly modeled in the service template.
· Alternatively, the orchestrator MAY be able to reflect the additional components/resources associated with the Artifact Processor as part of the instance model (post deployment).
Artifact Processors that do not use the service template topology as their execution environment do not impact the deployed topology. It is up to each orchestrator implementation to decide if these artifact processors need to be removed.
Detailed Artifacts may be generated on-the-fly as orchestration happens. May be propagated to other nodes in the topology. How do we describe those?
This section shows how orchestrators might execute the steps listed above for a few common artifact types, in particular:
1. Shell scripts
2. Python scripts
3. Package artifacts
4. VM images
5. Container images
6. API artifacts
7. Non-standard artifacts
By illustrating how different types of artifacts are intended to be processed, we identify the information needed by artifact processors to properly process the artifacts, and we will also identify the components in the topology from which this information is intended to be obtained.
Many artifacts are simple bash scripts that provide implementations for operations in a Node’s Lifecycle Interfaces. Bash scripts are typically intended to be executed on Compute nodes that host the node with which these scripts are associated.
We use the following example to illustrate the steps taken by TOSCA orchestrators to process shell script artifacts.
|
tosca_definitions_version: tosca_simple_yaml_1_3 description: Sample tosca archive to illustrate simple shell script usage. template_name: tosca-samples-shell template_version: 1.0.0-SNAPSHOT template_author: TOSCA TC
node_types: tosca.nodes.samples.LogIp: derived_from: tosca.nodes.SoftwareComponent description: Simple linux cross platform create script. attributes: log_attr: { get_operation_output: [SELF, Standard, create, LOG_OUT] } interfaces: Standard: create: inputs: SELF_IP: { get_attribute: [HOST, ip_address] } implementation: scripts/create.sh
topology_template: node_templates: log_ip: type: tosca.nodes.samples.LogIp requirements: - host: node: compute capability: tosca.capabilities.Container relationship: tosca.relationships.HostedOn # Any linux compute. compute: type: tosca.nodes.Compute capabilities: os: properties: type: linux |
This example uses the following script to install the LogIP software :
|
#!/bin/bash
# This is exported so available to fetch as output using the get_operation_output function export LOG_OUT="Create script : $SELF_IP"
# Just a simple example of create operation, of course software installation is better echo "$LOG_OUT" >> /tmp/tosca_create.log |
For this simple example, the artifact processing steps outlined above are as follows:
1. Identify Artifact Processor: The artifact processor for bash shell scripts is the “bash” program.
2. Establish Execution Environment: The typical execution environment for bash scripts is the Compute node respresenting the Host of the node containing the artifact.
3. Configure User Account: The bash user account is the default user account created when instantiating the Compute node. It is assumed that this account has been configured with sudo privileges.
4. Deploy Artifact Processor: TOSCA orchestrators can assume that bash is pre-installed on all Compute nodes they orchestrate, and nothing further needs to be done.
5. Deploy Dependencies: Orchestrators should copy all provided artifacts using a directory structure that mimics the directory structure in the original CSAR file containing the artifacts. Since no dependencies are specified in the example above, nothing further needs to be done.
6. Identify Target: The target for bash is the Compute node itself.
7. Pass Inputs and Retrieve Outputs: Inputs are passed to bash as environment variables. In the example above, there is a single input declared for the create operation called SELF_IP. Before processing the script, the Orchestrator creates a corresponding environment variable in the execution environment. Similarly, the script creates a single output that is passed back to the orchestrator as an environment variable. This environment variable can be accessed elsewhere in the service template using the get_operation_output function.
The following examples show a number of potential use case variations (not exhaustive) :
For example, a Bash script called “create.sh” that is used to install some software for a TOSCA Node; that this introduces imperative logic points (all scripts perhaps) which MAY lead to the creation of “opaque software” or topologies within the node
· Initial examples used would be independent of the specific flavor of Linux.
· The “create” operation, as part of the normative Standard node lifecycle, has special meaning in TOSCA in relation to a corresponding deployment artifact; that is, the node is not longer “abstract” if it either has an impl. Artifact on the create operation or a deployment artifact (provided on the node).
“create.sh” prepares/configures environment/host/container for other software (see below for VM image use case variants).
1. “create.sh” followed by a “configure.sh” (or “stop.sh”, “start.sh” or a similar variant).
2. in Compute node (i.e., within a widely-used, normative, abstract Node Type).
3. In non-compute node like WebServer (is this the hello world)?
· Container vs. Containee “hello worlds”; create is “special”; speaks to where (target) the script is run at! i.e., Compute node does not have a host.
· What is BEST PRACTICE for compute? Should “create.sh” even be allowed?
· Luc: customer wanted to use an non-AWS cloud, used shell scripts to cloud API.
i. Should have specific Node type subclass for Compute for that other Cloud (OR) a capability that represents that specific target Cloud.
For example, a Postgres user
For example, using example from the meeting where script depends on AWS CLI being installed.
· How do you decide whether to install an RPM or python package for the AWS dependency?
· How do we decide whether to install python packages in virtualenv vs. system-wide?
For example. run apt-get vs. yum
· The same operation can be implemented by different artifacts depending on the flavor of Linux on which the script needs to be run. We need the ability to specify which artifacts to use based on the target.
· How do we extend the “operation” grammar to allow for the selection of one specific artifact out of a number of options?
· How do we annotate the artifacts to indicate that they require a specific flavor and/or version of Linux?
· A variant would be to use different subclasses of abstract nodes, one for each flavor of Linux on which the node is supposed to be deployed. This would eliminate the need for different artifacts in the same node. Of course, this significantly reduces the amount of “abstraction” in service templates.
· Environment variables that may not correspond to input parameters
· For example, OpenStack-specific environment variables
· How do we specify that these environment variables need to be set?
For example, containing AWS credentials
· This configuration file may need to be created dynamically (rather than statically inside a CSAR file). How do we specify that these files may need to be created?
· Or does this require template files (e.g. Jinja2)?
A second important class of artifacts are Python scripts. Unlike Bash script artifacts, Python scripts are more commonly executed within the context of the Orchestrator, but service template designers must also be able to provide Python scripts artifacts that are intended to be executed within the topology being orchestrated,
Need a simple example of a Python script executed in the Orchestrator context.
Need a simple example of a Python script executed in the topology being orchestrated.
The following grammar is provided to allow service providers to specify the execution environment within which the artifact is intended to be processed:
Need to decide on grammar. Likely an additional keyword to the “operation” section of lifecycle interface definitions.
Some python scripts conform to Python version 2, whereas others may require version 3. Artifact designers use the following grammar to specify the required version of Python:
TODO
· Need to decide on grammar. Is artifact processor version associated with the processor, with the artifact, the artifact type, or the operation implementation?
Most Python scripts rely on external packages that must be installed in the execution environment. Typically, python packages are installed using the ‘pip’ command. To provide isolation between different environments, it is considered best practice to create virtual environments. A virtual environment is a tool to keep the dependencies required by different python scripts or projects in separate places, by creating virtual Python environments for each of them.
The following example shows a Python script that has dependencies on a number of external packages:
TODO
· Python scripts often have dependencies on a number of external packages (that are referenced by some package artifact). How would these be handled?
· How do we account for the fact that most python packages are available as Linux packages as well as pip packages?
· Does the template designer need to specify the use of virtual environments, or is this up to the orchestrator implementation? Must names be provided for virtual environments?
· Typically, dependent artifacts must be processed in a specific order. TOSCA grammar must provide a way to define orders and groups (perhaps by extending groups grammar by allowing indented sub-lists).
Most software components are distributed as software packages that include an archive of files and information about the software, such as its name, the specific version and a description. These packages are processed by a package management system (PMS), such as rpm or YUM, that automates the software installation process.
Linux packages are maintained in Software Repositories, databases of available application installation packages and upgrade packages for a number of Linux distributions. Linux installations come pre-configured with a default Repository from which additional software components can be installed.
While it is possible to install software packages using Bash script artifacts that invoke the appropriate package installation commands (e.g. using apt or yum), TOSCA provides improved portability by allowing template designers to specify software package artifacts and leaving it up to the orchestrator to invoke the appropriate package management system.
The following example shows a software component with an RPM package artifact.
Need a simple example
The following example shows a software component with Debian package artifact.
Need a simple example
· In this scenario, the host on which the software component is deployed must support RPM packages. This must be reflected in the software component’s host requirement for a target container.
· In this scenario, the host on which the software component is deployed must support Debian packages. This must be reflected in the software component’s host requirement for a target container.
Some template designers may want to specify a generic application software topology that can be deployed on a variety of Linux distributions. Such templates may include software components that include multiple package artifacts, one for each of the supported types of container platforms. It is up to the orchestrator to pick the appropriate package depending on the type of container chosed at deployment time.
Supporting this use case requires the following:
· Allow multiple artifacts to be expressed for a given lifecycle operation.
· Associate the required target platform for which each of those artifacts was meant.
How do we specify multiple artifacts for the same operation?
How do we specify which platforms are support for each artifact? In the artifact itself? In the artifact type?
· VM Images is a popular opaque deployment artifact that may deploy an entire topology that is not declared itself within the service template.
· The “create” operation, as part of the normative Standard node lifecycle, has special meaning in TOSCA in relation to a corresponding deployment artifact; that is, the node is no longer “abstract” if it either has an impl. Artifact on the create operation or a deployment artifact (provided on the node).
· In the future, the image itself could contain TOSCA topological information either in its metadata or externally as an associated file.
o Can these embedded or external descriptions be brought into the TOSCA Service Template or be reflected in an instance model for management purposes?
· Consider create.sh in conjunction with a VM image deployment artifact
o VM image only (see below)
o Create.sh and VM image, both. (Need to address argument that they belong in different nodes).
o Configure.sh with a VM image.? (see below)
o Create.sh only (no VM image)
· Implementation Artifact (on TOSCA Operations):
o Operations that have an artifact (implementation).
· Deployment Artifacts:
o Today: it must appear in the node under “artifacts” key (grammar)
o In the Future, should it:
§ Appear directly in “create” operation, distinguish by “type” (which indicates processor)?
§ <or> by artifact name (by reference) to artifact declared in service template.
§ What happens if on create and in node (same artifact=ok? Different=what happens? Error?)
§ What is best practice? And why? Which way is clearer (to user?)?
§ Processing order (use case variant) if config file and VM image appear on same node?
In the case of onboarding of images, the cloud management platform plays the role of artifact processor. Different cloud management platforms have different image characteristics.
For example :.
· Openstack (Glance) - disk_format, container_format, min_disk, min_ram etc.
· Vmware - vmware_disktype, vmware_ostype etc.
· OpenshiftContainer - name, namespace, selfLink, resourceVersion etc.
These are described as artifact properties. They are not processed by the Orchestrator, but passed on to the cloud management platform for further processing.
Some implementations may need to be implemented by invoking an API on a remote endpoint. While such implementations could be provided by shell or python scripts that invoke API client software or use language-specific bindings for the API, it might be preferred to use generic API artifacts that leave decisions about the tools and/or language bindings to invoke the API to the orchestrator.
To support generic API artifacts, the following is required:
· A format in which to express the target endpoint and the required parameters for the API call
· A mechanism for binding input parameters in the operation to the appropriate parameters in the API call.
· A mechanism for specifying the results and/or errors that will be returned by the API call
Moreover, some operations may need to be implemented by making more than one API call. Flexible API support requires a mechanism for expressing the control logic that runs those API calls.
It should be possible to use a generic interface to describe these various API attributes without being forced into using specific software packages or API tooling. Of course, in order to “invoke” the API an orchestrator must launch an API client (e.g. a python script, a Java program, etc.) that uses the appropriate API language bindings. However, using generic API Artifact types, the decision about which API clients and language bindings to use can be left to the orchestrator. It is up to the API Artifact Processor provided by the Orchestrator to create an execution environment within which to deploy API language bindings and associated API clients based on Orchestrator preferences. The API Artifact Processor then uses these API clients to “process” the API artifact.
· REST
· SOAP
· OpenAPI
· IoT
· Serverless
TODO
To unambiguously describe how artifacts need to be processed, TOSCA provides:
1. Artifact types that define standard ways to process artifacts.
2. Keywords such as checksum, version etc. that enable identification of suitable artifact processor and transfer of artifact to artifact processor.
3. Artifact Properties that enable the artifact processor to process the artifact
4. Descriptive metadata that provide additional information needed to properly process the artifact.
The implementations subject to conformance are those introduced in Section 11.3 “Implementations”. They are listed here for convenience:
· TOSCA YAML service template
· TOSCA processor
· TOSCA orchestrator (also called orchestration engine)
· TOSCA generator
· TOSCA archive
A document conforms to this specification as TOSCA YAML service template if it satisfies all the statements below:
(a) It is valid according to the grammar, rules and requirements defined in section 3 “TOSCA Simple Profile definitions in YAML”.
(b) When using functions defined in section 4 “TOSCA functions”, it is valid according to the grammar specified for these functions.
(c) When using or referring to data types, artifact types, capability types, interface types, node types, relationship types, group types, policy types defined in section 5 “TOSCA normative type definitions”, it is valid according to the definitions given in section 5.
A processor or program conforms to this specification as TOSCA processor if it satisfies all the statements below:
(a) It can parse and recognize the elements of any conforming TOSCA YAML service template, and generates errors for those documents that fail to conform as TOSCA YAML service template while clearly intending to.
(b) It implements the requirements and semantics associated with the definitions and grammar in section 3 “TOSCA Simple Profile definitions in YAML”, including those listed in the “additional requirements” subsections.
(c) It resolves the imports, either explicit or implicit, as described in section 3 “TOSCA Simple Profile definitions in YAML”.
(d) It generates errors as required in error cases described in sections 3.1 (TOSCA Namespace URI and alias), 3.2 (Parameter and property type) and 3.6 (Type-specific definitions).
(e) It normalizes string values as described in section <IP_ADDRESS> (Additional Requirements)
A processor or program conforms to this specification as TOSCA orchestrator if it satisfies all the statements below:
(a) It is conforming as a TOSCA Processor as defined in conformance clause 2: TOSCA Processor.
(b) It can process all types of artifact described in section 5.3 “Artifact types” according to the rules and grammars in this section.
(c) It can process TOSCA archives as intended in section 6 “TOSCA Cloud Service Archive (CSAR) format” and other related normative sections.
(d) It can understand and process the functions defined in section 4 “TOSCA functions” according to their rules and semantics.
(e) It can understand and process the normative type definitions according to their semantics and requirements as described in section 5 “TOSCA normative type definitions”.
(f) It can understand and process the networking types and semantics defined in section 7 “TOSCA Networking”.
(g) It generates errors as required in error cases described in sections 2.10 (Using node template substitution for chaining subsystems), 5.4 (Capabilities Types) and 5.7 (Interface Types).).
A processor or program conforms to this specification as TOSCA generator if it satisfies at least one of the statements below:
(a) When requested to generate a TOSCA service template, it always produces a conforming TOSCA service template, as defined in Clause 1: TOSCA YAML service template,
(b) When requested to generate a TOSCA archive, it always produces a conforming TOSCA archive, as defined in Clause 5: TOSCA archive.
A package artifact conforms to this specification as TOSCA archive if it satisfies all the statements below:
(a) It is valid according to the structure and rules defined in section 6 “TOSCA Cloud Service Archive (CSAR) format”.
The following items will need to be reflected in the TOSCA (XML) specification to allow for isomorphic mapping between the XML and YAML service templates.
· The “TOSCA Simple ‘Hello World’” example introduces this concept in Section 2. Specifically, a VM image assumed to accessible by the cloud provider.
· Introduce template Input and Output parameters
· The “Template with input and output parameter” example introduces concept in Section 2.1.1.
· “Inputs” could be mapped to BoundaryDefinitions in TOSCA v1.0. Maybe needs some usability enhancement and better description.
· “outputs” are a new feature.
· Grouping of Node Templates
· This was part of original TOSCA proposal, but removed early on from v1.0 This allows grouping of node templates that have some type of logically managed together as a group (perhaps to apply a scaling or placement policy).
· Lifecycle Operation definition independent/separate from Node Types or Relationship types (allows reuse). For now, we added definitions for “node.lifecycle” and “relationship.lifecycle”.
· Override of Interfaces (operations) in the Node Template.
· Service Template Naming/Versioning
· Should include TOSCA spec. (or profile) version number (as part of namespace)
· Allow the referencing artifacts using a URL (e.g., as a property value).
· Repository definitions in Service Template.
· Substitution mappings for Topology template.
· Addition of Group Type, Policy Type, Group def., Policy def. along with normative TOSCA base types for policies and groups.
· Addition of Artifact Processors (AP) as first class citizens
· Types / Property / Parameters
o list, map, range, scalar-unit types
o Includes YAML intrinsic types
o NetworkInfo, PortInfo, PortDef, PortSpec, Credential
o TOSCA Version based on Maven
o JSON and XML types (with schema constraints)
· Constraints
o constraint clauses, regex
o External schema support
· Node
o Root, Compute, ObjectStorage, BlockStorage, Network, Port, SoftwareComponent, WebServer, WebApplicaton, DBMS, Database, Container, and others
· Relationship
o Root, DependsOn, HostedOn, ConnectsTo, AttachesTo, RoutesTo, BindsTo, LinksTo and others
· Artifact
o Deployment: Image Types (e.g., VM, Container), ZIP, TAR, etc.
o Implementation : File, Bash, Python, etc.
· Artifact Processors
o New in v1.2 as “first class” citizen
· Requirements
o None
· Capabilities
o Container, Endpoint, Attachment, Scalable, …
· Lifecycle
o Standard (for Node Types)
o Configure (for Relationship Types)
· Functions
o get_input, get_attribute, get_property, get_nodes_of_type, get_operation_output and others
o concat, token
o get_artifact
o from (file)
· Groups
o Root
· Policies
o Root, Placement, Scaling, Update, Performance
· Workflow
o Complete declarative task-based workflow grammar.
· Service Templates
o Advanced “import” concepts
o Repository definitions
· CSAR
o Allow multiple top-level Service Templates in same CSAR (with equivalent functionality)
The following individuals have participated in the creation of this specification and are gratefully acknowledged:
Contributors:
Alex Vul (alex.vul@intel.com), Intel
Anatoly Katzman (anatoly.katzman@att.com), AT&T
Arturo Martin De Nicolas (arturo.martin-de-nicolas@ericsson.com), Ericsson
Avi Vachnis (avi.vachnis@alcatel-lucent.com), Alcatel-Lucent
Calin Curescu (calin.curescu@ericsson.com), Ericsson
Chris Lauwers<EMAIL_ADDRESS>Claude Noshpitz (claude.noshpitz@att.com), AT&T
Derek Palma (dpalma@vnomic.com), Vnomic
Dmytro Gassanov (dmytro.gassanov@netcracker.com), NetCracker
Frank Leymann (Frank.Leymann@informatik.uni-stuttgart.de), Univ. of Stuttgart
Gábor Marton (gabor.marton@nokia.com), Nokia
Gerd Breiter (gbreiter@de.ibm.com), IBM
Hemal Surti (hsurti@cisco.com), Cisco
Ifat Afek (ifat.afek@alcatel-lucent.com), Alcatel-Lucent
Idan Moyal, (idan@gigaspaces.com), Gigaspaces
Jacques Durand (jdurand@us.fujitsu.com), Fujitsu
Jin Qin, (chin.qinjin@huawei.com), Huawei
Jeremy Hess<EMAIL_ADDRESS>, Gigaspaces
John Crandall, (mailto:jcrandal@brocade.com), Brocade
Juergen Meynert (juergen.meynert@ts.fujitsu.com), Fujitsu
Kapil Thangavelu (kapil.thangavelu@canonical.com), Canonical
Karsten Beins (karsten.beins@ts.fujitsu.com), Fujitsu
Kevin Wilson (kevin.l.wilson@hp.com), HP
Krishna Raman (kraman@redhat.com), Red Hat
Luc Boutier (luc.boutier@fastconnect.fr), FastConnect
Luca Gioppo, (luca.gioppo@csi.it), CSI-Piemonte
Matej Artač, (matej.artac@xlab.si), XLAB
Matt Rutkowski (mrutkows@us.ibm.com), IBM
Moshe Elisha (moshe.elisha@alcatel-lucent.com), Alcatel-Lucent
Nate Finch (nate.finch@canonical.com), Canonical
Nikunj Nemani (nnemani@vmware.com), Wmware
Priya TG<EMAIL_ADDRESS>NetCracker
Richard Probst (richard.probst@sap.com), SAP AG
Sahdev Zala (spzala@us.ibm.com), IBM
Shitao li (lishitao@huawei.com), Huawei
Simeon Monov (sdmonov@us.ibm.com), IBM
Sivan Barzily, (sivan@gigaspaces.com), Gigaspaces
Sridhar Ramaswamy (sramasw@brocade.com), Brocade
Stephane Maes (stephane.maes@hp.com), HP
Steve Baillargeon (steve.baillargeon@ericsson.com), Ericsson
Thinh Nguyenphu (thinh.nguyenphu@nokia.com), Nokia
Thomas Spatzier (thomas.spatzier@de.ibm.com), IBM
Ton Ngo (ton@us.ibm.com), IBM
Travis Tripp (travis.tripp@hp.com), HP
Vahid Hashemian (vahidhashemian@us.ibm.com), IBM
Wayne Witzel (wayne.witzel@canonical.com), Canonical
Yaron Parasol (yaronpa@gigaspaces.com), Gigaspaces
|
Revision |
Date |
Editor |
Changes Made |
|
WDO1, Rev01 |
2018-02-06 |
Matt Rutkowski |
· Initial WD02, Revision 01 baseline for TOSCA Simple Profile in YAML v1.3 |
|
WDO1, Rev02 |
2018-02-27 |
Matt Rutkowski |
· Updated Rev. history to WD01, v1.3 · Upated all namespaces to 1.3 (to match version). · Updated TC Chairs and Editors. · Section 6.2.1- Entry Defintions - Added support for multiple (equivalent) Entry Defintions as unordered list (declarative) of Service Templates. · Added sections 6.2.2 Notes and 6.2.3 Use Cases to better inform reader about multiple Entry Definitions usages and processing for/by Orchestrators. · Section 3.8.5 – Added artifact definitions to Group definition o Note: we still have to discuss adding Artifact (Types/Defns._ to Group Type and this may affect Node Type schema and processing. |
|
WD01, Rev03 |
2018-03-29 |
Calin Curescu Dmytro Gassanov, Priya T G, Chris Lauwers |
· Updated definition of get_input to allow structure parsing and dereference into the names of these nested structures when needed similar to what get_propery and get_attribute can do. See sections <IP_ADDRESS> and <IP_ADDRESS> · Section 3.7.4: Deprecate the properties keyname in artifact type definitions · Section <IP_ADDRESS>: Fix the “imports” example to be consistent with the grammar. · Section <IP_ADDRESS>: Remove obsolete prose discussing the use of a “selectable” directive. · Section 2.10.2; Remove obsolete prose discussing the use of a “substitutable” directive |
|
WD01 Rev03a |
2018-04-02 |
Chris Lauwers |
· Minor fix to get_input grammar · Section <IP_ADDRESS>: scalar-unit.bitrate |
|
WD01 Rev04 |
2018-06-05 |
Chris Lauwers |
· Section <IP_ADDRESS>: cleanup to prose that introduces the various scalar unit types · Section <IP_ADDRESS>: remove filter_name from node_filter grammar · Section 2.15: operation output examples · Section 3.6.14: attribute mappings · Sections 3.6.16 and 3.6.17: add output definitions to operation and interface definitions. |
|
WD01 Rev05 |
2018-07-30 |
Chris Lauwers |
· Section 3.3.5: add key_schema keyword for property, attribute, and parameter definitions of type map. · Section 3.9: add new schema_definition section that defines reusable schema definition grammar. Schema definitions support recursion to support lists of lists, maps of maps, maps of lists, and lists of maps. · Section 3.6.10: use new schema_definition grammar in property definitions · Section 3.6.12: use new schema_definition grammar in attribute definitions · Section 3.6.14: use new schema definition grammar in parameter definitions · Section 3.7.6: allow entry_schema and key_schema definitions for data type definitions that derive from TOSCA set types such as list or map. |
|
WD01 Rev06 |
2018-08-23 |
Calin Curescu |
· The word “list” was used to describe what are actually YAML maps throughout the document, e.g. the map of property definitions was described as list of property definitions. This created confusion with the real lists and the usage of TOSCA list datatype. Thus I replaced “list” with “map” where the list actually referred to a TOSCA map in sections: 3.6.17, 3.6.18, 3.7.2, <IP_ADDRESS>.1, 3.7.4, 3.7.5, 3.7.6, 3.7.7, 3.7.9, 3.7.10, 3.7.11, 3.7.12, 3.8.1, 3.8.2, 3.8.3, 3.8.4, 3.8.5, 3.8.6, 3.8.7, 3.8.9, 3.8.12, 3.9, 3.10, <IP_ADDRESS>, <IP_ADDRESS> · The word sequenced list was used to describe a YAML list. As we changed the improper use of list to map, we don’t need the “sequenced” list qualification, as all lists in YAML are sequenced. So I removed the word “sequenced” when used before a list in sections: 3.6.5, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, 3.7.6, 3.7.9, 3.8.3, 3.9.2, 3.10 · Changed “array of 2 strings” to “list of strings (w. 2 members)” in sections: <IP_ADDRESS>, <IP_ADDRESS>. · Changed the title of section <IP_ADDRESS>.2 from “Bulleted (sequenced) list notation” to “Bulleted list notation” as all YAML lists are sequenced list and the bulleted list notations is semantically not different from the bracket notation. · Corrected the improper use of a bulleted list usage when defining capabilities in example 22, in section 2.13 “Using YAML macros to simplify templates”. |
|
WD01 Rev07 |
2018-11-05 |
Chris Lauwers |
· Accept all changes in the document and publish the “clean” version as a new baseline. No other changes as compared to Rev06. |
|
WD01 Rev08 |
2018-11-12 |
Chris Lauwers |
· Incorporate Priya’s Artifact Properties contribution o Reintroduce artifact property definitions in artifact type definitions (these were previously depreceted in Rev03) Section 3.7.4 o Introduct artifact property assignments in artifact definitions—Section 3.6.7 o Added an application modeling use case that shows an example with multiple artifact definitions in a node template—Section 11.1.9 o Expand on the use artifact properties for VM Images—Section 13.3.5 · Various edits to fix typos and grammatical errors—Sections 1 and 2 |
|
WD01 Rev09 |
2018-11-15 |
Chris Lauwers |
· Correct PortInfo assignment example in Section <IP_ADDRESS> (courtesy of Steve B.) · Remove get_operation_output examples (Section 2.14.3 and 2.14.4) in anticipation of get_operation_output getting deprecated. · Add introductory section on notifications based on Calin’s proposal (Section 2.16) · Add notification definition and notification implementation definition grammar (Section 3.16.19 and 3.16.18) · Add notification definitions to interface definition grammar (Section 3.6.20) |
|
WD01 Rev10 |
2018-11-26 |
Matej Artač |
· Cleanup examples in Chapter 2 to improve readability |
|
WD01 Rev11 |
2018-11-27 |
Thinh Nguyenphu Gabor Marton |
· Support for external workflow languages (Section 3.8.7) · Add external workflow example (Section 7.3.8) |
|
WD01 Rev12 |
2018-12.10 |
Calin Curescu Thinh Nguyenphu Anatoly Katzman
|
· Minor editorial corrections to notification definitions (Section 2.16 and Section 3.6.19) · Various editorial changes to improve correctness and consistency · Introduce not operator in condition clause definitions (Section 3.6.25) |
|
WD01 Rev13 |
2018-12-17 |
Priya TG Chris Lauwers |
· Minor corrections to the artifact definition section (Section 3.6.7) · Deprecate “assert” keyname in condition clauses (Section 3.6.25) and update the examples accordingly. |
|
WD01 Rev14 |
2018-12-22 |
Calin Curescu |
· To eliminate confusion around events and event_types in condition-event-action policy triggers we have changed the keyname “event_type” to “event” in the trigger definition. They serve the same purpose. The usage of “event_type” is deprecated. (Section 3.6.22 Trigger definition). · We have consolidated the use of activities (as defined in the workflow step) and action (as defined in the policy trigger). We have unified them so that the “action” defined in the policy trigger refers to a list of activity definitions instead of only one. (Section 3.6.23 Activity definitions and Section 3.6.22 Trigger definition). · To allow conditions in policies to effect operations and workflow calls, and thus ensure a meaningful use of event-condition-actions policies we have defined the possibility to specify input values when calling operations or inlining workflows from within the activity definition. Moreover specifying input values is also needed when inlining external workflows, since they have no access to template node attributes. Syntactically this is consolidated in a short and long form of the activity definition, where the short form does not specify input values and is fully backward compatible and the long form allows the specification of input values. (Section 3.6.23 Activity definitions). |
|
WD01 Rev 15 |
2019-01-22 |
Chris Lauwers Arturo Martin De Nicolas Calin Curescu Matej Artač
|
· Minor corrections to condition clause examples (Section 3.6.25) · Fix single line map grammar (Section <IP_ADDRESS>.1) · Remove reference to ‘selectable’ directive in node filter definition in node template · Add missing section number to artifact_types definitions section (become Section <IP_ADDRESS>. All sections below <IP_ADDRESS> have their section number incremented) · Added the keyname Other-Definitions to the TOSCA.meta file in the CSAR. Its value should point to a list of yaml files that define substitution templates that may be used for nodes defined in the main service template (Section 6. TOSCA Cloud Service Archive (CSAR) format). · Fix broken bookmarks (Section 3.6.19 and 3.6.20) |
|
WD01 Rev 16 |
2019-02-03 |
Chris Lauwers |
· Consistently use tosca_simple_yaml_1_3 · Clarify definitions of abstract and no-op nodes (Section 1.8) · (Re)-introduce the ‘substitute’ directive to indicate node templates as abstract (Sections 2.10 and 2.11). · Introduce substitution_filter example (new Section 2.12. all sections below 2.12 have their section number incremented by 1) · Add substitution_filter keyname to the substitution_mappings grammar (Section 3.8.13) · Add attribute_mapping section (new Section 3.8.9. All subsequent subsections have their section number incremented) · Remove property-to-constant-value and property-to-property options from property_mapping syntax. Only property-to-input mappings are allowed (Section 3.8.8). · Document the substitute directive (Section 3.4.3) |
|
WD01 Rev 17 |
2019-02-06 |
Chris Lauwers Calin Curescu Priya TG |
· Eliminate inconsistencies between ‘occurrences’ syntax in Capability Definitions, Capability Assignments, Requirement Definitions, and Requirement Assignments (Sections 3.7.2, 3.7.3, 3.8.1, and 3.8.2) · Explicitly specifying the possibility to add custom keynames in the TOSCA.meta file for extended use of the TOSCA.meta beyond the scope of this TOSCA specification (Section 6.2.1 Custom keynames in the TOSCA.meta file) · Note about deprecation (Section 1.5.1) · Add normative and non-normative template artifact types (Sections 5.4.5, 9.1.4, and 9.1.5) · Introduce discussion about CSAR onboarding in the Artifacts Processing chapter (Section 13.1) · Experimental support for creating multiple node instances from the same node template (Section 2.20) · Single-line grammar for parameter definitions (Section <IP_ADDRESS>) · Property definition refinement grammar (Sections <IP_ADDRESS> and <IP_ADDRESS>) |
|
WD01 Rev 18 |
2019-02-12 |
Chris Lauwers |
· Use “select” directive in abstract node template example that uses node_filter (Section 2.9.2) · Document “select” directive in node template grammar (Section 3.4.3) · Deprecate interface definitions, requirement definitions, and capability definitions in group types (Section 3.7.11) · Deprecated interface definitions in group definitions (Section 3.8.5) |
|
WE01 Rev 19 |
2019-02-19 |
Chris Lauwers |
· Initial CSD candidate. · Identical to Rev 18 but with all changes accepted. |
|
WD01 Rev 20 |
2019-03-28 |
Chris Lauwers |
· Remove Chapter 14 · Remove Section 7.4 |
|
WD01 Rev 22 |
2019-04-25 |
Calin Curescu |
· Definition of range has been changed so that upper bound can be “greater than or equal to” lower bound (and not just not strictly “greater than”). This solves inconsistencies where such a range is needed (e.g. occurrences: [1,1] ) (Section 3.3.3) · Added the changes we introduced to “interface definition” (i.e. operations, notifications) also to “interface type definitions” (Section 3.7.5) · Reformulated the “activity definitions” for better readability (Section 3.6.23) |
|
WD01 Rev 23 |
2019-08-12 |
Chris Lauwers |
· Incorporate minor editorial fixes. |


Sorry, Google Calendar API v2 was closed at 2014/11/17. This extension dose not work. No idea to support API v3 that have api call limits...


[1]
Interchangeable lenses; Somewhat hefty
[2]
lenses, 16/9, audio . . .; no step by step white balance


|
WebWork 2 : How do I populate a form bean and get the value using the taglib
This page last changed on Nov 30, 2004 by jcarreira.
First off, if you're coming from Struts, you may feel more comfortable using FormBeans instead of using the Action as your form bean. Be aware, though, that in Webwork you DO have the option of having the properties directly in the Action class. If you want to use a FormBean, here's an example: public class TestAction extends ActionSupport { private TestBean myBean; public TestBean getMyBean() { return myBean; } public void setMyBean(TestBean myBean) { this.myBean = myBean; } protected String doExecute() throws Exception { myBean = new TestBean(); BeanUtil.setProperties(ActionContext.getContext().getParameters(), myBean); return SUCCESS; } } <!-- This will call getMyBean() on your action and put it on the top of the value stack -> <webwork:property value="myBean"> <!- This will call getName() on your TestBean and print it to the page --> The name is: <webwork:property value="name"/> </webwork:property> This is a good way to do it if you have several parameters from the TestBean that you want to display, but, if you have just one, like in this case, it's probably better to do this: <webwork:property value="myBean/name"/>
Which will call getMyBean.getName() and print that out to the page. |
| Document generated by Confluence on Dec 14, 2004 16:36 |


c = 0
ui, uj = next(vx, None), next(vy, None)
while (ui is not None) and (uj is not None):
if Lx[ui] == Ly[uj]:
c += 1
ui = next(vx, None)
uj = next(vy, None)
elif Lx[ui] < Ly[uj]:
ui = next(vx, None)
else:
uj = next(vy, None)
return c/float(nv_x+nv_y-c)
// get labels for vertices
Lx, Ly = Gx[1], Gy[1]
c, a, b = 0, 0, 0
while a < nv_x and b < nv_y:
la = Lx[vx[a]]
lb = Ly[vy[b]]


{% extends "ralph_pricing/report.html" %}
{% load url from future %}
{% load i18n %}
{% block description %}
{% trans "This report provides detailed info regarding costs for top ventures (i.e. from the top of the ventures' hierarchy tree) within selected time frame." %}
{% endblock %}


On November 21st, Super Duper is hosting an event for
children battling cancer to be team captain to build and
launch rockets! Each captain has the opportunity to be bring
a team of one to two super duper sidekick friends who together
will design, construct and launch kid-friendly rockets.
Sidekicks can be anyone -- a friend, supporter, cousin,
sister, brother, etc -- as long as they are between the
ages of 5 and 10 years old.
The event will be hosted at NASA’s Moffett Field. Rockets,
rocket instructors and lunch will be provided by the event.
We only ask that you bring one to two chaperones per child.
Applications are now open. As there are limited spots,
we will be taking teams on a first come, first serve
basis so be sure to apply now!
Left 4
Left 5
Help us spread awareness!
Help us spread the word by posting your own
Super Duper photo to
facebook
with the hashtag #youaresuperduper and a link to
youaresuperduper.org!
If someone you love is going through hardships, be sure to remind them how
super duper awesome and brave they are!
Together, we can make this a truly amazing event for everyone
involved, raise awareness and make someone smile!


EASTER 2 WEDNESDAY
Entrance Antiphon
I will praise you, Lord, among the nations;
I will tell of your name to my kin, alleluia.
Collect
As we recall year by year the mysteries by which,
through the restoration of its original dignity, human nature has received the hope of rising again,
we earnestly beseech your mercy, Lord, that what we celebrate in faith we may possess in unending love. Through our Lord...
FIRST READING Acts 5:17-26
A reading from the Acts of the Apostles
In those days: The high priest rose up and all who
were with him, that is, the party of the Sadducees, and filled with jealousy they
arrested the apostles and put them in the common prison. But at night an angel
of the Lord opened the prison doors and brought them out and said, "Go and
stand in the temple and speak to the people all the words of this Life." And
when they heard this, they entered the temple at daybreak and taught. Now the
high priest came and those who were with him and called together the council
and all the senate of
The word of the Lord.
RESPONSORIAL PSALM Psalm Psalm 34:2-3.4-5.6-7.8-9 (R. 7a)
R. The lowly one called, and the Lord heard him.
Or Alleluia!
I will bless the LORD at all times,
praise of him is always in my mouth. In the LORD my soul shall make its boast;
the humble shall hear and be glad.
R. The lowly one called, and the Lord heard him.
Glorify the LORD with me; together let us praise
his name. I sought the LORD, and he answered me; from all my terrors he set me
free.
R. The lowly one called, and the Lord heard him.
Look towards him and be radiant; let your faces not
be abashed. This lowly one called; the LORD heard, and rescued him from all his
distress.
R. The lowly one called, and the Lord heard him.
The angel of the LORD is encamped around those who fear
him, to rescue them. Taste and see that the LORD is good. Blessed
the man who seeks refuge in him.
R. The lowly one called, and the Lord heard him.
ALLELUIA John 3:16
R. Alleluia.
Gospel John 3:16-21
A reading from the holy Gospel according to John
Jesus said to Nicodemus, “God so loved the world
that he gave his only-begotten Son, that whoever believes in him should not
perish but have eternal life. For God sent the Son into the
world, not to condemn the world, but that the world might be saved through him.
He who believes in him is not condemned; he who does not believe is condemned
already, because he has not believed in the name of the only Son of God. And
this is the judgment, that the light has come into the world, and men loved
darkness rather than light, because their deeds were evil. For every one who
does evil hates the light, and does not come to the light, lest his deeds
should be exposed. But he who does what is true comes to the light, that it may
be clearly seen that his deeds have been wrought in God.
The Gospel of the Lord.
Prayer over the Offerings
O God, who by the wonderful exchange effected in this sacrifice have made us partakers of the one supreme Godhead, grant,
we pray, that as we have come to know your truth, we may make it ours by a worthy way of life. Through Christ our Lord.
Communion Antiphon
I have chosen you from the world, says the Lord, and have appointed you to go and bear fruit, fruit that will last, alleluia.
Prayer after Communion
I have chosen you from the world, says the Lord, a
nd have appointed you to go and bear fruit, fruit that will last, alleluia.


BeautyTips is a jQuery tooltips plugin which uses the canvas drawing element in the HTML5 spec to dynamically draw tooltips (sometimes called "talk bubbles" or "help balloons") associated with a html element on the page. These tips are highly configurable and can be triggered in many different ways.
The canvas element is supported in modern versions of FireFox, Safari, and Opera. However, Internet Explorer needs a separate library called ExplorerCanvas included on the page in order to support canvas drawing functions. ExplorerCanvas was created by Google for use with their web apps and you can find it here.
BeautyTips was written to be simple to use and pretty. All of its options are documented at the bottom of the .js file and defaults can be overwritten globally for the entire page, or individually for each target element (more about this in the wrap up section).
BeautyTips has been tested with jQuery 1.2.6 and 1.3 on Firefox 3.x, Safari 3.x (also works on iPhone!), IE 6.x+, and Opera 8+, but I'm sure other canvas-capable browsers will work as well.
By default each tooltip will be positioned on the side of the target element which has the most free space. This is affected by the scroll position and size of the current window, so each Beauty Tip is redrawn each time it is displayed. It may appear above an element at the bottom of the page, but when the page is scrolled down (and the element is at the top of the page) it will appear below it. Additionally, positions can be forced or a preferred order can be defined. See examples below.
BeautyTips has a page in the plugins directory on jQuery.com. This is where you can download the latest version. It is also the best place to post bugs and feature requests.
http://plugins.jquery.com/project/bt
To fix z-index problems with form elements in IE6, include the bgiframe plugin on your page. BeautyTips will automatically recognize it and use it.
BeautyTips also works with the hoverIntent plugin see hoverIntent example below for usage.
The function can be called in a number of ways.
$(selector).bt();
$(selector).bt('Content text');
$(selector).bt('Content text', {option1: value, option2: value});
$(selector).bt({option1: value, option2: value});
Note: html and javascript textareas are live. Feel free to experiment with the code and see how BeautyTips are affected.
This is the simplest example. No arguments are sent and the default settings are used to create a tip which appears on the side with the most space.
Tip appears above the element when it is clicked. The contents of tip is provided when creating the tip.
This example uses the contentSelector attribute to determine where the content comes from. In this case the selector is $(this).attr('href')
and the content is the href attribute of the hovered link. Other options define a red balloon with bold white text. The box will be a variable width up to 400px ("width: 'auto' in cssStyles makes text box shrink-to-fit) with rounded corners. The script will try to position the box to the left, then to the right, and finally it will place it on the bottom if it does not fit elsewhere.
There are four different functions which can be triggered at different points in the lifetime of a beautyTip: preShow, postShow, preHide, and postHide.
In this example, a function is triggered to change the content of the
target element before the tip is shown. After the tip is hidden, another
function changes the content back. this
in these function refers to the target element. These functions could be used for just about anything.
When the BeautyTip is active, an additional class is added to the target element. This class, called "activeClass", can be defined when calling the bt() function. Additionally, each BeautyTip popup has a wrapper div which surrounds its content. The class on this div is also definable.
Note that the BeautyTip "balloon" itself is drawn as a bitmap using canvas methods and functions similar to an <img> element, so it can not be affected by CSS. There are many options for changing this element using JavaScript options though.
The BeautyTip balloons are drawn dynamically and highly configurable. Customizable attributes include background color and opacity, stroke width and color, spike length and width, corner radius, and more. For convenience, style attributes such as font color and weight can be sent through the JavaScript call as well.
Images can be loaded into the BeautyTip. You should, however, add width and height attributes (or use CSS for this) so that the browser will know what size to "save space for" as the image loads.
This example also uses some special triggers so that the tip appears on mouseover, but disappears using click. BeautyTips' default clickAnywhereToClose option also allows the user to click anywhere in the document (outside of the tip) in order to close it. This can be disabled either globally or per tip.
The trigger is what causes the tip to appear/disappear. The default option is 'hover', which will trigger the tip when the mouse hovers over an element. If the hoverintent plugin is installed (as on this page), that will become the default trigger and there will be slight (but configurable) delay before the tip appears.
In this example, the trigger events for this textfield are 'focus' and 'blur'. This means that the tip will get triggered even if the user uses the tab key to enter/leave this form field.
In this example, 'keyup' triggers the display of the tip while 'blur' removes it. This means that the tip won't appear until the user actually changes the field (using the keyboard).
The full list of trigger events are: blur, focus, load, resize,
scroll, unload, click, dblclick, mousedown, mouseup, mousemove, mouseover,
mouseout, mouseenter, mouseleave, change, select, submit, keydown, keypress,
keyup,
and error
. However not all events are available for all elements (see: events documentation).
This tip is initiated with a trigger of 'none'. All of the options are set, but turn on/off of the tip isn't bound to any event. We can, however, turn on and off the tip using Javascript. $('#example15').btOn(); turns it on. $('#example15').btOff(); turns it off. These btOn() and btOff() functions are available for all elements which have been set up using the bt() function. So, we can programmatically turn on any BeautyTip on the page. Click here to turn on the tip from the previous example.
The hoverIntent plugin allows control over how and when the mouseOver
event gets triggered when a user hovers over an element. In this example,
the interval
has been cranked up to 1 second, so the user
needs to hover for almost a second before the tip appears. The timeout
has been raised to 2 seconds so the tip will remain visible for that long
before disappearing.
Content comes from the #content
div of the html page: demo-ajax.html. Note: this isn't really ajax, it's actually ahah (asynchronous HTML and HTTP). Ahah is much easier to deal with than ajax (which technically uses XML).
Requested ajax page doesn't exist. This example uses a custom error message. This example may not work correctly if you have opened the file locally (without a web server).
AjaxPath is being read from the 'href' value of the link. This is accomplished by defining the ajaxPath as an array. The first value of the array is the jQuery code to find the path value (in this case "$(this).attr('href')"
). The optional second value of the array is the content selector within the loaded page (in this case 'div#content'
). This is a handy way of adding "preview" BeautyTips to a bunch of links on a page.
A popup with lots of content. This popup gets populated from a div which immediately follows this text in the html source, but gets hidden by the same script which defines the BeautyTip. This is a good way to provide degradable help which appears for users with JavaScript disabled.
This tip is chock-full of content. It is intended to show how BeautyTips deals with fitting large content onto the page. The rest of this content is gibberish. Seamlessly empower dynamic communities with clicks-and-mortar testing procedures. Globally scale front-end ideas through next-generation web services. Holisticly harness business data via resource maximizing meta-services.
Assertively pontificate extensible ROI via end-to-end manufactured products. Compellingly scale resource sucking human capital rather than visionary infomediaries. Quickly evolve robust data with intuitive vortals.
Authoritatively revolutionize scalable solutions without e-business intellectual capital. Compellingly restore web-enabled potentialities through tactical information. Phosfluorescently disintermediate stand-alone convergence for team building sources.
Interactively leverage existing sticky products rather than orthogonal expertise. Enthusiastically innovate worldwide process improvements whereas proactive markets. Appropriately evisculate B2B niche markets before vertical content.
Quickly reinvent state of the art potentialities after process-centric experiences. Completely e-enable sticky technology whereas impactful ideas. Dynamically underwhelm holistic "outside the box" thinking whereas effective testing procedures.
Synergistically plagiarize cost effective leadership and low-risk high-yield e-commerce. Credibly maintain market positioning strategic theme areas and client-based benefits. Globally disseminate clicks-and-mortar infomediaries for premium e-tailers.
Professionally reconceptualize interdependent content through error-free innovation. Collaboratively provide access to one-to-one strategic theme areas without magnetic web-readiness. Appropriately negotiate strategic opportunities without timely alignments.
Continually engineer premier best practices after plug-and-play communities. Monotonectally drive installed base users whereas wireless products.
Animation can be added by creating a custom showTip
or hideTip
function. Each function gets an argument of box
, which is a reference to the .bt-wrapper div around the tip. The box
element is set to display: none, so your code will presumably use animation methods to show it. The this variable in each function refers to the target (hovered, clicked, focused, etc) element. The hideTip
function gets a second argument of callback
. This is a reference to the cleanup function and MUST be triggered at the end of the hideTip
animation.
It appears that this animation doesn't work correctly in Internet Explorer. This is most likely a bug somewhere between jQuery and Explorer Canvas. It does degrade to non-animated functionality though. Ironically, the complex animation example below works better in IE.
At the time that showTip
is triggered, the tip is hidden (display: none) but completely built, positioned, and ready to go. If we want to animate its position, size, or other attributes, we need to create variables representing the current attributes so that we know where to end our animation. In this example, we're animating the size of the canvas (the bitmap drawing of the tip) as well as it's left and top position so that it remains centered as its size animates.
In order to keep the animation efficient, the content (the text) is hidden during the animation and appears after the animation is finished.
hideTip
works in reverse. The callback gets called at the end of the animation to cleanup the box, removing it from the DOM and getting things ready for the next time the tip is triggered.
Drop shadows are part of the canvas spec, but they are not implemented by many browsers. Drop shadows currently only work in Safari and Firefox 3.5 and higher. Eventually I would like to create canvas-drawn drop shadows that should work in all browsers, but for the time being, keep in mind that these won't work in all browsers. However, for these non-drop-shadow browsers, you can define "no shadow options" (noShadowOpts) to define how the tip should be displayed if shadows aren't supported.
Netflix-style big descriptive popups using ajax.
Google Maps balloons! Content is provided by a hidden div on the page. Note the use of centerPointX to adjust where the spike extends from. We're also using a close-box "x" image in the content which is a javascript link to close the tip.
Facebook-style.
Hulu style. Use Safari or Firefox 3.5+ to get the full effect with the drop shadow.
A full list of options can be found at the bottom of the jquery.bt.js file itself. Scroll to the bottom of the file to see the list of options along with their default values and a short descriptions of what each one does.
These defaults can be overridden during each call to the $.bt() function (as in the examples above) or they can be overridden globally for all BeautyTips on the page. For instance, to change the ajax loading content for all BeautyTips on the page, you could insert the following code into your document's <head> (somewhere after <script src="jquery.bt.js"...):
<script language="JavaScript">
jQuery.bt.options.ajaxLoading = '<img src="/images/throbber.gif" width="40" height="40" />';
jQuery.bt.options.closeWhenOthersOpen = true;
</script>
Found bugs and/or want to contribute to development? Please use the issue queue on jQuery.com.
Twitter: I tend to post about BeautyTips development on Twitter, so follow me if you'd like to keep up with the latest news.
IRC: I also tend to hang out in the #jQuery IRC room (username: jjeff). If you've got quick questions about BeautyTips, try to find me there.
Is BeautyTips saving you money and development time on your project? Do you feel compelled to reward its developer for his hard work and encourage further development? Well you could certainly buy him something from his Amazon wish list.
It's always encouraging to hear from people using BeautyTips for cool and/or notable things. Just send a note to . I'd love to hear from you. Please do not email me with support requests. Those should go to the issue queue.
- Jeff Robbins


Welcome to Ben's pizza parlor!
What kind of pizza would you like?
small
medium
large
huge
Pepperoni
Cheese
Pineapple
Olives


For an equilateral triangle, all sides must be equal. For an isosceles triangle, two sides are exactly equal. For a scalene triangle, none of the sides is equal. the sum of any two sides of the triangle must be greater than the third side


Custom Webpage
Abandoned Places
Rising Sea Levels
Overgrown Train Tracks
Sandy Floridian Home
Overgrown Ship in Australia


{% extends "layout.html" %} {% block page_header %}
Create a playlist to edit with your circle of friends.


Given EURJPY data, our first step is to decompose our data into multiple resolutions. We work with wavelets using the pywt package. For denoising, Daubechies and Symlets are good choices for Wavelets, and we use Symlets 10 in our strategy. We create a Symlets 10 Wavelet using the following:
w = pywt.Wavelet('sym10')
To determine the length of the data we’d need for a certain number of levels after decomposition, we can solve for:
\[log_{2}(\frac{len(data)}{wavelength-1})=levels\]Given the length of a Symlet 10 wavelet is 20, if we want three levels, we solve for len(data) to get len(data) = 152, which means data would need to have at least 152 values. Since we will denoise our components using thresholding, we specify threshold = 0.5 to indicate the strength of the thresholding. This threshold value can be any number between 0 and 1.
To decompose our data, we use:
coeffs = pywt.wavedec(data, w)
For each component, we threshold/denoise the component (except for the first component, the approximation coefficients), roll the values of the component one spot to the left, and replace the last value of the component with a value forecasted from an SVM. This process looks like the following in code:
for i in range(len(coeffs)): if i > 0: # we don't want to threshold the approximation coefficients coeffs[i] = pywt.threshold(coeffs[i], threshold*max(coeffs[i])) forecasted = __svm_forecast(coeffs[i]) coeffs[i] = np.roll(coeffs[i], -1) coeffs[i][-1] = forecasted
The __svm_forecast method fits partitioned data to an SVM model then predicts one value into the future, and can be found under SVMWavelet.py file under the Algorithm section
Once we forecast one value into the future, we can aggregate the forecasts by recombining the components into a simple time-series. We do this with:
datarec = pywt.waverec(coeffs, w)
Since we want the aggregate forecast one time-step into the future, we return the last element of this time-series, or datarec[-1].
Our trading rules are simple: feed in the past 152 points of daily closing prices of EURJPY into our SVM Wavelet forecasting method, and divide that number by the current close of EURJPY to get the forecasted percent change. Then, we emit an Insight based on the direction of the percent change with the weight of the Insight as the absolute value of the percent change. We use the InsightWeightPortfolioConstructionModel so that the weight of the Insight determines the portfolio allocation percentage, which means larger forecasted moves will have a larger allocation.


| Created: | 8/19/2020 1:37:01 PM |
| Modified: | 8/19/2020 1:37:01 PM |
| Project: | |
| Advanced: |
| Attribute |
|
Public serial id |
|
Details:
|
|
Public integer budgetable_id |
|
Details:
|
|
Public integer budget_type_id |
|
Details:
|
|
Public bigint award_amount_cents |
|
Details:
|
|
Public date start_date |
|
Details:
|
|
Public date end_date |
|
Details:
|
|
Public varchar(255) created_by |
|
Details:
|
|
Public varchar(255) updated_by |
|
Details:
|
|
Public timestamp with time zone(0) created_at |
|
Details:
|
|
Public timestamp with time zone(0) updated_at |
|
Details:
|
|
Public bigint distribution_line_amount_cents |
|
Details:
|
|
Public bigint balance_amount_cents |
|
Details:
|
|
Public boolean is_at_or_below_threshold |
|
Details:
|
|
Public boolean is_negative_balance |
|
Details:
|
| Operation | ||
|
Public budget_periods_pkey( id: serial, |
||
|
Details:
<<PK>>
|
| Tag | Value |
| Owner | public |
|
Details:
|
| Property | Value |
| isFinalSpecialization: | 0 |


My name is Günter Lugo. I currently work in healthcare technology focusing on electronic health records. Currently, I am an implementation specialist in the customer success department. I am looking to transition to the engineering team.


Aarakocran | |
| Description | Aarakocran are bipedal birdmen, with hands incorporated into their wings.  They are adept flyers with superior vision. |
| Stat Adjustments | dexterity+2, constitution-1, charisma-1, max dexterity adj.+2, max constitution adj.-1, max charisma adj.-1, save vs overlooking+50 |
| Bonus Abilities | Eagle Eyes(50%), Winged Flight(100%), Hunting(50%) |
| Bonus Languages | Bird Speak(100%) |
| Life expectancy | 45 years |
| Starting Equipment | a nice tunic, a pair of pants, a knitted weapon belt |
| Qualifying Classes | Apprentice Artisan Assassin Barbarian Bard Beastmaster Burglar Cleric Doomsayer Druid Fighter Gaian Gaoler Healer Minstrel Missionary Necromancer Oracle Pirate Dancer Purist Ranger Reliquist Scholar Shaman SkyWatcher Templar Thief Trapper |


µEforth (micro-Eforth) simplifies EForth even futher, by building just enough of the core of the system in C to allow the rest to be be built in proper Forth.
A handful of "tricky" words that involve internal loops or many steps are built in their own functions:
FIND ( a n -- xt | 0 ) PARSE ( ch -- a n ) S>NUMBER? ( a n -- n f | 0 ) CREATE ( "name" -- ) EVALUATE1 ( -- )
This includes EVALUATE1
which parses a single word and
interprets or compiles it (reusing PARSE
,
FIND
, and S>NUMBER?
).
See core.h.
A few global variables connect parsing and compilation state between
C and Forth (by way of a memory region accessed via 'SYS
):
'TIB --- Pointer to the Translation Input Buffer #TIB --- Length of the Translation Input Buffer >IN --- Number of characters consumed from TIB BASE --- Numeric base for printing and parsing STATE --- State of compiling, -1 for compiling, 0 for interpreting CURRENT --- Pointer to pointer to last word of current vocabulary CONTEXT --- Pointer to pointer to last word of context vocabulary 'NOTFOUND --- Execution token of a handler to call on word not found
Error handling is routed via a deferred callback in 'NOTFOUND
used when a word is absent from the dictionary.
This is eventually directed to an error routing that prints
a proper error, once I/O and exceptions are available.
X-Macros are then used to build up a small set of core opcodes defined in 1-3 lines each:
0= 0< + U/MOD */MOD AND OR XOR LSHIFT RSHIFT DUP SWAP OVER DROP @ L@ C@ ! L! C! SP@ SP! RP@ RP! >R R> R@ : ; EXIT EXECUTE BRANCH 0BRANCH DONEXT DOLIT ALITERAL CELL DOES> IMMEDIATE 'SYS
See opcodes.h.
I/O and access to systems outside Forth are connected via a few per platform words. Typically this set of words should be minimal, while still allowing relevant parts of the host system to be available to Forth.


Our monsters are a friendly bunch. They only live under your bed because they’re too polite to ask if they can snuggle.


| {{ '' + var }} | {{ '' + node }} |
|---|---|
| {{ cell }} |
Enter a boolean expression such as A ^ (B v C)
in the box and click Parse.
See {{ ext_info ? 'less' : 'more' }} information
Supported operations are AND
, OR
, NOT
, XOR
, IMPLIES
and EQUIV
.
Instructions
Operations and constants are case-insensitive.
Variables are case sensitive, can be longer than a single character, can only contain alphanumeric characters, digits and the underscore character, and cannot begin with a digit.
Operations
Operations are executed in order of precedence, from higher to lower.
Operations with the same precedence are executed from left to right.
To execute a particular operation first, surround it with parenthesis ( )
.
| Operation | Aliases | Description | Precedence |
|---|---|---|---|
NOT A |
~ ' ! ¬ |
false if A is true; true if A is false. | first |
A AND B |
∧ ^ & · * |
true if both A and B are true; false if either or both are false. | second |
A EQUIV B |
⇔ ≡ ↔ = |
true if both A and B are true or both are false; false if one is true and the other is false. | second |
A IMPLIES B |
⇒ → ⊃ > |
true if A is false, or A is true and B is true; false if A is true and B is false. | second |
A OR B |
∨ v + ∥ | |
true if A is true, B is true, or both are true; false if either or both are false. | third |
A XOR B |
⊻ ⊕ |
true if A is true and B is false; true if A is false and B is true; false if both are true or both are false. | third |
Constants
| Constant | Aliases | Description |
|---|---|---|
TRUE |
1 T ⊤ true |
Always evaluates to true. |
FALSE |
0 F ⊥ false |
Always evaluates to false. |


Bunker is a contact storage application. It is built to hold things like addresses, birthdays, phone numbers, and emails.
Bunker is currently completely free. It is also open-source! You can find the entire source code for this project on gitHub. ;)
Bunker was made for a personal project at Union College during a web technologies course. Its main purpose was to teach the concepts and applications of node.js along with many of its accompanying plugins.
Bunker was written nearly completely by Nathan Bland, a senior computer science major at Union College. With some key assists from the instructor of the class - Ben Barber - and some aid from fellow classmates.
One major shoutout to the oatmeal comic for the error page images. He makes other awesome stuff, you should go read some of his comics when you have a chance.
Bunker is free to use, but is also still under development. While it is currently in a mostly stable state, that does not mean things will not break. When things do break, you can't blame the creator for loss of data, or time. The software is provided as is, use it wisely. =)