[07:13] Good morning Juju world! [07:18] Hello everyone! [07:19] I have question about juju and maas 2 [07:19] is Juju already compatible with maas 2? [07:19] I am asking because I have problem bootstrapping maas2 cloud [07:19] I get the following error during the process [07:19] ERROR cmd supercommand.go:458 new environ: Get http://localhost:5240/MAAS/api/1.0/version/: dial tcp 127.0.0.1:5240: getsockopt: connection refused [07:20] It want to use 1.0 API version instead of 2.0 [07:24] I need to add that I use juju 1.2.1 and maas 2.1.3 [07:25] Did anyone had similar problem and solved it? === salmankhan1 is now known as salmankhan === frankban|afk is now known as frankban [10:08] morning folks [10:08] trying to bootstrap some test nonsense [10:09] juju-wait fails when I try and run the sample bundletester -t cs:bundle/wiki-simple [10:09] on the matrix readme [10:09] File "/usr/local/lib/python2.7/dist-packages/juju_wait/__init__.py", line 102, in juju_exe [10:09] if not shutil.which(juju): [10:09] AttributeError: 'module' object has no attribute 'which' [10:09] anyone got any sane ideas? [10:11] magicaltrout: old python version= [10:12] https://docs.python.org/3/library/shutil.html#shutil.which [10:12] "New in version 3.3." [10:17] yeah SimonKLB [10:17] but as I have python 3 installed [10:17] how do I tell juju-wait to use it ?:) [10:18] or more to the point, whats the ubuntu way of making python3 the default, 2.7 still seems to be /usr/bin/python [10:18] which is whats in the shebang [10:19] hmm, looks like the latest version has python3 https://git.launchpad.net/juju-wait/tree/juju_wait/__init__.py [10:19] perhaps the wait plugin needs an update [10:19] oh yeah so it does [10:26] magicaltrout: since it's installed under python2.7 the shebang might not be considered when it's executed [10:26] not sure how the plugins are being run, but if they are not executed standalone then that might be the problem [10:44] thanks SimonKLB I fixed that by just changing the shebang in the plugin [10:44] bundletester is completely hosed on my xenial install though [10:46] bugg@tom-laptop2:~/Projects/charms/layer-gitlab/tests$ juju api-endpoints -e aws1:admin/default [10:46] ERROR unrecognized command: juju api-endpoints [10:46] no idea what its trying to do there but it doesn't like it [10:52] some juju2.0 thing I guess [10:59] magicaltrout: you dont run 2.0? [10:59] i do run 2.0 [10:59] thats why i'm confused [10:59] i just pip2 installed bundletester [10:59] like all the docs say [11:00] have you tried the charmbox docker container? [11:00] but it doesn't like my juju install, which was apt and now snapd to check [11:00] it comes pre-packaged with all the test-stuff [11:00] I've not [11:00] i'll give it a spin [11:01] yea do it! i'm using it all the time when building/testing charms, it's very handy [11:12] much improved it seems SimonKLB [11:12] thanks for the hint [11:12] great np :) [12:15] https://jujucharms.com/q/gitlab so here's another gripe about the charmstore [12:16] I get (kinda) why you'd not want to return gitlab recommended and gitlab non recommended [12:16] but if you have gitlab and gitlab-server [12:16] surely you need to do a wildcard search there by default? people are full on searching blind [12:21] watch last nights video rick_h. Good show, thanks for the demo! :) [12:21] magicaltrout: awesome [13:40] alright [13:40] next testing error cause clearly i'm doing something fully moronic [13:40] why is bundletester trying to test my tests.yaml? [13:45] cory_fu: I think that I've figured out where those timeouts were coming from when running matrix against JaaS. I replaced the asyncio.wait_for calls with simple awaits, and got a traceback: http://paste.ubuntu.com/24466731/ [13:46] cory_fu: it looks like this is happening when we first try to open the socket connection, before we can get at redirect_info, if there's any present. [13:46] cory_fu: I think that a retry might be the most sensible thing to do -- what do you think? [13:46] Interesting. So you think the wait_for for the timeout was somehow masking the connection error? [13:47] cory_fu: yes. I think that we were creating a future, but not checking the exception status on it. [13:48] cory_fu: regardless, I think that we've made python-libjuju much more enthusiastic about raising errors, so I think the reasons for wrapping add_model in a wait_for may have gone away. [13:48] petevg: We don't have access to any future that wait_for creates. There doesn't seem to be any way to check for an exception with wait_for [13:48] cory_fu: ugh. All the more reason not to use it, I think ... [13:49] petevg: The wait_for was there to prevent the connection from hanging indefinitely [13:49] It seems to be the only way to enforce a timeout [13:49] I guess we could roll our own wait_for using create_task and asyncio.sleep [13:50] cory_fu: I think that we may not need it at all -- we've got higher level timeouts wrapped around matrix in the CI tools, and it looks like the native timeouts work pretty well. [13:50] magicaltrout: bugs on charmbox welcome <3 thats my ugly baby :) [13:50] petevg: Hrm. I was thinking for other code that uses libjuju [13:51] charmbox is fine lazyPower many thanks [13:51] cory_fu: this code was in matrix, anyway :-) [13:51] comapred to trying to run tests on my own machine [13:51] petevg: Oh, well fine then [13:51] :) [13:51] cory_fu: python-libjujuj provides that monitor class to get around the cases where you aren't going to hear abotu a timeout. [13:51] magicaltrout: indeed, and it insulates you from dependency bloat running tests, thats why we created it. [13:51] doing revq on your laptop shouldn't leave you with 800+ dependencies installed. [13:52] hehe [14:03] so there seems to be a missing document [14:03] cause i couldn't find this a few months ago and gave up then [14:03] how do you get stuff into the review queue these days? [14:03] actually via the app itself or some other method? [14:04] oh yeah, request a review, conundrum solved [14:07] Start your review by saying "Thanks", no matter what the outcome of the review is going to be. [14:07] If you recognise somebody you've worked with on IRC, thank them. [14:07] lol [14:07] I understand why thats written down, but it does make me chuckle [14:08] magicaltrout: you should totally google 'conundrum etymology' [14:10] * magicaltrout did and is thoroughly confused [14:10] time for biscuits [14:27] magicaltrout: :) [14:27] magicaltrout: mostly it as because of the pendantic thing that i was amused [15:01] need to test config setting in amulet [15:01] can I look at a file on the unit to check settings? [15:04] ah sentry file_contents it seems [15:21] petevg: is there a bundletester flag to disable matrix tests? [15:21] kjackal: there isn't. You can not have matrix installed, though, and it will skip it. [15:21] petevg: I want them but in case I want to exclude them how do i do that? [15:21] --dontrunthecrazyshit [15:22] crazy petevg! Right magicaltrout? [15:22] kjackal: best thing to do right now is to temporarily rename the matrix executable. You should file a ticket against bundletester, though, because it's not that hard to add a flag :-) [15:23] petevg: you said I can do a "pip unsinstall matrix" right? [15:24] kjackal: it depends on what you did to install it in the first place. [15:24] kjackal: I haven't pushed the pypi package, though, so it's unlikely that pip will work. [15:24] kjackal: if you're in cwr-ci, matrix is just part of the image; probably renaming the executable is the way to go. [15:25] Locally, I usually just have it installed in a venv, so it's easy to turn on and off :-) [16:43] cory_fu, kwmonroe: simple but brutal solution for "matrix is too green", which was caused by us not cleaning up a health check after we hit an internal timeout. I'm just yanking the timeout, because we handle that at a higher level in cwr-ci, anyway: https://github.com/juju-solutions/matrix/pull/129 [16:47] petevg: bundletester didn't use the -z, so i think what you've done is reasonable. are there any other callers that i should check (for -z) off the top of your head? [16:47] kwmonroe: I don't think that anybody was using "-z". It had a default timeout internally. [16:48] kwmronoe: ... and that timeout was basically just there for cwr-ci ... which now has its own timeout wrapped around matrix, anyway, complete with model cleanup. [16:53] kwmonroe, cory_fu: The other piece of the puzzle is that I got rid of a major source of hangs by adding that Monitor class to the python-libjuju connection. Matrix should basically never just sit there anymore. (At least, never sit there once it has managed to put its test suite together, which is the part that the timeout covered, anyway.) [16:54] awesome petevg! === frankban is now known as frankban|afk === mup_ is now known as mup === zeus is now known as Guest24728 === mimizone_ is now known as mimizone