[00:15] <msx> hello guys, i'm starting with Juju (so far loving it) and while I'm at the configuration stage I want to ask you: how do you usually use Juju, straight from the r00t account (seems somewhat dangerous to me), from a special account setup to that end (like use "juju") or just from the account you usually use to manage your Ubuntu servers?
[00:16] <sarnold> msx: so far as I've used juju myself, I've just used my own user account; if I had shared administrative tasks with other users, I'd likely take the 'juju' user route and have people ssh in or sudo in ..
[00:17] <msx> sarnold: that's what i was thinking, thanks a lot sarnold :D
[00:24] <lazyPower> msx: its common practice to use a jump host when sharing it with a team
[00:25] <lazyPower> there are newer features in the pipeline that will make sharing administrative control of your juju infrastructure easier, but until thats 100% fleshed out and documented, my suggestion would be to use a shared host/account for management.
[00:37] <msx> lazyPower: hei! Sorry for the late reply. Yes, we are a very small team (just two) so my idea is to have both of us the same level of access to all Juju's features, thus I will be creating a juju account tailored for this end
[00:37] <msx> lazyPower: thank you very much for your suggestion :)
[00:37]  * lazyPower hat tips
[00:37] <lazyPower> any time
[00:37] <msx> "hat tips" lol
[03:50] <davecheney> marcoceppi: https://bugs.launchpad.net/bugs/1281394
[03:50] <_mup_> Bug #1281394: uniter failed to run non-existant config-changed hook <juju-core:New> <https://launchpad.net/bugs/1281394>
[03:50] <davecheney> ^ config-changed isn't manditory, right ?
[04:16] <lazyPower> davecheney: none of the hooks are mandatory afaik
[04:16] <lazyPower> it basically creates an immutable service, but its not required.
[04:17] <davecheney> lazyPower: thanks for confirming
[04:17] <davecheney> this is a regression then
[04:17] <davecheney> deploying the ubuntu charm *used* to work
[04:17] <davecheney> and that is a charm that doens't get much simpler
[04:18] <lazyPower> indeed. i'm running the amulet test against 0.17.2 that arosales wrote
[04:25] <davecheney> lazyPower: what does , juju deploy cs:ubuntu
[04:25] <davecheney> give you ?
[04:46] <lazyPower> davecheney: loading 1 sec.
[04:46] <lazyPower> also, the amulet test passed
[04:47] <davecheney> well shit
[04:47] <davecheney> one of us did something wrong
[04:48] <lazyPower> which version of juju are you running davecheney?
[04:48] <davecheney> 1.17.3.1
[04:48] <davecheney> (trunk)
[04:48] <davecheney> what does juju status ubuntu/0 say
[04:48] <lazyPower> must be in trunk, 1.17.2.1 isn't complaining about the config-changed hook
[04:48] <davecheney> 2.1 ?
[04:48] <davecheney> what is that
[04:48] <davecheney> are you doing upload tools from a release vesion ?
[04:49] <lazyPower> http://paste.ubuntu.com/6952698/
[04:49] <lazyPower> nope
[04:49] <davecheney> lazyPower: something is very strange then
[04:49] <davecheney> release tools do not have a 4th digit
[04:50] <davecheney> oh, you're using the local provider
[04:50] <davecheney> never mind
[04:50] <lazyPower> i can check on a cloud provider, 1 moment
[04:51] <davecheney> please
[04:51] <davecheney> hp if oyu can
[04:51] <lazyPower> sure thing
[04:57] <lazyPower> davecheney: http://paste.ubuntu.com/6952734/
[05:02] <davecheney> weird
[05:02] <davecheney> can you have a look in the unit logs on that machine and see what happened
[05:03] <davecheney> did it try to execute the config-changed hook
[05:03] <davecheney> did it ignore it
[05:03] <davecheney> etc
[05:18] <lazyPower> davecheney: http://paste.ubuntu.com/6952783/
[05:19] <lazyPower> i see nothing relating to skipping the config-changed hook. let me check the unit-0 log
[05:20] <davecheney> lazyPower: yeah, that paste is the machine agent
[05:20] <lazyPower> yeah nothing in the controller node's logs either
[05:20] <davecheney> wont' be
[05:21] <davecheney> will only be in machine-1:/var/log/juju/unit-ubuntu-0.log
[05:22] <lazyPower> that was included in that first paste
[05:22] <lazyPower> it shoul dhave been appended at the bottom
[05:22] <lazyPower> i did a cat *.log | pastebinit
[13:07] <xp1990> Hi! is anyone here available to help me with a problem?.
[13:07] <xp1990> I'm using juju 1.16.6
[13:07] <xp1990> and the I'm getting the old index file contains no data for cloud, error.
[13:07] <xp1990> I have generated imagemetadata.json and index.json
[13:07] <xp1990> and uploaded them, using swift, to my cloud public bucket
[13:07] <xp1990> which is named juju-<hash>/streams/v1/
[13:08] <xp1990> then the two json files are there
[13:08] <xp1990> yet I still get an error when running juju bootstrap
[13:09] <xp1990> that says the index file has no data for cloud  {RegionOne <ip>}
[13:17] <marcoceppi> xp1990: can you pastebin your imagemetadata.json and index.json?
[13:18] <tomixxx3> marcoceppi: hi, do u know already a bug fix for the "internal server error" of openstack dashboard?
[13:21] <marcoceppi> tomixxx3: you have to remove django 1.5 and install 1.3, I don't have the exact steps yet
[13:23] <tomixxx3> marcoceppi: kk
[14:12] <hazmat> marcoceppi, do you have any amulet tests for mysql?
[14:13] <marcoceppi> hazmat: just some very light weight skels, nothing of concequence yet
[14:14] <hazmat> marcoceppi, k, just checking cause of addition of ssl support to interface
[14:14] <marcoceppi> hazmat: ah, yeah that's fine, I'll make sure a test exists to gen ssl certs and validate those
[14:16] <hazmat> marcoceppi, so.. i'm taking a slightly different approach.. might be more trouble than its worth.. but its much easier to configure.. ie just set ssl="on"  or ssl="only"and mysql services becomes a ca and hands its ca fingerprint on the relation, with only going to establish client cert passing and checking.
[14:16] <marcoceppi> hazmat: sounds sexy to me
[14:16] <marcoceppi> I like making it easier for users
[14:17] <hazmat> yeah.. i still have to verify its sane for ha setups.
[14:17] <hazmat> but significantly easier for end users and bundles.
[14:17]  * marcoceppi nods
[14:49] <dimitern> hazmat, it seems the fix for bug 1174610 sadly cannot land yet, due to 1.16 having direct state access, and needs to be postponed until the next release
[14:49] <_mup_> Bug #1174610: unit ids should be unique <regression> <juju-core:Triaged by dimitern> <https://launchpad.net/bugs/1174610>
[15:04] <hazmat> dimitern, yeah.. saw the bug email.. no worries. glad to see it get some attention
[16:06] <tomixxx3> marcoceppi: do u think i can investigate the i-net on my own in order to get openstack-dashboard to run? or is it really hard to change django version?
[16:11] <marcoceppi> tomixxx3: not that hard, just uninstall django
[16:12] <tomixxx3> so, sudo apt-get purge django1.5 and sudo apt-get install django 1.3?
[16:14] <roadmr> tomixxx3: yes
[16:14] <roadmr> tomixxx3: *some* parts of the dashboard will still error out, I got that but haven't looked into it further
[16:15] <roadmr> tomixxx3: still you should be able to get an overview and get the all-important credentials
[16:15] <roadmr> (it's mostly some graphs and reports that still fail)
[16:15] <tomixxx3> ok..
[16:17] <tomixxx3> do i have to uninstall/restall django only on the openstack-dashboard node?
[16:18] <tomixxx3> roadmr: do i have to uninstall/reinstall django only on the openstack-dashboard?
[16:18] <tomixxx3> +node
[16:25] <roadmr> tomixxx3: yes, only on that one
[16:25] <roadmr> tomixxx3: juju ssh openstack-dashboard/0 should get you where you need to be
[16:25] <tomixxx3> roadmr: kk
[16:36] <jamespage> marcoceppi, OK - I'm going to bite the bullet and write some amulet tests for the openstack charms
[16:36] <marcoceppi> jamespage: there's a known bug with subordinates that's being patched
[16:36] <jamespage> I need better automated testing in the charm itself - deployer configs are OK - but its hard to get contributors todo that if they don't know about it
[16:37] <jamespage> marcoceppi, is there a good example/guide I can follow?
[16:37] <jamespage> and can I use deployer configs?
[16:48] <tomixxx3> roadmr: ok i have installed django 1.3 now but i still get the interal server error. do i have to restart apache or sth similar?
[16:48] <roadmr> tomixxx3: hmm maybe, I don't remember if I did
[16:48] <tomixxx3> btw, i had to use other commands than sudo apt-get purge or install
[16:48] <roadmr> try it and let me know if it works :)
[16:48] <roadmr> tomixxx3: oh really?
[16:49] <tomixxx3> yes, pip install Django==1.3 to install django for example
[16:49] <tomixxx3> can i simple reboot the nodes?
[16:50] <roadmr> yes that should work
[16:50] <roadmr> tomixxx3: didn't apt-get install python-django=1.3.1-4ubuntu1.8 work? (assuming a 12.04 node)
[16:51] <tomixxx3> roadmr: dunno i have not tried this, but when i do some i-net investigation, i have read that everyone uses other commands
[16:51] <roadmr> tomixxx3: well you could also pip install django=1.4 which I think is the correct version for grizzly
[16:52] <roadmr> tomixxx3: I specifically didn't want to go too deep (at that point I may as well ditch juju and manage the servers manually) so I stuck with what I could do with apt-get
[16:54] <tomixxx3> roadmr: np, i just investigated google and i have found that other commands so i have tried them :-)
[16:55] <roadmr> tomixxx3: cool!
[16:56] <tomixxx3> roadmr: an mathematician told me: "todoay, the only important thing is to know WHERE to search" ^^
[16:57] <roadmr> tomixxx3: indeed :)
[16:57] <tomixxx3> ohoh keystone failed. "hook failed: "config-changed"'
[16:58] <tomixxx3> but openstack dashboard is online :-)
[17:00] <roadmr> \o/
[17:16] <tomixxx3> i got the following "Unable to communicate with identity service: [Errno 111] Connection refused. (HTTP 400)" when i try to manually invoke "change-config"
[17:17] <xp1990> Hi guys, got a bit of an issue, during bootstrap my client will just hang at attempting to connect to
[17:17] <xp1990> Any idea how I could fix this, or debug it?
[17:19] <xp1990> http://pastebin.com/fpGTPCUd
[17:22] <tomixxx3> oh keystone is working now oO
[17:27] <tomixxx3> i manually executed ./hooks/change-config and i got this http 400 exception but keystone is indicated as "started" when i execute "juju status"
[17:32] <jamespage> marcoceppi, omg - /usr/bin/python3 /usr/bin/easy_install3 cherrypy
[17:32] <marcoceppi> jamespage: ugh, I need to stop cherrypy for something else
[17:32] <marcoceppi> s/stop/drop/
[17:32] <jamespage> marcoceppi, i object more to 'easy_install;
[17:33] <jamespage> marcoceppi, currently means I can't run amulet inside our QA cloud
[17:33] <marcoceppi> jamespage: what, would pip be better? I should actually just have the tarbal in there and use a venv I guess
[17:34] <jamespage> marcoceppi, archive or contains in charm good for me
[17:34] <marcoceppi> I'll use something from the archive
[17:38] <stub> What is the syntax in an amulet test to deploy 'this charm'? It seems to be d.add('mycharm'), but that seems  to be hitting the charm store and failing with a 404 (since the charm isn't in the store yet)
[17:46] <jamespage> stub, I was just about to ask the same thing
[17:46] <jamespage> stub, I need a pre-flight test prior to submission or to review a MP
[17:46] <jamespage> marcoceppi, ^^ is that possible?
[17:47] <marcoceppi> stub jamespage that's a known issue that's being patched in 1.2.9 - it'll deploy using local, but will attempt to do a remote lookup when running relation grafting
[17:48] <marcoceppi> so it does a lookup against the charmworld api, quite annoying I know
[17:48] <stub> that's ok, it means I get to submit my new charm without having to debug these tests ;)
[17:49] <marcoceppi> stub: technically we don't require tests..yet ;)
[17:49] <stub> I require tests ;)
[17:49] <jamespage> marcoceppi, confused
[17:50] <marcoceppi> jamespage: sorry, when you d.add() charm, if charm is the name of the current charm the test is being run from it'll use that in it's deloy schema. However, later on down the road in the whole amulet stuff, it does a lookup against charmworld (where you're getting the 404) to get relation details. It's failing there
[17:51] <jamespage> marcoceppi, ok- so it's using the local charm - I'm writing tests for an existing charm so that's ok I think
[17:52] <marcoceppi> jamespage: yeah, it autodetcts if you're in a charm, when you run d.add('charm') and don't specify a charm to pull from, it'll check if the current charm the test is running from is the charm added and use that path for the deployer file, otherwise it'll expand the url to use the charmstore
[17:52] <jamespage> marcoceppi, its used bzr to clone the charm into the deployer directory right?
[17:52] <marcoceppi> jamespage: pretty much, yes
[17:52] <jamespage> OK - so any changes have to be commited to the branch first
[17:52] <jamespage> I understand
[17:53] <marcoceppi> jamespage: actually, I think it does a copydir, I need to verify
[17:53] <marcoceppi> pretty sure I did that instead to git charms would still work
[17:54] <jamespage> marcoceppi, looks that way
[17:56] <jamespage> marcoceppi, no - I can't tell
[17:56] <marcoceppi> jamespage: actually, it looks like it leaves it up to deployer
[17:57] <stub> Oh, charm proof wants a copyright now... anyone know what I should be using?
[17:57] <marcoceppi> stub: an OSI approved license
[17:58] <jamespage> marcoceppi, what's the assumption on where the things in tests/ get run from? the root?
[17:58] <jamespage> of the charm?
[17:58] <marcoceppi> jamespage: CHARM_DIR
[17:58] <stub> So wack a GPL3 on there since this is on Canonical time
[17:59] <marcoceppi> stub: sure, a lot of people have been doing the debian style copyright file
[18:00] <marcoceppi> stub: somethign like this, https://github.com/charms/wordpress/blob/master/copyright
[18:00] <marcoceppi> but basically, just who owns the copyright, and the license for all the charm files
[18:00]  * stub copy pastas
[18:01] <stub> Did you really write that charm in 2012?
[18:02] <marcoceppi> stub: yes, it's an old ass charm
[18:03] <marcoceppi> and that was a re-write of the original charm, so it existed even before that
[18:07] <jamespage> marcoceppi, I've not got this far yet but does the deployer tidy up after itself?
[18:07] <marcoceppi> jamespage: how so?
[18:07] <jamespage> i.e. will it destroy the services ready for the next run
[18:07] <marcoceppi> jamespage: yeah, so each test file gets a fresh bootstrap, unless you set a certain flag
[18:08] <marcoceppi> jamespage: you can log the output of the test run using the -o flag with juju test, which will copy all the logs from the run to the path in -o
[18:09] <jamespage> marcoceppi, juju test was the bit of magic I was missing
[18:09] <marcoceppi> jamespage: oh, yeah, sorry, amulet and juju-test are decoupled. Ones a framework for writing tests the other is the test executor
[18:11] <jcastro> utlemming, how close to non-beta do you consider the vagrant boxes?
[18:12] <marcoceppi> utlemming: on a related note, the mounts are broken in the latest images, where should we file bugs?
[18:12] <jamespage> marcoceppi, ah - so I probably don't want to be installing amulet in tests/01-setup
[18:12] <marcoceppi> jamespage: you probably /do/ want to be doing that
[18:13] <jamespage> marcoceppi, yeah - but juju tests bootstraps and environment to run that script
[18:13] <marcoceppi> jamespage: I'm working on adding isolation to juju-test, so running it will create an LXC that executes the tests without dirtying your system
[18:14] <marcoceppi> jamespage: oh, yeah, that's another issue. For the time being people have been making the script non-executable, for the sake of time you can just feed the juju-test plugin the tests  you want to run
[18:14] <marcoceppi> ie: juju tests 02-other-test 03-this-thing
[18:14] <marcoceppi> to bypass waiting for a setup/teardown to install deps
[18:14] <jamespage> marcoceppi, ok - nice
[18:27] <arosales> jcastro: do you know if http://askubuntu.com/questions/134977/juju-stuck-in-pending-state-when-using-lxc is still valid for 1.16.x release?
[18:30] <marcoceppi> arosales: tjat
[18:30] <marcoceppi> that's a really old release of juju
[18:32] <marcoceppi> arosales: as in, that's python juju
[18:41] <jcastro> I voted to close it
[18:48] <arosales> jcastro: marcoceppi: ack that is what I was thinking based of the comments and release
[18:48] <arosales> thanks
[19:01] <hazmat> and mostly likely its nothing to do with juju but the lxc version of the time if memory serves
[19:01] <jcastro> yeah, mostly I want it deleted so we can get the google search namespace back
[19:01] <hazmat> hmm..
[19:02] <hazmat> actually that quetsion/answer is still revelant
[19:02] <hazmat> ufw can still interfere with local provider
[19:02] <hazmat> jcastro, ie.. this is still a real possibility https://bugs.launchpad.net/juju/+bug/998238
[19:03] <_mup_> Bug #998238: local provider unit agents get stuck in pending state because of host firewall blocking communication <pyjuju:Triaged> <https://launchpad.net/bugs/998238>
[19:03] <hazmat> its dated but the symptons and solutions are still the same
[19:03] <jcastro> huh
[19:03] <jcastro> I wonder if we can put a check in core and at least spit something out?
[19:03] <hazmat> bugs away
[21:53] <lazyPower> utlemming: is there a specific launchpad project you'd like me to open bugs against the virtualbox images? I went looking for cloud-images and have found no such project or relevant projects  - the closes was cloud-init.
[21:53] <lazyPower> *closest