[00:00] <SpamapS> Eh, but I have a variable with raw bytes from a file.
[00:00] <SpamapS> and I want to print them out
[00:00] <niemeyer> SpamapS: foo.decode("utf-8"), for instance
[00:00] <SpamapS> actually.. I think for this..
[00:00] <niemeyer> SpamapS: Which yields unicode
[00:00] <SpamapS> config-get and relation-get need to have a --format=raw ..
[00:00] <niemeyer> Or rather, the Python notion of unicode
[00:00] <SpamapS> because right now we're tacking on a \n
[00:01] <niemeyer> SpamapS: Yeah, possibly
[00:01] <SpamapS> Ok, well at the moment, high-byte chars in config/relation settings will likely cause a stacktrace
[00:01]  * SpamapS tries it
[00:03] <SpamapS> actually no .. hm
[00:04] <SpamapS> json format encodes it in proper json notation
[00:04] <SpamapS>  config-get --format=json disable-large-pages
[00:04] <SpamapS> "\u5b50"
[00:07] <kees> 子 made me look
[00:07] <SpamapS> hahaha
[00:08] <SpamapS> Thought about going with a 3 byte char but thats just not playing fair ;)
[00:08] <SpamapS> ok so unicode does cause an error.. but config-get and relation-get just silently swallow it
[00:09] <SpamapS> or rather.. high byte chars
[00:30] <_mup_> Bug #901494 was filed: config-get and relation-get silently drop values with high-byte characters <juju:New> < https://launchpad.net/bugs/901494 >
[00:42] <_mup_> Bug #901495 was filed: config-get and relation-get silently drop values with high-byte characters <juju:Triaged> < https://launchpad.net/bugs/901495 >
[01:12]  * SpamapS continues his bug triage RAMPAGE
[01:35] <hazmat>  elmo its on the wishlist
[01:36] <elmo> hazmat: not having a go at you, but FWIW if I didn't work in Canonical, I can't imagine using juju in a production environment without that bug being fixed
[01:37] <hazmat> elmo, part of the issue with bothering with the acls, is that there isn't any transport level security
[01:37] <hazmat> elmo, but fair enough... does puppet or chef have any notion of multi-user?
[01:38] <hazmat> granted at the level of acl granularity without transport level security, its just about consistency from compromised nodes,
[01:39] <hazmat> which a ca will give you..
[01:39]  * hazmat wonders about keystone
[02:02] <SpamapS> hazmat: puppet and chef do have to at least verify each node individually before they're allowed to do things like export configs or shot data into data bags.
[02:02] <SpamapS> s/shot/shove/
[02:04] <SpamapS> $ killall java
[02:04] <SpamapS> so true
[02:40] <osa> hi folks, can you please explain how i can change a "unit" status from stop to start using juju?
[03:36] <SpamapS> doh
[03:47] <smoser> SpamapS, i'm maingly walking through http://askubuntu.com/questions/65359/how-do-i-configure-juju-for-local-usage
[03:48] <smoser> trying to get localdev . oneiric host, i pulled juju from bzr.
[03:48] <smoser> after 'juju bootstra', i got
[03:49] <smoser> SSH authorized/public key not found.
[03:49] <smoser> 2011-12-08 03:44:11,349 ERROR SSH authorized/public key not found.
[03:49] <smoser> then made myself a key (ssh-keygen)
[03:50] <smoser> now juju status shows
[03:50] <smoser> http://paste.ubuntu.com/763416/
[05:35] <SpamapS> smoser: there are a bunch of logs in weird places you can check
[05:36] <smoser> i destroyed and started over and fine.
[05:36] <SpamapS> smoser: but ultimately, I think your main machine is not started
[05:36] <smoser> probably a bug though if you dont have .ssh/id_rsa
[05:36] <SpamapS> smoser: have you tried a destroy-environment and bootstrap again?
[05:36] <smoser> yeah, and that worked.
[05:36] <smoser> we can poke at a later date.
[05:37] <smoser> heres the initial stab i made at juju local provider -> openstack
[05:37] <smoser> http://paste.ubuntu.com/763456/
[05:37] <smoser> (unsuccessful atm)
[05:49] <SpamapS> smoser: I like the way the config file pans out... one big yaml for the whole thing
[05:49] <smoser> thats all adam_g
[05:50] <smoser> do we know what that internal error network issue is about ?
[05:50] <smoser> that forces a reboot?
[05:50] <SpamapS> the pty thing?
[05:52] <SpamapS> I think it must be an lxc bug
[05:52] <SpamapS> if you're talking about how ssh starts to fail on the containers
[05:56] <smoser> not pty, SpamapS
[05:57] <smoser> libvirt network issue on 'juju bootstrap'
[05:57] <smoser> was reproducible 2/2 for me on oneiric instance in canonistack.
[06:07] <SpamapS> OH
[06:07] <SpamapS> That I don't know
[06:07] <SpamapS> smoser: the wya virsh is used is kind of weird..
[06:07] <SpamapS> way even
[06:08] <smoser> i thought so too
[06:08] <SpamapS> I believe its done that way so that juju can just sudo out for those few things
[06:08] <SpamapS> but.. seems like juju could just fork and sudo exec itself..then use libvirt.
[06:09] <smoser> nah, its not that.
[06:09] <SpamapS> or leave the network alone
[06:09] <smoser> not just the groups.
[06:09] <smoser> something else i think.
[06:09] <SpamapS> my old crappy lxc provider just let libvirt's default network do the dirty work
[06:12] <SpamapS> smoser: is a bug filed about the network problems?
[06:12] <SpamapS> smoser: IIRC there was one that involved non-english locales that was fixed right after 11.10 released
[06:13]  * SpamapS should just go through the 29 commits since 11.10 and cherry pick the bug fixes into an SRU
[06:13] <smoser> dont know if ther eis a bug
[06:13] <smoser> it is documented at http://askubuntu.com/questions/65359/how-do-i-configure-juju-for-local-usage
[06:14] <SpamapS> smoser: documented pretty scantily
[06:14] <smoser> google "juju local"
[06:14] <smoser> thats what you come up with
[06:15] <smoser> yes, its crappy documentation of that bug. and there should be a bug.
[06:16]  * SpamapS went on a triage rampage today, so may be leaning a bit too much toward "File a bug"
[06:16] <SpamapS> took new bugs from 75 -> 55 .. but .. still 184 open bugs.. we have to figure out which ones of those actually matter. :-P
[07:37] <TheMue> moo
[07:42] <rog> TheMue: mornin'
[07:49] <TheMue> Wonna setup an EC2 instance today. Any useful hints before I step into a common known trap?
[09:15] <mpl> hi all
[09:17] <TheMue> hi mpl
[10:34] <TheMue> hmm, mysql up and running on a second instance. how may I login via ssh to an instance?
[10:42] <koolhead11> hi all
[10:43] <nijaba> TheMue: via juju ssh?
[10:47] <TheMue> nijaba: Ah, that's the missing link. thx
[10:48] <nijaba> np
[10:48] <nijaba> TheMue: I tend to use this a lot less than 'juju debug-hooks' in my (small) practice of charm dev
[10:49] <TheMue> neat
[10:49]  * koolhead11 installed oneiric and will try juju on local system
[10:50] <TheMue> nijaba: yep. I'm just doing my fist steps and want to look around a bit.
[10:51] <nijaba> marcoceppi: did you change ch_get_file recently, or was I wrongly assuming that the downloaded file would always be /tmp/download?
[10:52] <koolhead11> jcastro: around
[10:53] <nijaba> koolhead11: jcastro is on vacation this week
[10:53] <koolhead11> nijaba: ok. am using http://askubuntu.com/questions/65359/how-do-i-configure-juju-for-local-usage
[10:53] <nijaba> (which does not mean he is not around though)
[10:53] <koolhead11> nijaba: :P
[10:53] <nijaba> koolhead11: sorry, never tried myself yet
[10:54] <koolhead11> nijaba: np. i am giving it a try :D
[10:54] <nijaba> koolhead11: I would be interested in your findings :)
[10:54] <koolhead11> sure
[10:55] <koolhead11> smoser: i think its my openstack and networking which gave put me in all the trouble
[10:55] <koolhead11> i want to play with juju so i need to see that working :D
[10:56] <koolhead11> customized cloud image would not b having any issue.
[10:56] <koolhead11> #optimistic thinking :D
[11:08] <koolhead11> Am i supposed to do any configuration for networking? http://paste.ubuntu.com/763669/
[11:10] <drt24> could someone fix: https://help.ubuntu.com/community/Orchestra/Juju so that the orchestra environment has a default-series as otherwise juju complains of it being invalid (currently having problems with my ubuntu sso)
[11:20] <drt24> Also having fixed that I get "Could not find any Cobbler systems marked as available and configured for network boot." though I have two VMs who booted off it.
[11:23] <jseutter> juju bootstrap fails with "error: internal error Network is already in use by interface virbr0".  Does anyone know how to fix this?
[11:24] <koolhead11> jseutter: reboot your machine
[11:24] <koolhead11> i had same error
[11:24] <jseutter> koolhead11: I've tried that twice, with no change
[11:24] <koolhead11> and You may also need to set the net.ipv4.ip_forward=1 in you /etc/sysctl.conf.
[11:24] <jseutter> k, taking a look
[11:25] <jseutter> hm, do I need to reboot after modifying sysctl.conf?
[11:26] <jseutter> rebooting.
[11:26] <koolhead11> aah not needed
[11:29] <koolhead11> marcoceppi: hey there
[11:30] <koolhead11> jseutter: it was not needed
[11:30] <koolhead11> now you will get an error for missing keypair
[11:30] <koolhead11> so generate one
[11:30] <koolhead11> :D
[11:30] <jseutter> koolhead11: ah.
[11:30] <koolhead11> :P
[11:30] <jseutter> koolhead11: I still get the same error: Network is already in use by interface virbr0
[11:31] <koolhead11> jseutter: but i don`t pastebin the whole output
[11:31] <koolhead11> i just added net.ipv4.ip_forward=1 in you /etc/sysctl.conf
[11:31] <koolhead11> this line and did juju bootstrap
[11:31] <koolhead11> next error i got now is for keygen
[11:32] <jseutter> koolhead11: hm...  I must have a different issue then...
[11:32] <koolhead11> jseutter: your using Oneiric
[11:32] <koolhead11> ?
[11:32] <jseutter> koolhead11: yes
[11:32] <koolhead11> http://askubuntu.com/questions/65359/how-do-i-configure-juju-for-local-usage
[11:32] <koolhead11> see this
[11:33] <koolhead11> am thinking to edit this with putting <bold> in the error part and also add the missing key error
[11:42] <drt24> solution to bootstrap not working: sudo cobbler system edit --name your-system-name --netboot-enabled=True --mgmt-classes=orchestra-juju-available
[11:43] <jseutter> koolhead11: hm.  Yeah, that askubuntu page you referenced results in me getting the same error still
[11:44] <jseutter> koolhead11: unless I'm misunderstanding something you're trying to tell me
[11:45] <koolhead11> jseutter: i also tried juju while having conversation with u and faced same errors
[11:45] <koolhead11> drt24: ?
[11:46] <jseutter> koolhead11: ah.  I was originally following the CharmSchool page on the juju site, then found the error, then came here to irc.
[11:47] <jseutter> koolhead11: ahasenack has it working.  I have a mac - what about you?
[11:47] <koolhead11> jseutter: well i have ubuntu :d
[11:47] <jseutter> :P
[11:47] <jseutter> koolhead11: just wondering if it is hardware related.
[11:47] <koolhead11> jseutter: so your running ubuntu inside some VM or however it works in mac
[11:48] <jseutter> koolhead11: no, I'm running ubuntu on mac hardware
[11:48] <nijaba> jseutter: any chance you are connected to network via wifi?
[11:48] <jseutter> nijaba: yes, I'm on wifi
[11:49] <nijaba> jseutter: I don't think wifi supports bridging
[11:49] <drt24> koolhead11: I asked a question earlier, and that was the solution.
[11:49] <nijaba> jseutter: in fact I know for a fact it does not
[11:49] <nijaba> jseutter: limitation in the wifi drivers
[11:49] <koolhead11> aaaaaaaaaaah nijaba if that is the case am going to edit askubuntu doc again :D
[11:50] <nijaba> koolhead11: we had the same pb with kvm a few years back
[11:50] <koolhead11> ooh. ok
[11:51] <nijaba> "Warning: Network bridging will not work when the physical network device (e.g., eth1, ath0) used for bridging is a wireless device (e.g., ipw3945), as most wireless device drivers do not support bridging!"
[11:51] <nijaba> from https://help.ubuntu.com/community/KVM/Networking#bridgednetworking
[11:51] <ahasenack> nijaba: the bridge does not involve the wifi interface
[11:51] <ahasenack> nijaba: it's just like firing up local kvm instances that use libvirt
[11:51] <ahasenack> nijaba: the guest is not getting an IP address from the LAN dhcp server, but from libvirt
[11:52] <ahasenack> it's 192.168.122.X
[11:52] <nijaba> ahasenack: ah...  ok, sorry
[11:52] <nijaba> koolhead11: jseutter: ^^
[11:53] <jseutter> nijaba: nod.  I'm sitting beside ahasenack
[11:53] <koolhead11> nijaba: ooh am going to remove the comment i just added :(
[12:02] <koolhead11> nijaba: i am done with $ juju expose wordpress
[12:05] <koolhead11> but state seems to be null http://paste.ubuntu.com/763702/
[12:09] <nijaba> koolhead11: whoa, weird
[12:10] <koolhead11> nijaba: :P
[12:11] <jseutter> hm..  If I run juju bootstrap as root, then it works
[12:11] <koolhead11> http://paste.ubuntu.com/763706/
[12:11] <koolhead11> in verbose
[12:12] <koolhead11> jseutter: where is your config file locates
[12:12] <koolhead11> d
[12:12] <jseutter> ~/.juju/environments.yaml
[12:16] <koolhead11> and its owned by ordinary user with sudo access correct?
[12:17] <koolhead11> i just started the debug log
[12:17] <drt24> Any idea on what to fix when using orchestra and deploying using juju fails with "Invalid host for SSH forwading: ssh: Could not resolve hostname small0.orchestra.lan: Name or service not known" (the orchestra server does indeed not know what IP small0.orchestra.lan should point to - though cobbler does.
[12:17] <koolhead11> and i can see 2011-12-08 17:45:58,864 Machine:0: unit.deploy DEBUG: Creating master container...
[12:18] <jseutter> logging off to save battery
[12:19]  * koolhead11 wonders if he should file a bug.
[12:47] <TheMue> After adding a relation between mysql and wordpress (like in the tutorial), why is the relation called db? Is this part of one of the both charms?
[13:03] <marcoceppi> nijaba: The path to the dowloaded file is returned from the func. You should be doing something like DOWNLOADED_FILE=`ch_get_file ... ...`
[13:03] <nijaba> marcoceppi: yes, I figured that, but it seemed to have worked differently previously, or I was on crack
[13:04] <koolhead17> nijaba: i figured out what i was doing wrong. :)
[13:04] <koolhead17> it takes good time to reach  state: started
[13:04] <marcoceppi> nijaba: I did, but it didn't work for things like downloading from source forge, or dynamic download scripts since the file was being saved as "download" or "download.php?id=x". This update ensures the file name stays intact, the downside is it's not saved in /tmp/ anymore
[13:05] <koolhead17> and also i have to use $ juju deploy --repository=/usr/share/doc/juju/examples local:wordpress
[13:05] <SpamapS> TheMue: db is just a free-form identifier name hat is supposed to put in context the interface.. so for instance in mediawiki ther is a need for a slave: and db: both with interface: mysql
[13:05] <nijaba> marcoceppi: ah, so I was not on crack then :P
[13:05] <koolhead17> hola SpamapS i finally juju running :D
[13:05] <marcoceppi> I don't know why I didn't get your charm picked up. I pulled all the official charms down and ran a grep for anyone using ch_file_get to make sure it was being assigned
[13:05] <nijaba> marcoceppi: my charmed worked, then broke, so I was surprised
[13:05] <koolhead17> via LXC though
[13:06] <marcoceppi> I should go check the charms again
[13:06] <nijaba> marcoceppi: fixed now, so no worried.  Will have to wait for someone to approve my merge proposal
[13:07]  * koolhead17 is happy!!
[13:09]  * marcoceppi reviews
[13:11] <marcoceppi> nijaba: Why are you also echoin' the error in limesurvey-common?
[13:11] <nijaba> marcoceppi: easier to debug?  would that be a pb?
[13:12] <marcoceppi> It's not a problem, I was just curious since no one would really see the echo - It would just show up in the juju-log :)
[13:16] <nijaba> marcoceppi: unless you are using juju debug-hooks
[13:17] <marcoceppi> Oh, duh.
[13:17] <marcoceppi> It is a little early here for me
[13:17] <nijaba> np :P
[13:24] <marcoceppi> nijaba: Shoot, just realized that the upgrade-hook wasn't updated to use the new ch_get_file
[13:26] <nijaba> marcoceppi:  it should just be a link...
[13:26] <nijaba> marcoceppi: to install
[13:26]  * marcoceppi wanders off to get coffee
[13:27] <TheMue> SpamapS: Thx, found the definition in the charms.
[13:48]  * nijaba got his roundcube charm working :)
[13:48] <koolhead17> nijaba: :D
[13:59] <SpamapS> nijaba: *Saweet*
[14:00] <SpamapS> BTW, sabdfl and I are running a webinar in 1 hour...
[14:00]  * SpamapS fishes out the link
[14:00] <SpamapS> http://www.brighttalk.com/webcast/6793/39309
[14:02] <nijaba> SpamapS: just retweeted about it
[14:02] <SpamapS> nijaba: ty, retweeted
[14:03] <koolhead17> SpamapS: good luck!! :)
[14:04] <SpamapS> nijaba: in your limesurvey charm.. you shouldn't need to juju-log *and* echo..
[14:04] <SpamapS> juju-log should be echoing its message
[14:16] <nijaba> SpamapS: 1300 registrations to your webinar!
[14:22] <SpamapS> only 1300? ;)
[14:25] <hazmat> nice
[14:25]  * hazmat wades through the aftermath of SpamapS's bug-rampage
[14:35] <drt24> how do I tell if juju bootstrap is making progress?
[14:38] <SpamapS> drt24: thats the one step that we don't have much insight into, because it starts the first juju agents on new machines
[14:39] <nijaba> SpamapS: regarding juju-log, this is not what I am observing :(
[14:39] <drt24> SpamapS: is there a log somewhere of what it is doing?
[14:39] <SpamapS> nijaba: hrm, we should fix that, though I can see why it might not.. because then the messages would double up in the charm log
[14:39] <koolhead17> drt24: juju -v bootstrap
[14:39] <koolhead17> does gives some info
[14:39] <SpamapS> yes, but that will not tell you what the new instance is doing
[14:40] <SpamapS> drt24: if its an ec2 instance, you can use ec2-get-console-output .. but that sometimes lags by a couple of minutes
[14:40] <SpamapS> drt24: juju status will try to wait a bit for the instance to be started
[14:40] <drt24> I am using orchestra
[14:40] <SpamapS> drt24: for orchestra, you should have logs from the install on the orchestra server
[14:41] <SpamapS> drt24: I don't recall the exact location for them, but /var/log/syslog *might* have it
[14:41] <drt24> juju status just gets "ERROR Connection refused" after juju bootstrap says it has finished successfully.
[14:41] <SpamapS> drt24: right thats because the install hasn't completed yet
[14:42] <koolhead17> drt24: juju -v status
[14:43] <drt24> syslog has lots of "Could not open dynamic file '/var/log/orchestra/rysyslog/.../cron' - discarding message
[14:44] <SpamapS> drt24: yeah I think thats a bug.. have to create the dirs underlying those logs and it will fill them up
[15:01] <nijaba> duh, I wrongly changed bug #795479 to fix released instead of proposed, and now I can't change it back :(
[15:01] <_mup_> Bug #795479: Charm needed: roundcube <new-charm> <juju Charms Collection:Fix Released by nijaba> < https://launchpad.net/bugs/795479 >
[15:06] <nijaba> SpamapS: sounds great :)
[15:07] <drt24> "ERROR 'dict' object has no attribute 'read'" when running juju bootstrap.
[15:09] <drt24> File "/usr/lib/python2.7/dist-packages/juju/providers/orchestra/launch.py" line 45
[15:22] <hazmat> rog, what version of go are we using? stable, weekly, tip?
[15:22] <rog> hazmat: weekly.
[15:23] <rog> hazmat: it's fast moving at the moment, but stable is just too old
[15:23] <hazmat> rog, cool, thanks
[15:42] <mpl> rog: so I've played with exp/ssh a bit (just connecting a client to a server), and it seems at first sight that there's no out of the box mechanism to do port forwarding (which is what python juju uses iiuc). Gonna investigate some more.
[15:43] <rog> mpl: interesting.
[15:51] <kickinz1> Hi!
[16:04] <rog> kickinz1: hi
[16:12] <kickinz1> I just have another question....May I?
[16:14] <SpamapS> kickinz1: please do!
[16:15] <kickinz1> I'm re-installing an orchestra server to use it in conjonctionwith juju
[16:15] <kickinz1> (managing an openstack cloud)
[16:16] <nijaba> marcoceppi: thanks for reverting my mistake
[16:16] <kickinz1> The other tim (11.10), I had some little troubles, that I've been able to manage, now, I quite know how to do, but...
[16:16] <marcoceppi> nijaba: which, what?
[16:17] <nijaba> marcoceppi: fix-released/proposed
[16:17] <kickinz1> In cobbler I don't have anything but hardy by default, I have to use cobbler-ubuntu-import, why?
[16:17] <marcoceppi> nijaba: Oh! No problem :D
[16:17] <kickinz1> The other time I didn't need to do that.
[16:18] <kickinz1> Is ther a special comand to do to doanload all repos?
[16:21] <kickinz1> Cause I don't have the profiles with *_juju now...
[16:22] <kickinz1> Maybe I'm not clear enough?
[16:26] <kickinz1> I don't have mgmtclasses too....
[16:36] <SpamapS> kickinz1: hm
[16:37] <SpamapS> kickinz1: you do need to run the import script, it should end up with all supported releases
[16:38] <_mup_> juju/robust-zk-connect r422 committed by jim.baker@canonical.com
[16:38] <_mup_> Merged trunk
[16:45] <kickinz1> SpamapS: Thanks, but which scritp? cobbler-ubuntu-import?
[16:48] <SpamapS> kickinz1: yeah I think thats it
[16:50] <kickinz1> I ran it, but doesn't worked, I have the repos but not the profiles (cobbler-ubuntu-import natty-x86-64 oneiric-X86_64 .. )
[16:51] <drt24> kickinz1: or orchestra-$something? that got some of my brokenness fixed
[16:54] <kickinz1> SpamapS & drt24: thanks orchestra-import-isos, was the good one thanks!
[16:55] <whit> hazmat: howdy kapil
[16:55] <hazmat> whit, greetings
[16:56] <whit> hazmat: if I wanted to setup a single box setup of openstack, is that possible to bootstrap with juju?
[16:57]  * whit has a spare ubuntu box, and needs to get a openstack environment set up to play with
[16:57] <nijaba> marcoceppi: thanks for your review.  I have now addressed your remarks (or I think I have)
[16:58] <hazmat> whit, i think i'd recommend just using the devstack script in that scenario.. http://devstack.org/
[16:58] <whit> hazmat: yeah...
[16:58] <SpamapS> whit: smoser has been working on making a juju version of devstack tho
[16:58] <SpamapS> hazmat: ^^
[16:58] <SpamapS> smoser: how's that juju-devstack script coming btw?
[16:59] <whit> heard that in the webcast this morning, hence me showing up here :)
[16:59]  * whit has futzed with devstack script
[16:59] <smoser> "working".
[16:59] <smoser> not much.
[17:00] <whit> was tempted to hack it to use supervisor rather than a host of screen calls
[17:00] <SpamapS> Actually the screen bits are nice. I wouldn't mind having that for the juju local provider's consoles.
[17:00] <smoser> only tried a bit last night. hopefully adam_g will be able to help some. but the goal is that its largely just the same juju openstack providers that he's working on.
[17:00] <smoser> whit, "supervisor" ?
[17:01] <SpamapS> smoser: yeah I'd expect it to be a short list of juju commands and the specialized "scaled down" config.yaml
[17:01] <SpamapS> smoser: I think he meant supervisord
[17:01] <whit> smoser: supervisord? http://supervisord.org/
[17:01]  * whit shrugs
[17:02] <whit> it's nice for tying together processes that make up a single service and managing those processes together
[17:03] <SpamapS> whoa.. 11 hours for recipe build queue.. :-P
[17:03] <smoser> interesting.
[17:04] <smoser> the niceness of the screen or tmux is that you go to a window for the log of nova-compute
[17:04] <smoser> kill it
[17:04] <smoser> edit code
[17:04] <smoser> press up a copule times, start it
[17:04] <smoser> cycle is very fast.
[17:04] <smoser> clearly something else could provide the same, even monitoring writes and re-loading like the django development webserver does.
[17:05] <smoser> but it works well enough
[17:05] <whit> smoser: yeah, that is nice.  the cycle with supervisorctl is simular
[17:06] <whit> for example, I have a series of applications sandboxed in virtualenvs, managed by supervisor
[17:06] <whit> I have one command to start everything
[17:06] <whit> I issue one command to stop something I want to work directly on
[17:06] <whit> start it by hand in the foreground, futz with it
[17:07] <whit> get it to where I want, restart it under supervisor
[17:07] <SpamapS> whit: yeah, vagrant users cite similar things. We kind of want you to have that in juju, but also have the ability to move the same thing into production easily.
[17:07] <rog> team meeting now?
[17:08] <marcoceppi> nijaba: Looks good to me!
[17:08] <rog> hazmat: ^
[17:08] <hazmat> rog, indeed
[17:10] <marcoceppi> nijaba: Just need someone else to look it over :)
[17:10]  * whit nods at SpamapS 
[17:10] <whit> makes sense
[17:11] <whit> though, we leverage that system to move things to prod easily, since supervisor is also running everything in prod
[17:11] <whit> but it's all handrolled
[17:11]  * whit shrugs
[17:12] <hazmat> rog, fwereade, jimbaker, bcsaller, invites out
[17:12] <jimbaker> hazmat, ok
[17:21] <niemeyer> Hello there!
[17:22] <nijaba> marcoceppi: I am sure SpamapS will be happy to review ;)
[17:28] <mpl> 'lo gustavo
[18:04] <nijaba> Question: should charm enable ssl as an option or should ssl be handled by the loadbalancer?
[18:04] <SpamapS> nijaba: good question
[18:05] <SpamapS> nijaba: I think there's a decent argument for apache and apache ssl to become subordinate charms to accomplish things like that
[18:05] <nijaba> SpamapS: so at he moment you would recommend not to implement it as an option in charms?
[18:07] <SpamapS> nijaba: since subordinate charms are still a long way off, it might be interesting to see it done like that.
[18:07] <nijaba> SpamapS: I think it would make sense for roundcube.  I'll work on it...
[18:11] <marcoceppi> The problem with SSL is getting a trusted certificate
[18:11] <hazmat> http://theopenphotoproject.org/
[18:11] <marcoceppi> Not sure how you would work that in, but I'm interested
[18:13] <nijaba> marcoceppi: in the meantime, I like snakeoil better than no ssl on my emails :)
[18:13] <marcoceppi> True true :)
[18:20] <SpamapS> well we could charm up openca :)
[18:21] <SpamapS> Also you can have Amazon do your SSL w/ cloudfront
[18:25] <nijaba> if I need to store a value that can be used by all my unit.  This is a value that should be generated once for the first unit, then reused by all others. is there a 'config-set' that I could use?
[18:52] <marcoceppi> ah, dash is giving me headaches again
[18:54] <adam_g> is it assumed that `unit-get private-address` from one side of a relation will be the same as `relation-get private-address` from the other?
[19:16] <koolhead17> SpamapS: is it possible to get the presentation slide of today`s juju cast/talk sumwer
[19:21] <SpamapS> koolhead17: I believe its attached to the webinar somehow
[19:22] <koolhead17> SpamapS: i have not finished watching it. cool i will wait for the link :)
[19:44] <koolhead17> SpamapS: nopes, i was not able to get/see any link for the slides :(
[20:03] <marcoceppi> I'm wondering about the best way to handle this test for charm-helper-sh
[20:04] <SpamapS> marcoceppi: tests should be relatively easy to write
[20:05] <marcoceppi> SpamapS:  I'm trying to do this in all.sh (so you can include _all_ libraries)
[20:05] <SpamapS> marcoceppi: you can "mock" wget with an alias.. or.. even better.. fire up a tiny webserver
[20:05] <marcoceppi> However, I can't reliably get the dirname when sourcing. I'm trying to avoid hardcoded paths :\
[20:06] <marcoceppi> I've got a test case written :) It does a test against every type of file pull
[20:07] <SpamapS> marcoceppi: OH I've had this problem before.
[20:07] <SpamapS> marcoceppi: sourcing does not set $0
[20:07] <marcoceppi> The internet is failing with help, since they're written in dash I can't use $BASH_SOURCE
[20:07] <SpamapS> thats sort of why BASH_SOURCE exists. :)
[20:08] <marcoceppi> DASH_SOURCE doesn't seem to exist either :\
[20:08] <SpamapS> marcoceppi: no, dash is minimalistic by design
[20:08] <SpamapS> -rwxr-xr-x 1 root root 950896 May 18  2011 /bin/bash
[20:08] <SpamapS> -rwxr-xr-x 1 root root 109768 Oct 27 11:20 /bin/dash
[20:09] <marcoceppi> Right, I understand the goal I'm just hitting a wall with this
[20:09] <SpamapS> marcoceppi: One way to go is to have users "exec" a command to get all..
[20:09] <SpamapS> marcoceppi: another is to call it all.bash , and don't let people use "all" from dash.
[20:10] <marcoceppi> I suppose exec /usr/share/charm-helper/sh/all.sh would be a good solution
[20:10] <marcoceppi> will anything that file sources be available in the global source?
[20:10] <marcoceppi> scope*
[20:10] <SpamapS> marcoceppi: I'd be in favor of the latter.. keep all simple for the people who just want bash... let dash/csh/ksh weirdos use the individuals
[20:11] <SpamapS> marcoceppi: no you'd do this
[20:11] <marcoceppi> So, have an all.bash
[20:11] <SpamapS> eval `/usr/share/charm-helper/bash/all.bash`
[20:11] <marcoceppi> looks kind of ugly
[20:11] <SpamapS> and it would spit out the source lines
[20:14] <SpamapS> marcoceppi: you're going to have to figure this out when two helpers share code anyway ;)
[20:15] <marcoceppi> So, right now I have this in the file: http://paste.ubuntu.com/764170/
[20:15] <marcoceppi> Which obviously won't work when sourced, but it's the idea I had
[20:16]  * marcoceppi had ideas for a ch_require function when separate ch modules required functions from another module
[20:16] <SpamapS> marcoceppi: right, just add 'echo' in front of the . and you can eval/exec it.
[20:17] <marcoceppi> hum, so there really isn't any way around that scoping issue then? I'll go ahead and do that then open a bug to see if we can avoid having to use eval
[20:17] <_mup_> juju/robust-zk-connect r423 committed by jim.baker@canonical.com
[20:17] <_mup_> Backoff for 1s if environment pending because no addr assigned
[20:17] <_mup_> juju/trunk r430 committed by kapil.thangavelu@canonical.com
[20:17] <_mup_> [trivial] yield on add_auth calls in tests [f=832384]
[20:17] <SpamapS> marcoceppi: I'm guessing there isn't. But maybe its time to evaluate whether "sh" is worth it. :)
[20:17]  * marcoceppi *nods furiously*
[20:18] <marcoceppi> :)
[20:18] <marcoceppi> I'll give this a go then! thanks :D
[20:19] <SpamapS> marcoceppi: it may be a good idea for us to just say "never mind that was a bad idea, use bash"
[20:19]  * SpamapS has lots of bad ideas
[20:20] <marcoceppi> SpamapS has more good ones than bad
[20:25] <fwereade_> hazmat: ping
[20:28] <SpamapS> nijaba: isn't @ubuntucloud supposed to retweet stuff I tweet @ubuntucloud ?
[20:29] <hazmat> fwereade_, pong
[20:30] <fwereade_> hazmat, if a relation goes away while a unit agent is down, can you think of a way to reconstruct the workflow such that we can call the departed hook?
[20:31] <hazmat> fwereade_, i don't know that we  need to do that in the workflow
[20:32] <fwereade_> hazmat, well, ok, maybe we just need the lifecycle
[20:32] <hazmat> fwereade_, its not something we would call the departed hook for, just relation-broken if the relation was removed.
[20:33] <hazmat> fwereade_, when the down agent comes back it has a delta to apply or queue for hook execution, the relation-broken hook in that sense is no different
[20:33] <fwereade_> hazmat, hm, ok, but wouldn't we call departed if it went away while we were running?
[20:33] <hazmat> fwereade_, departed is called when other nodes that where participating in the relation go away
[20:34] <hazmat> fwereade_, the on disk record of state, needs a delta computation against current state when it comes back up, to determine what the missed events/hooks are
[20:35] <fwereade_> hazmat, ok, scratch nonsense about departed
[20:36] <fwereade_> hazmat, the question remains, how do I construct a lifecycle which I can then cause the relation-broken hook to fire?
[20:37]  * hazmat ponders
[20:37] <fwereade_> hazmat, the unit_relation appears to be needed for the HookScheduler -- if it were just the watches it were needed for, we could just about get away with a localised hack
[20:37] <SpamapS> fwereade_: I had some thoughts on that
[20:37] <hazmat> fwereade_, i think you just create one ad hoc
[20:38] <fwereade_> hazmat, heh, ok, that looked doable but kinda evil
[20:38] <SpamapS> fwereade_: really, when the client says "that relationship is no more" .. it should insert a "TODO" item for each side to ACK the state
[20:38] <SpamapS> fwereade_: so if one side is offline, thats fine, when it comes back it will see that it has a TODO and do it, then ack it (possibly just by deleting the TODO)
[20:38] <hazmat> fwereade_, actually even simpler than that
[20:39] <hazmat> fwereade_, a static method on the unit rel lifecycle, just give it the executor and the rel name.
[20:39]  * fwereade_ peers at the code
[20:39] <hazmat> and it will queue a broken hook
[20:39] <hazmat> fwereade_, look at the depart lifecycle method, thats basically the same notion
[20:40] <hazmat> hmm... the relhookcontext..
[20:40] <hazmat> so effectively its already broken for depart hooks
[20:40] <fwereade_> hazmat, the unit relation is still needed.. yep ^^
[20:40] <fwereade_> hazmat, hadn;t thought if it that way but, yeah, I think so
[20:44] <fwereade_> SpamapS, I think what you say makes sense, but it's a bit far outside current mental scope for me to be sure
[20:45] <SpamapS> Avoids having to store state locally if you keep everything in ZK
[20:50] <fwereade_> SpamapS, this is true, I can't actually think of a good reason to store that state locally, but solving this specific problem feels like a pretty fearsome change...
[20:51] <SpamapS> fwereade_: not knowing the code, I can't comment much on how hard it will be.. only that I think this would work. ;)
[20:53] <fwereade_> hazmat, wait, hold on, will the UnitRelationState actually be *gone*? it suddenly looks to me as though it *is* deleted immediately if the *service* goes away, but may be left around if just the *relation* goes away
[20:53]  * fwereade_ reads some more with furrowed brow
[20:53] <hazmat> fwereade_, so right now it appears that the full hook cli api for relations would in a rel-broken  hook.. if the underlying rel states haven't been garbage collected... spamas's notion of capturing intent/acks has some value as it can help a gc known when it safe to clean out the rel structure. an offline node, could be offline for a while.. ie. it should be expected that the relation is gone... so that comes back to what are the expecta
[20:53] <hazmat> tions of a relation-broken hook execution and the applicable apis that can be used. i can't get around the notion that at a minimum the hook should have access to its own unit's relation settings, so we do need the structures marked explicitly for cleanup as they execute -broken hooks.
[20:55] <hazmat> fwereade_, if the rel goes away its removed in  _process_service_changes
[20:57] <fwereade_> hazmat, ok, if unit rel state really always stays around (which I don't think it does when the service is destroyed)
[20:57] <hazmat> so the memory structures are pruned for unit-rel state, the underlying zk structures are still present atm (lacking gc), and so the unit rel can be constructed on the fly/transiently for the broken hook execution, but that needs the ack coordination around gc of the state.
[20:58] <fwereade_> hazmat, I had the impression that GC didn't exist yet
[20:59] <fwereade_> hazmat, I was just poking around, and I guess I *couldn't* find anything that deleted unit-relation states
[20:59] <hazmat> fwereade_, self._relations.pop
[21:00] <hazmat> fwereade_, you mean the in memory  state or zk state?
[21:00] <fwereade_> hazmat, sorry, zk state
[21:00] <fwereade_> hazmat, things I am now pretty sure of
[21:01] <fwereade_> hazmat, actually I'm not that sure, thinking again
[21:01] <hazmat> fwereade_, right so the gc doesn't exist, but it has an obvious implementation for most of things, this is one place where coordination would be needed, at the very least that should get captured.. the same problem arises in the stop case (except the states are indeed gc'd), we need to capture intent/ack instead of justs modifying the state
[21:04] <hazmat> in this case the state is being modified atm, but it will be, so the need for ack is still there, just creating a new node for the unit would suffice upon depart.
[21:05] <hazmat> fwereade_, i wonder though if we don't also need a separate hook context for broken, it should never see any other members of the rel
[21:05] <fwereade_> hazmat, I was just looking upon RelationHookContext.get_members, with a sour expression
[21:05] <hazmat> nor set settings, just be able to retrieve its own settings
[21:06] <fwereade_> hazmat, even that may be tricky, doesn't service destruction delete the unit containers?
[21:07] <hazmat> fwereade_, yeah.. this is a more generic problem we have multiple places
[21:07] <hazmat> we express intent by modification of the state, and then have actors change their env to match state
[21:08] <hazmat> but the state we're modifying is identity, and we create missing identity scenaros for the actors
[21:08] <hazmat> we need to capture the intent as a state change that can be coordinated upon by the actors while they retain their identity
[21:09] <fwereade_> hazmat, ok, so basically the unit agent is responsible for finally trashing its own state in ZK as it dies, and for trashing the last of the service state as well (if the service is marked as going-away, I guess)
[21:10] <fwereade_> hazmat, not *is*, *should be*
[21:10] <hazmat> fwereade_, actually it formalizes a new trusted actor, a gc agent, that can enact the final removal of actor identity from the topology
[21:11] <hazmat> but the gc actor needs coordination with any actor that it has completed the intent
[21:11] <hazmat> the actor can of course attempt to clean up its own nodes
[21:12] <fwereade_> hazmat, ah, ok: so for example the client marks "dying", each unit agent marks itself "dead", GC cleans up
[21:12] <hazmat> but the topology node in particular is off limits to most actors in the system as it represents truth in the system, as expressed by the user
[21:13] <hazmat> the notion then is that the topology can be extended to capture these intents from users (destroy-service/remove-unit) which still trigger the requisite state changes to enact behavior, but with the identity changes being async to that
[21:14] <fwereade_> hazmat, sure, there's no reason to mess with the topology itself, surely the dying flag can live in the actor's own nodes?
[21:14] <hazmat> so sort of like on ec2-terminate-instances the instance isn't immediately dead, and it continues to appear in the output of describe-instances for some time, till its identity is finally gc'd
[21:14] <hazmat> fwereade_, only if you trust the actor ;-)
[21:15] <fwereade_> hazmat, ...ha, yes
[21:15] <hazmat> i'm not dead yet ;-)
[21:15] <fwereade_> hazmat, far from it :)
[21:17] <SpamapS> arg.. argparser.HelpFormatter is not an extendable class. :/
[21:18] <fwereade_> hazmat, ok; so that would be cool, but my proximate problem is in calling relation-broken
[21:18] <fwereade_> hazmat, which it seems is broken anyway
[21:19] <fwereade_> hazmat, I'm somewhat taken by the idea of a less-featureful RelationDepartedHookContext
[21:19] <fwereade_> hazmat, but there wouldn't be much difference between that and a plain HookContext
[21:21] <fwereade_> hazmat, (but that specifically is not really a relevant consideration atm)
[21:22] <fwereade_> hazmat, this would definitely qualify as an API change
[21:22] <hazmat> fwereade_, that sounds good to me, you'd need stub impl of the relhookcontext, and you'll need at least rel-name identity to queue up the broken hook.
[21:22] <fwereade_> hazmat, does that feel like the least worst accessible solution to you?
[21:22] <fwereade_> hazmat, yeah, I can probably keep track of the name :p
[21:23] <hazmat> fwereade_, yeah.. that seems okay.
[21:23] <hazmat> the api change is sane as well
[21:23] <hazmat> but should get to the list
[21:23] <hazmat> i'll need to write up the intents stuff
[21:23] <fwereade_> hazmat, indeed, I'll start writing it up now, may not land until tomorrow morning
[21:23] <hazmat> fwereade_, sounds good
[21:24] <hazmat> SpamapS, yeah.. we use raw formatter normally..
[21:24] <fwereade_> hazmat, cheers
[21:24] <hazmat> SpamapS, i'm pretty disappointed with the extensibility of argparse
[21:24] <hazmat> its a mess down there
[21:24] <hazmat> it works, and is very useful, but extending it is ugly
[21:24] <SpamapS> hazmat: techniclaly this is violating its API:
[21:25] <SpamapS> class JujuFormatter(argparse.HelpFormatter):
[21:25] <SpamapS> "Only the name of this is considered public API"
[21:26] <SpamapS> hazmat: doesn't seem to be designed for flexibility.. just seems to want to be the simplest to use.
[21:27] <hazmat> SpamapS, yeah.. and its still miles better than what it replaced.. the python stdlib has gone through 3 gens of option parsing
[21:27] <hazmat> SpamapS, alternatively we could use commandant (extracted from bzr)
[22:09] <hazmat> jimbaker, could you review the ssh cleanup branch.. ideally they should go in together to avoid the output oddities.
[22:09] <hazmat> SpamapS, just wanted to confirm txzk in the ppa is a nightly from txzk trunk?
[22:26] <_mup_> Bug #901901 was filed: error in provisioning agent when terminating machine <juju:New> < https://launchpad.net/bugs/901901 >
[22:27] <hazmat> niemeyer, how's the conference?
[22:43] <jimbaker> hazmat, i reviewed that branch, so it's all set
[22:44] <hazmat> jimbaker, cool, just need one more +1
[22:46] <jimbaker> hazmat, sounds good. bcsaller, you want to look at this branch, lp:~hazmat/juju/sshclient-refactor ? it's a pretty sweet refactoring imho, and will allow us to get rid of perhaps the most annoying issue in juju :)
[22:59] <niemeyer> hazmat: It was great so far
[22:59] <niemeyer> hazmat: Today is actually a more "compact" meeting with just the more active users/developers
[23:00] <niemeyer> hazmat: Several interesting brainstorms
[23:00] <niemeyer> hazmat: Tomorrow is the real MongoSV conference..
[23:00] <niemeyer> hazmat: Expected to have 1000+ participants (!)
[23:00] <hazmat> niemeyer, right on, wow
[23:52] <jimbaker> hazmat, now that bcsaller has approved your branch, just need to a get final OK on lp:~jimbaker/juju/robust-zk-connect. it's a very small change, just adds a sleep to backoff  while waiting for the addr to be assigned instead of hammering away