[lxc-devel] [PATCH] add console to lxc api

[Dwight Engen]

On Wed, 29 May 2013 13:52:51 -0400
Stéphane Graber <stgraber at stgraber.org> wrote:

> On 05/29/2013 01:38 PM, Serge Hallyn wrote:
> > Quoting Dwight Engen (dwight.engen at oracle.com):
> >> On Wed, 29 May 2013 09:24:40 -0500
> >> Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
> >>
> >>> Quoting Dwight Engen (dwight.engen at oracle.com):
> >>>> Make lxc_cmd_console() return the fd from the socket connection
> >>>> to the caller. This fd keeps the tty slot allocated until the
> >>>> caller closes it. Returning the fd allows for a long lived
> >>>> process to close the fd and reuse consoles.
> >>>>
> >>>> Add API function for console allocation.
> >>>>
> >>>> Create test program for console API.
> >>>>
> >>>> Signed-off-by: Dwight Engen <dwight.engen at oracle.com>
> >>>
> >>> It looks good and tests fine, so overall
> >>>
> >>> Acked-by: Serge E. Hallyn <serge.hallyn at ubuntu.com>
> >>>
> >>> However, do you think it would be better to call this function
> >>> lxcapi_console_getfd(), and have lxcapi_console() be a higher
> >>> level function which actually runs the lxc_mainloop() the
> >>> way lxc_console() does, either binding to the caller's fds
> >>> 0,1,2, or to 3 passed-in fds?
> >>
> >> Yeah, APIizing this has some questions:
> >>
> >> There currently isn't an lxc_console() that I can see despite there
> >> being a prototype in lxc.h :) Do you mean that lxcapi_console()
> >> essentially be the guts of what is now lxc_console.c? Including
> >> setup of tios, sigwinch handler and mainloop callbacks? I'm fine
> >> with doing that just want to be sure I know what you mean :)
> > 
> > That would be my thought.
> > 
> >> I think essentially this would mean moving those things from
> >> lxc_console.c to console.c. Doing this would make it easy to write
> >> your own lxc-console with only one call, but I'm not sure how
> >> useful that is without being able to override parts (ie. supply
> >> your own mainloop callbacks for instance). How are people going to
> >> want to use/bind to this functionality?
> > 
> > I'm not sure how real people would use this.  For me it would just
> > be
> > 
> > 	sudo python3
> > 	import lxc
> > 	c=lxc.Container('dir1', None)
> > 	c.console()
> 
> That'll definitely be the default behaviour of the binding with a tty
> parameter letting you choose to attach to console or ttyX.

... and we don't expect c.console() to return until the session is done
(ie. ctrl-a-q)? Also I don't think we (currently) have a way of
attaching to the console after the fact, but it would be nice to handle
that.

> > or going to purely do-what-i-mean code:
> > 	x = vte.Terminal()
> > 	c.console(x.stdin, x.stdout, x.stderr)
> 
> I'm a bit less clear about how I'll implement that one. It's likely to
> be a separate function, probably open_console() to be consistent with
> some other python function naming but for the rest, I indeed expect it
> to take the tty and the 3 default fds as arguments.
> 
> > I bet Stéphane has a better idea :)

Thanks Stéphane for the input, I'm also going to look a little at
Virtual Machine Manager to see how their console thing might make use
of this since "Write our own libvirt driver based on lxcapi" is on the
1.0 roadmap.

> > -serge
> > 
> > ------------------------------------------------------------------------------
> > Introducing AppDynamics Lite, a free troubleshooting tool for
> > Java/.NET Get 100% visibility into your production application - at
> > no cost. Code-level diagnostics for performance bottlenecks with
> > <2% overhead Download for free and get started troubleshooting in
> > minutes. http://p.sf.net/sfu/appdyn_d2d_ap1
> > _______________________________________________
> > Lxc-devel mailing list
> > Lxc-devel at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/lxc-devel
> > 
> 
>