Skip to main content
Version: 7.2402.x.x RR

Glossary

Artifact​

  • Description: Output of the generation process. The artifacts are the input for the provisioning process that transfers the artifacts to a specific set of infrastructure nodes that need to be transferred to a specific location.

Generation​

  • Description: The process by which artifacts and instructions are created out of configuration elements.
  • Comments: Generation and deployment are two discrete steps. First, nevisAdmin 4 generates the artifacts and instructions. The user can review the result and choose to continue with deployment.

Generation Engine​

  • Description: A standalone command line program that generates and deploys a configuration.

Provisioning​

  • Description: Provisioning is transferring artifacts and instructions to hosts. It is part of deployment.

Branch​

  • Description: A sequence of committed changes within a configuration unit. A new project can be created by forking off a branch from an existing project. Creating/deleting a branch are explicit operations of the version control domain.

Commit​

  • Description: Operation of the version control system in which a set of changes is added to a branch. A commit cannot be undone. A commit cannot be undone. When publishing changes to Git, nevisAdmin 4 runs git commit immediately followed by git push to the remote version control repository.

Running Configuration​

  • Description: The current configuration of a host managed by nevisAdmin.

Configuration​

  • Description: Consists of patterns that, on a high level, specify the behavior of Nevis components and relate third-party components. The configuration is abstract, thus without specifying concrete host names or IP addresses for the locations of these components. Multiple branches of the same configuration can exist at the same time. They are made available as projects.

Deployable Pattern/ Instance Pattern​

  • Description: A pattern that can be deployed to one or multiple hosts.
  • Comments: Each deployable pattern has a deployment target property that allows for the selection of a host or a host group. A deployable pattern is the starting point of a generation process, with its own generation context.

Deployment​

  • Description: The process of updating the running configuration on one or multiple hosts. A process that transports artifacts (provisioning) and activates them at hosts by executing instructions, thus applying a configuration.

Deployment Target​

  • Description: The service, host, or group of hosts onto which a deployment is executed.

Filter​

  • Description: A concept for narrowing the number of elements to those that meet specified criteria.

Generation Context​

  • Description: The context in which instructions and artifacts are generated. During each generation round, a separate Generation Context is created per deployable pattern and host.

Host​

  • Description: An entity to which configuration can be deployed. Similar to "server" and "hostname".
  • Comments: Also known as (virtual) machine, VM, server, or hostname.

Host Group​

  • Description: A container for hosts. A host can be in zero, one or multiple groups. The group contains hosts with similar function. Purposes of groups:
    • A host group can act as the deployment target within a deployable pattern.
    • A host group can specify values for variables which apply only within that group.
    • A host group can be used to restrict deployment only to those hosts.

Infrastructure​

  • Description: All inventories within nevisAdmin 4.

Instruction​

  • Description: A UNIX command that is executed on a target host during deployment.

Inventory​

  • Description: A list of hosts, groups and host and group variables. A tenant can have multiple inventories.

Pattern Category​

  • Description: The classification of a pattern. Purely for helping users navigate/find related patterns or related pattern types.

Pattern (Class)​

  • Description: Serves as a reusable template to define processes and use cases in configuration. Pattern types consist of property types, validation and generation code. Pattern types are plug-ins. They may be provided by nevisAdmin 4 (standard patterns) and can be developed by an integrator or the customer (custom patterns).
  • Comments: Pattern classes are written in the Groovy scripting language.

Pattern Library​

  • Description: A collection of plug-in bundles containing, mainly, pattern types. Standard Pattern Library = all patterns shipped with the product and officially supported. Custom Pattern Library = a set of patterns developed by or for a specific customer, normally for non-standard use cases.

Pattern (Instance)​

  • Description: A concrete pattern instance (object) containing user-provided configuration settings. Pattern instances can be stored in version control in the context of the project. Each pattern instance is associated with one pattern class: the class contains a script that validates the settings and generates instructions and artifacts based on the settings.
  • Comments: Each pattern instance is stored in a separate YAML file. This includes all property values.

Pattern Reference​

  • Description: Link from one pattern to another pattern. A property of the type "pattern reference", which can be one of the properties in a pattern, allows the referencing pattern to utilize the referenced pattern during the generation process.

Plug-in​

  • Description: Extension of the nevisAdmin 4 platform. The following object types are realized as plug-ins:

    • Pattern types

    • Property types

    • Generators

    • Reports

      A plug-in is identified by its class name. It is a Groovy or Java class provided by a plug-in bundle.

Plug-in Bundle​

  • Description: A set of plug-ins and their resources packaged as a JAR file. It can be dynamically uploaded, activated and deactivated at runtime. Plug-in bundles have a version number.
  • Comments: In the nevisAdmin 4 user interface, the plug-in bundles (JAR files) appear as (pattern) libraries.

Project​

  • Description: Collection of patterns and variables definitions belonging to the same configuration. nevisAdmin 4 manages one or more projects. nevisAdmin knows (stored locally) which projects exist and which version control system and branch to load them from.

Property (Instance)​

  • Description: Based on a certain property type. The user can then either set a value or use a variable.

Property Type​

  • Description: Basic building block of patterns. Each property type has its own representation on the UI. Each pattern type is composed of a set of property names and property types.
  • Comments: Some examples: SimpleTextProperty, SelectionProperty, ReferenceProperty and AttachmentProperty.

Orchestration​

  • Description: Orchestration solution like Ansible, Puppet, Salt, Shell.

Stage​

  • Description: A server environment where configuration is deployed to. Often, customers have sequences of stages through which configurations move from testing towards production (for example, TEST, INTEGRATION, ACCEPTANCE, PRODUCTION).
  • Comments: Within nevisAdmin 4, stages are modeled as inventories.

Issue​

  • Description: An event that happened during one of the processes, such as generation, validation, deployment, etc, and which is communicated to the user. Issues have a severity like ERROR, WARNING, or NOTICE.

Tenant​

  • Description: A single nevisAdmin instance is able to manage multiple dedicated configuration subdivisions, called tenants. Each tenant has its own projects and inventories, and supports tenant-level permissions.

Variable​

  • Description: A property can use a variable instead of having a fixed value. The property will use the value assigned to that variable in a specific context, for example a hostname that depends on the actual generation / deployment context.

YAML​

  • Description: "YAML Ain't a Markup Language". The formatting language (comparable to JSON and XML) used by nevisAdmin 4 to store, export and import various kinds of data. Benefits of this format include:
    • It is optimized to be both machine-readable/editable and human-readable/editable (unlike XML and JSON).
    • It is loosely typed (unlike XML).
    • It is commonly used for managing configuration and deployment.
  • Comments: http://en.wikipedia.org/wiki/YAML