Package org.thales.punch.platform.api

To deal with configuration and administative tasks, the punchplatform relies on a carefully well designed configuration service.

See: Description

Interface Summary

Interface	Description
IApplication	The IApplication interface lets you access a given topology resources.
IApplicationControl
IApplicationExitController	This interface is used to be prompted about punch application that expresses their willingness to stop.
IApplicationExitReporter	This interface lets punch application express their willingness to exit.
IApplicationStartReporter	An application start reporter can be used to signal the start of an application.
IBook	The IBook interface lets you access a given dag resources.
IChannel	The IChannel interface lets you access a given channel resources.
IConsolePrinter	Whenever a pojo must be printed out the the terminal, it can rely on these methods to produce a colored and rightly aligned information.
IConstants	Use this one for various constant values that are used in several places.
IECS
IEntity	The IEntity interface lets you access a given entity or dag resources.
IExitCondition	Punch application may decide they need to stop.
IExitRequest	This interface express a wish of some application to exit, with a success or failure endeavor.
IKafkaCluster	Interface used to access settings from the platform relative to kafka clusters.
IKeys	Some (a big part) of the Punchplatform configuration properties are defined in json files.
IKubernetesCluster
IMetrics	This interface groups all the metric name we use.
IParameters	All enumeration of punchplatform parameters (arguments of main class)
IPlatform	The IPlatform represents your entry point to access your running platform configuration data.
IPrinterPojo	The ppunch cli are meant to be used in two different ways.
IPunchLineNodesName
IPunchPlatformProperties	The PunchPlatformProperties represents your platform punchplatform.properties file.
IPunchShell	Shells that exists in punchplatform
IReservedFields	Reserved punchplatform fields.
IResolver	The IResolver is in charge of resolving sone logical addresses, i.e.
IRuntime	Available execution runtime for punchlines
ISecurity
IShivaCluster	Shiva administration interface.
ISystemProperties
ITenant	This interface gives you access to all the configuration files defined for a given tenant.
ITopic	The ITopic interface lets you access a given topology resources.
ITopology	The ITopology interface lets you access a given topology resources.
IZookeeperCluster	Interface used to access settings from the platform relative to Zookeeper clusters.

Class Summary

Class	Description
ApplicationEnv	An application is one of the many application launched by books or channels.
Environment	This class is the single entry point to access the several environment variables.
IECS.Error	error field content
IECS.Host
LogRecord	A LogRecord simply represents a log4j, stdout or stderr trace catched from shiva itself or one of its launched application.
NodeImpl	A punchline dag node.
PlatformProvider	This your one and single entry point to get access to your platform configuration file.
Subscription

Enum Summary

Enum	Description
EClusterType	The valid clusters
EExitType	The valid exit types, platform or process.
EPunchlineDeployMode	The runtime type of this punchline.

Package org.thales.punch.platform.api Description

To deal with configuration and administative tasks, the punchplatform relies on a carefully well designed configuration service. Its architecture is simple, robust and safe.

There are two type of tasks performed on a punchplatform : some are performed directly by the user using cli commands, others are executed periodically as platform housekeeping tasks.

The general idea is to have a zookeeper cluster in charge of centralizing all the resources and property files required to perform an administrative action. All platform tasks rely on zookeeper to retrieve configuration information. Note that zookeeper only contains the latest version of configuration items. It does not keep track of the history. This is good enough for platform taks that are in charge of implementing dynamic services : dynamic means here that whenever a new channel or tenant is defined, platform service will eventually be notified and take appropriate actions. No need to reconfigure and restart the platform tasks whenver you (as a user) update your configuration.

For example one of the platform service is in charge of exposing the overall platform health to third-party supervision services. Should you add a new channel, that new channel health information will be shortly dynamically and automatically part of the overall platform health status.

The question is now : as a user, how do you update the configuration. Users deal with plain configuration files, stored in a local unix folder. That folder location is defined in the user environment PUNCHLATFORM_CONF_DIR variable. The layout of that folder is :

• PUNCHPLATFORM_CONF_DIR/tenants : holding all per tenant files (including channels and per tenant etc/conf.json files)
• PUNCHPLATFORM_CONF_DIR/tenants : holding all per tenant files (including channels and per tenant etc/conf.json files)
• PUNCHPLATFORM_CONF_DIR/punchplatform.properties : the platform-wide properties. In that file are defined the urls of the platform applicative services such as Elasticsearch, Spark, Storm clusters.

This folder is git enabled. This lets user safely update their configuration items. Once happy, they commit and push their changes. This makes the changes propagated to zookeeper, hence visible in turn to administrative tasks.

To sum up the platform configuration plane relies on unix folder and Git as far as users as concerned, and zookeeper as far as administrative tasks are concerned.

Two last point are worth understanding. First user submit commands using a cli tool, such as starting a channel, it is not (in general) wise to go through the commit first. Often user need to test configuration changes first. This is important in order not to mess up with the platform monitoring should you perform repair or test actions on your production platform. To make user life simple, platform cli tools automatically detect and use configuration from local folder versus central zookeeper.

Second, some resource files are too big to go through zookeeper. Big resources (jars, binaries, database geoip content files) are preinstalled on the remote servers and accessed locally by startup topologies. The LocalEnvironment class helps you to deal with specifically accessing local only resources.