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
Comments
Updated by tgelf on 2014-03-25 17:07:58 +00:00
|
Updated by mfriedrich on 2014-03-30 17:03:48 +00:00
|
Updated by mfriedrich on 2014-03-31 19:36:44 +00:00
|
Updated by mfriedrich on 2014-04-01 15:10:04 +00:00
final decision
|
Updated by mfriedrich on 2014-04-01 15:16:19 +00:00
|
Updated by mfriedrich on 2014-04-02 09:06:50 +00:00
|
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". |
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. |
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, NB: "address" is imho a NOT a custom attribute but an essential host property |
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.:
Doesn't this look far better? And it also fits the way of using them later on: Best, |
Updated by mfriedrich on 2014-04-02 15:02:40 +00:00
dev meeting happened, implementation details updated. |
Updated by mfriedrich on 2014-04-03 08:34:53 +00:00
|
Updated by mfriedrich on 2014-04-03 09:05:43 +00:00
|
Updated by mfriedrich on 2014-04-03 09:20:46 +00:00
|
Updated by mfriedrich on 2014-04-04 15:10:47 +00:00 cgis don't like command custom variables -> #5940 |
Updated by mfriedrich on 2014-04-04 19:51:57 +00:00
Done:
todo
|
Updated by mfriedrich on 2014-04-04 20:59:35 +00:00
done
todo
|
Updated by mfriedrich on 2014-04-05 15:52:02 +00:00
**** **** access custom attributes either directly on the object as |
Updated by mfriedrich on 2014-04-05 16:43:38 +00:00
|
Updated by mfriedrich on 2014-04-06 12:23:30 +00:00 done
todo
|
Updated by mfriedrich on 2014-04-07 12:11:55 +00:00
modified attributes is made a seperate task in #5956 |
Updated by mfriedrich on 2015-05-12 13:40:08 +00:00
|
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
Attachments
Changesets
2014-04-03 09:35:25 +00:00 by (unknown) 5c58eb3
2014-04-04 14:35:45 +00:00 by (unknown) 17b87c9
2014-04-04 14:53:03 +00:00 by (unknown) af62121
2014-04-04 15:32:23 +00:00 by (unknown) 5030bab
2014-04-04 15:35:56 +00:00 by (unknown) 19434dc
2014-04-04 15:36:28 +00:00 by (unknown) fb5d0f3
2014-04-04 15:45:59 +00:00 by (unknown) 31d54b2
2014-04-04 16:41:54 +00:00 by (unknown) fb038b3
2014-04-04 17:01:28 +00:00 by (unknown) f64ba65
2014-04-04 17:35:47 +00:00 by (unknown) e375f15
2014-04-04 18:09:23 +00:00 by (unknown) 0a03998
2014-04-04 19:36:47 +00:00 by (unknown) aba4f1a
2014-04-04 19:52:33 +00:00 by (unknown) f13e7b5
2014-04-04 20:57:56 +00:00 by (unknown) 09cbf18
2014-04-04 21:03:20 +00:00 by (unknown) 31e3377
2014-04-05 07:24:11 +00:00 by (unknown) 5ccdf01
2014-04-05 11:55:29 +00:00 by gbeutner b7cdd1b
2014-04-05 14:26:51 +00:00 by gbeutner 1a2241c
2014-04-05 15:13:17 +00:00 by (unknown) e309a5d
2014-04-05 15:45:28 +00:00 by (unknown) 4966dfd
2014-04-05 15:53:37 +00:00 by (unknown) b9415aa
2014-04-05 17:08:46 +00:00 by (unknown) d3b67cf
2014-04-06 08:45:50 +00:00 by gbeutner 98fba78
Relations:
The text was updated successfully, but these errors were encountered: