[01:25] oh poo [01:26] wanting to add something to a worker manifold, but it just defines itself as a copy of engine.AgentApiManifoldConfig [01:26] * thumper sighs [01:26] * thumper unpicks [01:26] perhaps after a dog walk [03:16] Bug #1271744 changed: bootstrap on maas with --metadata-source fails

[03:16] Bug #1567763 changed: bootstrapping private openstack, with --metadata-source fails when instance-type constraint is specified

[03:20] bugger [03:20] clean up a test and now it fails [03:20] * thumper reverts [03:29] axw: the more I think about it, the more I think your approach for those flaky MachineSuite tests is the right thing to do for now [03:29] axw: i'll give it a try soon [03:29] menn0: cool [03:33] fark [03:54] thumper: http://reviews.vapour.ws/r/5342/ [04:22] Bug #1588115 changed: json: cannot unmarshal string into Go value of type nova.jsonEntity

[05:35] thumper: http://reviews.vapour.ws/r/5343/ [08:26] axw: ping [08:26] rogpeppe: pong [08:26] axw: yo! [08:26] howdy [08:26] axw: is it a bug or a feature that credentials can't be updated or deleted? [08:27] rogpeppe: bug [08:27] axw: ok, thought so, just checking [08:27] rogpeppe: working on the foundations of updating them still [08:27] axw: (if you try to update an existing credential, you get a "state changing too quickly" error) [08:27] axw: (not the most informative error in the world :] ) [08:28] rogpeppe: oh, well that's a different type of bug :) I just meant that we don't react to changes at the moment [08:28] I guess we're assuming they don't exist at the moment [08:28] axw: yeah, so there's no way for us to change them [08:29] axw: i was wondering if immutability was by design [08:29] axw: but it seems not :) [08:29] axw: i think it should make an update txn if the doc already exists [08:30] rogpeppe: yep. not set in stone, but at the moment we don't assume immutability. there's no documented workflows for updating creds, but I don't see any problem with updating existing ones [08:31] axw: i think that perhaps it's a mistake for the transaction Run method to *always* return "state changing too quickly" if the transaction fails [08:31] axw: whether that's appropriate surely depends on whether the transaction is designed to work in all cases [08:32] rogpeppe: it should always be valid, except if the transaction asserts are wrong? [08:32] (which seems to be the case here) [08:33] axw: well, there might well be operations which are designed to fail in certain cases (for example, a Remove operation might fail because the doc doesn't exist) [08:34] axw: or it might well be legitimate to have an operation that is supposed to fail if the doc already exists (insert vs update) [08:35] rogpeppe: sure, but you check that at the top of the transaction loop. if it doesn't exist, you return errors.NotExistsf. otherwise you assume it's there, but add an assert; the failure causes the loop to restart [08:36] you only get the "state changing too quickly" error if what you're chekcing at the top of the loop doesn't match what's in the assert, or if it really is happening too quickly [08:36] changing* [08:36] axw: that implies even more unnecessary round trips [08:36] axw: but i guess that's par for the course [08:36] rogpeppe: you don't *have* to use the transaction loop [08:36] rogpeppe: this error only occurs when you do [08:37] axw: you don't have to use the transaction loop? i thought that was the only way to run transactions these days. [08:38] rogpeppe: state.State.runTransaction doesn't use a loop [08:38] rogpeppe: state.State.run does [08:40] axw: ah, i didn't know about runTransaction or the distinction between that and run [08:41] axw: not great naming tbh - i think that Run should probably be named something that implies it will loop [08:41] rogpeppe: agreed on that [08:55] axw: just reported these bugs: [08:55] axw: https://bugs.launchpad.net/juju-core/+bug/1608421 [08:55] Bug #1608421: UpdateCloudCredentials should be able to change existing credential [08:55] axw: https://bugs.launchpad.net/juju-core/+bug/1608422 [08:55] Bug #1608422: it is not possible to remove cloud credentials [08:55] rogpeppe: thanks [08:56] axw: you're planning to fix these, right? (if not, we can probably do some work on it) [08:56] rogpeppe: eventually yes, but I don't know when I will get to them [08:56] axw: ok [09:02] Bug #1608421 opened: UpdateCloudCredentials should be able to change existing credential [09:02] Bug #1608422 opened: it is not possible to remove cloud credentials [09:05] Bug #1608421 changed: UpdateCloudCredentials should be able to change existing credential [09:05] Bug #1608422 changed: it is not possible to remove cloud credentials [09:08] Bug #1608421 opened: UpdateCloudCredentials should be able to change existing credential [09:08] Bug #1608422 opened: it is not possible to remove cloud credentials [09:12] axw: is it my imagination, or are there no tests at all for the State.UpdateCloudCredentials method? [09:19] rogpeppe: indeed, that one slipped through [09:20] axw: i'm doing a coverage test on state now :) [11:25] huh, irc wasn't open [11:25] anastasiamac, can we chat about supported architectures? [11:31] fwereade: yes we can :) [11:32] anastasiamac, tell me if I get any of the following statements wrong [11:32] fwereade: k [11:32] axw: as a followup to the UpdateCloudCredentials thing, there are a few other methods that could do with tests in state... https://bugs.launchpad.net/juju-core/+bug/1608494 [11:32] Bug #1608494: state: not all public methods are tested [11:33] anastasiamac, *in general*, bootstrapping with local image metadata will cause the image metadata to be uploaded and put in the database and made accessible to all environ instances created on the controller [11:34] fwereade: right (when database is present and we have a connection to it) [11:34] anastasiamac, there is a window of badness that affects *only* the environ instance that's actually bootstrapping the controller [11:36] fwereade: kind of... i have a gut feeling that the "window of badness" has a flow on affect. If it's fixed the flow-on effect *may* be fixed too [11:36] anastasiamac, that problematic environ instance is running on the same machine as the one that got the image metadata in the first place [11:36] anastasiamac, (I'm pretty sure that agents won't get env config except via an api conn? or at least via the database) [11:37] fwereade: i *think* it maybe that environ instance *has access* to the machine that has image metadata [11:39] fwereade: well, metadata has several data soureces - database is one of thethem and we hope is the main one - but ther are also url and file data sources.. [11:39] anastasiamac, I don't understand the follow-on effect [11:40] anastasiamac, well, sure, but I don't think we need to care what the data sources are -- we just need to care that they *match* [11:40] fwereade: so I ahve seen bugs where private clouds (or no intrnet env) can bootstrap using --metadtaa-url (= web served data) not metadata source (= file locations) [11:40] fwereade: but had troubles deploying workload [11:40] fwereade: right about the match [11:41] fwereade: so form what i've seen, the "badness" occurs before stat is open where we select tools and get custom metadata from locally accessible location [11:42] fwereade: we detemrine supported architectures from declared data sources (which we have not declared yet) and are ignoring bootstrap custom metadata [11:42] anastasiamac, so, the local stuff is not a properly configured data source for the environ? shouldn't it be? [11:43] fwereade: when we get it, we do not have environ yet [11:43] fwereade: we pass it into startinstance as params [11:43] anastasiamac, all the more reason to create the environ knowing what data source it should use [11:43] fwereade: data source is created [11:43] fwereade: but data source is just the location to look at [11:44] fwereade: what we need here is a collection of actual values [11:44] fwereade: since we do not have anywhere to put them et. we can only pass them around [11:44] fwereade: i *think* :) [11:44] anastasiamac, the data source is an abstraction allowing us to get those values, isn't it? [11:44] anastasiamac, how does an environ know SupportedArchitectures if not by looking at what some datasource provides? [11:45] fwereade: yes, and as soon as we get a chance we put them in db :) [11:45] fwereade: suppoted architectures does not look i db at this stage anyway.. it's somethign that needs to happen but has not yet [11:45] fwereade: putting this custom metadata into db will not help [11:45] anastasiamac, well, the provider should pretty much never be looking in the db, tbh [11:46] anastasiamac, I'm not suggesting we should [11:46] fwereade: becasue we only obtain it and use it before db is started [11:46] anastasiamac, right [11:46] fwereade: \o/ [11:46] anastasiamac, I'm saying that the environ we use to bootstrap is misconfigured if it's using a different data source to the one specified [11:47] anastasiamac, (and that a local source needs to be uploaded and put in the db to be accessible later, but it sounds like that all works correctly anyway) [11:47] fwereade:db upload works exactly as expected :) [11:48] fwereade: peerfectly :) [11:48] anastasiamac, (and also cautioning you against imagining that an environ ever "should" look in the db, that may be the ultimate source of the data but db concerns belong nowhere near environs) [11:48] anastasiamac, cool [11:48] anastasiamac, I'm sorta implicitly dismissing the follow-on concerns then [11:49] fwereade: even better for me then :) [11:49] anastasiamac, I can see an easy way to bootstrap and not be able to deploy, if you use a metadata url that's accessible to the client but not the controller [11:49] anastasiamac, and that is sorta a Don't Do That Then situation [11:50] anastasiamac, and it sounds like the upload of local metadata is also fine, so managing to bootstrap should imply we can deploy anything covered by that local metadata [11:50] anastasiamac, remind me how data sources *are* associated with an environ? [11:50] Bug #1608494 opened: state: not all public methods are tested [11:50] fwereade: this specific fix does not deal with URL served metadata - this works. Metadat-source is a file location [11:51] fwereade: metadata-url vs metadata-source [11:52] anastasiamac, yeah -- and it really seems like there's *one* environ, that we're trying to bootstrap, which will fail if it doesn't have proper access to the local metadata [11:52] anastasiamac, am I missing something? or am I pointing at the central problem [11:52] fwereade: right. of course with my changes, i managed to bootstrap :) [11:56] morning [13:33] Bug #1608527 opened: lxd bootstrap now slow, timing out, fails

[13:45] Bug #1608527 changed: lxd bootstrap now slow, timing out, fails

[13:45] Bug #1608528 opened: machineSuite.TestShortPollIntervalWhenNoStatus timing problem: expect 2, obtained 2

[13:45] Bug #1608529 opened: suprious 'd' in log output during lxd bootstrap [13:45] Bug #1608533 opened: Race in github.com/juju/juju/apiserver/tools_test

=== natefinch-afk is now known as natefinch [15:01] will be back later [15:58] ug, taxes on part of my property went up by 54% since last year :/ Luckily, it's the smaller of the two parcels, but it still means over $200 a month extra I'm paying... except that it's doubled by my mortgage company this year to put extra in escrow :/ [16:15] Bug #1608597 opened: CalledProcessError for juju-2.0 deploy -m slaveX:default deployment_file [16:27] Bug #1608597 changed: CalledProcessError for juju-2.0 deploy -m slaveX:default deployment_file [16:33] Bug #1608597 opened: CalledProcessError for juju-2.0 deploy -m slaveX:default deployment_file [16:43] natefinch: I understood very little of that [16:44] you can move to argentina, 200 dollars is about 1/3 of my yearly tax [16:45] perrito666: the property that my house is on is in two towns... one of the towns decided that the piece of land I own in their town is worth twice as much this year as was worth last year. [16:45] ah, I see, we have a much more strict definition of town [17:02] * rick_h_ goes for lunchables [17:03] rick_h_: you should really find something less processed than lunchables. Those things are terrible. [17:26] natefinch: just my way of saying 'food for lunch' [17:26] leftover blue apron meal today [17:26] rick_h_: I know, just giving you a hard time :) [17:27] rick_h_: I had leftover thai food :) [17:31] I had .... too hard to translate, dry tomatoes, some greens, mozzarela and ham on ciabatta with a flavoured cream :p [17:31] lunch caught me off my house, otherwise it would be way less pretentious [17:48] perrito666: sounds tasty [17:49] also, verdict on the taxes: evidently the town did a review, and realized they'd been taxing us at the residential rate, but that piece of land is in a commercial zone, which is a lot more expensive. sigh. [18:00] natefinch, 54% is crazy in one year [18:00] I would have something to say about that [18:01] alexisb: well, the land *is* in a commercial zone, I knew that when we moved in. So, basically we've been getting a 33% discount for the last 6 years :/ [18:14] when attempting to build Juju from master it is hanging on cmd/jujud has anyone ever run into this before? [18:22] hatch: nope. [18:22] hatch: when's the last time you did a successful build? [18:22] natefinch: on this machine, never [18:22] fresh install [18:22] hatch: hm.. suspicious [18:22] Go 1.6.3 [18:23] hatch: are you using the makefile or running go install manually? [18:23] I was running `go install -v ./...` [18:23] *nod* did you run godeps first? [18:23] yep [18:23] I got nuthin. [18:24] maybe Juju doesn't build with 1.6.3? [18:25] I can try it locally.... I was using 1.6.2, can try 1.6.3 easy enough [18:25] I've just deleted everything and it's rebuilding [18:26] will see if it hangs [18:26] yup hung again on jujud [18:27] I'll try downgrading to 1.6.2 [18:30] natefinch: fwiw 1.6.2 also hangs [18:31] natefinch: ping for meeting [18:32] rick_h_: oops, thanks, coming [18:32] hatch: building now... probably something weird with the machine you're building with [18:33] natefinch: yeah, I am just not sure how I go about debugging it as there isn't any output [18:33] natefinch: go build also hangs [18:34] as expected I suppose [19:21] * rick_h_ goes to get boy from camp biab [20:15] katco: can you add some step by step QA docs to https://github.com/juju/juju/pull/5906 please and once there natefinch can you please look at and review and validate QA please? [20:16] rick_h_: sure thing [20:16] rick_h_: pointer to step-by-step instructions are in the review's "testing" section [20:16] katco: ah, sorry. I got an email on the PR but didn't see anything to the RB [20:28] natefinch: also please mark https://bugs.launchpad.net/juju-core/+bug/1604474 fix comitted [20:28] Bug #1604474: Juju 2.0-beta12 userdata execution fails on Windows

[20:28] rick_h_: done [20:29] ty [20:31] katco: while your branch is up for review can you peek at https://canonical.leankit.com/Boards/View/122969419/123586962 please? [20:31] katco: looks like it just didn't get landed due to conflicts that maybe you could resolve/get it landed? [20:31] katco: as a quick win for the b14 [20:32] rick_h_: it looks like it doesn't have a ship it [20:32] katco: oh nvm, reviews say needs lots of love. More than just conflicts. [20:33] * rick_h_ follows bug to pr to RB to ... :) [20:33] hehe [20:47] man, the github CLI helper, hub, really makes testing other people's branches easy. I can just hub checkout https://github.com/juju/juju/pull/5906 and run the code from a PR. [20:58] natefinch: <3 if you find a good pattern write it up please. I was using my old tricks from before with custom git aliases [20:58] natefinch: making it easier/faster to qa-prs is <3 [21:02] natefinch: https://github.com/juju/docs/blob/adc36a78430d84f5c6ab05b271eb3b700768ba40/README.md#using-git-aliases is what we used to use [21:04] katco, rick_h_: ran out of time to test that PR. I have it all deployed.. but hit a weird situation while removing and re-adding. Will continue looking at it after the kids are in bed === natefinch is now known as natefinch-afk [21:04] Bug #1608677 opened: Remove filesystem cache for charm archives [21:04] natefinch-afk: ty, have a good evening [21:26] hey whats up guys? [21:27] I'm having some issues with network spaces on aws ... I guess I'll write the list ... thought I would check here first [21:29] I have successfully bootstrapped into my aws vpc using `juju bootstrap mycloud aws --credential mycred --config vpc-id=my-vpcid --config force-vpc-id='true' --upload-tools` [21:30] and subsequently created a model on my aws controller in the vpc with `juju add-model my-new-model -credential mycred --config vpc-id=my-vpcid --config force-vpc-id='true'` [21:31] following which, I add a network space, and then my subnet [21:32] http://paste.ubuntu.com/21814798/ [21:34] ok, everything looks great so far .... then I go and launch an instance and it all falls apart -> http://paste.ubuntu.com/21815678/ [21:34] any ideas? [21:46] sent to the list [22:47] Bug #1608723 opened: "juju test" command needs updating for juju 2.0 [22:57] thumper: o/ http://reviews.vapour.ws/r/5346/ [22:57] this makes that flaky MachineSuite test fail reliably as well as cleaning up a bunch of other stuff [22:58] * thumper looks [23:01] shipit [23:13] bdx: can you confirm the rest of the story there? Did the bootstrap instance start on the right vpc you asked it to? [23:13] bdx: from the list it seems like you asked it to do the right thing, but I'm curious if juju did all the right things with the vpc for the controller, machines for the units deployed, etc. [23:43] thumper: point me to your review [23:59] thumper: the liiiiiiink [23:59] http://reviews.vapour.ws/r/5345/