| === freeflying is now known as freeflying_away | ||
| === akikei is now known as akkykg | ||
| === freeflying_away is now known as freeflying | ||
| === freeflying is now known as freeflying_away | ||
| === freeflying_away is now known as freeflying | ||
| hazmat | davecheney, The haproxy charm supports this via explicit configuration as explained in its readme | 04:38 |
|---|---|---|
| hazmat | davecheney, it already extends the interface | 04:38 |
| === freeflying is now known as freeflying_away | ||
| === stub` is now known as stub | ||
| === CyberJacob|Away is now known as CyberJacob | ||
| === freeflying_away is now known as freeflying | ||
| matzie | hi, anyone around to validate my mental model of juju's intentions and capabilities? Fair to describe it as, "like apt-getfor services", orchestrating multiple machines in any cloud (or pseudo-cloud env, like local lxc) and doing whatever is necessary to both provision and configure the individual components of that service and link them together…? | 06:22 |
| axw | matzie: I think everything after "like apt-get for services" is pretty accurate. Whereas apt-get has automatic dependency resolution, in juju you deploy individual services and connect them together explicitly | 06:31 |
| matzie | ok that makes sense | 06:31 |
| matzie | so it's up to individual charms how to do the actual work, right? and there's no single prescribed way of doing that? | 06:32 |
| axw | matzie: right. juju takes care of provisioning machines, opening up ports etc.; installing charms onto a machine; and giving charms a way of connecting to one another | 06:35 |
| axw | how they behave is entirely up to you | 06:35 |
| axw | a charm is just a set of executables (scripts, typically) and some metadata | 06:35 |
| matzie | ok. I've been working heavily with ansible recently, which has an extensible "inventory" concept that can get data from lots of places… wondering whether the output of 'juju status' is generated at each call by effectively working through whatever options are specified (e.g. in environments.yaml) or whether juju has its own 'inventory' under the hood? | 06:39 |
| axw | matzie: juju has a mongo database (implementation detail - could change in the future) that it contains information about machines, services, charms, etc. | 06:41 |
| axw | matzie: I'm not experience with Ansible, but your description makes it sound like it discovers information about the environment | 06:44 |
| axw | <matzie> ok. I've been working heavily with ansible recently, which has an extensible "inventory" concept that can get data from lots of places… wondering whether the output of 'juju status' is generated at each call by effectively working through whatever options are specified (e.g. in environments.yaml) or whether juju has its own 'inventory' under the hood? | 07:01 |
| axw | <axw> matzie: juju has a mongo database (implementation detail - could change in the future) that it contains information about machines, services, charms, etc. | 07:01 |
| axw | <axw> matzie: I'm not experience with Ansible, but your description makes it sound like it discovers information about the environment | 07:01 |
| matzie | thanks for your help earlier axw - I'mtravelling with intermittent connection. | 07:01 |
| axw | nps | 07:01 |
| axw | matzie: (follow on) juju, otoh, knows everything about the environment because it "owns" it; so it has all the knowledge it needs in its mongodb database | 07:02 |
| matzie | it can do - an arbitrary script squirts JSON into it defining the hosts it works with and variables about them. There are scripts that query EC2 for example. | 07:02 |
| axw | ah ok | 07:03 |
| matzie | probably trivial to parse the output of juju status. But pleased to hear that I've basically got the idea behind juju, and it's clearly a game changer. Exploring it further today now my train journey's ending. Thanks again. | 07:04 |
| matzie | ah - that mongodb is on the bootstrapped node? | 07:05 |
| axw | matzie: juju status output is either json or yaml (--format=...) | 07:05 |
| axw | matzie: yes | 07:05 |
| matzie | perfect. Ok, catch you later... | 07:05 |
| matzie | I think I'm affected by https://bugs.launchpad.net/juju-core/+bug/1221868 (EC2/default VPC/ Security groups etc) so switched from using brew to install the client to using go. Now bootstrapping fails with 'invalid series "unknown"' and setting default-series: precise in my env.yaml doesn't help. Any suggestions? | 09:19 |
| matzie | (everything's fine when I use a different Region where I don't have a VPC) | 09:20 |
| matzie | (well - everything *was* fine with the (devel) version I got from brew.) | 09:22 |
| axw | matzie: do you mean you're building juju-core from source? | 09:27 |
| matzie | just followed instructions under the Mac tab on https://juju.ubuntu.com/docs/getting-started.html - first set uses brew, that worked fine, but once I switched to my normal EC2 region, everything stopped working, which led me to that bug. | 09:28 |
| matzie | so I followed the go / bzr route on that same page, which means I now get | 09:28 |
| matzie | $>juju --version | 09:29 |
| matzie | 1.17.0-unknown-amd64 | 09:29 |
| axw | ok | 09:29 |
| matzie | whereas previously I had 'precise' in there. Thought specifying the series might make it work, but no luck so far. | 09:29 |
| axw | matzie: presumably this env hasn't successfully bootstrapped yet, so can you "rm ~/.juju/environments/<envname>.jenv" and try bootstrapping again? | 09:30 |
| matzie | indeed, but I'll try it again to be safe | 09:30 |
| axw | there's some recent changes that cache env.yaml attributes in these environment-specific .jenv files | 09:30 |
| matzie | (and manually deleting the control bucket / instances / sec groups etc too) | 09:31 |
| matzie | pasty: http://paste.pound-python.org/show/mVz6p1u5YdTRAikj7qDc/ | 09:35 |
| matzie | I think I'll just test with a different region (and the earlier version that brew installs) for now to workaround this | 09:37 |
| axw | matzie: the problem, I think, is that trying to bootstrap with unreleased tools won't work on OS X | 09:38 |
| axw | because it can't find released tools, it tries and fails to upload *linux* tools locally | 09:39 |
| matzie | I see. experimented with sync-tools command too, but that expects them to - yes, upload them. | 09:39 |
| matzie | I'll maybe repeat tests from a linux box then. | 09:39 |
| axw | the EC2 bug fix should be in 1.16.0 I think, which should be released in the next day or so | 09:40 |
| matzie | great | 09:40 |
| TheMue | matzie: just heard you've got probs with juju on mac | 09:49 |
| TheMue | matzie: will see how i can help | 09:49 |
| matzie | thanks - no hurry though, can workaround | 09:49 |
| matzie | can use a linux machine too, just need to get a client with the fix for https://bugs.launchpad.net/juju-core/+bug/1221868 - added ppa:juju/devel but that didn't seem to work. | 09:51 |
| matzie | and can also workaround for today (just got a few hours to explore juju) by using a different EC2 region without a VPC | 09:51 |
| TheMue | matzie: ok, just read the problem description so far, will now read the pasting | 09:53 |
| TheMue | matzie: but yes, the "unkown" series is something we have to handle | 09:53 |
| matzie | sure. everything's fine for now just using a different region, and I hear a new release that incorporates this bug fix is imminent, so no problem. Thanks for all the help guys | 09:56 |
| TheMue | matzie: ah, ic, and even if the built tool would have the correct name for the series in your environment it would have been built on os x. so you would have no luck running it on ec2 (or anywhere else) | 09:57 |
| matzie | ah | 09:57 |
| mgz | gnuoy: https://bugs.launchpad.net/juju-core/+bug/1089291 | 09:57 |
| gnuoy | thanks | 09:58 |
| TheMue | matzie: yes, the region (eu-west-1) does not have the tools so far. that's why the system tries to build one locally | 09:59 |
| TheMue | matzie: and so you get a fine os x "unknown" binary which doesn't help you :/ | 09:59 |
| matzie | oh so it's the region that's the problem, not just that I have a VPC in that region? I see, so the bug wasn't the issue at all | 09:59 |
| TheMue | matzie: that's my first finding, but let me investigate further | 10:01 |
| matzie | thx | 10:01 |
| TheMue | matzie: in the moment meeting, will continue after it | 10:02 |
| === CyberJacob is now known as CyberJacob|Away | ||
| === CyberJacob|Away is now known as CyberJacob | ||
| noodles785 | Wow - I hadn't done any charming for a few weeks, just created a new saucy instance, installed juju and tried the local provider (without refreshing on exactly what was required). End result, prompted clearly for exactly what was missing and bootstrapped in a minute painlessly: http://paste.ubuntu.com/6217921/ | 13:13 |
| noodles785 | Well done to whoever has been working to make that painless :-) | 13:14 |
| mgz | jamespage: does ppa:juju-core/golang have arm binaries yet? | 14:06 |
| marcoceppi | noodles785: fyi, `sudo apt-get install juju-local` will fix those local deps :) but I'm glad you had a postive experience | 14:45 |
| === freeflying is now known as freeflying_away | ||
| === freeflying_away is now known as freeflying | ||
| === freeflying is now known as freeflying_away | ||
| gary_poster | jcastro, marcoceppi marked GUI bug 1237605 invalid. They are clickable, but AFAWCT the discourse charm does not declare any ports to expose, so JHuju doesn't tell the GUI about any, so we can't make it a link | 15:34 |
| _mup_ | Bug #1237605: Public URL in the inspector should be clickable <juju-gui:Invalid> <https://launchpad.net/bugs/1237605> | 15:34 |
| jcastro | oh, interesting! | 15:34 |
| jcastro | I didn't know you linked based on what the charm did, that's actually totally awesome | 15:34 |
| marcoceppi | gary_poster: it exposes port 80 via open-port | 15:35 |
| gary_poster | marcoceppi, which hook? | 15:35 |
| jcastro | huh so if a charm exposes some odd port, then the gui would just handle that and show the user something clickable? | 15:36 |
| marcoceppi | gary_poster: https://github.com/marcoceppi/discourse-charm/blob/master/hooks/db-relation-changed | 15:36 |
| marcoceppi | gary_poster: wordpress also does this in the db-relation-changed hook | 15:37 |
| gary_poster | jcastro, currently, if charm exposes 80 or 443, that will make the main address clickable. other ports are listed individually. currently they are also clickable individually, but next release will only do that if connection is tcp, not udp | 15:38 |
| jcastro | that is pretty cool | 15:38 |
| gary_poster | marcoceppi, ah! jcastro I think your image showed that you had not connected a db yet. so no charm bug, but the port will not show up until you connect a db | 15:39 |
| gary_poster | marcoceppi, might be a confusing pattern | 15:39 |
| gary_poster | but that's philosophical, not technical; I'll leave you all to decide | 15:39 |
| jcastro | yeah, then that would make sense because at the time I was going to the page to show that it would not be running because there's no db | 15:39 |
| marcoceppi | gary_poster: well if you don't connect a db, there's nothing to show. That's the idea behind opening port | 15:40 |
| marcoceppi | at least what I would conclude | 15:40 |
| jcastro | right, ok so the right answer then to tell users is ... we tell you the address, and where you will go | 15:40 |
| jcastro | but we don't like it because you're not done yet | 15:40 |
| marcoceppi | jcastro: gary_poster I like that gui does this | 15:40 |
| jcastro | link it I mean | 15:40 |
| marcoceppi | +1 | 15:40 |
| jcastro | yeah, this is actually a good feature, just non obvious | 15:40 |
| gary_poster | marcoceppi, ack. OTOH, if you go to the port and the web page says "hey! I don't have a db!" that would potentially help folks. <shrug> | 15:41 |
| marcoceppi | gary_poster: RTFM ;) | 15:41 |
| gary_poster | marcoceppi, lol, ok :-) | 15:41 |
| marcoceppi | gary_poster: but that's also an interesting idea | 15:41 |
| jcastro | like at the charm level? | 15:41 |
| marcoceppi | gary_poster: actually, that's kind of a cool idea, might be worth discussing as a potential best practice | 15:41 |
| jcastro | "hey don't forget to relate mysql dude." | 15:41 |
| marcoceppi | jcastro: yeah, so open port 80 after install and put a placeholder page that says what to do to get the charm working | 15:42 |
| marcoceppi | jcastro: once you add db, that page goes away | 15:42 |
| jcastro | yeah | 15:42 |
| jcastro | man you know what | 15:42 |
| jcastro | a standard placeholder page, that could link back to the readme, etc. | 15:42 |
| jcastro | for those cases where you just deploy from the store and can't be bothered to read anything | 15:43 |
| jcastro | until it doesn't work ... | 15:43 |
| marcoceppi | jcastro: not only that, what if the standard placeholder embeded the readme and rendered it if RST/MD? | 15:43 |
| gary_poster | this all sounds great to me :-) | 15:43 |
| jcastro | "Sorry, this service isn't up and running yet, you might have missed a relation, here's the readme to get you started" | 15:43 |
| jcastro | gary_poster, I read that as "This sounds great, let me know when you guys are done and I want to be clear this has nothing to do with the GUI." | 15:44 |
| jcastro | :p | 15:44 |
| gary_poster | jcastro, lol | 15:48 |
| gary_poster | the "I want to be clear..." part was not intended, but I'm fine with it. ;-) | 15:49 |
| stub | marcoceppi: I'm looking at amulet to see if I can use it to replace chunks of my test suite. I need to test that my charm copes with the environment being modified (units added, removed etc.). | 16:27 |
| stub | marcoceppi: The deployer seems to let me build and deploy an environment, but not modify it. | 16:27 |
| marcoceppi | stub: yeah, I'm adding removing/adding units outside of deployer working in the Deployment module for amulet, it's on track for 1.1 release | 16:29 |
| stub | marcoceppi: Do you think it will cope if I add or remove units outside of deployer? I'm after the improved waiting | 16:30 |
| stub | oh, that would work for some tests (when I need to remove stuff), but not for the ones where I need to add units. | 16:31 |
| marcoceppi | stub: it should* since it scrapes juju status for actual information | 16:31 |
| marcoceppi | unit modification will work, since all the relations are already modeled via the proxy relation and subordinates | 16:31 |
| marcoceppi | just adding services wont' work since Deployment needs to re-create a new subordinate, etc | 16:32 |
| stub | I'm also loving doing fast runs by reusing machines. I hope I can keep that with juju deployer (maybe just a choice between terminate services and terminate machines in the tear down?) | 16:37 |
| marcoceppi | stub: I've not tested removing stuff outside of deployer, it should theoretically work | 16:38 |
| marcoceppi | stub: I dont' expose any juju-deployer command line options yet, but certainly could | 16:39 |
| marcoceppi | stub: that being said, feedback for changes are more than welcome, let me know what you need to test successfully and I'll be happy to implement (within reason) | 16:39 |
| stub | marcoceppi: https://code.launchpad.net/~stub/charm-helpers/test-harness/+merge/181865 is what I'd like to replace with amulet. I was originally thinking of it going into charm-helpers, but now I think it is better in Amulet. | 16:42 |
| * marcoceppi reads | 16:43 | |
| stub | huh... thought I'd already flagged it as wip, not needs review | 16:44 |
| stub | (I don't care about the API, just being able to construct and destruct a deployment piece by piece and the sentries for real waiting) | 16:48 |
| marcoceppi | stub: right, so you can construct and wait currently, deconstructing will have to happen outside of deployer, and I'd rather use the API for that to avoid calls to subprocess as much as possible | 16:50 |
| marcoceppi | Not sure when, but hopefully around the sprint if not shortly after I should have 1.1 near ready for release | 16:50 |
| stub | ok, I wasn't sure if juju-deployer supported modifying existing deployements, or just bootstrapping new ones. | 16:51 |
| stub | No hurry for me - I have what I need at the moment. Do you think I'm doing the right thing keeping the code just in my charm, rather than landing it in charm-helpers or somewhere? | 16:52 |
| marcoceppi | stub: that's fine, but you're more than welcome to push to charmhelpers. Amulet isn't designed to be the only testing solution out there | 16:53 |
| stub | I don't want us to end up supporting two similar code bases, one of which will likely just be a confusing wrapper around Amulet :) | 16:54 |
| stub | I could add the fixture into Amulet instead when it has the functionality it needs. | 16:55 |
| marcoceppi | stub: I'd be happy to accept that | 17:07 |
| adam_g | getting an error bootstrapping b/c no tools are available for 1.16.. are these being published soon? | 17:56 |
| ahasenack | adam_g: I asked in the mailing list, I don't know why 1.16 was pushed to the *stable* ppa before tools were available | 17:56 |
| ahasenack | same error here, btw | 17:56 |
| adam_g | ahasenack, yea. ugh | 17:56 |
| ahasenack | adam_g: weird, it says "In addition, no tools could be located to upload." | 18:05 |
| ahasenack | adam_g: but juju bootstrap --upload-tools seems to find some | 18:05 |
| ahasenack | maybe it found them somewhere in my trunk checkout | 18:06 |
| adam_g | ahasenack, i just reverted back to 1.15.1 | 18:09 |
| ahasenack | adam_g: oh, you had it | 18:09 |
| ahasenack | I had 1.14 | 18:09 |
| ahasenack | which is gone from the ppa | 18:09 |
| adam_g | ahasenack, i just found an one lying around in /var/cache/apt/archives :) | 18:09 |
| adam_g | *old one | 18:09 |
| ahasenack | hehe | 18:11 |
| ahasenack | I have this bad habit of running apt-get clean after an upgrade | 18:11 |
| === ahasenack is now known as andreas | ||
| jcastro | marcoceppi, hey did you try null/manual provisioning yet? | 19:26 |
| marcoceppi | jcastro: not yet | 19:31 |
| marcoceppi | sinzui: does 1.16.0 fix build issues with brew? | 19:34 |
| marcoceppi | also \o/ 1.16.0 is out | 19:34 |
| sinzui | marcoceppi, yes it does. | 19:34 |
| sinzui | I still have yet to verify it on my own mac before making a pull request | 19:35 |
| sinzui | ^ marcoceppi | 19:35 |
| marcoceppi | sinzui: ah, cool. I know they (brew ppl) were asking me about the 1.14.1 build hiccup | 19:36 |
| sinzui | marcoceppi, The error was bad logic in the juju-core build, When we added support for Windows, we lost support for all *nix. We put that back | 19:37 |
| marcoceppi | sinzui: cool | 19:43 |
| sinzui | marcoceppi, arosales_ I just confirmed that home brew loves juju 1.16.0. It builds for me. I will make a pull request | 20:54 |
| marcoceppi | sinzui: awesome! Thanks | 21:08 |
| arosales | sinzui, good to hear | 21:28 |
| === CyberJacob is now known as CyberJacob|Away | ||
| arosales | sinzui, good to hear. Thanks for submitting it. | 21:37 |
| sinzui | arosales, marcoceppi I see the pull is marked as good https://github.com/mxcl/homebrew/pull/23186 | 21:42 |
| === freeflying_away is now known as freeflying | ||
| zradmin | anyone have a gomaasapi error with 1.16? the juju deployer is telling me it cant find addresses for instances in maas and cannot provision new machines for some reason | 23:53 |
| davecheney | :( | 23:56 |
| davecheney | zradmin: can you give some more output | 23:56 |
| davecheney | maybe there is magic that can be aplied | 23:56 |
| zradmin | davecheney: sure what do you need? currently its just giving me a generic 409 | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!