[00:00] hazmat: Intel emerald ridge [00:01] hazmat: re the test failures.. what about the argparse bits? [00:01] SpamapS, haven't run into those yet [00:02] SpamapS, i manually installed the dep packages, checked out and ran tests [00:02] SpamapS, do you have another mechanism you'd recommend to reproduce [00:06] jimbaker, bcsaller can i get a +1 on this trivial.. http://paste.ubuntu.com/754300/ [00:07] that cleans up some of the tests to be more reliable [00:07] thanks folks just back and reading your points here [00:10] Spamaps, I open the cobbler web interface and check [00:13] hazmat: a checkout doesn't seem to show the behavior, only the installed version does [00:14] hazmat: its possible dh_python2 is broken or juju is doing something to confuse it [00:16] SpamapS, my .juju/environment.yaml is the same as the one in section 2. https://wiki.edubuntu.org/ServerTeam/OrchestraJuju [00:17] Spamaps, I also added: "default-series: oneiric" [00:19] SpamapS, I also made sure management classes has orchestra-juju-available selected. [00:20] SpamapS, I must have missed something else hey? [00:27] moozz: can you do a 'cobbler system show-variables -n name-of-system' and pastebin it? [00:28] moozz: you have to run that as root on the orchestra-provisioning-server [00:31] Spamaps, will do [00:32] SpamapS, to be honest I cannot remember [00:34] hazmat: you have to yield on watch_d twice in a row? [00:34] oh, bad read [00:34] 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] bcsaller, yeah... the exists_d wait, is just to be nice.. its not really needed [00:35] hazmat: yeah, +1 on the trivial [00:37] SpamapS, Should I run this instead perhaps: "sudo cobbler system dumpvars" [00:39] SpamapS, fixes committed, not sure about the argparse problem, i'll email barry about them [00:40] s/it [00:41] moozz: yes thats the one [00:41] moozz: sorry mixing 3 different things in my head ;) [00:43] SpamapS, No probs. Here is the output -> http://pastebin.com/XSfGYW1M [00:44] jimbaker, does 2to3 suggest xrange? [00:44] that seems odd [00:44] i thought that was gone in py3 [00:53] 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] SpamapS: It is midday here in AU not sure what time it is where u r, am I bothering u? [01:12] config-get is available outside of the config-changed hook, correct? [01:17] marcoceppi, yup [01:18] moozz: its 17:17 for me.. not bothering me at all but have a lot of stuff going on ;) [01:18] Right, that's what I figured. What about relation-get seems it can't be used outside of it's hook, correct? [01:18] 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] SpamapS: Says no suck option [01:20] SpamapS: will try with just host name [01:21] SpamapS: sudo cobbler system dumpvars oscs1 gives the same output as the previous pastebin [01:22] SpamapS: same with ip address [01:23] moozz: sudo cobbler system list [01:26] SpamapS: http://pastebin.com/x2R5YNFE [01:26] SpamapS: I have a host list. These are the hosts I eventually wish to build openstack on. [01:28] SpamapS: "sudo cobbler system dumpvars nova-compute" gives me the same error as in http://pastebin.com/XSfGYW1M [01:29] moozz: alright, I'm trying to get a test system up to follow along [01:29] moozz: --name nova-compute [01:30] SpamapS: Got output pastiing now [01:31] moozz: btw, you may want to apt-get install pastebinit [01:31] really helpful for this [01:31] cmd | pastebinit will put it into a pastebin for you :) [01:32] SpamapS: thanks. http://pastebin.com/Z0Ni59Hv [01:33] mgmt_classes : ['orchestra-juju-acquired'] [01:33] moozz: this means juju believe it has taken control of that system [01:33] moozz: are you certain juju bootstrap failed? [01:33] SpamapS yes [01:35] SpamapS: I wonder how we can check f sure? [01:36] moozz: juju status [01:36] SpamapS: cool trick with pastebinit [01:37] SpamapS [01:37] SpamapS: ERROR juju environment not found: is the environment bootstrapped? [01:40] moozz: ok, so change that mgmt class to orchestra-juju-available and try bootstrap again [01:40] moozz: maybe do juju -v bootstrap so you get verbose output [01:41] SpamapS: http://pastebin.com/TWwZLB0g [01:43] SpamapS: ok, I will list the env to check and out put to pastebin [01:44] moozz: did you try bootstrap again yet? [01:45] SpamapS is there a command line way to do this? [01:47] SpamapS: Tried this "sudo cobbler mgmtclass edit --name orchestra-juju-available" [01:48] moozz: no you'd want "sudo cobbler system edit --name nova-compute --mgmt-class 'orchestra-juju-available' [01:49] SpamapS: Yay! It worked. Should I make all other hosts available to? [01:50] SpamapS: Bummer, error actually: All available Cobbler systems were also marked as acquired (instances: MTMyMjUzMzEwOC42MjYwNDAxNjEuMjAwODk) [01:50] 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] moozz: hah, weird [01:51] SpamapS: very [01:51] moozz: dumpvars again, check the mgmtclass [01:51] ok [01:52] SpamapS: http://paste.ubuntu.com/754358/ [01:53] SpamapS: Seems set [01:54] 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] SpamapS: Any idea what this error means then? [01:56] moozz: on your system, you have both.. mgmt_classes : ['orchestra-juju-acquired', 'orchestra-juju-available'] [01:56] moozz: you need it to just have 'orchestra-juju-available' [01:58] 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] SpamapS: Sorry about the dumb question but what does the "...acquired" do? [01:59] moozz: available means "available for juju" , acquired means "taken by juju" [02:00] SpamapS: ok doing now? :-) [02:01] SpamapS: Done, now "'dict' object has no attribute 'read'" after typing juju bootstrap. :-) [02:02] moozz: *wha* ? [02:05] SpamapS: Seems now when I run "juju bootstrap" I get the error "'dict' object has no attribute 'read'" [02:05] moozz: I understand that. But maybe you could run it with '-v' and pastebin that? [02:07] SpamapS: ok [02:08] moozz: thats not a normal condition. :-/ [02:11] SpamapS: http://pastebin.com/nybeHuxY [02:12] moozz: interesting.. can you try 'sudo cobbler system edit --name=nova-compute --ks-meta=""' then bootstrap again? [02:13] moozz: I think there's an existing bug for this problem [02:14] SpamapS: cobbler: error: no such option: --ks-meta; You are trying to send an empty document, exiting [02:15] moozz: darn inconsistent cli.. change it to --ksmeta [02:17] SpamapS: SpamapS: Same [02:18] moozz: can you do a cobbler system dumpvars on it again and grep for 'ks_meta' ? [02:18] SpamapS: Note class is set to accuired [02:19] ok [02:19] moozz: acquired, but you're getting the dict/read bug? [02:20] Spamaps: http://paste.ubuntu.com/754379/ [02:21] ks_meta : tree=http://@@http_server@@/cblr/repo_mirror/oneiric-x86_64 [02:21] doesn't seem like it got fixed [02:21] SpamapS: I will try running the command again [02:21] moozz: the ks_meta should be *empty*, mgmt class should be ONLY orchestra-juju-available .. [02:23] SpamapS: tried to clear the ks_meta again but no luck [02:24] SpamapS: hmm :-P [02:24] moozz: --ksmeta="" works for me [02:24] :-) [02:25] SpamapS: can this be checked in the Web UI? [02:26] moozz: yourserver/cobbler_web should have a web UI on it [02:26] SpamapS: Just checked the UI and empty. ?? [02:27] SpamapS: No kickstart metadata there [02:28] Spamaps: Checking inhetit in the UI [02:29] moozz: and the mgmt classs? [02:30] SpamapS: mgmt classes empty [02:31] moozz: so.. put the available one in ;) [02:32] SpamapS: system: no ks_meta, should i remove <> from the oneiric-x8x_64-juju profile? [02:34] moozz: definitely not! [02:35] SpamapS: ok. Should the management classes have nothing set in them? as they do have nothing set [02:36] moozz: ... no.. they should have orchestra-juju-available [02:37] SpamapS: The class exists but has no packages or files specified [02:38] SpamapS: Sorry about all this [02:38] um, packages? what? [02:38] moozz: I think you may be confusing terms [02:39] moozz:under the system record in the web interface, sub menu "Management" the only thing that matters is "Management Classes" [02:39] SpamapS: under: configuration->Management Classes-> orchestra-juju-available->resources-> nothing is set [02:40] That doesn't mean anything [02:40] Configuration->Systems [02:40] thats where the magic happens [02:40] SpamapS: ok [02:41] SpamapS: Yes it is set [02:42] SpamapS: Wonder where the dict issue is comming from [02:43] dunno [02:43] but I have to go now [02:43] family is home [02:43] moozz: good luck.. maybe send to the mailing list if you get stuck [02:43] SpamapS: Many thanks and very sorry [02:50] SpamapS, cheers [04:14] Is there any limitation on the length of time a hook can run? [04:43] marcoceppi: no, but there's some thought that it would be a good idea [04:46] Okay, I've got an install hook that's going to take about...45 minutes [04:48] So, just FYI [04:49] marcoceppi: might it be better to put that in the background? [04:49] maybe, but how could I capture an install fail if it fails? [04:49] marcoceppi: what will it be doing for 45 min? [04:49] one word: cpan [04:51] Hopefully there's an easier way to get all these Perl modules [04:55] cpan? [04:56] its not packaged? [04:56] or rather.. [04:56] the stuff you need isn't packaged? [04:57] marcoceppi: debian has *really* good tools for turning cpan stuff into debs [04:58] Oh, maybe it is packaged I'm following instructions from the INTERNETS [04:58] marcoceppi: dh-make-perl in particular understands CPAN perfectly [05:25] marcoceppi: koha? [05:28] SpamapS Yeah actually [05:29] marcoceppi: saw your G+ post [05:29] marcoceppi: surprised that they use debian and suggest CPAN [05:34] 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] marcoceppi: perl can be like wonderland... ;) [06:33] hi all [06:35] the instance id i provide in my yaml file is required to have a user name "ubuntu" [06:36] i mean the instance ? [07:25] koolhead17: what instance? [07:26] koolhead17: do you mean the image id? [07:26] SpamapS: yes [07:26] am running Juju on openstack [07:26] *trying [07:27] koolhead17: the standard ubuntu 11.10 cloud images should work fine on openstack [07:27] SpamapS: am not using cloud image am using amd64 11.10 server image with my own customization as per my network requirement [07:28] ah so you're using the orchestra provider? [07:28] SpamapS: no [07:28] :) [07:28] well then I'm confused [07:29] why won't the cloud images work? [07:29] SpamapS: this is what i have done [07:29] 1. my own openstack infra is up and running [07:29] 2. over that i am trying to install juju and try/experiment with the charms [07:30] koolhead17: great, so, load the Ubuntu cloud images into glance, and you should be all set. [07:30] 3. since my nova and internal network both are behind proxy i need to mention that info in my /etc/apt/config [07:30] koolhead17: I don't think charms assume the ubuntu user.. but I do think juju might assume it for ssh purposes. [07:31] SpamapS: yes juju assumes, so i was wondering if i should remaster the image creating a user ubuntu [07:31] :) [07:31] koolhead17: well you can rebundle the Ubuntu cloud image with your changes. [07:32] SpamapS: cloud image has no username/passwd to i can log in with :( [07:32] smoser: suggested me another way, i will try to do that when am in office [07:32] SpamapS: cloud image log in is keybased [07:34] that is why i was using the amd64 image instead cloud image :( [07:36] koolhead17: juju expects keys too [07:37] SpamapS: i think metadata server/nova does that 4 juju [07:38] SpamapS: let me ping you in say 1 hr once am there :) [07:40] koolhead17: will be asleep by then [07:40] about to sign off [07:40] koolhead17: sorry... good luck tho.. :) [07:43] SpamapS: np. will keep you posted. :D [09:43] <_mup_> Bug #898082 was filed: immediate agent restart fails < https://launchpad.net/bugs/898082 > [11:58] Hello jujuers! [11:59] hello niemeyer :) [12:13] niemeyer: mornin'! [12:34] koolhead11, rog: What's up for the day? [12:35] 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] rog: Woohay! [12:35] rog: Mine is to unblock your ec2 branch :-) [12:35] niemeyer: oh please, please! [12:38] niemeyer: mind you, your reviews will probably skupper my forward progress at tip :-) [12:38] rog: Yeah, kind of expected.. sorry about that [12:39] niemeyer: that's fine, it will be great to remove the sword dangling over my head... [12:41] 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] hola rog :) [12:42] koolhead11: hi [12:42] rog: Absolutely [12:42] niemeyer: good [12:43] 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] niemeyer: that's what i thought. [12:43] 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] niemeyer: but it does mean that code is more complex initially than it would be for the functionality that currently exists [12:43] s/would be/needs to be/ [12:44] rog: Hmm, do you have some example? [12:45] koolhead11: I'm out of context.. all of those things work well in a standard Ubuntu image. What's going on there? [12:45] niemeyer: am using 11.10 server 64 bit image [12:46] and just added info of my proxy server in it /etc/apt/config [12:46] niemeyer: for instance, the cloudinit stuff talks about provisioners, but we don't have a provisioner yet [12:47] 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] rog: Can you paste a snippet just to make the idea more concrete? [12:47] 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] niemeyer: http://paste.ubuntu.com/754811/ [12:48] koolhead11: Yeah, for some reason it can't login into the ubuntu account [12:49] 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] niemeyer: the structure is somewhat different, but the code is pretty much exactly taken from the python [12:49] koolhead11: I recommend trying to login, by hand, onto the machine [12:49] koolhead11: ssh ubuntu@ [12:49] koolhead11: This should work [12:49] 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] niemeyer: its asking 4 passsword [12:51] niemeyer: but am not sure if ubuntu server iso has a user with name ubuntu :( [12:52] rog: I see your point. Haven't evaluated the code, but the structure looks fine. [12:53] niemeyer: good. [12:53] koolhead11: Yeah, it shouldn't ask for a password, because bootstrap sent your ssh key there [12:53] niemeyer: that file is the moral equivalent of providers/common/cloudinit.py, BTW [12:53] koolhead11: Which cloud-init should install in the system [12:53] koolhead11: In the Ubuntu user [12:54] niemeyer: 0.6.1-0ubuntu22 [12:54] koolhead11: ? [12:54] my custom image has no user ubuntu [12:54] niemeyer: my cloud init version [12:54] :p [12:55] koolhead11: You'll have to change your image so it behaves like the other cloud images. [12:55] niemeyer: and what all it will have apart from cloud-init, a user ubuntu ? [12:56] koolhead11: I apologize, but I have no way to tell how your custom image differs from a standard image [12:56] koolhead11: I'd use the standard images instead [12:56] niemeyer: okey. let me dig into it. Will keep you posted :D [12:57] koolhead11: Cool, sorry about that [12:57] np [12:58] 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] rog: I'm a bit surprised to see it there as well [13:01] 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] rog: How do you mean [13:02] rog: Ah, the comment [13:02] rog: The comment is bogus [13:03] rog: The name of the file is "authorized_keys", and it can contain more than one key concatenated to each other [13:03] niemeyer: not just that. depends whether append can take an item and/or a list. i can check. [13:03] rog: That's where the name comes from [13:03] niemeyer: it looks like authorized-keys is a key in the environment config file [13:04] niemeyer: which contains literal keys [13:04] rog: ~/.ssh/authorized_keys is the name of the ssh file [13:04] rog: Where that setting will end up in [13:04] niemeyer: but: [13:04] rog: The file accepts a concatenated list of keys [13:04] if config.get("authorized-keys"): [13:04] return config["authorized-keys"] [13:04] rog: Yes, that's fine? [13:05] isn't that getting a set of literal keys from the config file? [13:05] rog: This is getting a value from the config file [13:05] rog: That should contain the text to be inserted into ~/.ssh/authorized_keys [13:05] niemeyer: so authorized-keys contains only one string? [13:05] rog: Yes, the text to be inserted into ~/.ssh/authorized_keys [13:06] niemeyer: ok, that's cool then. i'm not familiar with all the ssh config stuff [13:07] rog: No worries [13:07] niemeyer: presumably all the heuristics in get_user_authorized_keys are standard, but it's all somewhat opaque to me [13:07] rog: I'll change the Python version to remove the bogus comment [13:09] niemeyer: hmm, in that case shouldn't it return the concatenation of all the keys in key_names? [13:10] hazmat: ping [13:10] lunch [13:11] rog: I don't know what you mean by that [13:11] niemeyer, pong [13:11] rog: Well, potentially, but the current is fine as well [13:11] hazmat: Quick cowboying: [13:12] * hazmat grabs a hat [13:12] hazmat: http://paste.ubuntu.com/754828/ [13:15] niemeyer, +1 [13:15] hazmat: Cheers [13:15] niemeyer, was the variable stuff causing a problem? [13:15] just unexpected? [13:16] 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] niemeyer, fair enough [13:17] i have to help out building a garage out back for a little bit, i'll be back in 40m [13:18] hazmat: Cool, see you soon [13:24] 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] rog: ^ [13:28] niemeyer: thanks [13:28] niemeyer: BTW is there a reason why authorized-keys-path isn't mentioned in environment/config.py ? [13:29] niemeyer: doesn't that mean it won't be allowed if someone does actually try to specify it? [13:29] rog: No, should be mentioned [13:30] niemeyer: and authorized-keys too, presumably [13:30] rog: as optional [13:30] rog: yeah [13:30] niemeyer: hmm, shows it's not much used :-) [13:30] rog: It does not mean that, though [13:30] rog: Not really.. this is used by _every single deployment_ [13:30] ah [13:31] so any key not mentioned in environment/config.py is actually allowed? [13:31] rog: KeyDict doesn't kill unknowns [13:31] niemeyer: ah, so unknowns just don't get any checking, but they still go in [13:32] rog: Right [13:32] damn, i was assuming that environment/config.py mentioned everything [13:32] i wonder what other keys are lurking around [13:33] niemeyer: just to check, both authorized-keys and authorized-keys-path should go in as String() ? [13:34] 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] 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] hazmat, well, I can see what's *happening*, but colour me surprised [13:37] f [13:37] odd, my irc client spontaneously froze and reconnected [13:38] * hazmat kicks xchat [13:38] hazmat, I can take a proper look at it soon if you like? [13:38] 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] 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] hazmat, I'll kick it around and see what I can come up with [13:43] fwereade, for context.. most of the conversation with 'moozz' is here http://irclogs.ubuntu.com/2011/11/30/%23juju.html [13:43] hazmat, I'm reading it, thanks :) [13:52] 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] 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] rog: Where's that? [13:53] in cloudinit/CloudConfig/cc_ssh.py [13:53] in the cloudinit source [13:54] niemeyer: line 98, in particular [13:57] 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] niemeyer: add_ssh_key in common/cloudinit.py should probably be add_ssh_keys otherwise too [14:01] rog: Looking [14:03] rog: Yeah, there's a minor mismatch in the Python code indeed [14:04] rog: It's not broken because it never reaches the point of actually dealing with the keys [14:04] niemeyer: i think get_user_authorized_keys should return a list [14:04] rog: Yeah, that sounds fine [14:04] rog: But it should not require a list from the user [14:05] rog: In the configuration/file, that is [14:05] niemeyer: it's slightly broken, i think, because add_ssh_key can be called with multiple keys in the same string [14:05] niemeyer: which will lead to the above mentioned mismatch in the final cloudinit code [14:05] rog: I mean it's not broken in the sense that it works [14:05] niemeyer: unless you're relying on disable_root, i guess [14:05] rog: Which we're not, so it works [14:06] niemeyer: yup [14:06] rog: You're right that it's logically incorrect [14:06] i wonder if authorized-keys-path should allow a set of names [14:06] rog: No [14:07] 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] niemeyer: ok. so should get_authorized_keys make sure to return at most one key? [14:08] er, no [14:08] rog: Yeah, it sounds like a good interface as far as Go is concerned [14:08] rog: (keys []string, err error) [14:08] yup. hmm, authorized-keys could accept a set of keys [14:09] rog: Well.. that said, it's trivial to test for list(keys) == 0 [14:09] rog: Hmmm.. but we need the error anyway, so +1 on (keys, err) [14:09] rog: and erroring if not keys are ofund [14:09] found [14:09] no [14:09] Erm [14:09] lol [14:09] rog: and erroring if no keys are ofund [14:09] Ok, I can't type.. I hope you get it :) [14:09] i do [14:10] niemeyer: i do wonder about authorized-keys though [14:10] rog: It's too late to wonder.. it already has a format, and we should follow it for the moment [14:10] niemeyer: presumably it will only allow one key currently (it'll probably produce a malormed cloudinit if you put in something else) [14:10] ok [14:10] it should really be authorized-key :-) [14:11] rog: Nope [14:11] rog: For the same reason that authorized_keys is keys.. it accepts multiple keys. [14:11] rog: We can handle a list internally consistently, while accepting the authorized_keys format in those options [14:11] 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] 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] thus http://paste.ubuntu.com/754923/ [14:31] rog: Sounds fine, except this function looks weird [14:31] and http://paste.ubuntu.com/754925/ [14:32] rog: This feels like over-engineering things a bit [14:32] niemeyer: it ends up simpler, i think [14:32] rog: get_user_authorized_keys is a single function, small, that does what we need [14:32] niemeyer: currently, get_user_authorized_keys relies on poking inside config [14:32] niemeyer: i was trying to avoid that [14:33] niemeyer: and in the process make a more generally useful function [14:33] niemeyer: but i'm open to different ideas [14:35] 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] rog: Well, or maybe not.. [14:37] rog: I guess the problem is mainly on the documentation [14:37] niemeyer: i think the only logic missing is this: http://paste.ubuntu.com/754934/ [14:37] which seems reasonable [14:37]