[00:46] <arashbm> Hi there!
[00:46] <arashbm> I have a problem setting up local provider
[00:46] <arashbm> my juju is updated with ppa and my user is a member of 'libvirtd' group
[00:46] <arashbm> It appears that there is a problem in networking.
[00:46] <arashbm> error: Failed to start network default
[00:46] <arashbm> error: internal error Child process (/usr/sbin/dnsmasq -u libvirt-dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --except-interface lo --listen-address 192.168.122.1 --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases --dhcp-lease-max=253 --dhcp-no-override) status unexpected: exit status 2
[00:47] <arashbm> (it appears when I 'juju bootstrap')
[00:52] <arashbm> I don't know why but the problem suddenly solved right now after stopping dnsmasq ('sudo service dnsmasq stop').
[01:38] <hazmat>  arashbm sounds like you had multiple dns masqs running
[01:39] <hazmat> odd though, its directly listening on the interface
[01:39] <hazmat> but possibly the other one was binding to all interfaces
[01:41] <arashbm> I think it's the default behavier of stock dnsmasq (as stated in /etc/dnsmasq line 96)
[01:42] <arashbm> no sry
[02:30] <SpamapS> hazmat: something definitely broken with destroy-service
[02:30] <SpamapS> hazmat: several times I've done it and gotten 'no node' and had to run it again
[02:30] <SpamapS> hazmat: I'll debug and get you a proper bug report tomorrow
[02:30]  * hazmat takes a look
[04:13] <_mup_> juju/relation-hook-commands-spec r8 committed by jim.baker@canonical.com
[04:13] <_mup_> Removed support for using relation name with -r and corresponding proposal simplification; other edits
[04:14] <_mup_> juju/relation-info-command-spec r8 committed by jim.baker@canonical.com
[04:14] <_mup_> Now relation-ids and corresponding simplification
[04:16] <_mup_> juju/relation-reference-spec r10 committed by jim.baker@canonical.com
[04:16] <_mup_> Updated with respect to review comments
[04:58] <shazzner_> has anyone had experience with the ceph charm?
[04:59] <shazzner_> having some issues :/
=== almaisan-away is now known as al-maisan
[07:47] <arashbm> hi, I have a problem developing a charm,
[07:47] <arashbm> The problem is that not all service-units offer http interface, how can I manage that so that when for example haproxy is related to my service it only relates to those units offering http?
[07:48] <arashbm> Is there a good example of such behavior in any other charms so I can look in the source?
[09:22] <jaaap> trying to deploy a few juju charms locally on LXC.. but the charms are kept in state : pending. I installed wordpress, and in the /var/lib/lxc/ja-local-wordpress-0/rootfs/var/log/juju/unit-wordpress-0-output.log it's written "/usr/bin/python: No module named juju.agents" not sure if this is a bug, or if i'm doing something wrong
[09:25] <arashbm> jaap: check your proccess and network stats, It's doing something!
[09:26] <arashbm> jaap: took me a night of downloads (of course with 14KB/s)
[09:26] <arashbm> jaaap ^^
[09:36] <jamespage> morning all
[09:37] <jamespage> arashbm, still working on that generic rails charm?
[09:38] <jamespage> I was thinking about that last night
[09:39] <jamespage> arashbm, I think the best way todo this would be to fail the relation for service units that don't offer http interfaces
[09:39] <jamespage> the relation will then be marked as error - so uses know something is up
[09:39] <jamespage> arashbm, re generic charms - the only one we really have ATM is the node-js.app charm
[09:42] <arashbm> jamespage: yea! But I have problem sharing my code over Launchpad!
[09:42] <arashbm> It's blocked in our country! :|
[09:42] <arashbm> and I'm still trying to find a good example of services that offer an interface on only some units
[09:44] <jamespage> arashbm, thats not helpful now is it :-(
[09:45] <jamespage> arashbm, the closest I think you will get to it is to use the 'optional' field - https://juju.ubuntu.com/docs/charm.html#the-metadata-file
[09:45] <jamespage> but its not enforced
[09:46] <jamespage> arashbm, re the generic charm approach - I'm personally not sold on that
[09:46] <jamespage> I like the idea of a template charm for stuff like that
[09:46] <jamespage> but I think a charm should encapsulate a specific service
[09:46] <jamespage> just my personal opinion :-)
[09:49] <arashbm> jamespage, the problem is that a web serve or a worker in rails are very similar, they use the same code, operate the same environment, they user same db and so on.
[09:57] <jaaap> arashbm: how would you debug the lxc instance? the instances got not ip address but sshd seems to be running (not sure how to connect), does nothing on the network (tried tcpdump), juju writes the service is started "2012-03-22 09:44:56,511: juju.state.unit@INFO: Started service unit wordpress/0" but state from juju status is pending… hmm
[10:01] <arashbm> jaaap: on `juju debug-log` it states that it's 'Creating master container...'
[10:01] <arashbm> this step took me a long time with a spike in `perl` cpu usage
=== fenris is now known as Guest95871
[10:11] <jaaap> arashbm, weird though cause the system looks like it's doing nothing at all, cpu, men and network wise
=== al-maisan is now known as almaisan-away
[11:01] <zyga> hi
[11:01] <zyga> can I use juju to quickly spawn a VM for development?
[11:04] <arashbm> How could I set up a provider on a bare metal ubuntu server? I plan to use it for development only!
[11:06] <roubi> good morning
[12:43] <jaaap> i took me some while to figure out how LXC works, finally after understanding the lxc-console command i was able to access the LXC container of my wordpress deployment to see what was going on… nothing. I tried to run the wordpress/hooks/install script manually and it just took a couple of seconds to complete. I'm wondering where this get stuck. I see dhclicent tries to open /var/lib/dhcp3/dhclient.eth0.leases where the folder /var/lib/dhcp3 does no
[12:43] <jaaap> t exist… just creating this folder makes the dhclient writes it's config file. Not sure if this is the bug? Anyway, the LXC container is still not running. How would i know what commands juju are trying to execute once the LXC is started?
[12:44] <jaaap> correction, the LXC container is running but not the Juju service
[12:45] <jaaap> would like to develop and submit my plugin for tomorrow, but with the struggling of juju bugs makes it a bit more complicated
[12:53] <jdstrand> hello
[12:53] <jdstrand> so I'm fairly prficient with juju/lxc now and have workarounds for the things that blocked my before. so now I moved to openstack and juju
[12:54] <jdstrand> I have openstack running in a vm and it works perfectly fine with another client on the libvirt network starting and stopping instances via euca2ools
[12:55] <jdstrand> however, when I try to use juju, some weirdness happens. these are all VMs and not real credentials, so I am not redacting anything
[12:55] <jdstrand> here is my environments.yaml:
[12:55] <jaaap> i see juju fails to execute python inside the LXC container for my wordpress deployment
[12:55] <jaaap> root@ja-local-wordpress-0:~# /usr/bin/python -m juju.agents.unit --nodaemon --logfile /var/log/juju/unit-wordpress-0.log --session-file /var/run/juju/unit-wordpress-0-agent.zksession >> /var/log/juju/unit-wordpress-0-output.log
[12:55] <jaaap> /usr/bin/python: No module named juju.agents
[12:56] <jdstrand> http://paste.ubuntu.com/895046/
[12:57] <jdstrand> the juju started host doesn't respond to pings and nmap is filtered on the public address
[12:57] <jdstrand> I copied over my openstack.id_rsa* keys to the openstack vm and tried them on the private ip. ssh responded, but I couldn't login
[12:57] <jdstrand> $ ssh -i ./.ssh/precise_openstack.id_rsa root@10.0.0.2
[12:57] <jdstrand> Permission denied (publickey)
[12:57] <jdstrand> meh
[12:57] <jdstrand> $ ssh -i ./.ssh/precise_openstack.id_rsa ubuntu@10.0.0.2
[12:57] <jdstrand> Permission denied (publickey).
[12:57] <jdstrand> $ nmap -PN -p 22 10.0.0.2|grep ssh
[12:57] <jdstrand> 22/tcp open  ssh
[12:57] <jdstrand> $ nmap -PN -p 22 192.168.122.225|grep ssh
[12:57] <jdstrand> 22/tcp filtered ssh
[12:58] <jdstrand> $ ssh-keygen -l -f ./.ssh/precise_openstack.id_rsa.pub
[12:58] <jdstrand> 2048 a9:4c:a5:47:55:da:af:77:db:d3:19:84:d0:5e:fa:a3  jamie@sec-precise-amd64 (RSA)
[12:58] <jdstrand> $ nova keypair-list|grep mykey2
[12:58] <jdstrand> | mykey2 | a9:4c:a5:47:55:da:af:77:db:d3:19:84:d0:5e:fa:a3 |
[12:58] <jdstrand> so there are two things:
[12:58] <jdstrand> euca-describe-images shows that when running an instance via euca-run-instances, it is in the 'default' security group and 'running mykey2'
[12:58] <jdstrand> euca-describe-images shows that when running an instance via juju, it is in the 'juju-openstack, juju-openstack-0' security group and 'running None'
[12:59] <jdstrand> (note that './.ssh/precise_openstack.id_rsa.pub' is /home/jamie/.ssh/openstack.id_rsa.pub on sec-precise-amd64 (the machine *not* running openstack but that can run euca2ools fine)
[12:59] <jdstrand> )
[13:00] <jdstrand> euca-describe-groups has the following: http://paste.ubuntu.com/895048/
[13:01] <jdstrand> are these bugs I should file? is my environments.yaml wrong?
[13:02] <jdstrand> here is a euca-describe-instances output showing an instance started via euca2ools (i-0000000b) and one started via juju (i-00000007)
[13:02] <jdstrand> http://paste.ubuntu.com/895052/
[13:04] <jdstrand> both were started from sec-precise-amd64 and i-0000000b is fully functional/accessible but i-00000007 is not
[13:05] <jdstrand> looking at https://juju.ubuntu.com/docs/provider-configuration-ec2.html, it seems 'ec2-key-name' is no longer available...
[13:13] <jdstrand> I should perhaps mention that the openstack vm is running on up to date precise, as is the other vm (sec-precise-amd64)
=== almaisan-away is now known as al-maisan
[14:44] <arosales> jcastro: doing some browsing at omg and getting some "not founds"
[14:45] <arosales> for all banner links
[14:45] <arosales> ie http://omgubuntu.co.uk/go/2/http://www.omgubuntu.co.uk/2012/03/have-you-taken-the-ubuntu-user-survey/
[14:47] <jcastro> arosales, can you hard refresh and try again?
[14:47] <marcoceppi> jcastro: it doesn't look like the re-writes for that plugin are working. We'll have to add them to nginx
[14:47] <marcoceppi> err arosales ^
[14:48] <arosales> marcoceppi: ah, ok
=== niemeyer_ is now known as niemeyer
[15:02] <arosales> marcoceppi: and jcastro: nice work on OMG too, btw :-)
[15:12] <jcastro> robbiew, so our man brandon wants to charm up drupal with the same hotness as wordpress, but he's on a mac
[15:13] <robbiew> juju: guess needs to install ubuntu...or use a VM
[15:13] <robbiew> or wait until 12.10...no other real option unfortunately
[15:13] <jcastro> he's published mac software before, is it viable to show him the other work that was done perhaps?
[15:14] <robbiew> that could work
[15:14] <jcastro> ok I'll work that
[15:14] <m_3> jcastro: I think it's worth pushing a vagrant spin-up... it'll install virtualbox and get ubuntu server up and running pretty quickly
[15:15] <m_3> then lxc from there locally
[15:15] <jcastro> oh the thing you mentioned last night?
[15:15] <robbiew> doesn't AWS give t1.micro away?
[15:15] <jcastro> robbiew, that's exactly what we used with a shared byobu instance.
[15:15] <jcastro> it was pretty cool
[15:16] <robbiew> nice
[15:16] <jcastro> maybe after his charm imbrandon can work on that and/or a mac port. He's old school coredev so he knows how ubuntu works.
[15:17] <robbiew> just remember go-lang is coming ;)
[15:28] <_mup_> juju/environment-settings r487 committed by kapil.thangavelu@canonical.com
[15:28] <_mup_> work in progress
[15:49] <m_3> jdstrand: hi, reading backchannel now... I'll try to reproduce
[15:49] <jdstrand> m_3: thanks! :)
[16:11] <m_3> jdstrand: ok, so I'm checking the precise juju cli against openstack
[16:11] <m_3> jdstrand: meanwhile, here're a couple of things to check:
[16:11] <m_3> try just 'juju ssh 0'
[16:12] <m_3> key handling has changed lately, so I'm not sure... but I think juju injects the default key found in the cli's env
[16:12] <m_3> ec2-key-name is no longer used
[16:15] <_mup_> juju/trunk r490 committed by kapil.thangavelu@canonical.com
[16:15] <_mup_> [trivial] point juju to the charm store url [r=jimbaker,fwereade]
[16:15] <m_3> jdstrand: you might also try with a larger instance size... m1.tiny might not have the resources necessary (I know this is a prob on ec2 t1.micros, but don't know how this compares to tiby on nova)
[16:16] <m_3> jdstrand: I'll let you know in a bit if my previously-working juju openstack setup is still working with precise
[16:17] <jdstrand> m_3: trying, 'juju ssh 0', but with 'running None' and nmap telling me it is filtered, I am not optimistic
[16:17] <m_3> right
[16:17] <jdstrand> m_3: I in the console log that cloud-init completed
[16:17] <jdstrand> s/I/I saw/
[16:18] <jdstrand> juju ssh 0 just hangs
=== al-maisan is now known as almaisan-away
[16:19] <m_3> the biggest problem we've seen with juju on openstack has been that you either need to proxy ssh or attach a "public" address to the bootstrap node before issuing subsequent juju commands
[16:19] <jdstrand> m_3: what envvar do I need to set in the cli env for the ec2-key-name?
[16:20] <jdstrand> m_3: adam_g alerted me to that. I have setup /etc/nova/nova.conf to have --auto_assign_floating_ip. as mentioned, this works fine with euca2ools and you can see in my euca-describe-instances that it does have a the public address
[16:21] <m_3> jdstrand: 'authorized-keys: <public key>' might work for that... the last working setup I had was using ec2-key-name (oneiric)
[16:22] <m_3> jdstrand: authorized-keys do get injected by cloud-init in ec2... testing now on canonistack
[16:22] <jdstrand> m_3: I can try that-- do you care if I tear down this instance?
[16:22] <m_3> nope
[16:23] <jdstrand> m_3: to be clear, that should have the full 'ssh-rsa ...<key> <user>@<host>' that I would find in the public key?
[16:24] <m_3> jdstrand: yes... example https://pastebin.canonical.com/62855/
[16:26] <jdstrand> m_3: can I omit 'authorized-keys-path: /home/jamie/.ssh/openstack.id_rsa' (note this does not use my default ssh key)
[16:26] <m_3> usually have to watch lp output of import-ssh-id for CRs though
[16:26] <m_3> yes, I'd pitch that
[16:28] <jdstrand> m_3: this key is not in lp. should it be? this isn't canonistack, this is a private openstack (https://wiki.ubuntu.com/SecurityTeam/TestingOpenStack)
[16:28] <m_3> jdstrand: no need, just common practice to `import-ssh-id <id> >> .juju/environments.yaml` and edit
[16:29] <jdstrand> oh I see what you mean
[16:29] <jdstrand> I thought you meant for the juju instance or something
[16:31] <jdstrand> m_3: still have 'running None' in euca-describe-instances. here is updated yaml: http://paste.ubuntu.com/895293/ (again, these creds don't mean anything in the real world)
[16:33] <m_3> jdstrand: ok, gimme a few to see what I can spin up
[16:33] <jdstrand> m_3: fyi, euca-get-console-output shows the instance is installing things
[16:34] <jdstrand> an ssh keypair was generated
[16:35] <jdstrand> m_3: oh! this time the instance responded when I did 'ssh -i ./.ssh/openstack.id_rsa 192.168.122.225'
[16:35] <jdstrand> m_3: however, could not login
[16:35] <m_3> jdstrand: hmmm
[16:35] <m_3> juju ssh 0?
[16:36] <m_3> is it hanging or denying?
[16:36] <jdstrand> $ juju ssh 0
[16:36] <jdstrand> 2012-03-22 11:35:56,477 INFO Connecting to environment...
[16:36] <jdstrand> 2012-03-22 11:35:59,915 ERROR Invalid SSH key
[16:36] <m_3> nice
[16:36] <jdstrand> I wonder if there is a race with the first time euca-authorize is used
[16:36] <jdstrand> aiui, the security groups need to be in place before the instance is started
[16:37] <m_3> each instance gets a new security group last I checked
[16:37] <m_3> so they're adding new ones during startup
[16:37] <jdstrand> destroy-environment does seem to clean them up
[16:38] <m_3> and yeah, it's gotta be there first... then can be changed afterwards with 'juju expose'
[16:38] <jdstrand> something certainly didn't work right earlier today with that though
[16:38] <jdstrand> (even though euca-describe-groups showed the groups were there)
[16:40] <m_3> it's worth trying it without authorized-keys or authorized-keys-path at all
[16:41] <jdstrand> m_3: wouldn't that just add my default key? how would juju know to use the one I added to nova?
[16:42] <m_3> it wouldn't use the one you added to nova... it would just inject your default
[16:42] <m_3> don't think the nova one is necessary... that's injected by default so euca-tools can talk
[16:43] <jdstrand> right, so it wouldn't match my keypair. I'm assuming that is significant
[16:43] <jdstrand> hmmm, I am used to specifying -k <keypair> with euca-run-instances
[16:43] <m_3> right
[16:44] <jdstrand> I figured juju operated in a similar fashion
[16:44] <m_3> juju injects its own... that _used_ to be what you told it to with `ec2-key-name`
[16:44] <m_3> and it injects `authorized-keys`
[16:44]  * m_3 looking to see if 'juju ssh' will take '-i'
[16:45] <jdstrand> ok, then I guess the 'running None' bit makes sense
[16:45] <m_3> so it seems like the problematic part is convincing the juju cli to use a particular key
[16:45] <jdstrand> cause juju isn't doing the -k <keypair> equivalent to let nova know
[16:46] <m_3> just guessing man... I need to look at the code to see what the latest behavior really is
[16:47] <jdstrand> oh, now 'ssh -i ./.ssh/openstack.id_rsa ubuntu@192.168.122.225' worked
[16:47] <jdstrand> juju ssh 0 does not
[16:48] <m_3> right... we injected the public part of openstack.id_rsa, but aren't telling 'juju ssh' which keys to use
[16:48] <m_3> does 'juju status' say permission denied?
[16:48] <jdstrand> 2012-03-22 11:48:42,970 ERROR Invalid SSH key
[16:49]  * jdstrand tries with authorized-keys-path
[16:50] <jdstrand> $ juju status
[16:50] <jdstrand> Environment config cannot define both authorized-keys and authorized-keys-path. Pick one!
[16:50] <jdstrand> 2012-03-22 11:50:31,096 ERROR Environment config cannot define both authorized-keys and authorized-keys-path. Pick one!
[16:55] <m_3> jdstrand: did you try with neither option defined?
[16:57] <m_3> you'd have to bounce the environment, but it should inject your default key... and then _use_ that key to talk to the instance
[16:57] <jdstrand> m_3: I will try that in a moment
[16:57] <jdstrand> I think before I specified the private key to authorized-keys-path
[16:58] <m_3> oh gotcha
=== zyga is now known as zyga-food
=== fenris is now known as Guest70667
=== Guest70667 is now known as ejat
[17:20] <jdstrand> m_3: /win 30
[17:20] <jdstrand> meh
[17:20] <jdstrand> m_3:
[17:20] <jdstrand> argh
[17:21] <jdstrand> m_3: so, it seems that only after cloud-init is done does the image become unreachable
[17:21] <jdstrand> I will try m1.small now
[17:25] <m_3> jdstrand: ok
[17:25] <marcoceppi> Can I set the value of a config in a charm?
[17:26] <jdstrand> m_3: I'm going to file several bugs surrounding the ssh stuff in the meantime
[17:26] <marcoceppi> Sorry, that was a fractured question. I want to set the value of a config key in a hook, does config-set exist and does is it accessible to hooks?
[17:26] <m_3> marcoceppi: from a hook... not at the moment... you have to use 'juju set' from the cli
[17:26] <marcoceppi> darn, k
[17:27] <marcoceppi> I'm trying to capture a one-time routine, in this case flushing cache on all the units a charm runs on, so my idea was juju set flush-cache=true and have the hook reset it to false when it finished execution. Any ideas on a best practice for this?
[17:29] <jcastro> hazmat, look in your g+ window please
=== zyga-food is now known as zyga
[17:43] <jdstrand> m_3: *sigh* my problem is that the bootstrap node installs libvirt-bin, which starts the 192.168.122.0/24 default network, which happens to be the ip address that the instance's public ip address is in
[17:43] <m_3> yikes
[17:43] <jdstrand> m_3: why does this node need libvirt-bin?
[17:44] <jdstrand> s/node/instance/
[17:44] <m_3> jdstrand: there've been _lots_ of problems with lxc doing the same sort of thing
[17:44] <m_3> jdstrand: that's a bug
[17:44] <m_3> jdstrand: it's a dep of the juju package because of LXC
[17:44] <jdstrand> m_3: ok, I'll file a bug on it
[17:45] <m_3> I thought that was filed and fixed in the ppa... looking now
[17:45] <jdstrand> m_3: one way to solve this would be to break up the juju package to have juju-lxc, which is just a metapackage
[17:46] <SpamapS> its not Depends
[17:46] <SpamapS> its Recommends
[17:46] <jdstrand> then juju can Suggests it and the tools can tell you to install juju-lxc if it is missing
[17:46] <SpamapS> the problem is juju installs itself without doing --no-install-recommends
[17:46] <m_3> ah
[17:46] <jdstrand> ok, that would work too
[17:46] <SpamapS> we don't actually need the 'juju' package for agents though
=== koolhead17|away is now known as koolhead17
[17:47] <SpamapS> I think we should probably split the package into juju-core and juju .. and only install juju-core on the boxes
[17:48] <SpamapS> and juju would just be a metapackage
[17:48] <jdstrand> SpamapS: filing a bug now
[17:49] <m_3> marcoceppi: as a cache-flush, it's probably safe to do it whenever 'juju set' is called... you might not need anything complicated there
[17:50] <marcoceppi> m_3: good point, especially since there are only two other config settings and they're only for s3 access keys
[17:51] <SpamapS> hazmat: ^^ splitting juju into two packages might be simpler than trying to refactor the cloudinit stuff to use --no-install-recommends
[17:51] <SpamapS> hey can we get the bug bot in here to also watch the bugs for the ubuntu juju package?
[17:58] <jdstrand> SpamapS, hazmat: fyi, bug #962389
[17:58] <_mup_> Bug #962389: juju Recommends on lxc installs libvirt-bin which causes problems when testing in virtualized environments <juju (Ubuntu):New> < https://launchpad.net/bugs/962389 >
[17:58] <SpamapS> jdstrand: thanks... I may end up marking it as a duplicate of the other one we have open, but for now its good to have both
[17:59] <SpamapS> jdstrand: btw I'm almost done refactoring aws-status into indicator-aws.. :)
[18:00] <jdstrand> SpamapS: thanks, any idea when this might be fixed? I need to figure out some way to workaround this to finish my mir
[18:00]  * jdstrand really doesn't want to have to regenerate his openstack vm
[18:02] <SpamapS> jdstrand: well the simplest thing would be to drop the Recommends
[18:03] <SpamapS> jdstrand: since juju bugs you about the package being missing.. perhaps thats the best short term solution
[18:03] <jdstrand> if juju bugs you about it, then that does make sense (assuming it only bugs you when trying to use 'local:'
[18:03] <SpamapS> in fact.. I think I will do that.. not everybody uses local
[18:03] <SpamapS> jdstrand: yeah, it handles the missing package gracefully enough that I think we can just make it a suggests
[18:04] <SpamapS> jdstrand: you may as well suspend your MIR anyway, I expect a FFE + Upload today
[18:04] <jdstrand> awesome. that would work great for me :)
[18:04] <SpamapS> jdstrand: I'll fix that bug in that upload as well.
[18:04] <jdstrand> well, I have been working on it for days :)
[18:04] <SpamapS> jdstrand: new provider is landing.. maas
[18:05] <jdstrand> SpamapS: would you mind pinging me when you upload?
[18:05] <SpamapS> jdstrand: I will ping you straight away yes
[18:05] <jdstrand> thanks
[18:14] <m_3> sad but true: charmtests.markmims.com... fixing the remaining charms with config.yaml typing issues now
[18:17] <SpamapS> m_3: What a long strange trip it's been
[18:18] <m_3> SpamapS: yup
[18:35] <marcoceppi> A boolean config value, does it get translated to 0,1 or stay False,True?
[18:36] <m_3> marcoceppi: dude... don't even ask
[18:36] <SpamapS> hahahaha
[18:36] <marcoceppi> <3 :D
[18:36] <SpamapS> should be documented anyway
[18:37] <SpamapS> I believe it will be 'False' or 'True'
[18:37]  * marcoceppi makes a quick test
[18:37] <SpamapS> since its just printed with  str(value)
[18:37] <SpamapS> unless you ask for json
[18:37] <m_3> yeah, it'll look like a string in the hook
[18:37] <SpamapS> then it will be json pure
[18:37] <m_3> which makes one wonder the value of strong typing
[18:38] <marcoceppi> my bad, I really just wanted ENUM() for config options, to keep people from doing stupid things, got booleans instead
[18:38] <SpamapS> m_3: as long as we use python it won't matter.. and Go will have to make sure it continues to print the values the same at least in the first release so we can transition.
[18:38] <SpamapS> marcoceppi: yes, enum would be fantastic
[18:41] <m_3> nice... charms that mix boolean:FALSE and int:1 in the same config
[18:41] <m_3> (the int:1's used as a bool of course)
[18:44] <SpamapS> m_3: I hope that at some point we can go back and clean up the old crusty charms that existed before we knew what a good charm was ;)
[18:45] <m_3> SpamapS: me too... we can make a fix-it-friday or soemthing
[18:45] <m_3> :)
[18:46] <m_3> actually I'd like to get 'deprecated' parts into all the interfaces while still on oneiric
[18:46] <m_3> then we can actually deprecate them in the bump to precise
=== hspencer is now known as hspencer[afk]
[19:23] <jimbaker> niemeyer, hazmat what did i do wrong in the code review of https://codereview.appspot.com/5836049/ ? i see the new version here https://codereview.appspot.com/5836049/patch/8001/9002, but it's not linked to the review comments https://codereview.appspot.com/5836049/diff/5001/source/drafts/relation-reference.rst
[19:30] <hazmat> jimbaker, each submit generates a new diff that is empty of comments, previous comments are linked to diff revisions on the issue.
[19:36] <_mup_> juju/trunk r491 committed by kapil.thangavelu@canonical.com
[19:36] <_mup_> remove ability to spec charm store url via env variable per request.
[19:47] <jimbaker> hazmat, so what should the flow be?
[20:02] <marcoceppi> Should upgrade-charm put new configuration options in place on the charm? Or does it need a destroy/deploy?
[20:03] <jdstrand> SpamapS: I neglected to say anything about indicator-aws
[20:03] <jdstrand> SpamapS: cool! :)
=== hspencer[afk] is now known as hspencer
[20:19] <hazmat> jimbaker, not sure what your asking, the flow is typically you respond to previous review points via comments, work on the changes, resubmit and get a fresh review
[20:20] <SpamapS> marcoceppi: config-get *should* see them
[20:20] <jimbaker> hazmat, so the flow is lbox propose ... address comments ... lbox submit ... more work ...  lbox submit ...
[20:20] <SpamapS> marcoceppi: and config-changed should run when they're changed.
[20:21] <hazmat> jimbaker, yup
[20:21] <marcoceppi> SpamapS: juju doesn't let me set against the units
[20:22] <marcoceppi> let me try another upgrade
[20:22] <jimbaker> hazmat, backing up... sounds like there's a fresh review in place then at https://codereview.appspot.com/5836049/patch/8001/9002
[20:23] <jimbaker> so should be all set
[20:24] <SpamapS> marcoceppi: juju set omg-wp clear_cache=something isn't working?
[20:26] <niemeyer> SpamapS: juju is consistently getting stuck on juju status in 486
[20:26] <niemeyer> SpamapS: Are there (or were) any known issues around htat
[20:26] <niemeyer> ?
[20:26] <marcoceppi> SpamapS: yeah, but I think upgrade-charm failed
[20:32] <m_3> ok, much better... charmtests.markmims.com
[20:32] <SpamapS> niemeyer: nothing I'm aware of
[20:32] <SpamapS> marcoceppi: the hook failed?
[20:32] <marcoceppi> \o/ minecraft is fixed
[20:33] <marcoceppi> SpamapS: it looks like the upgrade-charm hook failed
[20:34] <marcoceppi> So, nevermind
[20:45] <eb015> I have a problem with bootstrap in juju: error: Environments configuration error: /home/localadmin/.juju/environments.yaml: environments.orchestra.acquired-mgmt-class: required value not found
[20:48] <SpamapS> eb015: are you trying to use orchestra?
[20:55] <_mup_> juju/trunk r492 committed by kapil.thangavelu@canonical.com
[20:55] <_mup_> [trivial] update store unit test to point to temporary elastic ip
[21:03] <eb015> yes
[21:07] <eb015> My environments.yaml is juju: environments
[21:09] <eb015> What's mean update store unit test to point to temporary elastic ip?
[21:10] <imbrandon> marcoceppi: at some point in the next ~12 hour i'll do that op code cache clear, its very simple , just need to get my bearing waking up and such
[21:17] <eb015> I'm trying to use orchestra...
[22:37] <marcoceppi> imbrandon: I've already got something in place, it's not elegant though
[22:40] <imbrandon> marcoceppi: rockin kk
[23:17] <_mup_> juju/trunk r493 committed by kapil.thangavelu@canonical.com
[23:17] <_mup_> [trivial] full test suite update for cs url, update all references to use a constant in repository mod