lxd: don't inject local snaps on a different arch #1577

Merged
merged 11 commits into from Oct 16, 2017

Conversation

4 participants
Collaborator

kalikiana commented Sep 29, 2017

  • Have you followed the guidelines for contributing?
  • Have you signed the CLA?
  • If this is a bugfix. Have you checked that there is a bug report open for the issue you are trying to fix on bug reports?
  • If this is a new feature. Have you discussed the design on the forum?
  • Have you successfully run ./runtests.sh static?
  • Have you successfully run ./runtests.sh unit?

As brought up in the forum when running the Snapcraft snap with a remote that has a different architecture it will try to push local snaps that can't be installed. For instance, local x86-64 machine, remote Raspberry Pi, which is armhf. In that case we have to install the snaps from the store instead.

@kalikiana kalikiana self-assigned this Sep 29, 2017

-1 because of the test that returns before the assertion.
What about a manual test here?

snapcraft/internal/lxd.py
+ # Switch channel if needed
+ cmd[1] = 'refresh'
+ self._container_run(cmd)
+ return
@elopio

elopio Oct 10, 2017

Member

I think it might be clearer if you split wrap this into a function.

@kalikiana

kalikiana Oct 10, 2017

Collaborator

Good idea actually. I refactored it now, and the file-based install also uses it.

snapcraft/tests/test_lxd.py
'revision': 'x1'},
]
builder = self.make_cleanbuilder()
builder.execute()
+ if hasattr(self, 'cross') and self.cross:
+ return
@elopio

elopio Oct 10, 2017

Member

I don't understand this return. Should it be a skip? A test without assertion is wrong.

@kalikiana

kalikiana Oct 10, 2017

Collaborator

I was thinking the existing assertions didn't make sense... I added different ones now.

@kyrofa

kyrofa Oct 10, 2017

Member

The return still seems to be here, though.

@kalikiana

kalikiana Oct 11, 2017

Collaborator

I figured it's redundant since it's the same in both cases... which in hindsight I should've said in the comment. I added it now anyway.

Makes sense, although I have a few questions.

+ if (self._project_options.target_arch
+ and self._project_options.target_arch != self._server_arch):
+ channel = json['result']['channel']
+ return self._install_snap(name, channel, is_classic=is_classic)
@kyrofa

kyrofa Oct 10, 2017

Member

Okay so we still keep the channel here? Very good.

@sergiusens

sergiusens Oct 16, 2017

Collaborator

eventually this code would need some refactoring, these return statements in the middle will bite us back later

snapcraft/internal/lxd.py
+ self._container_run(['snap', 'install', name] + args)
+ if channel:
+ # Switch channel if needed
+ self._container_run(['snap', 'refresh', name] + args)
@kyrofa

kyrofa Oct 10, 2017

Member

I'm curious why we're doing this in a step separated from the install. I guess I have two questions:

  1. Why not just use --channel=<cannel> in the install?
  2. What do we expect to happen if we refresh to (or install with) a channel when installing with --dangerous?
@kalikiana

kalikiana Oct 11, 2017

Collaborator

I updated the comments in an attempt to clarify: snap install will do nothing if the snap's already installed, even if the channel is different. So the refresh is needed to switch it - it won't do anything if the channel is the same. That's just how the command works...
There is no case where --dangerous is used with a channel - if it's a different arch and we snap install by name plus channel, there's no reasonable way to push an x-revisioned snap then, so we use the regular one. Does this make sense to you?

@kyrofa

kyrofa Oct 11, 2017

Member

Ah, I see-- I actually missed that you were also passing the channel to install. Carry on.

snapcraft/tests/test_lxd.py
'revision': 'x1'},
]
builder = self.make_cleanbuilder()
builder.execute()
+ if hasattr(self, 'cross') and self.cross:
+ return
@elopio

elopio Oct 10, 2017

Member

I don't understand this return. Should it be a skip? A test without assertion is wrong.

@kalikiana

kalikiana Oct 10, 2017

Collaborator

I was thinking the existing assertions didn't make sense... I added different ones now.

@kyrofa

kyrofa Oct 10, 2017

Member

The return still seems to be here, though.

@kalikiana

kalikiana Oct 11, 2017

Collaborator

I figured it's redundant since it's the same in both cases... which in hindsight I should've said in the comment. I added it now anyway.

Collaborator

kalikiana commented Oct 11, 2017

Failing with a false negative any.whl/urllib3/util/retry.py", line 228, in increment total -= 1 TypeError: unsupported operand type(s) for -=: 'Retry' and 'int'

kyrofa approved these changes Oct 11, 2017

Looks good to me @kalikiana, thanks for the fix.

Tests were added

this lxd module seems like refactor ready to allow it to grow further, but this does solve the problem

@sergiusens sergiusens merged commit 5cef613 into snapcore:master Oct 16, 2017

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@sergiusens sergiusens added the bug label Oct 16, 2017

@sergiusens sergiusens added this to the 2.35 milestone Oct 16, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment