[lxc-devel] liblxc, lxc-browse()

Francois-Xavier Bourlet francois-xavier.bourlet at dotcloud.com
Mon May 9 20:58:28 UTC 2011


Ok, thank a lots for the help! I am quite busy at this time, but soon
I will provide a clean patch.

Thanks again.

On Mon, May 9, 2011 at 1:48 PM, Daniel Lezcano <daniel.lezcano at free.fr> wrote:
> On 05/07/2011 01:53 AM, Francois-Xavier Bourlet wrote:
>>
>> ok thanks for all the information and example.
>>
>> I believe that rather than trying to iterate over every containers
>> running or not and trying to merge the result we could simply iterate
>> only on running container, or only stopped container (I simplify). So
>> lxc_for_each could simply take a state in parameter, in case we are
>> looking for running containers we only have to look in /proc/net/unix
>> else browsing LXCPATH.
>>
>> But then what about state like booting/stopping etc? Is
>> booting/stopping are "running" in some way? Maybe rather than passing
>> a state to lxc_for_each we can imagine a boolean parameter with the
>> notion of *active* *inactive*, or something with a better name to
>> introduce the fact we are looking for "running" container or simply
>> registered ones?
>>
>> I have to run really ofter lxc_for_each, and adding complexity (and so
>> slowing down the function) is a big concern for me. I dont need a full
>> list of every containers in every state, but only whats is actually
>> present in the cgroup filesystem and what is registered. I would
>> prefer to let the user (the developer using lxc_for_each) decide and
>> implement itself the appropriate complexity.
>
> Ok, as the name of 'volatile' container is already presented in the man
> page, we can add this boolean to lxc_for_each and let the caller of this
> function to handle the duplicate names.
>
> In attachment the routine to look for containers in /proc/net/unix and not
> in LXCPATH/<name>.
>
> So when 'volatile' is set, this routine should be called otherwise the other
> one I sent in a previous email.
>
>
>



-- 
François-Xavier Bourlet




More information about the lxc-devel mailing list