Normative Types & connectsTo

The RelationshipType base type of “connectsTo” in the current draft on Normative Types in Tosca seems to be incomplete.

In the following, options for resolving this incompleteness are surveyed in the light of emerging ideas about simplification, json exchange formats, procedures for obtaining information from the environment, and clarifying the scope of “network feature” specification in TOSCA.

RootRelationshipType : ConnectsTo

ValidSource

typeRef description

EndpointRequirement RootRequirementType

ValidTarget

name description

EndpointCapability RootCapabilityType

Interfaces

name parms description

TBD

Properties

name type Prescription

default description

TBD

DefinitionRelationship that indicates a node can “connect” to another node of a specified type. For example: •A WebApplication node “connectsTo” a Database node.

Known SubclassesIPEndpointRequreiment, HTTPEndpointRequirement, IPEndpointCapability, HTTPEndpointCapabilityCan we not flatten??? Using properties such as “protocol” (or protocol list?)

InstanceStates

state description

N/A -

Tiers & Dependencies

SugarCrmApp

[SugarCRMApplication]

SugarCrmDb

[SugarCRMDatabase]

ApacheWebServer

[ApacheWebServer]

MySql

[MySQL]

connects to

hosted on

hosted on hosted on

hosted on

depends on

VmApache

[Server]

VmMySql

[Server]

hosted on hosted on

OsApache

[OperatingSystem]

OsMySql

[OperatingSystem]

hosted on hosted on

WebTier

[Tier]

DbTier

[Tier]

PhpModule

[ApachePHPModule]

Networked Service Endpoints

Service Endpoint Network Layers URL: <protocol,hostname,port,path,[queryparams]> DNS/NIS/hostsfile name to address resolution IP Routing, Reachability, Public, Private, NAT DHCP: MAC to IP (Probably not in scope)

ConnectsTo network info. between OS levels? But, why not just instead modeled as TOSCA

Property? Static vs Dynamic values issues. GetsFromEnv or SetsToEnv e.g. hostname to IP mapping in some name resolution table?

Delete it and capture network information as a value in a

Property element, e.g. service URL. And/or: add a node for a network tier, with layers for

hostedOn dependencies, and depicting installation constraints (such as “app and service on same subnet” by using “dependsOn” relations from app or service to network tier)

Some other modeling using existing containers. What are some pros/cons for Deletion?

Delete or Fix “connectsTo” as a Normative type

Pros for DeletionPros:

Overall simplification. Main use cases relate to service endpoint configuration. Handle with Properties and environmental procedures (getEndpointInfo(node n)).

YAML models already “collapse” flavors of dependencies, and use environmental procedures to get/set .

Avoid spending time on “fixing/completing” normative type sections

Cons for DeletionCons

Still need to tell modelers what network information belongs where in a TOSCA model...

And what should be omitted (I.e, left to the implementation to default or handle sensibly)?

TOSCA model (imo) should be able to specify placing a tier on a separate subnet. For example, if multiple services are used by central application, some may be in on-premise DB services (“hybrid” clouds). Should have some TOSCA approach for models of this style of cloud deployment/topology...

If Direction is to “Fix” Decide on scope of networking feature specification relating to

life-cycle operations! For example, service endpoint network installation,

configuration, start/stop. Add way for service invoker to obtain endpoint information in form needed for install/config/start (environment procedures).

Or, add way to specify a constraint on OS routing table so as to make service reachable from invoker.

Or, add way to request that a service be in protected/private domain.

Can default networking features be defined when multiple tiers are present – at least as guidance for modelers?