[00:04] well, checked my creds, vpc, subnet ids ... everything looks good, but I just can't deploy anything it seems [00:04] possibly I am hitting an aws quota I think [00:05] https://pastebin.com/QgZjHbyV [00:36] wallyworld_: http://paste.ubuntu.com/25531025/ [00:36] I tried to be as direct as possible [00:38] let me know if you can't grok whats going on, but basically I deploy ubuntu in each of the models at the end, showing the config of the models you can see the config is similar for both models, but I can't get anything to deploy in one of them.... and for that matter, for any new model I create ... as of like less than an hour ago [00:43] those 2 models were created with the same creds .... so strange that the same command completes in one but fails in the other [02:28] bdx: all those allocating machines - that means that either they have not been created by the cloud, or they have not been able to start the juju agent to phone home. you'd need to look at cloud and juju logs to dig in a bit [02:28] axw: thanks for reviews [02:28] wallyworld_: np [02:52] wallyworld_: bugger, sorry! [02:59] wallyworld_: Trying to run juju from a snap, I keep getting this: http://paste.ubuntu.com/25531660/ [03:00] The snap was installed with --classic. [03:00] wallyworld_: any ideas? [03:08] babbageclunk: nfi, haven't seen that before [03:08] veebers: looks like lnding is borked http://ci.jujucharms.com/blue/organizations/jenkins/github-merge-juju/detail/github-merge-juju/243/pipeline [03:18] wallyworld_: just needed to chown ~/snap - not sure how it ended up owned by root. [03:18] hmm [03:51] wallyworld_: I just re-ran it, lets see what happens [04:18] thumper: hey, should I be doing official builds on develop or 2.2? develop right? [04:37] babbageclunk: develop [04:37] thumper: thanks, that's what I'd guessed but figured I'd check early just in case I needed to move it. [04:37] * thumper nods === frankban|afk is now known as frankban [07:55] wallyworld_: are you free to review a little-ish PR? https://github.com/juju/juju/pull/7855 [07:55] there's more coming soon [08:54] axw: sure, just have to go get lachie from school, will do it as soon as i'm back [08:55] sorry i missed the ping before [08:55] wallyworld_: it can wait till tomorrow, I'll just put up the other PR rebased on top [08:55] ok, i'll look at both === salmankhan1 is now known as salmankhan === frankban is now known as frankban|afk === akhavr1 is now known as akhavr [23:13] It looks like I have added a potential bomb in the processing of bundle options... [23:13] only in the --bundle-config file, but it is there none the less [23:13] * thumper will fix... [23:14] oh no... [23:14] it's all good [23:14] phew [23:14] bundle config is processed before bundle.Verify [23:14] and bundle.Verify ensures the options are valid for the charm option types [23:14] yay [23:15] well fuck [23:15] * thumper is stunned [23:16] thumper: this really is an emotional rollercoaster [23:16] :) [23:16] https://github.com/juju/charm/blob/v6-unstable/config.go#L62 [23:16] this function returns a value and an error [23:16] but if it gets a type it doesn't understand, does it return an error? no it panics [23:16] FFS [23:17] why? [23:17] at least I haven't made it worse, [23:17] thumper: so the comments are lying "// returns an error if it cannot be parsed to the correct type." [23:18] yeah [23:18] comments lie [23:18] this code is all 4-6 years old [23:22] thumper: gross. [23:24] thumper: maybe the author decided to panic because of the defer option.error call? The wrapping it does doesn't make sense for an invalid type. (Not that that's a good reason.) [23:29] babbageclunk: you could format the error so it still makes sense... [23:29] geez [23:29] * thumper adds a bug [23:29] thumper: oh sure