Bug 1244093 - RFE: virsh: support regex/glob domain start/destroy/etc
Summary: RFE: virsh: support regex/glob domain start/destroy/etc
Status: NEW
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt   
(Show other bugs)
Version: unspecified
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
URL:
Whiteboard:
Keywords: Reopened
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-07-17 05:56 UTC by brent s.
Modified: 2018-07-18 14:41 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-04-10 21:38:36 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description brent s. 2015-07-17 05:56:29 UTC
Description of problem:
More of a feature request, but virsh should support regular expressions (at the VERY least, globbing- though regexes would of course be ideal)- especially for commands referencing a domain. And, even more ideally, extended regular expressions (if needed by the argument parser).


e.g. for a list of domains such as:

> PROD_projectname
> projectname_devel
> projectname_develv1
> projectname_develv2
> ...
> projectname_develv20

and a command such as:

> virsh # start|destroy|undefine|shutdown|etc. --regex 'projectname_devel\(v[1-3,5]\)?'
> virsh # start|destroy|undefine|shutdown|etc. --eregex 'projectname_devel(v[1-3,5])?'

Would perform the operation on the following domains only (and either in parallel or sequentially):

> projectname_devel
> projectname_develv1
> projectname_develv2
> projectname_develv3
> projectname_develv5


And non-matching domains would not have the operation applied to them (e.g. PROD_projectname, projectname_develv6, projectname_develv10, etc.)


Version-Release number of selected component (if applicable):
N/A, but I'm on 1.2.17 (on Arch x86_64)

How reproducible:
N/A

Steps to Reproduce:
N/A

Actual results:
Regexing/globbing/wildcards are not supported.

Expected results:
Implemented via a similar method above.

Additional info:
USE CASES:
- Development vs. staging vs. production, etc.
- Many libvirt implementations use relatively consistent names for enterprise environments as according to their function (e.g. auth_ldap.internal, auth_ldap.external, web_portal, web_bugtracker, etc.).
- For uses of cross-distro/cross-operating system testing platforms for developers
etc.

Comment 1 Cole Robinson 2016-04-10 21:38:36 UTC
IMO the virsh 'shell' is really half baked... we should have never even added commands like pwd/cd/echo since it just motivates more requests like this, and it's never going to be a full featured shell. Really virsh is just a thin wrapper around the libvirt API, anything more than that should probably be in a different tool

Comment 2 brent s. 2016-04-10 23:58:56 UTC
Now, hold on.

After 9 months, the only thing you have to say is comparing irrelevant shell-like commands to the request? I mention nothing about the "shell-like" functions- I mention a use case *specifically centered around starting/stopping groups of domains more easily*. Praytell, what sort of "requests like this" are you referring to? I don't want to run perl in the thing, I just want some way of managing more than one machine at a time with patterns using a tool meant to... manage more than one domain at a time on a virt platform on which there are likely multiple similarly-named domains. I fail to see what's so unreasonable about that, and I'd appreciate further input on what makes it such an unreasonable request.

Do you mean to say it is unreasonable to ask that there were some sort of way of managing a multitude of guests aside from a bash loop? Because *that* strikes me as unreasonable. Would support for grouping be more reasonable? I'm not understanding the logic here.

Comment 3 Jonathan D. 2016-04-11 01:17:34 UTC
I've thought about this kind of thing many times -- I think it'd be a low hanging fruit to make Virsh a lot more friendly.  Acting on groups of domains is a pretty common thing to do, so why not do it?

Comment 4 Cole Robinson 2016-04-11 14:07:40 UTC
apologies, that was hasty and impolite. I did a lot of bug cleanup yesterday and impatience got the better of me. particularly I got confused by the globbing thing after just triaging other bugs regarding virsh's poor shell mode.

I agree that acting on groups of domains is a useful thing to do. The question is whether a) it will ever actually be implemented in virsh, b) it's reasonable to even add to virsh

re: a), a request to this bug tracker isn't any guarantee that any core libvirt devs will work on it. the answer to 'why not do it' is because there's basically an endless pile of work to do, and no one with the combo of time+energy+skills has cared enough to do it yet. unless someone shows up on the list with patches (or pays someone to implement it) this will likely sit indefinitely

re: b) there's an argument to be made that this doesn't even belong in virsh, from a maintenance point of view. virsh has very little 'smarts' besides being a dumb wrapper around the rather large libvirt API. even with very little smarts it clocks in at nearly 30000 lines of C code. to libvirt users, virsh may seem like the sensible place to do it, but many times over the years that someone has suggested adding some smarts to libvirt (like this type of globbing) one or more libvirt devs have said 'we really need a better shell written in a higher level language since adding these types of things to virsh in C is extra painful'. including things like machine readable output, expanded output for various commands, colorized output, better shell mode, higher level commands for specific functional tasks, etc. that's partly what I was trying to get at in my response

In isolation this feature wouldn't be too much work, but if we add it for a few commands it won't be long until we get a request to add it for more/all commands, which is a giant chunk of work. which leads to the 'we need a better tool' argument.

we can leave this open and see if anyone takes it up


Note You need to log in before you can comment on or make changes to this bug.