[00:00] <SpamapS> hazmat: Intel emerald ridge
[00:01] <SpamapS> hazmat: re the test failures.. what about the argparse bits?
[00:01] <hazmat> SpamapS, haven't run into those yet
[00:02] <hazmat> SpamapS, i manually installed the dep packages, checked out and ran tests
[00:02] <hazmat> SpamapS, do you have another mechanism you'd recommend to reproduce
[00:06] <hazmat> jimbaker, bcsaller can i get a +1 on this trivial.. http://paste.ubuntu.com/754300/
[00:07] <hazmat> that cleans up some of the tests to be more reliable
[00:07] <moozz> thanks folks just back and reading your points here
[00:10] <moozz> Spamaps, I open the cobbler web interface and check
[00:13] <SpamapS> hazmat: a checkout doesn't seem to show the behavior, only the installed version does
[00:14] <SpamapS> hazmat: its possible dh_python2 is broken or juju is doing something to confuse it
[00:16] <moozz> SpamapS, my .juju/environment.yaml is the same as the one in section 2. https://wiki.edubuntu.org/ServerTeam/OrchestraJuju
[00:17] <moozz> Spamaps, I also added: "default-series: oneiric"
[00:19] <moozz> SpamapS, I also made sure management classes has orchestra-juju-available selected.
[00:20] <moozz> SpamapS, I must have missed something else hey?
[00:27] <SpamapS> moozz: can you do a 'cobbler system show-variables -n name-of-system' and pastebin it?
[00:28] <SpamapS> moozz: you have to run that as root on the orchestra-provisioning-server
[00:31] <moozz> Spamaps, will do
[00:32] <moozz> SpamapS, to be honest I cannot remember
[00:34] <bcsaller> hazmat: you have to yield on watch_d twice in a row?
[00:34] <bcsaller> oh, bad read
[00:34] <moozz> Spamaps, I ran: 'sudo cobbler system show-variables -n oscs1' but get usage error message. I thing "show-variable" is not an option on my version
[00:35] <hazmat> bcsaller, yeah... the exists_d wait, is just to be nice.. its not really needed
[00:35] <bcsaller> hazmat: yeah, +1 on the trivial
[00:37] <moozz> SpamapS, Should I run this instead perhaps: "sudo cobbler system dumpvars"
[00:39] <hazmat> SpamapS, fixes committed, not sure about the argparse problem, i'll email barry about them
[00:40] <hazmat> s/it
[00:41] <SpamapS> moozz: yes thats the one
[00:41] <SpamapS> moozz: sorry mixing 3 different things in my head ;)
[00:43] <moozz> SpamapS, No probs. Here is the output -> http://pastebin.com/XSfGYW1M
[00:44] <hazmat> jimbaker, does 2to3 suggest xrange?
[00:44] <hazmat> that seems odd
[00:44] <hazmat> i thought that was gone in py3
[00:53] <moozz> SpamapS, Getting this error for a few cobbler commands: TypeError: cannot marshal None unless allow_none is enabled
[00:57] <_mup_> juju/trunk r421 committed by kapil.thangavelu@canonical.com
[00:57] <_mup_> [trivial] some minor test fixes from precise pkg builds [r=bcsaller]
[01:10] <moozz> SpamapS: It is midday here in AU not sure what time it is where u r, am I bothering u?
[01:12] <marcoceppi> config-get is available outside of the config-changed hook, correct?
[01:17] <hazmat> marcoceppi, yup
[01:18] <SpamapS> moozz: its 17:17 for me.. not bothering me at all but have a lot of stuff going on ;)
[01:18] <marcoceppi> Right, that's what I figured. What about relation-get seems it can't be used outside of it's hook, correct?
[01:18] <SpamapS> moozz: the dumpvars, I think you need to give it a -n system_name
[01:18]  * SpamapS re-installs cobbler to follow along
[01:19] <moozz> SpamapS: Says no suck option
[01:20] <moozz> SpamapS: will try with just host name
[01:21] <moozz> SpamapS: sudo cobbler system dumpvars oscs1 gives the same output as the previous pastebin
[01:22] <moozz> SpamapS: same with ip address
[01:23] <SpamapS> moozz: sudo cobbler system list
[01:26] <moozz> SpamapS: http://pastebin.com/x2R5YNFE
[01:26] <moozz> SpamapS: I have a host list. These are the hosts I eventually wish to build openstack on.
[01:28] <moozz> SpamapS: "sudo cobbler system dumpvars nova-compute" gives me the same error as in http://pastebin.com/XSfGYW1M
[01:29] <SpamapS> moozz: alright, I'm trying to get a test system up to follow along
[01:29] <SpamapS> moozz: --name nova-compute
[01:30] <moozz> SpamapS: Got output pastiing now
[01:31] <SpamapS> moozz: btw, you may want to apt-get install pastebinit
[01:31] <SpamapS> really helpful for this
[01:31] <SpamapS> cmd | pastebinit will put it into a pastebin for you :)
[01:32] <moozz> SpamapS: thanks. http://pastebin.com/Z0Ni59Hv
[01:33] <SpamapS> mgmt_classes : ['orchestra-juju-acquired']
[01:33] <SpamapS> moozz: this means juju believe it has taken control of that system
[01:33] <SpamapS> moozz: are you certain juju bootstrap failed?
[01:33] <moozz> SpamapS yes
[01:35] <moozz> SpamapS: I wonder how we can check f sure?
[01:36] <SpamapS> moozz: juju status
[01:36] <moozz> SpamapS: cool trick with pastebinit
[01:37] <moozz> SpamapS
[01:37] <moozz> SpamapS: ERROR juju environment not found: is the environment bootstrapped?
[01:40] <SpamapS> moozz: ok, so change that mgmt class to orchestra-juju-available and try bootstrap again
[01:40] <SpamapS> moozz: maybe do  juju -v bootstrap so you get verbose output
[01:41] <moozz> SpamapS: http://pastebin.com/TWwZLB0g
[01:43] <moozz> SpamapS: ok, I will list the env to check and out put to pastebin
[01:44] <SpamapS> moozz: did you try bootstrap again yet?
[01:45] <moozz> SpamapS is there a command line way to do this?
[01:47] <moozz> SpamapS: Tried this "sudo cobbler mgmtclass edit --name orchestra-juju-available"
[01:48] <SpamapS> moozz: no you'd want "sudo cobbler system edit --name nova-compute --mgmt-class 'orchestra-juju-available'
[01:49] <moozz> SpamapS: Yay! It worked. Should I make all other hosts available to?
[01:50] <moozz> SpamapS: Bummer, error actually: All available Cobbler systems were also marked as acquired (instances: MTMyMjUzMzEwOC42MjYwNDAxNjEuMjAwODk)
[01:50] <SpamapS> moozz: Its best to make them available one at a time, so that you can make sure the service you're deploying goes to the system you want it on.
[01:51] <SpamapS> moozz: hah, weird
[01:51] <moozz> SpamapS: very
[01:51] <SpamapS> moozz: dumpvars again, check the mgmtclass
[01:51] <moozz> ok
[01:52] <moozz> SpamapS: http://paste.ubuntu.com/754358/
[01:53] <moozz> SpamapS: Seems set
[01:54] <SpamapS> moozz: I just tried    sudo cobbler system edit --name=foo --mgmt-classes="orchestra-juju-available"   and it overwrite the acquired with only avialable
[01:55] <moozz> SpamapS: Any idea what this error means then?
[01:56] <SpamapS> moozz: on your system, you have both.. mgmt_classes : ['orchestra-juju-acquired', 'orchestra-juju-available']
[01:56] <SpamapS> moozz: you need it to just have 'orchestra-juju-available'
[01:58] <SpamapS> moozz: you're going to run into one problem here.. with only 3 machines.. you won't have anywhere to put rabbitmq and mysql
[01:58] <moozz> SpamapS: Sorry about the dumb question but what does the "...acquired" do?
[01:59] <SpamapS> moozz: available means "available for juju" , acquired means "taken by juju"
[02:00] <moozz> SpamapS: ok doing now? :-)
[02:01] <moozz> SpamapS: Done, now "'dict' object has no attribute 'read'" after typing juju bootstrap. :-)
[02:02] <SpamapS> moozz: *wha* ?
[02:05] <moozz> SpamapS: Seems now when I run "juju bootstrap" I get the error "'dict' object has no attribute 'read'"
[02:05] <SpamapS> moozz: I understand that. But maybe you could run it with '-v' and pastebin that?
[02:07] <moozz> SpamapS: ok
[02:08] <SpamapS> moozz: thats not a normal condition. :-/
[02:11] <moozz> SpamapS: http://pastebin.com/nybeHuxY
[02:12] <SpamapS> moozz: interesting.. can you try 'sudo cobbler system edit --name=nova-compute --ks-meta=""' then bootstrap again?
[02:13] <SpamapS> moozz: I think there's an existing bug for this problem
[02:14] <moozz> SpamapS: cobbler: error: no such option: --ks-meta; You are trying to send an empty document, exiting
[02:15] <SpamapS> moozz: darn inconsistent cli.. change it to --ksmeta
[02:17] <moozz> SpamapS: SpamapS: Same
[02:18] <SpamapS> moozz: can you do a cobbler system dumpvars on it again and grep for 'ks_meta' ?
[02:18] <moozz> SpamapS: Note class is set to accuired
[02:19] <moozz> ok
[02:19] <SpamapS> moozz: acquired, but you're getting the dict/read bug?
[02:20] <moozz> Spamaps: http://paste.ubuntu.com/754379/
[02:21] <SpamapS> ks_meta : tree=http://@@http_server@@/cblr/repo_mirror/oneiric-x86_64
[02:21] <SpamapS> doesn't seem like it got fixed
[02:21] <moozz> SpamapS: I will try running the command again
[02:21] <SpamapS> moozz: the ks_meta should be *empty*, mgmt class should be ONLY orchestra-juju-available ..
[02:23] <moozz> SpamapS: tried to clear the ks_meta again but no luck
[02:24] <moozz> SpamapS: hmm :-P
[02:24] <SpamapS> moozz: --ksmeta="" works for me
[02:24] <moozz> :-)
[02:25] <moozz> SpamapS: can this be checked in the Web UI?
[02:26] <SpamapS> moozz: yourserver/cobbler_web should have a web UI on it
[02:26] <moozz> SpamapS: Just checked the UI and empty. ??
[02:27] <moozz> SpamapS: No kickstart metadata there
[02:28] <moozz> Spamaps: Checking inhetit in the UI
[02:29] <SpamapS> moozz: and the mgmt classs?
[02:30] <moozz> SpamapS: mgmt classes empty
[02:31] <SpamapS> moozz: so.. put the available one in ;)
[02:32] <moozz> SpamapS: system: no ks_meta, should i remove <<inhert>> from the oneiric-x8x_64-juju profile?
[02:34] <SpamapS> moozz: definitely not!
[02:35] <moozz> SpamapS: ok. Should the management classes have nothing set in them? as they do have nothing set
[02:36] <SpamapS> moozz: ... no.. they should have orchestra-juju-available
[02:37] <moozz> SpamapS: The class exists but has no packages or files specified
[02:38] <moozz> SpamapS: Sorry about all this
[02:38] <SpamapS> um, packages? what?
[02:38] <SpamapS> moozz: I think you may be confusing terms
[02:39] <SpamapS> moozz:under the system record in the web interface, sub menu "Management" the only thing that matters is "Management Classes"
[02:39] <moozz> SpamapS: under: configuration->Management Classes-> orchestra-juju-available->resources-> nothing is set
[02:40] <SpamapS> That doesn't mean anything
[02:40] <SpamapS> Configuration->Systems
[02:40] <SpamapS> thats where the magic happens
[02:40] <moozz> SpamapS: ok
[02:41] <moozz> SpamapS: Yes it is set
[02:42] <moozz> SpamapS: Wonder where the dict issue is comming from
[02:43] <SpamapS> dunno
[02:43] <SpamapS> but I have to go now
[02:43] <SpamapS> family is home
[02:43] <SpamapS> moozz: good luck.. maybe send to the mailing list if you get stuck
[02:43] <moozz> SpamapS: Many thanks and very sorry
[02:50] <hazmat> SpamapS, cheers
[04:14] <marcoceppi> Is there any limitation on the length of time a hook can run?
[04:43] <SpamapS> marcoceppi: no, but there's some thought that it would be a good idea
[04:46] <marcoceppi> Okay, I've got an install hook that's going to take about...45 minutes
[04:48] <marcoceppi> So, just FYI
[04:49] <SpamapS> marcoceppi: might it be better to put that in the background?
[04:49] <marcoceppi> maybe, but how could I capture an install fail if it fails?
[04:49] <SpamapS> marcoceppi: what will it be doing for 45 min?
[04:49] <marcoceppi> one word: cpan
[04:51] <marcoceppi> Hopefully there's an easier way to get all these Perl modules
[04:55] <SpamapS> cpan?
[04:56] <SpamapS> its not packaged?
[04:56] <SpamapS> or rather..
[04:56] <SpamapS> the stuff you need isn't packaged?
[04:57] <SpamapS> marcoceppi: debian has *really* good tools for turning cpan stuff into debs
[04:58] <marcoceppi> Oh, maybe it is packaged I'm following instructions from the INTERNETS
[04:58] <SpamapS> marcoceppi: dh-make-perl in particular understands CPAN perfectly
[05:25] <SpamapS> marcoceppi: koha?
[05:28] <marcoceppi> SpamapS Yeah actually
[05:29] <SpamapS> marcoceppi: saw your G+ post
[05:29] <SpamapS> marcoceppi: surprised that they use debian and suggest CPAN
[05:34] <marcoceppi> SpamapS: yeah, the install uses a mix of cpan and packages, I'm trying to track down all the packages now to avoid cpan
[05:36] <SpamapS> marcoceppi: perl can be like wonderland... ;)
[06:33] <koolhead17> hi all
[06:35] <koolhead17> the instance id i provide in my yaml file is required to have a user name "ubuntu"
[06:36] <koolhead17> i mean the instance ?
[07:25] <SpamapS> koolhead17: what instance?
[07:26] <SpamapS> koolhead17: do you mean the image id?
[07:26] <koolhead17> SpamapS: yes
[07:26] <koolhead17> am running Juju on openstack
[07:26] <koolhead17> *trying
[07:27] <SpamapS> koolhead17: the standard ubuntu 11.10 cloud images should work fine on openstack
[07:27] <koolhead17> SpamapS: am not using cloud image am using amd64 11.10 server image with my own customization as per my network requirement
[07:28] <SpamapS> ah so you're using the orchestra provider?
[07:28] <koolhead17> SpamapS: no
[07:28] <koolhead17> :)
[07:28] <SpamapS> well then I'm confused
[07:29] <SpamapS> why won't the cloud images work?
[07:29] <koolhead17> SpamapS: this is what i have done
[07:29] <koolhead17> 1. my own openstack infra is up and running
[07:29] <koolhead17> 2. over that i am trying to install juju and try/experiment with the charms
[07:30] <SpamapS> koolhead17: great, so, load the Ubuntu cloud images into glance, and you should be all set.
[07:30] <koolhead17> 3. since my nova and internal network both are behind proxy i need to mention that info in my /etc/apt/config
[07:30] <SpamapS> koolhead17: I don't think charms assume the ubuntu user.. but I do think juju might assume it for ssh purposes.
[07:31] <koolhead17> SpamapS: yes juju assumes, so  i was wondering if i should remaster the image creating a user ubuntu
[07:31] <koolhead17> :)
[07:31] <SpamapS> koolhead17: well you can rebundle the Ubuntu cloud image with your changes.
[07:32] <koolhead17> SpamapS: cloud image has no username/passwd to i can log in with :(
[07:32] <koolhead17> smoser: suggested me another way, i will try to do that when am in office
[07:32] <koolhead17> SpamapS: cloud image log in is keybased
[07:34] <koolhead17> that is why i was using the amd64 image instead cloud image :(
[07:36] <SpamapS> koolhead17: juju expects keys too
[07:37] <koolhead17> SpamapS: i think metadata server/nova does that 4 juju
[07:38] <koolhead17> SpamapS: let me ping you in say 1 hr once am there :)
[07:40] <SpamapS> koolhead17: will be asleep by then
[07:40] <SpamapS> about to sign off
[07:40] <SpamapS> koolhead17: sorry... good luck tho.. :)
[07:43] <koolhead17> SpamapS: np. will keep you posted. :D
[09:43] <_mup_> Bug #898082 was filed: immediate agent restart fails <juju:New> < https://launchpad.net/bugs/898082 >
[11:58] <niemeyer> Hello jujuers!
[11:59] <koolhead11> hello niemeyer :)
[12:13] <rog> niemeyer: mornin'!
[12:34] <niemeyer> koolhead11, rog: What's up for the day?
[12:35] <rog> niemeyer: my aim for the day is (at least) to get go juju to start an instance with zookeeper running on it, with appropriate tests.
[12:35] <niemeyer> rog: Woohay!
[12:35] <niemeyer> rog: Mine is to unblock your ec2 branch :-)
[12:35] <rog> niemeyer: oh please, please!
[12:38] <rog> niemeyer: mind you, your reviews will probably skupper my forward progress at tip :-)
[12:38] <niemeyer> rog: Yeah, kind of expected.. sorry about that
[12:39] <rog> niemeyer: that's fine, it will be great to remove the sword dangling over my head...
[12:41] <rog> niemeyer: BTW when i come to implement a piece of functionality, i'm assuming if in doubt it's best to just port the existing python code (modulo Go structural changes) and all its heuristics, to try and avoid second system effect. is that the right thing to do?
[12:41] <koolhead11> hola rog :)
[12:42] <rog> koolhead11: hi
[12:42] <niemeyer> rog: Absolutely
[12:42] <rog> niemeyer: good
[12:43] <niemeyer> rog: We can refactor down the road much more easily, and introducing more significant differences won't be a problem when there isn't a second version
[12:43] <rog> niemeyer: that's what i thought.
[12:43] <koolhead11> niemeyer: am not using the custom cloud image so i have 3 changes in my server image. 1. get cloud-init installed 2.user ubuntu needs to be created and my juju system publick key has to b there and at same time i need to have public key info of the image
[12:43] <rog> niemeyer: but it does mean that code is more complex initially than it would be for the functionality that currently exists
[12:43] <rog> s/would be/needs to be/
[12:44] <niemeyer> rog: Hmm, do you have some example?
[12:45] <niemeyer> koolhead11: I'm out of context.. all of those things work well in a standard Ubuntu image. What's going on there?
[12:45] <koolhead11> niemeyer: am using 11.10 server 64 bit image
[12:46] <koolhead11> and just added info of my proxy server in it /etc/apt/config
[12:46] <rog> niemeyer: for instance, the cloudinit stuff talks about provisioners, but we don't have a provisioner yet
[12:47] <koolhead11> niemeyer: Cannot connect to machine i-0000002e (perhaps still initializing): Invalid SSH key 2011-11-30 18:15:15,815 ERROR Cannot connect to machine i-0000002e (perhaps still initializing): Invalid SSH key
[12:47] <niemeyer> rog: Can you paste a snippet just to make the idea more concrete?
[12:47] <koolhead11> 2011-11-30 18:16:05,767 DEBUG Spawning SSH process with remote_user="ubuntu" remote_host="192.168.4.4" remote_port="2181" local_port="49900".
[12:48] <rog> niemeyer: http://paste.ubuntu.com/754811/
[12:48] <niemeyer> koolhead11: Yeah, for some reason it can't login into the ubuntu account
[12:49] <niemeyer> koolhead11: It's really hard for me to tell you why because you have an image that does not match the standard cloud image, apparently
[12:49] <rog> niemeyer: the structure is somewhat different, but the code is pretty much exactly taken from the python
[12:49] <niemeyer> koolhead11: I recommend trying to login, by hand, onto the machine
[12:49] <niemeyer> koolhead11: ssh ubuntu@<ip>
[12:49] <niemeyer> koolhead11: This should work
[12:49] <niemeyer> koolhead11: If it doesn't, it means cloud-init failed to put your key in the proper location in the proper way, for reasons that will have to be found
[12:50] <koolhead11> niemeyer: its asking 4 passsword
[12:51] <koolhead11> niemeyer: but am not sure if ubuntu server iso has a user with name ubuntu :(
[12:52] <niemeyer> rog: I see your point. Haven't evaluated the code, but the structure looks fine.
[12:53] <rog> niemeyer: good.
[12:53] <niemeyer> koolhead11: Yeah, it shouldn't ask for a password, because bootstrap sent your ssh key there
[12:53] <rog> niemeyer: that file is the moral equivalent of providers/common/cloudinit.py, BTW
[12:53] <niemeyer> koolhead11: Which cloud-init should install in the system
[12:53] <niemeyer> koolhead11: In the Ubuntu user
[12:54] <koolhead11> niemeyer:  0.6.1-0ubuntu22
[12:54] <niemeyer> koolhead11: ?
[12:54] <koolhead11> my custom image has no user ubuntu
[12:54] <koolhead11> niemeyer: my cloud init version
[12:54] <koolhead11> :p
[12:55] <niemeyer> koolhead11: You'll have to change your image so it behaves like the other cloud images.
[12:55] <koolhead11> niemeyer: and what all it will have apart from cloud-init, a user ubuntu ?
[12:56] <niemeyer> koolhead11: I apologize, but I have no way to tell how your custom image differs from a standard image
[12:56] <niemeyer> koolhead11: I'd use the standard images instead
[12:56] <koolhead11> niemeyer: okey. let me dig into it. Will keep you posted :D
[12:57] <niemeyer> koolhead11: Cool, sorry about that
[12:57] <koolhead11> np
[12:58] <rog> niemeyer: BTW, i'm looking at get_user_authorized_keys in common/utils.py. how much of that is necessary? for instance, we haven't got an implementation of os.path.expandvars AFAIK, but perhaps that functionality isn't much used.
[12:59]  * niemeyer looks
[13:00] <niemeyer> rog: I'm a bit surprised to see it there as well
[13:01] <rog> niemeyer: there's also the singular/plural thing, which i think is probably a bug in the original, if authorized-keys has more than one key
[13:02] <niemeyer> rog: How do you mean
[13:02] <niemeyer> rog: Ah, the comment
[13:02] <niemeyer> rog: The comment is bogus
[13:03] <niemeyer> rog: The name of the file is "authorized_keys", and it can contain more than one key concatenated to each other
[13:03] <rog> niemeyer: not just that. depends whether append can take an item and/or a list. i can check.
[13:03] <niemeyer> rog: That's where the name comes from
[13:03] <rog> niemeyer: it looks like authorized-keys is a key in the environment config file
[13:04] <rog> niemeyer: which contains literal keys
[13:04] <niemeyer> rog: ~/.ssh/authorized_keys is the name of the ssh file
[13:04] <niemeyer> rog: Where that setting will end up in
[13:04] <rog> niemeyer: but:
[13:04] <niemeyer> rog: The file accepts a concatenated list of keys
[13:04] <rog> if config.get("authorized-keys"):
[13:04] <rog>         return config["authorized-keys"]
[13:04] <niemeyer> rog: Yes, that's fine?
[13:05] <rog> isn't that getting a set of literal keys from the config file?
[13:05] <niemeyer> rog: This is getting a value from the config file
[13:05] <niemeyer> rog: That should contain the text to be inserted into ~/.ssh/authorized_keys
[13:05] <rog> niemeyer: so authorized-keys contains only one string?
[13:05] <niemeyer> rog: Yes, the text to be inserted into ~/.ssh/authorized_keys
[13:06] <rog> niemeyer: ok, that's cool then. i'm not familiar with all the ssh config stuff
[13:07] <niemeyer> rog: No worries
[13:07] <rog> niemeyer: presumably all the heuristics in get_user_authorized_keys are standard, but it's all somewhat opaque to me
[13:07] <niemeyer> rog: I'll change the Python version to remove the bogus comment
[13:09] <rog> niemeyer: hmm, in that case shouldn't it return the concatenation of all the keys in key_names?
[13:10] <niemeyer> hazmat: ping
[13:10] <rog> lunch
[13:11] <niemeyer> rog: I don't know what you mean by that
[13:11] <hazmat> niemeyer, pong
[13:11] <niemeyer> rog: Well, potentially, but the current is fine as well
[13:11] <niemeyer> hazmat: Quick cowboying:
[13:12]  * hazmat grabs a hat
[13:12] <niemeyer> hazmat: http://paste.ubuntu.com/754828/
[13:15] <hazmat> niemeyer, +1
[13:15] <niemeyer> hazmat: Cheers
[13:15] <hazmat> niemeyer, was the variable stuff causing a problem?
[13:15] <hazmat> just unexpected?
[13:16] <niemeyer> hazmat: Not exactly, but there's no _trivial_ function like that yet, and it's currently unused/untested/unnecessary in the Python side, so I decided to try the easy way of keeping the compatibility :)
[13:16] <hazmat> niemeyer, fair enough
[13:17] <hazmat> i have to help out building a garage out back for a little bit, i'll be back in 40m
[13:18] <niemeyer> hazmat: Cool, see you soon
[13:24] <hazmat> looks like thats already well in hand by others
[13:28] <_mup_> juju/trunk r422 committed by gustavo@niemeyer.net
[13:28] <_mup_> Removing bogus comment from get_user_authorized_keys (with
[13:28] <_mup_> justification comment), and removing untested/unused/unnecessary
[13:28] <_mup_> use of expandvars so that it's simpler to keep compatibility.
[13:28] <_mup_> [r=hazmat]
[13:28] <niemeyer> rog: ^
[13:28] <rog> niemeyer: thanks
[13:28] <rog> niemeyer: BTW is there a reason why authorized-keys-path isn't mentioned in environment/config.py ?
[13:29] <rog> niemeyer: doesn't that mean it won't be allowed if someone does actually try to specify it?
[13:29] <niemeyer> rog: No, should be mentioned
[13:30] <rog> niemeyer: and authorized-keys too, presumably
[13:30] <niemeyer> rog: as optional
[13:30] <niemeyer> rog: yeah
[13:30] <rog> niemeyer: hmm, shows it's not much used :-)
[13:30] <niemeyer> rog: It does not mean that, though
[13:30] <niemeyer> rog: Not really.. this is used by _every single deployment_
[13:30] <rog> ah
[13:31] <rog> so any key not mentioned in environment/config.py is actually allowed?
[13:31] <niemeyer> rog: KeyDict doesn't kill unknowns
[13:31] <rog> niemeyer: ah, so unknowns just don't get any checking, but they still go in
[13:32] <niemeyer> rog: Right
[13:32] <rog> damn, i was assuming that environment/config.py mentioned everything
[13:32] <rog> i wonder what other keys are lurking around
[13:33] <rog> niemeyer: just to check, both authorized-keys and authorized-keys-path should go in as String() ?
[13:34] <hazmat> fwereade, SpamapS was helping someone with orchestra last night (8hrs ago), and they pointed to some traceback they where able to get in juju.. http://pastebin.com/nybeHuxY just wondering if this rang any bells
[13:36] <mpl> niemeyer: hi. do you want the logger to be used in the charm and schema packages as well? i.e should I replace fmt calls there to logF calls for example?
[13:36] <fwereade> hazmat, well, I can see what's *happening*, but colour me surprised
[13:37] <hazmat> f
[13:37] <hazmat> odd, my irc client spontaneously froze and reconnected
[13:38]  * hazmat kicks xchat
[13:38] <fwereade> hazmat, I can take a proper look at it soon if you like?
[13:38] <hazmat> fwereade, the irc logs have some additional context, i dunno that it was setup correctly, but i doubt a user would know it from the traceback
[13:39] <fwereade> hazmat, well, it's weird, it looks like the data is coming back in a format it would be *lovely* if it did come back in, but hasn't IME
[13:39] <fwereade> hazmat, I'll kick it around and see what I can come up with
[13:43] <hazmat> fwereade, for context.. most of the  conversation with 'moozz' is here http://irclogs.ubuntu.com/2011/11/30/%23juju.html
[13:43] <fwereade> hazmat, I'm reading it, thanks :)
[13:52] <rog> niemeyer: looking in the final cloudinit code, it does seem to assume that each entry in ssh_authorized_keys is a separate key.
[13:53] <rog> niemeyer: it can put a prefix on every key, which won't work if there's more than one line in a key
[13:53] <niemeyer> rog: Where's that?
[13:53] <rog> in cloudinit/CloudConfig/cc_ssh.py
[13:53] <rog> in the cloudinit source
[13:54] <rog> niemeyer: line 98, in particular
[13:57] <rog> niemeyer: it will probably work de-facto because we won't be using disable_root but i think it's probably worth getting right
[13:59] <rog> niemeyer: add_ssh_key in common/cloudinit.py should probably be add_ssh_keys otherwise too
[14:01] <niemeyer> rog: Looking
[14:03] <niemeyer> rog: Yeah, there's a minor mismatch in the Python code indeed
[14:04] <niemeyer> rog: It's not broken because it never reaches the point of actually dealing with the keys
[14:04] <rog> niemeyer: i think get_user_authorized_keys should return a list
[14:04] <niemeyer> rog: Yeah, that sounds fine
[14:04] <niemeyer> rog: But it should not require a list from the user
[14:05] <niemeyer> rog: In the configuration/file, that is
[14:05] <rog> niemeyer: it's slightly broken, i think, because add_ssh_key can be called with multiple keys in the same string
[14:05] <rog> niemeyer: which will lead to the above mentioned mismatch in the final cloudinit code
[14:05] <niemeyer> rog: I mean it's not broken in the sense that it works
[14:05] <rog> niemeyer: unless you're relying on disable_root, i guess
[14:05] <niemeyer> rog: Which we're not, so it works
[14:06] <rog> niemeyer: yup
[14:06] <niemeyer> rog: You're right that it's logically incorrect
[14:06] <rog> i wonder if authorized-keys-path should allow a set of names
[14:06] <niemeyer> rog: No
[14:07] <niemeyer> rog: It should accept a single path, with a list of keys, in the well known format of an authorized_keys path.. no invention there.
[14:07] <rog> niemeyer: ok. so should get_authorized_keys make sure to return at most one key?
[14:08] <rog> er, no
[14:08] <niemeyer> rog: Yeah, it sounds like a good interface as far as Go is concerned
[14:08] <niemeyer> rog: (keys []string, err error)
[14:08] <rog> yup. hmm, authorized-keys could accept a set of keys
[14:09] <niemeyer> rog: Well.. that said, it's trivial to test for list(keys) == 0
[14:09] <niemeyer> rog: Hmmm.. but we need the error anyway, so +1 on (keys, err)
[14:09] <niemeyer> rog: and erroring if not keys are ofund
[14:09] <niemeyer> found
[14:09] <niemeyer> no
[14:09] <niemeyer> Erm
[14:09] <rog> lol
[14:09] <niemeyer> rog: and erroring if no keys are ofund
[14:09] <niemeyer> Ok, I can't type.. I hope you get it :)
[14:09] <rog> i do
[14:10] <rog> niemeyer: i do wonder about authorized-keys though
[14:10] <niemeyer> rog: It's too late to wonder.. it already has a format, and we should follow it for the moment
[14:10] <rog> niemeyer: presumably it will only allow one key currently (it'll probably produce a malormed cloudinit if you put in something else)
[14:10] <rog> ok
[14:10] <rog> it should really be authorized-key :-)
[14:11] <niemeyer> rog: Nope
[14:11] <niemeyer> rog: For the same reason that authorized_keys is keys.. it accepts multiple keys.
[14:11] <niemeyer> rog: We can handle a list internally consistently, while accepting the authorized_keys format in those options
[14:11] <rog> niemeyer: sounds good
[14:29] <_mup_> juju/trunk r423 committed by gustavo@niemeyer.net
[14:29] <_mup_> Add a comment to get_user_authorized_keys pointing out the
[14:29] <_mup_> inconsistency spotted by Roger.
[14:30] <rog> niemeyer: actually, on balance, i think it's easier to treat the authorized_keys contents as universal currency, and do the split when marshalling the cloudinit file.
[14:30] <rog> thus http://paste.ubuntu.com/754923/
[14:31] <niemeyer> rog: Sounds fine, except this function looks weird
[14:31] <rog> and http://paste.ubuntu.com/754925/
[14:32] <niemeyer> rog: This feels like over-engineering things a bit
[14:32] <rog> niemeyer: it ends up simpler, i think
[14:32] <niemeyer> rog: get_user_authorized_keys is a single function, small, that does what we need
[14:32] <rog> niemeyer: currently, get_user_authorized_keys relies on poking inside config
[14:32] <rog> niemeyer: i was trying to avoid that
[14:33] <rog> niemeyer: and in the process make a more generally useful function
[14:33] <rog> niemeyer: but i'm open to different ideas
[14:35] <niemeyer> rog: The motivation is good, but there's missing functionality, and I'm afraid you'll end up implementing pretty much the full logic for the current function elsewhere, in addition to the generic version you came up with
[14:36] <niemeyer> rog: Well, or maybe not..
[14:37] <niemeyer> rog: I guess the problem is mainly on the documentation
[14:37] <rog> niemeyer: i think the only logic missing is this: http://paste.ubuntu.com/754934/
[14:37] <rog> which seems reasonable
[14:37] <niemeyer> rog: Agreed, you just have to fix the documentation
[14:38] <niemeyer> rog: This function doesn't _find_ an authorized_keys file, it _assembles_ one.
[14:38] <rog> niemeyer: it returns the contents of an authorized_keys file, no?
[14:38] <niemeyer> rog: Then, the fact it takes an argument is weird.. if you pass the argument in, this function becomes ioutil.ReadFile
[14:39] <rog> niemeyer: yeah, i know.
[14:39] <niemeyer> rog: No, read the Python function again
[14:39] <rog> ah, no you're right it's not.
[14:39] <rog> it expands home dirs
[14:39] <niemeyer> rog: Ah, ok
[14:39] <niemeyer> rog: Sounds fine then
[14:39] <rog> niemeyer: that needs documenting tho
[14:40] <niemeyer> rog: Btw, your original point of assembling the file with all keys sounds fine
[14:40] <jcastro> mainerror: ok I owe you some testing
[14:40] <jcastro> I mean marcoceppi
[14:40] <rog> niemeyer: good. i started to do it the other way, but this seemed better.
[14:40] <niemeyer> rog: That said, I wonder if we should be returning a list indeed.. it feels like a good point for doing that, even more given that we'll have to concatenate the keys
[14:40] <rog> niemeyer: i don't think we ever concatenate keys
[14:41] <niemeyer> rog: If you assemble the file with all keys, how do you plan to return all of them?
[14:41] <rog> niemeyer: there's only ever one file used
 rog: Btw, your original point of assembling the file with all keys sounds fine
[14:41] <rog> oh... do you mean my *original* point?
[14:41] <rog> back ages and ages ago
[14:41] <niemeyer> :-)
[14:42] <rog> i think i'd just concatenate them.
[14:42] <niemeyer> rog: I'd prefer to have a list..
[14:42] <niemeyer> rog: We'll need the list no matter what
[14:43] <rog> niemeyer: yeah, at one level or other.
[14:43] <niemeyer> rog: But, I'm fine either way
[14:43] <rog> niemeyer: i'll see how it goes with a list. i'll probably have a separate parse function
[14:43] <niemeyer> rog: Cool
[14:43] <rog> niemeyer: that's called by AuthorizedKeys
[14:43] <rog> niemeyer: the parsing is trivial, luckily
[14:44] <niemeyer> rog: Indeed
[14:45] <rog> niemeyer: is it possible for an authorized_keys file to be malformed?
[14:45] <niemeyer> rog: :-)
[14:45] <rog> niemeyer: just wondering whether ParseAuthorizedKeys needs to return an error...
[14:46] <niemeyer> rog: I'd say not at this time, at least..
[14:46] <niemeyer> rog: Btw, s/Parse/parse/, please
[14:47] <niemeyer> rog: Oh, crap.. we may need it to parse the config option
[14:47] <rog> niemeyer: hmm. i was thinking of having it in the public interface, so external agents can easily add their own authorized_keys files to cloudconfig if they want.
[14:48] <niemeyer> rog: Yeah, sorry, sounds sane
[14:48] <rog> oh yeah.
[14:48] <rog> *that*'s why i wanted to have it return a string
[14:48] <rog> because otherwise the external logic becomes more complex
[14:49] <niemeyer> rog: Ok, I'm convinced.. :)
[14:49] <rog> lol
[14:49] <rog> i'll go with that until i decide otherwise :-)
[14:50] <niemeyer> Ouch.. I missed a call
[14:51] <hazmat> niemeyer, when you've got a minute, i replied to the clean stop merge proposal, with some comments a  link to a stop protocol i'd like to discuss
[14:51] <hazmat> s/and a
[14:52] <jcastro> m_3: ok I'm starting with phpmyadmin and then on to status net
[14:53] <niemeyer> hazmat: Cool.  I need to get some lunch, and will need to interview someone afterwards if I manage to reschedule the slot I just missed, but then we can talk.
[14:53] <hazmat> niemeyer, sounds good, i'm around, just ping
[14:53] <niemeyer> hazmat: Will do
[15:00] <jcastro> marcoceppi: ping me when you're around
[15:00] <jcastro> m_3: SpamapS: you guys too, we have an opportunity to bikeshed!
[15:07] <mpl> rog: I'm having trouble setting a go env where I can satisfy all the deps at the same time without having to resort to gofix. (gotest, goetveld, juju itself etc). Have you decided on which go version you're following for most of the tools?
[15:07] <rog> mpl: i'm moving to weekly for everything
[15:08] <mpl> hmm, and so is gustavo?
[15:08] <rog> mpl: some things i've run gofix on but not submitted a merge request. i've forgotten which ones :-)
[15:09] <rog> mpl: yeah, i think so. os.Error is just old hat these days :-)
[15:09] <mpl> ouch. gocheck for ex seems to still use os.Error
[15:09] <mpl> exactly.
[15:09] <rog> mpl: i might have pushed a merge req for gocheck. i'll just see.
[15:10] <mpl> thx
[15:10] <rog> mpl: yeah. https://code.launchpad.net/~rogpeppe/gocheck/fix-error-printing
[15:10] <rog> it's still pending
[15:10] <rog> niemeyer: ^
[15:11] <mpl> ok, good to know, thx.
[15:12] <mpl> I wish there was a goinstall mode where it would run gofix on the fly.
[15:14] <rog> mpl: i think there's such a thing just been implemented
[15:15] <mpl> cool
[15:39] <m_3> jcastro: yo
[15:39] <jcastro> m_3: hey so marco has a use_upstream config option
[15:39] <m_3> nice
[15:39] <jcastro> which is basically "get upstream instead of the package"
[15:40] <jcastro> which is fine, but I think that we should sort out what we should call it
[15:40] <jcastro> as I'm sure a bunch of charms will want to do this
[15:40] <m_3> right, discussed yesterday
[15:40] <jcastro> ah ok
[15:40]  * jcastro goes reading IRC logs
[15:40]  * m_3 looks to see if marco added it to charm-tools
[15:41] <m_3> jcastro: may've been the day before... dunno
[15:45] <jcastro> oh ok
[15:45] <jcastro> so we have the same way for everybody, that's all I was asking
[15:45] <jcastro> m_3: thank you for not making it "promulgate_upstream=true"
[15:46] <m_3> ha!
[15:46] <jcastro> ok the phpmyadmin stuff works for me
[15:47] <m_3> jcastro: cool... finishing ts3 review, then I'll do phpmyadmin
[15:48] <jcastro> ok I think we have status.net incoming today too
[15:48] <m_3> rockin
[15:48] <jcastro> m_3: oh hey, remember to manually poke me when you accept one just in case I miss it, so I can start the blog entry
[15:49] <m_3> jcastro: cool... will do.  I'll ping you when it's actually promulgated to lp:charm... there's sometimes time delay between fix-released and prom
[15:50]  * jcastro nods
[15:52] <jcastro> SpamapS: I'm going to start a wiki page on this: https://bugs.launchpad.net/charm/+bug/894825/comments/8
[15:52] <_mup_> Bug #894825: Teamspeak charm needed <new-charm> <juju Charms Collection:Triaged> < https://launchpad.net/bugs/894825 >
[15:52] <jcastro> and add it to the steps, because we need to start forcing ourselves to document this
[15:53] <SpamapS> jcastro: right, charm guide. :)
[15:54] <jcastro> I was going to go with "charm snippets"
[15:54] <jcastro> but ok, charm guide it is
[15:54] <SpamapS> I don't like the term snippets... it implies that this is trivial stuff.
[15:57] <jcastro> SpamapS: can you add the "get the tarball" one here to this page? That outta be enough for now.
[15:57] <jcastro> https://juju.ubuntu.com/CharmGuide
[15:59] <SpamapS> jcastro: Talk accepted for SCALE!!!
[15:59] <jcastro> \o/
[15:59] <SpamapS> jcastro: I wonder if we can use something like doxygen and have inline comment blocks document the charm helper API
[16:00] <koolhead11> SpamapS: hey
[16:00] <SpamapS> jcastro: ooo.. ignite talks http://www.socallinuxexpo.org/scale10x/events/upscale
[16:01] <jcastro> SpamapS: oh man
[16:01] <jcastro> SpamapS: I started saying "we should do one" but then that would be like 4 events for us
[16:06] <robbiew> plus we're sponsoring the Cloud & Virt track
[16:07] <robbiew> I think we're good ;)
[16:07] <robbiew> especially if I can get the shirts sorted
[16:14] <SpamapS> I might do one
[16:15] <SpamapS> but it won't be ubuntu or juju related.. just something funny I've been working on
[16:15] <jcastro> so far we'd do devops day lightning talk (if we can get it), charm school, and then our normal talk
[16:21] <marcoceppi> jcastro: hey
[16:21] <jcastro> marcoceppi: lunching, catch you on the flip side, my ride is here
[16:21] <m_3> damn, "PTY allocation request failed on channel 0" suddenly crept up again for LXC
[16:36] <marcoceppi> m_3: I get that all the time on another server, but only when I connect from Ubuntu, when I do it from a Mac OSX terminal, it doesn't occur.
[16:39] <m_3> marcoceppi: I have to flush the lxc cache when it happens... got about two weeks of lxc runs out of this last one
[16:48]  * hazmat lunches
[16:53] <fwereade_> back shortly, early supper
[16:55] <SpamapS> m_3: have we reported that bug yet? seems like its an LXC bug
[16:56] <jcastro> marcoceppi: ok back, phpmyadmin worked for me
[16:56] <jcastro> I have a dumb question though
[16:56] <marcoceppi> jcastro: Sweet! I'm still working on the package thing but that's coming along nicely
[16:56] <jcastro> what happens if you set the use_upstream config after you've deployed?
[16:56] <marcoceppi> Oh?
[16:57] <jcastro> I tried setting it before I deployed, but got an error
[16:57] <marcoceppi> Well, use_upstream doesn't do anything
[16:57] <jcastro> ah, so that's why I can't find anything in there
[16:57] <jcastro> ok. :)
[16:58] <marcoceppi> in the latest pushed, what will happen - if the package is installed then it'll purge the package and do an install from upstream then re-generate the config, vice versa for upstream -> pkg
[16:58] <marcoceppi> err, when this is done - not latest pushed
[17:00]  * jcastro nods
[17:00] <jcastro> that will be handy
[17:00] <jcastro> this could be an awesome use case right
[17:00] <jcastro> you use the packaged version
[17:01] <jcastro> and then you run into a bug.
[17:01] <jcastro> you report it and doing your due diligence you find it was fixed in the latest upstream release
[17:01] <jcastro> you can "switch" the instances you care about
[17:01] <jcastro> test, report back, then eventually -> SRU.
[17:02] <SpamapS> marcoceppi: *saweeet*
[17:02] <marcoceppi> Yeah, I hope to have it pushed up for review by the end of the day so I can call this one a wrap
[17:03] <jcastro> <3
[17:03] <SpamapS> Though what would be really great would be an auto-backports PPA that just has all the latest versions of software in the Ubuntu dev release in it for all the supported versions so you don't have to go "off the reservation" :)
[17:03] <jcastro> marcoceppi: george's statusnet charm will need a review soon
[17:04] <marcoceppi> SpamapS: What's edge if you don't bleed a little :)
[17:04] <marcoceppi> jcastro: Yeah, I was talking to him about it last night. He's just wrapping up a few logistics IIRC
[17:04] <jcastro> marcoceppi: awesome
[17:05] <jcastro> marcoceppi: that's 2 for him, we should get him reviewing soon
[17:05] <jcastro> I fear we will kill m_3 otherwise
[17:06]  * marcoceppi should help review charms more too
[17:06] <jcastro> I saw a guy file a bug on cherokee webserver today
[17:06] <jcastro> let's hope he's working on it. :)
[17:16]  * SpamapS will review some stuff soon too. :)
[17:16] <SpamapS> jcastro: cherokee + ?
[17:16] <jcastro> it's a webserver
[17:16] <SpamapS> webservers are not really charmable ;)
[17:17] <SpamapS> They're as charmable as "python"
[17:17] <SpamapS> like Johnny 5, they neeeeeeed iiinnnpuuuuuutt
[17:17] <jcastro> well then, we'll see what he comes up with
[17:18] <jcastro> SpamapS: you need to explain the difference between that and things like ntp to me
[17:18] <jcastro> but we can do that over voice later.
[17:18] <jcastro> ie. how come ntp is charmable but not a web server
[17:20] <SpamapS> NTP takes input from the system clock, other NTP sources, etc.
[17:20] <SpamapS> same w/ MySQL.. it takes input from mysql clients
[17:20] <SpamapS> so maybe cherokee + ftp for static hosting.. that would be a cool charm.
[17:21] <SpamapS> but whats more compelling is like, cherokee + php-fcgid for a cherokee PHP framework charm
[17:23] <jcastro> SpamapS: nod
[17:23] <jcastro> SpamapS: is your talk scheduled? I'd like to announce our presence at scale on cloud.u.c
[17:23] <m_3> SpamapS: man... that's a blast from the past
[17:24] <SpamapS> jcastro: schedule seems to not be public yet.
[17:24] <jcastro> ok
[17:24] <SpamapS> m_3: cherokee?
[17:24] <m_3> Johnny 5
[17:25] <SpamapS> OH haha
[17:25] <SpamapS> Steeeeeeeefaaaanniieeeee
[17:26] <m_3> haven't reported lxc bug yet... haven't taken the time to root it out enough for a decent bug report
[17:26] <m_3> wasn't it like "no 5 is alive!"
[17:26] <m_3> title?
[17:41] <mpl> niemeyer: ok, I have to ask now. what's wrong with using the standard log package for what you want me to do?
[17:42] <niemeyer> mpl: What we discussed actually depends on the standard logging package
[17:42] <niemeyer> mpl: It's just accommodating its usage
[17:43] <hazmat> jcastro, i'd add kafka to the list
[17:43] <hazmat> the hot and hairy
[17:44] <jcastro> hazmat: apache kafka?
[17:44] <hazmat> jcastro, yup
[17:44] <jcastro> on it
[17:49] <mpl> niemeyer: at the moment there's no output/printing afaics in the juju package. so I have the log.go file ready, but none of its funcs are used. should I add some test func (in config_test.go for example) which uses those log functions?
[17:49] <m_3> negronjl: jeez, I'm still testing mongo... the test-stack I was using yesterday had bugs and I chased down that rabbit-hole all afternoon
[17:50] <niemeyer> mpl: Sounds good
[17:50] <niemeyer> mpl: You can actually create log_test.go, though
[17:50] <niemeyer> mpl: Since that's unrelated to config
[17:50] <mpl> indeed
[17:52] <mpl> niemeyer: I'm thinking instead of only one prefix ("JUJU "), there could be another one specifically for debug funcs (like "JUJU:DEBUG "). what do you think?
[17:53] <niemeyer> mpl: Sounds like a good idea
[18:00] <rog> niemeyer: how're you feeling about go-juju-initial-ec2?
[18:10] <niemeyer> rog: I'm feeling bad, because I haven't sent you a review yet
[18:10] <niemeyer> rog: But bear with me, you'll have something today
[18:11] <rog> niemeyer: i'm feeling a bit like i'm on the end of a bendy branch, as i keep making modifications on a stack of 3 merge requests :-)
[18:11] <rog> niemeyer: am happy about that
[18:11] <niemeyer> rog: Yeah, it's time to go back to the bottom of the stack
[18:12] <rog> hopefully some of what i've done in the meantime will still be valid
[18:12] <niemeyer> rog: I have the interview done, am organizing a project plan for something entirely unrelated that I was asked about, and will then dig onto it
[18:12] <rog> cool. i'll be finishing for the day in about 40 mins.
[18:12] <niemeyer> rog: I'm optimistic too
[18:12] <niemeyer> rog: Cool
[18:13] <niemeyer> rog: I'll should be in before that
[18:13] <niemeyer> rog: I should be in before that
[18:14] <rog> niemeyer: haven't quite got zookeeper running on an instance, but i have got AuthorizedKeys working properly, with tests.
[18:14] <niemeyer> rog: Sweet!
[18:28] <jcastro> m_3: I made a page for "gotchas" https://juju.ubuntu.com/CharmGuide
[18:29] <jcastro> if you want to expand the architecture bullet there
[18:39] <m_3> jcastro: cool
[18:48] <rog> niemeyer: i'm off for the day. looking forward to review in the morning, thanks in advance!
[18:48] <rog> see y'all tomorrow
[18:49] <niemeyer> rog: Enjoy your evening!
[18:50] <rog> niemeyer: will do, i can taste the beer already....
[18:56]  * SpamapS just uploaded charm-tools to precise
[18:59] <hazmat> bcsaller, jimbaker if one you have a moment, this branch could use a review.. lp:~fwereade/juju/unacquire-unlaunched-machine
[19:00] <jimbaker> hazmat, i will take a look at it
[19:12] <SpamapS> Failure: twisted.internet.defer.TimeoutError: <juju.control.tests.test_status.StatusTest testMethod=test_collect_filtering> (test_collect_filtering) still running at 5.0 secs
[19:12] <SpamapS> hazmat: didn't you say you had some fixes for that?
[19:13] <SpamapS> would like to get a more recent version of juju into precise for testing purposes
[19:14] <hazmat> SpamapS, i did, their on trunk
[19:14] <hazmat> SpamapS, as of last night
[19:20] <SpamapS> hazmat: ahh, this was 420 .. we need 423 :)
[19:20] <hazmat> SpamapS, latest is 423, fixes are in 421
[19:20]  * marcoceppi obligatory 420 joke
[19:20] <hazmat> word
[19:21]  * SpamapS giggles
[19:22] <SpamapS> darn, builders are busy.. 2 hours till they are tried
[19:29] <jcastro> SpamapS: awesome, while you wait you can review this:
[19:29] <jcastro> https://bugs.launchpad.net/charm/+bug/897746
[19:29] <_mup_> Bug #897746: Charm needed: Status.net <new-charm> <juju Charms Collection:New for george-edison55> < https://launchpad.net/bugs/897746 >
[19:33]  * SpamapS reviews
[19:35] <jcastro> SpamapS: ok so in this case
[19:35] <jcastro> I was messing with it, and I got it wrong
[19:35] <jcastro> and the author was like "it _needs_ these three config options set or it doesn't work".
[19:36] <jcastro> have we thought about a way of returning what config options are required for a service to work?
[19:36] <SpamapS> I suggested that optiosn w/o a default in config.yaml should prevent deploy without being set, but there was resistance to that.
[19:36] <SpamapS> options even
[19:37] <SpamapS> Its ok though
[19:37] <SpamapS> deploy it.. thats fine. Don't open-port until you have all the config options.
[19:37] <jcastro> i wasn't thinking so black and white
[19:37] <jcastro> something like "W: this charm needs foo,bar, and baz set, see README" or somesuch
[19:38] <jcastro> and that totally gives me an out, I read the things I need, pass "juju set foo" and then keep going
[19:39] <marcoceppi> What's a case for blank config option that isn't a required?
[19:39] <SpamapS> Yeah maybe a message about there being no defaults for those things.
[19:39] <jcastro> I think it's fine if juju just keeps going and let's me deploy
[19:39] <SpamapS>     description: The email address of the administrator (cannot be changed)
[19:40] <SpamapS> that kind of sucks. ;)
[19:41] <jcastro> heh
[19:41] <jcastro> anyone know where "juju get" is documented?
[19:41] <jcastro> I only just discovered it now. :(
[19:42] <marcoceppi> SpamapS: not much of a configuration option, is it :)
[19:42]  * SpamapS was supposed to write an argparse -> manpage generator at one point
[19:42] <jcastro> SpamapS: what we need is debconf for charms
[19:42]  * jcastro runs away quickly
[19:43] <SpamapS> BTW, we need to change file_get to sha256
[19:43] <SpamapS> md5sum *sucks*
[19:44] <SpamapS> jcastro: or an upstart for the cloud? ;)
[19:44] <jcastro> might as well fix that now
[19:46] <hazmat> jcastro, juju get --help
[19:46] <marcoceppi> SpamapS: which file get?
[19:46] <jcastro> hazmat: any idea why that isn't exported out to juju.u.c/docs?
[19:47] <jcastro> or is it supposed to be?
[19:47] <hazmat> its not
[19:47] <hazmat> their inline docs to the impl
[19:47] <hazmat> we don't assume the location of the docs from the code
[19:47]  * jcastro nods
[19:48] <hazmat> hmm those get/set both need some formatting help
[19:50] <jcastro> and a man page to point to all the subcommand thingies
[19:50] <jcastro> I did honestly try to look for it in a man page and the online docs. :)
[19:51] <SpamapS> marcoceppi: btw, using a URL for the md5sum is not adequate in ch_get_file
[19:51] <marcoceppi> SpamapS: Why not?
[19:51] <SpamapS> marcoceppi: unless it is retrieved over HTTPS and wget is set to verify certs
[19:52] <marcoceppi> ohhh, duh
[19:52] <SpamapS> marcoceppi: same problem as the tarball.. MITM. :)
[19:52] <marcoceppi> Just when I thought I had it all figured out
[19:52] <SpamapS> its ok
[19:52] <SpamapS> I heard one guy figured it all out, and then he turned into a real dick.
[19:52] <marcoceppi> I'll force a check for https with remote hashes then :)
[19:52]  * SpamapS has luckily drunk enough alcohol to forget some, so not as much of a dick anymore
[19:53] <SpamapS> no you don't have to force that
[19:53] <SpamapS> just make sure wget verifies certs, and that we have the ca certs installed
[19:53] <marcoceppi> But if it's not over https, the whole functions point is nullified
[19:54] <SpamapS> pick that up on review
[19:54] <SpamapS> if people want to use it in a stupid way, let 'em. ;)
[19:54] <SpamapS> "enough rope to hang yourself, and then a little more"
[19:54] <marcoceppi> so, just plug along merrily if someone uses http:// ?
[19:54] <marcoceppi> but push a warning out with juju-log :)
[19:55] <SpamapS> a warning is a good idea yeah
[19:58]  * marcoceppi doh=100; while [ doh > 0 ]; do juju-log "You should have had a V8, and used https"; doh=$((doh-1)); done
[19:58] <hazmat> bcsaller, jimbaker.. trivial re fix cli help formatting
[19:58] <hazmat> http://paste.ubuntu.com/755300/
[19:59] <jimbaker> hazmat, taking a look
[19:59] <bcsaller> hazmat: just hooking the formatter used in other clis to commands where its missing
[19:59] <bcsaller> hazmat: looks fine to me
[19:59] <hazmat> cool, its a very trivial
[19:59] <hazmat> makes the output significantly better though
[19:59] <bcsaller> nice
[19:59] <SpamapS> marcoceppi: another cool feature of ch_get_file would be to cache it so you don't have to re-download the next time install is run.
[20:00] <SpamapS> marcoceppi: actually you can probably just do a conditional get based on file mod time
[20:00] <SpamapS> wtf? wget doesn't support automatic If-Modified-Since? that seems silly
[20:00] <jcastro> surely curl does?
[20:00] <jimbaker> ok, well i'm getting a mod_python error on the plain diff because i wanted to try it out (http://paste.ubuntu.com/openid/login/?next=/755300/plain/), but looks fine to me
[20:01] <SpamapS> jcastro: only an explicit date.. can't just give it a file
[20:02] <marcoceppi> lame
[20:02] <jimbaker> speaking of curl, i thought for bug 814974, it might be nice if the url being specified could also specify options for curl
[20:02] <_mup_> Bug #814974: config options need a "file" type <juju:Triaged by jimbaker> < https://launchpad.net/bugs/814974 >
[20:03] <jimbaker> so use curl to retrieve the desired doc, but also capture how it was retrieved
[20:04] <_mup_> juju/trunk r424 committed by kapil.thangavelu@canonical.com
[20:04] <_mup_> [trivial] fix cli long help formatting [r=bcsaller,jimbaker]
[20:05] <hazmat> niemeyer, did you have time to talk today?
[20:06] <SpamapS> jcastro: status.net reviewed.. minor problems that have to be fixed.. should be very easy. :)
[20:06] <niemeyer> hazmat: We can do that now if you want
[20:07] <SpamapS> jimbaker: hm. Interesting idea.
[20:08] <hazmat> niemeyer, invites out
[20:08] <jimbaker> raw tweak on help is definitely nice
[20:09] <jimbaker> SpamapS, using juju get, you would be able to retrieve this spec. config-get would of course retrieve the file uploaded as a consequence of juju set
[20:10] <SpamapS> jimbaker: metadata.. the bane of POSIX filesystems since the dawn of time. ;)
[20:10] <jimbaker> SpamapS, :)
[20:11] <jcastro> SpamapS: awesome, I'll poke him to check it out. When the time comes don't forget to ping me when you promulgate or whatever we call that now so I can blog about him
[20:12] <SpamapS> jcastro: ROCK THE BELLS
[20:12] <jimbaker> just to be clear, what config-get would retrieve would be a url pointing to a copy of that uploaded file now being stored in the env
[20:13] <jimbaker> eg in the s3 control bucket
[20:13] <SpamapS> jimbaker: right
[20:17] <negronjl> m_3: no worries about mongo .... no rush
[20:18] <SpamapS> are there any open source apps out there that make use of mongo?
[20:23] <jcastro> SpamapS: George Edison is a pseudoname
[20:23] <jcastro> SpamapS: nice to know you're checking copyright though!
[20:24] <SpamapS> hah
[20:25] <SpamapS> you people who turn your nose up at copyrights just don't appreciate how much being dicks about copyrights has helped Debian's longevity. :)
[20:26] <jcastro> I wasn't making fun of you, just noting your attention to detail
[20:27] <SpamapS> Oh I don't take it personally.. I just think its funny that you guys are like "meh copyright, meh, license"
[20:28] <SpamapS> Something wired weird in me thinks its cool. :-P
[20:29] <SpamapS> marcoceppi: I love you man, but your email client sucks. kthxbai ;)
[20:29] <SpamapS> X-Mailer: Palm webOS
[20:30] <jcastro> marcoceppi: hey, not bad, only like 4 weeks from your first charm to someone making fun of your MUA. That's an impressive achievement.
[20:30] <SpamapS> seriously.. take a bow
[20:35] <marcoceppi> ಠ_ಠ
[20:36]  * marcoceppi bows
[20:47] <jcastro> SpamapS: charm updated.
[20:47] <jcastro> SpamapS: sorry to be so painful about it, I just am aching to blog this one
[20:58] <obuisson> hi all
[21:02] <jcastro> SpamapS: line 14: /usr/share/charm-helpers/sh/net.sh: No such file or directory
[21:03] <jcastro> SpamapS: ok so basically this means we'll need to install the charm helpers right?
[21:07] <m_3> obuisson: welcome
[21:12] <marcoceppi> jcastro: you'll have to install charm-tools
[21:12] <marcoceppi> as that provides charm-helpers
[21:13] <jcastro> @marcoceppi you mean the charm has to right?
[21:13] <marcoceppi> jcastro: Correct
[21:14] <jcastro> so the first best practice is to install the charm tools so you can use the other best practices, heh
[21:14]  * marcoceppi verifies
[21:14] <jcastro> but then I have to enable the juju PPA on every instance
[21:15] <marcoceppi> jcastro: not sure, checking if it's enabled by default
[21:17]  * marcoceppi assumes the repo is added, waits for EC2
[21:21] <marcoceppi> jcastro: Yeah, it's in there. Just need to do an apt-get install charm-tools
[21:21] <marcoceppi> oh, actually, just need do install charm-helper-sh
[21:31] <marcoceppi> SpamapS: Could you make wget a required dependency for charm-helpers-sh ? since it uses wget and it appears to not be installed by default
[21:36] <m_3> marcoceppi: looks like it's in there: http://bazaar.launchpad.net/~charmers/charm-tools/packaging/view/head:/debian/control
[21:36] <m_3> but I don't know for sure... still learning about packaging stuff
[21:37] <marcoceppi> m_3: Awesome, I was wondering how the magic of packaging worked. I thought SpamapS  was just doing it by hand
[21:37] <marcoceppi> Oh, looks like it already has the right dependencies too
[21:38] <m_3> marcoceppi: it's all juju (orig sense of the word)
[21:38] <m_3> that might not be what's made it to the package archives yet though...
[21:39]  * m_3 checking version
[21:40] <m_3> apt-cache show charm-helper-sh shows 0.2+bzr85-4~oneiric1, but lp's at 86
[21:41] <m_3> dunno how to update it tho
[21:41] <niemeyer> And I hear it's Squash'o'clock
[21:41] <niemeyer> Laters
[21:41] <m_3> 0/
[21:42] <marcoceppi> m_3: looking at debian/changelog revision 86 is package version 85
[21:42] <marcoceppi> so it's up to date
[21:42] <marcoceppi> http://bazaar.launchpad.net/~charmers/charm-tools/packaging/revision/86/debian/changelog
[21:43] <m_3> gotcha... cool
[21:45] <m_3> negronjl: we could probably remove hostname from the mongodb and mongodb-replica-set
[21:46] <m_3> negronjl: it's finally up with a client that uses the replicaset (hopefully properly)... no problems yet
[21:46] <m_3> just twiddling with variations atm
[21:47] <m_3> (remove hostname from the _interfaces_ that is)
[21:48]  * negronjl crosses fingers 
[21:48] <negronjl> m_3: when you break it ( 'cause I know you will ), let me know how so i can see about fixing it :)
[21:49] <negronjl> m_3: the implementation is not too robust
[21:51]  * SpamapS returns from lunch
[21:51] <SpamapS> Package: charm-helper-sh
[21:51] <SpamapS> Architecture: all
[21:51] <SpamapS> Depends: wget, bind9-host, ${misc:Depends}
[21:51] <SpamapS> marcoceppi: charm-helper-sh does depend on wget
[21:52] <marcoceppi> SpamapS: Yeah, I just saw that. I didn't realize it was already awesomfied
[21:52] <SpamapS> marcoceppi: we should make it also depend on ca-certificates tho
[21:52] <marcoceppi> truth
[21:52]  * SpamapS updates the packaging
[21:53]  * jcastro EODs in a few.
[21:54] <jcastro> SpamapS: m_3 thanks for the reviews today chaps, good progress made today
[21:58] <SpamapS> jcastro: more fixes needed
[22:00] <jcastro> SpamapS: true
[22:00] <jcastro> I've been mulling a "you know what, we need to slow down and have a day where we clean up our existing ones."
[22:00] <jcastro> but I haven't thought it through enough yet.
[22:02] <SpamapS> commented
[22:02] <SpamapS> Is George not able to IRC?
[22:08] <_mup_> juju/scp-command r418 committed by jim.baker@canonical.com
[22:08] <_mup_> Merged trunk
[22:09] <m_3> jcastro: we have been gradually cleaning up existing ones... taking more than a day tho :)
[22:10] <jcastro> m_3: yeah I just don't want to get in the habit of fast fooding charms when we can take the extra minute to sort out the charm-tool or whatever will make the next charms easier.
[22:11] <m_3> jcastro: agree 10%
[22:11] <m_3> er
[22:11] <m_3> 100%
[22:11] <m_3> :)
[22:12] <m_3> just budget more than a day
[22:12] <m_3> otherwise people'll make charm changes without really testing the changes
[22:15] <SpamapS> sorry what?
[22:15] <SpamapS> I don't follow.. budget more than a day for making a charm?
[22:15] <SpamapS> Or for pulling common stuff into charm-helper?
[22:22] <jcastro> SpamapS: so like, at one point we say "ok we have X new charms, freeze is Y weeks away, let's chill on the new charms for a bit and do some review and tooling"
[22:23] <jcastro> so maybe removing custom bits with things that the charm tools offer as a convenience feature
[22:24] <SpamapS> Hrm..
[22:24] <SpamapS> I'd think stuff like that is really early cycle, likely to break type change
[22:25] <SpamapS> Typically you build up debt as you approach release.. then you pay it back when you can take time to deal with the fallout.
[22:25] <SpamapS> having 5 ways to wget+md5sum is just tech debt
[22:26] <SpamapS> and converting them to use CH is paying that back.
[22:26] <SpamapS> jcastro: but I see what you're getting at.. and would agree that there needs to be *some* period of such change.
[22:27] <jcastro> SpamapS: hey man, it's not even december yet, let it wild west for another month I say
[22:27] <jcastro> :)
[22:27] <SpamapS> I'm trying to decide when to switch from oneiric to precise even.
[22:27] <SpamapS> Feels like we should just auto-backport all new charms to all old releases, and fix them as problems are found.
[22:28] <SpamapS> But.. nah.. we'll just let people bzr push their charm into the old release if they think its appropriate.
[22:29] <SpamapS> release day is just when dev focus changes to the new dev release of Ubuntu
[22:47] <m_3> SpamapS: all I was saying is that it takes more than a day to refactor and/or clean up all the charms we already have
[22:49] <m_3> SpamapS: BTW, is it possible to 'crossbuild' for different releases?  i.e., build a package for natty on an oneiric instance?
[22:49] <m_3> I've been only trying to build natty on natty, oneiric on oneiric
[22:50]  * m_3 mess of VMs lying around
[22:50] <SpamapS> m_3: yes thats what pbuilder and sbuild do :)
[22:50] <SpamapS> I don't use VMs.. I just have chroots for everything
[22:50] <SpamapS> m_3: install ubuntu-dev-tools and 'man mk-sbuild'
[22:50] <SpamapS> sbuild is "tha bomb"
[22:50] <m_3> ahh... yes, that'd be more lightweight <grin>
[22:52] <m_3> I thought 'bzr bd' was the bomb
[22:59] <SpamapS> m_3: bzr bd was the bomb, but now its just a tool.. sbuild is *BLOWIN UP*
[22:59]  * SpamapS gets freakizzle in the hizzle
[23:00] <SpamapS> m_3: and agreed, it will take a long time to refactor all of them. What we should do instead is just identify an issue when we see it, and file a bug.. and any time we're fixing one bug in a charm, make sure to fix any of these other lingering issues.