| === JoshStrobl is now known as JoshStrobl|ZZZ | ||
| === JoshStrobl|ZZZ is now known as JoshStrobl | ||
| blahdeblah | hi all - I'm trying to get my local provider working with juju and getting an unusual error: http://pastebin.ubuntu.com/12978319/ | 09:35 |
|---|---|---|
| blahdeblah | Google seems to be remarkably silent on this error message - any clues? | 09:36 |
| Odd_Bloke | lazypower: Hey, so my problem with the Jenkins charm is actually more interesting; OpenJDK 7 has a bug where it segfaults if the fully-qualified hostname is greater than 64 characters. | 09:39 |
| Odd_Bloke | lazypower: On GCE Juju, the fully-qualified hostname is 'juju-<UUID>-machine-<machine number>.c.<project name>.internal', which is almost always going to be over that. | 09:40 |
| blahdeblah | hmmm - OK. I manually created lxcbr0 and manually gave it the IP address 10.0.3.1/24 and it seems happy-ish. | 09:42 |
| Odd_Bloke | blahdeblah: On what release? | 09:42 |
| blahdeblah | laptop is wily; juju stable ppa; juju 1.24.7 | 09:43 |
| Odd_Bloke | blahdeblah: OK, there are known issues with lxc in wily release; what version of lxc do you have installed? | 09:43 |
| blahdeblah | the one that comes with wily, whatever that is | 09:44 |
| * blahdeblah checks version | 09:44 | |
| blahdeblah | 1.1.4-0ubuntu1.1 | 09:44 |
| Odd_Bloke | blahdeblah: Right, so you should have the fix; is the lxc service running? | 09:45 |
| blahdeblah | I ran service lxc restart earlier; it didn't seem to start anything called lxc, though... | 09:46 |
| blahdeblah | However, creating the bridge & IP manually seems to have enabled it to bootstrap | 09:46 |
| blahdeblah | Trying a juju deploy cs:ubuntu now | 09:46 |
| Odd_Bloke | blahdeblah: What does `service lxc-net status` show? | 09:47 |
| blahdeblah | Odd_Bloke: http://pastebin.ubuntu.com/12978355/ | 09:48 |
| blahdeblah | Getting lots of this in juju debug-log output: machine-0: 2015-10-27 09:48:49 WARNING juju.apiserver.client status.go:653 error fetching public address: "public no address" | 09:49 |
| Odd_Bloke | Interesting, I get http://paste.ubuntu.com/12978367/ | 09:51 |
| blahdeblah | I haven't rebooted since I installed lxc; is that necessary/recommended? | 09:52 |
| Odd_Bloke | blahdeblah: I don't think so. | 09:52 |
| blahdeblah | My feeling is that whatever it tried to do on install with networking setup failed | 09:52 |
| blahdeblah | Nothing much seems to be happening with my cs:ubuntu deploy; just sitting there with status "Waiting for agent initialization to finish" | 09:53 |
| Odd_Bloke | blahdeblah: Do you have anything that looks relevant in /etc/default/lxc-net? | 09:54 |
| Odd_Bloke | blahdeblah: That step can take a while. | 09:54 |
| blahdeblah | It has USE_LXC_BRIDGE="false" - not sure why; is that the default? | 09:54 |
| Odd_Bloke | blahdeblah: I'm not sure, but I think that's what you need to adjust. | 09:55 |
| blahdeblah | That's my thinking, too. :-) | 09:55 |
| blahdeblah | status looks a bit different now :-) | 09:56 |
| * blahdeblah rebootstraps & redeploys cs:ubuntu | 09:57 | |
| blahdeblah | still much the same result, even though it got a DHCP address and added a lxcbr0 port: Oct 27 19:58:33 peleg kernel: [44383.575124] lxcbr0: port 1(vethR77403) entered forwarding state | 10:00 |
| Odd_Bloke | blahdeblah: "much the same result" being? | 10:00 |
| blahdeblah | lots of machine-0: 2015-10-27 09:59:14 WARNING juju.apiserver.client status.go:653 error fetching public address: "public no address" | 10:00 |
| blahdeblah | Oooh - hang on; firewall denies on lxcbr0; that's progress | 10:00 |
| * blahdeblah fixes that | 10:00 | |
| blahdeblah | \o/ that's better | 10:02 |
| blahdeblah | thanks for the help, Odd_Bloke | 10:02 |
| blahdeblah | juju ssh ubuntu/0 working | 10:02 |
| Odd_Bloke | blahdeblah: Happy to help. :) | 10:02 |
| blahdeblah | I don't suppose there's a way to get them using a different mirror by default? | 10:03 |
| blahdeblah | .au is a bit of a bandwidth backwater... | 10:03 |
| Odd_Bloke | blahdeblah: There are ways to do it if you're creating a container from the command-line; I'll have to defer to someone Juju specific for Juju-started containers. | 10:05 |
| blahdeblah | Looks like it: https://jujucharms.com/docs/stable/config-general | 10:05 |
| Odd_Bloke | blahdeblah: Yeah, that looks promising. :) | 10:05 |
| ezobn | Hi All ;-) Trying to upgrade to Liberty OpenStack release via Juju charms ;-) all works good, instead of nova-manage db sync - says that I have to run `nova-manage db migrate_flavor_data' first. But there no such option in nova-manage :-( | 10:07 |
| Odd_Bloke | jamespage: ^ Sounds like one for you. | 10:07 |
| blahdeblah | thanks very much for the help, Odd_Bloke | 10:07 |
| Odd_Bloke | ezobn: It is the OpenStack Summit ATM, so helpful people are less likely to be on IRC. :) | 10:08 |
| Odd_Bloke | blahdeblah: :) | 10:08 |
| ezobn | Odd_Bloke: sure, but why not to try ? ;-) | 10:09 |
| blahdeblah | sweet - that apt-mirror seems to work | 10:09 |
| Odd_Bloke | lazypower: I've filed https://bugs.launchpad.net/charms/+source/jenkins/+bug/1510450 for the problem. | 10:10 |
| mup | Bug #1510450: Cannot install in GCE <jenkins (Juju Charms Collection):New> <https://launchpad.net/bugs/1510450> | 10:11 |
| === Makyo is now known as Guest72537 | ||
| === marlinc_ is now known as marlinc | ||
| gennadiy | hi all, i have question about expose service in bundle. i added expose: true to my bundle but when i import this bundle to juju-gui my services are not exposed | 14:25 |
| gennadiy | http://bazaar.launchpad.net/~tads2015dataart/charms/bundles/tads2015-demo/bundle/view/head:/bundles.yaml | 14:25 |
| === Guest72537 is now known as Makyo | ||
| Icey | is it possible to tell Juju to not spread instances over different AZs with AWS? | 16:11 |
| pmatulis | Icey: there is a way to target specific AZs | 16:13 |
| pmatulis | juju machine add zone=us-east-1a | 16:14 |
| marcoceppi | Icey: any reason you'd not want resilliance and best practices? | 16:17 |
| Icey | ceph | 16:18 |
| Icey | it tends to expect low latency (within one DC) rather than spread out over datacenters many (but not region) miles apart | 16:18 |
| Icey | we can discuss more later, i'm off to lunch | 16:19 |
| bbcmicrocomputer | marcoceppi: hey, I have multiple new charms that I want to write tests for. What are the best practices for using 'juju test' with amulet framework and being able to write tests that deploy/relate these charms when they're not currently in the charm store? Is there an environment variable that can be used which determines whether a charm is sourced from local disk or the charm store depending on current test environment? | 16:33 |
| bbcmicrocomputer | I'd like to avoid hacking the actual test code to do this | 16:34 |
| bbcmicrocomputer | I couldn't find anything in the docs | 16:34 |
| jose | kwmonroe: ping | 18:04 |
| lazypower | bbcmicrocomputer: really good questions. with a few answers | 18:06 |
| kwmonroe | yo jose! | 18:07 |
| lazypower | bbcmicrocomputer 1) there's a project we used called 'bundletester' - and this is by far the defacto method to use when testing your charms. http://github.com/juju-solutions/bundletester for more information. this is pip installable via `pip install bundletester` - i highly recommend using a venv to islolate. | 18:07 |
| kwmonroe | jose: i see you're a lawyer now ;) | 18:07 |
| lazypower | bbcmicrocomputer: furthermore, to test local charms, you can `export JUJU_REPOSITORY=/path/to/charmdir` - so long as that points at your dirtree root for the charm repository. EG if your charms are in $HOME/charms, thats your JUJU_REPOSITORY, preserving the trusty/mysql dirpath for the strings you'll place in a bundle. Additionally, this lends itself nicely to amulet | 18:08 |
| lazypower | bbcmicrocomputer: if you're not using a bundle to define a deployment leveraging multiple services, you can test each charm in isolation by declaring it inline on the deployment, for example, d = amulet.deployment, d.add('mycharm') -- assuming mycharm is your charm name -- amulet will sense you're testing the charm that you're currently in, and thus deploy local:trusty/mycharm - so you're executing off the local charm. | 18:10 |
| jose | kwmonroe: lol, was that what you were asking for? I kinda tried to get an answer but not sure if that was what you were looking for | 18:11 |
| kwmonroe | jose: that was a mighty fine answer -- charm copyright covers charm source and not payloads. the followup question about license requirements for redistributing binary packages on an external host is still a bit hazy, but that's not a typical charm author issue. i think i'll call out the licenses in the readme like you suggested, and then maybe dig into requirements for re-distribution for repo maintainers. | 18:13 |
| jose | kwmonroe: that's what the IBM people did for their charms, and they added a config option called 'accept-software-license' or something similar that defaulted to no. if people wanted to install, they would have to set that config option to 'yes' and only then it'd install | 18:14 |
| jose | and that could get even easier by setting an error message on status saying 'you need to accept the license, see readme' | 18:14 |
| lazypower | cmars - I'm pretty sure this is getting resolved with an incoming release? | 18:16 |
| lazypower | cmars - terms will settle a lot of this, out of band of the charm code correct? ^ | 18:16 |
| lazypower | i'm calling attention to this so we dont waste cycles implementing something thats going to have to be gutted in a future rev of juju | 18:16 |
| kwmonroe | yeah jose, i could go that route.. but ibm had their own special license. my stuff is gpl licensed. if we used a config option every time somebody needed to accept the gpl, we'd have a bunch of lameness :) i'm cool with a callout in the readme and think that makes the most sense. thanks! | 18:16 |
| lazypower | AIUI its on the schedule for 1.26 | 18:16 |
| jose | hehe | 18:17 |
| lazypower | or perhaps after 1.26.... | 18:34 |
| bbcmicrocomputer | lazypower: thanks for the detailed answers! | 18:49 |
| lazypower | bbcmicrocomputer np, sorry it wasn't in the docs, we'll be cycling over them in the next week - bugs for that would be quite helpful | 18:49 |
| lazypower | github.com/juju/docs - anything you find missing, misleading, et-al will help us nail down a tighter story for docs when we do the planning for the update | 18:50 |
| lazypower | starting w/ the getting started guide, so there's plenty to pick from :) | 18:50 |
| bbcmicrocomputer | lazypower: nice | 18:51 |
| lazypower | bbcmicrocomputer have you taken a look at charming 2.0 these days? | 18:52 |
| lazypower | using layers + reactive pattern to write skinny charms leveraging existing work to not only assemble your charm logic, but to plug into other services using interfaces written by others? | 18:52 |
| bbcmicrocomputer | lazypower: I read the docs/presentations but not played around with it yet | 18:53 |
| lazypower | bbcmicrocomputer : i'll have a developer perspective video for next week from stokachu and his contribution of the nodejs layer | 18:54 |
| lazypower | informative video to be sure, if you'r eon the mailing list - it will be syndicated there | 18:54 |
| bbcmicrocomputer | nice | 18:54 |
| bbcmicrocomputer | I'll look out for it | 18:54 |
| === natefinch is now known as natefinch-afk | ||
| bbcmicrocomputer | lazypower: I think I'm a little confused, as Juju docs seem to say you should never code 'juju deploy local:mycharm', only 'juju deploy mycharm' - test runner will determine where to fetch the real charm (presumably from some environment variable or switch), but then amulet seems to have lots of logic for accepting different charm urls | 19:56 |
| bbcmicrocomputer | so my main question is where does the logic live for selecting whether we're testing local disk charms on this test or we're pulling from the charm store because the charm store CI is running? | 19:57 |
| bbcmicrocomputer | is it something the charm author is meant to bake into their tests, is it something only the test runner should know about? | 19:59 |
| lazypower | bbcmicrocomputer: nah. just write tests for 'mycharm' | 20:05 |
| lazypower | the fact you export JUJU_REPOSITORY will satisfy it finding th elocal charm. if you implicitly need to test the CS version of a charm, say an extant dependency. 1 of 2 this has occurred | 20:06 |
| lazypower | 1) you should be placing your tests in a bundle | 20:06 |
| lazypower | 2) You add that in your test d.deploy('cs:trusty/mysql') which will always pull the latest mysql charm, and add it to your testing bundle. | 20:06 |
| lazypower | but if you're doing that level of testing in amulet, say its a requirement, you really should have a bundle to deploy the suite of charms, and embed the tests there. then in which case, JUJU_REPOSITORY again to the rescue | 20:07 |
| bbcmicrocomputer | lazypower: cool, thanks for the clarification | 20:12 |
| lazypower | NP, there are edge cases in there i'm sure | 20:12 |
| lazypower | and if you run into them feel free to ping bbcmicrocomputer | 20:12 |
| bbcmicrocomputer | thanks | 20:12 |
| bbcmicrocomputer | lazypower: sorry, being a pita.. | 20:25 |
| bbcmicrocomputer | lazypower: a grep over bundletester and amulet for 'JUJU_REPOSITORY' doesn't seem to reveal any special logic that takes place unless I specify 'local:mycharm' as opposed to 'mycharm' | 20:26 |
| bbcmicrocomputer | it's possible I've misunderstood everything at this stage | 20:26 |
| bbcmicrocomputer | I guess this also raises another Q that if I have new charms, where each's tests deploy the others to relate, how does that go into the Charm Store in stages without charm urls being incomplete? | 20:30 |
| bbcmicrocomputer | for charm A to pass its tests (and be reviewed successfully), how does the test runner know to pull charm B (yet in the Charm Store) from my local LP account (without me explicitly saying - which I shouldn't :) ) | 20:31 |
| bbcmicrocomputer | like I say, I may possibly have completely misunderstood something key | 20:32 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!