[00:00] <adam_g> hazmat, is the websocket module used by python-jujuclient available anywhere in the ubuntu archive?
[00:00] <hazmat> adam_g, no
[00:00] <adam_g> didnt think so. darn.
[00:01] <hazmat> adam_g, andreas has a package/ppa for python-jujuclient
[00:02] <hazmat> adam_g, https://launchpad.net/~ahasenack/+archive/python-jujuclient
[00:04] <adam_g> hazmat, ah, thanks
[00:13] <jose> hey marcoceppi or anyone around, is there a link to the charm design template?
[00:13] <jose> s/design/icon/
[00:14] <marcoceppi> jose: yeah I just uploaded it for the docs, http://marcanonical.com/icon.svg
[00:14] <marcoceppi> that section of the charm author docs should be landing soonish
[00:14] <jose> great, thanks! :)
[01:21] <jose> marcoceppi: how should I do the copyright? to Canonical Ltd.?
[01:21] <marcoceppi> jose: no! You're the copyright holder :D
[01:22] <jose> ok!
[01:22] <marcoceppi> We jsut ask that, in order to be in the store, the charms are licensed under a free license
[01:27] <jose> great
[01:27]  * jose continues working
[05:23] <alok_> hi there
[05:25] <alok_> i cant find installation for juju local
[05:25] <alok_> *guide
[05:39] <davecheney> aaaand, he's gone
[11:10] <pavel> hello, guys
[11:11] <pavel> can somebody help me with this error?
[11:11] <pavel> error: cannot start bootstrap instance: no "precise" images in us-west-2 with arches [amd64 i386]
[11:11] <pavel> juju version:1.11.2-precise-amd64
[11:25] <pavel> ok, I switched to backported 1.10 and it works
[12:11] <jamespage> pavel, where are you pulling 1.11.2 from to get that issue?
[12:11] <jamespage> pavel, there are some problems with earlier golang versions - I think we should have that fixed today...
[12:14] <pavel> jamespage, from devel ppa
[12:15] <jamespage> pavel, yeah - looks like the amd64 builds are still waiting to go through
[12:16] <jamespage> ~1hr - if that does not happen I'll go see if we can get the priority bumped
[12:16] <pavel> don't worry, 1.10 is ok for me
[12:18] <pavel> when I run bootstrap from amd64 it looks for amd64 machine in ec2?
[12:18] <pavel> or it runs amd64 by default?
[12:23] <mgz> pavel: I think this is an issue with the cloud images format having been changed, which breaks deploying on ec2 with 1.11
[12:23] <mgz> wallyworld: ^is that the symptom?
[12:24] <wallyworld> yes
[12:25] <melmoth> jamespage, looks like it s working now....i ll play with it a bit, adding master and stuff, just to see what happen.
[12:29] <jamespage> melmoth, great
[12:29] <jamespage> I'll propose that for merge
[12:45] <jamespage> adam_g, merged both of your updated charm-helpers branches - thanks!
[12:49] <jamespage> wallyworld, when you have some simplestreams juju-tools avaliable happy to test that for you
[12:50] <wallyworld> jamespage: awesome thanks. i'm waiting on some sample data to test with myself. will let you know when we are at the stage where it can be consumed
[12:51]  * jamespage thinks that is a real enabler
[12:51]  * wallyworld does too
[12:51] <wallyworld> for most cases, it will be configless for the user
[12:52] <pavel> hm... was the 'debug-hooks' command removed from 1.10?
[12:53] <mgz> as in, was it in juju-core and removed? no.
[12:53] <mgz> it hasn't been implemented in the rewrite.
[12:54] <mgz> see bug 1027876
[12:54] <_mup_> Bug #1027876: cmdline: Support debug-hooks <cmdline> <juju-core:Triaged> <https://launchpad.net/bugs/1027876>
[12:55] <pavel> I see...
[12:55] <pavel> is there any guide to upgrade charms that was written for 0.7 to 1.10 ?
[12:56] <pavel> for example I see that structure of config.yaml changed a bit
[12:57] <mgz> pavel: no doc on charm relevent changes from pyjuju to gojuju that I'm aware of
[12:57] <mgz> evilnickveitch: ^is there anything along those lines?
[12:57] <mgz> pavel: that said, the aim was for charms to basically be compatible
[12:58] <pavel> I still didn't figure out why, but my overrides in custom config for service deployment doesn't override default value
[12:58] <pavel> now I changed format of config.yaml and trying again
[12:59] <mgz> well, that sounds familar
[13:00] <evilnickveitch> mgz, pavel there isn't anything on rewriting charms for 1.x as yet. But I would be happy to hear of any issues with that so I could include something
[13:00] <mgz> fwereade: ^what's the answer to default values not getting overridden?
[13:01] <fwereade> pavel, mgz, I'm not familiar with that... any more detail? are you using a yaml file with --config?
[13:02] <mgz> evilnickveitch: I think several of the issues should just be bugs for us, but we have made several deliberate changes that we really should get recorded somewhere, I'll do some poking
[13:02] <evilnickveitch> mgz thanks
[13:02] <pavel> fwereade, yes it's yaml file, but named with .yml
[13:03] <pavel> maybe it's my fault, I have to try several options more
[13:03] <fwereade> pavel, that shouldn't be a problem; but there was a format change there, we released accepting a format that didn't match python
[13:03] <fwereade> pavel, the python format is `servicename: {...}`
[13:03] <pavel> yes, I found new format in the docs
[13:04] <fwereade> pavel, huh, the docs included the new format? bah
[13:04] <pavel> new format for default values
[13:04] <pavel> charm: mediawiki service: mediawiki settings: {}
[13:05] <fwereade> pavel, I am not familiar with that format at all, would you link me where it came from please?
[13:05] <pavel> ah
[13:05] <pavel> sorry
[13:05] <pavel> my mistake
[13:05] <fwereade> phew :)
[13:05] <pavel> I looked at ' juju get mediawiki'
[13:06] <fwereade> pavel, just one note: inside the charm, the name "config.yaml" is special, and configs with different filenames will not be picked up; so far as we are aware we have not changed how that works
[13:07] <pavel> yes, this is clear
[13:07] <fwereade> pavel, but when you're specifying service config settings, the format of the file you pass to --config has changed back to how it was in python, after a regrettable period of incompatibility
[13:07] <pavel> for 1.10 it's service: {}
[13:07] <pavel> ?
[13:07] <fwereade> pavel, however the file name there should not make any difference
[13:07] <fwereade> pavel, for 1.10 it's just a naked map without the service name
[13:07] <pavel> gotcha!
[13:08] <fwereade> pavel, sorry about that one :(
[13:08] <pavel> no problem, thanks a lot for your help
[13:10] <pavel> in the official docs it's service: {} now, thought the recommended installation is 1.10
[13:12] <mgz> we may need a note there, though we can probably get 1.11 out to everywhere when it's release
[13:12] <mgz> d
[13:17] <pavel> is there a date for 1.11 release?
[13:17] <mgz> this week!
[13:17] <pavel> awesome
[13:21] <teknico> I'm also getting the same error as pavel with juju trunk: error: cannot start bootstrap instance: no "precise" images in us-east-1 with arches [amd64 i386]
[13:22] <mgz> teknico: ec2 is borked right now as the cloud images data changed
[13:22] <fwereade> teknico, *that* I am afraid to say is because the image metadata format on cloud-images.ubuntu.com changed unexpectedly
[13:23] <mgz> you can either use 1.10, or --upload-tools if you build locally
[13:24] <teknico> fwereade, mgz, thanks, I have i386 locally, can I still use --upload-tools?
[13:25] <pavel> fwereade, juju deploy ... --upload-tools ?
[13:25] <pavel> sorry, juju bootstrap --upload-tools ?
[13:28] <mgz> teknico: good question, not sure.
[13:28] <fwereade> teknico, pavel: sorry, it's the ubuntu image metadata we've lost
[13:28] <fwereade> teknico, pavel: so far as I'm aware the tools are all still around
[13:29] <mgz> pavel: yeah, bootstrap, but it's uploading your own builds (so, you need all the deps and so on locally)
[13:29] <pavel> crap, I'll wait for fix :)
[13:29] <mgz> ah, yeah, pants, probably not the right work around
[13:30] <teknico> ok, I'll downgrade too :-)
[13:35] <fwereade> pavel, we are just waiting for someone to get in so we can figure out exactly what happened
[13:37] <pavel> fwereade, hope it will be an easy fix
[13:37] <fwereade> pavel, it really should be but we want clarity and certainty so we actually unbreak it, rather than just breaking it differently
[14:04] <teknico> pavel: how did you switch back to 1.10? I can't come up with the right command
[14:05] <pavel> what ubuntu distro do you use?
[14:08] <teknico> pavel: I'm on raring
[14:09] <pavel> ok, then
[14:09] <pavel> sudo apt-get autoremove juju juju-core
[14:09] <pavel> sudo add-apt-repository -r ppa:juju/devel
[14:09] <pavel> sudo apt-get update
[14:09] <pavel> sudo apt-get install juju-core
[14:10] <teknico> pavel: thanks, but the devel ppa has 1.11.2, hasn't it? https://launchpad.net/~juju/+archive/devel
[14:11] <pavel> there is '-r' there
[14:11] <pavel> it's for removing
[14:11] <teknico> aah, right
[14:20] <teknico> pavel: it worked, thanks
[14:21] <pavel> np
[14:26] <fwereade> pavel, teknico, others: smoser has resolved the image metadata issue and I am able to bootstrap again
[14:36] <pavel> fwereade, yes, it's working!
[14:37] <fwereade> pavel, great, sorry for the problem in the first place
[14:37] <pavel> fwereade, thanks for such quick fix
[14:41] <jcastro> m_3_: new charm in the queue, mailman!
[14:42] <m_3_> jcastro: ack
[14:55] <fwereade> pavel, direct all praise toward smoser please :)
[14:56] <pavel> smoser, thank you so much :)
[15:45] <jamespage> jam: any chance you will get to bug 1189507?
[15:45] <jamespage> https://bugs.launchpad.net/juju-core/+bug/1189507
[15:45] <_mup_> Bug #1189507: juju-core duplicates quantum security groups <serverstack> <juju-core:Triaged by jameinel> <https://launchpad.net/bugs/1189507>
[15:48] <jamespage> jam: soonish anways
[15:55] <marcoceppi> Well be starting charm meeting soon!
[15:58] <marcoceppi> http://ubuntuonair.com/
[16:04] <marcoceppi> http://pad.ubuntu.com/7mf2jvKXNa
[16:05] <arosales> kirkland, pad with notes is @ http://pad.ubuntu.com/7mf2jvKXNa
[16:06] <pavel> can you grant me an access?
[16:06] <arosales> pavel, to the google hangout?
[16:06] <kirkland> arosales: thanks!
[16:06] <pavel> to the pad? or I don't need it?
[16:07] <arosales> you shouldn't need access, are you getting an error
[16:07] <pavel> Yes, I'm getting an error
[16:07] <pavel> is this correct hangout url? https://plus.google.com/hangouts/_/calendar/ajVxODVtbWk2dWp2anRpaTVzMW4zbGk1aW9AZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ.p11le79ijn643h9hl7bmc36hbg
[16:07] <pavel> it's empty at the moment
[16:08] <arosales> pavel, try: https://plus.google.com/hangouts/_/b32ae1008a86dcde437cb82a07c95aa5edb9c329?authuser=0&hl=en
[16:08] <arosales> for the hangout
[16:08] <arosales> pavel, http://pad.ubuntu.com/7mf2jvKXNa for the pad with notes
[16:08] <arosales> pavel welcome, we see you now :-)
[16:08] <arosales> pavel, thanks for joining
[16:28] <arosales> jamespage, sorry we were just ending
[16:28] <jamespage> arosales, yeah - I missed the time
[16:28] <jamespage> np
[16:29] <jamespage> arosales, was busy raising bugs on juju-core :-)
[16:30] <arosales> jamespage, well thats time well spent then :-)
[16:35] <jamespage> marcoceppi, are you reserving the tests top-level directory for charm tests?
[16:40] <pavel> arosale, I'm not able to access pad
[16:41] <pavel> arosales, "Either you have not been granted access to this resource or your entitlement has timed out. Please try again."
[16:45] <arosales> pavel, hmm .. .
[16:45] <pavel> arosales, maybe smth is wrong with my ubuntu one account )
[16:46] <arosales> pavel, let me check another lp account and see if they can access the pad
[16:47] <pavel> arosales, looks like it's issue with my account
[16:47] <arosales> pavel, ok ping me if you continue to have issues
[16:48] <pavel> arosales, I'll create a brand new account and try again
[16:49] <arosales> pavel, ugh. ok
[16:51] <pavel> arosales, still getting this error
[16:53] <arosales> pavel,  "Either you have not been granted access to this resource or your entitlement has timed out. Please try again." is that the error
[16:53] <pavel> yes
[17:10] <Daviey> mgz, jamespage: How are we looking for a saucy upload?
[17:14] <mgz> Daviey: we really need a release first, which... is proving annoying, with several breakages, not all juju-releated
[17:15] <mgz> (eg, today, 1.11 hasn't been working on ec2, because the cloud images data got changed)
[17:16] <Daviey> mgz: Honestly, i'd be happy if we got something nonfunctional into saucy right now.
[17:16] <Daviey> There is always one more bug, delaying it.
[17:16] <mgz> this is true.
[17:18] <Daviey> mgz / jamespage: Is there any reason we can't just upload the daily from the PPA?
[17:18] <Daviey> (I know it's not quite reproducible source that i'd like)
[17:23] <ahasenack> Daviey: I don't think the ppa has "dailies"
[17:25] <ahasenack> it does have a recent build, though
[17:30] <Daviey> ahasenack: https://code.launchpad.net/~dave-cheney/+recipe/juju-core ?
[17:38] <ahasenack> Daviey: nice, that's news to me
[17:39] <ahasenack> Daviey: so just the tools story isn't handled by that, meaning, if you push this into saucy, people will have to remember to bootstrap with --upload-tools
[17:42] <Daviey> Ugh
[17:45] <ahasenack> and, hm, that also won't work. They need a full development environment
[17:45] <ahasenack> in which case they already have juju-core installed by source
[17:55] <adam_g> jamespage, where can i find the  nvp-transport-node subordinate?
[18:25] <wedgwood> adam_g: jamespage: looks like charm-helpers tests are broken on revno 46 for systems without python-dnspython installed
[18:30] <adam_g> wedgwood, gah, ok. ill take a look now
[18:30] <wedgwood> adam_g: jamespage http://pastebin.ubuntu.com/5862461/
[18:30] <wedgwood> cool, thanks
[18:31] <adam_g> wedgwood, actually, im working on cleaning up other stuff in that area. ill fix that as part of that
[18:31] <wedgwood> perfect
[18:36] <jamespage> adam_g, lp:~james-page/charms/precise/nvp-transport-node/trunk
[18:36] <jamespage> adam_g, you need access to NVP bits and pieces to make it work
[18:36] <adam_g> jamespage, thanks
[18:37] <adam_g> jamespage, cool. was trying to get the full picture when looking at the nova-c-c merge. im wondering if it might be a good idea to encapsulate all of the additional nvp config in an nvp subordinate, to keep nova-c-c's config.yaml minimal
[18:37] <adam_g> dunno if that + the transport subordinate would be awkward
[18:38] <jamespage> adam_g, maybe
[18:38] <jamespage> the transport sub gets used on nova-compute and quantum-gateway nodes
[18:38] <jamespage> not nova-cc
[18:38] <jamespage> me thinks
[18:40] <adam_g> jamespage, thinking out loud... would it be possible to use a single subordinate that can be related to all 3 services?  if its related to nova-c-c, it just exports its nvp-related config. if its related to q-gateway + nova-c, it goes thru the installation
[19:09] <jamespage> adam_g, that might work; however I'm concerned re the bits and pieces that configure quantum networking in ncc
[19:09] <jamespage> what we are really talling about is a redux on the way we integrated quantum into nova
[19:11] <adam_g> jamespage, hmm, i think a lot of that is going to change heavily anyway as soon as it moves to templating
[19:12] <jamespage> adam_g, agreed - that might be the right point in time to make this happen
[19:12] <jamespage> the pattern is similar to the cinder backends stuff we discussed a while back
[19:12] <jamespage> adam_g,  I think the nvp-transport-node sub stands as it is
[19:13] <jamespage> adam_g, the other bits are less than ideal but I don't want to waste to much time pushing them in to charms which are going to be re-written anyway.
[19:14] <adam_g> jamespage, im just thinking about when/if we have an NVP subordinate for  nova-c-c, we'll have an aditional NVP subordinate for q-gateway and nova-compute. other quantum plugins would require the same, probaby. might be better to have 1 subordinate with multiple interfaces
[19:15] <jamespage> adam_g, I don't disagree
[19:15] <jamespage> so actually maybe a nvp suboridinate that does different things to different charms determined by relationship is a good idea
[19:15] <jamespage> adam_g, how about we park the charms for the next few weeks while we figure this stuff out
[19:16] <jamespage> (the NVP updates that is)
[19:17] <adam_g> sounds good
[19:19] <adam_g> https://code.launchpad.net/~gandelman-a/charm-helpers/ha_os_cleanup/+merge/174028
[19:19] <adam_g> wedgwood, that should fix the tests
[19:20] <adam_g> jamespage, ^ theres some cleanup we talked about yesterday, gonna propose the context + templating next then start on the nova-c-c charm so we can figure out how we want to do the subordinates
[19:27] <wedgwood> adam_g: I'll defer to jamespage for landing. I see some lint issues - I know he'll mention them.
[19:27] <adam_g> wedgwood, oh thanks for reminding me. :)
[19:28] <wedgwood> ;)
[19:34] <adam_g> done
[23:19] <BeatsMusic> Can someone pls help with this error
[23:19] <BeatsMusic> 2013-07-10 23:18:06,519 ERROR SSH forwarding error: bind: Cannot assign requested address
[23:19] <BeatsMusic> Is it trying to connect to a bind server ?
[23:30] <sarnold> BeatsMusic: no, 'bind' in this case means bind(2) system call, to request a specific address
[23:30] <BeatsMusic> Just got that
[23:30] <BeatsMusic> thx
[23:30] <BeatsMusic> looks like juju can't connect to zookeeper
[23:30] <BeatsMusic> 2013-07-10 23:29:10,123 DEBUG Spawning SSH process with remote_user="ubuntu" remote_host="m03.ops.nyc1.beats" remote_port="2181" local_port="45778". 2013-07-10 23:29:10,239 ERROR SSH forwarding error: bind: Cannot assign requested address
[23:49] <BeatsMusic> After juju bootstrap
[23:49] <BeatsMusic> all i get is this
[23:49] <BeatsMusic> server refused to accept the client
[23:49] <BeatsMusic> 2013-07-10 23:48:55,504:19440(0x7f489e5c3700):ZOO_ERROR@handle_socket_error_msg@1579: Socket [127.0.0.1:46485] zk retcode=-4, errno=111(Connection refused): server refused to accept the client 2013-07-10 23:48:55,522:19440(0x7f489fdc6700):ZOO_ERROR@handle_socket_error_msg@1579: Socket [127.0.0.1:50187] zk retcode=-4, errno=111(Connection refused): server refused to accept the client
[23:50] <BeatsMusic> The host is up,  should i wait it out ?