[00:24] <m_3> mornin
[03:26] <sep332> hello, I was just wondering if there is a way to deploy a Diaspora server using Juju?
[03:41] <hazmat> SpamapS, even with format2?
[03:41] <hazmat> sep332, there doesn't appear to be a charm for it, only owncloud
[03:42] <hazmat> sep332, contributions welcome.. https://juju.ubuntu.com/docs/charm-store.html
[03:42] <sep332> of course :) I was wondering if there was a project underway, thank you
[04:32] <imbrandon> SpamapS: its the novel way in how it handles the sub commands, i did it POC in ruby a) cuz thats what i knew well enough to pump it out in less than an hour and b) it wasnt php so there was a chance on it to be taken serious and c) python argparse can lick my ...
[04:33] <imbrandon> but language aside its the idea that i'm trying to convey more than anything , and the way i explain things i figured this time it was best said with code :)
[04:33] <imbrandon> it could be redone in python , c++, vb6 , i dont care :)
[06:38] <SpamapS> imbrandon: heh true :)
[06:49]  * SpamapS gets back to fighting with nrpe, nagios, and *
[06:52] <SpamapS> hazmat: yes even w/ format 2, config-get on a defaulted "" gives back ''
[06:52] <SpamapS> hazmat: which I suspect is just format_json doing its job as directed
[06:52] <SpamapS> hazmat: what I really want is *RAW*
[06:52] <SpamapS> not smart, and not json
[06:52] <SpamapS> give me the raw bytes
[07:06] <SpamapS> hrm.. seems like there is a bug in relation-ids when used w/ subordinates
[07:32] <lifeless> SpamapS: oh noes
[10:25] <matsubara> Hello there, I'm writing a charm that needs to install a new kernel so I can load the kvm module. if I install the new kernel, reboot, how can I resume the install hook from where it left?
[10:38] <hazmat> SpamapS, format2 is yaml, and an empty string is an empty string
[10:50] <hazmat> SpamapS, re relation-ids w/ subordinates, could you describe the issue, i don't see a  bug re.
[14:26] <jcastro> jamespage: heya
[14:26] <jcastro> jamespage: did you have a chance to look at the ubuntu charm?
[14:26]  * jcastro has a plan to demo it
[15:31] <jcastro> xnox: hazmat: hey so any luck testing the openstack provider?
[15:32] <xnox> jcastro: quantal mirrors on hpcloud were up today. will test tonight.
[15:33] <hazmat> jcastro, on vacation today.. doing meetings though
[15:33] <jcastro> oh nice, is that what imbrandon set up?
[15:33] <jcastro> hazmat: ok I'll catch you on the flip side
[15:34] <xnox> yes
[15:49] <SpamapS> hazmat: I'm still diagnosing the subordinate issue.
[15:49] <SpamapS> matsubara-afk: you can't resume the install hook, but you can set everything up to resume the process on reboot with an upstart job
[15:50] <SpamapS> matsubara-afk: juju and the agents will also keep track of what has completed, so its possile if you do a 'reboot' without exitting the install hook that on reboot the agent will re-run install.
[15:51] <SpamapS> matsubara-afk: one guarantee we have is that config-changed will run whenever the agent is started up, so you can also put your resume logic in there
[15:56] <negronjl> 'morning all
[15:56] <SpamapS> negronjl: buenos dias
[15:56] <jimbaker> negronjl, morning
[15:56] <negronjl> SpamapS: hola
[15:56] <negronjl> jimbaker: 'morning
[15:57] <matsubara> thanks SpamapS
[16:06] <SpamapS> hazmat: # config-get monitors  │································
[16:06] <SpamapS> ''  err
[16:06] <SpamapS> lets try that again
[16:06] <SpamapS> # config-get monitors
[16:06] <SpamapS> ''
[16:06] <SpamapS> jimbaker: ^^ so even individual values are json encoded I assume?
[16:07] <SpamapS> actually no looks like smart still
[16:07] <matsubara> SpamapS, do you know of a charm that does the resume with an upstart job as an example?
[16:07] <SpamapS> matsubara: no, reboots are a recent addition
[16:08] <matsubara> SpamapS, do I need to run a special juju command to reboot? or just reboot the machine and juju will do the right thing?
[16:08] <SpamapS> well, 4 or 5 months ago, but still, recent enough that its a new thing to play with
[16:08] <SpamapS> no
[16:08] <SpamapS> just reboot
[16:08] <SpamapS> matsubara: juju installs upstart jobs for the machine and unit agents
[16:11] <matsubara> SpamapS, what's the difference between juju-machine-agent.conf and juju-maas-nodes-0.conf in /etc/init/? (maas-nodes-0 is the name of this charm btw)
[16:12] <SpamapS> matsubara: one runs the machine agent, the other runs a unit agent
[16:12] <jimbaker> SpamapS, in charm format 1, json encoding is used at some point. in a roundabout way, this accounts for why smart formatting renders strings as unicode
[16:14] <matsubara> SpamapS, what the machine agent does and what the unit agent does? (sorry, if this is explained in the docs, I can read there)
[16:16] <jamespage> jcastro, yep - but it appears to be a store issue
[16:16] <jcastro> ah ok
[16:16] <SpamapS> matsubara: machine agent spawns/removes unit agents and units (units are instantiations of charms)
[16:16] <jamespage> jcastro: james_w and niemeyer discussed it after my initial query yesterday
[16:16] <SpamapS> jimbaker: I don't know what that means..
[16:17] <jamespage> I think a change is proposed which should fix it
[16:17] <jamespage> but I've lost my backscroll....
[16:17] <matsubara> SpamapS, I see. thanks!
[16:17] <SpamapS> jimbaker: what I see is '' where I would expect nothing
[16:17] <jcastro> jamespage: oh ok, so it's on the right radars then
[16:17] <SpamapS> jimbaker: its particularly problematic in shell scripts
[16:22] <jimbaker> SpamapS, understood. yaml can properly account for an empty value (= None in Python), but the question is whether this is readily produced by code using relation-set/relation-get
[16:23] <jimbaker> vs an empty string which can also be kept as a distinct value
[16:24] <jimbaker> fwiw, the output was intentionally made as friendly to shell scripts as possible, using the variety of acceptable yaml formats
[16:32] <jimbaker> SpamapS, i guess one possible problem here is that relation-set foo= implies that foo should be deleted; so if you want store an empty string, you would say something like relation-set foo='', which then keeps this as an empty string, reporting back ''. i guess we could tweak it such that it returns nothing in this case, at the cost of losing roundtripping on this value
[16:37] <SpamapS> jimbaker: yaml is totally unacceptable to shell, so I'm not sure how that computes..
[16:38] <jimbaker> SpamapS, i think it sounds like format: 2 has a big problem
[16:38] <SpamapS> jimbaker: for shell, I want a string of bytes every time with strings. The only time yaml/json/fooo matters is boolean.
[16:38] <jimbaker> as i have implemented it, since it does use yaml, pervasiviely
[16:39] <jimbaker> SpamapS, do you want relation settings to interpret booleans?
[16:39] <SpamapS> jimbaker: sometimes it will be ok. Many times it will not. :-/
[16:39] <SpamapS> jimbaker: no, but this is config settings
[16:40] <jimbaker> SpamapS, also, when you say a string of bytes, i assume you mean to keep it as such. so no unicode interpretation. feed bytes in any format (say utf-8, high bytes, whatever), get back as the exact string of bytes
[16:41] <SpamapS> jimbaker: just think of how hard it will be to use in shell..  echo "Title='$(confi-get title)'" is pretty common. Now that will be ''thetitle''
[16:41] <SpamapS> jimbaker: *yes*
[16:41] <SpamapS> why the heck would juju try to interpret the bytes?!
[16:42] <SpamapS> don't confuse "string" with "str"
[16:42] <jimbaker> SpamapS, my apologies
[16:44] <SpamapS> no apology necessary
[16:45] <SpamapS> I'm just surprised this never came up during any review
[16:45] <SpamapS> like, did anybody actually try format 2?
[16:49] <jimbaker> SpamapS, i did, and i did bear in mind the formatting aspects of shell (hence the format tweaking). in my usage, it seemed fine. but that does not change the fact that it does not work for you
[16:50] <jimbaker> SpamapS, fwiw, there is an extensive discussion of how it is supposed to work in the merge proposal, https://code.launchpad.net/~jimbaker/juju/charm-format-2/+merge/108831
[16:54] <jimbaker> SpamapS, in any event, it should be straightforward to change the format, given the refactoring that was done, to mean use bytes when working with relation settings. this can also be tweaked to provide for special interpretation of true/false if that's desired
[17:02] <SpamapS> jimbaker: you guys said way too much for me to find where you all thought it was a good idea to output all strings wrapped in ''
[17:03] <SpamapS> + self.assert_smart_output("", "''\n")
[17:03] <SpamapS> I see that it is intentional
[17:04] <jimbaker> SpamapS, yes, it does ensure roundtripping of empty strings
[17:05] <SpamapS> is it only empty?
[17:06] <SpamapS> I haven't actually tried any full strings
[17:06] <jimbaker> SpamapS, so a couple of options i see:  1) we could specifically work around that, so empty strings are always ouput as nothing at all; 2) change it to bytestrings
[17:06] <SpamapS> can dial my surprise down a lot if its only empties
[17:06] <jimbaker> SpamapS, yaml tries to avoid quotes on strings if possible
[17:06] <SpamapS> jimbaker: I think I'll just argue for format 3 to have raw byte strings, which is what it should have always been
[17:07] <SpamapS> or at least, we need an explicit way to say "don't touch this"
[17:07] <jimbaker> SpamapS, i don't think we have to support format 3 if it makes more sense to just use bytestrings
[17:07] <SpamapS> I'd also like for relation-set and 'juju set' to be able to take input from stdin
[17:07] <SpamapS> jimbaker: no this is bigger than a single issue
[17:08] <SpamapS> I've wanted to insert a binary file a few times now
[17:08] <jimbaker> juju set is different, because it does interpret its input
[17:08] <SpamapS> x="$(cat foo)" is not the way to do that.
[17:09] <jimbaker> SpamapS, well if you do use !!binary, you can feed in a b64 encoded string
[17:10] <SpamapS> jimbaker: which I already do. ;)
[17:10] <SpamapS> jimbaker: but then on the -get side I have to use yaml again to decode it
[17:10] <SpamapS> and then we run into shell fail again
[17:11] <SpamapS> jimbaker: I think it makes a ton of sense to use yaml. It just doesn't make any sense to leave the shell without any help parsing it
[17:12] <jimbaker> SpamapS, do try it with nonempty strings, to see if that really works or not for your case. if not, we can change to bytestrings and forget yaml for relation-set/relation-get
[17:20] <SpamapS> jimbaker: Ok so non empties works. BUT the bigger issue is that it is very non-obvious how juju is interpreting things when I would expect that strings would always just be raw strings. This is something to think about long term.
[17:23] <jimbaker> SpamapS, so it sounds like we should at least change the output of empty strings to nothing, as we discussed
[17:24] <SpamapS> no
[17:24] <SpamapS> special casing makes it workse
[17:24] <SpamapS> worse
[17:24] <SpamapS> jimbaker: this is a deeper issue
[17:25] <SpamapS> jimbaker: the fact that relation-set monitors="$(cat monitors.yaml)" does not result in   monitors: "...the content of the yaml file" is a deep and troubling problem
[17:25] <jimbaker> SpamapS, then i suggest changing to bytestrings in format: 2 for relation-get/set. config settings should be kept in yaml however
[17:25] <jimbaker> since they do have a type interpretation
[17:26] <SpamapS> jimbaker: but
[17:26] <SpamapS> jimbaker: the type is *string*
[17:26] <SpamapS> so, can I expect a string with all the yaml in it?
[17:26]  * SpamapS has not tried it yet
[17:26] <jimbaker> of course there is relation-get - to consider
[17:27] <jimbaker> but that could imply yaml output
[17:28] <SpamapS> it does imply yaml
[17:28] <SpamapS> but the values must be the strings that were set
[17:28] <jimbaker> SpamapS, since we know the types for config values, we could take this into account
[17:29] <jimbaker> so use yaml to parse except for string types, which implies bytestrings
[17:29] <SpamapS> no except
[17:30] <SpamapS> meh
[17:30] <SpamapS> jimbaker: forget I said anything. I'll deal. I don't have the mental capacity to debate these subtleties
[17:32] <jimbaker> SpamapS, let's just put it on hold then. your points, especially with respect to reasonable usage like relation-set monitors="$(cat monitors.yaml)" are valid. however, i certainly agree about the subtlety
[17:33] <jcastro> jamespage: m_3 hey check this out: http://whirr.apache.org/docs/0.7.1/quick-start-guide.html
[17:33] <jcastro> it's like basically juju for hadoop
[17:37] <jimbaker> SpamapS, i have just updated this merge proposal to be more robust, but it remains quite useful: it adds help to jitsu. https://code.launchpad.net/~jimbaker/juju-jitsu/subcommand-help/+merge/111634
[17:40]  * avoine just got juju to bootstrap on HP cloud with the openstack branch
[17:41] <SpamapS> avoine: woot!
[17:41] <avoine> really cool indeed
[17:42] <avoine> using the latest userpass auth-mode
[17:44] <SpamapS> avoine: when I tried it destroy-environment failed
[17:44] <SpamapS> avoine: and machine 0 didn't have metadata
[17:45] <avoine> your right, destroy-environment is not working
[17:47] <avoine> I think I have the metadata
[17:47] <avoine> well there is something in /var/lib/cloud/instances/i-00010533/user-data.txt
[17:51] <SpamapS> no i mean in juju status
[17:52] <avoine> ok
[17:52] <avoine> yeah same here
[18:13] <jcastro> https://juju.ubuntu.com/docs/getting-started.html
[18:13] <jcastro> hey should we recommend installing cgroups-lite for LXC?
[18:13] <jcastro> it was my understanding that yes, we should
[18:13] <SpamapS> doesn't lxc recommend it already?
[18:14] <jcastro> ah yes, correct, that answers my question, ta
[18:14] <jcastro> <---- reshuffling getting-started.rst
[18:15] <SpamapS> cool
[18:16] <SpamapS> bcsaller: hey, do subordinates not watch their relation settings like regular unit agents? I do relation-sets in later hooks using -r and they are never propagated to subordinates
[18:19] <bcsaller> SpamapS: they should
[18:19] <SpamapS> http://paste.ubuntu.com/1076855/
[18:19] <SpamapS> Thats on the mysql side.. setting it in upgrade-charm
[18:21] <SpamapS> http://paste.ubuntu.com/1076860/
[18:21] <SpamapS> bcsaller: and thats the unit agent that is connected on the other side. sees the change, but does not run changed hook
[18:22] <bcsaller> SpamapS: I can look into it but I was pretty sure those code paths were tested
[18:22] <bcsaller> thanks for letting me know
[18:23] <SpamapS> bcsaller: Its a corner case, don't spend much time on it
[19:37] <RichardRaseley> So, I am interested in setting up an OpenStack environment using JuJu and MaaS (as outlined here https://help.ubuntu.com/community/UbuntuCloudInfrastructure), but I only have 5 nodes to work with. Is it possible for me to co-locate some of the services but still use juju to do the deployment? Like if I wanted 1x for mass / juju 1x mysql, rabbitmq, keystone, horizon, and 3x nova nodes...
[19:39] <jamespage> jcastro, kinda
[19:46] <jcastro> jamespage: hey so I think there might be a problem with the etherpad-lite charm
[19:46] <jcastro> and the best I can figure out is "some kind of npm error"
[19:46] <jamespage> jcastro, marvellous
[19:47] <jamespage> jcastro, I'll take a look tomorrow
[19:47] <jcastro> http://pastebin.ubuntu.com/1076998/
[19:57] <jamespage> jcastro, the nodejs PPA has upgraded from 0.6.x to 0.8.x and etherpad does not like it
[19:59] <jamespage> jcastro, whats in the archive will probably work - I'll test tomorrow
[19:59] <SpamapS> jamespage: the distro caught up with nodejs last cycle btw
[19:59] <jamespage> SpamapS, yeah - I know - well at least for about 1month anyway
[19:59] <jcastro> heh
[20:00] <jcastro> SpamapS: I was waiting for your "archive rocks, told you this would happen."
[20:00]  * SpamapS bows
[20:00] <SpamapS> one is glad to be of service
[20:01] <jamespage> SpamapS, npm landed pretty late didn't it
[20:01] <jamespage> I think thats why the charm still uses the PPA TBH
[20:01] <jcastro> I'll test with the archive version and if it works submit a branch
[20:01] <jcastro> I need to get better at workflow with charms anyway
[20:01] <jamespage> jcastro, thanks - that would be really great
[20:01] <jamespage> I'll review it tomorrow
[20:02] <jamespage> assuming its working OK :-)
[20:02] <jcastro> heh
[20:11] <jcastro> same errors switching to node in the distro
[21:44] <jamespage> jcastro, odd
[22:00] <imbrandon> mmm ferrari fxx
[22:00]  * imbrandon want
[22:21] <jimbaker> hazmat, i just proposed a branch that reuses security groups (and does not attempt to delete the machine security groups)
[22:22] <jimbaker> hazmat, seems to work well in actual usage against ec2 too
[22:28] <hazmat> SpamapS, i think some of your output concerns might be addressed by https://code.launchpad.net/~bcsaller/juju/sane_output_test_option/+merge/106067
[22:28] <hazmat> jimbaker, sweet!
[22:30] <jimbaker> hazmat, it certainly makes for a better experience
[22:33] <SpamapS> hazmat: hopefully. I think the issues are subtle.. but will bite us
[22:49] <m_3> mornin gang
[22:49] <imbrandon> heya m_3
[23:00] <SpamapS> alright, juju precise SRU going to precise-updates!
[23:00] <SpamapS> *finally*
[23:11] <m_3> whoohoo!
[23:49] <sigmonsays_> Hello
[23:49] <imbrandon> Hello
[23:50] <sigmonsays_> This is quite the long shot but I am curious about seeing gozk (go zookeeper) implementation. From my understanding, some pieces of juju were rewritten in Go to take advantage of talking to zookeeper using go. I was wondering what such implementation might look like
[23:52] <imbrandon> sigmonsays_: niemeyer wrote that ( gozk ) iirc, might be the best to ask
[23:54] <sigmonsays_> thanks imbrandon
[23:54] <m_3> sigmonsays_: https://launchpad.net/gozk it's all in the open