On 05/28/2013 04:37 PM, Michael H. Warfield wrote: > On Tue, 2013-05-28 at 15:58 -0400, Stéphane Graber wrote: >> Hey everyone, > >> Thanks for the feedback on my previous autostart proposal. > >> Here's a detailed bullet-point list of what should be done to implement >> autostarting containers in upstream LXC. > > Yes. I concur with virtually (excuse the pun) all of this... > >> Changes to the container config: >> - ADD: lxc.start.auto (integer, 0 = disabled, 1 = enabled, default: 0) > > This default could be conditional. That's how I would incorporate the > Ubuntu paradigm. Anything in /etc/lxc/auto should be default: 1. > >> - ADD: lxc.start.delay (integer, time in second, default: 0) >> - ADD: lxc.start.order (integer, boot order, default: 0) >> - ADD: lxc.group (string, multi-value, default: empty) > > I would also like to see an "lxc.start.disabled" flag, ala OpenVZ. It > has been surprisingly helpful at times at preventing accidents when > working on large systems. If disabled is set to 1 you prohibit starting > unless some sort of override is issued (force parameter or edit the > config). It may not seem like a major thing and there are ways around > it but it has been handy back in my OpenVZ days. Just a suggestion. If > it's too complicated, it's no big thing.
Sure, that's easy enough to add and if that helps people migrate from
OpenVZ that's fine.
I personally never used the disabled property back when I was still
using OpenVZ but I guess on a system shared with multiple sysadmins it
may make sense.
>> - NOTE: lxc.start.auto is an integer as there are plans to implement a
>> third value 2 = last-state.
>
> YES!
>
> I'm attaching some bash pseudo code that implements
> scanning /etc/lxc/auto (autoboot default on) and
> then /var/lib/lxc/*/config (autoboot default off) and then sorting the
> boot order off all enabled containers into a list and emitting that list
> on stdout.
>
> The "last state" is conditionalized based on the existence of a
> file /var/lib/lxc/{CONTAINER}/state file and that file containing the
> line "running". Just a thought.
>
> I did not implement group filtering or boot order filtering (both good
> ideas). The issue of the "delay" parameter is up to the actual startup
> code itself.
>
> This issue of the container name vs the container config is a royal
> PITA. You can't really deterministically say what the container name
> name should be based on the contents of the container config but it
> relates to the LXC /var/lib/lxc subdirectory (but then the Ubuntu
> autoboot paradigm breaks that) but there's nothing in the content of the
> config file that directly relates back to the putative container name
> (NO it's NOT the utsname). Maybe that's something else we should
> address.
>
> It's strictly proof of concept code but it parses my config files and
> does basically the right thing. It's a strawman to show that this isn't
> really all that difficult to implement. Use as you see fit. I've tried
> to comment it with the gotcha's and ideas I see. Code is attached way
> below the jump.
>
> Let me repeat this one last time and make it very clear. This is proof
> of concept code entirely. It is NOT READY FOR PRIME TIME. It is not
> intended to go into the repositories and it has a lot of loose ends
> (which I tried to document in the comments - spaces in path names WILL
> break it!). It's not intended as a patch but just an idea of how "I
> would do it." Your mileage may vary.
>
> Let the rock throwing commence.
>
>> Changes to the system config:
>> - ADD: lxc.autostart.enabled (boolean, default: false)
>> - ADD: lxc.autostart.group (string, multi-value, default: empty)
>
>> Changes to the commands:
>> - lxc-config
>> * Add a "-n <container>" option to query the container config instead
>> of the system config
>>
>> - lxc-list
>> * Allow filtering by group
>> * Allow showing the groups in the fancy view
>>
>> - lxc-start
>> * Add a "-a" option which will match any container that has
>> lxc.start.auto set to 1
>> * Add a "-g <groups>" option which will match any container that has
>> one of the groups in lxc.group matching one of the groups in <groups>
>> (comma separated).
>> * Both options imply -n.
>> * NOTE: When starting containers, sort them by start order
>> (lxc.start.order) and wait until the delay is passed before starting the
>> next one (lxc.start.delay).
>>
>> - lxc-stop
>> * Add a "-a" option which will match any container that has
>> lxc.start.auto set to 1
>> * Add a "-g <groups>" option which will match any container that has
>> one of the groups in lxc.group matching one of the groups in <groups>
>> (comma separated).
>> * Both options imply -n.
>>
>> Examples:
>> - lxc-start -a => Starts all auto-started containers that are in one of
>> the groups listed in lxc.autostart.group (system config). If the system
>> config entry isn't set, start all containers that DO NOT have
>> lxc.start.group set (container config).
>> - lxc-start -g django => Starts all the containers that have django in
>> their lxc.start.group regardless of the autostart flag.
>> - lxc-start -g django -a => Starts all autostarted containers that have
>> django in their lxc.start.group.
>> - lxc-start -g django,graphite -a => Starts all autostarted containers
>> that have either django or graphite in their lxc.start.group
>> - lxc-start -g any => Starts all defined containers regardless of
>> autostart flag or group.
>>
>> - lxc-stop behaves in the exact same way as lxc-start but
>> stopping/shutting down/rebooting the container instead.
>>
>> - lxc-config -n p1 lxc.utsname => returns p1
>> - lxc.config lxc.autostart.enabled => returns true
>
>
> Regards,
> Mike
>
--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
