Skip to content
This repository has been archived by the owner on May 1, 2024. It is now read-only.

Accept custom LXC configuration #47

Merged
merged 1 commit into from May 1, 2017
Merged

Conversation

elventear
Copy link
Contributor

Provide a way to pass custom LXC parameters for a container, as an advanced setting.

The need for this arose from this bug:

https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1575779

The only way I have to found to work around is to set the container to raw.lxc: lxc.aa_profile=unconfined.

@codecov-io
Copy link

codecov-io commented Mar 20, 2017

Codecov Report

Merging #47 into master will increase coverage by 0.35%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master      #47      +/-   ##
==========================================
+ Coverage   92.12%   92.47%   +0.35%     
==========================================
  Files          42       42              
  Lines         990      997       +7     
==========================================
+ Hits          912      922      +10     
+ Misses         78       75       -3
Impacted Files Coverage Δ
lxdock/conf/schema.py 100% <ø> (ø) ⬆️
lxdock/conf/config.py 100% <100%> (ø) ⬆️
lxdock/container.py 82.99% <100%> (+1.36%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f832ab5...5c9cf01. Read the comment docs.

@ghost
Copy link

ghost commented Mar 20, 2017

Thanks for this PR @elventear, this looks handy. Would you mind adding documentation and tests along with this?

Also, I'm wondering if the s suffix is appropriate in lxc_configs. After all, the lxc command line always refer to config, not configs.

# Get user defined lxc configs
lxc_config = self.options.get('lxc_configs', {}).copy()

# Overwrite any configuration settings with lxcdock defaults
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lxdock, not lxcdock. 😄

@elventear
Copy link
Contributor Author

@hsoft I'd gladly add some tests, I looked into it but this part of the code does not seem to be tested directly in the unit tests. At least the configuration dictionary that gets passed to the client. I would appreciate pointers on how to test this.

Also, no sure if we want to test this via integration too.

The reason I went with lxc_configs is because it allows to pass multiple configuration keys at once. lxc only allows one at a time, and to do several you would need to call it multiple times. But if you would prefer to change it, I am ok naming it lxc_config.

@ellmetha
Copy link
Contributor

Perhaps it would make more sense to have a lxc_configs option if we are considering a list of key/value configuration options. Otherwise I would go with the lxc_config option name.

I think you should add a test demonstrating that it is indeed possible to add a custom lxc option to a container. It could be an integration test. Also, you'll want to add this new option to the LXDock file reference documentation.

@@ -14,6 +15,14 @@
FIXTURE_ROOT = os.path.join(os.path.dirname(__file__), 'fixtures')


@contextlib.contextmanager
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your tests are looking good, thanks! I don't mean to be nitpicking, but I don't think you'll be needing this context manager for your tests. As long as your container names start with lxdock-test- (correct me if I'm wrong @ellmetha ), cleanup will be automatically taken care of at

def _remove_test_containers(client=None):

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@elventear you can use the containername helper to construct your test container names (see:

def containername(self, name):
).

@@ -156,3 +165,14 @@ def test_can_open_a_shell_for_a_specific_container(self, mocked_call, persistent
assert mocked_call.call_count == 1
assert mocked_call.call_args[0][0] == \
'lxc exec {} -- su -m root'.format(persistent_container.lxd_name)

def test_set_lxc_config(self):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that you should've placed this test in integration/test_container.py because it is related to a feature implemented in the Container class. 😉

docs/conf.rst Outdated
@@ -108,6 +108,25 @@ And then use it in your LXDock file as follows:
image: old-ubuntu
mode: local

lxc_configs
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO lxc_config would make more sense because we are considering a dictionary.

@elventear
Copy link
Contributor Author

Sorry for the delay, life has kept me busy and just recently found time to finalize this. I have tried to address all comments. I have rebased and squashed the PR.

Extend the lxcdock configuration schema to allow passing custom LXC
configuration settings.

containers:
- name: test01
test1_key: test1_value
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why this test1_key line?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It slipped through the review. It should be removed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright! Thanks for reminding this to us!

@ellmetha ellmetha merged commit d67470a into lxdock:master May 1, 2017
@ellmetha
Copy link
Contributor

ellmetha commented May 1, 2017

Merged. Thanks @elventear! 😉

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants