Quoting Stéphane Graber (stgra...@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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxc-devel ------------------------------------------------------------------------------ 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
