Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add integration test for lp-1920939 #891

Merged

Conversation

TheRealFalcon
Copy link
Member

Proposed Commit Message

Add integration test for lp-1920939

In #856 we added the ability to use partprobe instead of blockdev for
reading partitions. Test that partprobe succeeds where blockdev fails.

Also add a mechanism to our integration tests to allow a callable to be
called between `lxc init` and `lxc start`

Additional Context

Test Steps

Run the test

Checklist:

  • My code follows the process laid out in the documentation
  • I have updated or added any unit tests accordingly
  • I have updated or added any documentation accordingly

In canonical#856 we added the ability to use partprobe instead of blockdev for
reading partitions. Test that partprobe succeeds where blockdev fails.

Also add a mechanism to our integration tests to allow a callable to be
called between `lxc init` and `lxc start`
Copy link
Collaborator

@OddBloke OddBloke left a comment

Choose a reason for hiding this comment

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

This looks good, thanks! I have some nittish comments about kwargs naming/presence inline: given these are important APIs, I think they're worth addressing (but I'll Approve and leave it up to you).

More broadly, I feel like we're starting to really push the sensible limits of kwargs in this part of the codebase. I wonder if introducing a parameter object pattern might help here: we would have a single layer which would translate marks into a Python object, which we'd then pass around: the various layers of our stack would access their parameters (e.g. params.image_id) but pass the same object around. Not for this PR, of course, but I suspect this would be easier to follow but, again, I'll leave it up to you!

@@ -292,7 +292,7 @@ def _mount_source(instance: LXDInstance):
).format(**format_variables)
subp(command.split())

def _perform_launch(self, launch_kwargs):
def _perform_launch(self, launch_kwargs, **kwargs):
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think we can just specify lxd_setup=None here? (Or =lambda _: None if you're feeling spicy, or perhaps id, which is effectively a noop: https://docs.python.org/3/library/functions.html#id)

Copy link
Member Author

Choose a reason for hiding this comment

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

I was hoping to keep the method arguments the same here (Liskov Substitution Principle?) which is why I went with the more generic **kwargs.

(Same comment for the other comment on the other _perform_launch).

@@ -142,12 +142,12 @@ def _get_initial_image(self):
except (ValueError, IndexError):
return image.image_id

def _perform_launch(self, launch_kwargs):
def _perform_launch(self, launch_kwargs, **kwargs):
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't think we need to take **kwargs here: on non-LXD platforms, we should have skipped any tests which are passing lxd_setup before we get to this point.

pycloudlib_instance = self.cloud_instance.launch(**launch_kwargs)
return pycloudlib_instance

def launch(self, user_data=None, launch_kwargs=None,
settings=integration_settings):
settings=integration_settings, **kwargs):
Copy link
Collaborator

Choose a reason for hiding this comment

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

Would naming this in a non-default fashion make it clearer that it's passed through unmodified (e.g. perform_launch_kwargs)? I don't think we want to be conflating other things into this parameter in future.

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm wary of pushing LXD-specific stuff up into the base class. I've always thought of **kwargs (especially when named **kwargs) to serve exactly this purpose when dealing with inheritance. Got some instance-specific info you need to pass but want to keep a consistent API and aren't keen on adding more abstraction? Stuff it into kwargs. I thought that was a well-trodden python paradigm, but I could be wrong.

@TheRealFalcon TheRealFalcon merged commit 4c3c362 into canonical:master May 14, 2021
@TheRealFalcon TheRealFalcon deleted the integration-test-cc-disk branch May 14, 2021 19:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants