[lxc-devel] Rethinking lxc-info a bit

[Serge Hallyn]

Quoting Stéphane Graber (stgraber at ubuntu.com):
> Hello,
> 
> We recently got reports of the recent changes to lxc-info breaking
> existing scripts.

In my own case, I have a host with several containers where a backup
script uses 'lxc-info -n $container -p | awk ...' to get the init pid,
then rsyncs from /proc/$pid/root/$path to /decrypted_backup/$name/$path.
The fix was trivial (once diagnosed), but I don't know how many people
have scripts built into their infrastructure depending on this.

In the past, lxc-info -n www -p would have shown

pid: $pid

I always thought the 'pid:\t' was silly in that case.  OTOH, getting rid
of it now would, again, break 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.

Is there anything which lxc-list would not suffice for?

> This also brought on the next problem.
> 
> == 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.
> 
> == --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).
> 
> 
> 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.
> 
> 
> 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.

Sounds good to me.

Perhaps we should have a transition guide for 1.0?  Where would that
belong?

>  - Have -H also apply to the general formatting, simply printing <key>:
>    <value> when passed.
> 
> 
> 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?
> 
> -- 
> Stéphane Graber
> Ubuntu developer
> http://www.ubuntu.com



> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk

> _______________________________________________
> Lxc-devel mailing list
> Lxc-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel