Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[dev.icinga.com #5855] custom attributes (vars) V2 #1358

Closed
icinga-migration opened this issue Mar 25, 2014 · 22 comments

Comments

@icinga-migration
Copy link
Member

@icinga-migration icinga-migration commented Mar 25, 2014

This issue has been migrated from Redmine: https://dev.icinga.com/issues/5855

Created by tgelf on 2014-03-25 16:28:40 +00:00

Assignee: mfriedrich
Status: Closed (closed on 2014-04-07 12:11:55 +00:00)
Target Version: 0.0.10
Last Update: 2014-04-07 12:11:55 +00:00 (in Redmine)


Attribute: vars
Docs: Custom Attributes

  • functionality of custom and macros in one feature
  • dump static configured vars (Host, Service, User, Commands, IcingaVars) into IDO, livestatus, status.dat
  • extra handling for address**,**_url, etc -> not dumped into customvariables
  • support modified attributes for custom attributes
  • runtime macros for custom attributes
    • support for $_{HOST,SERVICE}...$ is removed
    • "magic" runtime macros ($HOSTSTATE$ etc.) are named like $host.state$, $icinga.datetime$
    • $HOSTADDRESS$ -> $address$ or $host.vars.address$, provides fallback to host_name just like Icinga 1.x
    • access custom attributes either directly on the object as $address$ or $host.vars.address$ for specific object scope
object CheckCommand "keks" { 
  import "..." 
  command = " $plugindir$/blub" 
  env = { 
    HOSTNAME = "$host.name$ $host.state$" 
  } 
}
  • export_macros -> env
  • env is a dictionary, not an array
  • env keys are env variable names
  • macros in env values will be resolved (macro resolver)
  • no more escape_macros; all macros will be escaped if a string is provided
  • IcingaMacros -> IcingaVars, global custom attributes
  • 'vars' is a dynamicobject attribute
  • rename entire documentation/code

Attachments

  • test.conf mfriedrich - 2014-04-05 16:42:46 +00:00

Changesets

2014-04-03 09:35:25 +00:00 by (unknown) 5c58eb3

Merge 'macros' and 'custom' attributes into 'vars', part 1.

Refs #5855

2014-04-04 14:35:45 +00:00 by (unknown) 17b87c9

Add CompatUtility::IsLegacyAttribute().

Refs #5855

2014-04-04 14:53:03 +00:00 by (unknown) af62121

DB IDO: Dump application and command vars.

Refs #5855

2014-04-04 15:32:23 +00:00 by (unknown) 5030bab

Livestatus: Add command custom variables.

Refs #5855

2014-04-04 15:35:56 +00:00 by (unknown) 19434dc

StatusDataWriter: Dump command and application custom variables.

Refs #5855

2014-04-04 15:36:28 +00:00 by (unknown) fb5d0f3

Update documentation with schema extensions.

Refs #5855

2014-04-04 15:45:59 +00:00 by (unknown) 31d54b2

Livestatus: Add application variables to status table.

Refs #5855

2014-04-04 16:41:54 +00:00 by (unknown) fb038b3

Update documentation reflecting current changes.

Refs #5855

2014-04-04 17:01:28 +00:00 by (unknown) f64ba65

Update documentation.

Refs #5855
Refs #5919
Refs #5939

2014-04-04 17:35:47 +00:00 by (unknown) e375f15

Implement global runtime macros as $icinga.<name>$.

Refs #5855

2014-04-04 18:09:23 +00:00 by (unknown) 0a03998

Implement ${host,service}.<name>$ runtime macros.

Refs #5855

2014-04-04 19:36:47 +00:00 by (unknown) aba4f1a

Implement $user.<name>$ runtime macros.

Refs #5855

2014-04-04 19:52:33 +00:00 by (unknown) f13e7b5

Update documentation for custom attribute runtime macros.

Refs #5855

2014-04-04 20:57:56 +00:00 by (unknown) 09cbf18

Implement 'env' dictionary instead of 'export_macros' array.

Revamp notification runtime macros too.

Refs #5855

2014-04-04 21:03:20 +00:00 by (unknown) 31e3377

Drop duplicate attribute.

Refs #5855

2014-04-05 07:24:11 +00:00 by (unknown) 5ccdf01

Fix macros.

Refs #5855

2014-04-05 11:55:29 +00:00 by gbeutner b7cdd1b

Update the auto-discovery scripts.

Refs #5855

2014-04-05 14:26:51 +00:00 by gbeutner 1a2241c

Update documentation.

Refs #5855

2014-04-05 15:13:17 +00:00 by (unknown) e309a5d

Access custom attributes as ${host,service,user}.vars.<name>$.

Refs #5855

2014-04-05 15:45:28 +00:00 by (unknown) 4966dfd

Provide 1.x fallback using GetName() for address macros.

Refs #5855

2014-04-05 15:53:37 +00:00 by (unknown) b9415aa

Fix typo.

Refs #5855

2014-04-05 17:08:46 +00:00 by (unknown) d3b67cf

Fix host custom attribute 'address' as runtime macro.

Refs #5855

2014-04-06 08:45:50 +00:00 by gbeutner 98fba78

Remove the escape_macros attribute.

Refs #5855

Relations:

@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Mar 25, 2014

Updated by tgelf on 2014-03-25 17:07:58 +00:00

  • Subject changed from macros VS custom are redundant to macros VS custom: they are redundant
@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Mar 30, 2014

Updated by mfriedrich on 2014-03-30 17:03:48 +00:00

  • Target Version set to 0.0.10
@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Mar 31, 2014

Updated by mfriedrich on 2014-03-31 19:36:44 +00:00

  • Status changed from New to Assigned
  • Assigned to set to mfriedrich
  • Priority changed from Normal to High
  • drop $_HOST...$ and $_SERVICE...$ macro support (kill the docs with "3.3.2.1 Custom Variables as Runtime Macros" too)
  • drop custom dictionary
  • only use macros (find a better name)
  • dump as
    • status.dat: legacy _ prefix
    • db_ido: table customvariables
    • livestatus: customvariable arrays
@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Apr 1, 2014

Updated by mfriedrich on 2014-04-01 15:10:04 +00:00

  • Subject changed from macros VS custom: they are redundant to custom attributes V2
  • Category set to Configuration

final decision

  • functionality of custom variables and macros in one feature: "custom".
  • dump static configured macros (Host, Service, User, IcingaMacros) into IDO, livestatus, status.dat
  • extra handling for address**,**_url, etc -> not dumped into customvariables
  • support modified attributes for custom variables
  • support for $_{HOST,SERVICE}...$ is removed
  • "magic" runtime macros ($HOSTSTATE$ etc.) are named like $host.state$, $icinga.datetime$
  • $HOSTADDRESS$ with magic host_name if not set is dropped
@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Apr 1, 2014

Updated by mfriedrich on 2014-04-01 15:16:19 +00:00

  • Tracker changed from Bug to Feature
@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Apr 2, 2014

Updated by mfriedrich on 2014-04-02 09:06:50 +00:00

  • name should be "macros", instead of "custom"
@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Apr 2, 2014

Updated by tgelf on 2014-04-02 10:06:27 +00:00

Wasn't this "custom" instead of "macros" so that naming would fit legacy custom vars and database table names? A macro may be seen as "a set of instructions that is represented in an abbreviated format".

@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Apr 2, 2014

Updated by mfriedrich on 2014-04-02 12:27:26 +00:00

imho it's not about fitting legacy 1.x but keeping a naming schema which is reasonable for what these values are for.

"custom" sounds bad, especially in terms of "custom.address" or "custom.address128". and it does not match what it is being used for, being available as runtime macros and apply rules accessor.

I've played a bit with names yesterday evening, and "custom" just doesn't sound right, without having any legacy schema in mind which must be supported for compatibility reasons.

macros provide a key-value tuple, and it's reasonable to call them like so.

@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Apr 2, 2014

Updated by tgelf on 2014-04-02 12:33:29 +00:00

Well, a "macro" is per definition still "a set of instructions that is represented in an abbreviated format"... It's ok to look for a better name than the legacy "custom". "Macro" in my opinion is not an improvement.

Cheers,
Thomas

NB: "address" is imho a NOT a custom attribute but an essential host property

@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Apr 2, 2014

Updated by tgelf on 2014-04-02 12:39:47 +00:00

Other proposal, what about forgetting about the "dictionary" for this custom/macro thingy? The only reason for that "sub-namespace" is the fact that object attribute names are validated and custom attributes are not. Polluting the "object namespace" with custom attributes would in fact obsolete/hinder attribute name validation.

Icinga 1 solves this with a "magic prefix", being the underscore. What do you think about reintroducing such and skipping the dictionary-style macro/customvar definitions? The dollar sign might fit this:

e.g.:

object Host "localhost.localdomain" {
    alias    = "localhost"
    address  = "127.0.0.1"
    $slatime = "24x7"
}

Doesn't this look far better? And it also fits the way of using them later on: $host.slatime$

Best,
Thomas

@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Apr 2, 2014

Updated by mfriedrich on 2014-04-02 15:02:40 +00:00

  • Description updated

dev meeting happened, implementation details updated.

@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Apr 3, 2014

Updated by mfriedrich on 2014-04-03 08:34:53 +00:00

  • Description updated
@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Apr 3, 2014

Updated by mfriedrich on 2014-04-03 09:05:43 +00:00

  • Subject changed from custom attributes V2 to custom attributes (vars) V2
  • Description updated
@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Apr 3, 2014

Updated by mfriedrich on 2014-04-03 09:20:46 +00:00

  • Description updated
@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Apr 4, 2014

Updated by mfriedrich on 2014-04-04 15:10:47 +00:00

cgis don't like command custom variables -> #5940

@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Apr 4, 2014

Updated by mfriedrich on 2014-04-04 19:51:57 +00:00

  • Done % changed from 0 to 50

Done:

  • functionality of custom and macros in one feature
  • dump static configured vars (Host, Service, User, Commands, IcingaVars) into IDO, livestatus, status.dat
  • extra handling for address**,**_url, etc -> not dumped into customvariables
  • support for $_{HOST,SERVICE}...$ is removed
  • "magic" runtime macros ($HOSTSTATE$ etc.) are named like $host.state$, $icinga.datetime$
  • $HOSTADDRESS$ with magic host_name if not set is dropped
  • IcingaMacros -> IcingaVars, global custom attributes
  • 'vars' is a dynamicobject attribute

todo

  • support modified attributes for custom attributes
  • export_macros -> env
  • env is a dictionary, not an array
  • env keys are env variable names
  • macros in env values will be resolved (macro resolver)
  • no more escape_macros; all macros will be escaped if a string is provided
  • rename entire documentation/code (step by step done)
@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Apr 4, 2014

Updated by mfriedrich on 2014-04-04 20:59:35 +00:00

  • Done % changed from 50 to 70

done

  • export_macros -> env
  • env is a dictionary, not an array
  • env keys are env variable names
  • macros in env values will be resolved (macro resolver)

todo

  • support modified attributes for custom attributes
  • no more escape_macros; all macros will be escaped if a string is provided
  • rename entire documentation/code (step by step done)
@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Apr 5, 2014

Updated by mfriedrich on 2014-04-05 15:52:02 +00:00

  • Description updated
  • Done % changed from 70 to 80

**** $HOSTADDRESS$ -> $address$ or $host.vars.address$, provides fallback to host_name just like Icinga 1.x

**** access custom attributes either directly on the object as $address$ or $host.vars.address$ for specific object scope

@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Apr 5, 2014

Updated by mfriedrich on 2014-04-05 16:43:38 +00:00

  • File added test.conf
@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Apr 6, 2014

Updated by mfriedrich on 2014-04-06 12:23:30 +00:00

done

  • no more escape_macros; all macros will be escaped if a string is provided (thx Gunnar)

todo

  • support modified attributes for custom attributes
  • rename entire documentation/code (step by step done)
@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Apr 7, 2014

Updated by mfriedrich on 2014-04-07 12:11:55 +00:00

  • Status changed from Assigned to Closed
  • Done % changed from 80 to 100

modified attributes is made a seperate task in #5956

@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented May 12, 2015

Updated by mfriedrich on 2015-05-12 13:40:08 +00:00

  • Relates set to 9222
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.