| menn0 | thumper: I was going to add a test to make sure the machine unit watcher doesn't show things from other environments but that's opened a whole can of worms in terms of filtering work we need to do and required test infrastructure | 00:35 |
|---|---|---|
| menn0 | thumper: do you want me to press on or do the minimal work required to get the units env UUID work landed? | 00:36 |
| menn0 | thumper: I'm aware that the identity work needs to get done too | 00:36 |
| === mup_ is now known as mup | ||
| ericsnow | how do you get an agent.Config from state? | 01:03 |
| axw | ericsnow: you don't. agent.Config is read from disk, and only from disk | 01:07 |
| thumper | menn0: how big is that can of worms? | 01:08 |
| menn0 | thumper: at least the rest of the day | 01:08 |
| * thumper hears "and Friday" | 01:09 | |
| ericsnow | axw: my real question is where do I look up the environment's data dir | 01:09 |
| menn0 | thumper: likely | 01:09 |
| ericsnow | axw: from what I could tell environs.Config doesn't give it to you | 01:09 |
| thumper | menn0: well, we know we will need a bunch of extra tests later anyway | 01:09 |
| axw | ericsnow: that'd be encoded in the upstart job | 01:09 |
| thumper | menn0: I say punt on it for now, but leave notes in the code | 01:09 |
| menn0 | thumper: and actually, since writing to you last i've realised that we can't really do this until at machiens have been migrated too | 01:09 |
| axw | ericsnow: the agent is told where it is as a command line arg | 01:10 |
| thumper | menn0: that makes sense | 01:10 |
| axw | ericsnow: what are you trying to do? | 01:10 |
| thumper | menn0: because they all have dependencies on each other | 01:10 |
| ericsnow | axw: that's what I gathered | 01:10 |
| ericsnow | axw: for backups we currently have a bunch of paths hard-coded | 01:10 |
| menn0 | thumper: I was trying to set up a second env it's own machine, services and units to test with and kept running into collisions with the initial env | 01:10 |
| thumper | heh | 01:10 |
| * thumper nods | 01:10 | |
| menn0 | thumper: I will add some TODOs | 01:10 |
| ericsnow | axw: I'm looking at how to pull those from elsewhere | 01:11 |
| axw | ericsnow: IIRC, datadir is passed into the apiserver as a "resource" ... one sec | 01:11 |
| ericsnow | axw: you're right | 01:11 |
| menn0 | thumper: I have a fair idea of how the test infrastructure for this should look (i.e. a new method on ConnSuite to create a new env and an easy way to get a Factory for that) | 01:12 |
| * thumper nods | 01:12 | |
| axw | ericsnow: can you not take it from there then? | 01:12 |
| thumper | axw: CI blocker: http://reviews.vapour.ws/r/104/diff/ ? | 01:12 |
| ericsnow | axw: yeah, I guess I was hoping for a single-source-of-truth for paths | 01:13 |
| axw | thumper: looking | 01:13 |
| thumper | ericsnow: are you guys looking at https://bugs.launchpad.net/juju-core/+bug/1373611 | 01:14 |
| mup | Bug #1373611: cannot restore a HA state-server <backup-restore> <ci> <ha> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1373611> | 01:14 |
| thumper | perrito666: is this your fix from before? | 01:14 |
| ericsnow | thumper: no | 01:14 |
| axw | thumper: bugger, I thought our compatibility was only the other way around... | 01:15 |
| thumper | axw: I pasted back in the code I deleted earlier | 01:15 |
| ericsnow | thumper: http://reviews.vapour.ws/r/101/ has a fix | 01:16 |
| axw | thumper: yep. LGTM | 01:16 |
| thumper | axw: yeah... see the bug description https://bugs.launchpad.net/juju-core/+bug/1373424 | 01:16 |
| mup | Bug #1373424: method Client.AddMachinesV2 is not implemented <api> <ci> <compatibility> <regression> <juju-core:In Progress by thumper> <https://launchpad.net/bugs/1373424> | 01:16 |
| ericsnow | thumper: for #1373611 | 01:16 |
| mup | Bug #1373611: cannot restore a HA state-server <backup-restore> <ci> <ha> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1373611> | 01:16 |
| thumper | ericsnow: I was wondering if that was it | 01:16 |
| thumper | ericsnow: has it been submitted? | 01:16 |
| ericsnow | thumper: don't think so: https://github.com/juju/juju/pull/836 | 01:17 |
| * thumper submits it | 01:21 | |
| wwitzel3 | does anyone know where in the API call steps we unmarshall values? | 01:32 |
| thumper | wwitzel3: in the magic bit of the code | 01:38 |
| thumper | wwitzel3: juju/rpc maybe? | 01:38 |
| wwitzel3 | thumper: well, I'm getting ERROR json: cannot unmarshal object into Go value of type names.Tag | 01:38 |
| thumper | yeah... | 01:38 |
| wwitzel3 | but the logs have no information on where the is being generated from at all | 01:38 |
| thumper | the wire protocol needs to use strings | 01:39 |
| thumper | until we fix the wire protocol | 01:39 |
| thumper | wwitzel3: we could fix it... | 01:39 |
| thumper | wwitzel3: you just need to provide the json serialization functions for all the concrete types | 01:39 |
| thumper | wwitzel3: the error is being raised by the json serialization code | 01:40 |
| wwitzel3 | thumper: where is that code? apiserver? the jsoncodec call? | 01:40 |
| thumper | wwitzel3: the json code? inside the standard library | 01:40 |
| thumper | json.Marshal | 01:41 |
| wwitzel3 | thumper: I mean within our code, where is the unmarshalling happening? | 01:41 |
| thumper | wwitzel3: I'm guessing, but probably in juju/rpc where it puts the code on the wire | 01:41 |
| thumper | wwitzel3: api.client unmarshals actually | 01:41 |
| wwitzel3 | thumper: if I could fucking spell, I'd probably have less questions | 01:43 |
| wwitzel3 | acking for unmarshall exact match wasn't ever going to be helpful | 01:43 |
| wwitzel3 | I'm a moron | 01:44 |
| wwitzel3 | thank you | 01:44 |
| wwitzel3 | Umarshall that is | 01:44 |
| wwitzel3 | I at least had the puncuation right | 01:44 |
| wwitzel3 | thumper: so, is the solution to switch back to strings? or to define how to unmarshal names.Tag? | 01:45 |
| thumper | wwitzel3: yes... | 01:45 |
| thumper | wwitzel3: for assistance, version.go:117 | 01:46 |
| thumper | not sure if you want to go that way or not just yet | 01:46 |
| wwitzel3 | thumper: a Tag is pretty easy type to implement that for | 01:46 |
| thumper | wwitzel3: yep | 01:47 |
| wwitzel3 | thumper: and it is still that something based on string isn't easily serializable to JSON anyway | 01:47 |
| thumper | wwitzel3: because we even have the magic parseFooTag mthods | 01:47 |
| wwitzel3 | s/still/silly | 01:47 |
| wwitzel3 | ok, I'll go that route since I think it makes things better | 01:47 |
| thumper | good luck | 01:47 |
| wwitzel3 | it's just typing | 01:48 |
| thumper | and tests :) | 01:48 |
| wwitzel3 | yep | 01:48 |
| davecheney | can someone help me | 01:59 |
| davecheney | for some reason I can no longer see both the comments and the diff on the same screen | 01:59 |
| thumper | davecheney: maybe | 01:59 |
| davecheney | something has happened and reviewboard does not show me the comments that others have made on a review | 02:00 |
| davecheney | unless I go to the "view review" screen | 02:00 |
| davecheney | but then it doesn't show me the code | 02:00 |
| davecheney | and I need to go to the "view diff" screen | 02:00 |
| thumper | davecheney: I've had to go to view diff screen too | 02:06 |
| thumper | I thought it was just me getting used to the tools | 02:06 |
| perrito666 | thumper: did you merge my fix? | 02:07 |
| thumper | perrito666: aye | 02:07 |
| perrito666 | thumper: thank you sir | 02:07 |
| davecheney | thumper: this worked a few weeks ago | 02:08 |
| davecheney | ie, on the diff screen you would see inline comments | 02:08 |
| davecheney | now they are all hidden on another screen | 02:08 |
| perrito666 | btw axw you might have inadvertedly fixed a problem in environs.Environ StateServerInstances congrats, you now subconsciously rock | 02:08 |
| thumper | how the hell do I change the topic | 02:08 |
| axw | perrito666: heh, what was that? | 02:09 |
| davecheney | massive storm in sydney atm | 02:09 |
| davecheney | if i go offline | 02:09 |
| davecheney | please sent paramedics | 02:09 |
| thumper | heh | 02:09 |
| perrito666 | axw: well the bug I fixed should have been triggered long ago but apparently StateServerInstances was returning only one instance :p and after your commit it now returns all the state servers | 02:09 |
| thumper | ugh | 02:10 |
| axw | perrito666: ah :) that only happens for new environments tho | 02:10 |
| thumper | the bot still things there are ci blockes | 02:10 |
| perrito666 | davecheney: dont you prefer us to send an internet technician? I mean I dont see paramedics getting you back online | 02:10 |
| thumper | but they are both fix committed now | 02:10 |
| perrito666 | thumper: takes a bit I think | 02:10 |
| axw | perrito666: it was an intentional improvement, didn't know it fixed anything in particular tho :p | 02:10 |
| * thumper taps his fingers impatiently | 02:11 | |
| perrito666 | axw: neither did I, in fact none of us knew it was broken | 02:12 |
| perrito666 | axw: the test you added does the same restore did that is why I realized | 02:12 |
| davecheney | thumper: http://reviews.vapour.ws/r/79/diff/# | 02:12 |
| davecheney | can you go to line 100 in filestorage/wrapper.go | 02:13 |
| davecheney | and tell me if the line is properly gofmt'd on your screen | 02:13 |
| davecheney | i'd like you to the line if that was something that RB could do | 02:14 |
| * thumper looks | 02:17 | |
| davecheney | or this one http://reviews.vapour.ws/r/103/diff/# | 02:18 |
| davecheney | api/backups/list_test.go lines 27 onwards | 02:18 |
| davecheney | it looks liek RB gives up after three levels of indentation | 02:18 |
| thumper | davecheney: looks properly formatted to me | 02:18 |
| thumper | davecheney: list_test looks fine to me too | 02:19 |
| davecheney | hang on, screenshotting | 02:20 |
| davecheney | thumper: check your mail | 02:21 |
| thumper | davecheney: yeah, yours looks different to mine | 02:21 |
| thumper | davecheney: I see proper formatting | 02:21 |
| thumper | davecheney: may I suggest it is your shitty browser? | 02:22 |
| thumper | :) | 02:22 |
| davecheney | chrome, just like everyone else | 02:22 |
| thumper | hmm... | 02:22 |
| thumper | it really does look fine here | 02:22 |
| thumper | chromium here | 02:23 |
| davecheney | fine, i'll just ignore any formatting issues | 02:23 |
| davecheney | the bot will catch them for me | 02:23 |
| thumper | gah... why is the bot not working out that we have fixed the blockers? | 02:55 |
| menn0 | thumper: http://reviews.vapour.ws/r/93/diff/ PTAL | 02:58 |
| thumper | menn0: ok | 02:58 |
| cmars | thumper, i told the buildbot that those blockers were fixed. it seemed to accept builds now | 03:01 |
| thumper | cmars: how? | 03:01 |
| thumper | cmars: I thought it looked at LP | 03:02 |
| cmars | you put $$fixes-<bug#>$$ in the merge comment | 03:02 |
| davecheney | $$__JFDI__$$ | 03:05 |
| cmars | ah, crap. buildbot is not remembering the fixes-NNN. i suppose that was already tried.. | 03:16 |
| menn0 | thumper: are you still looking at that PR? | 03:18 |
| thumper | yup | 03:19 |
| menn0 | thumper: ok | 03:19 |
| thumper | cmars: I did that | 03:19 |
| menn0 | thumper: just making sure you didn't forget to hit publish | 03:19 |
| thumper | cmars: that is how it landed the fixes | 03:19 |
| sinzui | cmars, CI is blocked by the two critical bugs in the topic. a fix for 1 of them is being test now | 03:19 |
| thumper | sinzui: I thought the blockage got removed when we committed them? | 03:20 |
| sinzui | no | 03:20 |
| thumper | sinzui: are they removed later now? | 03:20 |
| thumper | ah | 03:20 |
| sinzui | CI was being reopen but the tests dfailed | 03:20 |
| sinzui | we not wait for someone to make the bug fix released when the test is passed | 03:20 |
| thumper | sinzui: ack | 03:24 |
| wwitzel3 | oh man, so apparently if you implement a method on an interface with a pointer receiver .. every single place in the world you've ever used that break | 03:24 |
| thumper | wwitzel3: you can't implement a method on an interface | 03:24 |
| thumper | at least I didn't think so... | 03:24 |
| thumper | davecheney: ? | 03:25 |
| thumper | wwitzel3: yeah, the more I think about it, the more I think that you can't do that, it makes no sense | 03:25 |
| thumper | menn0: published response | 03:26 |
| wwitzel3 | thumper: no, I mean on the concreate implementation | 03:28 |
| wwitzel3 | thumper: sorry, it's late, shitty wording | 03:28 |
| thumper | wwitzel3: ok | 03:29 |
| thumper | why does it break? | 03:29 |
| wwitzel3 | thumper: I added the UnmarshalJSON method to the tag interface and then added an implementation on MachineTag. Now I have several dozen errors for does not implement Tag (UnmarshalJSON method has pointer receiver). Every where we reflect tag.(MachineTag) | 03:30 |
| wwitzel3 | which makes sense | 03:30 |
| wwitzel3 | I would need to pass in a pointer | 03:30 |
| wwitzel3 | but there are a ton of touch points in the test :/ | 03:30 |
| thumper | wwitzel3: you don't need to add the marshal and unmarshal methods to the tag interface... | 03:31 |
| thumper | wwitzel3: or at least, not yet | 03:31 |
| wwitzel3 | but the params we are sending over the wire are []names.Tag | 03:31 |
| thumper | wwitzel3: yes, the unmarshal needs a pointer | 03:31 |
| thumper | wwitzel3: as it changes the instance | 03:31 |
| thumper | wwitzel3: and not a copy of it | 03:31 |
| thumper | wwitzel3: hmm... | 03:32 |
| thumper | maybe you do need it ? | 03:32 |
| wwitzel3 | if I don't add them to the interface, it complains it doesn't know how to Unmarshal a Tag, which makes sense | 03:33 |
| wwitzel3 | I'll figure it out eventually | 03:34 |
| wwitzel3 | tag.(*MachineTag) .. is probably want I want | 03:35 |
| menn0 | thumper: thanks | 03:36 |
| menn0 | thumper: I did make the change in service.go! | 03:36 |
| thumper | menn0: did you | 03:37 |
| menn0 | thumper: the tests wouldn't be passing without it | 03:37 |
| thumper | must have missed it | 03:37 |
| menn0 | thumper: but you're right that a migration step would also be needed so I might just undo that | 03:37 |
| thumper | menn0: ah, so you did | 03:37 |
| thumper | yeah, it makes me a little sad, but probably faster for now | 03:37 |
| menn0 | thumper: or *evil grin* could we just strip a trailing "/" off the prefix if it's there? | 03:40 |
| thumper | haha | 03:40 |
| menn0 | thumper: I'm half-serious | 03:40 |
| thumper | do it | 03:40 |
| menn0 | thumper: alrighty | 03:41 |
| wwitzel3 | that's my favorite exchange of the night | 03:46 |
| menn0 | thumper: http://reviews.vapour.ws/r/93/diff/ | 04:04 |
| thumper | menn0: do your upgrade test while I have a coffee | 04:05 |
| thumper | that sounds a bit weird | 04:05 |
| thumper | but Rachel just got home | 04:05 |
| * thumper cracks the whip | 04:06 | |
| menn0 | thumper: doing it already :) | 04:06 |
| menn0 | thumper: what's a quick and easy subordinate charm I can add to my test environment? | 04:06 |
| davecheney | menn0: nagios-nrpe | 04:11 |
| menn0 | davecheney: thanks | 04:12 |
| === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: 1373611 | ||
| menn0 | thumper: well that didn't go so well... | 04:30 |
| menn0 | thumper: some services have disappeared | 04:30 |
| menn0 | thumper: I'm going to check the DB | 04:30 |
| thumper | oh... | 04:40 |
| thumper | jam: hey there | 04:43 |
| thumper | menn0: so... how is the db looking? | 04:51 |
| thumper | menn0: did you want to talk it through? | 04:51 |
| menn0 | thumper: the db looked as I expected it but obviously something wasn't right | 04:52 |
| wwitzel3 | so the Marshal methods have to be part of the interface definition for the generic names.Tag to support json encoding, and eventually I got it all working on the names package, but there are just too many places where we do something like []names.Tag{NewUnitTag()} .. which no longer works the momemnt you have a pointer receiver | 04:52 |
| menn0 | thumper: I'm just testing the same env with master so that I can be sure it was the units change | 04:52 |
| thumper | menn0: ok, | 04:52 |
| menn0 | thumper: ok master is fine | 04:54 |
| menn0 | thumper: going to rebase my branch to upstream and recreate the problem again | 04:54 |
| thumper | kk | 04:54 |
| * thumper notices that st.AllServices() definitely leaks services across environments... | 04:56 | |
| menn0 | thumper: there's tons and tons of stuff that leaks across envrionments | 04:57 |
| menn0 | thumper: once we have the base DocID changes done we'll need to circle back and deal with all that, writing tests as we go | 04:57 |
| thumper | agreed | 04:57 |
| menn0 | thumper: I was thinking it might be a good idea to set up an alternate environment in the setup of ConnSuite that doesn't get directly referred to in tests but will expose places that leak | 04:58 |
| menn0 | thumper: unexpected data should show up all over the place and cause tests to fail | 04:59 |
| menn0 | thumper: this canary env should be fairly well set up with several machines, services, subordinate units etc to maximise the stuff it'll expose | 05:01 |
| * thumper nods | 05:02 | |
| menn0 | the mediawiki charm just won't install at the moment | 05:03 |
| thumper | that seems reasonable, but potential overkill | 05:03 |
| menn0 | I keep having to ssh to the box and do a "apt-get update" and then run "juju resolved --retry mediawiki/0 to get it to install | 05:03 |
| menn0 | is that expected? | 05:03 |
| menn0 | this is with 1.20.7 | 05:03 |
| thumper | menn0: local? | 05:04 |
| menn0 | thumper: yep | 05:04 |
| thumper | menn0: could be due to the apt upgrade / update thing | 05:04 |
| thumper | your template is out of date | 05:04 |
| menn0 | thumper: right | 05:04 |
| menn0 | thumper: very likely | 05:04 |
| menn0 | thumper: delete the template machine or is there a faster way? (start the template and update it?) | 05:05 |
| thumper | yeah | 05:05 |
| thumper | yes to starting the template | 05:05 |
| thumper | and logging in, and doing an apt-get update/upgrade | 05:06 |
| menn0 | thumper: ok, i'll do that | 05:06 |
| thumper | then shutting it down again | 05:06 |
| wwitzel3 | (╯°□°)╯︵ ┻━┻ | 05:08 |
| thumper | ┬─┬ ノ( ゜-゜ノ) | 05:09 |
| bradm | hey, do we have a stable 1.20.8 yet? wondering when I should expect to need to change to it | 05:09 |
| menn0 | thumper: http://paste.ubuntu.com/8423049/ :( | 05:09 |
| menn0 | thumper: the exact final result doesn't appear to be deterministic either | 05:10 |
| thumper | menn0: oh crud | 05:10 |
| thumper | menn0: is it the status collection? | 05:10 |
| thumper | menn0: units have status | 05:10 |
| * menn0 checks | 05:11 | |
| thumper | the status command would be looking there, right? | 05:11 |
| menn0 | yeah but we haven't changed the statuses collection keys yet. | 05:11 |
| menn0 | maybe that's the problem. | 05:11 |
| menn0 | it didn't break services... | 05:11 |
| * thumper nods | 05:11 | |
| thumper | menn0: I think... | 05:12 |
| thumper | menn0: that status should still keep local ids | 05:12 |
| thumper | but need to check | 05:12 |
| thumper | it is how it gets the underlying entity | 05:12 |
| thumper | I'm being called for dinner | 05:12 |
| * thumper will be back for team-lead meeting later | 05:12 | |
| === thumper is now known as thumper-afk | ||
| dimitern | morning all | 05:24 |
| menn0 | thumper-afk: the migration steps for units and services have mixed everything up. | 05:26 |
| menn0 | thumper-afk: for example, all services now have a name of "rsyslog-forwarder-ha" I can only tell them apart from the _id. | 05:27 |
| menn0 | thumper-afk: must be something with the generic upgrade function. I'll take a look | 05:27 |
| dimitern | davecheney, hey | 06:03 |
| davecheney | dimitern: o/ | 06:03 |
| dimitern | davecheney, due to the way names.NewEnvironTag() works, you *can* create an invalid tag without panicking, i.e. tag := names.NewEnvironTag(""), then tag.Id() == "" is equivalent to tag == nil if tag used to be names.Tag | 06:04 |
| davecheney | dimitern: thanks for confimring | 06:04 |
| davecheney | i think it is still a bug | 06:04 |
| davecheney | i think the problem is NewEnvironTag("") should fail | 06:05 |
| dimitern | davecheney, I agree | 06:05 |
| dimitern | davecheney, but environ tags are relatively recent, and we still have to support the case when it's not set | 06:05 |
| davecheney | dimitern: i wish thumper was here | 06:06 |
| davecheney | environ tags are basically manditory for mees | 06:06 |
| davecheney | mess | 06:06 |
| davecheney | whatever | 06:06 |
| davecheney | we can't keep continuing to say, oh well, if you don't have an env tag we can just overlook it this time | 06:06 |
| dimitern | davecheney, since I saw your comments too late, I'll do a follow-up to do some of your suggestions and reply about NewEnvironTag | 06:07 |
| davecheney | ok, thanjs | 06:08 |
| davecheney | thanks | 06:08 |
| menn0 | thumper-afk: I've figured out the garbled data following the migration. if you read data into a map using mgo and then save that map in a slice you need to recreate that map before starting the next loop. setting it to nil was sufficient. | 06:11 |
| menn0 | thumper-afk: there's still what looks like a presence issue. after the upgrade the units are marked as down. the agents are started (in the DB too) but the presence check is failing. | 06:13 |
| menn0 | thumper-afk: I'll continue tomorrow. I need to EOD. | 06:13 |
| === menn0 is now known as menn0-eod | ||
| dimitern | davecheney, wanna have a look? http://reviews.vapour.ws/r/105/ | 06:27 |
| davecheney | looking | 06:30 |
| davecheney | dimitern: looks good, two issues | 06:32 |
| dimitern | davecheney, cheers | 06:33 |
| dimitern | davecheney, I don't think returning an error there is sensible, due to the possibility of not having environ UUID at the endpoint level | 06:35 |
| dimitern | davecheney, and the login *will work* without it, for the same reason | 06:36 |
| davecheney | sure | 06:36 |
| dimitern | davecheney, but maybe adding a warning and continuing will be useful | 06:36 |
| davecheney | var e names.EnvironTag | 06:36 |
| davecheney | e.String() | 06:36 |
| davecheney | no | 06:36 |
| davecheney | e.Id() => "" | 06:36 |
| davecheney | so there is no way to distinguish between presenting an environ id that is "", and the environ id being invalid and passing "" as a fallback | 06:37 |
| davecheney | simply put, there is no point validating if we're not going to reject values which are not valid | 06:37 |
| dimitern | davecheney, given a names.EnvironTag already, Id() == "" is the same as it being invalid | 06:38 |
| === uru_ is now known as urulama | ||
| dimitern | davecheney, but names.IsValidEnvironment(uuid-or-tag.Id()) works | 06:38 |
| davecheney | crap | 06:38 |
| dimitern | davecheney, the point of that code there is to only use the uuid if it's valid (an improvement from before when we didn't even validate the uuid) | 06:39 |
| dimitern | davecheney, that's why I suggest to do a logger.Warningf("API endpoint has invalid environment UUID %v", uuid) when it's not valid, but still let it through | 06:40 |
| davecheney | i guess that is all we can do | 06:40 |
| davecheney | this will end up being a buig | 06:40 |
| davecheney | i'm sure of this | 06:40 |
| davecheney | but what else can we do | 06:40 |
| dimitern | or maybe "ignoring invalid API endpoint environment UUID %v" | 06:40 |
| davecheney | sure | 06:41 |
| dimitern | yeah, we can incrementally make it better :) | 06:41 |
| dimitern | davecheney, updated - http://reviews.vapour.ws/r/105/diff/1-2/ | 06:48 |
| === uru_ is now known as urulama | ||
| dimitern | davecheney, is it good to land like this? | 06:53 |
| axw | jam: contributions to things like gwacl still need CLA signing, right? | 06:55 |
| jam | axw: I'm pretty sure all our stuff is (c) Canonical under the same CLA | 06:56 |
| jam | so they don't need to sign it separately | 06:56 |
| jam | but it does need to be signed | 06:56 |
| axw | jam: ok - someone sent in an MP for gwacl specifically | 06:56 |
| axw | if they've signed, it shows up on their LP ~ page right? | 06:57 |
| jam | axw: I see "Canonical Contributer Agreement" as one of my groups on https://launchpad.net/~jameinel/+participation | 06:57 |
| jam | so I think so | 06:57 |
| axw | thanks | 06:58 |
| jam | though I don't see it for https://launchpad.net/~axwalk/+participation | 06:58 |
| dimitern | jam, hey, can you have a look at http://reviews.vapour.ws/r/105/diff/ please? | 06:58 |
| jam | I'm not sure that everyone in "Canonical" is also in CCA | 06:58 |
| jam | dimitern: can you actually compare Tag objects? I thought it was an interface, and you don't want to compare exact internals | 06:59 |
| jam | if you can, those changes seem fine | 06:59 |
| axw | jam: AFAIK, only required if you don't work for Canonical; employment contract covers employees | 07:00 |
| jam | I'm just concerned if doing "t1 := names.Tag("foo"); t2 := names.Tag("foo"); t1 != t2" | 07:00 |
| jam | axw: right, you don't need to sign it, I just mean you need to look for one or the other | 07:00 |
| axw | ah yep | 07:00 |
| dimitern | jam, only names.Tag is an interface, the others are simple structs implementing it | 07:01 |
| jam | dimitern: axw: https://launchpad.net/~not-canonical :) | 07:01 |
| axw | hehe | 07:01 |
| jam | I got there from jelmer, who used to work at canonical | 07:02 |
| jam | Trying to find someone who isn't me or at canonical who should have signed the agreement to confirm participation | 07:02 |
| dimitern | jam, yep that's the "former employees and people often mistaken as employees" list :) | 07:02 |
| jam | dimitern: is there a simple way to link part of an RB diff? | 07:03 |
| jam | I'm looking at one that is very-much comparing a names.Tag to a names.Tag | 07:03 |
| dimitern | jam, you can link a X-Y diff, like this http://reviews.vapour.ws/r/105/diff/1-2/ | 07:03 |
| jam | dimitern: yeah, I want to link a line in the review: http://reviews.vapour.ws/r/105/diff/#1 | 07:04 |
| jam | one of those is *definitely* a names.Tag | 07:04 |
| dimitern | jam, apistate.EnvironTag() (names.EnvironTag, error) | 07:04 |
| dimitern | jam, and environ.EnvironTag() (names.EnvironTag) | 07:05 |
| dimitern | jam, confusingly enough, environ has at least 4 more Tag methods - ServerTag, Tag, etc. | 07:05 |
| jam | func(tag names.Tag) bool { | 07:05 |
| jam | dimitern: ^^ | 07:06 |
| jam | from 3 lines above that | 07:06 |
| dimitern | jam, aah, this one | 07:06 |
| dimitern | jam, yeah, but it really is a names.EnvironTag | 07:07 |
| dimitern | jam, because we do tag, err := ParseEnvironTag(strTag) and then call canAccess(tag) | 07:07 |
| dimitern | jam, it's just wrapped inside a names.Tag due to the way AuthFunc is defined | 07:08 |
| jam | dimitern: http://play.golang.org/p/wbU4gcGnWe seems to work | 07:09 |
| jam | the interface isn't the same, but it seems to compare the underlying object | 07:10 |
| dimitern | jam, http://play.golang.org/p/DzZ6RmhiE3 | 07:11 |
| dimitern | jam, :) yep | 07:12 |
| jam | dimitern: in your example you're using concrete types, Tag isn't doing anything | 07:12 |
| jam | ah, I guess 'u' was wrapped in a Tag | 07:13 |
| dimitern | jam, exactly | 07:13 |
| dimitern | jam, if I had func(tag Tag) bool { return tag == internalTag }, I could call it like f(Tag(u)) | 07:14 |
| dimitern | oops, I meant just f(u) | 07:14 |
| jam | dimitern: so what I was more concerned about was the e1 == e2 | 07:14 |
| jam | because the interface comparison *could* compare the underlying pointers | 07:14 |
| jam | rather than the objects that those pointers represent | 07:14 |
| jam | dimitern: but you can use all kinds of wrappers, "==" seems to just compare the underlying structs | 07:15 |
| dimitern | jam, yeah, but if that's the case st.EnvironTag() will return some different pointer than the tag arg points to | 07:16 |
| dimitern | and they'll never be == | 07:16 |
| dimitern | yeah, I seem to recall some doc or article about golang that comparisons work like that | 07:17 |
| dimitern | jam, so, is it good to land? | 07:18 |
| dimitern | jam, I have at least 2 follow-ups queued :) | 07:18 |
| jam | dimitern: this seems strange: if names.IsValidEnvironment(apiInfo.EnvironTag.Id()) { | 07:20 |
| jam | convert it from being a tag, just to check if it was a valid tag | 07:20 |
| jam | not saying there is a better way | 07:20 |
| jam | LGTM | 07:20 |
| dimitern | jam, if you follow the discussion we had earlier with davecheney | 07:20 |
| dimitern | jam, NewEnvironTag does not panic or validate at all what you give it | 07:21 |
| dimitern | it's a bug, but kinda intentional wrt backwards-compatibility for envs without uuid | 07:21 |
| dimitern | jam, thanks! | 07:21 |
| jam | dimitern: sure, it just feels like something that should be "tag.IsValid()" | 07:21 |
| davecheney | jam: no | 07:22 |
| davecheney | i disagree | 07:22 |
| davecheney | you should never have to ask tag.IsValid | 07:22 |
| davecheney | there are two possiblitues | 07:22 |
| davecheney | var t names.Tag | 07:22 |
| davecheney | t == nil { // not a valid tag, in fact not a tag at all | 07:22 |
| davecheney | var t names.UserTag | 07:22 |
| davecheney | t _must_ have a valid value | 07:22 |
| davecheney | ie, don't do this | 07:22 |
| davecheney | do this insteat | 07:22 |
| davecheney | t := names.NewUserTag | 07:23 |
| dimitern | -> panic | 07:23 |
| dimitern | better do ParseUserTag | 07:23 |
| davecheney | yes | 07:23 |
| jam | dimitern: well, you should never panic in response to user input. | 07:23 |
| davecheney | jam: good point | 07:23 |
| dimitern | +100 | 07:24 |
| davecheney | william thinks we should only use tags over the api | 07:24 |
| davecheney | so in a way they are not user input | 07:24 |
| jam | davecheney: validating in the client sending the data != validating in the server receiving the data | 07:24 |
| dimitern | but they are still strings when passed over the wire | 07:24 |
| jam | "just don't send bad data" | 07:24 |
| davecheney | yes, and we do that across the api boindaries with ParseUserTag | 07:24 |
| jam | and then my servers won't crash | 07:24 |
| davecheney | it gets more interesting when you're writing the implementation of, say | 07:25 |
| davecheney | juju ssh unit/0 | 07:25 |
| davecheney | the command needs to convert that string into a unit tag | 07:25 |
| davecheney | and it isn't as simple as | 07:25 |
| dimitern | i'm itching to write a simple DoS script that given an api endpoint tries API calls with all sort of crazy tags | 07:25 |
| dimitern | :) | 07:25 |
| davecheney | "unit-"+argv[1] | 07:25 |
| davecheney | dimitern: you're welcome to try | 07:26 |
| davecheney | that path is very well tested | 07:26 |
| dimitern | davecheney, yeah, at least for all facades I wrote; not all of them check all cases though | 07:27 |
| aznashwan | hey guys; I'm currently working on some tests in which I need to patch the container type as obtained from (juju/api.State).Agent().Entity(machineTag) | 08:21 |
| === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: None | ||
| jam | ah, ffs. "github.com/juju/txn" depends on "github.com/juju/juju/testing" not "github.com/juju/testing"... | 09:34 |
| axw | jam: just commented on the PR - we can fix that by disabling TLS. I can do that now if you like | 09:41 |
| axw | I don't think there's any need for TLS in these tests | 09:41 |
| jam | axw: yeah, I brought that up to bogdan, but seems fine as long as someone else agrees. | 09:43 |
| axw | dimitern: was there a particular reason for choosing ^ over ! for excluding networks? | 09:57 |
| axw | (I'm just curious) | 09:58 |
| natefinch | heh I was just going to ask that. | 09:58 |
| axw | :) | 09:58 |
| natefinch | man, I swear the calendar on my phone said the team meeting was now... must be an old copy | 10:01 |
| dimitern | axw, natefinch, yes, mainly due to ! having special meaning in bash and also fwereade and jam recommended ^ vs. ! IIRC | 10:01 |
| axw | dimitern: ok, I had suspected bash. makes sense. | 10:02 |
| natefinch | wow, that is a damn shame | 10:05 |
| natefinch | (bash, that is) | 10:05 |
| natefinch | ! is so much more obvious, but yeah, since bash decided no one ever gets to use !, there's no real alternative | 10:06 |
| axw | nobody's very happy with bash today | 10:07 |
| === fabrice is now known as fabrice|lunch | ||
| jam | dimitern: TheMue: taking the dog out, will try to be back in time | 10:27 |
| dimitern | jam, sure | 10:27 |
| TheMue | jam: no problem | 10:28 |
| natefinch | gsamfira: nice point on Juju units not needing rsyslog anymore | 10:30 |
| natefinch | removing external dependencies is already paying dividends :) | 10:30 |
| gsamfira | natefinch: I should have removed that dependency in the same commit. I don't know where my head was | 10:31 |
| gsamfira | natefinch: less moving parts, the better | 10:31 |
| natefinch | gsamfira: especially since we let people install random stuff on the same machine | 10:32 |
| jam | dimitern: standup? | 10:48 |
| dimitern | jam, sorry, brt | 10:53 |
| === thumper-afk is now known as thumper | ||
| jam | TheMue: I think you clicked the link :) | 11:01 |
| TheMue | ouch | 11:01 |
| jam | TheMue: I'll give it a look, right now i'm in the team leads meeting | 11:01 |
| TheMue | ok | 11:02 |
| === fabrice|lunch is now known as fabrice | ||
| === jacekn_ is now known as jacekn | ||
| * thumper -> bed | 11:54 | |
| cmars | jam, hangout? | 12:02 |
| jam | cmars: brt | 12:02 |
| === AndChat|9081 is now known as bogdanteleaga | ||
| === urulama is now known as urulama-afk | ||
| === jheroux_away is now known as jheroux | ||
| cmars | jam, re: login API PR, just pushed a minor comment fix, and confirmed v0 facade fallback on current master | 12:57 |
| jam | cmars: thanks | 12:58 |
| jam | we just had: FAIL: upgrade_test.go:420: UpgradeSuite.TestLoginsDuringUpgrade fail in a seemingly unrelated change | 12:58 |
| jam | is that a known flaky test? | 12:58 |
| jam | It failed with: c.Assert(err, gc.IsNil) ... value *params.Error = ¶ms.Error{"", "upgrade in progress - Juju functionality is limited"} ("upgrade in progress - Juju functionality is limited") | 12:59 |
| natefinch | spurious "upgrade in progress" errors is definitely a problem we've hit with the tests before... I forget exactly what causes it | 13:00 |
| perrito666 | natefinch: its a race-ish condition iirc | 13:00 |
| perrito666 | authenticator enters upgrade mode because of the upgrade worker and this doesnt finish before the test does whatever its trying to do | 13:01 |
| perrito666 | dimitern: ping | 13:01 |
| dimitern | perrito666, pong | 13:04 |
| perrito666 | dimitern: I see that you assigned me a card during the night/mornign | 13:04 |
| perrito666 | was that a mistake or you really wanted to assign that to me? | 13:04 |
| dimitern | perrito666, mistake, sorry - it was about the AddMachinesV2 API not implemented on 1.18; I added a card, found the issue, commented on the bug and realized I won't have time to fix it, but thumper did it | 13:05 |
| perrito666 | np, just trying to figure out if action was required from me | 13:06 |
| perrito666 | I wonder if this is the image people has of us http://io9.com/scorpion-brings-the-stupidest-most-batshit-insane-hack-1638333877 | 13:25 |
| natefinch | WTF | 13:28 |
| natefinch | seriously, totally unrealistic. If you have to stop as fast as possible, why would you turn your tires SIDEWAYS?! | 13:29 |
| cmars | perrito666, lol, that was amazing | 13:34 |
| natefinch | I don't care about the ridiculous antics of flying an aircraft 20 feet off the ground w/ ethernet dragging behind... but the fac tthat they think you can't land an airplane without software is just ridiculous. | 13:36 |
| Spads | especially when they show you can get most of a touch&go | 13:37 |
| perrito666 | natefinch: apparently his car doesnt have abs | 13:38 |
| perrito666 | also, really? nobody has a laptop? does not seem to be a very large quantity of data | 13:40 |
| perrito666 | they can copy it to a sd and then just throw that over the window :p | 13:40 |
| wwitzel3 | I know it is my own fault, but perrito666 .. you own me 2:17 of my life back | 13:40 |
| cmars | i'm just still amazed at the strength of that rj45 connector | 13:41 |
| perrito666 | I believe that these shows are written the following way: "we have the following stunts on budget, lets add some argument around | 13:41 |
| wwitzel3 | cmars: that is the only believable thing from the video .. I've seen the damage a cable accidently hooked around a foot does ;) | 13:41 |
| cmars | ooh ouch | 13:42 |
| perrito666 | cmars: I am equally amazed of the strength of the rj45 adapter of the laptop which should be as strong as a mini usb connection | 13:42 |
| cmars | jam, what do you think re: https://github.com/juju/juju/pull/392. ok to land? | 13:44 |
| wwitzel3 | perrito666: also if you're driving a 458 you should probably have flipped the ABS to off anyway, otherwise you shouldn't be driving a 458. | 13:45 |
| perrito666 | wwitzel3: I drive an opel corsa from BEFORE abs so I wouldnt know | 13:45 |
| wwitzel3 | I have arrays, I'd like all their content to be in a single array .. there are points in the code where we validate each item, in each array .. so should just add an append to the validation loops of each array? | 13:48 |
| perrito666 | wwitzel3: you lost me a bit there | 13:48 |
| wwitzel3 | I have 3 []string, I want to make a 4th []string that holds the contents of the all the []string. There are loops that already validate each item in the original []string. | 13:50 |
| wwitzel3 | So, should i just add an append for my new array to each of the original []string loops? | 13:50 |
| wwitzel3 | Or is there a better Go way | 13:50 |
| jam | wwitzel3: is it ok to modify in place? | 13:52 |
| jam | wwitzel3: you can do "ar1 = append(ar1, ar2...)" | 13:52 |
| jam | ar1 = append(ar1, ar3...) | 13:52 |
| jam | else, you can create a new ar, and then do appends | 13:52 |
| jam | wwitzel3: but "append(foo, slice...)" will append all of slice to foo | 13:53 |
| jam | wwitzel3: no loop needed | 13:53 |
| natefinch | wwitzel3: there's no "mash these N slices together". foo = append(foo, bar...); foo = append(foo, baz...); foo = append(foo, bat...) is the best you get | 13:56 |
| perrito666 | natefinch: that would be a nice feature to have | 13:56 |
| natefinch | natefinch: not really. The 3 lines are perfectly clear. If you really want, you can make it into a single loop for _, s := range [][]string{bar, baz, bat} { foo = append(foo, s...) } | 13:57 |
| perrito666 | talking to self? | 13:58 |
| katco | natefinch: you could chain your appends too: append(append(append(foo, bar...), baz...), bat...) | 13:59 |
| perrito666 | katco: nice listp | 13:59 |
| perrito666 | lisp | 13:59 |
| katco | oh camon that's not lisp lol | 13:59 |
| cmars | append is like a cons... hmm | 14:00 |
| katco | haha | 14:00 |
| wwitzel3 | yeah perrito666, lisp is 2 brackets per every other character. | 14:00 |
| perrito666 | lol | 14:00 |
| wwitzel3 | I actually like lisp, but it is just so much fun to pick on | 14:01 |
| perrito666 | wait, you can actually use it? I thought it was just for the lulz | 14:01 |
| perrito666 | :p | 14:01 |
| perrito666 | natefinch: ericsnow wwitzel3 stdup? | 14:01 |
| natefinch | perrito666, ericsnow, wwitzel3: there's actually a TOSCA call now, and wwitzel3 and I should probably be on that | 14:02 |
| natefinch | can we delay until the afternoon? | 14:02 |
| natefinch | I have another meeting after tosca today | 14:02 |
| perrito666 | natefinch: np, better for me I can continue with my enrique iglesias playlist | 14:03 |
| ericsnow | perrito666: nice | 14:03 |
| natefinch | haha | 14:03 |
| perrito666 | you guys laugh as if it was a joke | 14:05 |
| natefinch | I'm just sad you don't share during standups | 14:05 |
| ericsnow | perrito666: I wasn't laughing :) | 14:05 |
| natefinch | I was | 14:05 |
| ericsnow | perrito666, natefinch: now I'm laughing | 14:06 |
| perrito666 | its very good to concentrate, there is no way you can get carried away with his music | 14:06 |
| natefinch | heh | 14:06 |
| ericsnow | perrito666: so it's like a white noise generator/sound machine | 14:06 |
| perrito666 | ericsnow: latino white noise :p | 14:07 |
| natefinch | lol | 14:07 |
| perrito666 | its much like listening to fm radio without the guy speaking and the pub | 14:07 |
| wwitzel3 | interesting, so if a method returns type FooBar, which is a concrete implementation of an interface Foo, I can write var f Foo .. then f = GetFooBar() | 14:34 |
| wwitzel3 | but I can't create a function that takes a function that returns type Foo and then pass it a function that returns type FooBar | 14:34 |
| perrito666 | wwitzel3: I believe it compares the identity of the function there, what you propose requires a bit more inteligence | 14:47 |
| perrito666 | you can double wrap though | 14:48 |
| perrito666 | func () (yourinterface){func()(your concrete type)} | 14:48 |
| ericsnow | is there an easy way to restart the jujud process running on machine-0 ("service" and "initctl" don't see the upstart job)? | 15:02 |
| natefinch | ericsnow: kill it and let upstart restart it? | 15:03 |
| ericsnow | natefinch: isn't initctl an interface for upstart (it doesn't see the job)? | 15:04 |
| ericsnow | natefinch: I'll try it | 15:04 |
| ericsnow | natefinch: well, that worked | 15:05 |
| ericsnow | natefinch: thanks | 15:05 |
| ericsnow | ha, since starting with Go I keep typing $GOHOME instead of $GOPATH | 15:06 |
| ericsnow | guess my subconscious is trying to tell me something | 15:07 |
| perrito666 | ericsnow: something strange indeed, since you work at home | 15:09 |
| ericsnow | perrito666: yeah, but in the context of programming languages, Go isn't home :) | 15:10 |
| perrito666 | } | 15:10 |
| perrito666 | well I hope never need to go home bc I dont really feel like making assembly and BASIC again .p | 15:11 |
| perrito666 | :p | 15:11 |
| ericsnow | ha | 15:11 |
| === fabrice is now known as fabrice|family | ||
| natefinch | ericsnow: for me $GOPATH=$HOME ,so in essence, $GOHOME is correct :) | 15:48 |
| ericsnow | natefinch: :P | 15:48 |
| natefinch | although, what really revolutionized it for me was $CDPATH=$GOPATH/src | 15:49 |
| natefinch | so I can do cd github.com/juju/juju and it does the right thing | 15:49 |
| natefinch | anyone know lxc and want to help a user in #juju? he has a bunch of lxc containers that aren't coming up, though existing ones work fine | 15:57 |
| jcw4 | OCR: trivial change to fix go vet warning http://reviews.vapour.ws/r/106/ | 16:00 |
| natefinch | Anybody? I am the world's least helpful person when it comes to lxc | 16:02 |
| jcw4 | natefinch: my only bit of wisdom about lcx containers is when the templates get messed up : http://irclogs.ubuntu.com/2014/07/30/%23juju-dev.html#t02:08 | 16:04 |
| katco | does juju not harvest machines if there are no running units on them? | 16:08 |
| natefinch | katco: if you remove the last service on them it will, yes | 16:09 |
| natefinch | it used to not, by default, but now it does, by default, and there's a setting somewhere to turn it off | 16:10 |
| katco | well i worked on the harvest mode settings | 16:10 |
| katco | i thought it worked like that, but i wanted to 2x check before replying to nick moffitt's email | 16:10 |
| Spads | hi | 16:10 |
| Spads | katco: so even if it's supported, it can be important to remove a unit, do a postmortem, and then manually destroy it later | 16:15 |
| Spads | katco: so having the tools show you the states of things is essential even if you can have it auto-destroy | 16:15 |
| katco | Spads: oh hi :) | 16:15 |
| Spads | my last name has an unique spelling, so I tend to highlight on it :) | 16:16 |
| katco | Spads: right i was just about to respond... i love your idea to return 0 if nothing is errored. i'll add that to the spec and look into it | 16:16 |
| katco | Spads: :D | 16:16 |
| katco | Spads: so does the filtering take care of your post-mortem use-case? exit-code aside | 16:16 |
| Spads | katco: can you filter machines that are not associated with services? | 16:17 |
| katco | Spads: sure, if you specify a state, it just looks for that state | 16:17 |
| Spads | katco: but "not used by any service" isn't a machine state | 16:18 |
| Spads | the machine shows up in machines: but nowhere else | 16:18 |
| Spads | also again, I'm not interested specifically in ERROR | 16:18 |
| katco | Spads: oh sorry, i misunderstood | 16:18 |
| Spads | but also in anything that isn't perfect | 16:18 |
| Spads | anything in progress | 16:18 |
| katco | Spads: so you'd like a filter on un-utilized? | 16:18 |
| Spads | anything pending | 16:18 |
| Spads | yeah | 16:19 |
| Spads | basically when I run juju status it's to learn about things that are out of the ordinary | 16:19 |
| Spads | so I don't want to see services that are STARTED or machines that are JUST_FINE_THANKS | 16:19 |
| katco | haha | 16:19 |
| Spads | I want to see everything that's *not* those | 16:19 |
| Spads | like I want to filter *out* states | 16:19 |
| Spads | does that make sense? | 16:20 |
| katco | Spads: hm. wondering if it would be acceptable to add a not conditional to the filter | 16:20 |
| Spads | yeah | 16:20 |
| katco | or if that's too fancy/scope creep | 16:20 |
| Spads | well I think that filter/filter-out are a common pattern | 16:20 |
| Spads | grep/grep -v | 16:20 |
| Spads | etc | 16:20 |
| katco | i don't think i can make the decision, but i at least understand what you're saying now | 16:20 |
| Spads | select where not... | 16:20 |
| katco | i'll write up a user-story for you to look at to make sure i have it right, and then i'll check in with a lead | 16:21 |
| Spads | cool, do you want to summarise it for the list? | 16:21 |
| katco | Spads: sure will do | 16:21 |
| Spads | That's perfect. Many thanks! | 16:21 |
| katco | Spads: thank you for the input :) | 16:21 |
| Spads | if I had my druthers | 16:21 |
| Spads | juju status would behave as I described above | 16:22 |
| Spads | and juju status --verbose would dump the whole state | 16:22 |
| Spads | but I think that ship has sailed :) | 16:22 |
| katco | as default | 16:22 |
| katco | ? | 16:22 |
| Spads | yep | 16:22 |
| katco | i believe we're planning on moving to --format summary as default | 16:22 |
| katco | which makes the sitaution at least a little better | 16:22 |
| Spads | I'll have to find time to take a closer look at tip | 16:22 |
| katco | but i don't think that decision has been made yet (hint hint) | 16:22 |
| katco | like a 1.21 or 1.22 thing i think | 16:23 |
| * Spads nods | 16:23 | |
| katco | at any rate. good discussion. i'll update the spec | 16:23 |
| Spads | excellent. Thanks for your time! | 16:25 |
| bodie_ | so what's the policy on gopkg dep versioning? | 17:12 |
| bodie_ | I have a breaking change to charm I need to make, and a juju/juju branch ready to land which unbreaks it, I just need to figure out whether I need to move to charm v5 or how to properly integrate my work | 17:13 |
| mgz | bodie_: what specifically? | 17:13 |
| bodie_ | it's just a variable rename but it does cause juju to fail the tests without the core branch, so I'm thinking it would need a new gopkg charm version | 17:14 |
| rick_h_ | bodie_: on the charm package? | 17:14 |
| mgz | ah. not sure that's been fully argued yet. in theory, yes, vNEXT and change imports and dependencies.tsv for juju | 17:14 |
| mgz | but there was a thread recently with jam and rog about charm specifically | 17:14 |
| rick_h_ | bodie_: because we have stuff on that as well to keep up to date. rogpeppe has done a lot of work around the charm package and versioning and would be good to make sure we're in the loop | 17:14 |
| rogpeppe | bodie_: what's the variable? | 17:15 |
| bodie_ | rogpeppe, renaming ActionRequested to Action per fwereade, and removing it from unitHooks | 17:16 |
| rogpeppe | bodie_: in general if something's in gopkg.in, we try very hard to keep changes backwardly compatible according to the rules specified in http://gopkg.in/ | 17:16 |
| jcw4 | rogpeppe: fwiw, I'm fairly sure no-one has actually depended on that variable in production yet.... | 17:17 |
| rogpeppe | bodie_: you could just keep the old ActionRequested variable around | 17:17 |
| rogpeppe | bodie_: and document it as deprecated | 17:17 |
| jcw4 | rogpeppe: +1 | 17:17 |
| bodie_ | hmm... so use both | 17:17 |
| rogpeppe | bodie_: it can be deleted if/when we change the version | 17:18 |
| bodie_ | ok, and then leave it as v4 since it's not a breaking change? | 17:18 |
| rogpeppe | bodie_: yeah | 17:18 |
| rogpeppe | jcw4: i also am tempted to agree with you about known users | 17:18 |
| rogpeppe | jcw4: but... | 17:18 |
| bodie_ | rogpeppe, that makes sense. my other question is whether I need to rebase it on master or on the godeps'd version | 17:18 |
| rogpeppe | jcw4: i think it's nice to exercise this stuff so we know what to do when we *do* have users... | 17:19 |
| jcw4 | rogpeppe: +2 | 17:19 |
| bodie_ | rogpeppe, jcw4, there's already code in core using ActionRequested | 17:19 |
| bodie_ | fwiw | 17:19 |
| rogpeppe | bodie_: i don't understand that question | 17:19 |
| rogpeppe | bodie_: why do you need to rebase anything? | 17:19 |
| bodie_ | rogpeppe, I have a commit to charm I want to land on top of the commit history... what I normally do is rebase my changes on top of master to ensure they're compatible with the current version | 17:20 |
| rogpeppe | FWIW, i agree with fwereade about the name change | 17:20 |
| rogpeppe | bodie_: that seems usual, yes | 17:21 |
| rogpeppe | bodie_: (i often don't actually rebase, but merge then reset) | 17:21 |
| bodie_ | rogpeppe, but in this case, the version of charm in use by juju core (i.e. the hash from godeps) isn't master, unless I'm mistaken | 17:22 |
| rogpeppe | i seem to get less conflicts that way | 17:22 |
| bodie_ | interesting | 17:22 |
| rogpeppe | bodie_: that shouldn't influence how you land changes to charm | 17:22 |
| rogpeppe | bodie_: it just means that juju-core hasn't caught up with recent charm changes | 17:23 |
| bodie_ | rogpeppe, I just don't want to make a change to godeps that implicitly includes a charm version that juju isn't built against | 17:23 |
| bodie_ | i.e. if Juju is on charm version C and my change is version A (i.e. master), but A includes B because A was rebased onto B instead of onto C.... am I making sense here? | 17:24 |
| bodie_ | say B was the previous master | 17:24 |
| rogpeppe | bodie_: the entry in godeps should always reference a commit in the dependency's history | 17:25 |
| rogpeppe | bodie_: you'll just be adding to the head of that history, so juju will be pointing somewhat back in time | 17:26 |
| rogpeppe | bodie_: and when juju is ready, it can change godeps to point to the new charm master | 17:26 |
| rogpeppe | bodie_: i'm not really understanding your question in fact | 17:27 |
| rogpeppe | bodie_: godeps *specifies* which charm version juju is built against | 17:27 |
| bodie_ | right | 17:27 |
| rogpeppe | bodie_: and all that matters is the state at that actual referenced commit. if there are some commits in the history that juju was never built against, it doesn't matter | 17:28 |
| rogpeppe | bodie_: in the end, just commit to the charm repo as if juju didn't exist | 17:29 |
| rogpeppe | bodie_: then change juju to refer to the newly pushed commit by changing godeps | 17:29 |
| rogpeppe | bodie_: does that make sense? | 17:30 |
| bodie_ | rogpeppe, then, I guess my question is more about juju; I notice godeps indicates a version of charm older than master, so if I land my charm changes on top of charm master, then update godeps to the new charm master, it will implicitly include the charm master that I landed on top of, which previously wasn't in juju's deps | 17:30 |
| rogpeppe | bodie_: yeah, that's fine. it's water under the bridge | 17:30 |
| rogpeppe | bodie_: the charm package could change very frequently, but juju wouldn't need to update godeps for every commit | 17:31 |
| bodie_ | rogpeppe, I assumed that if godeps points to an older charm hash, it's because juju isn't ready to have the newer charm master | 17:31 |
| bodie_ | ah | 17:31 |
| bodie_ | hm | 17:31 |
| natefinch | bodie_: you're right that one of those new commits could break juju | 17:31 |
| rogpeppe | bodie_: it's usually a good idea to update godeps to the latest commits to all dependencies | 17:31 |
| natefinch | bodie_: (one of the ones that you didn't author) | 17:31 |
| bodie_ | natefinch, exactly | 17:32 |
| rogpeppe | bodie_: particularly for gopkg.in deps | 17:32 |
| rogpeppe | bodie_: for others, you have to be more careful because changes might not be backwardly compatible | 17:32 |
| natefinch | bodie_: there's not really anything you can do about that except try it, and if it breaks, figure out who made the intervening commits, and figure out why it broke | 17:32 |
| bodie_ | rogpeppe, regarding gopkg.in deps, that does make sense; I think my confusion about gopkg came because I had previously used gopkg for charm and been advised not to do so | 17:32 |
| natefinch | bodie_: but in theory, the whole pooint of using gopkg.in is that you're *not* supposed to make breaking changes on the same branch | 17:33 |
| rogpeppe | bodie_: but you can't do anything too bad because the 'bot will throw your PR out if the updated dep breaks something | 17:33 |
| rogpeppe | bodie_: yeah, davecheney doesn't like gopkg.in | 17:33 |
| rogpeppe | bodie_: but it's too late now | 17:33 |
| bodie_ | true, and it passes all my tests. hmm... the current charm master must be for a juju branch that hasn't landed. | 17:34 |
| rogpeppe | bodie_: and i think it makes a lot of sense, although there are potential issues too | 17:34 |
| natefinch | I don't see what the difference is, really. We could also just use github.com/juju/charm.v3 instead of a branch called v3 | 17:34 |
| rogpeppe | natefinch: except then you'd need a different repo for each version | 17:34 |
| rogpeppe | natefinch: so you couldn't share issues between them | 17:34 |
| natefinch | rogpeppe: right... .my point is, gopkg.in isn't hurting anything. It's just like using a completely different package whenever you change version numbers | 17:35 |
| rogpeppe | natefinch: yup | 17:35 |
| natefinch | rogpeppe: and it makes many things nicer, like issues on the | 17:35 |
| natefinch | repo | 17:35 |
| rogpeppe | bodie_: the recent charm changes were probably just me adding to the bundles in the charm testing dir | 17:35 |
| bodie_ | single point of failure, bus factor of one... just saying | 17:35 |
| rogpeppe | natefinch: yeah. dave's objection is to having the version encoded in the package path | 17:36 |
| rogpeppe | bodie_: it's not a spof | 17:36 |
| rogpeppe | bodie_: there are fallback servers | 17:36 |
| bodie_ | well, assuming whoever's paying for gopkg.in stops paying for it | 17:36 |
| rogpeppe | bodie_: and the code is almost trivial | 17:36 |
| rogpeppe | bodie_: you're assuming that it costs something to run | 17:36 |
| natefinch | if gopkg.in goes away ,the biggest thing we have to do is move our branches into separate repos and find/replace in the code | 17:36 |
| rogpeppe | bodie_: i suppose the domain name costs something | 17:37 |
| natefinch | or run our own redirector | 17:37 |
| bodie_ | fair enough | 17:37 |
| natefinch | rogpeppe: servers that fail over to one another generally aren't free | 17:37 |
| natefinch | rogpeppe: though I guess thinks like heroku and GAE do offer free tiers | 17:38 |
| bodie_ | yeah, I didn't mean a technical single server but rather the service itself, but I don't see it going away if people depend on it and it's foss | 17:38 |
| bodie_ | just the domain is mildly problematic | 17:38 |
| bodie_ | potentially | 17:38 |
| natefinch | bodie_: the domain name can go away ,and that's nearly as bad as the service going away. But still, all it requires is a find&replace and you're back in business. | 17:38 |
| bodie_ | haha, I'm seriously not saying I *think* this would happen | 17:38 |
| bodie_ | yeah, good point | 17:39 |
| bodie_ | heh, I always wonder how long github is going to be around | 17:40 |
| rogpeppe | bodie_: one nice thing about gopkg.in is that it needs no persistent state at all | 17:40 |
| rogpeppe | bodie_: yeah | 17:40 |
| rogpeppe | anyway, i gotta | 17:40 |
| rogpeppe | go | 17:40 |
| bodie_ | sure, take care. thanks for the advice | 17:40 |
| rogpeppe | bodie_: np, good chat | 17:41 |
| rogpeppe | g'night all | 17:41 |
| rick_h_ | thanks for the help rogpeppe, night | 17:41 |
| bodie_ | for the gopkg deprecated variable, should I mention it in README or is it sufficient to comment the variable with a TODO? | 17:52 |
| === BradCrittenden is now known as bac | ||
| natefinch | bodie_: I'd say in the code is fine | 17:56 |
| perrito666 | natefinch: meeting | 18:05 |
| perrito666 | ericsnow: likewise | 18:05 |
| stokachu | is there a situation where juju would not run kvm-ok? like maybe on an amd system? | 18:30 |
| stokachu | http://paste.ubuntu.com/8427274/, line 1484 just says kvm container creation failed | 18:30 |
| stokachu | but thats it | 18:30 |
| natefinch | is trunk broken? | 18:52 |
| natefinch | I tried to bootstrap on ec2 and it takes a long time and then says "no instances found" | 18:52 |
| natefinch | mmm.. godeps out of date.... will retry | 18:53 |
| bodie_ | can I get an LGTM on https://github.com/juju/charm/pull/53 please? | 18:56 |
| bodie_ | it's a -3/+2 pr | 18:57 |
| natefinch | and yet it took two commits | 19:01 |
| * natefinch is just giving you a hard time | 19:01 | |
| natefinch | bodie_: is that right, you just removed action-requested from unitHooks? | 19:02 |
| bodie_ | heh | 19:03 |
| === katco` is now known as katco | ||
| bodie_ | natefinch, yeah, and added Action kind | 19:03 |
| bodie_ | labeled ActionRequested DEPRECATED | 19:03 |
| bodie_ | it's just a dep for 617, is the thing, which is horribly overripe and finallyready to land | 19:04 |
| natefinch | ok, I guess? I don't know that I have a good enough idea of how this stuff is used to have any clue if you're breaking everything or not. I guess as long as no one calling UnitHooks() relies on ActionRequested being in there, that's ok. | 19:07 |
| sinzui | natefinch, bodie_ I hope both of you can help with the situation in https://bugs.launchpad.net/juju-core/+bug/1374087 | 19:10 |
| mup | Bug #1374087: Joyent is not deploying services reliably <joyent-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1374087> | 19:10 |
| bodie_ | natefinch, doesn't break juju core | 19:10 |
| sinzui | natefinch, bodie_ I don't have much information :( I can collect what you advise | 19:10 |
| bodie_ | natefinch, the goal is to prevent people from calling using an Action as a UnitHook | 19:11 |
| bodie_ | "calling using" = using... derp | 19:11 |
| natefinch | bodie_: lgtm'd | 19:15 |
| bodie_ | natefinch, thanks | 19:16 |
| natefinch | sinzui: looking | 19:16 |
| === Ursinha is now known as Ursinha-afk | ||
| natefinch | sinzui: do we have a contact at Joyent we could talk to? You'd think that a change that breaks outside users would be somethign they'd want to communicate with partners | 19:26 |
| sinzui | natefinch, I don't know who it is, but I know who I can ask | 19:27 |
| === Ursinha-afk is now known as Ursinha | ||
| jcw4 | mgz: how do we persuade CI to pick up a merge when there are LOTS of comments on the review? | 19:45 |
| perrito666 | jcw4: that should be no blocker | 19:47 |
| sinzui | jcw4, I think mgz merged his paging fix | 19:47 |
| jcw4 | perrito666: I vaguely remembered a discussion where lots of comments pushed the $$merge$$ onto a new page | 19:48 |
| jcw4 | sinzui: I see | 19:48 |
| perrito666 | jcw4: what sinzui said | 19:48 |
| jcw4 | sinzui: bodie_ is trying to land 617 | 19:48 |
| jcw4 | and it's not being noticed by CI | 19:48 |
| jcw4 | sinzui, mgz if you get a chance can you help us out in getting CI to notice that 617 is ready to land? | 19:51 |
| sinzui | jcw4, I don't have access to the machine or experience with the server | 19:52 |
| jcw4 | sinzui: okay, thanks! I don't know who else to ask... wallyworld maybe? | 19:52 |
| jcw4 | I guess he's not on | 19:52 |
| sinzui | I see the paged comment support is merged https://github.com/juju/jenkins-github-lander/commits/develop | 19:52 |
| natefinch | btw if anyone wants to lend a hand in #juju, it would be appreciated. Trying to debug one guy's mystery machine and now a second guy has come on. | 19:57 |
| jcw4 | natefinch: feel like a one armed paper hanger? | 19:57 |
| natefinch | yep | 19:58 |
| natefinch | ug... people really need to remember to update the help on commands | 20:10 |
| natefinch | juju upgrade-juju still says odd minor versions are considered development versions | 20:10 |
| hazmat | dumb golang question.. i'm looking at the ec2 provider / ec2.go ... its got a couple lines like this var _ environs.Environ = (*environ)(nil) | 20:30 |
| hazmat | is that some sort of side effect for the compiler to check? | 20:30 |
| hazmat | ie. another.. var _ simplestreams.HasRegion = (*environ)(nil) | 20:30 |
| natefinch | hazmat: yes, it's a compile-time check that environ fulfills the environs.Environ interface | 20:31 |
| natefinch | just a belt and suspenders check, really, since tests should also be checking that... but it can't hurt to have the compile-time check, too. It's useful for packages that intend to fulfill an interface, but don't actually use their type as that interface inside the package | 20:32 |
| hazmat | magical side effects ;-) | 20:34 |
| hazmat | cool | 20:34 |
| hazmat | more like inline assert instance creation cast | 20:35 |
| natefinch | sure | 20:37 |
| natefinch | except not magical at all. :) | 20:38 |
| bodie_ | any sufficiently advanced technology is indistinguishable from magic | 20:48 |
| bodie_ | :P | 20:48 |
| katco | sinzui: thank you for all your efforts with releasing 1.20.8 | 20:51 |
| sinzui | your welcome katco | 20:52 |
| bodie_ | hmmm, so how should I land 617? the CI bot doesn't seem to be picking up my $$merge$$ | 21:14 |
| bodie_ | I guess I have to wait for wallyworld? | 21:15 |
| thumper | bodie_: I wouldn't wait for wallyworld, he on holiday for a bit :) | 21:15 |
| bodie_ | thumper, any suggestions? | 21:20 |
| thumper | bodie_: which PR? | 21:20 |
| bodie_ | https://github.com/juju/juju/pull/617 @thumper | 21:21 |
| * thumper shrugs... | 21:23 | |
| thumper | I wonder if the bot is awake | 21:23 |
| bodie_ | thumper, I think so. jcw4 was saying he landed a trivial earlier today, I believe | 21:27 |
| jcw4 | yep | 21:27 |
| bodie_ | thumper, we thought it might be the pagination issue with PR comments, but apparently a fix for that was landed | 21:27 |
| bodie_ | I almost wonder if the fixed code is running on the ci server? | 21:28 |
| thumper | bodie_: I have no idea, sinzui? | 21:28 |
| bodie_ | already pinged him earlier.. | 21:28 |
| sinzui | thumper, the lander is not connected to CI. It does defer testing to CI though | 21:29 |
| bodie_ | ah | 21:29 |
| === jheroux is now known as jheroux_away | ||
| bodie_ | so this is a dead end until wallyworld is back? | 21:37 |
| ericsnow | running a local environment, should an "ubuntu" user exist on my box? | 21:40 |
| sinzui | ericsnow, the answer is NO but... | 21:44 |
| sinzui | ericsnow, there is an insane edge case that is not fixed. If your local host is a server ubuntu, you cannot delete the ubuntu user. its ridiculous because localhost on server or desktop always creates the container under the login users name, but when the os is the ubuntu server an the ubuntu user is deleted, juju trys to use it anyway | 21:46 |
| ericsnow | got it | 21:47 |
| ericsnow | thanks | 21:47 |
| sinzui | bodie_, I have a cunning plan...can you create a new pull request for your branch, and leave a comment with a link to the stuck PR and $$merge$$ | 21:53 |
| sinzui | bodie_, maybe the problem with the lander is that it is a few revs behind trunk, which has the paginated comment fix | 21:54 |
| bodie_ | sure, I'll try that. thanks sinzui | 21:55 |
| rick_h_ | thumper: working on getting back in network went boom or something | 21:58 |
| sinzui | I need to EOD now and it will be a hard reset because I need to switch to OS X to build juju and let my computer get the reboot it wanted on Monday | 21:59 |
| bodie_ | oh thank zombie baby jesus, the lander picked it up | 22:06 |
| bodie_ | anyone know what the deal is with godeps -t reporting differences even on master? I'm scouring my inbox but not seeing a discussion about a new "right way" | 22:29 |
| menn0 | thumper, waigani, davecheney: standup? | 23:00 |
| thumper | menn0: geez on the dot of 11 | 23:00 |
| === mup_ is now known as mup | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!