[13:22] <Odd_Bloke> smoser: When do/should cloud-init bugs get marked as Fix Released in the cloud-init LP project?
[13:23] <smoser> Odd_Bloke, i do it with release of the bug in a version.
[13:23] <smoser> ie, when 0.7.6 releases all those go to fix-released.
[13:23] <smoser> and ubuntu fix-released when ubuntu gets fixed.
[13:24] <Odd_Bloke> smoser: Cool, so I don't need to pay attention and do the marking myself when appropriate?
[13:24] <smoser> well, it wouldn't hurt :)
[13:24] <smoser> its a pain
[15:17] <Odd_Bloke> smoser: What are your thoughts on https://bugs.launchpad.net/cloud-init/+bug/1403617 ?
[15:18] <Odd_Bloke> smoser: My comment lays out the decision we need to make.
[15:21] <smoser> how do we not match with roject level keys now ?
[15:22] <smoser> Odd_Bloke, ie "we already don't match the GCE docs in the way we handle project-level keys so this may be a foolish consistency."
[15:23] <Odd_Bloke> smoser: I _think_ that we put all of the keys on the ubuntu user, even when they're defined against different users.
[15:23] <Odd_Bloke> smoser: But I may not be recalling that correctly.
[15:25] <smoser> how do they get defined for different users ?
[15:25] <smoser> we do put them on the ubuntu user for user.
[15:25] <smoser> sure
[15:28] <Odd_Bloke> smoser: Keys come from GCE as a list of "<user>:<key>" strings.
[15:28] <Odd_Bloke> smoser: Which GCE infers from the comment (e.g. "... dwatkins" will come as "dwatkins:...") in the user interface.
[15:29] <Odd_Bloke> But you just pass in a mapping to the instance creation API.
[15:30] <Odd_Bloke> smoser: We then trim the first half off before setting 'public-keys' in self.metadata (using the _trim_key function).
[15:30] <smoser> ah. i see.
[15:31] <smoser> i think you should override the per-project keys with per-instance if available.
[15:31] <Odd_Bloke> So if I defined {'dwatkins': 'ssh-rsa foo', 'smoser': 'ssh-rsa bar'}, we'd get both 'ssh-rsa foo' and 'ssh-rsa bar' on the ubuntu user.
[15:31] <Odd_Bloke> (And the Google scripts would create dwatkins and smoser users with the appropriate keys)
[15:31] <smoser> can we know the difference between "no instance keys given" and "instance keys given as empty string"
[15:31] <smoser> with the latter implying intent to have no ssh access
[15:32] <Odd_Bloke> I'll have a look; I _suspect_ not, but I'll confirm.
[15:35] <Odd_Bloke> Ah, we can; sshKeys is passed as a normal metadata attribute, and so if none are specified then the key isn't present.
[15:35] <Odd_Bloke> Let me confirm that the web UI behaves the same as the CLI client.
[15:37] <smoser> i'd just like to support that behavior
[15:38] <smoser> Odd_Bloke, so my general feeling here is that it makes sense to try to do what the cloud vendor wants.
[15:38] <smoser> however, i'm *more* interested in consistency of ubuntu across vendors
[15:38] <smoser> than i am in ubuntu's consistency with other vms on a given vendor
[15:38] <smoser> make sense?
[15:39] <smoser> i care more about ubuntu than i do GCE
[15:39] <Odd_Bloke> Yep, on the same page.
[15:40] <Odd_Bloke> So you're saying you think that 'empty instance keys' is approximately equal to (e.g.) no key given when starting an EC2 instance?
[15:42] <smoser> Odd_Bloke, yeah.
[15:42] <smoser> i think so. right ?
[15:43] <smoser> that could be achieved easily ehought though, by creating a key named "NOONE@NOWHERE"
[15:44] <smoser> and promptly shredding the private key
[15:46] <Odd_Bloke> Yeah.
[15:46] <Odd_Bloke> Let me see what GCE does if I manually set an empty string through the API.