[00:02] ping thumper [00:15] davecheney, thumper, whoops, I should sleep [00:15] fwereade__: I guess so :) [00:15] thumper: are your tests still broken ? [00:16] davecheney, thumper: if either of you is inclined to go on a trawl through my +activereviews I have a whole bunch and they should all be relatively easy [00:16] i have some suggestions that you can apply from my experiences making the tests work under Q [00:16] davecheney: I'm running a quantal virtual box [00:16] I've not tried today with raring [00:16] davecheney, thumper: they're all in a pipeline because they're all things I need to do to connect constraints up to environs [00:16] * fwereade__ waves and departs [00:16] fwereade__: ok [00:17] davecheney: do you know where lbox stores the google auth token? [00:18] ~/.lpad_oauth [00:18] ta [00:21] davecheney: it seems that a whole bunch of ubuntu pastebins were deleted over the weekend [00:21] no idea why [00:22] davecheney: also, ~/.lpad_oauth seems to only be the launchpad credentials [00:22] davecheney: I deleted it and tried lbox propose [00:23] thumper: good point [00:23] davecheney: but it used the google credentials I was trying to change [00:23] let me look again [00:26] thumper: ~/.goetveld_* [00:26] davecheney: ta [00:27] one per host [00:27] should only be one [00:27] * thumper nods [00:27] * thumper deletes it [00:27] and tries again [00:28] wow: error: Failed to load data for project "juju-core": use of closed network connection [00:28] tried again... and it does something [00:29] yup, nobody is sure if that is LP, or something weird in the go http client [00:29] 2013/02/25 11:28:41 JUJU environs: searching for tools compatible with version: 1.9.10-quantal-amd64 [00:29] 2013/02/25 11:28:45 JUJU juju bootstrap command failed: cannot start bootstrap instance: cannot allocate a public IP as needed [00:29] and the public IP shortage continues to make it impossible to test canonistack [00:43] davecheney: I'm tempted to just leave the raring test issues until atlanta, as I expect the round-tripping will be a lot faster [00:43] thumper: i'll propse a branch [00:43] i know most of the places that are broke [00:43] oh, ok [00:43] I am happy to test [00:44] from memory it is the test mocks [00:44] /s/mock/fixtures [00:47]

Please try again

[00:47]

[00:47] Sorry, there was a problem connecting to the Launchpad server. [00:47]

[00:47]

[00:47] Try reloading this page in a minute or two. [00:47] If the problem persists, let us know in [00:47] >the #launchpad IRC channel on Freenode. [00:47]

[00:47]

Thanks for your patience.

[00:47] love this [00:49] thumper: Proposal: https://code.launchpad.net/~dave-cheney/juju-core/097-environs-raring-fixtures/+merge/150254 [00:49] Rietveld: https://codereview.appspot.com/7380047 [00:52] davecheney: what's with the 097 branch prefix? [00:52] dunno, just something we all started doing [00:52] personally, i got lost in all the open branchs I had [00:52] numbering them at least let me know where they were temporarlly [00:56] davecheney: hmm, still fails a lot, I'll pastebin the errors [00:57] ta [00:57] gonna have to do this blind, i'm not upgrading to raring [00:58] :) [00:59] sorry, i need my machine to work [01:01] davecheney: http://paste.ubuntu.com/5563524/ [01:01] davecheney: I've managed to keep working using a quantal VM I had lying around :) [01:01] you need to do the git dance [01:02] arguably we should pass a faux gitconfig [01:02] I have done that... [01:02] dance harder, monkey boy [01:03] how to I get git to tell me what it has configured for user and email? [01:03] cat ~/.gotconfig [01:03] cat ~/.gitconfig [01:04] $ cat ~/.gitconfig [01:04] [user] [01:04] email = tim@penhey.net [01:04] name = Tim Penhey [01:04] and it still fails [01:04] le sigh [01:04] so I'm wondering what else has changed [01:04] either way, the test shouldn't assumed you've done the git dance [01:04] agree there 100% [01:05] thumper: am fixing now [01:05] can you be a sport and raise an issue [01:06] davecheney: for juju-core? [01:06] sure [01:06] for the entire test failure, or just the git dance? [01:06] either [01:06] sure [01:06] raise as many or as few as you like [01:06] the tests pass with quantal [01:07] and I hadn't done the git dance there (at least I don't think I had) [01:07] or if I had, something else has changed between quantal and raring about where git looks [01:07] yeah, they didn't used too, which is why i'm wary of upgrading to raring [01:07] * thumper files a bug about tests failing on raring [01:07] ok, raise an issue about the git parts failing [01:07] that is the biggest part of the failure atm [01:09] hmm... [01:09] filed bug 1132585 just now [01:09] <_mup_> Bug #1132585: Tests fail on raring < https://launchpad.net/bugs/1132585 > [01:09] ta muchly [01:19] davecheney: boo... [01:19] I thought I was going to be so clever [01:19] but go didn't like it [01:20] I was thinking I'd be able to inject a couple of methods into the cmd.Context function set from a testing module [01:20] but it ddn't work [01:20] was wanting something like: func (c *cmd.Context) StdoutString() string [01:20] but go said no [01:21] * thumper decides to use testing.stdout(c *cmd.Context) instead [01:21] with a capital S [01:21] I think that is nicer than bufferString(c.Stdout) [01:22] testing.Stdout(c) instead [01:22] davecheney: what do you think? [01:22] * davecheney doesn't really follow [01:22] paste ? [01:22] davecheney: the guts of it is: we have two identical bufferString implementations [01:22] and I was wanting to not [01:23] also considered changing the names somewhat [01:23] as I thought it read better [01:23] am I being too anal? [01:23] * davecheney doesn't really follow, has three people talking to him at the moment [01:23] :) [01:24] * davecheney is confused, i've hacked the uniter tests to supply a completely impossible value for GIT_CONFIG, and the tests still pass [01:24] * thumper shelves the change for an anal day [01:24] u gonna submit your cmd aliases branch, or what ? [01:31] I did [01:31] I thought I did it last week [01:31] but for some reason it didn't go through [01:31] fixed and resubmitted today [01:35] ugh [01:36] gnuflag FTL [01:36] * thumper realises that a bunch of refactoring wasn't needed [01:38] * thumper relocates [04:59] thumper: i can't figure it out, i've removed my own .gitconfig and the tests still pass [05:05] thumper: def a version change for git in raring [05:05] https://launchpad.net/ubuntu/+source/git [05:05] NFI what has changed [05:43] can you post the source for goroutine 10 [select]: [05:43] github.com/wharf/tuplespace.(*TupleSpaceImpl).run(0xc20015f000) /Users/alec/.go/src/github.com/wharf/tuplespace/tuplespace.go:164 +0xb88 [05:43] created by github.com/wharf/tuplespace.NewTupleSpaceImpl /Users/alec/.go/src/github.com/wharf/tuplespace/tuplespace.go:58 +0x142 ? [06:44] wallyworld_: poke [06:44] hi [06:44] mumble? [06:44] yep [06:44] just got on [08:09] fwereade__: ping [08:11] dimitern, fwereade__: morning! [08:11] rogpeppe: morning! [08:11] rogpeppe: how was your holiday? [08:12] dimitern: very good, thanks. nice weather, made it to the top of a few hills, had some nice food. [08:13] rogpeppe: cool :) [08:18] fwereade__, rogpeppe: Maybe one of you guys know. How do you compile just the test binary? I want to profile it, and I can run "go test -cpuprofile" but "go tool pprof" needs the build binary as a reference to interpret the profile output [08:18] jam: hiya [08:18] But I can't find a flag for "build just the test binary" [08:18] jam: go test -c [08:18] rogpeppe: anyway to actually find the documentation for that? [08:18] jam: go help test [08:18] go help testflag doesn't seem to have it [08:18] jam: testflag gives help on the flags for the test binary itself [08:18] rogpeppe: there are 4-different ways to get help, and I missed that one... :( [08:18] go test -h no good [08:19] go help [08:19] go help testflag [08:19] grep around online for a while [08:19] rogpeppe: thanks for at least pointing it to me. I really expected to find it somewhere else [08:19] jam: go help should be your first stop [08:19] jam: the testflag documentation is unusual [08:20] jam: because it's not really documentation on a go subcommand [08:20] jam: but it is referred to by the go test help [08:20] jam: (how else did you know about testflag?) [08:20] rogpeppe: well 'go -h' is my natural first stop, but that ==> 'go help' which is, unhelpful IMO [08:20] why would 'go help ' not match 'go -h' [08:21] rogpeppe: note that "go tool command -h" *is* the way to get help for individual commands as part of tools. [08:21] jam: i dunno. but to be fair that (and go help) both say "Use "go help [command]" for more information about a command." [08:21] Though "go help tool" *doesn't* show you what tools are available. [08:22] jam: they might well accept a patch making go command -h work [08:22] rogpeppe: and "go tool -h" also == "go help tool" which is a bit inconsistent. [08:23] rogpeppe: as is 'go build -h' [08:23] (I'm not planning on trying all of them, though) [08:23] jam: oh yes, so it is [08:24] jam: that's definitely an inconsistency i'd never noticed [08:24] jam: (because i've always used "go help x" - as i do in bzr and hg etc) [08:24] rogpeppe: also, there is no way to get the flags for the test command, you have to do some weird invocation of "go test -invalidflag" and then the binary fails and reports its options [08:24] jam: (but not juju!) [08:24] though those *don't* include the ones to 'go test' itself, because it is a different binary that interprets them. [08:25] jam: go help testflag, no? [08:25] rogpeppe: And I've generally always used "bzr command -h" :) [08:25] jam: ah, except not quite [08:25] rogpeppe: go help testflag doesn't do the -gocheck.* etc. [08:25] I tried reporting an issue on it [08:25] that there was no way to get the flags for the test suite [08:25] and it was sort of punted. [08:26] jam: you might be able to do "go test . -help" [08:26] rogpeppe: nope, that '-help' gets interpreted by 'go test' and just get 'go help' output [08:28] jam: yeah, that seems wrong [08:28] rogpeppe: anyway thanks, -c helped me get what I wanted, and I can use the 'go help foo' style [08:28] jam: np [08:29] jam: it'd be worth raising an issue i think. now's the time if we want it fixed by go 1.1 [08:30] rogpeppe: care to raise it? Might get more attention from you or dave [08:30] jam: i'd appreciate a review of https://codereview.appspot.com/7390043 if you have some time at some point, BTW. [08:31] jam: ok [08:39] jam: FWIW, go test is the *only* subcommand for which -h doesn't work [08:39] jam: it's probably something to do with the fact that it mixes flags between top level and compiled-binary level [08:41] Morning all. [08:42] TheMue: morning [08:42] TheMue, dimitern, rogpeppe, jam: mornings [08:42] fwereade__: yo! [08:43] fwereade__: i'm angling for reviews of https://codereview.appspot.com/7390043, but you're probably aware of that :-) [08:51] fwereade__, jam: morning [08:51] mgz: hey [08:55] hey dimitern [09:04] rogpeppe, just sent a slightly bewildered one :) [09:04] fwereade__: ok [09:04] rogpeppe, can you think of any reason for the ec2 tests to depend on the dummy provider? [09:04] fwereade__: i don't *think* so [09:05] fwereade__: do they? [09:05] rogpeppe, can't run them without fixing the dummy provider, it seems, but I can't quite figure out the connection [09:06] fwereade__: ah, i know [09:06] fwereade__: the tests build the tools when testing PutTools [09:07] rogpeppe, oh, ffs, ofc [09:07] fwereade__: and i guess the tools depend... hmm, they shouldn't [09:09] rogpeppe, ah! [09:09] rogpeppe, juju/testing uses the dummy provider [09:09] fwereade__: ah, of course [09:09] rogpeppe, btw: why does StartInstance take apiinfo/stateinfo? [09:10] * rogpeppe tries to remember [09:10] rogpeppe, fwiw I'm also planning to drop the tools param [09:11] fwereade__: oh yes, the idea was that the new instance needs to know how to contact the state server [09:11] rogpeppe, yeah, but the environment already knows that [09:12] rogpeppe, the only thing that's actually needed is the password [09:12] rogpeppe, (btw are passwords for stateinfos or just for apiinfos? it's not clear why we save them for both when bootstrapping and only for state when startinstanceing) === negronjl` is now known as negronjl [09:14] fwereade__: i'm not sure what you're referring to by that last sentence [09:16] rogpeppe, when you start a machine with a api info, what uses that API info? [09:16] fwereade__: i think i was trying to avoid making the assumption that the environment always knows where the state server is. [09:16] rogpeppe, why? [09:16] rogpeppe, that's the one core thing we depend on the environment being able to do for us ;p [09:17] fwereade__: we might want to store the current set of state server addresses in the state itself. [09:18] fwereade__: in fact for the state server (as opposed to the API server) i think that's going to be the case [09:18] fwereade__: hmm, but actually [09:19] fwereade__: we're going to be able to drop state.Info eventually [09:20] fwereade__: when you start a machine with an api info, the api info is used by the agents on that machine to connect to the API server. [09:22] fwereade__: one advantage of passing a state info into StartInstance is that the environ doesn't have to query the bucket and resolve the DNS name each time. but perhaps that's a trivial cost. [09:22] fwereade__: and it could be cached. [09:26] rogpeppe: so I'd like to ask a bit about possibly caching the 'bundleTools' output during the test suite. Right now it takes about 2.5s for it to compile jujud and then tarball.gz it, and it happens far more times than I would expect. [09:27] (eg, "BootstrapMultiple" test actually rebuilds the tools at least 2 times for that one test, but it also happens between tests.) [09:27] jam: yeah, it would be nice to get rid of that overhead [09:27] fwereade__: I think waitHooks{} is not working correctly [09:27] fwereade__: or maybe I'm not using it right [09:28] jam: i could never think of a sufficiently clean way of doing it, but i didn't think about it that hard. [09:28] rogpeppe, ok, long-term, I agree that the state info will probably be stored elsewhere and distributed separately, but for now it seems that the state info is the one we use and the api info is just kinda hanging on alongside without any agent actually using it yet -- is this correct? [09:28] dimitern, hmm, ok... would you paste me your output again and I'll see if any inspiration strikes? [09:28] fwereade__: agents will use it very soon. they do actually connect to it, i believe, currently, even if they don't actually use it. [09:29] fwereade__: actually... maybe they won't use it so soon. [09:29] fwereade__: hmm. [09:29] fwereade__: I'm augmenting the logging to see what's going on, just a moment [09:34] fwereade__: yes, the API info isn't currently used. but it will be - it's a placeholder for what's to come. [09:34] fwereade__: I found it! [09:34] * fwereade__ cheers at dimitern [09:34] dimitern, go on [09:34] fwereade__: matchLogHooks does not accept u/0 db2:0 [09:35] dimitern, grar, sorry [09:35] fwereade__: `u/0(| [a-z-]+:[0-9]+)` that's the hook pattern [09:35] dimitern, yeah, all makes sense [09:35] fwereade__: I'll change it to `u/0(| [a-z0-9-]+:[0-9]+)` [09:37] dimitern, sgtm [09:38] fwereade__: now the db2-relation-joined mysql/0 db2:0 is matched, but still somehow ignored [09:38] dimitern, discraded by test id badge checking? [09:39] fwereade__: still checking.. [09:41] fwereade__: :) the other regexp - donePattern needs changing as well [09:41] dimitern, ah, ok [09:44] fwereade__: now it works :) yay! [09:44] dimitern, w00t! [09:44] fwereade__: well, it fails, but for a different reason [09:45] fwereade__: matching seems to pick up all hooks now [09:45] fwereade__: this is what I got before the failure: [LOG] 0.53984 JUJU actual: []string{"install", "config-changed", "start", "upgrade-charm", "config-changed", "db2-relation-joined mysql/0 db2:0"}, ctx.hooks: []string{"install", "config-changed", "start", "db2-relation-joined mysql/0 db2:0"} [09:45] [LOG] 0.54002 JUJU expected []string{"install", "config-changed", "start", "db2-relation-joined mysql/0 db2:0"}; never got anything [09:46] fwereade__: upgrade-charm hook is missingm hence the failure [09:46] dimitern, yeah, I think you should specify the exact sequence of hooks [09:47] dimitern, I think if anything it makes the test clearer actually [09:47] dimitern, "do these things as close together as possible; check everything happens in the correct order" [09:47] fwereade__: yeah, I commented out the waitHooks{"upgrade-charm", "config-changed"} before the db2-r-j one, now I uncommented that and run it again [09:48] fwereade__: and guess what - OK: 1 passed [09:48] fwereade__: cool! I'll propose it now [09:51] fwereade__: I could debug it effectively by replacing c.Logf() with log.Printf() - we should think about this probably (otherwise these are 2 separate logs and are out of sync) [09:51] dimitern, expand please... I'm pretty sure that log.Printf is the one that produces apparent sequence breaks [09:53] fwereade__: well juju uses log.Printf/Debugf and all lines are in a nice, expected order when printed [09:54] dimitern, gaah sorry I totally misread you [09:54] fwereade__: c.Logf on the other hand is a separate log, so the combined output is not sequential [09:55] dimitern, they're happening on different goroutines anyway, though... [09:56] fwereade__: yes, and we you look at the output it's not helpful (smth happened here and before or after is happened this other thing in the other log) [09:56] s/we// [09:56] s/is// [09:56] :) I'm too fast to be readable today [09:57] :) [09:57] fwereade__: running a couple of times without the log hacks, to make sure the timing wasn't screwed somehow [09:58] dimitern, well, you can see the two streams of independent events going on, right, they're just interspersed -- how would that change if they used the same log? [09:59] fwereade__: well, you can tell that all lines after X happened after X happened, while now some things before X also happened after X [09:59] fwereade__: X = juju log [10:02] fwereade__: it'll be really nice if we separated parts of the uniter tests in smaller chunks (they can still use the same table format) - maybe on logical boundaries ("// XYZ tests" + NL) [10:03] dimitern, yeah, I think that'd be a definite win [10:04] fwereade__: there it is https://codereview.appspot.com/7385049 [10:04] dimitern, cool, will take a look shortly [10:05] dimitern, thanks :) [10:06] fwereade__: cheers, I left some questions in comments [10:32] dimitern, reviewed, LGTM, some comments [10:32] fwereade__: thanks! [10:42] rogpeppe, dimitern, jam: I would very much appreciate your thoughts on https://codereview.appspot.com/7394048 which is still WIP [10:42] fwereade__: I'll take a look in 2m [10:42] fwereade__: chunk mismatch. please reupload. [10:43] rogpeppe, what does that complaint actually imply? what will change if I repropose? [10:43] fwereade__: i've no idea, but reproposing usually seems to fix the problem. [10:44] rogpeppe, haha, ok :) [10:45] rogpeppe, better? [10:45] fwereade__: yup [10:45] fwereade__: thanks [10:45] rogpeppe, cool, wish I understood what was up there [10:46] fwereade__: me too. let me know if you find out! [10:50] fwereade__, dimitern: i've responded to your comments on this, and made some changes: https://codereview.appspot.com/7390043 [10:51] fwereade__: (i've also identified one significant omission, which i will be addressing shortly) [10:52] rogpeppe, sorry, it was clearly monday morning... I think I read the goroutine as a defer or something [10:53] fwereade__: ah, i wondered where the comments were coming from :-) [10:53] rogpeppe: cheers, I'll take a look [10:56] fwereade__: can we assume my CL closes bug 1101140 ? [10:56] <_mup_> Bug #1101140: uniter does not skip unimplemented relations

< https://launchpad.net/bugs/1101140 > [10:56] dimitern, yep [10:57] fwereade__: sweet! [10:57] :D [10:58] fwereade__: one down, 7 to go (wrt upgrade-charm bugs) [10:58] dimitern, yay :) [10:59] dimitern, SetCharm is the next goal, but I'm not sure whether you should be handling the config changes first or the sanity checks first [11:00] fwereade__: I'll revisit the notes and we may need to have a g+ later perhaps? [11:00] dimitern, I suspect doing the config changes is your best bet... maybe go with that, not worrying about the refcounting for now [11:00] dimitern, but, yeah, reread the notes and let me know [11:01] dimitern, I'd really appreciate thoughts on the Environ change first though :) [11:01] fwereade__: I'm on it now [11:01] dimitern, <3 [11:02] btw i'll need one more LGTM on this guys https://codereview.appspot.com/7385049/ - anyone willing? [11:07] rogpeppe, what's the other oversight? can't spot it, so LGTM, but you've made me nervous ;p [11:07] fwereade__: i never tear down the watchers when the connection is dropped [11:08] rogpeppe, ha! I remember that thought crossing my mind and then flitting away before I captured it in the first read [11:08] rogpeppe, ty, good catch [11:08] fwereade__: it requires a little more more mechanism, and i'm not quite sure of the best method yet [11:09] fwereade__: am reviewing your bootstrap refactoring branch BTW [11:09] rogpeppe, comments always welcome but it's far from complete [11:10] rogpeppe, it's totally focused on getting ec2 working, nothing else [11:10] fwereade__: i'm trying to think about implications for future providers [11:12] rogpeppe, I have made an effort to consider that but am glad for the backup scrutiny [11:13] rogpeppe, LaunchInstance might actually be something more like RunMachineAgentOnInstance if you're bothered by the local provider [11:15] fwereade__: how does the new environs.Bootstrap square with the local provider? [11:15] rogpeppe, what does it use that any provider doesn't provide? [11:16] fwereade__: i'm not sure that the local provider provides a working StartInstance, does it? [11:16] rogpeppe, no reason it can't do it, though, is there? the "instance" is always the local machine, but it gets "launched" when the machine agent is started [11:17] rogpeppe, same deal as the SSH provider [11:17] fwereade__: and what about future environments that have no bootstrap instance? [11:18] rogpeppe, I don't see that you'd use bootstrap at all in that case [11:19] rogpeppe, there's no actual bootstrapping going on there, is there? [11:19] fwereade__: yeah - you'd tell some other machine to create an environment for you. [11:19] fwereade__: that's still "bootstrapping" even though it doesn't require a new machine [11:20] fwereade__: in general, i like the way that the refactoring looks (and it's necessary) but i'm not sure about its exact positioning [11:20] rogpeppe, well, it performs tasks that have *some* degree of overlap with those in Bootstrap [11:21] dimitern: You've got a review. [11:21] TheMue: thanks! [11:21] rogpeppe, go on [11:21] dimitern: yw [11:21] fwereade__: i'm still mulling it over [11:25] fwereade__: reviewed [11:25] dimitern, cheers [11:29] fwereade__: i'm wondering about leaving environs.Bootstrap as it is, but providing another function, say environs.BootstrapInstance, that contains the bulk of what ec2.Bootstrap does now (the tools uploading and the instance starting). then ec2.Bootstrap (and other similar providers) would just call that, but stranger providers would be free to do as they wished. [11:30] rogpeppe, is your concern specifically about starting instances? because that feels to me like the only behaviour that should differ [11:31] fwereade__: it's not just about starting instances. it's also about the way that your proposal makes Bootstrap into a fundamentally racy thing when called concurrently. [11:31] fwereade__: perhaps i should publish my current comments on the CL [11:31] rogpeppe, was it not so beforehand? [11:31] rogpeppe, sgtm [11:32] fwereade__: (they're superceded by the above thought, but still pertinent to the CL) [11:32] mgz: standup? [11:32] dimitern: yup [11:33] fwereade__: no, Bootstrap was only racy because its implementations were racy, not because the operation is fundamentally racy, i think. [11:34] fwereade__: as a trivial example, dummy.Bootstrap isn't racy [11:35] fwereade__: i published my comments BTW [11:35] Hi. In Python Juju, how does Juju get onto a machine that I'm deploying to? It is fetched from Launchpad? I'll put it another way. I make some code changes to a machine provider in my local branch of lp:juju. I then deploy a charm using this code. Does the allocated machine use my updated code? Does a machine need the machine provider code? (MAAS in this instance.) [11:35] * TheMue enjoys lunch, biab [11:35] rogpeppe, cheers [11:35] allenap, depends on juju-origin in the config [11:35] allenap, IIRC you can set it to your own lp: branch [11:36] juju-origin: ppa [11:36] allenap: ^ [11:36] allenap, you'll need to push before it'll use it though [11:36] allenap, btw, I have a maas question [11:36] allenap, can a process on a maas node easily find out the maas instance id? [11:36] fwereade__: Cool, thank you, I think that'll be useful. [11:38] fwereade__: rvba is checking that for you. [11:38] allenap, rvba, cheers [11:39] fwereade__: Doesn't look like it. What's the use case? [11:40] allenap, there's this foul InstanceIdAccessor hack that's persisted all the way back since orchestra and is uglying up every provider [11:40] * allenap looks it up [11:41] fwereade__: I think the only thing you have is the 'name' of the node. [11:41] allenap, the bootstrap node needs to know its own instance id and set it before its provisioning agent starts trying to provision an instance for itself [11:41] rvba, and that's not the same as the instance id, I guess? [11:41] No [11:42] The 'name' is just the node's hostname. [11:42] rvba, ok, thanks, no worries [11:43] allenap, it's not a big deal, I can certainly make it less evil regardless [11:44] fwereade__: The MAAS provider (Python) does call `cloud_init.set_instance_id_accessor(instance_uri)` so I assume it's getting over to the machine somehow. [11:45] I'll check that it's there as soon as my node comes up… [11:45] (I've just destroyed my environment in the lab) [11:52] fwereade__: actually, allenap was right, the instance id is in /var/lib/cloud/instances/ [11:52] $ ls lib/cloud/instances/ [11:52] allenap, rvba, wow, really? cool [11:52] node-74c10d5c-7f34-11e2-9a9a-525400123456 [11:53] Right, so the directory names is the instance ID? [11:53] Yes [11:53] s/names/name/ [11:53] Contains cloud-init stuff. [11:53] Is it also in a file within? [11:54] rvba, allenap: in that case I think we can just straight-up drop InstanceIdAccessor and ask providers to implement InstanceId just as they do PrivateAddress/PublicAddress [11:54] rvba, allenap: we can always hack it in via provider-specific machine config for functionality-challenged clouds in the future [11:55] fwereade__: that would make more sense than the chunk of bash method used currently [11:55]