| rick_h | hatch: fyi https://codereview.appspot.com/13242046 | 00:47 |
|---|---|---|
| hatch | rick_h: u rock | 00:47 |
| hatch | odly enough I didn't get an email about this | 00:48 |
| rick_h | you probably did but at first it had no title since it was WIP | 00:48 |
| rick_h | the update just came through hopefully | 00:48 |
| rick_h | ok, I'm toast for the night. See you tomorrow. | 00:50 |
| hatch | thanks! have a good night | 00:51 |
| === schwuk_away is now known as schwuk | ||
| TheMue | frankban: ping | 08:41 |
| frankban | TheMue: pong | 08:50 |
| TheMue | frankban: morning | 08:51 |
| frankban | hi TheMue | 08:51 |
| TheMue | frankban: i'm currently working on https://bugs.launchpad.net/juju-core/+bug/1194945 | 08:51 |
| _mup_ | Bug #1194945: juju set is overloaded <juju-core:In Progress by themue> <https://launchpad.net/bugs/1194945> | 08:51 |
| TheMue | frankban: so on command line service options can be unset with "juju unset mysvc foo" | 08:52 |
| TheMue | frankban: and an empty string is allowed for sting options "juju set mysvc foo=" | 08:52 |
| TheMue | frankban: this leads to internal changes | 08:53 |
| TheMue | frankban: and in https://codereview.appspot.com/12867044/diff/5001/state/statecmd/config_test.go fwereade_ reminds me that it may influence the GUI | 08:53 |
| frankban | TheMue: taking a look | 08:53 |
| frankban | TheMue: so, with unset you restore a default value (as it is found in config.yaml). with set option="" you explicitly set an empty string, right? | 08:55 |
| TheMue | frankban: with that change unsetting an option with passing an empty string won't work anymore | 08:55 |
| TheMue | frankban: exactly | 08:55 |
| TheMue | frankban: and if the option is int, float or bool this would return an error | 08:56 |
| frankban | TheMue: how does this influence the behavior of the ServiceSet and ServiceUpdate API calls? | 08:57 |
| TheMue | frankban: have to take a look | 08:58 |
| TheMue | frankban: as far as i can see right now the setting mechanism works as before. only the implicit unsetting by setting the value of a setting (wow, how many settings ;) ) to "" won't work | 09:04 |
| TheMue | frankban: so the API may need a ServiceUnset too | 09:04 |
| TheMue | frankban: does the GUI uses the setting to "" for unsetting to default? or does it "only" provides settings to new values? | 09:05 |
| frankban | TheMue: maybe I am wrong, but doens't it already work passing nil values to ServiceSet? | 09:06 |
| TheMue | frankban: sadly not. it's a map[string]string, so "settings["foo"] = nil" is not possible, the value has to be a string. | 09:07 |
| frankban | TheMue: OIC, and I double checked we effectively pass values as strings in the API call. From a quick look at the code, I believe we already have a problem with the config (I suspect we pass "null" or something like that when the stripped value is empty, I need to test this). anyway, I guess we will need a UX for differentiating between the "set to empty" and "restore the default" behaviors. and yes, we might want | 09:17 |
| frankban | to implement a ServiceUnset API eventually, (or, just a crazy idea, perhaps change the ServiceSet to be map[string]*string?). | 09:17 |
| TheMue | frankban: here I would prefer the ServiceUnset, it would be more explicit | 09:18 |
| frankban | TheMue: I'll discuss this with gary_poster when he becomes available, thank you for the heads up | 09:19 |
| TheMue | frankban: how is setting to default handled from the users perspective? a button or flag? or the implicit knowledge that setting to an empty value unsets it? | 09:20 |
| TheMue | frankban: you have to thank william ;) | 09:20 |
| frankban | TheMue: AFAICT we just have input and check boxes. So I guess we don't have a story to restore boolean values to default, and for inputs/textareas we implicitly do that by setting an empty string (but I need to check). That's why I mentioned we need a UX story for the "restore defaults" semantic. | 09:23 |
| TheMue | frankban: would be cool, indeed | 09:24 |
| frankban | TheMue: ah! what happens when you unset the value? is it just deleted from the db or is the db field set to the charm default value? | 09:25 |
| frankban | TheMue: I am asking because I am curious about what we can expect to receive back from the megawatcher when you unset a config field | 09:26 |
| TheMue | frankban: how simple/complex is it to install the GUI on a local provider environment? i give a talk about juju end of October and would like to present the GUI there too. | 09:26 |
| TheMue | frankban: unsetting deletes the setting | 09:27 |
| frankban | TheMue: ok | 09:27 |
| TheMue | frankban: will add this to the release notes today | 09:27 |
| frankban | TheMue: the deploy story for the GUI is a juju charm, so it should be straightforward to deploy the GUI in a juju-core lxc env. However, never tried the local provider. If for some reason it does not work, then that's something we have to fix. | 09:28 |
| TheMue | frankban: ok, will check it | 09:29 |
| rick_h | jujugui anyone around for a second JS review of https://codereview.appspot.com/13242046/ to unblock the IE release from hatch | 11:21 |
| rick_h | frankban: that branch up for review is the card in coding in bundles? | 11:23 |
| frankban | rick_h: I can take a quick look before lunch if QA is not required | 11:24 |
| frankban | rick_h: yes, I'll move it | 11:24 |
| rick_h | frankban: hatch qa'd it already so I think it'd be safe to review sans-qa | 11:24 |
| rick_h | frankban: cool, will review the charm one and qa it when I get back from dropping the boy off at day care. I should be able to qa it with -core in lxc right? | 11:25 |
| frankban | cool rick_h, never tried the local provider (I am usually on ec2), but it's worth trying | 11:25 |
| rick_h | frankban: cool yea. <3'ing lxc provider for speed/testing | 11:26 |
| rick_h | frankban: gary wants me to get up to speed on the charm so will be fun to poke at. | 11:27 |
| frankban | rick_h: cool | 11:27 |
| frankban | rick_h: feel free to ping me if you need any help with the charm/guiserver code | 11:32 |
| rick_h | frankban: will do, thanks. | 11:32 |
| frankban | rick_h: review done | 11:54 |
| * frankban lunches | 11:54 | |
| gary_poster | hey bac. thank you for adding branch to bundle info. were you planning on adding that to API as well? I think it would be nice to have there. | 12:37 |
| bac | good point gary_poster | 12:38 |
| frankban | gary_poster: do we have a story for restoring default config values from the GUI? TheMue reported that the juju-core internals are changing: an empty string no longer means "restore default" | 12:46 |
| gary_poster | Thanks bac. Another question for you. In https://code.launchpad.net/~abentley/charms/bundles/wiki-bundle/bundle, we have three instances of the "bundle" string. Am I right that we can at least get rid of the "-bundle" or is that important for preventing some kind of name conflict? | 12:47 |
| bac | gary_poster: that portion "wiki-bundle" is user-chosen | 12:47 |
| bac | s/wiki-bundle/gary/ | 12:48 |
| rick_h | man, that N4 at $199 is screaming "take me to london" | 12:48 |
| gary_poster | frankban, interesting. Potentially connected to https://bugs.launchpad.net/juju-gui/+bug/1214087 (see comment 3) in terms of further complicating the picture. Investigating. | 12:49 |
| _mup_ | Bug #1214087: GUI fails to deploy keystone <juju-gui:New> <keystone (Juju Charms Collection):New> <https://launchpad.net/bugs/1214087> | 12:49 |
| gary_poster | bac, right, but "wiki-bundle" is a project name, right? | 12:49 |
| gary_poster | bac, so mediawiki would be a project | 12:49 |
| gary_poster | which could have bundles and charms? | 12:50 |
| gary_poster | that seems fine to me, but I wanted to make sure that you all had not identified some concern for overlap | 12:50 |
| bac | gary_poster: that name is the "basket" name, the name of the deployer file. it can contain multiple bundles | 12:51 |
| gary_poster | bac, yes, but doesn't that correspond to a project? I mean...let me get a concrete example | 12:51 |
| gary_poster | bac, so given https://code.launchpad.net/~charmers/charms/precise/mediawiki/trunk | 12:53 |
| gary_poster | huh...it is not listed in https://launchpad.net/charms/precise/+source/mediawiki | 12:54 |
| gary_poster | or https://launchpad.net/charms/+source/mediawiki | 12:54 |
| gary_poster | but still it could be | 12:54 |
| gary_poster | "mediawiki" is a package | 12:54 |
| gary_poster | so | 12:54 |
| gary_poster | https://code.launchpad.net/~charmers/charms/bundles/mediawiki/bundle | 12:55 |
| gary_poster | is a bundle for the same "mediawiki" package | 12:55 |
| gary_poster | right? | 12:55 |
| frankban | gary_poster: maybe, even if that seems more related to a check in the Keystone charm. I don't think the new behavior is already merged. But with that landed, unsetting a config passing an empty string will no longer work, and if you do that with int/float or bool config options, an error will be returned | 12:56 |
| rick_h | benji: rocks! http://askubuntu.com/questions/108689/how-can-i-get-tab-completion-with-juju-in-zsh | 12:56 |
| benji | :) | 12:56 |
| rick_h | benji: I was thinking of writing one that parsed the results of `juju help commands` | 12:57 |
| rick_h | benji: is there a good reason to not do that before I get started? | 12:57 |
| rick_h | ooh, I'll have to MP that with switch added in | 12:58 |
| gary_poster | frankban we have no GUI approach for resetting values to my knowledge. That only happens in the ghost config controls. I think we are ok for now, though we may well want an explicit way of controlling this in the future | 12:58 |
| benji | rick_h: that's what that script does | 12:58 |
| benji | see http://bazaar.launchpad.net/~benji/+junk/zsh-juju-completion/view/head:/make-completion.py | 12:58 |
| bac | gary_poster: yes, if that is how the devop chooses to name the basket. i hope this doesn't sound obtuse. if so, maybe we should talk. | 12:58 |
| benji | it was written against PyJuju though, so it could probably use some updating | 12:58 |
| rick_h | benji: ah, I was thinking of the _arguments doing that in shell | 12:58 |
| rick_h | benji: gotcha, cool. Thanks. Most helpful. | 12:58 |
| frankban | gary_poster: sounds good | 12:59 |
| gary_poster | cool thanks frankban | 12:59 |
| gary_poster | bac, but the two identical package names (for charm and bundle) should be considered to be related, yeah? | 12:59 |
| gary_poster | bac or do you consider the underlying LP concepts to be irrelevant? | 13:00 |
| benji | if we are going to be doing much with the CLI, I'd like to generate shell completion in a way inspired by how bzr does it; i.e., there is a subcommand that returns an easily parsable description of all the commands, options, etc. | 13:00 |
| rick_h | benji: ah, that's cool | 13:00 |
| rick_h | benji: yea, need some zsh subcommand completion awesomeness in there | 13:00 |
| rick_h | benji: completing service names to destroy and such would be awesome | 13:01 |
| bac | gary_poster: perhaps we can infer relevancy for the official/promulgated ones, if the ~charmers enforce a naming structure. otherwise, it is user-provided naming and therefore i don't think relevant. | 13:01 |
| benji | yep; I'm not sure how best to do it though, caching would seem manditory | 13:01 |
| rick_h | benji: yea :/ though for a first pass can wait | 13:01 |
| bac | rick_h, benji: did you see allenap's shell script for autocompleting project names within a go environment? it's pretty nice. | 13:02 |
| sinzui | gary_poster, bac, I see i walked into the middle of a conversation. charm/bundle/package names are arbitrary. Convention says they are related. They have changed and that caused confusion in the past | 13:03 |
| benji | bac: nope, I havn't. Sounds cool. | 13:03 |
| rick_h | bac: I use a forked/butchered workon script from doug hellman https://github.com/mitechie/workit to project hop | 13:03 |
| rick_h | bac: sounds similar? | 13:04 |
| gary_poster | bac ok fair enough, thanks. I'm writing a summary email of some of the stuff we discussed earlier this week, so I'm trying to get the details right. In that vein, I'm almost done with the email, but I have one other related question. In https://code.launchpad.net/~abentley/charms/bundles/wiki-bundle/bundle, the last "bundle" could be migrated to "trunk" trivially, once we are ready to go live with a new version o | 13:04 |
| gary_poster | f charmworld, right? | 13:04 |
| gary_poster | sinzui, ack, thank you. | 13:04 |
| sinzui | Novice users often try to version a package in the name and the same happened with charms. Charms don't accept charms with versions unless there are co-installable version. | 13:04 |
| sinzui | that is a rare case | 13:04 |
| abentley | gary_poster: We're changing the name of bundle branches from "bundle" to "trunk"? | 13:04 |
| gary_poster | abentley, I'm asking whether that would be trivial | 13:05 |
| bac | gary_poster: i think not. (sinzui may correct.) but if it were 'trunk' it would look just like a charm. using 'bundle' vs 'trunk' as the branch name is all that distinguishes them. | 13:05 |
| gary_poster | not the "bundles" series? | 13:05 |
| abentley | gary_poster: I think it would be trivial, for us, but it would require changes to the charm store, because it would then treat it as a charm. | 13:06 |
| gary_poster | abentley, ah! got it. thanks. | 13:06 |
| gary_poster | btw, abentley, I much appreciate your participation, but I apologize for unintentionally pinging you with those urls | 13:06 |
| abentley | gary_poster: np. | 13:07 |
| frankban | gary_poster: re always using the go sandbox in the charm when sandbox==true, I suspect we would have backward compatibility problem, i.e. someone upgrading to the new charm without updating the GUI to the (not yet released) last version. I guess this would be a problem even if we just allow sanbox mode in a juju-core env. do we care about those cases? | 13:10 |
| sinzui | bac, abentley gary_poster , trunk does conflict the store. The store will report an error, but wont break | 13:10 |
| gary_poster | sinzui, right. That adds detail to what abentley said but does not contradict it, right? | 13:11 |
| sinzui | right | 13:11 |
| gary_poster | cool thank you | 13:11 |
| rick_h | frankban: I'm getting errors about no shelltoolbox when running the make command? It looks like it's using a venv, does it not install it in the venv? | 13:12 |
| rick_h | hmm, looks like it's not in pypi, so no python package available. | 13:13 |
| frankban | rick_h: it should, it is listed in the tests/requirements.pip file | 13:14 |
| gary_poster | gotcha, frankban , your core situation is that I (a user) have an old GUI release with a new charm release, whatever the case. Mm. Thinking. | 13:14 |
| rick_h | frankban: hmm, did a make clean and trying again. Will see what's up. | 13:14 |
| frankban | rick_h: try "make clean" and male | 13:14 |
| frankban | make even | 13:14 |
| gary_poster | :-) | 13:14 |
| rick_h | frankban: oh, I'm missing something before it, a headers lib. http://paste.mitechie.com/show/1010/ | 13:15 |
| gary_poster | (and this will be the case for anyone using the ~juju-gui charm until we make the upcoming release) | 13:15 |
| frankban | gary_poster: yes | 13:17 |
| gary_poster | that's the only part that really bothers me :-P and we should have a release today | 13:17 |
| frankban | rick_h: interesting, so something is missing that is required to build apt_pkg | 13:17 |
| rick_h | frankban: yea, looking | 13:17 |
| gary_poster | hatch btw when you get in that's the third headline for this release: the sandbox mode now has a complete Juju-Core-based implementation, which is now the default | 13:18 |
| frankban | gary_poster: ok, I'll just make sure that the "go sandbox activated and used everywhere" lands after the new release | 13:18 |
| gary_poster | cool thanks frankban. you agree with that? I don't see a safe way to do anything else, really | 13:19 |
| rick_h | frankban: looks like might be libapt-pgk-dev. Retrying now | 13:19 |
| TheMue | frankban, gary_poster: the new behavior is already merged by accident. i'll now do a rollback. but we have then to find a good way for (a) setting string settings to empty strings and (b) unset settings | 13:19 |
| frankban | gary_poster: I agree with that, the only other solution would be activating features based on the gui version, but that's not simple to accomplish and probably not worth the effort | 13:21 |
| gary_poster | frankban, exactly | 13:21 |
| gary_poster | TheMue, for (a) I'm guessing the commandline is the issue? The API is straightforward AIUI: you send an empty string, and an empty string is stored. | 13:21 |
| gary_poster | In the new change I mean | 13:21 |
| rick_h | gary_poster: so based on your email my plan was to start looking at adding api3, the feature flag, etc today? or should I grab another inspector bug before heading over there? | 13:23 |
| TheMue | gary_poster: yes, sending a string leads to this string stored in case of a string setting | 13:23 |
| TheMue | gary_poster: but there's no unsetting | 13:23 |
| frankban | TheMue, gary_poster: AFAICT (b) requires a new API call or a change in the current config params (map[string]string -> map[string]*string) | 13:23 |
| gary_poster | TheMue, ok. That seems good for us for now. unsetting will be a new feature. Agree with frankban. | 13:23 |
| TheMue | gary_poster: and this has been done by sending an empty string before | 13:23 |
| gary_poster | ack | 13:24 |
| rick_h | frankban: yep, so libapt-pkg-dev is a dep to run the make command. | 13:24 |
| gary_poster | rick_h, let me see how we are doing on inspector. IE put us behind, and getting the inspector done is what we should do first to get things out the door. | 13:24 |
| rick_h | gary_poster: rgr | 13:24 |
| gary_poster | rick_h, please grab an inspector one. I'd rather have a chance to get one thing done and the other thing unstarted than be inprogress on two :-) | 13:25 |
| rick_h | gary_poster: k | 13:25 |
| frankban | rick_h: yeah, it is already listed in the HACKING.md file indeed: sudo apt-get install build-essential bzr libapt-pkg-dev python-pip \ | 13:25 |
| frankban | python-virtualenv xvfb | 13:25 |
| gary_poster | rick_h, you good with that under circumstances? | 13:25 |
| rick_h | frankban: ah, gotcha. Sorry, just went off the notes. I should have looked at it | 13:25 |
| rick_h | gary_poster: sure thing | 13:26 |
| gary_poster | cool thanks | 13:26 |
| frankban | rick_h: sorry, didn't remember that | 13:26 |
| rick_h | frankban: all good, I'm used ot charmworld having the make sysdeps so it's still in make | 13:26 |
| frankban | rick_h: so you run "sudo make sysdeps"? that seems a good idea | 13:27 |
| rick_h | frankban: yea, it's still a manual listed step so we dont' have to wait for it to run apt on every make command though. So I'd still be 'duh, didn't see that' | 13:27 |
| rick_h | frankban: but make <tab> shows the extra step | 13:28 |
| gary_poster | frankban, TheMue, from the GUI perspective, setting config values to their defaults is a non-issue. We can do it now because we can get the charm, discover the default value, and explicitly tell Juju to use that. We already have everything available to do that now, pretty trivially. The CLI would need its own solution though, and that's where that API might come in handy. | 13:29 |
| frankban | rick_h: yeah | 13:29 |
| frankban | gary_poster: agreed. from the GUI there is no difference in having the default value or no value stored in the juju-core db | 13:30 |
| gary_poster | right | 13:30 |
| gary_poster | filed #1217884 fwiw | 13:31 |
| _mup_ | Bug #1217884: Include a way to reset config values to their defaults <juju-gui:Triaged> <https://launchpad.net/bugs/1217884> | 13:31 |
| gary_poster | triaged low | 13:31 |
| gary_poster | if we get people asking for it we can reprioritize, or if someone wants to champion it on the team, cool | 13:31 |
| gary_poster | bac, looking at #1217884. Out of curiosity, how much work does it look like it would take to get Safari working? Do things mostly work, or...? | 13:33 |
| _mup_ | Bug #1217884: Include a way to reset config values to their defaults <juju-gui:Triaged> <https://launchpad.net/bugs/1217884> | 13:33 |
| gary_poster | bac sorry I meant to paste #1202408 | 13:33 |
| _mup_ | Bug #1202408: Left panel charm browser inter-cell scrolling in Safari <juju-gui:New> <https://launchpad.net/bugs/1202408> | 13:33 |
| gary_poster | This morning is apparently Gary's time to bother Brad as many times as possible | 13:34 |
| bac | gary_poster: i do not see the visual effects reported in that bug with jujucharms.com | 13:35 |
| rick_h | frankban: so when I enable the build in server I get that chrome websocket issue that came up in the call/fixed on the rapi side. | 13:36 |
| gary_poster | bac, oh! so, fix released? | 13:36 |
| rick_h | frankban: so this is our tornado server now? It needs the same fix? | 13:36 |
| bac | gary_poster: so perhaps whatever styling issues were causing it have been resolved. | 13:36 |
| gary_poster | cool. bac, more generally, though, how far away are we from Safari working well? | 13:36 |
| bac | gary_poster: or invalid. i don't think it was addressed directly just fixed as a by-product | 13:36 |
| gary_poster | ok | 13:36 |
| frankban | rick_h: yes, the browser now connects to tornado | 13:36 |
| frankban | rick_h: what version of chrome? | 13:37 |
| rick_h | frankban: ok, so I'm going to file that as a seperate bug, or find the old bug and tie to the charm | 13:37 |
| rick_h | frankban: 30 | 13:37 |
| rick_h | frankban: 31 actually as of today | 13:37 |
| rick_h | frankban: Error during WebSocket handshake: Sec-WebSocket-Protocol mismatch, the headers need to match from request to reply | 13:37 |
| rick_h | frankban: I think rapi was dropping the header? I'll have to look at the diff hazmat did | 13:37 |
| hazmat | rick_h, yeah, chrome was setting the value to undefined, i just had it return | 13:38 |
| TheMue | gary_poster: thanks for the info, will discuss it with fwereade_ , currently rolling back my last CL | 13:38 |
| hazmat | not unconditionally though | 13:38 |
| bac | gary_poster: i just poked around at it briefly and saw no issues | 13:38 |
| rick_h | frankban: ^ | 13:38 |
| bac | gary_poster: so perhaps we're really close. | 13:38 |
| rick_h | frankban: so doesn't effect this branch, but heads up | 13:38 |
| frankban | hazmat: so the server must include a Sec-WebSocket-Protocol=undefined header? | 13:39 |
| rick_h | frankban: yes | 13:39 |
| rick_h | frankban: so that they version headers match | 13:39 |
| hazmat | frankban, the server must send back what the client sent, and optionally use it to inform codec selection if it matches something known. | 13:40 |
| hazmat | frankban, fwiw upstream has change signficantly.. therve has done a lot refactoring on the twisted ws branch, though it appears to have stalled again | 13:40 |
| hazmat | frankban, oh this is with tornado? | 13:40 |
| * hazmat pokes at tornado src | 13:41 | |
| bac | gary_poster: turning on the inspector i do see some icon placement issues | 13:41 |
| hazmat | frankban, see select_subprotocol in tornado websocket.py | 13:42 |
| hazmat | probably needs to be overridden | 13:42 |
| sinzui | abentley, benji, do either of you have time to review https://code.launchpad.net/~sinzui/charmworld/search-featured/+merge/182509 | 13:42 |
| hazmat | this may just be a chrome beta/alpha bug as well | 13:42 |
| hazmat | considering it doesn't really care about the reply | 13:42 |
| abentley | sinzui: sure. | 13:42 |
| frankban | hazmat: yeah | 13:42 |
| bac | gary_poster: and big problems with ff on os x | 13:43 |
| frankban | hazmat: IIUC a "return subprotocols[0] if subprotocols else None" in select_subprotocol should do the trick | 13:45 |
| frankban | rick_h: thanks for QAing, and great to know that the GUI charm works well on a juju-core lxc provider | 13:48 |
| frankban | TheMue: ^^^^ | 13:48 |
| rick_h | frankban: yep, <3 the faster lxc local stuff. | 13:48 |
| frankban | TheMue: ^^^^ ;-) | 13:48 |
| rick_h | frankban: though I need to look into juju ssh, it uses the current username for the ssh so I had to ssh manually ubuntu@xxxx | 13:48 |
| TheMue | frankban: ah, great news | 13:49 |
| TheMue | frankban: will be a nice show to demonstrate it | 13:49 |
| frankban | rick_h: I'll start using it in place of ec2, do you have a ready-made local env conf? | 13:50 |
| rick_h | frankban: heh yea, local: type: local admin-secret: 2c6e61e81c9ad07af67f833129bef2d0 | 13:50 |
| frankban | cool, thank you | 13:50 |
| rick_h | frankban: nice short, and using juju switch to avoid the -e go and such | 13:51 |
| gary_poster | bac, ok thank you for details. | 13:51 |
| frankban | rick_h: I look forward to migrating the CI (and I guess jujucharms.com) and forget about multiple implementations ;-) | 13:52 |
| abentley | sinzui: At 310-311, do you really care about the order? If not, you can use assertItemsEqual instead. | 13:54 |
| frankban | guihelp, anyone available for a second review (no QA) of https://codereview.appspot.com/13340043 ? thanks! | 13:54 |
| sinzui | abentley, indeed I don't care. | 13:55 |
| abentley | sinzui: r=me | 13:56 |
| abentley | benji, bac, sinzui: Can we have a chat about migrations? | 13:57 |
| benji | sure | 13:57 |
| * benji finds his camera. | 13:57 | |
| sinzui | abentley, +1 | 13:57 |
| gary_poster | hey benji, could you verify that https://bugs.launchpad.net/juju-gui/+bug/1202413 is still an issue? I just tried it on saucy's FF 23 and it is OK | 13:58 |
| _mup_ | Bug #1202413: Relation drag line persists after clicking <juju-gui:Triaged> <https://launchpad.net/bugs/1202413> | 13:58 |
| gary_poster | benji I tried it on jujucharms and comingsoon | 13:58 |
| abentley | sinzui: guichat | 13:59 |
| adeuring | abentley: could you have a look at the changes in this branch lp:~adeuring/charmworld/spurious-failures ? I know that some stuff can be refactored -- my main point is so far to just reduce test failures... Comments should show why I made each change | 13:59 |
| abentley | adeuring: On a call, but I can look after. | 13:59 |
| * hatch crosses finger final qa doesn't break ;) | 14:02 | |
| * gary_poster crosses toes | 14:03 | |
| gary_poster | easier to type but harder to walk | 14:03 |
| hatch | haha | 14:03 |
| rick_h | hatch: stop poking the bear! :P | 14:07 |
| rick_h | hatch: actually, it's good stuff. We've found some legit bugs along the way so appreciate the firm stabbing at things | 14:07 |
| gary_poster | dran straight! | 14:08 |
| gary_poster | darn, even | 14:08 |
| rick_h | if we're down to the bugs darn near impossible to figure out, then must mean we're getting down to the last ones | 14:08 |
| * rick_h can hope at least! | 14:08 | |
| Makyo | Last bugs. I like it. | 14:17 |
| hatch | haha | 14:21 |
| === schwuk is now known as schwuk_away | ||
| hatch | *sigh* | 14:29 |
| rick_h | hatch: guichat? | 14:30 |
| hatch | sure | 14:31 |
| hatch | busy | 14:31 |
| hatch | gary_poster: I think we need to roll the core-backend debug change back | 14:38 |
| hatch | rick_h: is just testing core right now | 14:39 |
| hatch | but the sandbox is definitely broken when creating relations | 14:39 |
| gary_poster | hatch ok. you mean the default, right? | 14:39 |
| hatch | yep | 14:39 |
| gary_poster | hatch, ack. +1 on doing that and getting this release out the door | 14:39 |
| hatch | ugh lots of test failures when I switch back | 14:44 |
| === schwuk_away is now known as schwuk | ||
| hatch | trying now with only the config changed but the default still at go | 14:44 |
| gary_poster | hatch, look for that commit and try reverting the commit | 14:45 |
| hatch | gary_poster: if I set the default to 'go' and then set the configs to 'python' the tests all pass | 14:47 |
| gary_poster | hatch, heh ok | 14:48 |
| gary_poster | hatch, and it still works? :-P | 14:48 |
| hatch | it appears so :) | 14:48 |
| hatch | so looks like we won't be setting go as the default for now | 14:49 |
| hatch | now when someone calls me on hangouts, my computer, tablet, cell phone all ring....it's a little much haha | 14:50 |
| rick_h | hah | 14:50 |
| benji | This is a public apology to bac for incorrectly correcting his use of "monotonically increasing"; he was right, I was wrong. Let this be a less on to the rest of you... or something | 14:51 |
| * rick_h bows before the great and powerful bac | 14:52 | |
| gary_poster | hatch, ok. that slows down other tasks--frankban has a branch that was going to switch that so we could move forward with bundles. but...frankban, eh, let's talk. I think maybe we can still move forward. It will just be a bit riskier. :-/ | 14:52 |
| gary_poster | he has a charm branch that was going to switch the sandbox there to use go, I mean | 14:52 |
| rick_h | gary_poster: yea, there's a real bug/issue with the ondelta model event that's either not calling or getting the right thing. | 14:53 |
| hatch | gary_poster: I could take a 30min timebox to try and fix | 14:53 |
| gary_poster | luca__, do we have an agenda for webteam call? we will see them in a week, and we potentially have some important things to talk about then, but if there's no topics immediately let's skip it (again) | 14:53 |
| luca__ | gary_poster: I thought I cancelled it yesterday =O | 14:54 |
| gary_poster | luca__, oh cool. Sorry, just my phone not catching up to the times then :-P sorry, thanks | 14:54 |
| luca__ | gary_poster: no worries, how is everything? | 14:54 |
| gary_poster | hatch, yes, if you are up for it. Maybe pair with Makyo, or me? | 14:55 |
| hatch | ok gimme a few minutes to track it down | 14:55 |
| gary_poster | thanks hatch | 14:55 |
| frankban | gary_poster, hatch: so there is a problem in building relations in the go sandbox? | 14:56 |
| gary_poster | luca__, hectic. post-vacation catch up combined with more re-prioritization discussions and discussions about Dustin's feedback :-) | 14:56 |
| gary_poster | luca__, looking forward to seeing juju.ubuntu.com 1.0 or whatever it is called Monday :-) | 14:57 |
| hatch | frankban: yes models.js:975 calls the handler with the wrong information | 14:57 |
| hatch | currently looking into the fix | 14:57 |
| luca__ | gary_poster: haha, hopefully it looks good :) I'll give you a sneak peak when it's in a better shape. | 14:57 |
| frankban | hatch: thank you | 14:57 |
| hatch | frankban: and it's all your fault :P | 14:57 |
| gary_poster | cool luca__ :-) | 14:57 |
| luca__ | gary_poster: would you like to catchup on anything tomorrow? | 14:57 |
| frankban | hatch: that's surprising! | 14:58 |
| hatch | lol | 14:58 |
| hatch | so it appears that the delta that's coming back isn't including the endpoint data | 15:03 |
| frankban | hatch: isn't that code used also for real environments? if so, why relations work in real envs? | 15:03 |
| hatch | frankban: rick_h tried it in a real env and it didn't error | 15:04 |
| hatch | so possibly sandbox issue? | 15:04 |
| rick_h | hatch: but the service also didn't come up since it was in error | 15:04 |
| frankban | hatch: more probably, yes | 15:04 |
| hatch | frankban: here is the delta data https://gist.github.com/hatched/6367087 | 15:05 |
| hatch | which I'm certain is incorrect | 15:05 |
| frankban | hatch: perhaps you can take examples of how the delta should be from the test_model_handlers.js file, starting from line 351 | 15:07 |
| hatch | frankban: thanks I'll check it out | 15:08 |
| Makyo | jujugui units binding of service-overview viewlet does not work in FF against a real core env. Any ideas? | 15:10 |
| Makyo | (in trunk) | 15:10 |
| gary_poster | Makyo, works in chrome? | 15:11 |
| Makyo | gary_poster, I haven't checked yet, currently in the process of deploying the charm. | 15:11 |
| gary_poster | ack, Makyo. Worth a check; I'd assume it is browser agnostic, and a diff between our sandbox and the real world, but would be good to verify | 15:12 |
| Makyo | gary_poster, yep. Just can't test from local devel server in chrome. | 15:12 |
| gary_poster | oh :-/ | 15:12 |
| gary_poster | k | 15:12 |
| gary_poster | Makyo, old pre-inspector interface works | 15:13 |
| gary_poster | ? | 15:13 |
| abentley | bac: I'd like to re-enable test_ensures_category_questions. Can you describe the spurious test failures that caused you to disable it in https://code.launchpad.net/~bac/charmworld/spurious-test-failures/+merge/181418 ? | 15:13 |
| Makyo | Checking. | 15:13 |
| Makyo | gary_poster, yes. | 15:14 |
| gary_poster | k | 15:14 |
| hatch | frankban: somewhere between sandbox.js:handleClientAddRelation and sandbox.js:receiveNow it loses the Endpoints object :/ | 15:14 |
| bac | abentley: the test failed. spuriously. these failures are what prompted abel's investigation, that is on-going. he did seem to correlate some failures with slower machines. | 15:15 |
| abentley | bac: Were there any particular error messages you got? | 15:15 |
| bac | abentley: i do not recall the exact error conditions for each failure | 15:15 |
| bac | abentley: i'd suggest talking with adeuring | 15:17 |
| gary_poster | Makyo, hatch is deep in release. I have no further ideas without digging. Would you like a pair with me or rick_h, or an initial timebox investigation? The obvious thing to me is to suspect the deltas; dunno | 15:17 |
| Makyo | gary_poster, I know where it's going wrong, if it is, will update once I can test from the charm | 15:18 |
| gary_poster | Makyo, cool ty | 15:18 |
| abentley | bac: Please report spurious failures more thoroughly. Even a paste from the console would be very useful to me now. | 15:18 |
| adeuring | bac, abentley: as far as I understand the problem currently, it seems that ES is sometimes just a bit slow, especially when an index is created, deleted or when its mapping is changed. I have a branch that catches many errors. | 15:19 |
| abentley | adeuring: I'm looking at that branch you asked me to earlier. I assume it's the same? | 15:19 |
| adeuring | abentley: yes, that's the one I meant | 15:20 |
| bac | abentley: there were a set of about 6 tests that were failing in various combinations or not at all. they were reproducible by sinzui and adeuring in trunk. the failures were blocking the landing of other work. the work to fix them was handed off to adeuring. | 15:21 |
| adeuring | well, I got meanwhile errors/failures in many more tests.... | 15:21 |
| hatch | when base.js fires a 'msg' event, can someone tell me what listens for that event? | 15:22 |
| hatch | grep is failing me.... | 15:22 |
| bac | abentley: in the future attaching a failure report to a bug referenced in an XXX when disabling the tests is a fine idea | 15:22 |
| abentley | bac: Thanks. | 15:22 |
| adeuring | some problems still remain, but they look to me like real ES errors, like this one: sending faile | 15:23 |
| adeuring | d shard for [temp_index][3], node[gWVu1uWMSvegY4D7uW2c7g], [R], s[INITIALIZING], reason [F | 15:23 |
| adeuring | ailed to start shard, message [RecoveryFailedException[[temp_index][3]: Recovery failed fr | 15:23 |
| adeuring | om [Ezekiel][6hy-kGs5Qwe5OSuRjxJrXw][inet[/192.168.2.30:9300]] into [Gregory Gideon][gWVu1 | 15:23 |
| adeuring | uWMSvegY4D7uW2c7g][inet[/192.168.2.209:9300]]]; nested: RemoteTransportException[[Ezekiel] | 15:23 |
| adeuring | [inet[/192.168.2.30:9300]][index/shard/recovery/startRecovery]]; nested: RecoveryEngineExc | 15:23 |
| adeuring | eption[[temp_index][3] Phase[2] Execution failed]; nested: RemoteTransportException[[Grego | 15:23 |
| adeuring | ry Gideon][inet[/192.168.2.209:9300]][index/shard/recovery/prepareTranslog]]; nested: Engi | 15:23 |
| adeuring | neCreationFailureException[[temp_index][3] failed to create engine]; nested: LockObtainFai | 15:23 |
| adeuring | ledException[Lock obtain timed out: NativeFSLock@/var/lib/elasticsearch/elasticsearch/node | 15:23 |
| adeuring | s/0/indices/temp_index/3/index/write.lock]; ]] | 15:23 |
| hatch | ignore me, I missed the defaultfn | 15:24 |
| adeuring | restarting the ES server seems to help | 15:25 |
| abentley | adeuring: Have you tried ElasticSearchClient.wait_for_startup rather than calling health directly? | 15:27 |
| adeuring | abentley: yes, the "yellow" status is quite often not enough. | 15:27 |
| abentley | adeuring: Ah. | 15:27 |
| * gary_poster laughs at still having "yellow" ping him | 15:27 | |
| adeuring | abentley: and even the "green" status sometimes not suffient. but a refresh() call seems to help in this case | 15:28 |
| Makyo | Ugh, I've made this change before, I know I have >:/ | 15:29 |
| abentley | adeuring: This makes me worry that the calls may not be fixing the problem, merely delaying execution, and coincidentally fixing the problem. | 15:30 |
| abentley | Most of the time. | 15:30 |
| rick_h | Makyo: maybe made it in the python side and never got to the go side? Now with go default it's hitting again? | 15:30 |
| adeuring | abentley: that's possible. OTOH, it seems that ES responds for several requests before "the work is really finished", so waiting for a certain status may help indeed. | 15:32 |
| Makyo | rick_h, it's go only; we're just not passing an argument (and if that argument's undefined, it exits). I could've sworn I fixed this in the branch where I first added the unit list to the inspector. | 15:32 |
| rick_h | Makyo: ok, yea just tossing idea out there on 'what's changed recently' to trigger it | 15:32 |
| adeuring | abentley: and I don't see any better way to query the status of the ES server... | 15:32 |
| abentley | adeuring: Yes, the health is reasonable, it's the refresh that I worry about. | 15:32 |
| Makyo | rick_h, Yeah, now I'm confused too, because the code's there in trunk in the source, but not in the compressed prod file (at least, according to source maps) | 15:33 |
| rick_h | Makyo: orly, now that's interesting | 15:33 |
| rick_h | Makyo: cache? or build step issue for new js files ? | 15:34 |
| adeuring | abentley: well, the documenntation of refresh() says "making all operations performed since the last refresh available for search", so calling it should have some effects | 15:34 |
| abentley | adeuring: Right, but if the only operation was creating the index, I would expect that health was the only thing I had to wait for. | 15:34 |
| Makyo | rick_h, yeah, I'm not sure! Poking around further. | 15:35 |
| adeuring | abentley: maybe I need to check where exactly I added refresh() calls, but right now I see just one after a run_migration() call. And that call could do more that just create/delete indexes. I would beed to check more closely though to be sure... | 15:36 |
| abentley | adeuring: we'll be deleting those migrations anyway, so spurious test failures there don't matter. The only migration code we're keeping is the bit where we ensure category questions. | 15:38 |
| Makyo | rick_h, gary_poster - alright, I found it. It's disappointing. rick_h no clue why the sourcemaps are showing out-of-date code, maybe they weren't generated properly. The issue at the heart of it, though, is that we're now getting units before services. When we get unit-adds, we try to update the list of units stored with the service, which doesn't exist yet. That list is what's bound in the inspector. | 15:40 |
| gary_poster | Makyo, ah. :-/ | 15:41 |
| adeuring | abentley: right, but I saw also errors in test_search.py, for example. And they were not related to migrations either... | 15:41 |
| abentley | adeuring: Right, I | 15:41 |
| adeuring | so I think at least the changes I made to testing.__init__ are useful | 15:42 |
| * gary_poster wants time for more reliable, non-canonistack testing against juju core. | 15:42 | |
| abentley | adeuring: Right, I'm talking about the tests of migrations, since that's what you mentioned. I know that there are other tests that you updated. | 15:42 |
| hatch | timebox is up and I have no idea what's going on | 15:42 |
| gary_poster | Makyo, I think we talked about this possibility way back when and had an idea of how to approach it. | 15:43 |
| hatch | somewhere between receiving the delta and the onDelta call the endpoints get lost - but even the d3 stuff gets the proper data | 15:43 |
| Makyo | gary_poster, Yeah, sort by delta type to maintain the hierarchy. Investigating that now. | 15:44 |
| gary_poster | Makyo, cool thanks | 15:44 |
| gary_poster | hatch ok. we have 16 min till call.. | 15:44 |
| gary_poster | hatch, futz with it for 16 more min, hope for a miracle, and we'll figure out what to do after call? | 15:44 |
| hatch | sounds good | 15:45 |
| gary_poster | thanks | 15:45 |
| abentley | adeuring: Maybe in temp_index_client, you can do client._client.health(client.index_name, wait_for_status='green') instead ofclient.wait_for_startup. Then you won't need to do it at the bottom, so we avoid an unnecessary call. | 15:46 |
| gary_poster | frankban, LGTM with super trivial typo fix | 15:47 |
| adeuring | abentley: Right, might be worth a try | 15:48 |
| frankban | gary_poster: thank you | 15:48 |
| abentley | adeuring: at charmworld/migrations/versions/tests/test_migrations.py:285, the refresh call should not be doing anything, because index_charm always does a refresh. | 15:48 |
| Makyo | jujugui call in 10 kanban now | 15:50 |
| rick_h | jujugui small css review with qa please https://codereview.appspot.com/13347043 | 15:50 |
| adeuring | abentley: really? With these spurious errors it is hard to be sure that a change really helped, but I am pretty sure that the added call made a difference. But that could be in indication that it's just the added minor delay that helped... | 15:51 |
| abentley | adeuring: Would we save a lot of code by hardcoding wait_for_startup to "green"? I only chose yellow because it seemed to work. | 15:51 |
| adeuring | abentley: sure, I intended at least to add something like "wait_for_green", but a change to wait_for_startup() would do it too | 15:52 |
| abentley | adeuring: Really: search.py:284 sez "refresh=True". | 15:52 |
| adeuring | ok... | 15:52 |
| * adeuring becomes scared by ES | 15:52 | |
| gary_poster | rick_h, nice approach to z-index. We should doc somewhere. We might forget, but a doc somewhere is better than nothing at all :-P | 15:53 |
| rick_h | gary_poster: rgr, will find a place to not it, maybe a giant comment in the top of stylesheets.less | 15:53 |
| rick_h | to note* | 15:53 |
| gary_poster | rick_h, maybe so, or in rest doc...downsides to both. | 15:54 |
| gary_poster | whichever. something is better than nothing. :-) | 15:54 |
| rick_h | gary_poster: yea, thought about rst docs but didn't see anything that fit and adding another doc was :/ | 15:55 |
| gary_poster | understood. at some point we should actually have a doc that talks about when to have a new less doc and so on, but doesn't need to be now | 15:55 |
| gary_poster | rick_h, gave you a non-qa LGTM, now you just need the real one ;-) | 15:56 |
| rick_h | gary_poster: :) thanks | 15:57 |
| Makyo | jujugui call in 1 | 15:59 |
| frankban | hazmat: when you have a chance, coul you please review https://code.launchpad.net/~frankban/juju-deployer/guiserver-changes/+merge/182369 ? | 16:15 |
| hazmat | frankban, ack, in uds sessions atm | 16:15 |
| frankban | hazmat: thanks, no rush | 16:15 |
| === TheRealMue is now known as TheMue | ||
| Makyo | jujugui https://codereview.appspot.com/13350043 fix for ordering deltas (for showing units in the inspector) | 16:38 |
| bcsaller | hatch: can I get 10 minutes before we pair on the other, I need coffee | 16:57 |
| rick_h | bcsaller: I'm going to grab food, let me know if the re-propose diffs better or else I'll go find the branch and pull it down | 16:57 |
| Makyo | jujugui can I get at least one review on ^^^ - Doesn't need to land before the release, but does need to be a part of my branch, and I don't want to stack too deep. | 16:57 |
| hatch | bcsaller: sure thing | 16:58 |
| rick_h | Makyo: looking | 16:58 |
| Makyo | rick_h, thanks. | 16:58 |
| hatch | FYI there is a big movement in the node.js communities to sharing templates between the server and client side - so this is a solved problem as long as python has the proper tools | 16:59 |
| Makyo | At least, I don't think it needs to land before the release. A fix in place would certainly be nice. | 16:59 |
| rick_h | hatch: yes, except the issue we've got is that there's a lot of JS in our Y.Views to take api data to the template that would have to be duped | 16:59 |
| hatch | rick_h: no, abstracted :) | 17:00 |
| rick_h | hatch: it's a rabbit hole. Two projects with different uses never will agree 100% | 17:00 |
| === schwuk is now known as schwuk_away | ||
| rick_h | Makyo: replied | 17:01 |
| hatch | well tbh in my mind I see them sharing very few templates as the GUI will no longer have a fullscreen view | 17:01 |
| Makyo | rick_h, thanks. | 17:01 |
| rick_h | hatch: heh, the fullscreen is 90% sidebar with different max-widths :P | 17:02 |
| hatch | haha well ok then they don't 'need' to be shared - they can be allowed to diverge because they are no longer one | 17:03 |
| hatch | but honestly though we COULD render the gui under the fullscreen browser | 17:04 |
| hatch | which would allow us a quick initial load time AND the gui available | 17:04 |
| hatch | I just want one url for everything | 17:04 |
| hatch | which I think is what others also agree with | 17:04 |
| bcsaller | Makyo: are you sure the delta sorting reflects the real env? It looks like it could but we can't depend on it if its not the case | 17:05 |
| Makyo | bcsaller, how do you mean? The issue at hand is that we can't add units to service.units if service doesn't exist in the db yet. | 17:06 |
| bcsaller | I get that, I just want to be that it doesn't reflect a real difference in the way sandbox does deltas vs the live env | 17:07 |
| Makyo | bcsaller, it does, as of at least juju-core 1.13.2. The only difference I see, however, is in the order of the deltas, and this would normalize in both cases. | 17:08 |
| bcsaller | Makyo: sounds good, thanks | 17:09 |
| Makyo | Still miffed about the no newlines in debug-log, though. Impossible to see in there. | 17:09 |
| hatch | bcsaller: 10mins have passed :P | 17:13 |
| rick_h | Makyo: yea, that's annoying as can be | 17:14 |
| bcsaller | hatch: yeah, I stiill owe rick a review on his branch, trying to get through that now and then I'll ping you | 17:14 |
| hatch | :D sure np | 17:14 |
| Makyo | rick_h or bcsaller can you re ±1 https://codereview.appspot.com/13350043? Modified slightly so that we don't do arithmetic on 'undefined'. | 17:21 |
| bcsaller | Makyo: done | 17:24 |
| Makyo | bcsaller, thanks | 17:25 |
| Makyo | jujugui (notably hatch) alright if I land this branch, or want to wait for after release? | 17:26 |
| hatch | Makyo: land it - if it turns out we can't quickly fix this go issue then it won't be touched anyways | 17:27 |
| Makyo | hatch, cool, thanks. | 17:27 |
| bcsaller | hatch: ready when you are | 17:33 |
| hatch | lets do it! | 17:33 |
| sinzui | I can tell this is going to be a good 5 hours of coding, Sweet Transvestite from The Rocky Horror Picture Show starts my coding session | 17:55 |
| abentley | I see you shiver with annntici.... | 17:56 |
| sinzui | pation | 17:56 |
| abentley | Oh, that's right. You used to always have the currently playing track in your bzr commit messages. | 17:57 |
| gary_poster | hatch, I figure you are hacking. ping me when you want to talk. don't want to get in your way | 18:00 |
| hatch | gary_poster: now is fine | 18:00 |
| hatch | bcsaller: is just trying some things | 18:00 |
| gary_poster | cool hatch joining | 18:00 |
| hatch | bcsaller: guichat? | 18:10 |
| bcsaller | hatch: one sec, finishing a test | 18:10 |
| bcsaller | hatch: ok | 18:12 |
| hatch | gary_poster: do you know what your power adapter is called? | 18:12 |
| gary_poster | looking | 18:12 |
| gary_poster | hatch http://www.amazon.com/gp/product/B003UHYDYO | 18:13 |
| hatch | Makyo: can you join us in guichat? | 18:16 |
| hatch | gary_poster: after some more research we think we can pop out a fix in ~1H | 18:22 |
| gary_poster | hatch great! thank you! | 18:30 |
| gary_poster | and thanks bcsaller and Makyo | 18:30 |
| Makyo | Just upgraded a real service from the gui, woo. Good to see this stuff actually working. | 18:34 |
| hatch | boo yeah! Fixed | 18:35 |
| bcsaller | hatch: oh, you got it, great | 18:49 |
| hatch | yeah but for some reason the relation id is 'undefined undefined' | 18:49 |
| hatch | so trying to track that down... | 18:50 |
| bcsaller | it was called Key and is the above whitelist, you can turn that into a function if you need some more complex mapping | 18:50 |
| hatch | ahh thanks | 18:51 |
| hatch | any idea if the interface is on the endpoint? | 18:51 |
| hatch | I can't seem to find two services that supply one haha | 18:51 |
| bcsaller | hatch: I think that is name | 18:57 |
| bcsaller | sorry, was making more coffee | 18:57 |
| hatch | bcsaller: guichat? | 18:58 |
| bcsaller | rick_h: don't know if you saw, the CR didn't improve but I noted how to generate the diff, if you really can't review it at this point I can try deleting the MP and creating a new branch, but let me know | 18:59 |
| bcsaller | hatch: I'm there | 18:59 |
| rick_h | bcsaller: no, completely missed it and forgot about it. Sorry | 18:59 |
| bcsaller | rick_h: understood :) | 19:00 |
| * rick_h kills offlineimap and goes to look at what's up | 19:00 | |
| rick_h | holy moley! | 19:01 |
| rick_h | oh, that's trunk...ugh | 19:02 |
| sinzui | abentley, rick_h: My mind is boggling at a test failure. Before I change routing, I am adding tests for the similar routes. The json route tests always fail because there is not content-type (this is an implicit test in the test helper). While I can see the json view helper thinks it is adding content-type, I think it os borked. Can you confirm that http://staging.jujucharms.com/~gnuoy/precise/apache2-1/json doesn't have a con | 19:16 |
| sinzui | tent type? | 19:16 |
| rick_h | sinzui: don't see content-type headers | 19:17 |
| abentley | sinzui: Confirmed. | 19:17 |
| sinzui | Will the gui hate me if I ensure content-type is application/json | 19:17 |
| rick_h | sinzui: no, but 'just hitting' a url will hat eyou | 19:19 |
| rick_h | e.g. I can just pop an api url into my browser and see the json like I'm doing right now to look at gary_poster's bug request question | 19:19 |
| rick_h | sinzui: or do you mean only ensuring it's in the response? | 19:20 |
| sinzui | looks like webob.Response(json, content_type=u"application/json") doen't add the header | 19:20 |
| rick_h | sinzui: no, three's a headers thing to change | 19:21 |
| rick_h | sinzui: see the OPTIONS request stuff | 19:21 |
| rick_h | sinzui: I think it's request.response.headers? | 19:21 |
| sinzui | rick_h, we are passing headers as headerlist=[...] adding Content-Type fixes the response, but will that break the gui? | 19:22 |
| rick_h | sinzui: We can double check, but I don't think adding a content-type of json in the response will cause us any issues | 19:23 |
| sinzui | oh, are we still using /json? That is the old API point. | 19:23 |
| sinzui | Well people in the wild probably are | 19:24 |
| rick_h | sinzui: oh, that's the old old stuff. /me missed that | 19:24 |
| sinzui | oh, looks like headerlist is mutually exclusive to adding headers as separate args. | 19:27 |
| rick_h | bcsaller: I was having a hard time without hte rest of the file for context. Re-sub'd it as WIP just ot look at it https://codereview.appspot.com/13361043 | 19:32 |
| bcsaller | rick_h: oh, thank you | 19:34 |
| rick_h | bcsaller: is there no way to share this code between service.js and bundle.js? | 19:42 |
| bcsaller | rick_h: there should be, yes, sorry, still on a call | 19:44 |
| rick_h | bcsaller: k, np. | 19:45 |
| bcsaller | rick_h: I didn't have any UX when I stared so I just took what I could to move on, but a base mixin makes sense | 19:45 |
| rick_h | bcsaller: ok, well looked it over put notes in https://codereview.appspot.com/13361043/ but not comfy landing so much code dupe | 19:48 |
| bcsaller | rick_h: thanks, thats fine feedback and shouldn't be that long to fix | 19:48 |
| rick_h | bcsaller: cool | 19:48 |
| hatch | gary_poster: can you pop into guichat? | 19:57 |
| gary_poster | ok hatch | 19:57 |
| * Makyo -> vet | 20:09 | |
| hatch | gary_poster: https://bugs.launchpad.net/juju-gui/+bug/1218061 for your email | 20:21 |
| _mup_ | Bug #1218061: Duplicate relations created when using the go sandbox <juju-gui:Triaged> <https://launchpad.net/bugs/1218061> | 20:21 |
| gary_poster | hatch, heh, thanks | 20:22 |
| abentley | orangesquad, bac or benji: Could you please review https://code.launchpad.net/~abentley/charmworld/remove-migrations/+merge/182756 ? | 20:32 |
| * sinzui looks | 20:33 | |
| bac | abentley: sure | 20:33 |
| abentley | bac: Thanks. | 20:33 |
| bac | thanks abentley, looks good | 20:41 |
| abentley | bac: Thanks for the reminder about docs. I'll do that. | 20:41 |
| hatch | are there any plans to collapse the charms in the sidebar to a single one with a dropdown to select the series? | 20:48 |
| hatch | or even to only display the series which applies to the current env? | 20:48 |
| rick_h | hatch: when doing a search? | 20:49 |
| rick_h | hatch: that's part of what needs to be figured out in jcsackett's work | 20:49 |
| hatch | yeah there are 4 ceph-osd's one for each series | 20:49 |
| hatch | probably woudln't be clear for a n00b what the difference is | 20:50 |
| rick_h | hatch: yea, that's what we want to put in front of UX. There was talk of showing series info on the charm token, etc at one point | 20:51 |
| hatch | I'd vote for a dropdown in the charm details | 20:51 |
| hatch | buuut maybe ceph-osd is a odd one out having so many different versions | 20:51 |
| gary_poster | rick_h, you filed a bug or sent an email or anything? if not, do you want me to? | 20:54 |
| abentley | bac: Docs updated: https://code.launchpad.net/~abentley/charmworld/remove-migrations/+merge/182756 | 20:55 |
| bac | abentley: looks good | 20:57 |
| rick_h | gary_poster: on? | 20:58 |
| gary_poster | <rick_h> hatch: yea, that's what we want to put in front of UX. There was talk of showing series info on the charm token, etc at one point | 20:58 |
| rick_h | gary_poster: this is tied to the 'all category' bug and the UX improvements requested there that jcsackett is working on. | 20:59 |
| rick_h | gary_poster: the goal is to kill the filters, group into two parts, and then show UX to get suggestions on where they want to clean up the issues remaining | 20:59 |
| rick_h | gary_poster: so not a bug on it, and it's been hashed over in calls/etc in the past. | 20:59 |
| gary_poster | rick_h, oh...it seems only tangentially related, but as long as it is coming up with them I guess that is AOK | 20:59 |
| gary_poster | than kyou | 21:00 |
| hatch | jujugui looking for a QA/review on https://codereview.appspot.com/13366043/ for release | 21:06 |
| Makyo | On it | 21:06 |
| hatch | thanks | 21:06 |
| gary_poster | hatch, gave you LGTM without qa | 21:07 |
| hatch | OOooo riskay! | 21:07 |
| gary_poster | heh | 21:09 |
| Makyo | hatch, lgtm | 21:16 |
| hatch | thanks! | 21:16 |
| hatch | gary_poster: https://gist.github.com/hatched/fb98cc122380e74a0ad2 version notes | 21:36 |
| gary_poster | hatch for line 2, "almost finished"? :-) or "significant progress on" | 21:38 |
| gary_poster | for line 5, past tense for consistency ("Fixed") | 21:38 |
| gary_poster | for line 10, "user"? | 21:38 |
| gary_poster | Maybe move lines 6 and 7 to the top, since they are the headliners? | 21:39 |
| gary_poster | or do none of that. :-) It's good, thank you! | 21:39 |
| gary_poster | hatch ^^ | 21:39 |
| hatch | all done! | 21:39 |
| hatch | :) | 21:39 |
| hatch | thanks | 21:39 |
| * gary_poster steps away. thank you all, and see ya tomorry | 21:41 | |
| hatch | cya! | 21:43 |
| * hatch wonders what LP does when making a release that takes 10+min | 22:08 | |
| hatch | surely LP has to be more powerful than my mini running two VM's :D | 22:09 |
| hatch | jujugui 0.9.0 has been released! | 22:14 |
| bcsaller | woot | 22:14 |
| hazmat | nice | 22:47 |
| huwshimi | Morning | 23:08 |
| hatch | hi huwshimi how's it going? | 23:12 |
| huwshimi | hatch: Good thanks, yourself? | 23:13 |
| hatch | good good | 23:13 |
| hatch | huwshimi: so are you still on GUI stuff or on to other things? | 23:51 |
| huwshimi | hatch: Working on charmworld at the moment | 23:54 |
| hatch | ahh cool cool | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!