[lxc-devel] Creating an lxc-config binary

Serge Hallyn serge.hallyn at canonical.com
Tue May 1 14:23:47 UTC 2012


Quoting Matthijs Kooijman (matthijs at stdin.nl):
> Hi folks,
> 
> while writing scripts, I occasionally miss an lxc-config command, that
> can parse (and possibly also write) the lxc config files for me in a
> robust way. Sure, it's an easy format to just grep and sed over (or at
> least it looks like that at first glance), but that's not very
> future-proof or robust.
> 
> So, I looked into implementing such a command, with some help from
> Daniel Baumann on IRC, but ran into some (conceptual) problems along the
> way. So, instead of randomly picking a solution that didn't quite seem
> good, I'll detail my thoughts on the subject and hope others have useful
> ideas.
> 
> Similar to git-config?
> ======================
> First, Daniel proposed to make the command work similar to git-config
> (e.g., borrow command line options and syntax from there, as far as
> applicable). This seems like a good idea to me, to at least be
> consistent with something (for lack of any defined standard AFAIK).

Agreed.

> Script or binary?
> =================
> Then, there is the question if this command should be implemented in a
> script or an actual C binary.
> 
> Using a script is good because:
>  - A script is probably quicker to write
> Using a binary is good because:
>  - Having only a single codebase doing the file parsing prevents
>    (subtle) differences between lxc-config and the other commands.
>  - Having a single codebase is easie to maintain.
> 
> I'd say, using a binary is the better approach here.

Of course you can still re-use the lxc library from a python or
go script.  For instance lp:~frankban/lpsetup/lp-lxc-ip uses
at least get_init_pid() from liblxc.

I agree confile.c should get re-used, so as to avoid requiring
new config file items being introduced in multiple places.

Regarding raw vs processed values, I think it'd be worth introducing
whatever api you need into liblxc to export and import a config.

I.e.

enum {
	LXC_CONFIG_ARCH,
	LXC_CONFIG_PTS,
	...
	LXC_CONSOLE,
	LXC_NUM_CONFIGS
} lxc_configs;

char *lxc_config_names[] = [
	"arch",
	"pts",
	...
	"console",
	NULL
];

int lxc_get_num_configs();
int lxc_config_name_idx(char *config_name);
int lxc_get_num_networks();

enum {
	LXC_NET_VETH,
	LXC_NET_PHYS,
	...
	LXC_NUM_NET_TYPES
} lxc_net_types;

struct lxc_net_config {
	enum lxc_net_types type;
	...
};

struct lxc_net_config *lxc_get_network(int i);
int lxc_update_config(int i, struct lxc_net_config *new);

What I have above is probably stupid for a bunch of reasons, but my
point is just to get some sort of config set/get api into liblxc as
a first class citizen.

Then a program (python script, whatever) should be able to read and
update text config files, and new features added to liblxc should
automatically be usable by the program.

Maybe it should be based on lex+yacc rather than something like I
have above.

-serge




More information about the lxc-devel mailing list