[00:40] how do I perform code versioning in juju? [00:41] like for example, I make changes to my charm and need to push updates [00:45] drecute: You can push your changes to bzr or git at any time [00:45] drecute: However, if you want to "upgrade" the charm running, you can run the upgrade-charm command [00:45] `juju upgrade-charm --repository="/path/used/during/deployment" ` [00:46] that should increment the revision file in your charm, which for local deployments, is what juju uses to track changes [00:46] the revision file is completely optional and only used for deploying from your local machine, if you're deploying from the charm store, the charm store keeps it's own revision of the charm, which is monitors the official repository for changes then increments number [00:47] So if you run `juju deploy mysql` find a bug, fix the bug, get it merged in to the official charm, you just need to run `juju upgrade-charm mysql` and juju will see the version in the store is higher and run the upgrade [00:56] excellent. [00:57] Thanks marcoceppi|away === marcoceppi|away is now known as marcoceppi|trave === CyberJacob|Away is now known as CyberJacob === CyberJacob is now known as CyberJacob|Away === CyberJacob|Away is now known as CyberJacob === defunctzombie is now known as defunctzombie_zz === wedgwood is now known as Guest52531 [11:23] i'm trying to use juju with maas. I have both from ppa to make sure i use the latest versions. i've configured maas, have 2 nodes (1 declared and 1 allocated to root), however, after bootstrapping juju, when i type 'juju status', I get """error: Unable to connect to environment "". Please check your credentials or use 'juju bootstrap' to create a new environment. Error details: no reachable servers [11:23] i do not see any errors in /var/log/maas/*. what else should i check? [11:24] and my maas web ui works fine. [11:26] disposable: it sounds like bootstrap didn't work [11:26] could you try again with [11:26] juju bootstrap -v [11:26] (if you environment is bootstrapped, nothing will happen) [11:26] error: environment is already bootstrapped [11:27] ok, cool [11:28] could you do the status with -v for me ? [11:28] http://pastebin.com/SJVGsaTL is what's in my environments.yaml [11:28] (i really wish -v was the default) [11:29] davecheney: juju status takes forever to run (5+ minutes) [11:30] davecheney: so please don't think i've left [11:33] hmm, sounds like a timeout [11:33] it smells like the mongodb server onthe bootstrap node didn't start up [11:33] i'm guessing there are lots of timeout errors [11:42] davecheney: the verbose output isn't that much more informative - http://pastebin.com/FUri1dx3 [11:44] disposable: weird, why is you environment named "" [11:44] is node1 resolvable from your client ? [11:44] * davecheney is asking in #juju-dv [11:45] davecheney: it isn't. i haven't installed maas-dns and i'm using external dhcp server. [11:46] should node1 be running? [11:47] yes, if i understand correctly, node1 has been designated as the bootstrap node, or what we call machine 0 [11:48] if it's not running, that would explain what is going on [11:48] when i list the nodes in maas web ui, i see node1 as "Status: Allocated to root". I can't say i understand what that means. [11:49] davecheney: if i start node1, it'll try to pxe boot. will it not just get overwritten/reinstalled again? [11:51] disposable: tbh, i'm not sure, i'm not a maas expert [11:51] i only know it from the POV of juju and the provider interface [11:51] i *think* what has happened is your node 1 has been used as the bootstrap node [11:51] but becuase it is off, the environment is unaccessable [11:55] davecheney: since it's in virtualbox, i've taken a snapshot and it's now booting up [11:57] ok [12:09] i've made node1 resolvable, ran juju status -v and got this error - http://pastebin.com/5L5iXbxh On node1, i see network activity when juju staus is running, but otherwise there's no disk/net activity at all. [12:09] * davecheney looks [12:09] disposable: here is what may have happened [12:10] you may have shut down node 1 before the bootstrap process was complete === gary_poster|away is now known as gary_poster [12:10] i do not believe it was on while bootstrap was running. is there a way to un-bootstrap and re-bootstrap juju? [12:12] disposable: yes juju destroy-environment will remove the environment and release the machines back to the maas controller [12:12] davecheney, lol - (i really wish -v was the default) [12:12] davecheney: thank you. i'll try that later. [12:12] alias juju="juju -v" [12:12] juju is just a little to quiet these days :-) [12:13] jamespage: +1 [12:14] saves you having to run the command twice when it goes wrong [13:11] disposable: virtual box is not a good virtualizer for Maas [13:12] for one, pxe booting doesn't work (didn't work for me when I did this a year ago) === medberry is now known as med_ === Guest52531 is now known as wedgwood [14:12] is proper networking with containers ala 'juju add-machine 1/lxc' working in latest 1.13.1? [14:54] bbcmicrocomputer: i'm going to say a conditional yes [14:55] but i'd like to check with thumper before I say any more [14:56] davecheney: ah ok, thanks! [15:06] i'm trying to start over with juju+maas. when i issue juju destroy-environment, all i get back is - ERROR juju supercommand.go:274 command failed: gomaasapi: got error back from server: 409 CONFLICT [15:07] what should i do next (apart from reinstall)? [15:09] nevermind, deleting declared node from maas, fixed it. [15:09] s/maas,/maas [15:10] can any OSX users help test out the brew instructions in https://code.launchpad.net/~evarlast/juju-core/osx-homebrew-goget/+merge/178379 ? [15:12] it should be easy to check... it's just installing go with brew, then using go get to install juju client [16:28] adam_g, hazmat, around? seems like 'units:' was renamed to 'num_units:' in the rewrite? [16:28] juju-deployer that is [16:36] * hazmat pokes around orig src [16:37] sidnei, hmm. it does look that way [16:37] sidnei, i'll add in a back compat for it [16:37] hazmat: thanks [16:58] Hi all. [17:00] I upgraded to Ubuntu Saucy over the weekend, and with it to juju-core 1.12.0 (later to 1.13.1 via PPA). I've been using jitsu watch to wait for a node to come up, but now I'm getting an error "ImportError: No module named juju.control". [17:01] Am I missing a dependency somewhere? [17:04] JamesTait: jitsu is depreciated and no longer compatible with juju > 0.7 [17:04] marcoceppi, ah, that'd explain it. Is there something I should be using instead? [17:05] * JamesTait hasn't been keeping up to date with the charm schools. :( [17:05] JamesTait: so, we have juju plugins (being that we can create arbitrary juju subcommands much like bzr and git) however, at this time we dont' have a comperable watch alternative [17:06] JamesTait: what were you using watch for primarily? [17:09] marcoceppi, I'm using it in a Makefile where I wait for solr-jetty to be started and then use juju status to get its public IP address to put into a configuration file for something else. [17:09] JamesTait: Gotchya, would it be better to mock that exchange in a relation instead? [17:11] marcoceppi, this is for a local dev environment (for click package index), and I'm not quite sure what the status is of the dependent service (which is the click package index WSGI service). I think I'll need to have a chat with the chap who charmed it for production and see what we can work out. [17:12] JamesTait: ah, I see, so the ip isn't used directly with other charms, but for external service [17:12] services* [17:13] So, there's a tool called amulet that I've been working on, it's designed with testing in mind, but it has a port of the jitsu watch command in the form of `amulet wait` [17:13] in that the command will block until either a timeout is reached or the environment/service is moved to started [17:13] marcoceppi, yeah. The way the dev environment is currently set up, we use juju for solr-jetty, but the wsgi service is just run directly under gunicorn. [17:13] marcoceppi, ah yes, I recall reading about amulet. [17:15] JamesTait: So, it's in the ppa:juju/pkgs ppa, it's purpose is for functional tests, but you could certainly run that command add-hoc until I port the code to a juju plugin :) [17:16] It sounds like an option. I'm currently drafting an e-mail to the team to describe the problems I've had during the upgrade so others don't need to. :) [17:17] And "I'll fix the Makefile so you can all continue working as you are" sounds so much better than "We're going to need to re-work the dev environment and..." ;) [17:17] marcoceppi, thanks for your help, I'll give it a bash and let you know how we get on. === defunctzombie_zz is now known as defunctzombie [17:21] JamesTait: cheers, please let me know if you have any questions or feedback! [17:25] marcoceppi, will do! [17:36] marcoceppi, is amulet available on Saucy? [17:36] JamesTait: Oh, let me kick off a saucy build [17:36] Awesome, thanks. :) === tasdomas_afk is now known as tasdomas === tasdomas is now known as tasdomas_afk === defunctzombie is now known as defunctzombie_zz === defunctzombie_zz is now known as defunctzombie [20:57] adam_g: hi, I added the tests, could you take another look? https://code.launchpad.net/~ahasenack/charm-helpers/ceph-wait-for-device/+merge/179429 [20:57] thanks [20:57] andreas__, ack,, will in a bit === andreas__ is now known as ahasenack === CyberJacob is now known as CyberJacob|Away [22:14] ahasenack, any chance you can add the 'slow' attribute to those tests that wait on a timeout?