| axw | abentley: don't suppose you're working? CI seems to have died... merge job has been running for 2 hours | 01:10 |
|---|---|---|
| axw | I'll just kill it and hope for the best | 01:11 |
| * thumper heading out for a bit, taking daughter to BJJ | 02:14 | |
| === natefinch-afk is now known as natefinch | ||
| natefinch | google: ps human readable memory | 03:40 |
| natefinch | response: <hugeass command> | 03:40 |
| natefinch | nobody's put a -h on ps, huh? | 03:41 |
| === Makyo is now known as Guest78890 | ||
| === meetingology` is now known as meetingology | ||
| === JoseeAntonioR is now known as jose | ||
| natefinch | nobody's put a -h on ps, huh? | 05:42 |
| natefinch | oops wrong window | 05:42 |
| natefinch | oops wrong window | 05:52 |
| mup | Bug #1516891 opened: juju 1.25 misconfigures juju-br0 when using MAAS 1.9 bonded interface <juju-core:New> <MAAS:New> <https://launchpad.net/bugs/1516891> | 06:31 |
| mup | Bug #1516891 changed: juju 1.25 misconfigures juju-br0 when using MAAS 1.9 bonded interface <juju-core:New> <MAAS:New> <https://launchpad.net/bugs/1516891> | 06:34 |
| mup | Bug #1516891 opened: juju 1.25 misconfigures juju-br0 when using MAAS 1.9 bonded interface <juju-core:New> <MAAS:New> <https://launchpad.net/bugs/1516891> | 06:43 |
| === mup_ is now known as mup | ||
| frobware | dimitern, ping 1:1? | 09:04 |
| dimitern | frobware, sorry, omw | 09:05 |
| axw | wallyworld: http://reports.vapour.ws/releases/3318 -- azure-arm-provider is blessed. what's the process to merge into master? | 09:54 |
| wallyworld | axw: yay. when master unblocked, just create a branch, merge in tip of feature branch, and propose | 09:54 |
| axw | wallyworld: cool. no need for review on that I take it? | 09:55 |
| wallyworld | axw: judgement call, usually no | 09:55 |
| wallyworld | IMHO | 09:55 |
| dimitern | voidspace, frobware, jam, fwereade, standup? | 10:01 |
| voidspace | dimitern: bugger, bugger, bugger | 10:14 |
| voidspace | got distracted by work | 10:14 |
| voidspace | sorry | 10:14 |
| voidspace | dimitern: frobware: dooferlad: I guess you've finished | 10:15 |
| dooferlad | voidspace: yep | 10:15 |
| voidspace | dimitern: frobware: dooferlad: my standup then - I made the changes to add a machine.Principals method for my "address picking algorithm change" | 10:16 |
| dimitern | voidspace, :) hey, you didn't miss much | 10:16 |
| voidspace | dimitern: frobware: dooferlad: that made tests pass on CI - it's landed on 1.25 but master is still blocked | 10:16 |
| dimitern | voidspace, nice! yeah - too bad for master :/ I have 3 PRs blocked as well | 10:16 |
| voidspace | I thought I'd finished the implementation of Subnets using the new MAAS API and am waiting on the test harness - will need to sync up with dooferlad for that | 10:17 |
| voidspace | so I'd started on the ListSpaces implementation | 10:17 |
| dimitern | voidspace, please, call it Spaces() | 10:17 |
| voidspace | in the process of that this morning I discovered a flaw in the new Subnets code (wasn't filtering by subnet ID) | 10:17 |
| voidspace | dimitern: ok - I thought ListSpaces was your idea | 10:17 |
| voidspace | but fine | 10:17 |
| dimitern | voidspace, it was an early idea, but since we have Subnets() now, let's keep the consistency in names | 10:17 |
| voidspace | and it was fixing the subnet ID filtering that distracted me | 10:18 |
| voidspace | done now | 10:18 |
| voidspace | dooferlad: have you made a start on the maas test server update? | 10:18 |
| dooferlad | voidspace: yes | 10:18 |
| dimitern | voidspace, cheers | 10:19 |
| dooferlad | voidspace: working on it now. Will ping you when I have something worth sharing | 10:19 |
| voidspace | dooferlad: cool, let me know if you have any questions | 10:19 |
| voidspace | dooferlad: great! | 10:19 |
| voidspace | dooferlad: I'll carry on with Spaces then - can land it as a single branch | 10:19 |
| voidspace | dimitern: environ.Spaces() can just return a map of string -> []SubnetInfo - right? | 10:23 |
| voidspace | dimitern: and should we do anything with the maas "Default Space" (named like that) | 10:23 |
| voidspace | dimitern: we want to make sure our default space is the same as the maas default space | 10:23 |
| voidspace | otherwise nothing works | 10:24 |
| dimitern | voidspace, I think Spaces() needs to return []network.SpaceInfo | 10:26 |
| voidspace | dimitern: ok | 10:27 |
| voidspace | dimitern: all SpaceInfo will have is a name and a []SubnetInfo | 10:27 |
| dimitern | voidspace, and that in turn should have a Name, ProviderId, Subnets []network.Id | 10:27 |
| voidspace | there's no provider id beyond name | 10:27 |
| voidspace | dimitern: you want network.Id for subnets rather than SubnetInfo ? | 10:27 |
| dimitern | voidspace, I don't think we should care about the "Default space" | 10:27 |
| voidspace | dimitern: what do you mean by "not care" - not include it? | 10:28 |
| dimitern | voidspace, well, if we require Spaces() to return the full subnets info, wouldn't that be too restrictive on providers? | 10:28 |
| dimitern | voidspace, no, include it - we just won't use it for openstack | 10:28 |
| voidspace | the only provider we have that can list spaces is maas | 10:28 |
| dimitern | voidspace, for now | 10:28 |
| voidspace | and I suspect that for any provider we implement spaces for, the only way we'll get a slice of subnet IDs is by getting full subnet info anyway | 10:29 |
| dimitern | voidspace, will it be easier to do []SubnetInfo instead? | 10:29 |
| dimitern | voidspace, I mean, SpaceInfo with Subnets []SubnetInfo | 10:29 |
| voidspace | it would mean throwing away less information away | 10:29 |
| voidspace | so marginally less work | 10:29 |
| dimitern | voidspace, ok, let's do it so Spaces() return the full subnets info | 10:30 |
| voidspace | and include default space | 10:30 |
| voidspace | we need to be careful when we populate the model that we don't end up with a "juju default space" and a "maas default space" that are actually the same thing but we treat them differently | 10:31 |
| dimitern | voidspace, well, since a juju space name cannot contain a space, "Default space" will be the ProviderId, the juju name will need to be something like "default-space" I guess | 10:33 |
| voidspace | dimitern: so I need to transform all maas names into juju compatible ones | 10:33 |
| voidspace | dimitern: so ironically the "Provider Id" will be much more human readable than the "Space Name" | 10:34 |
| voidspace | dimitern: why do we have that restriction? | 10:34 |
| dimitern | voidspace, because of constraints and bindings | 10:34 |
| voidspace | ah | 10:34 |
| voidspace | fair enough | 10:34 |
| dimitern | voidspace, the transformation should be just lowercase it and replace spaces with - | 10:35 |
| voidspace | dimitern: sooo... when I fetch the space name from the maas subnet result I need to transform there too | 10:35 |
| voidspace | SubnetInfo.SpaceName has to be the juju space name | 10:35 |
| dimitern | voidspace, yeah I think so | 10:36 |
| voidspace | cool | 10:37 |
| voidspace | dimitern: thanks | 10:37 |
| voidspace | dimitern: hmmm... that's a one way transform though | 10:37 |
| voidspace | dimitern: (i.e. you won't be able to deterministacally go from the SpaceName on a Subnet to the MAAS space) | 10:38 |
| voidspace | dimitern: you can list spaces to see that though | 10:38 |
| voidspace | which will have both | 10:38 |
| voidspace | probably doesn't matter | 10:38 |
| dimitern | voidspace, when talking to maas we always need to use the provider id - we should have it once the space is imported | 10:38 |
| voidspace | dimitern: sure | 10:39 |
| voidspace | dimitern: but if someone sees a SubnetInfo (i.e. output from subnets list) the space name shown there is *not* the maas space name | 10:39 |
| dimitern | voidspace, but I don't think we'll need to do juju space name -> maas space provider id anywhere | 10:39 |
| voidspace | I'm talking about the user - not us | 10:39 |
| dimitern | voidspace, ah, sure - we need to have ProviderSpaceId on SubnetInfo | 10:39 |
| dimitern | voidspace, in addition to SpaceName | 10:40 |
| voidspace | that means a new facade | 10:40 |
| voidspace | as it's a change to the api output | 10:40 |
| voidspace | are you *sure* we need that as it's a lot of extra work | 10:40 |
| voidspace | (well - a moderate amount) | 10:40 |
| dimitern | voidspace, ProviderSpaceId is optional | 10:40 |
| voidspace | I say we should be aware of it but not do it for now | 10:40 |
| dimitern | voidspace, but good point about the versioning | 10:41 |
| voidspace | dimitern: still need a new facade, if someone writes any code depending on that value being present then they need to know which api version to require | 10:41 |
| dimitern | voidspace, that's the client subnets facade you're talking about? | 10:41 |
| voidspace | dimitern: yep | 10:41 |
| voidspace | as it's in 1.25 | 10:41 |
| dimitern | voidspace, yeah, I think before the release we should bump the version for sure | 10:41 |
| voidspace | dimitern: I say we don't need SpaceProviderId on SubnetInfo yet | 10:42 |
| dimitern | voidspace, but for the time being let's just keep it in mind (probably add a card for it though, once your change lands) | 10:42 |
| voidspace | cool | 10:42 |
| voidspace | nobody may actually care in practise, but if they do we can add it | 10:42 |
| dimitern | voidspace, we should be serious about api backwards compatibility | 10:43 |
| dimitern | voidspace, but given the time frame, it can wait for a while | 10:43 |
| voidspace | dimitern: so I think I do need to add SpaceProviderId to SubnetInfo - as it's needed for Spaces | 10:52 |
| voidspace | dimitern: however I don't need to add it to the apiserver SubnetResults | 10:52 |
| dimitern | voidspace, not yet, yep | 10:53 |
| dimitern | voidspace, it can stay within the provider code | 10:53 |
| dimitern | voidspace, and for importing at bootstrap we don't need to modify the api facades at all, since we have access to state at that point | 10:53 |
| voidspace | dimitern: and access to the provider | 10:54 |
| voidspace | dimitern: but we do need the proper provider id, so it will need to be on SubnetInfo (which is what we build the state model from) | 10:55 |
| dimitern | voidspace, we do have access to the provider when we have the environ config | 10:56 |
| dimitern | voidspace, network.SubnetInfo != params.SubnetInfo btw exactly for that reason | 10:56 |
| voidspace | yep, understood | 10:57 |
| mup | Bug #1516975 opened: Incompatible version formats <juju-core:New> <https://launchpad.net/bugs/1516975> | 11:02 |
| mup | Bug #1516975 changed: Incompatible version formats <juju-core:New> <https://launchpad.net/bugs/1516975> | 11:11 |
| mup | Bug #1516977 opened: juju upgrade-juju should guess version number <juju-core:New> <https://launchpad.net/bugs/1516977> | 11:14 |
| mup | Bug #1516977 changed: juju upgrade-juju should guess version number <juju-core:New> <https://launchpad.net/bugs/1516977> | 11:26 |
| mup | Bug #1516975 opened: Incompatible version formats <juju-core:New> <https://launchpad.net/bugs/1516975> | 11:26 |
| mup | Bug #1516975 changed: Incompatible version formats <juju-core:Invalid> <https://launchpad.net/bugs/1516975> | 11:32 |
| mup | Bug #1516977 opened: juju upgrade-juju should guess version number <juju-core:New> <https://launchpad.net/bugs/1516977> | 11:32 |
| mup | Bug #1516989 opened: juju status <service_name> broken <juju-core:New> <https://launchpad.net/bugs/1516989> | 11:44 |
| fwereade | straw poll: `type NotifyChan <-chan struct{}`, or `type NotifyChannel <-chan struct{}` | 13:02 |
| fwereade | jam, dimitern, frobware, anyone? ^^ | 13:03 |
| dimitern | frobware, I'd vote for the first one | 13:08 |
| dimitern | sorry :) I meant fwereade ^^ | 13:08 |
| fwereade | dimitern, cheers | 13:09 |
| frobware | dimitern, fwereade: for me the latter. :) | 13:17 |
| frobware | fwereade, speaking it out loud (in my head) I'm talking about a "channel" | 13:18 |
| dimitern | frobware, yeah, but the type name is "chan" and it's more common in the go code base to use Chan vs Channel | 13:20 |
| fwereade | dammit, now it's even again, if someone wants to tie-break? | 13:22 |
| fwereade | I do favour Chan myself but can't really muster up very strong arguments either way | 13:23 |
| perrito666 | I would vote for the seccond, there is no sense in adding the type to the name of something in a typed language | 13:23 |
| dimitern | fwereade, frankly, I don't care that much :) you can count me towards Channel if it helps | 13:23 |
| fwereade | Channel it is then, thanks all | 13:24 |
| fwereade | and: dimitern, frobware, perrito666: can I trouble any of you for reviews of http://reviews.vapour.ws/r/3143/ and http://reviews.vapour.ws/r/3146/ please? | 13:25 |
| fwereade | if I can get LGTMs there I can apply the various fixes for the pipeline to http://reviews.vapour.ws/r/3147/ and land in one fell swoop | 13:26 |
| dimitern | fwereade, I'll have a look shortly | 13:27 |
| fwereade | 3143 has already been looked at and I *think* just needs an LGTM and/or second opinion on the open issue | 13:27 |
| fwereade | 3146 is just a copy-code-and-fix-imports | 13:27 |
| fwereade | dimitern, tyvm | 13:27 |
| fwereade | frobware, opinion on thumper's comment at http://reviews.vapour.ws/r/3143/diff/3/?file=159341#file159341line96 ? | 13:48 |
| fwereade | frobware, am inclined to drop the issue but if anyone can tell me *why* it's bad I will change it | 13:48 |
| frobware | fwereade, looking | 13:50 |
| frobware | fwereade, plan.Init is actively populated with workers at this stage? | 13:54 |
| fwereade | frobware, yeah | 13:55 |
| fwereade | frobware, ha! some asshole could change Init once the func's returned | 13:55 |
| fwereade | frobware, thanks | 13:55 |
| dooferlad | dimitern, frobware, voidspace: https://plus.google.com/hangouts/_/canonical.com/maas-juju-net | 14:02 |
| dimitern | dooferlad, omw 2m | 14:02 |
| mup | Bug #1516975 opened: Incompatible version formats <juju-core:New> <https://launchpad.net/bugs/1516975> | 14:09 |
| voidspace | dooferlad: sooo... | 14:46 |
| dooferlad | voidspace: yep? | 14:46 |
| voidspace | dooferlad: I'll be changing my implementation to call the /node/{id}/ endpoint which now includes subnet information in the output | 14:46 |
| voidspace | dooferlad: which the test server may or may not already support - probably not | 14:47 |
| dooferlad | no, not yet | 14:47 |
| voidspace | dooferlad: so if you could include that in your test server work that would be wonderful :-) | 14:47 |
| dooferlad | voidspace: sure | 14:47 |
| voidspace | thanks | 14:47 |
| natefinch | rofl.... the output for juju run is sorted by machineID... alphabetically... i.e. 1, 10, 11, 12, 2, 3, 4 | 14:56 |
| mattyw | katco, not merging lxd in master? I'm excited for it to happen though | 15:07 |
| mup | Bug #1517076 opened: juju run output is sorted by machine id alphabetically not numerically <juju-core:New> <https://launchpad.net/bugs/1517076> | 15:15 |
| dooferlad | voidspace: this is more involved than just subnets because they depend on fabrics and VLANs. Fun :-| | 15:16 |
| voidspace | dooferlad: we're not initially going to be using fabrics and vlans though | 15:16 |
| voidspace | dooferlad: so even if they *should* appear in json output you can restrict the test server to just stuff that we're using | 15:16 |
| voidspace | when we need fabrics and vlans we can add them | 15:17 |
| dooferlad | voidspace: hmm, OK | 15:17 |
| voidspace | test server support doesn't need to be complete | 15:17 |
| dooferlad | voidspace: I will just dump out some sensible defaults | 15:17 |
| voidspace | cool | 15:17 |
| voidspace | it doesn't look like I'll need to query a subnet's ip addresses by the way | 15:17 |
| voidspace | if you haven't done that yet | 15:17 |
| voidspace | if you have there's no harm in keeping it | 15:17 |
| dooferlad | voidspace: Oh, I haven't got the basics down yet, but ignoring VLANs removes quite a chunk of work. | 15:18 |
| voidspace | yay \o/ | 15:18 |
| dimitern | fwereade, sorry, I just finished a call now and managed to push first of your reviews | 15:23 |
| fwereade | dimitern, np, I've been tussling with worker/environ again | 15:23 |
| katco | mattyw: we're merging lxd into master. waiting for bless from ci | 15:27 |
| fwereade | dimitern, and, thanks for the detailed review: I'm not sure I'll be making any code changes there, but there's no harm in making the comments less stupid | 15:27 |
| dimitern | fwereade, and the other one is done - I hope the reviews are useful :) | 15:28 |
| dimitern | fwereade, yep +1 | 15:28 |
| dimitern | katco, hey, any idea about that blocker bug? didn't we decide to rollback issues like that.. | 15:29 |
| katco | dimitern: we're going to try and get a fix in before EOD today, if not we'll revert | 15:31 |
| mattyw | katco, much excite ;) | 15:35 |
| katco | mattyw: :) | 15:35 |
| dimitern | katco, ok, thumbs up then :) | 15:38 |
| mup | Bug #1517092 opened: [xenial] libgo panic doing a bootstrap on ARM64 <arm64> <bootstrap> <xenial> <juju-core:New> <https://launchpad.net/bugs/1517092> | 15:45 |
| mup | Bug #1517092 changed: [xenial] libgo panic doing a bootstrap on ARM64 <arm64> <bootstrap> <xenial> <juju-core:New> <https://launchpad.net/bugs/1517092> | 15:48 |
| mup | Bug #1517092 opened: [xenial] libgo panic doing a bootstrap on ARM64 <arm64> <bootstrap> <xenial> <juju-core:New> <https://launchpad.net/bugs/1517092> | 15:54 |
| voidspace | dimitern: frobware: dooferlad: openstack hangout? | 16:33 |
| dooferlad | voidspace: we are skipping today I think | 16:34 |
| voidspace | dooferlad: no0pe | 16:34 |
| voidspace | *nope | 16:34 |
| voidspace | dooferlad: we skipped the second one last week | 16:34 |
| dooferlad | voidspace: and at this mornings hangout we discussed canceling this one | 16:35 |
| dooferlad | voidspace: which I realise you weren't at | 16:35 |
| dooferlad | voidspace: so, we should have mentioned that! I guess it should have been canceled in our calendars as well. frobware, dimitern? | 16:36 |
| voidspace | dooferlad: dimitern and the open stack guys are here | 16:36 |
| voidspace | but it's a low key discussion | 16:36 |
| voidspace | dooferlad: probably no harm in you skipping | 16:37 |
| natefinch | if we juju add-machine and then juju deploy, shouldn't the deployed unit get placed on the existing clean machine? | 16:45 |
| natefinch | i.e. instead of having deploy add another machine | 16:45 |
| natefinch | fwereade: ^ | 16:45 |
| dooferlad | voidspace: https://code.launchpad.net/~dooferlad/gomaasapi/subnets | 16:50 |
| dooferlad | voidspace: I can remove most of the VLAN code (untested) and propose a merge now, or you can just use what is there until I have finished up vlans, spaces and subnets. Shouldn't take long now. | 16:51 |
| voidspace | dooferlad: I can start using what you've got | 16:52 |
| voidspace | dooferlad: I'm "retooling" to use the node api instead of subnets plus addresses for when we're filtering by node id | 16:53 |
| voidspace | dooferlad: that's almost done and I have the start of maasEnviron.Spaces() too | 16:53 |
| voidspace | dooferlad: so plenty to be getting on with, but I'll need this code "real-soon-now" | 16:53 |
| voidspace | dooferlad: if I need it before you're done I'll use your branch until it lands | 16:53 |
| dooferlad | voidspace: sounds good. So far I just have basic get/post/put/delete support for subnets. I need to integrate subnets into nodes, add op=?? (if you need that) etc. | 16:55 |
| voidspace | I don't need ip_addresses now | 16:55 |
| voidspace | I still need unreserved_ranges | 16:56 |
| cherylj | sinzui: for the 1.26-alpha2 release notes, should they just be appended to the 1.26.0 release notes doc? | 17:11 |
| sinzui | cherylj: yes please | 17:11 |
| cherylj | sinzui: thanks! | 17:11 |
| fwereade | natefinch, assuming constraints match hardware characteristics, yes | 17:12 |
| natefinch | fwereade: was not seeing that happen last night on 1.25 | 17:13 |
| fwereade | natefinch, I don't think I have the mental bandwidth to do more than say "that sounds like a bug then" | 17:14 |
| natefinch | fwereade: no problem, just wanted to confirm that it really should be putting the unit on the existing machine, assuming the machine would otherwise be ok. | 17:15 |
| natefinch | (clean, matches constraints, etc) | 17:15 |
| === akhavr1 is now known as akhavr | ||
| marcoceppi | cherylj: we're back to power8 | 18:09 |
| marcoceppi | it's no longer a proxy issue | 18:09 |
| marcoceppi | we're getting a machine-0 log in the next 30 mins | 18:09 |
| === mbarnett` is now known as mbarnett | ||
| katco | natefinch: how's bug fix coming? | 19:37 |
| natefinch | katco: having some trouble reproing... running CI test s manually now to see if I can see it happen | 19:39 |
| katco | natefinch: k, lmk what happens. maybe menn0 did fix it :) | 19:39 |
| natefinch | that would be cool :) | 19:40 |
| natefinch | mgz: you around? | 20:06 |
| natefinch | or abentley? | 20:06 |
| abentley | natefinch: Hi. | 20:07 |
| natefinch | I'm looking at the jes CI failure on master... but when I try to run it I get provider validation failed: invalid EC2 provider config: environment has no access-key or secret-key | 20:07 |
| natefinch | this is when it's trying to do create-environment on top of the controller environment | 20:08 |
| natefinch | ...obviously the controller environment was created fine with an access key and secret key | 20:08 |
| abentley | natefinch: I could be wrong, but I don't think the controller environment provider config is used to create the hosted environments. | 20:12 |
| natefinch | thumper, menn0: is there a trick to getting the jes CI test to run? It seems to be failing when it tries to create-environment on top of the controller environment, saying it can't find EC2 keys | 20:13 |
| thumper | natefinch: you need to give it config for the environment, which includes cloud credentials | 20:13 |
| abentley | natefinch: Which jes test do you mean? | 20:14 |
| natefinch | thumper: I did... it bootstraps the controller environment just fine, then fails to create the child environment (or whatever we're calling them) | 20:15 |
| natefinch | abentley: assess_jes_deploy | 20:15 |
| thumper | did you pass the config through to the create environment call? | 20:16 |
| natefinch | thumper: I don't know? I gave the script the CLI args it asked for, and it didn't say I was missing any | 20:17 |
| thumper | hosted environments are what we are calling them | 20:17 |
| abentley | natefinch: Does environments.yaml contain access-key and secret-key for the "env" you specified? | 20:18 |
| natefinch | abentley: yes. Like I said, it was able to bootstrap the controller environment, so obviously those exist and are correct (also I can bootstrap that environment manually). | 20:20 |
| menn0 | natefinch: assess_jes_deploy worked for me but I had to hack it a little to do an --upload-tools so it would use juju from my machine | 20:21 |
| * menn0 checks what he did | 20:21 | |
| thumper | natefinch: I'm not sure how the ci script creates the hosted environment | 20:21 |
| abentley | natefinch: Not obviously. Perhaps bootstrap respects environment variables and create-environment does not, for example. | 20:21 |
| menn0 | abentley, natefinch: I don't have any EC2 related env vars set | 20:23 |
| menn0 | abentley, natefinch: here's what I did: ./assess_jes_deploy.py menn0-ec2 ~/tmp/workspace/bin/juju ~/tmp/workspace/logs menn0-testing | 20:23 |
| menn0 | menn0-ec2 is an EC2 env defined in my environments.yaml | 20:24 |
| menn0 | menn0-testing is the name of an env that the test will create, cloning the settings from menn0-ec2 | 20:24 |
| menn0 | ~/tmp/workspace/bin/juju is the path to the juju binary (jujud etc are next to it in the same directory) | 20:25 |
| natefinch | menn0: that's what I did, too | 20:25 |
| menn0 | ~/tmp/workspace/logs is where I asked for the artifacts to go | 20:25 |
| menn0 | natefinch: I also modified assess_jes_deploy.py so that the uploadTools arg to boot_context() is True instead of False | 20:27 |
| menn0 | but I don't think that will cause the problem you're seeing | 20:27 |
| menn0 | natefinch: maybe check your env for EC2 variables? Maybe there's some set that are causing a problem. | 20:27 |
| menn0 | natefinch: try "set | grep -e AWS -e EC2" | 20:29 |
| natefinch | hmm, so I do have the AWS keys in my environment | 20:29 |
| natefinch | maybe that's the problem | 20:29 |
| menn0 | natefinch: yep, try removing them | 20:29 |
| natefinch | or rather, lack of them in the environments.yaml | 20:32 |
| menn0 | natefinch: that makes even more sense | 20:41 |
| menn0 | I imagine the AWS keys will need to be in environments.yaml in order for create-environment to work | 20:42 |
| natefinch | gah, now it's giving me "failed to create new environment: admin-secret should never be written to the state" sigh | 20:46 |
| thumper | natefinch: I bet the config from environments.yaml is just being copied, try not explicitly setting admin-secret in the environments.yaml | 21:02 |
| thumper | actually, create-environment should read the environment vars | 21:02 |
| natefinch | thumper: maybe the script is stripping out the env vars? | 21:04 |
| * natefinch shrugs | 21:04 | |
| natefinch | I can try doing it manually when the script is finished (this is a long-ass test) | 21:04 |
| * thumper shrugs | 21:04 | |
| natefinch | ahh, wondrous exceptions | 21:06 |
| natefinch | OSError: [Errno 17] File exists: '../logs/machine-0' | 21:06 |
| perrito666 | tautological errors, next one should be file is file | 21:07 |
| natefinch | lol, I think the CI test failed while trying to dump logs | 21:14 |
| natefinch | thanks, exceptions! | 21:14 |
| thumper | quiet expectations | 21:14 |
| natefinch | os.mkdir(machine_dir) | 21:14 |
| natefinch | so after 15 minutes of running the test... it fails because the directory it was trying to create... existed. Sigh | 21:17 |
| menn0 | natefinch: I wonder if mgz's changes to grab logs for each environment is trying to write all the logs into the same place | 21:18 |
| natefinch | hmm could be, though it was trying to create machine-0 ... do we have a machine-0 in the host environment? | 21:18 |
| perrito666 | yes, that is a very annoying characteristic of CI tests, they assume a pristine env | 21:22 |
| mgz | menn0: I did not commit my change yet | 21:27 |
| mgz | CI tends to just be unforgiving about expected start state | 21:28 |
| menn0 | mgz: ah right | 21:28 |
| menn0 | so it's just that natefinch needs to clear the artifacts directory. there's probably stuff from a previous attempt hanging around. | 21:28 |
| mgz | I need to restart for hangouts, brb | 21:30 |
| natefinch | thanks, retrying with empty logs dir | 21:35 |
| natefinch | um hmm.. weird... cannot run instances: Your quota allows for 0 more running instance(s). You requested at least 1 (InstanceLimitExceeded) | 21:52 |
| wallyworld | menn0: do we still need to use st.docID(localid) when creating a doc to insert into a collection, or is the prefixing of the doc id with env-uuid automatic now? | 21:53 |
| wallyworld | everything in state still seems to use st.docID() | 21:53 |
| menn0 | wallyworld: it's not necessary any more | 21:54 |
| wallyworld | awedome, ty | 21:54 |
| menn0 | wallyworld: we can remove all the calls | 21:54 |
| menn0 | wallyworld: I've got a tech debt card for that | 21:54 |
| wallyworld | yay, ok | 21:54 |
| natefinch | katco: I'm not going to be able to figure out this bug before dinner. I have time after dinner, but I've just been strugging with CI too much | 21:54 |
| menn0 | but you know how it is | 21:54 |
| katco | natefinch: ok, i'll discuss in the release meeting. can you log where you're at somewhere | 21:55 |
| katco | natefinch: that i can look at? | 21:55 |
| katco | axw: wallyworld: does the new azure provider use simplestreams? | 21:56 |
| wallyworld | katco: no | 21:56 |
| wallyworld | it queries the cloud directly | 21:56 |
| katco | alexisb: ^^ | 21:56 |
| wallyworld | to look up images ids | 21:56 |
| katco | wallyworld: ty | 21:56 |
| wallyworld | katco: i already told alexisb taht | 21:56 |
| natefinch | katco: not a lot to say. Couldn't repro manually, CI hasn't gotten through the test yet (each attempt is like 20 minutes) | 21:59 |
| natefinch | katco: updated the bug: https://bugs.launchpad.net/juju-core/+bug/1516144 | 21:59 |
| mup | Bug #1516144: Cannot deploy charms in jes envs <blocker> <charms> <ci> <regression> <juju-core:Fix Committed by menno.smits> <https://launchpad.net/bugs/1516144> | 21:59 |
| === natefinch is now known as natefinch-afk | ||
| katco | natefinch: ok | 21:59 |
| katco | wwitzel3: ericsnow_: any updates on your end? | 22:20 |
| menn0 | thumper: review pls: http://reviews.vapour.ws/r/3169/ | 22:21 |
| * thumper looks | 22:21 | |
| ericsnow_ | katco: patch should be done in the next little while (based on Nate's patch + tests) | 22:22 |
| katco | ericsnow_: cool. demonstrably addresses memory issue? | 22:22 |
| ericsnow_ | katco: yes | 22:22 |
| perrito666 | super, a bit of rain and power starts doing funny stuff | 22:26 |
| menn0 | thumper: thanks | 22:28 |
| sinzui | katco: cherylj : Do you have time to review http://reviews.vapour.ws/r/3170/ | 22:47 |
| wwitzel3 | katco: not yet, I'll be working on it tonight to try and at least get past this stupid series issue. | 22:56 |
| katco | wwitzel3: ok | 22:56 |
| wwitzel3 | katco: my plan was to bug someone who is starting their day to take a look at ti with me | 22:56 |
| katco | wwitzel3: not a bad idea. alexis is also going to see if jam or fwereade have any insights | 22:56 |
| wwitzel3 | katco: yeah, that'd be great. I was going to bug people after Jessa and I have dinner. | 22:57 |
| katco | wwitzel3: k sounds good. say hi to natefinch-afk; he'll be working on trying to repo the master blocker tonight :p | 22:58 |
| katco | repro rather | 22:58 |
| wwitzel3 | :) | 23:01 |
| alexisb | thumper, wallyworld, ^^^ if someone is around when wwitzel3 is back on it would be nice to have a AUS/NZ timezone person to bounce ideas off of | 23:07 |
| wallyworld | sure | 23:07 |
| === ericsnow_ is now known as ericsnow | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!