[lxc-devel] Rethinking lxc-info a bit

[Dwight Engen]

On Wed, 13 Nov 2013 14:41:55 -0500
Stéphane Graber <stgraber at ubuntu.com> wrote:

> Hello,
> 
> We recently got reports of the recent changes to lxc-info breaking
> existing scripts.
> 
> While discusing those issues, I noticed a few points that I think are
> worth discussing and addressing, I'm going to postpone alpha3 until
> that's done as the current state of things would break quite a bunch
> of scripts.
> 
> == confusing -n behaviour ==
> Since Dwight's last change, -n now accepts a regular expression,
> which I believe is the only case where it does. That seems fairly
> unintuitive and redundant with what lxc-list for example provides.
> This also brought on the next problem.

I did this because I wanted to be able to get info on all/some
containers and the previous precedent for that: lxc-wait, even before
I messed with it ;) used regex matching. I think Serge mentioned that
he didn't like regex's there, and would prefer glob fnmatch style
matching. I'm not particularly tied to lxc-info being able to handle
multiples though, so I'm fine if we want to rip that out :)

Also I don't think lxc-ls has a way to list all containers, (ie. both
defined and active) but it would be easy to have it do that now.

> == change of behaviour when one of the filter is passed ==
> In the past, someone could do "lxc-info -n p1 -p" and trivially
> retrieve the PID.
> 
> The new behaviour instead returns:
> Name:           p1
> Pid:            19446
> 
> Even though I didn't ask for the container's name. "pid" was also
> renamed to "Pid", breaking anyone attempting to grep for the entry.

I agree name shouldn't be printed in that case, or any time a specific
thing is asked for. I actually looked for trouble the name changing
might cause, and the only potential case I saw in the shipped lxc
stuff was lxc-test-ubuntu, but it was okay because it called lxc-info
-i and awked out the second column, so renaming "IP" didn't break it.

You are correct though that external scripts might've broken though. If
we're going to say that lxc-info's output is "stable" though so folks
can grep out which parts they want, then maybe we don't need options
like -i and -p ?

> == --state-is option is redundant ==
> The state-is option always seemed a bit odd to me, in fact, it's
> absolutely identical to "lxc-wait -t 0 -n <name> -s <STATE>" and I
> don't really think it has its place in lxc-info. I'd suggest we just
> remove it entirely (yes, that'll break some scripts).

Agree, especially considering it doesn't even seem to work right now.
$? seems to always be 0 for me.

> I'm sorry I didn't think about those problems when reviewing the
> recent changes to lxc-info, but hopefully it's not too late to
> correct some of that.

Sorry for introducing these problems :(

> 
> So my suggestion for lxc-info in LXC 1.0 are:
>  - Only support one container and make -n mandatory, fail with an
> error if the container can't be found.
>  - Drop --state-is entirely and tell anyone who used it to use
> lxc-wait instead.
>  - Only print Name: if none of the filters are passed
>  - Make the combination of -H + a single filter only return that
> value, so that "lxc-info -n p1 -P -H" will just return 19446 without
> any formatting. Recommend doing that to anyone parsing lxc-info's
> output.
>  - Have -H also apply to the general formatting, simply printing
> <key>: <value> when passed.

That all sounds fine to me. 
 
> With those done, there will still be breakage for users of alpha2
> upgrading to alpha3, but that should at least ensure no more surprises
> after that point and a more script friendly command.
> 
> 
> Thoughts?
>