Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

tocWaldur allows you to provision complex infrastructure using following methods:

  1. API-based

...

  1. offerings 
    Jira
    serverSystem JIRA
    serverIdca50d181-b528-3212-b97e-7f9646e1b71e
    keyWAL-762
  2. Request-based offerings

Waldur supports configuration of offerings, which lead to creation of a new service request in Helpdesk for manual processing. Typically, this is needed for setting up and exposing over API offerings that cannot be automated or require offline negotiations.

Configuration of offerings is done in Waldur MasterMind configuration file, under OFFERINGS section of WALDUR_SUPPORT configuration.

High-level idea

Provisioning an offering of the request-based type, will lead to creation of offering request model and a ticket in the Helpdesk backend with a summary: 'Request for '{Offering_label}'. 'Offering_label' is going to be taken from configuration of the offering, in particular from 'offering_type→label' section. If label is not present a name of the section will be used. 

OFFERINGS configuration structure

As an example, let's configure an offering for Digital Transformation of existing applications into cloud-native ones. A block under 'OFFERINGS' section would need to be added to the WALDUR_SUPPORT section:

Code Block
WALDUR_SUPPORT = {
...
'DEFAULT_OFFERING_TYPE': 'Service Request',
'OFFERINGS': {
	'offering_type': {
    	'label': 'Digital transformation',
        'category': 'Security',
		'article_code': '',  # article code is used for encoding product category in accounting software
        'product_code': '',  # technical code used by accounting software
    	'order': ['field_name2', 'field_name1'],
    	'options': {
         	'field_name1': {
             	'type': 'integer',
             	'label': 'Number of legacy applications',
             	'default': 1,
          	},
          	'field_name2': {
             	'type': 'string',
             	'label': 'Estimated deadline'
             	'help_text': 'Free form description when the project needs to be done'
          	},
     	}
	},
...
}

Please note that article code and product code are optional fields. Maximum length of each field is 30 characters. If these fields are defined, they are copied from configuration to newly created offering.

Each field configured in 'options' must be present in the 'order' set otherwise an appropriate error will be raised. 

There are 4 pre-defined fields: project, name, description and type. Specifying any of them in configuration may lead to unexpected behavior.

  • Project field has to be referenced in a request as a URL link.
  • Name allows to redefine label of the offering to be displayed in Service Store.
  • Description will be added to the end of the issue description if provided.
  • Type which defines an offering type and a configuration section to read from. 

Field options

Type

  • integer
  • string - considered to be default one and can be omitted.

Default

Default value to use if field has not been provided in request.

Label

Issue description. Considering configuration below a description of the issue will have the next format:

No Format
'Name': 'IT Transformation'
'Number of legacy applications' : '10'
'Estimated deadline': 'Deadline in May'
'Description': 'I would like to transform my applications into more cloud-enabled'

Please notice that 'Description' field is always placed on the bottom of the issue description.

Category

A category name of the service. Used for grouping of services in Service Store.

Help Text

A description of a field that will be displayed in the form near a corresponding field. 

Example of creating a new request-based offering

For an offering configured as described above, the following API request would be accepted:

Sending POST request to the URL: https://waldur.example.com/api/offering/offering-name-used-in-URL/ with a body payload of:

Code Block
{ 
'field_name1': '10', 
'field_name2': 'Deadline in May', 
'project': 'https://waldur.example.com/api/projects/00cf40c2-9332-42c4-bad3-4fd965ff21dc', 
'name': 'IT Transformation',
'description': 'I would like to transform my applications into more cloud-enabled.',
'type': 'offering_type',
}

Issue type configuration

It is possible to configure a type of the issue by editing 'DEFAULT_OFFERING_TYPE' configuration. For instance, default type is configured to 'Service Request' as shown below:

Code Block
languagepy
WALDUR_SUPPORT = {
...
'DEFAULT_OFFERING_TYPE': 'Service Request',
'OFFERINGS': { ... },
...
}

Default offering type is used as an issue type in a configured Helpdesk tool.

Accounting

A total price for a particular offering is calculated based on the number of days the offering was in OK status, i.e. available for the end-user for consumption.

Lifecycle of a typical offering lifecycle is as follows:

  • Offering types are configured by operator of Waldur MasterMind.
  • User selects a service offering from a Service Store and submits a request. Request is created with a status of "Requested".
  • Operations fulfill the request.
  • A staff user defines price per day of the offering and updates it in the administrative panel of MasterMind and sets offering state to OK.
  • Accounting starts from the moment of setting the state to OK.
  • Accounting ends with a staff user setting offering state to Terminated.

Created offerings can be browsed in Support → HelpDesk → Offerings menu.

Image Removed

Price can be updated by clicking on required offering and setting price in the form that shows up.

Please notice that a price per day needs to be defined.

...

  1. Ansible-based applications