Conversation
Upstream has a bug: canonical/pylxd#257 It is fixed in 2.2.5, which is yet to be released. This commit fixes this situation within lxdock.
a9faada
to
9cd833a
Compare
Ubuntu deprecated the PPA and directed people to either use the backports or to use snap. The backports for trusty is too old, thus snap is the only option.
9cd833a
to
bedbd5c
Compare
77a7e9f
to
1218159
Compare
It looks like just one failing test. I am wondering in what way is the backports version of lxd "too old", I am still using the version that came with 16.04 and haven't had any issues. |
I'm still having trouble with the tests on my own machine. Not sure why, but need to check. Also there is a real failure with respect to LXD_DIR, need to figure that out still. |
Ok cool, let me know if you need some help, I will try to get this PR through over the weekend if you can get it passing and it's about time to remove the "this project is not maintained" notice I think :) |
Strangely enough the tests now passes on my local machine (that's without the pylxd2.2.5 update as well), but refuses to pass on CI. |
OK I see what you mean, let me find out what I can do. It seems to be a recursion loop while installing pylxd in the typing library (Python 3 type hinting). I wonder if it's OS related, I wonder how many people still care about running the tests on 14.04, or if it is about time to switch to 16.04 I'll take a copy of your commit into another branch and have a play over the weekend if I get a chance. |
I have no issues switching to 16.04 minimum because 14.04 never really shipped with lxd in apt in the first place, I doubt many people will be using 14.04 with lxd and going through the trouble to set it up. Also Ubuntu 14.04 is going out of support April next year and 18.04 is just around the corner, it's about time to move on from Trusty. Those people still using 14.04 would then have the option to either upgrade to the next LTS, or stick with an old version of lxdock. But first we need to establish that is the actual problem, at the moment it's just a feeling I have. |
I see, your version is probably better than mine and a bit further ahead. I see you are sleeping until the socket comes up, I ran into that too. |
Something is wrong with travis I think. It's been acting up. If you look at https://travis-ci.org/lxdock/lxdock/builds/342664121, the tests ran, but they failed for some reason or another. |
Yeah I have been seeing all sorts of weird things with Travis too, for example "apt get remove lxd" and it says it can't do that because the apt cache is locked, but in another python version if will work fine. Or it fails to pull down the python3.4 tar and says it's corrupt. Not just that but I've seen all sorts of weird errors yesterday as I was trying things, that seemed unrelated. |
Not sure if travis actually has proper xenial support tbh: travis-ci/travis-ci#5821 |
Yeah that is pretty bad, I understand what they are coming from as they have to support a lot of jobs, but it's been 2 years! 2 years since the release of Ubuntu 16.04, and 18.04 is just around the corner. If we can't figure out how to get this past Travis CI, there are always alternatives like Circle CI etc. |
afd6964
to
a294081
Compare
@shuhaowu If you look at issue #106 it seems that another project called conjure-up also run tests with LXD, they are still using Trusty (not Xenial) and the Snap version of LXD so I am going to try that out for a bit as it looks promising. I don't really want to double up on work you've already done in your existing PR but I just want to have a try anyway. He does say it isn't without it's problems though, we might have to occasionally restart a test. They also use a Makefile, we already have a Makefile in the project so could maybe put the build and test related stuff in the Makefile instead of adding a scripts folder, it's just a thought anyway, I don't really mind either way. |
@@ -2,5 +2,4 @@ | |||
|
|||
|
|||
def get_client(): | |||
""" Returns a PyLXD client to be used to orchestrate containers. """ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm just wondering why remove this docstring, it seems a bit unrelated?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo, will fix.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TBH I find this whole file to be somewhat redundant now that we don't need to do something special to get the client, but yeah.
I'll take a look at that again. At this point I'm not sure if you're taking the work of getting the tests running or if I do it. I don't mind either way, but we do have 2 branches up right now.
I personally don't really like having everything in a giant make file and prefer scripts/* as it is a little easier for people to discover the code that way. I personally associate Makefile to only be for builds (and possibly tests) so I would be surprised if the CI setup code is in there, but that's just my opinion. |
Ubuntu deprecated the PPA and directed people to either use the backports or to use snap. Trusty-backport's version is too old. Thus we try to install this via snap, which means this PR requires #113.
Would be interesting/faster to use the docker version of travis to do this, but I'm not quite sure how it would be possible.
Also closes #103