normative types & connectsto the relationshiptype base type of “connectsto” in the current...
DESCRIPTION
Tiers & Dependencies SugarCrmApp [SugarCRMApplication] SugarCrmDb [SugarCRMDatabase] ApacheWebServer [ApacheWebServer] MySql [MySQL] connects to hosted on depends on VmApache [Server] VmMySql [Server] hosted on OsApache [OperatingSystem] OsMySql [OperatingSystem] hosted on WebTier [Tier] DbTier [Tier] PhpModule [ApachePHPModule]TRANSCRIPT
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?