hatch | jcsackett ahh thanks | 01:53 |
---|---|---|
hatch | huwshimi so any luck tackling it on your own? | 01:54 |
huwshimi | hatch: I didn't mange to figure out anything yesterday :( | 01:54 |
hatch | ok cool, I'll take a look | 01:55 |
huwshimi | thanks heaps | 01:56 |
hatch | huwshimi what if you include the juju-templates? | 01:56 |
hatch | asically the error is because it can't find the element in the dom | 01:56 |
huwshimi | I'll try | 01:58 |
huwshimi | hatch: No change | 01:59 |
hatch | blarg | 02:00 |
hatch | ok I've pulled it down | 02:01 |
hatch | will investimagate | 02:01 |
huwshimi | hatch: Feel free to leave it to your work day, I have plenty to go on with. | 02:02 |
hatch | huwshimi it's because it's rendering without the mv flag | 02:12 |
hatch | it's rendering the old scaleup UI | 02:12 |
hatch | if you put a debugger in the method that's failing and inspect the innerHTML of the container you can see this | 02:12 |
huwshimi | Oh | 02:13 |
hatch | huwshimi that's because the createServiceInspector method is no longer how we render the inspectors while under mv | 02:14 |
hatch | so this is actually testing a path which is no longer valid | 02:14 |
hatch | so really - the proper fix is to fix the way inspectors are rendered | 02:15 |
hatch | for tests | 02:15 |
hatch | but you may be able to hax around it by setting the mv flag and doing some other bits | 02:16 |
huwshimi | yep, trying | 02:27 |
hatch | huwshimi any luck? | 02:59 |
huwshimi | hatch: Just having some lunch... | 03:02 |
hatch | ok cool, I think I'm gona head and watch some tv, if you can't get it just leave the PR and I'll take a look in the am | 03:02 |
hatch | have a good one | 03:04 |
=== uru_ is now known as urulama | ||
=== uru_ is now known as urulama | ||
rogpeppe | urulama: morning! | 07:21 |
urulama | rogpeppe: hey there | 07:21 |
urulama | rogpeppe: how's it going? | 07:22 |
huwshimi | rogpeppe, urulama: Morning | 07:23 |
rogpeppe | urulama: not bad thanks | 07:23 |
urulama | rogpeppe: i'm trying to finish the "sprint summary" document so that i can move forward with the implementation part, but it's taking tiiiiime :) | 07:23 |
rogpeppe | urulama: have you recovered from last week yet? | 07:23 |
urulama | huwshimi: good evening ;) | 07:23 |
huwshimi | :) | 07:23 |
urulama | rogpeppe: em ... partly recovered. progress bar at around 33% :) | 07:23 |
rogpeppe | urulama: :-) | 07:24 |
urulama | rogpeppe: we have a national holiday on Friday, might help to move to 50% :) and it's good to put things on paper as long as they are still in memory | 07:27 |
rogpeppe | urulama: definitely | 07:27 |
urulama | rogpeppe: i plan to jump on PRs and current implementation around noon (in 2h) ... would that be ok? any open questions or anything until then? | 07:29 |
rogpeppe | urulama: no, all's good | 07:29 |
urulama | rogpeppe: great to hear ... ok, back to tasks for the next 2 months | 07:30 |
urulama | rogpeppe: oh, btw, how far have you and Francesco come regarding uploads? | 07:32 |
rogpeppe | urulama: uploads now work | 07:32 |
urulama | rogpeppe: as in "zip properly formatted dir" and upload and new charm is in charmstore? | 07:33 |
rogpeppe | urulama: and you can now download individual archive files too | 07:33 |
rogpeppe | urulama: yup | 07:33 |
urulama | \o/ | 07:33 |
rogpeppe | urulama: ah, the only thing that's not done is that we don't currently verify bundles against the existing charms | 07:34 |
urulama | rogpeppe: as in when bundle is uploaded it is not checked wether the charms are in the CS? | 07:35 |
rogpeppe | urulama: yes | 07:35 |
rogpeppe | urulama: we deliberately left it for a later PR - but it does need doing | 07:35 |
rogpeppe | urulama: and there's also something i thought of in bed this morning | 07:36 |
rogpeppe | urulama: which is that we can't always start revision numbers from zero | 07:36 |
urulama | morning, frankban | 08:00 |
frankban | morning urulama | 08:00 |
frankban | urulama: are you able to connect to canonical IRC servers? | 08:00 |
urulama | yes | 08:00 |
urulama | frankban: but i've seen others being disconnected | 08:00 |
frankban | urulama: uhm, ok | 08:00 |
* TheMue has troubles too, also with SSO | 08:01 | |
frankban | urulama: I see "Connection failed. Error: Connection refused" | 08:01 |
frankban | will try again later | 08:01 |
frankban | switched to zsh, let's see how it works | 08:01 |
urulama | frankban: next step acme? :) | 08:13 |
frankban | urulama: http://www.nooooooooooooooo.com/ | 08:15 |
frankban | ;-) | 08:15 |
urulama | :) :) :) | 08:15 |
* urulama bookmarks the page for future use | 08:16 | |
urulama | frankban: ok, i have problems with cannonical irc as well, however, it manages to reconnect | 08:38 |
frankban | urulama: ok | 08:39 |
frankban | urulama, rogpeppe, jrwren: https://github.com/juju/charmstore/pull/69 | 10:45 |
urulama | frankban: finishing a doc, then lunch, then PR. ok with you? can move PR first if it is blocking anything else | 10:46 |
frankban | urulama: it's ok thanks | 10:47 |
rogpeppe | frankban: reviewed | 10:56 |
frankban | rogpeppe: thanks | 10:57 |
* urulama goes on short lunch | 11:40 | |
urulama | frankban: the tests currently check mostly if the time is there ... could we create a bit more complex test? starting with a charm revision at time 0, then upload new revision, one in the period T of time? Then, check if all revisions have proper n*T archive-upload time? | 12:26 |
frankban | urulama: not sure if I understand. at the store level, we already check that the time is the expected one (in a specified timeframe) | 12:29 |
urulama | frankban: suggestion is to have a "possible" reggression test, that adds a charm (addCharm), multiple times, and check proper revisions and timestamps | 12:34 |
urulama | frankban: on the api level | 12:35 |
frankban | urulama: so, we publish a charm with the same id two times and we check the id is incremented and t2> t1? | 12:36 |
urulama | frankban: yes, maybe also with "sleep" of time T between publishing | 12:37 |
frankban | urulama: why sleeping? | 12:37 |
rogpeppe | urulama: i don't really see what that test would be adding | 12:41 |
rogpeppe | urulama: given that we're testing that the upload time is within a very short period | 12:41 |
rogpeppe | urulama: (assuming frankban applies my suggested change) | 12:42 |
frankban | rogpeppe: I did | 12:42 |
* frankban lunches | 13:03 | |
* rogpeppe also lunches | 13:10 | |
bac | ha, this is a nice tool: http://www.downforeveryoneorjustme.com/lastpass.com | 13:36 |
rogpeppe | bac: should be www.downfordownforeveryoneorjustme.com :-) | 14:17 |
bac | rogpeppe: i don't get it | 14:18 |
rogpeppe | bac: well, really, it would be an infinitely long name | 14:18 |
rogpeppe | bac: the point being that it's only that web site that makes the check | 14:18 |
bac | rogpeppe: true | 14:19 |
rogpeppe | bac: so it could be down for everyone except me and their server | 14:19 |
bac | rogpeppe: regardless of the inaccuracy of their naming, it is a nice check, especially when you have reason to believe it is just you. | 14:20 |
bac | as i often do | 14:20 |
rogpeppe | bac: absolutely. i've found it very useful in the past, although i'd forgotten about it of late | 14:20 |
hatch | wb Makyo | 14:47 |
frankban | rogpeppe: I am going to change BulkIncludeHandler to receive a request rather than a method and flags | 14:47 |
rogpeppe | frankban: i started off doing that | 14:47 |
rogpeppe | frankban: but it didn't work out | 14:47 |
frankban | rogpeppe: we need access to req.Body e.g. for the extra info stuff | 14:47 |
frankban | rogpeppe: why? | 14:48 |
rogpeppe | frankban: really? | 14:48 |
frankban | rogpeppe: extra-info PUT | 14:48 |
rogpeppe | frankban: hmm, i guess i thought that stuff would be in the flags, but you're probably right | 14:48 |
frankban | rogpeppe: anyway, I'd feel the framework to be more friendly if it gives the request to you anyway | 14:49 |
rogpeppe | frankban: the reason it didn't work out was because of Router.GetMetadata | 14:49 |
rogpeppe | frankban: and that it seemed wrong to be making up Requests for bulk metadata requests | 14:50 |
hatch | jujugui call in 10 | 14:50 |
rogpeppe | frankban: are you planning to do extra-info ? | 14:50 |
rogpeppe | frankban: i was working towards that | 14:50 |
frankban | rogpeppe: I was just taking a look at the framework and realized that. If you want to tackle it I'll live it to you | 14:51 |
frankban | rogpeppe: I'll look at something else, like verifyWithCharms in publish API | 14:51 |
rogpeppe | frankban: i'd be happy to pair on it if you like. i'm wading through mud currently. | 14:51 |
frankban | rogpeppe: sounds good | 14:52 |
rogpeppe | frankban: cool, let's do that. | 14:52 |
rogpeppe | frankban: after the standup? | 14:52 |
frankban | rogpeppe: sure | 14:52 |
rogpeppe | frankban: BTW, if we used a standard "application/x-www-form-urlencoded" MIME type, then the PUT arguments will end up in the flags argument | 14:56 |
rogpeppe | frankban: we don't say much about how the PUT values are encoded in the spec | 14:56 |
urulama | rogpeppe: good point, we dont | 14:57 |
hatch | jujugui anyone else getting "party is over" error? | 14:58 |
rogpeppe | hatch: yup | 14:58 |
hatch | worked now | 14:58 |
hatch | just keep trying I guess | 14:58 |
hatch | heh | 14:58 |
rogpeppe | urulama, frankban: we could standardise on using a single form attribute, say "value" containing the JSON-encoded value to PUT. | 14:59 |
frankban | rogpeppe: It's doable, still not sure if I like it over just sending the json in the body | 15:00 |
jrwren | "It's taking too long to connect you to this video call. Try again in a few minutes." | 15:02 |
urulama | jrwren: daily standup :) | 15:02 |
jrwren | "please wait..>" | 15:02 |
frankban | rogpeppe: gogogo in 5 | 15:15 |
rogpeppe | frankban: ok | 15:15 |
rogpeppe | frankban: i'm there, BTW | 15:15 |
hatch | man somethin is munchin on my internets | 16:01 |
jcsackett | hatch: this is the second day, if we're going by your sign on/sign off. | 16:05 |
hatch | yeah it is :/ | 16:05 |
hatch | good thing I don't pay for QOS | 16:06 |
hatch | oh wait.... | 16:06 |
hatch | rogpeppe your card that's in landing....is it still landing or blocked? Maybe it should be moved into tracking? | 16:09 |
rogpeppe | hatch: i'm trying to land it but it's blocked | 16:10 |
rogpeppe | hatch: if tracking is a better place for that, then by all means move it there | 16:10 |
hatch | rogpeppe yeah I think that lane is for actively landing....whereas yours might sit there for a week? :) | 16:11 |
kadams54 | hatch: completely befuddled on this test I'm trying to fix. Ping me when you have a few moments. | 16:23 |
hatch | kadams54 you're in luck I just finished a review | 16:23 |
hatch | what's up? | 16:23 |
kadams54 | this is the currently breaking code: https://github.com/juju/juju-gui/blob/develop/app/widgets/deployer-bar.js#L257 | 16:25 |
kadams54 | It loops through a set of keys and checks to see if any of their values have a length. | 16:25 |
hatch | ok | 16:26 |
hatch | is there more to this story? | 16:28 |
hatch | :) | 16:28 |
kadams54 | The problem is that my code adds a new key who's property is an int | 16:28 |
kadams54 | So I thought I'd just add an Array.isArray check before we look at length | 16:28 |
kadams54 | It's false, but hasChange is still getting set to true | 16:28 |
hatch | ok looking | 16:29 |
kadams54 | Should I push my changes up so you can see them? | 16:30 |
kadams54 | Or would you prefer something like a gist? | 16:30 |
hatch | well I'm just trying to figure out what this is doing | 16:32 |
kadams54 | This screenshot pretty much summarizes my confusion: http://cl.ly/image/20132A2e051Z | 16:32 |
kadams54 | Both conditions for the if statement eval to false, yet we're inside and hasChange is set to true. | 16:33 |
hatch | that might be an issue with how watches are evaluated | 16:35 |
hatch | what if you run those in the console? | 16:35 |
hatch | and you'll want to use Y.Array.isArray() I'm not sure if Array.isArray() is supported everywhere yet | 16:36 |
hatch | what is this even testing for? What makes it a major change? If any of the objects have something in them then major change is true? | 16:36 |
jcsackett | thanks for the review, Makyo. :) | 16:40 |
kadams54 | hatch: we're using an object as a hash here. The original code makes an assumption that all the values in the hash are arrays of changes. If any of the arrays have a non-zero length, then we have major changes and need to display the summary panel in addition to the changelog. | 16:41 |
hatch | ok but that basically means that if there is anything in changes then we need to show it...what tasks aren't shown? | 16:42 |
hatch | what I'm getting at is this method isn't necessary | 16:42 |
hatch | because if you do anything it will return true | 16:42 |
hatch | if any of the changes keys have values it's true | 16:42 |
jcsackett | jujugui: i need 2 reviews on this (very short) PR. https://github.com/juju/juju-gui/pull/491 | 16:44 |
kadams54 | But not all of the keys in the hash are arrays of changes. | 16:44 |
hatch | jcsackett no test? :) | 16:44 |
jcsackett | hatch: nope--there's no meaningful way to get in and test the d3 logic. | 16:45 |
hatch | kadams54 right - but what I'm saying is that this method is causing you issues.....I don't think this method is necessary because if there is anything in the changes object then it's shown | 16:45 |
jcsackett | i can break out the logic about what to show into a separate method and test that, if you like. | 16:45 |
kadams54 | hatch: not necessarily the case. | 16:45 |
hatch | jcsackett well that's just not true :) we test the unit list somewhere | 16:45 |
hatch | kadams54 ok what is the case where it isn't? | 16:45 |
kadams54 | hatch: for example, if the user just adds a container, we only show the changelog. We don't show the summary panel. | 16:46 |
jcsackett | hatch: we set up some stuff using the generateAndBind, but we don't inspect those contents. | 16:46 |
kadams54 | In that case, all of the arrays in the changes hash would have a 0 length. | 16:46 |
kadams54 | i.e., no "major" changes | 16:46 |
jcsackett | hatch: which is reasonable, b/c it's just testing "does d3 set an a tag when i tell it to set an a tag. | 16:46 |
jcsackett | hatch: as i said, if you like i can break that change out into a "chooseDisplayName" method for units, and test *that*. | 16:47 |
hatch | jcsackett I'm pretty sure we have a test which renders the unit list and then checks the dom to make sure there are x number of units rendered | 16:47 |
hatch | maybe inspector overview or something | 16:47 |
hatch | kadams54 ok and you have added something to changes.addUnits? | 16:48 |
kadams54 | Yeah… totalUnits… | 16:48 |
jcsackett | hatch: that's where i looked. unless you | 16:48 |
kadams54 | Which is an int | 16:48 |
jcsackett | hatch: unless you're talking the scale out tests, which arne't qute the same kettle of fish. | 16:48 |
kadams54 | hatch: sorry, I didn't add anything to changes.addUnits. I added it to changes. So changes now has changes.addUnits and changes.totalUnits. | 16:50 |
hatch | kadams54 ok so you could have getChanges return an object where one property is the changes and the other is the total units | 16:50 |
hatch | then you don't have to modify this method | 16:50 |
hatch | which is what I would recommend because your putting stuff in the changes property that doesn't really fit with the rest of the dataset | 16:51 |
kadams54 | OK, will do | 16:51 |
hatch | sounds good? | 16:51 |
hatch | ok cool | 16:51 |
hatch | jcsackett I'm just saying it would be nice if we could test that when we pass an uncommitted model into the d3 stuff it renders the proper name | 16:52 |
hatch | and the other way | 16:52 |
hatch | it was what the bug was about afterall | 16:53 |
jcsackett | hatch: i'm not disagreeing, but the test for that will be ridiculous. like i said, i can break out the logic part of it into another method, and test that it returns the right thing; after that it's a matter of believing d3 does the right thing or not. | 16:53 |
hatch | I'll try and find the test | 16:53 |
hatch | you may be able to copy it | 16:53 |
hatch | one sec | 16:53 |
hatch | but I agree if you have to write it all | 16:53 |
hatch | no good :) | 16:53 |
jcsackett | i'm reading through inspector_overview and not seeing anything that looks right. | 16:54 |
hatch | jcsackett test_inspector_overview.js:477 | 16:56 |
hatch | the test is massive but you can likely modify it to use one uncommitted unit model as well as the regular others | 16:56 |
hatch | or add another unit to the list | 16:56 |
jcsackett | hatch: i'll see--i don't think the return from that is quite right to see what's rendered in the lists, but you might be right. | 16:57 |
jcsackett | oh, i see, it's dumping the whole damn mess. | 16:57 |
jcsackett | ok. | 16:57 |
hatch | so you should be able to just add an uncommitted unit to this and test that that unit is rendered properly and that another one is rendered property too | 16:58 |
* rogpeppe is done for the day | 17:09 | |
rogpeppe | g'night all | 17:09 |
jcsackett | hatch: done. | 17:09 |
jcsackett | thanks for helping sort out where to test it; that block is impenetrable when you're scanning without being certain what you're looking for. :p | 17:10 |
hatch | haha yeah it is np | 17:11 |
hatch | ok will qa | 17:11 |
hatch | jcsackett lint error | 17:11 |
hatch | lol | 17:11 |
hatch | we should make a rule - if your tests fail with a lint error you got to buy everyone a coffee :P | 17:12 |
jcsackett | i honestly am not sure of the utility of lint being run on every test--on merge, sure, but it's just noise to me. | 17:13 |
hatch | I always run the full suite before pushing - and now that I'm in Ubuntu the tests don't fail randomly lol | 17:14 |
jcsackett | hatch: i always run the tests; i don't always run check. | 17:15 |
hatch | oh right cuz it's really slow for you isn't it? | 17:15 |
jcsackett | hatch: sufficiently slow. | 17:15 |
jcsackett | slow enough that i end up waiting a while, not long enough to do anything meaningful while it runs. | 17:16 |
hatch | time for an ssd? | 17:19 |
kadams54 | hatch: looks like huw needs second reviews on a couple PRs? | 17:29 |
hatch | kadams54 the x uncommitted one I need to write the fix for it to get it to land | 17:30 |
hatch | but the mv scale up one does | 17:30 |
hatch | is yours all good to go? | 17:30 |
hatch | looks good | 17:31 |
hatch | once the tests pass you can land it | 17:31 |
kadams54 | Yeah | 17:31 |
kadams54 | I was noticing we had a build-up of cards in review | 17:31 |
kadams54 | I'll dig into the mv scale up one. | 17:32 |
kadams54 | Looks like the scale up one needs to be rebased and have some conflicts resolved | 17:34 |
=== urulama is now known as urulama-afk | ||
hatch | telcos should have a flag on peoples accounts which mark their level of expertise | 19:06 |
hatch | so when you call with a problem they don't ask you if you have restarted your router and make you do it again for kicks | 19:07 |
hatch | jcsackett can you rebase your branch and shippit? | 19:09 |
hatch | #491 that is | 19:10 |
jrwren | I actually called Comcast once after I did some basic troubleshooting. I had forgot to reset my cable modem. | 19:19 |
jrwren | The support person saying "Turn it off and back on again" actually solved my problem. | 19:19 |
hatch | lol | 19:20 |
urulama-afk | jrwren: config-changed error: http://pastebin.ubuntu.com/8029262/ | 19:30 |
urulama-afk | jrwren: relations in charms: http://pastebin.ubuntu.com/8029269/ | 19:32 |
jrwren | urulama-afk: that doesn't look like an error. :( | 19:33 |
urulama-afk | error: no relation id specified | 19:34 |
urulama-afk | maybe it's enough to trigger the hooks and to leave the charm in "installed" but not "started" state | 19:34 |
jrwren | urulama-afk: I'll try to reproduce. Thanks. | 19:35 |
jrwren | urulama-afk: I'm still new enough to charming that I don't remember all this stuff. I can't recall if that error: is valid or not. | 19:36 |
urulama-afk | jrwren: me and you both :) | 19:36 |
jrwren | jrwren: Still, and invalid error message is a bug, so I'll fix it. | 19:36 |
jrwren | s/and/an/ | 19:36 |
urulama-afk | jrwren: yes, i can exit the tmux and then the status is "started" | 19:37 |
jrwren | urulama-afk: can you curl that ip on the listen port? | 19:37 |
urulama-afk | jrwren: it gets stuck on most of the hook scripts, but running them manually and exiting tmux produces service in a "started" state, and curl works | 19:41 |
jrwren | hrm. it gets stuck and you have to resolved --retry? | 19:42 |
urulama-afk | jrwren: i mean, the CS is empty, but there are "error" codes to show that it works | 19:42 |
jrwren | urulama-afk: that is VERY weird. | 19:42 |
jrwren | urulama-afk: Empty and responsive is my goal. | 19:43 |
=== urulama-afk is now known as urulama | ||
urulama | jrwren: i haven't tried deploying without debug-hooks, let me add another unit, it might just as well work | 19:43 |
urulama | jrwren: indeed ... seems like debug-hooks interpret your error messages as true errors ... without them, the charm starts and is in "started" mode | 19:49 |
jrwren | urulama: Good, that is what I thought. | 19:50 |
hatch | you guys ok with all this? I've done some charm work, can maybe offer some input | 19:50 |
hatch | jcsackett thanks | 19:51 |
urulama | jrwren: ok, so fixing that is simple, just changing error to "warning" or something, as they are not true errors | 19:51 |
urulama | hatch: thx | 19:51 |
jcsackett | hatch: no worries; hadn't noticed i had all my reviews for it. :) | 19:51 |
jcsackett | thanks for pinging me. | 19:51 |
jrwren | urulama: its charmhelpers. | 19:51 |
urulama | jrwren: khm. then it might not be that innocent after all :) | 19:52 |
jrwren | hatch: What is the right way to use charmhelpers.core.hookenv.relation_get ? | 19:52 |
hatch | what's this python mumbo jumbo...I just shell out to the real relation get | 19:53 |
hatch | https://github.com/hatched/ghost-charm/blob/master/hooks/db-relation-changed | 19:53 |
hatch | so sorry, I have never used charmhelpers :) | 19:54 |
jrwren | hatch: I'm pretty sure I was told to use this. | 19:54 |
hatch | yeah you likely were | 19:54 |
hatch | sometimes the abstraction is more work though | 19:54 |
hatch | case-and-point :) | 19:54 |
jrwren | hatch: Are you sure it is only sometimes? :) | 19:54 |
hatch | haha | 19:55 |
hatch | jrwren you'll probably have some luck asking in #Juju-dev | 19:55 |
urulama | hatch: do not lead jrwren into temptations! :) | 19:56 |
jrwren | It is likely as simple as if not relation_ids(): before those relation_get calls' | 19:57 |
hatch | urulama haha sorry - I've written charms in node and bash, and fixed the gui one which is in python so never really used charmhelpers and the like | 19:57 |
urulama | hatch: i deploy charms from CLI, that doesn't mean GUI is useless :D | 20:03 |
hatch | urulama definitely not, after about the 1000th time of writing `juju set some-really-big-charm-name some-really-big-config-name="some really long value"` you'll just use quickstart and use the GUI exclusively | 20:04 |
hatch | lol | 20:04 |
urulama | :D :D | 20:05 |
urulama | ok, time to really EOD ... see you all tomorrow, jujugui (and irc clients go 'ping' all over the globe) | 20:06 |
bac | later urulama | 20:06 |
jrwren | urulama: good night. TY. | 20:06 |
hatch | haha cya urulama | 20:06 |
=== urulama is now known as uru__ | ||
rick_h__ | jrwren: ask in #juju of marcoceppi or mbruzek around that. Maybe tvansteenburgh as well. They work on and maintain the charmhelpers | 20:42 |
rick_h__ | hatch: helps us use/make better our own tools :P | 20:42 |
marcoceppi | o/ | 20:43 |
hatch | rick_h__ I'm not sure anything that's 3 levels deep for a simple shell-out call is a valid abstraction :D | 20:43 |
rick_h__ | hatch: time to make it better? | 20:43 |
rick_h__ | hatch: shell out with proper catching of return values, logging integration, etc can be worth it | 20:43 |
rick_h__ | however I have a lack of context in this matter so I wave my hands around in a general fashion | 20:43 |
hatch | honestly I have no idea what it does under the hood, never used it :) | 20:43 |
mbruzek | ask me what? | 20:44 |
rick_h__ | mbruzek: jrwren is having some issues with relation-get and charmhelpers or the like | 20:44 |
rick_h__ | mbruzek: just volunteering you for support of jrwren gets stuck :) | 20:44 |
* mbruzek nods | 20:44 | |
hatch | maybe I should write a charm in python to learn about these helpers-of-the-charm | 20:47 |
marcoceppi | hatch: ALL HAIL THE HELPERS OF THE CHARM | 20:51 |
jrwren | hatch: If you are a cranky programmer like me, it might just annoy you that it isn't in bash. ;] | 20:51 |
hatch | jrwren bash MAKES a cranky programmer | 20:52 |
hatch | marcoceppi lol | 20:52 |
hatch | rick_h__ you still around? | 20:52 |
* jrwren uses /dev/tcp in bash instead of curl | 20:52 | |
hatch | lol | 20:52 |
hatch | jcsackett Makyo kadams54 want to weigh in on https://github.com/juju/juju-gui/pull/486#issuecomment-51975411 ? | 20:54 |
rick_h__ | hatch: sure | 20:54 |
rick_h__ | hatch: packing up, flight home in the morn | 20:55 |
hatch | rick_h__ want to weigh in on that? ^ | 20:55 |
kadams54 | hatch: lgtm | 20:55 |
rick_h__ | hatch: looking | 20:55 |
rick_h__ | hatch: "update a template which doesn't exist" ? | 20:56 |
hatch | rick_h__ the real issue is that it's not the template which doesn't exist, it's that it's using the old inspector rendering code | 20:57 |
hatch | so we have to write a new test mock for generating the inspector to use the NEW mv style inspector rendering code | 20:57 |
hatch | which has to be done anyways but will block this branch | 20:57 |
rick_h__ | hatch: that seems like something we'll need anyway? (a new helper for generating a new inspector) | 20:58 |
rick_h__ | hatch: ok, but this comment is about waiting until MV is released, not about a missing test helper? | 20:58 |
rick_h__ | nothing here is documenting/adding that we need the helper as the 'right' fix? | 20:58 |
hatch | yeah sorry that wasn't clear | 20:58 |
rick_h__ | or am I mis-reading that? | 20:58 |
* rick_h__ loads up kanban | 20:59 | |
hatch | so this branch either needs to wait until the new inspector mock test thingy is written or apply the included patch to land it now | 20:59 |
hatch | I gather the new inspector mock thingy will take 1day and then moving all the tests to use it will be....2? | 21:00 |
rick_h__ | hatch: ok, I'm cool with the patch with a proper XXX, documenting the place the needs updating, and a follow up card at the top of the lane | 21:00 |
hatch | ok I'll work on the inspector thingy, I added a friday card to chat about it | 21:01 |
hatch | thx | 21:01 |
rick_h__ | hatch: coolio, thanks. | 21:01 |
hatch | safe travels! | 21:01 |
rick_h__ | wheeeee | 21:02 |
rick_h__ | can't wait to have my own pillows again | 21:02 |
hatch | lol | 21:02 |
hatch | it's the small things, right? | 21:02 |
rick_h__ | you know it | 21:03 |
rick_h__ | like AC that works | 21:03 |
rick_h__ | getting sick of always sweating in EU | 21:03 |
hatch | haha, I never would have thought that would be an issue | 21:03 |
rick_h__ | us norhern folks don't like it so hot, my basement office is calling me | 21:04 |
hatch | haha | 21:05 |
hatch | I'm with you on that one! | 21:05 |
hatch | Makyo good choice in cards :) | 21:15 |
rick_h__ | well I'm out, have fun all. See you soon. | 21:15 |
hatch | cya rick_h__ safe travels | 21:15 |
hatch | jujugui lf a review (no qa) https://github.com/juju/juju-gui/pull/492 | 22:06 |
huwshimi | Morning | 23:03 |
hatch | morning huwshimi | 23:21 |
hatch | huwshimi all reviews are done and comments made so you should be able to land both of your branches | 23:24 |
hatch | today | 23:24 |
hatch | and if you could also do a quick review on mine that would be great because mine provides the hooks you will need to mark up the UI with the 'deleted' attributes | 23:24 |
hatch | ^ huwshimi | 23:24 |
jrwren | huwshimi: Good morning. | 23:25 |
jrwren | My wife and child just reminded me that today is my last day living at the age of 36 years old. | 23:34 |
hatch | WHAAAAA | 23:35 |
hatch | I thought you were like.......26 | 23:35 |
hatch | lol | 23:35 |
jrwren | Whaaa??? | 23:36 |
hatch | haha yeah | 23:36 |
huwshimi | hatch: Yep no problems, just doing a little qa | 23:41 |
huwshimi | hatch: So to use that flag would we have to update this to use lazyDestroyMachines? https://github.com/juju/juju-gui/blob/develop/app/widgets/machine-view-panel.js#L710 | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!