You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
edit items specifying their name or a pattern that occurs in the resource name
show items specifying their name or a pattern that occurs in the resource name
Given a highly consistent naming pattern for resources that would be fine to easily select related resources that way.
However the real world is not perfect and sometimes one wants to select resources containing some (more or less) magic string.
Therefore I suggest an enhancement that will allow matching not only based on the resource name, but also on the resource content. While I don't want to propose a specific syntax really, I'm sketching how it could be done:
"crm(...) configure# grep pattern" could list the names of all resources where either the name matches pattern, or where the text representation matches pattern (a possible extension might be "grep xmlpattern" where the XML would be considered instead).
To combine such search result with commands easily, a set of additional commands can be imagined:
"show [all] matchingpattern": Display all resources matching (as described above) pattern. The xml extension would be possible, too (match XML and display XML)
"edit [all] matchingpattern": Edit all resources (in a single editor) matching pattern (as described above). The xml extension would be possible, too (match XML and display XML)
"delete [all] matchingpattern": Deleting all resources matching pattern (as described above) is probably a bad idea (thinking of order and colocation (among others))
filter [all] matchingpattern": ...restrict resources fed into filter...
... (possibly more)
(all is just some syntactic fill-word ("sugar") with no change in semantics, meaning it does not "match everything")
The text was updated successfully, but these errors were encountered:
Another thinkable option would be combining the restriction changed with the new feature, so that the searching would be restricted to any items that were changed (directly or indirectly through dependencies). Unsure about the syntax. A new keyword matching-changed (matchingchanged)?
Yeah, I like crm configure show related:*foo* related:*bar*. But, it stays within "the resource name" makes the usage limited. Example, I may want to show all resources based on ocf:hearbeat:Filesystem.
I hesitate to add yet another subcommand crm configure grep, since the subcommand list under crm configure is pretty long already. With that, I incline to improve the subcommands like "show | edit | delete ..."
In crm shell
configure
context you canedit
items specifying their name or a pattern that occurs in the resource nameshow
items specifying their name or a pattern that occurs in the resource nameGiven a highly consistent naming pattern for resources that would be fine to easily select related resources that way.
However the real world is not perfect and sometimes one wants to select resources containing some (more or less) magic string.
Therefore I suggest an enhancement that will allow matching not only based on the resource name, but also on the resource content. While I don't want to propose a specific syntax really, I'm sketching how it could be done:
"
crm(...) configure# grep
pattern" could list the names of all resources where either the name matches pattern, or where the text representation matches pattern (a possible extension might be "grep xml
pattern" where the XML would be considered instead).To combine such search result with commands easily, a set of additional commands can be imagined:
show
[all
]matching
pattern": Display all resources matching (as described above) pattern. Thexml
extension would be possible, too (match XML and display XML)edit
[all
]matching
pattern": Edit all resources (in a single editor) matching pattern (as described above). Thexml
extension would be possible, too (match XML and display XML)delete
[all
]matching
pattern": Deleting all resources matching pattern (as described above) is probably a bad idea (thinking oforder
andcolocation
(among others))filter
[all
]matching
pattern": ...restrict resources fed intofilter
...(
all
is just some syntactic fill-word ("sugar") with no change in semantics, meaning it does not "match everything")The text was updated successfully, but these errors were encountered: