| menn0 | thumper: ping? | 00:18 |
|---|---|---|
| thumper | otp | 00:18 |
| menn0 | thumper: kk | 00:18 |
| katco | anastasiamac_: ping | 00:21 |
| thumper | menn0: ok, back but need food | 00:59 |
| thumper | whazzup? | 00:59 |
| * thumper finds the tag "fallout" amusing | 00:59 | |
| * thumper needs food badly | 01:00 | |
| menn0 | thumper: I just finished lunch. let me know when you're available | 01:20 |
| ericsnow | can anyone tell me if wwitzel3 and I need to implement storage for the new GCE provider? | 01:20 |
| ericsnow | my understanding is that we don't | 01:20 |
| thumper | menn0: my lunch is cooking but I have a few minutes now | 01:22 |
| menn0 | thumper: ok | 01:23 |
| menn0 | thumper: so this maas issue is that since dimiter's big address handling change | 01:23 |
| menn0 | thumper: no state server thinks it is the master any more | 01:23 |
| thumper | hahaha | 01:23 |
| thumper | oops | 01:23 |
| thumper | why? | 01:24 |
| menn0 | in mongo.IsMaster | 01:24 |
| menn0 | the address for the replicaset master is compared against the machine's internal address | 01:24 |
| menn0 | if they match then IsMaster returns true | 01:24 |
| menn0 | but they no longer match | 01:24 |
| thumper | can we compare across all addreses for the machine? | 01:25 |
| menn0 | it seems on maas the replicaset master address comes back as the DNS address of the host. e.g. juju-qa-maas-node-29.maas | 01:25 |
| menn0 | but the "best" internal address that it gets compared against is an IP | 01:26 |
| menn0 | I have a fix which does just that | 01:26 |
| menn0 | I just wanted to check that you thought it was a sane idea | 01:26 |
| menn0 | I guess there's a risk of 2 machines thinking they are master | 01:27 |
| thumper | a fix which compares against all? | 01:27 |
| menn0 | yes | 01:27 |
| thumper | it is unlikely to cause two to think they are master will it? | 01:27 |
| menn0 | if the replicaset master addr comes back as say "localhost" or some machine/link local address | 01:27 |
| menn0 | and the machine also has that in it's list | 01:27 |
| menn0 | but I don't think that's likely because I think link local addresses are already being filtered out | 01:28 |
| * thumper thinks | 01:28 | |
| thumper | I say "it may well fix it and doesn't look like it'll hurt, and whoever is up next can back it out and fix another way if they are so inclined" | 01:28 |
| thumper | so do it | 01:29 |
| menn0 | cool | 01:29 |
| menn0 | i'll make sure dimiter knows what i've done so that he can verify | 01:29 |
| * thumper nods | 01:29 | |
| menn0 | there might also be another way to skin this cat that he knows about | 01:29 |
| * menn0 thought he might actually be able to commit something today... | 01:30 | |
| menn0 | (that wasn't a CI unblocker) | 01:30 |
| waigani | menn0: the mover of blocks | 01:31 |
| menn0 | my 1 year old son is good at moving blocks | 01:31 |
| waigani | must be in the genes | 01:32 |
| thumper | ha | 01:32 |
| anastasiamac | menn0: take "the mover of blocks", my one would have been "meen0: the unblocker" :) | 01:40 |
| menn0 | thumper: here's that fix: http://reviews.vapour.ws/r/647/ | 01:55 |
| * thumper looks | 01:55 | |
| thumper | the unblockenator | 01:56 |
| menn0 | unblockenologist | 01:56 |
| menn0 | thumper: this fix is for 1.21 | 01:56 |
| menn0 | thumper: i'll forward port it once it's in | 01:57 |
| thumper | shipit | 01:57 |
| anastasiamac | menn0: i think that u r certainly turning unblocking into an art more than a science :-) of course, if u r happy with the title.. | 01:59 |
| anastasiamac | thumper: menn0: there should be a reward for unblocking CI the most.. | 01:59 |
| menn0 | beer! | 01:59 |
| menn0 | actually scotch might be more appropriate... | 01:59 |
| anastasiamac | menn0: as suprising as it may be, not everyone will be encouraged by beer ... | 02:00 |
| anastasiamac | menn0: or scotch | 02:00 |
| waigani | menn0 will be | 02:00 |
| anastasiamac | menn0: but certainly a start | 02:00 |
| thumper | menn0: what sort of scotch? | 02:00 |
| * thumper is not a fan | 02:00 | |
| menn0 | thumper: I like less challenging single malts | 02:01 |
| menn0 | thumper: I don't really go for the really smoky/peaty ones | 02:01 |
| thumper | menn0: how is scotch different from whiskey?> | 02:02 |
| menn0 | thumper: scotch is "scotch whiskey" ... whiskey from Scotland | 02:03 |
| thumper | ah | 02:04 |
| katco | thumper: hey thank you again for green-lighting that branch. i'll have more things landing in the coming days to get it into shape. | 02:27 |
| thumper | katco: ack | 02:27 |
| katco | thumper: ? | 02:27 |
| katco | thumper: ack as in TCP/IP ack? | 02:28 |
| thumper | katco: that is a general positive response "ok, got it" | 02:28 |
| thumper | yes | 02:28 |
| katco | thumper: ah ok :) | 02:28 |
| thumper | sorry, more irc specific geekiness | 02:28 |
| katco | thumper: you'll be happy to know that the stderr flag is coming back out now that machine agent is refactored | 02:28 |
| * katco enjoys geekiness, just wanted to make sure ;) | 02:28 | |
| * thumper nods | 02:31 | |
| thumper | I can hear the girls watching avengers... again... | 02:32 |
| anastasiamac | anyone could have a look at https://github.com/juju/names/pull/35?... with a pretty plz? | 02:38 |
| anastasiamac | waigani: ^^ | 02:38 |
| anastasiamac | thumper: i've heard avangers r beta than lion king :) | 02:40 |
| jw4 | anastasiamac: I'm a little cautious about reusing the validUserPart regex if it just *happens* to co-incide with the charm usage | 02:44 |
| jw4 | anastasiamac: is that usage semantically correct too? | 02:44 |
| * jw4 breaks for supper - sorry :) | 02:46 | |
| waigani | jw4: it's not exported so not intended for reuse, right? anastasiamac? | 02:46 |
| jw4 | waigani: I just mean reusing it in charm.go from user.go | 02:46 |
| * jw4 leaves for real this time | 02:47 | |
| anastasiamac | waigani: not intented for re-use outside but m re-using it in names itself | 02:48 |
| anastasiamac | waigani: should I not? | 02:48 |
| anastasiamac | waigani: if user reg ex changes for whatever reason, i'd like my part to still identify valid user | 02:49 |
| waigani | ah right, well, the definition of schema in the code is // schema:~user/series/name-revision | 02:49 |
| menn0 | ok fixes for the CI blocker merged into 1.21 and master | 02:54 |
| menn0 | re-enabling the build-revision jenkins job now | 02:54 |
| mattyw | morning all | 02:54 |
| waigani | anastasiamac: so there would be an issue if the format of the "user" in the schema and the "user" in the validation functions changed. But, I don't see why that would happen, and if the format changes, you'd have problems regardless and given charm.go is in the names package I think it's fine for there to be a package level "user" that it uses | 02:54 |
| waigani | anastasiamac: so, LGTM from me. | 02:55 |
| anastasiamac | waigani: thnx :-) | 02:56 |
| jw4 | anastasiamac: and LGTM from me - I didn't know the definition of the schema used the ~user part :) | 02:59 |
| anastasiamac | thnx jw4 :) and here I thought u were going to leave for real... | 02:59 |
| jw4 | lol | 03:00 |
| jw4 | confession: I'm actually BACK | 03:00 |
| jw4 | I scarfed | 03:00 |
| * thumper looks at anastasiamac's names branch | 03:01 | |
| thumper | anastasiamac: just a few easy tweaks | 03:03 |
| jog | menn0, looks like build revision 2179 has your fix for the MaaS upgrade and is being run through CI now | 03:10 |
| menn0 | jog: yep | 03:12 |
| menn0 | jog: i'm fairly confident it'll pass now | 03:12 |
| jog | menn0, are you done with finfolk? | 03:12 |
| menn0 | I am | 03:13 |
| jog | I should stop the server that running there, so this revision build can run when it gets to that test | 03:13 |
| menn0 | only the MAAS server is running now | 03:13 |
| menn0 | jog: I killed the other machine | 03:14 |
| menn0 | jog: but please check that everything is in order | 03:14 |
| menn0 | jog: I've cleaned up what I was using | 03:15 |
| * menn0 heads out to get some groceries | 03:15 | |
| jog | menn0, thanks! and yeah it's just the MaaS server that we shutdown | 03:15 |
| jog | menn0, thanks for the quick help on this one! | 03:15 |
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| anastasiamac | thumper: about separate var blocks... | 03:29 |
| anastasiamac | thumper: wanted to group exported vars vs non-exported... | 03:29 |
| anastasiamac | thumper: u don't like this grouping? | 03:29 |
| anastasiamac | thumper: one var block for all is beta? | 03:29 |
| thumper | I don't see why they need to be separated | 03:36 |
| thumper | exported vars have comments | 03:36 |
| thumper | internal ones don't | 03:36 |
| thumper | the comments are enough separation I think | 03:36 |
| thumper | oh my god | 03:39 |
| thumper | this coffee is good | 03:39 |
| thumper | I feel I may need another real soon now | 03:39 |
| anastasiamac | thumper: k since u have found a gr8 coffee, I'll put vars in one block... | 03:40 |
| thumper | waigani: you can't land stuff until this page: https://bugs.launchpad.net/juju-core/+bugs?field.tag=ci+regression&field.tags_combinator=ALL has no criticals | 03:40 |
| thumper | didn't find... made | 03:40 |
| waigani | thumper: good to know, I was using a different filter on lp | 03:41 |
| thumper | the tags stay there until CI passes, then it removes them | 03:41 |
| thumper | that is when master is open for landing again | 03:41 |
| jw4 | thumper: I thought it was only Critical though? And not including Fix Released? I shortened that to: http://goo.gl/4zd1e9 | 03:42 |
| thumper | jw4: it is, that's why I said no criticals | 03:43 |
| jw4 | thumper: doh :) | 03:43 |
| anastasiamac | thumper: if u made a gr8 coffee, does it mean u r k with me merging my PR into names? | 03:43 |
| thumper | jw4: I saved that page, so now I just start typing "regression" and hit enter | 03:43 |
| jw4 | thumper: nice | 03:43 |
| thumper | anastasiamac: do you feel strongly that they should be separate? | 03:44 |
| anastasiamac | thumper: not strongly enough :) | 03:44 |
| anastasiamac | thumper: they r distinct | 03:44 |
| anastasiamac | thumper: whether we r separating them otherwise si a style | 03:45 |
| anastasiamac | thumper: I am pendantic and will separate and teeth things apart until I get to nano levels | 03:45 |
| thumper | anastasiamac: I'm happy that the local and exported vars are grouped within the var statement | 03:46 |
| thumper | but we don't need multiple var statements | 03:46 |
| anastasiamac | thumper: excellent! I merge then? :P | 03:46 |
| thumper | anastasiamac: are they grouped yet? | 03:46 |
| * thumper refreshes | 03:47 | |
| thumper | sorry hadn't been looking | 03:47 |
| anastasiamac | thumper: they r :) | 03:47 |
| thumper | line 36 of charm.go | 03:48 |
| thumper | they are almost... | 03:48 |
| anastasiamac | thumper: ur coffee must b really good! m on it :-) | 03:49 |
| thumper | unfortunately my coffee is finished | 03:49 |
| thumper | I did consider making a big cup 4 shot one | 03:49 |
| thumper | but decided against it | 03:49 |
| thumper | perhaps I should have | 03:49 |
| waigani | anastasiamac: merge, quick! while you've still got a chance! | 03:49 |
| anastasiamac | thumper: should be perfect now but I'll re-order it for mattyw | 03:51 |
| mattyw | anastasiamac, waigani sorry - I jumped in at the wrong/ right time :) | 03:51 |
| thumper | mattyw: surely URI not URL | 03:52 |
| anastasiamac | waigani: m weaning myself off coffee (and onto the coke) so will not b as quick as all these "real coffee" drinkers :D | 03:52 |
| thumper | why no coffee? | 03:52 |
| thumper | that just seems cruel | 03:52 |
| thumper | coffee is so much better for you than coke | 03:53 |
| mattyw | thumper, I think so - but isn't the accepted name CharmURL? | 03:53 |
| thumper | mattyw: probably | 03:53 |
| anastasiamac | thumper: apparently my coffee is not up to wallyworld's standard... so coke it is atm | 03:53 |
| thumper | tut-tut | 03:53 |
| mattyw | I used to despise decent coffee - it felt like a waste of money | 03:53 |
| mattyw | all it took was one trip to Dunedin | 03:53 |
| thumper | mattyw: and now you want to buy an espresso machine? | 03:54 |
| menn0 | jog: thank you for the debugging help | 03:54 |
| mattyw | thumper, thinking about it | 03:55 |
| mattyw | anastasiamac, I'm basically not too fussed about the name | 03:55 |
| jog | menn0, np... the maas upgrade tests should start fairly soon for 2179 | 03:55 |
| mattyw | anastasiamac, but changing the ordering I think is a small change but very useful | 03:56 |
| mattyw | anastasiamac, at least for me :) | 03:56 |
| thumper | I was half joking about URI vs URL | 03:56 |
| anastasiamac | mattyw: the ordering is a bit of a thing for me, actually.. | 03:56 |
| anastasiamac | mattyw: i was hoping to group local and exported vars | 03:57 |
| anastasiamac | mattyw: m look n and may change in a sec :) | 03:57 |
| mattyw | anastasiamac, that makes a lot more sense, to be totally explicit - what confused me was I expected charmStoreSchemaSnippet to be the regex for the whole thing charm url - and then when I read the definition I was suprised | 03:58 |
| anastasiamac | mattyw: ic | 03:59 |
| mattyw | anastasiamac, ordering based on exported or not makes a lot of sense - I'd be happy with just a comment above local and charm store snippet I think | 03:59 |
| mattyw | anastasiamac, although the more I talk about it the more I think it's fine as it is | 03:59 |
| anastasiamac | mattyw: let's talk some more than :) | 03:59 |
| mattyw | anastasiamac, haha | 03:59 |
| anastasiamac | mattyw: well, this area my be confusing | 04:00 |
| anastasiamac | mattyw: and I'd like it to b clear from a glance | 04:00 |
| anastasiamac | mattyw: there is a block comment above the whole of var block | 04:00 |
| mattyw | anastasiamac, ah - I was about to suggest something like that | 04:01 |
| anastasiamac | mattyw: explaining what the whole URL (URI ***looking at thumper***) is | 04:01 |
| mattyw | anastasiamac, yeah - that's amazing - just land it as is - ignore me :) | 04:01 |
| anastasiamac | mattyw: r u sure? | 04:01 |
| mattyw | anastasiamac, I'd be tempted to add a comment above validCharmRegEx saying - this is the regex for the whole CharmURL | 04:02 |
| mattyw | anastasiamac, but then the actual regex basically says that | 04:02 |
| mattyw | anastasiamac, so even that feels redundant | 04:02 |
| mattyw | anastasiamac, I'm definitely in bikeshedding territory now though - just land it :) | 04:03 |
| anastasiamac | mattyw: k. I'll land as is and might come back to it as needed coz m still planning to head to juju/charm with it before even getting to juju/juju... | 04:03 |
| * anastasiamac landed tiny PR | 04:05 | |
| mattyw | anastasiamac, tiny PRs are the worst :) | 04:08 |
| thumper | :) | 04:08 |
| mattyw | waigani, ping? | 04:12 |
| waigani | mattyw: pong | 04:33 |
| mattyw | waigani, just looking at http://reviews.vapour.ws/r/474/diff/ -> what is OtherState for in storeManagerStateSuite? | 04:34 |
| waigani | mattyw: it's the state for another env, I should probably rename it to make that clear | 04:34 |
| waigani | mattyw: also that branch is a WIP, I'll be pushing up the latest tomorrow | 04:35 |
| mattyw | waigani, that's what I was going to suggest :) | 04:35 |
| mattyw | waigani, ok cool | 04:35 |
| waigani | mattyw: AND the fam is demanding that I join them for dinner, which I better do unless I want to sleep outside tonight! | 04:36 |
| mattyw | waigani, enjoy! | 04:36 |
| menn0 | jog: the maas upgrade test for 1.21 just passed | 04:42 |
| jog | woo hoo! | 04:42 |
| jw4 | yay | 04:43 |
| jw4 | how long does it usually wait on the "Attempting to connect to 10.0.30.173:22" line? | 04:43 |
| jw4 | menn0: can you mark as fix released or does that need to be someone else? | 04:44 |
| menn0 | jw4: it waits a while.. it's trying to make an API connection as the instance comes up | 04:45 |
| jw4 | menn0: yeah - it seemed to be several minutes | 04:45 |
| menn0 | menn0: I think someone from QA is supposed to do it. jog? | 04:45 |
| jog | jw4, menn0, in this case it's waiting for MaaS to boot a machine... usually around 10 minutes | 04:46 |
| menn0 | jw4: that's what I was seeing while manually testing with maas | 04:46 |
| jw4 | jog: I see | 04:46 |
| jw4 | menn0: cool - so you were testing your changes on the same hardware that's running the tests? | 04:46 |
| menn0 | jog: do you know how CI becomes unblocked? does it require a manual step by someone on the QA team or is it automated based on test results? | 04:47 |
| jw4 | menn0, jog it also looks like we only have one (or limited) hardware groups for maas? | 04:47 |
| jw4 | menn0: I think it's automated once the bug is marked Fix Released, but I could be wrong | 04:47 |
| menn0 | jw4: yeah I was using the host that Jenkins uses for MaaS tests (on KVM) | 04:48 |
| jw4 | menn0: interesting. Cool, but surprising | 04:48 |
| jog | menn0, I believe fixed-released will unblock | 04:48 |
| menn0 | jw4: suprising? | 04:49 |
| menn0 | jog: it's a shame that the "Fix Released" has 2 meanings | 04:50 |
| menn0 | s/ the// | 04:50 |
| menn0 | oh well | 04:50 |
| jw4 | menn0: I guess setting up a maas environment isn't trivial - but it seems like while you were working on finfolk none of the CI tests could run | 04:50 |
| jog | err actually fixed-committed | 04:50 |
| jw4 | jog: I don't think fixed committed will unblock CI? | 04:51 |
| jog | jw4, we're working on fixing that... finfolk was upgrade last week, so we can run multiple environments | 04:51 |
| menn0 | jw4: that's what sinzui told me to do :) he disabled one of the top level CI jobs | 04:51 |
| jw4 | jog, menn0 I see | 04:52 |
| menn0 | jw4: the bug needed fixing and that was the fastest way to get it sorted | 04:52 |
| jw4 | menn0: well (relatively speaking) it WAS lickety split fast | 04:52 |
| menn0 | jw4: i'd like to get my machine set up to do MaaS on KVM locally | 04:52 |
| jw4 | menn0: yeah me too | 04:53 |
| menn0 | jog: yeah I don't think Fix Committed alone is enough to unblock CI | 04:54 |
| jog | it's also possible to downgrade the bug from critical to high and it will unblock | 04:54 |
| menn0 | jog: it's still blocked now and I marked this ticket as Fix Committed quite some time ago | 04:54 |
| menn0 | jog: there must be something else to it | 04:54 |
| jw4 | menn0, jog : I bet if you mark it as fixed released it'll unblock | 04:54 |
| jw4 | menn0: maas-upgrade-trusty-amd64 looks set to pass momentarily too | 04:55 |
| menn0 | jw4: I think you're right but is that actually the correct process? | 04:55 |
| * jw4 shrugs | 04:55 | |
| menn0 | woot! | 04:55 |
| jw4 | that's where I'm lost too | 04:55 |
| jog | shall we wait for the second upgrade test to pass... there are two mass tests one for devel (which already passed) and one for stable maas | 04:55 |
| jog | the upgrade is actually going on now | 04:56 |
| jw4 | jog, yeah - the second one is the one I'm willing on as we watch :) | 04:56 |
| jw4 | woot | 04:58 |
| menn0 | jog: so when do the maas upgrade tests for master run? | 05:05 |
| jog | when a commit is picked up from that branch | 05:05 |
| jog | menn0, did you already apply this fix there? | 05:08 |
| jog | ah yes it looks like you did | 05:08 |
| menn0 | jog: yep I did. I merged them one after the other. | 05:10 |
| menn0 | jog: i'm about to EOD (and I imagine you were supposed to have quite some time ago) | 05:11 |
| jog | menn0, it's building now http://juju-ci.vapour.ws:8080/job/build-revision/2180/console | 05:13 |
| menn0 | jog: ok cool | 05:13 |
| jog | nice and we have a blessed build for 1.21 | 05:15 |
| jog | http://reports.vapour.ws/releases/2179 | 05:15 |
| menn0 | jog: \o/ | 05:17 |
| * menn0 is EOD | 05:25 | |
| jw4 | FWIW sinzui, mgz_, et. al. - I believe https://bugs.launchpad.net/juju-core/+bug/1403200 has passed all tests and deserves to be marked fix released | 05:39 |
| mup | Bug #1403200: maas upgrades do not complete <ci> <maas-provider> <regression> <upgrade-juju> <juju-core:Fix Committed by menno.smits> <juju-core 1.21:Fix Committed by menno.smits> <https://launchpad.net/bugs/1403200> | 05:39 |
| mattyw | davecheney, ping? | 06:03 |
| mattyw | davecheney, you know what - cancel that and ignore me forever | 06:03 |
| * mattyw needs to read docs more carefully | 06:03 | |
| jam1 | morning axw and wallyworld, how are you guys doing? | 06:05 |
| jam1 | axwwallyworld sorry, keep getting dc here if you ansnwered | 06:33 |
| === urulama is now known as urulama|out | ||
| anastasiamac | jam1: axw is off until Jan, I think | 07:02 |
| anastasiamac | jam1: wallyworld is off for the day ;) | 07:03 |
| anastasiamac | jam1: wallyworld will b back tomorrow | 07:03 |
| === liam_ is now known as Guest72494 | ||
| anastasiamac | jam1: did u get my last msgs about axw and wallyworld? | 07:08 |
| === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Bug reports: https://bugs.launchpad.net/juju-core/ | ||
| dimitern | CI no longer blocked | 07:33 |
| dimitern | previously failed PRs re-queued for merging | 07:49 |
| jam1 | anastasiamac: yes, apparently you didn't get mine: | 07:50 |
| jam1 | jam1 | 07:50 |
| jam1 | 09:05 | 07:50 |
| jam1 | anastasiamac: thanks, looking at the calendar it looks like both of them are off today | 07:50 |
| anastasiamac | jam1: yes, b oth r off today | 07:51 |
| anastasiamac | jam1: and ian is back tomorrow :) | 07:51 |
| dimitern | menn0, hey are you around? | 08:11 |
| menn0 | menn0: kinda :) | 08:12 |
| dimitern | menn0, :) | 08:19 |
| dimitern | menn0, so your fix worked | 08:19 |
| dimitern | menn0, thanks for the quick response | 08:20 |
| menn0 | dimitern: no problems. | 08:21 |
| menn0 | dimitern: is it the best fix though? | 08:21 |
| dimitern | menn0, I don't know about the best, but it's fool-proof at least | 08:22 |
| dimitern | menn0, I'll propose a slight fix to change the ordering of addresses returned by maas's instance.Addresses method | 08:23 |
| dimitern | menn0, which will make it slightly faster and in your patch the loop will do a single iteration most of the time | 08:23 |
| * dimitern needs to step out for a while | 08:26 | |
| menn0 | dimitern: that sounds good | 08:27 |
| menn0 | dimitern: that loop doesn't get called that often and there's not going to be huge numbers of addresses to check through so I don't think performance is much of an issue | 08:28 |
| jam1 | hi axw | 09:11 |
| axw | jam1: heya | 09:11 |
| jam1 | mark's in another discussion right now, so I've got some time if you want to give/get feedback on anything | 09:11 |
| axw | jam1: I have only just started looking at comments, nothing really controversial | 09:12 |
| axw | I really don't like count,size but maybe it's just me | 09:12 |
| jam1 | man, I wish I could use VIM to edit Google docs :) | 09:12 |
| jam1 | axw: so what mark really likes is clean, easy to read syntax | 09:12 |
| jam1 | and he feels that : an x, etc add a lot to how hard it is to read a given string | 09:13 |
| axw | jam1: my take on it is that the number doesn't mean anything when you see it first. so then you have to go digging into documentation, rather than it being obvious in the first case (Nx being a fairly universal way of representing a multiplier, I think). but admittedly it doesn't work when you don't have a size | 09:14 |
| axw | jam1: glad to see NFS out of scope :) | 09:16 |
| axw | jam1: "pool" is just the new term for "source"? | 09:27 |
| axw | I don't recall there being talk of pools previously | 09:27 |
| mattyw | dimitern, ping? | 09:38 |
| dimitern | mattyw, hey | 09:38 |
| jam1 | axw: pool is being explicitly fleshed out as a way to start passing extra parameters into the system, without overloading the "—storage" parameter. | 09:46 |
| axw | jam1: yeah, just read over that section a bit more. I like it. | 09:46 |
| axw | jam1: any general feedback/news before I head off? | 09:47 |
| jam1 | axw: I think we're pretty happy with what we've gotten to, and I'm just trying to make sure the current doc is consistent | 09:48 |
| jam1 | axw: we're soliciting feedback at this point (from maas, antes, etc) | 09:48 |
| axw | jam1: cool | 09:48 |
| axw | alright, I'm going to go have a holiday then ;) | 09:49 |
| axw | jam1: thanks, ttyl | 09:49 |
| jam1 | axw: enjoy | 09:51 |
| voidspace | TheMue: dimitern: I'm going to be a few minutes late to standup, sorry | 09:59 |
| dimitern | voidspace, ok, np | 09:59 |
| TheMue | voidspace: ok | 09:59 |
| dimitern | mgz_, hey, do you know when 1.21-beta4 is due? | 10:00 |
| jam1 | dimitern: I'm pretty sure it was due at least a week ago | 10:52 |
| jam1 | Our original promise was 1.21 on Nov 15 | 10:52 |
| jam1 | which we are *way* past. | 10:52 |
| dimitern | jam1, Oh, I see - well with the api-endpoints fix landed it can be release now | 10:55 |
| dimitern | jam1, although during my live testing I discovered an issue fixed on master and not backported to 1.21 which is important | 10:56 |
| dimitern | jam1, I'll file a bug for it and have a chat with sinzui should 1.21-beta4 wait for it | 10:56 |
| jam1 | dimitern: sounds like something that should block, and you've got a couple hours before mgz/sinzui would possibly build a 1.21-beta4 release :) | 10:57 |
| jam1 | dimitern: I'm happy for you to delegate that backport, but if you've found something serious, we should be serious about it. | 10:57 |
| dimitern | jam1, right, now's the time then | 10:58 |
| dimitern | jam1, the issue is apt-get retrying logic is faulty - we're calling cmd.CombinedOutput more than once, which errors out after the first call as Stdout is already set | 10:59 |
| jam1 | dimitern: sounds like a real, but not too hard to fix, bug, rigthH? | 11:00 |
| dimitern | jam1, the fix is in juju/utils/apt, so 1.21 needs to (carefully - as there are about a month of changes in utils since) start using a newer utils | 11:00 |
| jam1 | or we backport to what they are currently using | 11:00 |
| jam1 | yes, it sucks, but it might be less mental overhead | 11:01 |
| * jam1 heads to lunch | 11:04 | |
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| mgz_ | dimitern: yeah, beta4 is overdue, we're trying to release it currently - have got a good rev after your fix backport | 12:30 |
| dimitern | mgz_, there's an issue I discovered during my live tests - apt-get retry logic is not working | 12:31 |
| mgz_ | do you have an idea when it regressed? | 12:31 |
| dimitern | mgz_, which is already fixed on master, but not backported to 1.21 | 12:31 |
| dimitern | mgz_, I know as I fixed it in juju/utils/apt, but 1.21 uses an earlier rev of utils | 12:32 |
| mgz_ | well, certainly backport | 12:32 |
| dimitern | mgz_, should we hit the red button until this lands? | 12:32 |
| mgz_ | but is this a new breakage that wasn't in beta3? | 12:32 |
| dimitern | mgz_, let me check | 12:34 |
| dimitern | mgz_, it was broken since at least alpha3 (or beta2 - not quite sure; the commit log is ambiguous) | 12:38 |
| mgz_ | okay, so I think we try to get your fix for this beta, but it's not the end of the world if we don't | 12:39 |
| dimitern | mgz_, scratch that - alpha3 is more likely | 12:42 |
| dimitern | mgz_, ok, I'll file a bug then and target it | 12:42 |
| * dimitern thinks *everyone* should rebase and merge minor commits before they end up in master | 12:43 | |
| dimitern | or at least be aware they will end up on master and use helpful commit logs - sifting through like 30 commits like "fix dependencies.tsv", "update dependencies.tsv" or "add dependencies of dependencies to dependencies.tsv", are *not* helpful at all to point to *what* changed | 12:44 |
| mgz_ | thanks dimitern | 12:45 |
| === kadams54 is now known as kadams54-away | ||
| dimitern | mgz_, there's a pre-existing bug 1394524 which I now retargeted for 1.21-beta4 | 12:52 |
| mup | Bug #1394524: juju/utils/apt retrying logic is poorly tested and can fail the second time <bootstrap> <juju-core:Fix Committed by dimitern> <juju-core 1.21:In Progress by dimitern> <https://launchpad.net/bugs/1394524> | 12:52 |
| jw4 | ericsnow: ping | 13:25 |
| wallyworld | jam1: sorry, was away today but am online for a short time now | 13:50 |
| natefinch | fwereade: was there a decision about what to do about exposing zones to charms? Are we just going to let charms set their zone in their relation data the old fashioned way? | 14:07 |
| fwereade | natefinch, ah, sorry | 14:07 |
| fwereade | natefinch, we should certainly expose it, but I don't think there's any reason to dump it into relation data by default | 14:08 |
| fwereade | natefinch, those that need it can add it | 14:08 |
| fwereade | natefinch, and personally I would prefer to expose it via $JUJU_AVAILABILITY_ZONE than by tacking it onto unit-get | 14:08 |
| fwereade | natefinch, (and IMO we should not expose lists of zones at this stage -- I'm willing to hear proposals, but the ones I've seen have not been adequate ) | 14:09 |
| natefinch | fwereade: agree on list of zones. There seemed to be no need for that. | 14:09 |
| natefinch | fwereade: how about exposing zone of related units? I think that was in the proposal too, so you can see what zone your DB is in, for example. | 14:10 |
| fwereade | natefinch, strong -1 to that | 14:10 |
| fwereade | natefinch, zone-scoped relations would be kinda cool | 14:10 |
| fwereade | natefinch, but they also bump up against the yuckiness of local-scoped non-subordinate relations | 14:11 |
| fwereade | natefinch, ie they have exactly the same opaque failure modes | 14:11 |
| fwereade | natefinch, and we should figure out how to do them *both* right | 14:11 |
| fwereade | natefinch, *if* charms want to put that info over their relations, ofc we can't stop them | 14:12 |
| fwereade | natefinch, exactly the same in peer rels and pro/req rels | 14:12 |
| fwereade | natefinch, but I don't think it's something we want to make into a feature | 14:12 |
| natefinch | fwereade: ok | 14:12 |
| natefinch | fwereade: that sounds good. | 14:13 |
| natefinch | fwereade: so the spec is now - simply expose zone via $JUJU_AVAILABILITY_ZONE and that's it? | 14:15 |
| fwereade | natefinch, I think that's the MVP, yes ;) | 14:15 |
| natefinch | fwereade: ok :) | 14:16 |
| sinzui | natefinch, do you have a minute to review http://reviews.vapour.ws/r/650/ | 14:24 |
| natefinch | sinzui: ship it! | 14:25 |
| sinzui | thank you natefinch | 14:25 |
| natefinch | wwitzel3: 1:1 in moonstone? | 14:33 |
| ericsnow | jw4: pong? | 15:14 |
| jw4 | ericsnow: morning :) - Hey I've addressed all your issues on PR 616, with two issues asking for your agreement to drop in favor of a TODO : http://reviews.vapour.ws/r/616/ | 15:15 |
| jw4 | ericsnow: care to take a quick gander and drop or object? | 15:15 |
| * ericsnow takes a look | 15:15 | |
| ericsnow | jw4: thanks so much for addressing my concerns. | 15:22 |
| jw4 | ericsnow: thanks for raising them :) | 15:22 |
| ericsnow | jw4: I'm fine with dropping the first one and while I'm not convinced on the second one I guess I'm okay with dropping it for now too | 15:23 |
| ericsnow | jw4: what's the concern with using IsolationSuite | 15:23 |
| ericsnow | jw4: it's not like the mongo suite or something :) | 15:24 |
| jw4 | ericsnow: I think you make a good point in your comments. I was hesitant to pull in a big suite, but I think you're right - IsolationSuite is okay | 15:24 |
| jw4 | ericsnow: I'll do that and clean up the pr and ping you again | 15:25 |
| ericsnow | jw4: yeah, if you look at the code, it doesn't add much but what it does add is super helpful | 15:25 |
| ericsnow | jw4: thanks! | 15:25 |
| jw4 | ericsnow: thanks too | 15:25 |
| ericsnow | jw4: glad to do it | 15:25 |
| jw4 | gah - I missed the window while CI isn't blocked - teh suk | 15:42 |
| === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: 1403546 | ||
| sinzui | natefinch, can you find someone to look into bug 1403546 | 15:53 |
| mup | Bug #1403546: cannot get environment config: invalid series vivid <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1403546> | 15:53 |
| natefinch | oh FFS | 15:54 |
| natefinch | sinzui: the bug description has a typo that makes it hard to understand | 15:56 |
| natefinch | "As vivid really in in streams, hosts that don't know about vivid in ubuntu.csv must still work." | 15:56 |
| natefinch | should that say "vivid really is in streams"? | 15:56 |
| sinzui | natefinch, yes, I will fix it | 15:56 |
| natefinch | sinzui: why do we have vivid in streams but not in ubuntu.csv? ubuntu.csv was how we were going to support new series | 15:57 |
| natefinch | wait... I have vivid in ubuntu.csv | 15:57 |
| sinzui | natefinch, That data is delivered to hosts in updates. note everyone get series knowledge that the same time | 15:58 |
| sinzui | natefinch, since vivid is in devel, we can expect a period of months where we make agents, (Lp did), but the host machine doesn't have the release info yet | 15:59 |
| natefinch | this is quite aggravating, since the whole point of using ubuntu.csv was to avoid this problem. Do you have an idea on how we can fix this? | 16:01 |
| sinzui | natefinch, an entry in ubuntu.csv is canonical (in the real sense of the world), and other series for win, osx, centos, or ubuntu must be accepted. | 16:03 |
| sinzui | natefinch, ubuntu.csv is really about knowing the dates of when series expire, not about every series that will exist | 16:04 |
| * sinzui wonders if the recent failures to build osx clients are the same reason | 16:05 | |
| natefinch | sinzui: the main problem is translating a random series to an OS | 16:07 |
| sinzui | yeah | 16:07 |
| sinzui | natefinch, in the case, if we made a agent, then I think juju should accept it, maybe ignore it. I can run vivid container on these machines though, so the user might want to expect to use the unknown series. | 16:10 |
| ericsnow | perrito666: standup? | 16:21 |
| perrito666 | ericsnow: wjy not_ | 16:22 |
| perrito666 | sinzui: Ill take a look | 16:39 |
| sinzui | perrito666, thank you | 16:40 |
| jam1 | fwereade: natefinch: do we have a spec about default-hook ? | 16:49 |
| fwereade | jam1, 90% sure natefinch wrote one, will have a quick look | 16:49 |
| natefinch | looking | 16:50 |
| fwereade | jam1, natefinch: sorry, can't find it | 16:51 |
| fwereade | jam1, natefinch: bloody google ;) | 16:51 |
| natefinch | jam1, fwereade: I honestly can't remember if one was written... | 16:52 |
| natefinch | jam1, fwereade: does anm email thread count? search for "First customer pain point pull request - default-hook" | 16:53 |
| fwereade | natefinch, yeah, that was what I just found | 16:54 |
| jam1 | natefinch: fwereade: did it land in 1.21? I see it listed in the release notes, but I don't see it in the code yet | 16:54 |
| natefinch | jam1, fwereade: from Aug 15 | 16:54 |
| fwereade | natefinch, afraid it mostly devolved into discussion of something-changed | 16:54 |
| natefinch | jam1. fwereade: it did not land... it shouldn't have been in the notes | 16:54 |
| natefinch | jam1, fwereade: we decided it required juju-min-version (aka feature flags) first | 16:55 |
| natefinch | jam1, fwereade: which moonstone will get to sometime after the holiday break | 16:55 |
| alexisb | jam1, why do you ask | 16:57 |
| voidspace | dimitern: ping | 17:31 |
| dimitern | voidspace, pong | 17:31 |
| voidspace | dimitern: hey, hi | 17:31 |
| voidspace | dimitern: sorry to bother you so late | 17:31 |
| voidspace | dimitern: the topic of filling in AllocatableIPHigh and Low for maas | 17:32 |
| voidspace | dimitern: I've fixed all the other issues from review | 17:32 |
| dimitern | voidspace, np, I have to wait for a meeting anyway :) | 17:32 |
| voidspace | dimitern: currently we're using the MaaS networks api call to get subnet info | 17:32 |
| dimitern | voidspace, right | 17:32 |
| voidspace | dimitern: this *doesn't* include static / dynamic range info | 17:32 |
| voidspace | dimitern: http://maas.ubuntu.com/docs/api.html#networks | 17:32 |
| voidspace | dimitern: nodegroups does | 17:32 |
| dimitern | voidspace, aw ffs.. | 17:33 |
| dimitern | voidspace, true, so we need to implement that as well | 17:33 |
| voidspace | dimitern: so is it ok to use nodegroups? | 17:34 |
| voidspace | dimitern: I can pull the info out of a nodegroups call easily enough | 17:34 |
| voidspace | dimitern: although we can't filter nodegroups by instance id like we can networks | 17:35 |
| dimitern | voidspace, I think we have to use it - that's the only way to get the static range | 17:36 |
| voidspace | dimitern: so subnets should lose the instance id paramter | 17:36 |
| voidspace | dimitern: ok, so I'll make those changes | 17:36 |
| voidspace | dimitern: follow-up branch or on this branch? | 17:36 |
| dimitern | voidspace, cheers! | 17:36 |
| dimitern | voidspace, follow-up is fine | 17:37 |
| voidspace | dimitern: ok | 17:37 |
| voidspace | dimitern: so the current branch is ready I think | 17:37 |
| voidspace | dimitern: I changed the XXX to a TODO so I could land it | 17:37 |
| dimitern | voidspace, let me have a final glance | 17:37 |
| voidspace | dimitern: cool | 17:38 |
| voidspace | dimitern: XXX -> TODO just landed now | 17:38 |
| voidspace | dimitern: I'm going for coffee, bbiab | 17:38 |
| dimitern | voidspace, ok | 17:38 |
| === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: 1403546 1403596 | ||
| sinzui | natefinch, ericsnow sorry, new testing shows an other regression related to cTim for os x 1403596 | 17:42 |
| sinzui | bug 1403596 | 17:42 |
| mup | Bug #1403596: OSX build broken by stat.Ctim undefined <ci> <osx> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1403596> | 17:42 |
| jw4 | natefinch, sinzui : docker fixed a similar bug here https://github.com/andrewsmedina/docker/commit/8b2a7e35c35f894dca0795a4fde9ec0cfe04ce43 | 17:44 |
| jw4 | natefinch, sinzui looks like it's just separate implementations for darwin vs. others | 17:45 |
| sinzui | thank you jw4 | 17:45 |
| dimitern | voidspace, LGTM +2 very small suggestions | 17:45 |
| jw4 | sinzui, natefinch I'll look at this bug but I'm not familiar with the code so if anyone else can jump on it that's fine :) | 17:46 |
| wwitzel3 | anyone know how the default instance type for a provider is selected? | 18:12 |
| natefinch | wwitzel3: I think we have logic that just picks the least expensive of known options | 18:13 |
| voidspace | dimitern: ok | 18:15 |
| voidspace | dimitern: my wife has had to take our next door neighbour to hospital, so I'm on babysitting duty | 18:15 |
| voidspace | dimitern: I'll finish this later on | 18:15 |
| dimitern | voidspace, np, take your time | 18:23 |
| jcastro | rick_h_, do you happen to know luca's plan for the new videos page on jujucharms.com? | 18:30 |
| rick_h_ | jcastro: I know we're supposed to pull them from insights at some point. I've not seen the feed yet | 18:31 |
| rick_h_ | jcastro: now that's just to pull videos for the community page, I'm not aware of a straight 'videos page'. | 18:31 |
| jcastro | right | 18:32 |
| jcastro | I know it's generated | 18:32 |
| jcastro | afaict the "new videos page" is just a generated feed of videos tagged video in wordpress | 18:32 |
| rick_h_ | jcastro: it's on the todo with UX/web team next year along with deprecating out the juju.ubuntu.com domain and such. Most of them are out for the holiday already so not managed to move it forward. | 18:34 |
| jcastro | yeah I was just wondering where it stood on the list. | 18:34 |
| jcastro | like, pre or post-sprint, etc. | 18:34 |
| rick_h_ | top of the new year list. | 18:34 |
| rick_h_ | pre sprint | 18:34 |
| rick_h_ | sprint is 19th and that's for different stuff | 18:35 |
| jcastro | not bad, I like how you roll | 18:35 |
| rick_h_ | I want to kill of juju.ubuntu.com and manage.jujucharms.com (front end) first of next year | 18:35 |
| rick_h_ | was hoping to have it done pre-break but didn't make it | 18:35 |
| jw4 | sinzui, natefinch http://reviews.vapour.ws/r/655/ | 18:35 |
| jw4 | fixes ci blocker bug 1403596 ^^ | 18:38 |
| mup | Bug #1403596: OSX build broken by stat.Ctim undefined <ci> <osx> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1403596> | 18:38 |
| sinzui | thank you very much jw4 | 18:39 |
| jw4 | sinzui: yw | 18:39 |
| jw4 | OCR PTAL : http://reviews.vapour.ws/r/655/ | 18:49 |
| perrito666 | sinzui: upgrade juju for local is something that takes a lot of time? | 18:57 |
| dimitern | ericsnow, perrito666, http://reviews.vapour.ws/r/656/ PTAL - backport the fix for bug 1394524 for 1.21 - it has some changes I'd like to pass by you | 18:58 |
| mup | Bug #1394524: juju/utils/apt retrying logic is poorly tested and can fail the second time <bootstrap> <juju-core:Fix Committed by dimitern> <juju-core 1.21:In Progress by dimitern> <https://launchpad.net/bugs/1394524> | 18:58 |
| sinzui | perrito666, no, usually less than 5 minute | 18:59 |
| perrito666 | mmm, let me wipe all this | 18:59 |
| perrito666 | sinzui: to replicate I am juju bootstrap --series=precise --upload-tools and then doing an upgrade, I am in the right path_ | 19:00 |
| perrito666 | ? | 19:00 |
| perrito666 | sinzui: ok, I am not getting a precise series on local :( | 19:08 |
| sinzui | perrito666, :( you are doing what i do | 19:11 |
| sinzui | perrito666, I don't specify series | 19:12 |
| sinzui | since we saw the issue with trusty too on a machine that didn't know about vivid, may be you want to just try trusty | 19:12 |
| sinzui | perrito666, oh, I am confused now, since you are working with tip you are running juju from in the tree to upgrade right? isn't juju making the agent to upload? | 19:13 |
| perrito666 | sinzui: I believe we are both confused here | 19:15 |
| perrito666 | I am working with master tip, in an utopic machine, which most likely knows of vivid? | 19:15 |
| perrito666 | sinzui: http://pastebin.ubuntu.com/9553381/ | 19:15 |
| perrito666 | this is what I get from a bootstrap with local | 19:16 |
| sinzui | perrito666, That looks right, but since this issue is about upprades, I think you want to bootstrap 20 or 21, then call upgrade. I assume during upgrade that streams is checked | 19:23 |
| perrito666 | sinzui: makese sense, ill get 21 | 19:23 |
| sinzui | perrito666, you can remove/change the vivid linne in /usr/share/distro-info/ubuntu.csv | 19:24 |
| perrito666 | sinzui: that, is easier | 19:24 |
| sinzui | perrito666, I learned that trick when we first added trusty and several QA machines didn't know what to do. | 19:25 |
| voidspace | right, signing off | 19:30 |
| voidspace | g'night all | 19:30 |
| perrito666 | sinzui: still cant, life hates me | 19:46 |
| perrito666 | sinzui: does this fail only on local? | 19:46 |
| jw4 | who is OCR today? | 19:47 |
| sinzui | perrito666, might be, I suspected the localhost's dist_info was where vivid was absent | 19:48 |
| thumper | perrito666: morning | 20:03 |
| thumper | perrito666: how's the vivid blocker? | 20:03 |
| perrito666 | thumper: morning | 20:03 |
| perrito666 | thumper: trying to reproduce it with half brain and to patch it without reproducing it with other half | 20:04 |
| thumper | works for me | 20:04 |
| * perrito666 knows thumper is patting with the foot like someone in line for the mans bathroom | 20:04 | |
| waigani | yep | 20:04 |
| jw4 | thumper: the other blocker is just waiting for review: http://reviews.vapour.ws/r/655/ | 20:05 |
| jw4 | thumper: hint hint | 20:10 |
| thumper | jw4: yeah... we know | 20:10 |
| thumper | and are talking about it | 20:10 |
| jw4 | :) | 20:10 |
| jw4 | thumper: fwiw it's essentially the same fix that docker did for a similiar issue in their code | 20:11 |
| katco | wallyworld: hey can you ping me when you get on? | 20:22 |
| waigani | jw4: reviewed | 20:39 |
| jw4 | waigani: thanks | 20:39 |
| jw4 | waigani: updated - reviewboard doesn't quite know what to do with the file added and then removed within the review cycle :) | 20:46 |
| waigani | jw4: so there is no unix file any more, right? | 20:48 |
| jw4 | waigani: correct | 20:48 |
| waigani | jw4: lgtm | 20:49 |
| jw4 | waigani: thanks | 20:49 |
| waigani | np | 20:49 |
| menn0 | jw4: hold the phone! | 20:50 |
| thumper | jw4: if you use the filename suffix, you don't need the build directives | 20:50 |
| menn0 | jw4: what thumper said | 20:50 |
| jw4 | haha | 20:50 |
| menn0 | jw4: the build directives currently don't match the filenames | 20:50 |
| jw4 | menn0, thumper they should? | 20:50 |
| menn0 | jw4: you don't need them anyway, the filenames create implicit build tags | 20:51 |
| thumper | jw4: easier to just not have them | 20:51 |
| jw4 | thumper, menn0 : kk - reduces chances of inadvertent conflict | 20:51 |
| jw4 | thumper, menn0 : will remove | 20:51 |
| menn0 | jw4: at any rate, the current build tags are confusing | 20:51 |
| thumper | agreed | 20:51 |
| menn0 | jw4: would be better to use positives instead of negatives (i.e. +build linux ; +build windows ; +build darwin | 20:52 |
| === kadams54 is now known as kadams54-away | ||
| menn0 | jw4: but just remove them... | 20:52 |
| * menn0 stops talking | 20:52 | |
| jw4 | menn0: makes sense. I haven't used build tags before - I confess to the cargo cult | 20:52 |
| menn0 | jw4: here's the docs: http://golang.org/pkg/go/build/#hdr-Build_Constraints | 20:53 |
| jw4 | menn0: thanks | 20:54 |
| tvansteenburgh | hey guys, i need a script that will collect all unit logs if/when a deployment fails (unit goes to error state). anyone have such a thing? | 21:04 |
| bodie_ | does anyone know why charm master is 8 commits ahead, 153 commits behind charm v4? I assumed master was tip | 21:07 |
| menn0 | tvansteenburgh: I don't but Juju's CI tools do parsing of status and log capturing | 21:07 |
| menn0 | tvansteenburgh: you could steal some bits from there | 21:07 |
| menn0 | tvansteenburgh: https://launchpad.net/juju-ci-tools | 21:07 |
| thumper | jw4: just added an extra shipit | 21:07 |
| jw4 | thumper: woot | 21:07 |
| tvansteenburgh | menn0: thanks! | 21:08 |
| thumper | bodie_: no, master is the old one, and v4 new | 21:08 |
| thumper | bodie_: some gopkg.in thing that I'm personally not a fan of | 21:08 |
| thumper | but there ya go | 21:08 |
| bodie_ | I see | 21:08 |
| === kadams54-away is now known as kadams54 | ||
| bodie_ | I don't think it must be that way; gopkg should point to versions as they are tagged in the repo | 21:09 |
| menn0 | tvansteenburgh: there's certainly a lot more there than you need and it's probably coupled in inconvenient ways but hopefully there's some useful bits | 21:09 |
| bodie_ | my understanding is that normally you'd have your master ahead of your tagged versions | 21:09 |
| thumper | bodie_: gopkg can point to tags or branches | 21:09 |
| bodie_ | well yes | 21:09 |
| jw4 | bodie_: and isn't that what you're seeing?" | 21:09 |
| thumper | and those in charge of the charm repo decided to use branches | 21:09 |
| jw4 | bodie_: master is 8 commits ahead of v4? | 21:09 |
| jw4 | bodie_: oh - i didn't read the rest - 153 behind | 21:10 |
| bodie_ | it looks to me like master was abandoned in favor of working off v4, but I'm not sure if there's an accepted way we're working with charm. in the meantime I'm going to work off v4... | 21:10 |
| jw4 | sounds like v4 should just be merged to master periodically? | 21:11 |
| bodie_ | *shrug* I'm not sure what the divergence is about; it's possible the extra commits should be part of v4, it's possible they shouldn't | 21:11 |
| jw4 | no, I meant merging the other way | 21:12 |
| jw4 | the 153 extra commits in v4 maybe should be merged into master | 21:12 |
| bodie_ | maybe there's a reason they were abandoned, I really don't know | 21:13 |
| bodie_ | I think that was around the time the versioning in charm was being nailed down | 21:13 |
| === sebas538_ is now known as sebas5384_ | ||
| === mwhudson_ is now known as mwhudson | ||
| perrito666 | thumper: menn0 wanna give me some light? I think I am around the problem but not yet sure | 21:14 |
| thumper | sure, what do you need? | 21:15 |
| === sebas5384_ is now known as sebas5384 | ||
| perrito666 | I have some knowledge gaps that you might fill :) here is what is going on, according to me: | 21:15 |
| perrito666 | CI uses 1.20.10.1 to bootstrap a local env | 21:16 |
| perrito666 | using upload tools | 21:16 |
| perrito666 | so you have a local env with jujud 1.20.10.1 that, if I am right, is not aware of vivid | 21:16 |
| perrito666 | the machine though already has vivid in ubuntu.csv | 21:16 |
| perrito666 | CI triggers an upgrade | 21:16 |
| perrito666 | something in the upgrade (here is the gap) calls SeriesVersions with "vivid" all blows | 21:17 |
| perrito666 | If I use tip for this it does not happen | 21:17 |
| perrito666 | and I am now about to test with the tip of 1.20 | 21:18 |
| thumper | perrito666: version/supportedseries.go | 21:18 |
| thumper | perrito666: vivid is in master, is it in the 1.21 branch? | 21:18 |
| thumper | is it in 1.20? | 21:18 |
| menn0 | perrito666, thumper: just caught up | 21:19 |
| perrito666 | mmmm in 1.21 is in ubuntuSeries but not in seriesVersions | 21:20 |
| perrito666 | I wonder if that is right | 21:20 |
| jw4 | sinzui, mgz_ fix for bug 1403596 is in - not sure which tests need to pass to mark "Fix Released" | 21:20 |
| mup | Bug #1403596: OSX build broken by stat.Ctim undefined <ci> <osx> <regression> <juju-core:Fix Committed by waigani> <https://launchpad.net/bugs/1403596> | 21:20 |
| thumper | jw4: you don't mark it fix released | 21:21 |
| thumper | jw4: also needs to be back ported to 1.21 | 21:21 |
| jw4 | thumper: is that something I can/could do? | 21:21 |
| thumper | jw4: yes :-) | 21:21 |
| jw4 | thumper: just another pr against 1.21 branch? | 21:22 |
| thumper | jw4: start with the 1.21 branch | 21:22 |
| sinzui | jw4, thumper http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/build-osx-client/ is the test and i am fine with anyone marking the bug for 1.22 fix release when we see a pass with :master: | 21:22 |
| thumper | and cherry pick your fix | 21:22 |
| sinzui | thumper, the job passes for 1.21. | 21:22 |
| thumper | oh | 21:22 |
| sinzui | we released with what it built in fact | 21:22 |
| jw4 | thumper: thanks for the tips ! | 21:22 |
| thumper | sinzui: oh, just master? | 21:22 |
| sinzui | yep | 21:22 |
| thumper | jw4: not needed for 1.21 apparently | 21:22 |
| menn0 | thumper: the OS X issue was only just introduced as part of work on backups | 21:23 |
| menn0 | thumper: methinks | 21:23 |
| jw4 | sinzui: cool - does that CI build kick off automatically? | 21:25 |
| thumper | perrito666: I'm looking at pr 1216 | 21:25 |
| sinzui | jw4, it will | 21:25 |
| jw4 | sinzui: kk | 21:25 |
| * jw4 goes to unload groceries for wifey | 21:25 | |
| thumper | sinzui: re bug 1403546 | 21:26 |
| mup | Bug #1403546: cannot get environment config: invalid series vivid <ci> <local-provider> <regression> <vivid> <juju-core:Triaged by hduran-8> <https://launchpad.net/bugs/1403546> | 21:26 |
| thumper | sinzui: this is an upgrade from what? | 21:27 |
| sinzui | 1.20.10 thumper | 21:27 |
| thumper | sinzui: I don't think this effects master, but the 1.20 branch | 21:28 |
| perrito666 | thumper: I did too but if I get it right that only should blow if that is actually runing a vivid | 21:29 |
| thumper | the client is trying to upload the tools, but the server goes "vivid what" ? | 21:29 |
| sinzui | thumper, you don't have a tie machine, you cannot change the fact that ubuntu only has old jujus | 21:29 |
| thumper | perrito666: no... | 21:29 |
| perrito666 | thumper: that is what I just said :p | 21:29 |
| thumper | sinzui: I want a time machine | 21:30 |
| perrito666 | sinzui: mm, a tie machine, that sounds very useful, especialy in parties | 21:30 |
| sinzui | thumper, perrito666 I can put vivid into the ubuntu.csv and run the test again (if ci isn't building again) | 21:30 |
| thumper | ... | 21:30 |
| thumper | sinzui: you are right, we should be more careful about what we update / upgrade | 21:30 |
| thumper | I'm just trying to work out what? | 21:30 |
| thumper | sinzui: can you add to the bug report what is in the ubuntu.csv on the server, and the version of the server failing? | 21:31 |
| sinzui | thumper, sure, I can also make the trusty machine have 1.20.11 from proposed | 21:31 |
| sinzui | ubuntu proposed I mean | 21:31 |
| thumper | sinzui: while this is technically a regression, it is not one generated by code, but time | 21:32 |
| thumper | well | 21:33 |
| thumper | the code that uploads tools has probably changed in the last six months somewhat | 21:33 |
| thumper | which is the last time we had to deal with this | 21:33 |
| thumper | sinzui: the host is running on which series? | 21:34 |
| perrito666 | well we actually fixed this | 21:34 |
| thumper | sinzui: also, machine-0 log from the server would help | 21:34 |
| perrito666 | I know, it sounds like I am saying something idiotic | 21:34 |
| perrito666 | sinzui: thumper I just compiled 1.20 tip | 21:34 |
| sinzui | thumper, we have a precise host and a trusty host | 21:34 |
| perrito666 | bootrstraped local with it uploading tools | 21:34 |
| perrito666 | compiled master tip | 21:34 |
| perrito666 | upgraded | 21:34 |
| perrito666 | worked like a charm | 21:35 |
| sinzui | and obviously they didn't fail two days ago | 21:35 |
| thumper | sinzui: I'm following that error back to the source | 21:40 |
| thumper | sinzui: and things don't add up | 21:40 |
| * thumper is a little confused | 21:40 | |
| sinzui | thumper, I just updated the trusty machine to 1.20.11 which is from Ubuntu trusty proposed. | 21:40 |
| thumper | sinzui: the error originates from the method LegacyStorage | 21:40 |
| thumper | ... | 21:41 |
| thumper | I'm reading the wrong code | 21:41 |
| thumper | that's why I'm confused | 21:41 |
| * sinzui runs with --debug with the version ever Ubuntu user will get in a week | 21:42 | |
| perrito666 | thumper: are you reading master or 1.20? | 21:42 |
| thumper | perrito666: I was reading master, hence confusion | 21:42 |
| perrito666 | at least in master that error is spit by LegacyStorage which is never called in local | 21:42 |
| perrito666 | yeah, happened to me | 21:42 |
| perrito666 | I am trying to see if we are doing something new in tools uploading that might trigger this | 21:43 |
| perrito666 | I am suddenly suspicious of this snippet in master http://pastebin.ubuntu.com/9554502/ | 21:44 |
| sinzui | surely during upload, streams is checked, and the streams contain vivid, but the machine doesn't know about them. the error is probably in streams code | 21:44 |
| perrito666 | I am really starting to hate prereqs | 21:45 |
| thumper | perrito666: I've found the part in 1.20 I think | 21:47 |
| thumper | perrito666: right, the client thinks they are supported but the server doesn't | 21:47 |
| perrito666 | thumper: which of the 3 parts that yield the exact same error? | 21:47 |
| thumper | state/apiserver/tools.go line 172 | 21:47 |
| perrito666 | thumper: the server gets vivid from the uplading client? | 21:48 |
| thumper | perrito666: correct | 21:48 |
| perrito666 | mm, there is a comment from william on the uploading function that says someting like this might happen | 21:49 |
| sinzui | thumper, perrito666 looky at the result when I upgraded one of the machines to 1.20,11 http://juju-ci.vapour.ws:8080/job/local-upgrade-trusty-amd64/ | 21:50 |
| sinzui | a pass | 21:50 |
| * perrito666 wonders what is a safe bet solution there | 21:50 | |
| perrito666 | sinzui: off course | 21:51 |
| perrito666 | https://github.com/juju/juju/blob/juju-1.20.11/version/ubuntu/supportedseries.go | 21:51 |
| perrito666 | 11 adds vivid | 21:51 |
| sinzui | yep so it does | 21:51 |
| sinzui | so good news for ubuntu when this version moves from proposed to updates | 21:51 |
| thumper | sinzui: so... now what? | 21:51 |
| sinzui | thumper, I am not sure this didn't fail 2 days ago before the mad rush to land code | 21:52 |
| sinzui | so something changed to break older jujus from upgrading | 21:52 |
| thumper | yeah, I can't see what though... | 21:53 |
| perrito666 | sinzui: I have scanned everything going remotely near versions and nothing seems to have that effect | 21:53 |
| perrito666 | I see only one way to find out | 21:53 |
| sinzui | :/ | 21:53 |
| thumper | sinzui: are we sure that the versions that were passing before were using the same old 1.20.x version? | 21:54 |
| thumper | and not 1.20.11? | 21:54 |
| * thumper is reading the previous passing test | 21:55 | |
| thumper | 1.20.10.1 | 21:55 |
| thumper | sinzui: you went from having passing test upgrading from 1.20.10.1 to 1.21-beta4 | 21:57 |
| sinzui | yep | 21:57 |
| thumper | to failing tests upgrading from 1.20.10.1 to 1.22-alpha1 | 21:57 |
| thumper | we don't support 1.20 -> 1.22 upgrades | 21:57 |
| sinzui | no | 21:58 |
| thumper | so why are you testing them? | 21:58 |
| sinzui | remember that jobs test all version that you commit too | 21:58 |
| thumper | no I don't remember | 21:58 |
| sinzui | thumper, you need to read the side to learn the branch and revision tested | 21:58 |
| thumper | why are we running this job when it doesn't make sense? | 21:59 |
| sinzui | this is http://juju-ci.vapour.ws:8080/job/local-upgrade-trusty-amd64/666/ == be01edcb | 21:59 |
| sinzui | thumper, This ensures the same test passes for all jujus. the input is a the version of juju under test | 21:59 |
| thumper | sinzui: sure, this test makes sense for 1.21, but not for 1.22 | 22:00 |
| thumper | now it fails for 1.22 and it is a problem? | 22:00 |
| thumper | I don't get it | 22:00 |
| thumper | it seems that 1.21 isn't uploading vivid | 22:01 |
| thumper | but 1.22 is | 22:01 |
| thumper | 1.20.10 doesn't know about vivid | 22:01 |
| thumper | so upgrades to 1.22 (which is unsupported) now fail | 22:01 |
| sinzui | thumper, juju removed the rules to control how it hops to a version during upgrade...I believe you removed them when you added alphas to versions | 22:01 |
| thumper | we did | 22:02 |
| thumper | I have hoped that this would work | 22:02 |
| thumper | but this shows that we still have issues | 22:02 |
| sinzui | thumper, 1.18 will only let you go to 1.20, 1.20 will do what every you tell it | 22:02 |
| thumper | now... we can fix this | 22:02 |
| thumper | but I wonder how much it is worth it to fix | 22:02 |
| thumper | how far we wish to backport | 22:02 |
| thumper | I propose the following idea: | 22:03 |
| sinzui | no backport to 1.20... | 22:03 |
| sinzui | it is dead to me and we cannot make people use it | 22:03 |
| thumper | sure... | 22:03 |
| thumper | in which case 1.20 -> 1.22 should not be supported | 22:03 |
| sinzui | thumper, IS is using 1.20.10. they plan to hop to 12 then 14 | 22:03 |
| perrito666 | sinzui: that is ok | 22:04 |
| thumper | the fix is to have the tools processing not fail on tools it doesn't know about | 22:04 |
| thumper | just to drop them on the floor | 22:04 |
| perrito666 | 14->22 works | 22:04 |
| sinzui | yep | 22:04 |
| sinzui | I agree | 22:04 |
| thumper | sinzui: but that fix can be back ported to 1.21 | 22:05 |
| thumper | but not 1.20 | 22:05 |
| thumper | so we can't support jumping versions from 1.20 to 1.22 | 22:05 |
| === kadams54 is now known as kadams54-away | ||
| thumper | hopefully with this fix in place, we shouldn't hit this next time | 22:05 |
| sinzui | thumper, just ensure juju doesn't skip minor version? | 22:05 |
| thumper | no... that is not what I'm proposing | 22:06 |
| === kadams54-away is now known as kadams54 | ||
| perrito666 | thumper: what exactly are you proposing? | 22:12 |
| sinzui | perrito666, from ubuntu/canonical's perspective, every host should be accepting updates. We can test the precise host and see if it passes | 22:15 |
| sinzui | perrito666, from juju's perspective skipping minor versions is unpredictable, and juju should be taught to say no | 22:16 |
| sinzui | perrito666, and juju can also claim the issue is fixed by upgrading to the lastest 1.20...then hoping to 1.22 | 22:17 |
| perrito666 | sinzui: there is the point, when you say "by upgrading" you mean that we advice that and declare this issue solved or you are thinking on something else? | 22:18 |
| perrito666 | be aware that at this point I have a very interesting headache so be gentle with your answer | 22:19 |
| sinzui | perrito666, prove the two work arounds, add them to the bug, then mark the bug as wont fix | 22:20 |
| sinzui | perrito666, because the affected users are those with stale ubuntu packages or stale juju packages. | 22:20 |
| jw4 | sinzui: should 'build-osx-client' have kicked off by now? | 22:20 |
| sinzui | perrito666, we do need to prove both conditions. we proved juju.20.11 is fixed | 22:21 |
| perrito666 | the two workarounds are 1.20.10->1.20.14->1.22 and 1.20.10->1.21->1.22? | 22:21 |
| sinzui | jw4, I disabled CI so that we could explore how to fix perrito666's bug | 22:21 |
| jw4 | sinzui: ah; I see. | 22:21 |
| sinzui | perrito666, that is the juju work around. | 22:22 |
| sinzui | perrito666, lets take 5 minutes to test the precise machine with a current dist-info-data | 22:22 |
| sinzui | then we can let jw4 end his day with a victory | 22:22 |
| jw4 | sinzui: hehe - I have 5 pending PRs I wanna land before I leave on vacation tomorrow | 22:23 |
| perrito666 | jw4: I take you are not planning to sleep | 22:23 |
| jw4 | perrito666: lol | 22:23 |
| sinzui | jw4, I leave in 40 minutes | 22:23 |
| jw4 | sinzui: and code freeze for 1.22 is Friday right? | 22:24 |
| sinzui | yep | 22:24 |
| jw4 | sinzui: it's after 5pm for you right? Are you leaving for vacation or until tomorrow o_O | 22:26 |
| sinzui | jw4, I am just taking day trips | 22:27 |
| jw4 | sinzui: I see | 22:27 |
| sinzui | I don't like leaving my kitchen or internet | 22:27 |
| jw4 | sinzui: lol - what do you have google fiber or something? | 22:27 |
| perrito666 | sinzui: interesting I feel like that for my bathroom | 22:28 |
| jw4 | perrito666: ROFL <--- almost literally | 22:28 |
| jw4 | brings a whole new perspective to Google Fiber | 22:28 |
| sinzui | jw4, I do have fiber from verizon and no cable. just net | 22:29 |
| perrito666 | aghh how in the universe do I checkout a tag | 22:30 |
| perrito666 | ? | 22:30 |
| jw4 | perrito666: git checkout <tag> | 22:30 |
| perrito666 | thought so but not working | 22:30 |
| jw4 | perrito666: do you have the tag in your local repo? | 22:31 |
| perrito666 | jw4: no I was trying to fetch the one in github | 22:31 |
| jw4 | perrito666: git fetch --all --tags | 22:31 |
| sinzui | perrito666, http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/local-upgrade-precise-amd64/ | 22:31 |
| jw4 | --all probably not needed | 22:31 |
| jw4 | sinzui: I briefly considered moving to Kansas City when they were selected for Google Fiber | 22:32 |
| perrito666 | sinzui: that is precise | 22:32 |
| perrito666 | sinzui: I am now trying the 1.20.10 to somthing else jump | 22:32 |
| perrito666 | sinzui: ok, we have a different problem | 22:34 |
| jw4 | waigani: thanks for the email! Hopefully I can find it in gmail again next time. | 22:34 |
| perrito666 | sinzui: I just upgraded to 1.22 from 1.20.10 | 22:35 |
| * perrito666 headbuts the desk | 22:35 | |
| perrito666 | I am seriously over my EOD, anyone interested in taking over this? | 22:36 |
| perrito666 | otherwise Ill have to go be a family person and return later | 22:36 |
| * perrito666 eyes thumper | 22:36 | |
| * jw4 finds it strangely quiet in here suddenly | 22:37 | |
| alexisb | perrito666, I can make sure it gets handed off, go! | 22:37 |
| jw4 | run perrito666 run | 22:37 |
| * jw4 smiles nervously at alexisb | 22:38 | |
| thumper | perrito666: I got this | 22:40 |
| alexisb | thank you thumper | 22:40 |
| perrito666 | thumper: thanks a lot, see you al tomorrow people | 22:40 |
| perrito666 | thans alexisb too | 22:40 |
| perrito666 | cheers | 22:40 |
| sinzui | jw4, CI has started testing you revision | 22:51 |
| jw4 | sinzui: tx | 22:52 |
| thumper | sinzui: https://github.com/juju/juju/pull/1216/files definitely caused the upgrade failures | 22:55 |
| jw4 | woot | 22:56 |
| waigani | jw4: np, I used the command just before I read your email, so it was fresh in my memory. | 23:08 |
| === kadams54 is now known as kadams54-away | ||
| katco | wallyworld: ping, you here yet? | 23:23 |
| wallyworld | katco: sorry, been in meetings | 23:23 |
| wallyworld | got another one in 5 | 23:23 |
| katco | wallyworld: oh no worries at all | 23:23 |
| wallyworld | but i am free till then | 23:24 |
| jw4 | sinzui, waigani can we mark 1403596 fix released yet? It passed the osx ci build | 23:24 |
| katco | wallyworld: i was going to ask for some of your time for some peer-programming | 23:24 |
| alexisb | wallyworld, feel free to stump on our 1x1 if you need to chat with katco | 23:24 |
| sinzui | I just updated the bug jw4 | 23:24 |
| katco | alexisb: wallyworld: it's just stupid newbie questions. your call :) | 23:24 |
| jw4 | sinzui: gracias | 23:24 |
| wallyworld | katco: did you want to hook up now? | 23:24 |
| katco | wallyworld: yeah def.! | 23:24 |
| alexisb | :) | 23:25 |
| katco | wallyworld: tanazanite? | 23:25 |
| wallyworld | sure | 23:25 |
| katco | alexisb: ty so much! | 23:25 |
| wallyworld | alexisb: i'll ping you in a bit if you will be around | 23:25 |
| thumper | ok, lunch time.. bbl | 23:25 |
| alexisb | I will be until about 5 (1.5 hours from now) then I am on kiddo duty until our leads call | 23:25 |
| === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: None | ||
| sinzui | thumper, this bug might interest you. maybe you want to say it is a documentation issue if there is no fault https://bugs.launchpad.net/juju-core/+bug/1403165 | 23:26 |
| mup | Bug #1403165: Cannot destroy-environment with 'juju user add' .jenv file <config> <destroy-environment> <regression> <users> <juju-core:Triaged> <https://launchpad.net/bugs/1403165> | 23:26 |
| wallyworld | alexisb: ok, if i'm done i'll ping | 23:27 |
| thumper | sinzui: ta | 23:42 |
| anastasiamac | m trying to test newly checked-out charm.v4 on my machine and m getting http://pastebin.ubuntu.com/9555369/ what m I miss n? | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!