| blairbo | btw thanks for your help | 00:00 |
|---|---|---|
| blairbo | $ ls /var/log/upstart | 00:02 |
| blairbo | console-setup.log module-init-tools.log rsyslog.log | 00:02 |
| blairbo | container-detect.log mongodb.log ureadahead.log | 00:02 |
| blairbo | dbus.log network-interface-eth2.log ureadahead-other.log | 00:02 |
| blairbo | juju-db-juju-local.log procps-static-network-up.log | 00:02 |
| blairbo | lxc-net.log procps-virtual-filesystems.log | 00:02 |
| === andreas__ is now known as ahasenack | ||
| blairbo | sorry should have pastebin'd that.. my bad. http://pastebin.com/Emu7v3Z8 | 00:13 |
| marcoceppi | blairbo: weird. `juju destroy-environment` and re-bootstrap | 00:20 |
| marcoceppi | blairbo: see if that helps | 00:20 |
| blairbo | marcoceppi: will do. stand by | 00:20 |
| blairbo | marcoceppi: result - http://pastebin.com/Eu1D5qcv | 00:23 |
| marcoceppi | blairbo: how does juju status look now? | 00:24 |
| blairbo | marcoceppi: status - http://pastebin.com/hw4GJc9b | 00:24 |
| marcoceppi | blairbo: looks better, try deploying something now | 00:25 |
| blairbo | marcoceppi: which is how it looked before I deployed mysql last time.. let's give this a shot.. | 00:25 |
| marcoceppi | blairbo: what's the deploy command you're using? | 00:26 |
| blairbo | marcoceppi: juju deploy wordpress (local is the default environment in my environments.yaml file) | 00:29 |
| marcoceppi | blairbo: k | 00:30 |
| blairbo | marcoceppi: then "juju deploy mysql", then | 00:30 |
| blairbo | "juju add-relation mysql wordpress" | 00:30 |
| marcoceppi | blairbo: how's that going now? getting and oddness in juju status? | 00:31 |
| marcoceppi | blairbo: also, what does `juju version` say? | 00:32 |
| blairbo | marcoceppi: same oddness - http://pastebin.com/hw4GJc9b version is 1.14.0-precise-amd64 | 00:33 |
| marcoceppi | blairbo: old link | 00:34 |
| === defunctzombie is now known as defunctzombie_zz | ||
| blairbo | marcoceppi: oops - http://pastebin.com/8p7Z5is9 | 00:37 |
| marcoceppi | blairbo: this is a bug then, I'm still using 1.13.3 so I can't confirm atm | 00:38 |
| blairbo | marcoceppi: I am not opposed to starting from bare metal again. Should I revert? | 00:38 |
| marcoceppi | blairbo: you could try 1.13.3 | 00:41 |
| blairbo | marcoceppi: are you on precise? | 00:42 |
| marcoceppi | blairbo: no, raring on this machine | 00:42 |
| === defunctzombie_zz is now known as defunctzombie | ||
| blairbo | marcoceppi: ok. I'll give that a shot. I'm also having a hard time with my 2nd and 3rd NICs on precise - they refuse to pull an IPV4 address from DHCP. | 00:43 |
| === freeflying is now known as freeflying_away | ||
| sarnold | blairbo: what's your /etc/network/interfaces look like? | 00:47 |
| sarnold | blairbo: (I think the juju lxc provider requires all lxc guests to be on the same NATted bridge, so those extra nics may not even be useful to you as you're intending to use them..) | 00:48 |
| blairbo | sarnold: they're not configured for auto intentionally - I am trying to get them up manually to no avail. http://pastebin.com/RwJGPfp4 | 00:54 |
| sarnold | blairbo: Wouldn't you want some "iface eth1 inet dhcp" and "iface eth0 inet dhcp" lines in there, even without the 'auto' bit, so 'ifup eth0' or 'ifdown eth1' works? | 00:55 |
| blairbo | sarnold: yes, that would make life easier | 00:55 |
| sarnold | blairbo: of course if you just leave them out entirely, I'd hope you could run 'ifconfig eth0 up ; dhclient -i eth0 -whatever-else-is-needed...' | 00:55 |
| blairbo | sarnold | 00:59 |
| blairbo | sarnold: sorry, itchy pinky finger - no love on the dhclient as before | 01:00 |
| sarnold | blairbo: aww. :/ | 01:00 |
| blairbo | sarnold: did the same thing to me during the OS install | 01:01 |
| blairbo | sarnold: i'm thinking it may be a 32/64 bit issue with the hardware, as they are on PCI slots | 01:02 |
| blairbo | pardon the OT | 01:02 |
| sarnold | blairbo: hrm, seems unlikely to me, 64 bit support isn't exactly new.. :) hehe -- maybe check ethtool output for those other nics? maybe check the dhcp server logs if you can get to those? | 01:05 |
| === freeflying_away is now known as freeflying | ||
| === thumper-gym is now known as thumper | ||
| === defunctzombie is now known as defunctzombie_zz | ||
| === defunctzombie_zz is now known as defunctzombie | ||
| === freeflying is now known as freeflying_away | ||
| === thumper is now known as thumper-afk | ||
| === tasdomas_afk is now known as tasdomas | ||
| === freeflying_away is now known as freeflying | ||
| === Guest81313|Away is now known as CyberJacob | ||
| === defunctzombie is now known as defunctzombie_zz | ||
| === defunctzombie_zz is now known as defunctzombie | ||
| === defunctzombie is now known as defunctzombie_zz | ||
| === thumper-afk is now known as thumper | ||
| === freeflying is now known as freeflying_away | ||
| === freeflying_away is now known as freeflying | ||
| === freeflying is now known as freeflying_away | ||
| === freeflying_away is now known as freeflying | ||
| === kentb-out is now known as kentb | ||
| === tasdomas is now known as tasdomas_afk | ||
| === defunctzombie_zz is now known as defunctzombie | ||
| kentb | is there a way to cap constraints in juju, like for CPU memory, etc? I know that it'll work off minimums, but, wasn't sure if there was a way to say "don't pick this machine if it's got more than this amount of memory" for example. | 17:44 |
| === defunctzombie is now known as defunctzombie_zz | ||
| === defunctzombie_zz is now known as defunctzombie | ||
| === defunctzombie is now known as defunctzombie_zz | ||
| sidnei | kentb: it will start from the minimum in constraints and try to pick the smallest one that satisfies the constraints | 17:56 |
| kentb | ok | 17:56 |
| sidnei | kentb: note that there were bugs at some point that caused it to pick a random number of cpus for example if you only informed mem constraint | 17:57 |
| sidnei | kentb: the 1.14 release has the fixes | 17:57 |
| kentb | sidnei: ah ok...all the more reason to upgrade :) Thanks | 17:57 |
| sidnei | the actual bug was for openstack, where it only sorted by mem and then picked whatever was at the top | 17:58 |
| kentb | ok. that also explains things, too | 17:58 |
| ZonkedZebra | So I'm writing a charm and using juju-log extensively. Where does one see that output. debug-log shows the hook is being called but I don't see the messages passed to juju-log anywhere | 18:04 |
| kentb | one more question...for juju-bootstrap I believe you have to do a sync-tools prior to bootstrapping. If you are stuck behind a firewall that makes sync-tools difficult, is --upload-tools acceptable, especially if all you're doing is testing / non-production work? | 18:06 |
| === defunctzombie_zz is now known as defunctzombie | ||
| marcoceppi | ZonkedZebra: that goes in /var/log/juju/unit-*.log on the machine | 18:16 |
| marcoceppi | kentb: --upload-tools is meant only for dev, maybe fwereade could explain more about --upload-tools | 18:17 |
| marcoceppi | kentb: I'm still confused by --upload-tools and sync-tools, other than we recommend sync-tools | 18:17 |
| kentb | marcoceppi: ok, yeah, I figured sync-tools is what is strongly advised to use. That said, is there a way to get the tools source from elswhere, put them on your firewalled-off machine and point juju locally to those tools? | 18:19 |
| marcoceppi | kentb: --upload-tools will build the tools locally on your machine, so you need a go build environment, IIRC, to use it | 18:20 |
| marcoceppi | kentb: but it could be an alternative | 18:20 |
| kentb | marcoceppi: ok got it | 18:20 |
| ZonkedZebra | marcoceppi: I see things like "juju.worker.uniter modes.go:109 awaiting error resolution for "config-changed" hook" but i don't see any of the actual messages I'm passing to juju-log | 18:38 |
| jaywink | been wondering about juju logging too, on bootstrap phase. I see in the code (running development version) lots of logging calls in various parts but no idea where the log goes.. any ideas? :) | 18:43 |
| ZonkedZebra | /var/log/juju on each node has some log files. as well as juju debug-log seems to collect some log data from across all nodes | 18:46 |
| jaywink | ZonkedZebra, don't even have /var/log/juju but I haven't bootstrapped yet :) | 19:09 |
| jaywink | there are logging calls in the bootstrap phase too | 19:10 |
| ZonkedZebra | adding -v to any command should up the console logging but enough to figure out whats going on | 19:10 |
| kurt_ | marcoceppi: have you messed with getting the vnc console set up on openstack-dashboard, or no of someone who successfully has? | 19:14 |
| marcoceppi | kurt_: no idea | 19:18 |
| marcoceppi | ZonkedZebra: you don't see any juju-log data? | 19:18 |
| ZonkedZebra | marcoceppi: I see some, thinks that error seem to log the error message, but only if I'm currently debug-hooks | 19:19 |
| marcoceppi | ZonkedZebra: if you're running debug-hooks and your hooks are in bash, just add `set -ex` to the top of the script | 19:19 |
| marcoceppi | ZonkedZebra: it'll be super verbose | 19:20 |
| jaywink | ZonkedZebra, oh thanks, didn't know about -v, don't see any mention of it with "juju help" :P | 19:39 |
| marcoceppi | jaywink: if you run juju help bootstrap you should see all the options | 19:40 |
| marcoceppi | jaywink: bah, it's no there. -v and --debug are two additional options you can use | 19:40 |
| marcoceppi | that are global, but not in any of the command line help files | 19:40 |
| jaywink | marcoceppi tnx a lot more verbose now :) | 19:41 |
| ZonkedZebra | marcoceppi: thanks. Any experience or advice on deployment ssh keys (using git) | 19:49 |
| marcoceppi | ZonkedZebra: how so? Like placing SSH keys on a service/unit | 19:49 |
| ZonkedZebra | yep, bust way to provide a key to all nodes and to be used with the git clone/pull | 19:50 |
| marcoceppi | ZonkedZebra: via a configuration option | 19:51 |
| marcoceppi | juju set <service> deploy-key=`cat ~/.ssh/the-key-you-want` | 19:51 |
| AskUbuntu | How can I debug a juju client command? | http://askubuntu.com/q/347651 | 19:51 |
| ZonkedZebra | and then have the script write out the key file, use it, then delete it again? | 19:51 |
| ZonkedZebra | script=charm | 19:52 |
| marcoceppi | ZonkedZebra: just store the key in your users home directory on the charm, so during your hooks/config-changed hook, do something like this: | 19:53 |
| marcoceppi | ZonkedZebra: http://paste.ubuntu.com/6129743/ | 19:54 |
| ZonkedZebra | okay, but wouldn't that conflict if I run multiple services on the same node? they all run under the ubunutu user yes? | 19:57 |
| marcoceppi | ZonkedZebra: they all run as the root user, and yes if multiple charms are co-located, we dont' recommend co-location of services until containerization is fixed | 19:58 |
| ZonkedZebra | marcoceppi: fair enough. thanks | 19:59 |
| marcoceppi | ZonkedZebra: if that's a problem, just save the file as ".ssh/${$JUJU_UNIT_NAME/\//-}" | 20:00 |
| marcoceppi | instead of id_rsa, you'll just need to make sure you specify that key file as the one to use for git cloning | 20:01 |
| marcoceppi | ZonkedZebra: that'll take something like "service-name/0" to "service-name-0" which is a friendier file name | 20:01 |
| === tasdomas_afk is now known as tasdomas | ||
| === tasdomas is now known as tasdomas_afk | ||
| adam_g | hazmat, around? | 20:29 |
| kentb | marcoceppi: so what exactly are the tools that get sync'ed / uploaded prior to bootstrapping? Is it just API-related, internal-to-juju stuff? | 20:37 |
| zradmin | has anyone had issues with the glance charm working properly? | 20:43 |
| === CyberJacob is now known as CyberJacob|Away | ||
| ZonkedZebra | marcoceppi: is there an easy way to pass files along with the charm to use as templates instead of embedding them in the bash script? | 20:51 |
| marcoceppi | kentb: it's the actually uploading juju client to be installed on all the machines. The juju client for the services is uploaded and dpeloyed from the storage to keep the same version between machines | 20:52 |
| marcoceppi | ZonkedZebra: you can use things like cheetah | 20:52 |
| ZonkedZebra | marcoceppi: link? | 20:53 |
| marcoceppi | ZonkedZebra: there's a few charms that do that | 20:53 |
| marcoceppi | ZonkedZebra: there's an old bash charm helper hanging around that does this | 20:54 |
| marcoceppi | ZonkedZebra: https://github.com/marcoceppi/discourse-charm/blob/master/lib/file.bash | 20:57 |
| marcoceppi | ZonkedZebra: but that gives you the cheetah formatting | 20:59 |
| marcoceppi | ZonkedZebra: here's an example template file, you just use $VARIABLE in the file https://github.com/marcoceppi/discourse-charm/blob/master/contrib/upstart/discourse-sidekiq.conf.tpl | 21:00 |
| kentb | marcoceppi: excellent. just what I needed...thanks! | 21:06 |
| === defunctzombie is now known as defunctzombie_zz | ||
| === freeflying is now known as freeflying_away | ||
| === freeflying_away is now known as freeflying | ||
| === kentb is now known as kentb-afk | ||
| hazmat | adam_g, yes | 22:11 |
| adam_g | hazmat i merged darwin into lp:juju-deployer earlier in the month, noticed some more changes hitting darwin since. any chance we can move development to lp:juju-deployer? not sure what needs to happen in LP | 22:15 |
| hazmat | adam_g, ic. i think its just a question of getting the word/out announcement, and then updating the various ppa/pkg builders to point to the new origin. there's still a few new merge proposals in the queue against darwin, getting those merged, and we can either unlink the series or point the series to trunk also on lp. | 22:17 |
| === freeflying is now known as freeflying_away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!