[00:34] davecheney: had a chance to look at those charm reviews of mine? anything I need to do to help with it? [00:35] bradm: i'm still waiting for someone to take my charm training wheels off [00:35] i can review but not commit [00:35] i will re ping everyone, about everything [00:35] davecheney: thanks [00:36] davecheney: I figure my 2 squid charm merges will be good ones, since they're so trivial - I can understand my moin merge taking a while, its a tad larger [03:00] hey wallyworld, have a good break? [03:01] axw: not bad :-) no internet for a week and a busted laptop so i've only got back online today. seems like there were some hiccups with the release [03:01] wallyworld: there were a few very last minute bugs [03:02] but mostly okay I think. [03:02] wallyworld: I'm doing a little bit of refactoring in environs/tools/simplestreams.go around WriteMetadata [03:02] ok [03:02] i'm addi8ng in support for signing [03:03] there's a bug in the null provider caused by a subtle bug in WriteMetadata [03:03] bug number? [03:03] if existing tools metadata has size/sha256, it gets ignored when doing sync [03:03] just a sec [03:03] #1235717 [03:03] https://bugs.launchpad.net/juju-core/1235717 [03:04] eh [03:04] that's not right [03:04] https://bugs.launchpad.net/juju-core/+bug/1235717 [03:04] <_mup_> Bug #1235717: null provider bootstrap fails with error about sftp scheme [03:06] i need to read the code to understand the cause/effect i think [03:06] wallyworld: what ends up happening is, WriteMetadata finds tools and metadata in the target; doesn't do any copies, but thinks it needs to fetch the tools to compute metadata again [03:07] wallyworld: there's a simple fix, but rogpeppe thought it might be a good idea to refactor this function as it's doing quite a lot more than writing metadata [03:07] and I agree after getting thoroughly confused last night [03:07] yeah, it's purpose has grown [03:37] "nova-cloud-controller/1:identity-service-relation-joined:1963941934992934910" [03:37] are relation id's sequential ? [05:08] axw: if you know the number you can just do bug #1235717 and mup will give the right URL [05:08] <_mup_> Bug #1235717: null provider bootstrap fails with error about sftp scheme [05:15] thanks jam [05:15] forgot the shortcut [05:15] I think it doesn't like #1235717 [05:15] <_mup_> Bug #1235717: null provider bootstrap fails with error about sftp scheme [05:15] ah, I guess it likes it just fine [05:15] bug 1235717 also works, IIRC [05:15] <_mup_> Bug #1235717: null provider bootstrap fails with error about sftp scheme [05:15] maybe because I had it on its own line in the chat [05:16] #1235717 [05:16] <_mup_> Bug #1235717: null provider bootstrap fails with error about sftp scheme [05:16] :/ [05:16] axw: Seems to work for me, maybe it was taking a nap [05:16] or mup just doesn't like me [05:16] try again? [05:16] #1235717 [05:16] <_mup_> Bug #1235717: null provider bootstrap fails with error about sftp scheme [05:16] * axw shrugs [05:16] axw: best guess, it was loading it and just slow, but I don't really know [05:20] wallyworld: is there any reason not to fetch tools from storage, as opposed to via its URL, when computing sha256/size? [05:20] wallyworld: sshstorage doesn't have real URLs :) [05:32] wallyworld: a very concerning bug is #1236446 I'm trying to sort it out, but upgrading 1.14 => 1.15 is broken right now. [05:32] <_mup_> Bug #1236446: Cannot upgrade-juju from 1.14.1 to 1.15.1 on openstack

[05:42] axw: the tools can be fetched from anywhere. i think the url may have been used because that's all that is known at that level of the code, not sure now [05:43] wallyworld: cool. it's possible to get from storage by using StorageName, just wanted to check if there was another reason [05:44] axw: so long as storage is accessible [05:44] wallyworld: well, this is in the code that writes the metadata to storage, so it has to be [05:45] ah ok. i see what you mean now [05:46] jam: i've not had internet access for a week, so am wading through the emails. the upgrade is still broken then. is it only on openstack? [05:47] wallyworld: it might just be a configuration/uploading tools to the right location issue. According to the bug from Curtis EC2 and Azure are working [05:48] ok, reading the bug now [05:48] wallyworld: the primary email I'm going off of is "1.15.1 release summary" direct from Curtis to canonical-juju sometime yesterday" [05:48] ok [05:49] jam: Ping. [05:49] jpds: pong [05:50] walla walla ding n [05:50] dong [05:50] foiled! [05:51] jam: So, how do I make work? [05:51] Err: https://bugs.launchpad.net/juju-core/+bug/1202163 [05:51] <_mup_> Bug #1202163: openstack provider should have config option to ignore invalid certs

[05:52] jpds: you should be able to set "ssl-hostname-verification: false" in your environments.yaml for a particular provider. Note it has only been implemented for Openstack at this point [05:52] I imagine MaaS is another important target [05:52] jam: Yep, doesn't work. [05:52] jpds: with what specific version of juju and what does it actually do ? [05:53] jpds: We don't actually have a service that uses self signed certs to check, so I was mostly going off of code auditing [05:53] jam: 1.15.1, bootstrap says: certificate is valid for CN, not machine-5.maas. [05:53] jpds: "jam: Note it has only been implemented for Openstack at this point [05:53] (9:52:29) jam: I imagine MaaS is another important target" [05:53] jam: This is Openstack, within MAAS. [05:53] machine-5.maas is just my swift-proxy. [05:54] jpds: can you run "juju bootstrap --debug" and paste the result somewhere? [05:57] jam: One moment. [05:57] jam: Meh, public pastebin is broken. [05:58] jam: https://pastebin.canonical.com/98639/ [05:58] ssl-hostname-verification":true [05:58] jpds: yep [05:58] I think I know the problem [05:58] I can see it's totally ignoring my setting. [05:58] 1.15.1 has 2 config files [05:58] ~/.juju/environments.yaml [05:59] and ~/.juju/environments/.jenv [05:59] once the latter exists, it ignores the former (IIRC) [05:59] rogpeppe: ^^ the first instance of someone getting confused by this situation (as I mentioned last week :) [05:59] I changed .juju/environments/openstack.jenv. [06:00] Still doesn't work. [06:03] jpds: same debug result (it is set to true?) the only things I can think of off hand are to paste your config and see if there are typos, etc. [06:06] jam: Set to false, same error: https://pastebin.canonical.com/98640/ [06:12] jpds: odd that it is https on 8080, but I'll dig a bit more [06:14] jpds: certainly having that set is a prerequisite for anything else working, so we are one step closer [06:16] jam: Object store: https://machine-5.cloud:8080/v1/AUTH_01fe93f0573849ffa6ed03d082f26c7c [06:22] jpds: sure, I'm not saying it is wrong, I was just surprised. "port 80 is http, 8080 is where people put private http usually, and this is ssl enabled". but regardless, I'm trying to understand which bit of code is trying to read from that [06:22] I have an idea [06:22] given it is saying "cannot find provider-state" [06:22] but I would still have thought that it would be using the disabled hostnames fetch [07:00] jpds, jam: in general, we *always* ignored environments.yaml, and we still ignore the .jenv file, whichjust contains a record of what you bootstrapped with [07:00] jam, jpds: you will never ever be able to doanything useful by changing local config for a bootstrapped enviuronment [07:00] fwereade: but bootstrap hasn't actually succeeded yet for ssl-hostname-verification: false [07:01] jam, ah sorry, I'm still reading through the past [07:01] fwereade: so while I understand your point, it doesn't apply here, because he hasn't succeeded yet [07:01] jam, that seemed important enough to mention straight off [07:03] fwereade: sure, and I can see where it may have been relevant, as we create .jenv during bootstrap, so if it had succeeded but was failing on the server side, we couldn't change attributes there. [07:03] fwereade: is there an obvious way for a client to change the env setting? I think "juju set" is for services, is there a "juju set-env" ? [07:03] ah yes [07:04] jam, there is indeed [07:04] wallyworld: one option for the "unable to upgrade" is that we add a "juju set-env tools-url: ..." as advice for people upgrading on HP [07:04] jam, but if we haven't bootstrapped that won't help [07:04] It is *far* from ideal, but if we can come up with a workaround, it isn't as critical of a problem [07:05] fwereade: right. I'm trying to understand why bootstrap at all isn't working, as I did do some client level testing (by moving /usr/share/certs) but I'll try it again for jpds [07:07] jam, jpds: that paste seems to show ssl-hostname-verification set to true [07:08] jam, jpds: so that bit may wellbe working properly, and we need to figure out why it's set to that in the first place [07:09] fwereade: ugh, renaming /usr/share/ca-certificates doesn't *do* anything, you have to tweak /etc/* and then run "update-certificates". [07:10] fwereade: the first paste had "true" the second had "false" after he fixed the .jenv [07:10] fwereade: but *my* testing of it wasn't actually correct, because there is a cache of what actual certs are valid [07:13] ffs, I can't get certs to stop being trusted :( [07:13] "Updating certificates in /etc/ssl/certs... 0 added, 150 removed; done." [07:14] but 'wget' still happily dovnloads from an https: location [07:14] jam, gaah, bad luck [07:14] jam, and, I see, sorry poor reading comprehension [07:15] ugh.... UbuntuOne forces an extra Go_Daddy cert into the system so that U1 works, which is, of course, the cert that I want to use for Canonistack testing [07:16] jam, ouch [07:17] fwereade: but I can brute force it. mv /etc/ssl/certs{,.hidden} [07:17] works [07:17] I get an invalid cert trying to wget from canonistack === _mup__ is now known as _mup_ [07:19] well, now it fails because it has 0 root certs, but *maybe* it won't care as long as you have SkipInsecureVerify [07:21] fwereade: The second paste shows it set to false. [07:21] jpds, yeah, I seem to have reading problems, it's probably best to ignore everything I say first thing in the morning [07:28] Guys, I can't even use the local provideR: [07:28] 2013-10-08 07:28:25 ERROR juju supercommand.go:282 Get http://10.0.3.1:8040/provider-state: dial tcp 10.0.3.1:8040: connection refused [07:29] All I did was: sudo apt-get install juju-core lxc mongodb-server on a 13.04 machine. [07:29] With ppa:juju/devel. [07:29] jpds: you should be able to "apt-get install juju-local" which has the right dependencies [07:29] though maybe we don't have juju-local in the devel ppa [07:30] E: Unable to locate package juju-local === axw_ is now known as axw [07:34] fwereade: interesting bug wrt ~/.juju/environments/*. It would seem that "juju destroy-environment" deletes the file there [07:34] is that intentional? [07:34] jam, absolutely [07:34] Right, so looks like I have the dependencies, devel is just borked. [07:34] jam, unintended consequence? [07:34] fwereade: given that tweaks have to be done in that file [07:34] and then you nuke it [07:34] was a bit surprising [07:35] I was abusing the 2-layer so that I didn't have to upset my environments.yaml [07:35] anyway [07:35] jam, I don't quite get why it needed to be tweaked, to be fair -- shouldn't it have just been trashed in the first place? [07:36] fwereade: if you bootstrap with ssl-hostname-verification: true, it tries to do the bootstrap, it prepares, but can't launch an instance [07:36] so you then tweak the file [07:36] and can bootstrap again [07:36] but then destroy-env [07:36] jam, it's fair enough to do so if bootstrap didn't work, I guess [07:36] and then bootstrap [07:36] doesn't work [07:36] and if you *just* tweak ~/.juju/environments.yaml [07:36] then just "bootstrap" doesn't work [07:36] because the .jenv is still around [07:37] jam, I'd prefer in general to destroy-environment before continuing if bootstrap goes weird [07:37] jpds: so I can't reproduce what you are seeing here. If I nuke my certificates correctly, but set ssl-hostname-verification: false it succeeds in bootstrapping a canonistack instance. [07:37] I'll try one more thing [07:42] fwereade: so "juju destroy-environment" can't delete the env file because it fails to connect to the server... [07:42] jam, aw hell [07:42] rogpeppe, ^ [07:43] fwereade: so in this case, if you have a self-signed service, you try to "juju bootstrap" it fails because of ssl-hostname-verification, you should then edit *both* files to fix it, so that you can destroy and then bootstrap again later [07:44] morning [07:44] TheMue, heyhey [07:44] morning TheMue [07:45] fwereade: I have to go sign paperwork for house-stuff in about 1 hour. I may or may not make it back to the standup. What I'd *like* to do for code-review this week is to do a 5-why's on what's going on with the release. Does that sound reasonable to you ? [07:45] jam, yes, that sounds very sensible [07:45] jpds: so. I can get a bootstrapped environment using the tools from ppa:juju/devel after nuking my certs and setting the right settings in config [07:45] jam, better than focusing on any specific minutiae [07:46] fwereade: k, if I don't make it to the standup, can you let people know? [07:46] jpds: the keys seem to be: delete ~/.juju/environment/ENV.yaml, set ssl-hostname-verification: false in ~/.juju/environments.yaml [07:47] then, for me, juju bootstrap -e canonistack --debug is able to properly connect to everything. [07:47] jpds: my initial thought is that stuff might be hosed if you had something bootstrapped before, and you are trying to connect to something that should already be running but isn't [07:47] especially for local provider, I believe we changed how the environment storage worked [07:48] axw: ^^ can you confirm? [07:48] fwereade: maybe you know. Should "juju-1.14 bootstrap -e local" and then "juju-1.15 status" work? [07:48] I don't know if it does or not (I haven't tested it) [07:48] jam: it should work as before [07:49] jam, I think it should work [07:49] axw: (11:28:49) jpds: Guys, I can't even use the local provideR: [07:49] (11:28:51) jpds: 2013-10-08 07:28:25 ERROR juju supercommand.go:282 Get http://10.0.3.1:8040/provider-state: dial tcp 10.0.3.1:8040: connection refused [07:49] jam, assuming 1.15 has the right env set ofc ;p [07:49] ehh [07:49] fwereade: my question is if you're enviroment was 1.14 and then you try to do something with 1.15 [07:50] o [07:50] jam: Yeah, ppa:juju/stable works fine. [07:50] axw: I'm grasping here, but didn't we use disk storage for stuff, and then switch to http storage ? [07:51] jam: it was always http, it just got split [07:51] it used to http&disk in one [07:51] I'll try 1.14->1.15 in a sec [07:51] jpds: so stable should just be 1.14.1. which shouldn't work with self-signed certs. (but might be working for your local provider stuff) [07:52] jpds: but I did confirm that with ppa:juju/devel I was able to get up and running after nuking /etc/ssl/certs [07:52] which *didn't* work if i didn't set ssl-hostname-verification: false [07:52] jam: Nuking ssl/certs sounds fun. [07:53] But yeah, local works fine with stable, not devel. [07:54] jpds: well "mv /etc/ssl/certs /etc/ssl/certs.hidden" [07:54] not a full nuke :0 [07:54] I'll try that. [07:56] jam: I just bootstrapped with 1.14.1, status works (in my env) with trunk [07:57] axw: makes me wonder if "raring" is involved here [07:57] (13.04 machine) [07:57] jam: I'm on raring [07:59] jpds: so you shouldn't have to do anything with /etc/ssl/certs. I just did it because I don't have a Cloud with invalid certificates I can try to deploy to [07:59] jpds: I *think* the trick is to configure ~/.juju/environments.yaml with ssl-hostname-verification: false, then delete ~/.juju/environments/env.yaml and try to "juju bootstrap" [08:03] jam: uploading tools 1.14.1 for maas was awkward but I did it using the --dev option with the older client [08:03] jam: OK, now I have what looks like a swift error. [08:03] jam: seeing alot of polling of the MAAS API now - bug 1236734 [08:03] <_mup_> Bug #1236734: juju 1.15.1 polls maas API continually [08:06] jamespage: that appears to be cycling over all the nodes 1 at a time and then back around again ? [08:06] jam: I think so - it never stops [08:06] .12 is the bootstrap node [08:07] jamespage: well it hits 742b and then doesn't hit it again for about 6 requests [08:07] do you have 5-6 nodes in the env ? [08:07] jam: 6 physical servers and 8 lxc containers [08:08] jamespage: do you have any juju logs to correlate ? [08:09] jam: I can [08:09] jamespage: you may also need to do: juju set-env 'logging-config==DEBUG' [08:10] jam: pasted to the bug - but an obvious correlation [08:10] cannot get addresses for instance "/MAAS/api/1.0/nodes/node-0d121d8c-4527-11e2-ba10-2c768a4f56ac/": Requested array, got . [08:11] jamespage: those are provisioned (deployed to ) machines, right? not ones that are sitting idle? It does look like we're trying to set the addresses for the various machines but can't find the actual address [08:11] not sure the "Requested array" stuff is [08:11] jam: they are all provisioned - this was an upgrade to an existing environment [08:11] jamespage: can you do just a "wget" to /MAAS/api/1.0/nodes/?id=node-742baf7e-4527-11e2-9188-2c768a4f56ac&op=list and add the info there as well? [08:11] It may be that we were expecting to see a list of IP addresses [08:11] in a field and we can't find it now [08:12] and rogpeppe added a poll to find updates to addresses, though I thought it was polling 1/min not 1/s [08:12] mornin' all [08:12] rogpeppe: morning [08:12] morning rogpeppe [08:12] you ears must be burning :) [08:12] jam, TheMue: hiya [08:12] jam: that's probably why i got lost in the woods on my morning bike ride :-) [08:13] rogpeppe, jam: arrrrrgh does Addresses() actually work on maas? [08:13] jam: [08:13] curl "http://10.98.191.11/MAAS/api/1.0/nodes/?id=node-0d121d8c-4527-11e2-ba10-2c768a4f56ac&op=list" [08:13] Unrecognised signature: GET list [08:13] this is raring maas [08:13] fwereade: the implementation looked plausible, but i didn't try it live i'm afraid [08:13] jamespage: might be a POST, let me dig up my MaaS knowledge a bit [08:13] jam: its a GET in the apache log from juju as well [08:14] jamespage: k, I do see "When a machine has no address it will be bolled at ShortPoll == 1s until it does" [08:14] jam: it should probably back off after a while [08:15] * rogpeppe reads back through the log [08:15] jam: I suspect that is dependent on a newer maas maybe? [08:15] jam: in the WebUI I don't see any addresses associated with the servers [08:15] the error message is from gomaasapi in "failConversion(wantedType string, ob JSONObject)" [08:16] I'm not sure what API we are requesting yetd [08:16] http://paste.ubuntu.com/6208383/ [08:22] jamespage: mi.maasObject.GetMap()["ip_addresses"].GetArray() is expected to be the list of IP addresses for a machine... [08:22] jamespage: it appears to have been added in MaaS rev 1521 [08:22] jam: so this is a backwards compat issue? [08:22] "raphael badin: Add API method to fetch the IP addresses attached to a node" [08:23] 1461 is in raring [08:23] so, I see the same call to find IP Addresses in 1.14.1 [08:23] we just didn't poll it in the past [08:23] jam, fwereade: about destroy-environment: perhaps we should put a "bootstrapped" flag into the .jenv file; if there are bootstrap attributes in the file and that's not set, then juju destroy-environment could forgo trying to connect to the environment before deleting the file. [08:24] mgz: MaaS IPAddresses call is unreliable, and we seem to prefer it to DNSName (aka hostname) in the Addresses code [08:24] jamespage: so it looks like 1.14.1 *could* have looked for the "IP Addresses" field, but generally preferred the "hostname" field [08:24] rogpeppe, I think I'd prefer an omitempty NotBootstrapped than to have that cluttering up the file [08:24] 1.15.1 is now expecting the ip_addresses field [08:24] which apparently doesn't exist in raring [08:25] rogpeppe: it is a bit of an edge case for "ssl-hostname-verify" so I don't want us to go overboard fixing it, but something we should think about [08:25] fwereade: that seems reasonable [08:25] we've run into other problems with bootstrap failing and then the system requires destroying an environment that doesn't exist [08:26] jam: in fact i'm having second thoughts [08:26] jam: if bootstrap fails, some of the environment still does exist [08:26] jam: or can do, at any rate [08:27] jam: because we might have local storage which needs deleting [08:27] jam: and in the future, destroying an environment will probably be done by connecting to the API and getting the environment to destroy itself [08:28] jamespage, mgz: so we need to sort out the ip_addresses stuff. I'm thinking maybe we try ip_addresses and if that request fails just fall back to hostname [08:28] * jam goes to sign some paperwork at the bank [08:29] fwereade: regarding this: https://codereview.appspot.com/14032043/diff/19001/juju/conn.go#newcode171 [08:29] axw, ah yes [08:29] fwereade: the only con I had was, NewConn takes an Environ as input; so the output Conn would have a different Environ [08:30] axw, the initial Environ is *only* good for connecting [08:30] yep [08:30] fwereade: just might be surprising, but I suppose it could only be positively surprising [08:30] axw, there may be a case to be made that *that* env should be SetConfiged, but that feels a bit hairier to me [08:32] fwereade: agreed [08:32] fwereade: so I'll update it to SetConfig on a new env which gets set on the Conn [08:33] axw, you should be able to just create a new env with the latest config and set that on the conn [08:33] axw, no call for SetConfig there, I think [08:33] fwereade: yes sorry, what you said [08:34] fwereade: I just meant, the Conn that comes out will have a different (up to date) Env, rather than the input one [08:34] axw, great, sgtm [08:35] fwereade, axw: presumably it'll mean we'll have to add a mutex to the conn [08:35] mgz, so, maas instance Addresses -- should it just log an error and move onif ipAddresses fails? [08:35] fwereade, axw: and hide its Environ [08:35] rogpeppe: why do you say that? [08:35] rogpeppe: this is happening in NewConn [08:35] axw: ah yes, sorry [08:36] axw: i hadn't appreciated that [09:04] fwereade, sorry but bug 1236754 is going to cause problems [09:04] <_mup_> Bug #1236754: behaviour change: relation-get for unset attribute returns "" in 1.15.1 [09:05] jamespage, oh, hell, thanks for spotting that -- critical for 1.16, I guess [09:09] dimitern, looking at the history, my best guess is that ^^ is a consequence of the api changeover -- does anything spring to mind for you? [09:16] fwereade, sound like the map[string]interface{} -> map[string]string transition [09:16] fwereade, what should happen for unset settings and relation-get? [09:16] dimitern, yeah, I think you're right, we're doing that `value, _ = settings[key]` thing [09:18] rogpeppe, remember that problem I had where the bootstrap node would not talk to nova correctly? [09:18] rogpeppe, I figured out what it was [09:19] network fragmentation [09:20] actually jam might be interested in that as well ^^ [09:20] it was due to the fact that the bootstrap node was accessing the API server from within a neutron hosted private tenant overlay network [09:21] and the MTU's where set to 1500 on the gateway node [09:21] which was causing fragmentation when the bootstrap node tried to access the API server [09:21] hanging instance creation [09:21] jamespage: interesting [09:21] I bumped the MTU on the physical server to resolve the issue [09:22] 1546 provides enought space for the instance to still operate at 1500 with the extra 46 bytes carrying the GRE overlay headers [09:22] rogpeppe, I feel I need to log that somewhere; [09:22] but not sure where [09:22] someone else is bound to hit it [09:22] mgz: ping [09:22] jamespage: does the neutron API use UDP or something? [09:23] rogpeppe, no its TCP [09:23] dimitern, except I can't actually figure it out how we could have got blank output with the json formatter in the first place [09:24] rogpeppe, its this issue - http://techbackground.blogspot.co.uk/2013/06/path-mtu-discovery-and-gre.html [09:25] fwereade, interesting point [09:25] jamespage: interesting; i didn't realise that MTU wasn't negotiated correctly [09:26] rogpeppe, althought the bootnote about ovs 1.10 should apply - but I still see issues - interesting [09:26] jamespage: is there anything we can do in juju to help here? [09:26] rogpeppe: on most wan links the MTU is usally adjusted down, to leave room for the GRE encapsulation [09:26] rogpeppe, I'm still thinking about that [09:27] davecheney, yeah - thats the other way to fix this - drop the mtu on the instances themselves [09:27] that can be done using DHCP options [09:27] jamespage: IMO it's the more common approach [09:27] for you cant guarentee jumbo frames [09:27] davecheney, its not 100% reliable - not all dhcp clients use that option [09:28] jamespage: indeed [09:28] one of the many problems with GRE encapsulation [09:35] jamespage, is it possible that in https://bugs.launchpad.net/juju-core/+bug/1236754 it actually used to return `null` rather than ``? [09:35] <_mup_> Bug #1236754: behaviour change: relation-get for unset attribute returns "" in 1.15.1 [09:36] fwereade, possibly [09:36] fwereade, null -> None as well [09:36] jamespage, that's the only explanation I can see that makes sense [09:36] fwereade, but I remember raising a bug about this [09:36] in 1.12 [09:36] so it's not the api [09:37] dimitern, yeah, it's the type change down in RelationGetCommand.Run [09:41] fwereade, TheMue: i'd appreciate a review of this, please. https://codereview.appspot.com/14395043/ [09:41] *click* [09:42] fwereade: if Addresses doesn't work on maas, that kinda stuffs the API caching [09:44] rogpeppe, indeed -- have you seen mgz today? [09:44] fwereade: nope [09:44] rogpeppe, because it *looks* like we just need to log and ignore errors from the ipAddresses method [09:45] fwereade: yeah, we've already got one address, so returning an error seems wrong [09:45] fwereade: fyi, you can't bootstrap on hp cloud using the shared credentials cause we are out of security groups. there's a whole lot of nec and yjp ones but i'm not sure if any of those can be deleted [09:46] davecheney, do you know if we can do anything about the above? [09:54] fwereade: i'm not sure I understand the problem [09:54] fwereade: about MTUs ? [10:00] rogpeppe: you've got a review [10:01] TheMue: thanks [10:02] TheMue: "I dislike the 0 postfix" - what would you use instead? [10:03] TheMue: personally i think it works ok when you've got two views of the same object - [10:03] davecheney, sorry, I mean about nec/yjp security groups in hpcloudas referenced by wallyworld [10:04] TheMue: the zero implies an original [10:04] davecheney: you can't juju bootstrap on hp cloud right now [10:04] it errors with a 400 code, too many sec groups [10:05] nova sec-group-list shows a lot of them for sure [10:06] wallyworld: wha [10:06] this is news to me [10:06] rogpeppe: as i said, only a personal thing. i would write agentConfig, err := NewAgentConfig() [10:07] are you using firewall-mode: global ? [10:07] TheMue: and what about the second variable, which is also an agent config, and refers to the same object? [10:07] i haven't set that anywhere [10:07] whatever the default it [10:07] is [10:07] wallyworld: the default is not to use that [10:07] and by default you get 25 security groups *PER TOP LEVEL ACCOUNT* [10:08] TheMue: (the variable currently named "config") [10:08] ie, if you're sharing some account Antonio gave you [10:08]