[00:14] hey huwshimi I haven't from you about progress. how are the transitions? [00:15] gary_poster: Just working on them now... being a bit of a hassle tbh :) [00:21] huwshimi, ack :-) fwiw we will probably make a release tomorrow. if it is in that would be cool. if not, so be it. [00:21] ttyl [00:21] gary_poster: Ok, understood. [01:43] gary_poster: ping... can you help with demo prep for a few minutes? [01:44] gary_poster: wondering what I should expect to see wrt subordinates [01:54] Any reason raring was left off of the series in the gui search? [01:58] m_3: subordinates should work ok I believe. I know we tested that out in a case during sprints. [01:58] marcoceppi: huh? precise should be still set though we're moving to remove the filters soon so it'll go away [01:59] https://jujucharms.com/fullscreen/search/?series=precise&text=apache&type=approved shows series with precise pre-selectedxc [01:59] rick_h: precise is set, but there are raring charms and no way to show them [01:59] marcoceppi: ah right...well we 'support' LTS [01:59] (exactly 7 personal branch'd raring charms) [01:59] So...quantal is a goof? [01:59] thuogh I did think raring was added...checking [02:00] I'm fine with it being unchecked by default [02:02] marcoceppi: looking, if we've got it in the back end I can get it in the gui for tomorrow's deploy [02:03] marcoceppi: so it looks like the back end has them https://manage.jujucharms.com/api/2/charms?series=raring&text= [02:03] rick_h: thanks, it's not a vital think I was just asking because someone brought it up in the room [02:03] I can open a bug - again not vital [02:03] marcoceppi: so I'll add raring in, but yea none of them are 'reviewed' [02:03] and looks like none for saucy [02:03] https://manage.jujucharms.com/api/2/charms?series=saucy&text= [02:03] I'm pretty sure there are no saucy charms [02:04] marcoceppi: so the idea is to remove filters all together and try to display series on the block of charm token going forward so they'll start showing up, but that's probably at least a few days away so can show for now [02:06] rick_h: sounds good, again nothing I've mentioned is vital. m_3 has the more pressing "issues" [02:06] marcoceppi: what issues? [02:07] rick_h: Airquote that, he was just trying to get subordinates tow rok [02:20] rick_h: hey... any hints on how to export a bundle in the current juju-gui? [02:20] bcsaller: ^^ [02:23] rick_h: also, I'm having some problems getting subordinates to display [02:23] they show up as standalong (unrelated) services [02:24] this is pretty important... last minute demo change from mark for tomorrow morning... so any help appreciated [02:25] m_3: yea, looking and noticed that. Lookinf for the dnd support as well [02:25] Makyo: hatch ^^ ? [02:26] thanks [02:29] m_3: so S-d (shift-d) will do an export [02:29] m_3: and dragging that file onto the canvas should imporr it [02:29] m_3: might need :flags:/dndexport/ in the url to make it work [02:32] rick_h: ok, thanks, I'll try that in a sec... old session up [02:32] hmm, except it exports but won't import :/ [02:32] m_3: I don't know on the subordinate stuff. Hoping others come along on that one. [02:32] k, thanks... seems like shift-d did something [02:32] I'm digging through the output now [02:40] I'm getting subordinates, but they're only showing as subordinates on deploy, which I thought had landed. [02:40] m_3, ^^^ [02:40] m_3, Using puppet as a test here. [02:40] Makyo: might have landed but not on jujucharms.com. [02:40] and damned if I can get an import to work though it seems like it should :/ [02:41] rick_h, True. It shows as a subordinate after deploy, just not during the deploy process. Guess that landed after the release. [02:45] Makyo: so that's if I deploy it using the gui [02:45] ? [02:45] Makyo: I've been actually just trying to get the gui to show a stack I've spun up from a script [02:45] m_3, This was testing on jujucharms running in a sandbox, yeah. I have an instance running now on EC2, though, so give me a second. [02:45] but I can add subs after-the-fact if that's necessary to get the to show that way in the gui [02:45] ack [02:47] m_3, using core? Checking that now, and pending services aren't showing the 'subordinate' flag. [02:47] m_3, er... don't suppose pending matters with subordinates. [02:47] It shows up as a regular service without a status bar. [02:48] Makyo: using 1.11.4 on hp (and ec2) [02:49] m_3, Alright. I can't inspect the ws frames from firebug, but I can dig in real quick. Just a sec. [02:49] Makyo: is it worth trying to deploy the subordinates via the gui? [02:49] m_3, Let me check. [02:49] k [02:52] m_3, Deploying puppet on EC2/core 1.11.3 from the GUI results in an error. <-- jujugui [02:53] m_3, is there another subordinate you know of offhand I can test with? [02:53] ganglia-node [02:53] newrelic will always error out if that's useful (license config) [02:53] juju (the charm) is a sub [02:53] ganglia-node's the most relevant atm [02:54] m_3, also fails. [02:54] {"RequestId":13,"Error":"subordinate service must be deployed without units","Response":{}} [02:54] We're trying to deploy subordinates with one unit. [02:55] hmmm... ganglia-node has been deploying fine [02:55] m_3, From the GUI? [02:55] juju deploy mysql && juju deploy ganglia-node && juju add-relation mysql ganglia-node [02:55] Makyo: nope, not from the gui [02:55] m_3, Ah, yeah, this is from the GUI, which is assuming all services want at least one unit. [02:56] ack [02:56] ok, so I'm hearing I should probably either scrub subs from the demo bundle [02:56] or accept that they're gonna look funny? [02:58] Makyo: ok, so next issue I'm seeing... status seems to be out of sync with `juju status` [02:58] four units of a single service [02:58] `juju status` reports two fine, two in error state [02:59] m_3, Probably scrub; no way to view subordinate relations without them being recognized as subordinates. This maaay be on core, though, so let me check debug-log [02:59] gui shows them all in error state... red bar on main icon, _and_ when I click 'view' the details screen shows all units in 'error' state [03:00] m_3, Is this with the serviceInspector flag in the URL, or without? [03:00] Makyo: ack on scrub [03:00] Makyo: no serviceInspector flag afaik [03:00] lemme reproduce, then I can hand you the url [03:00] m_3, Okay. Flag would be URL ending in /:flags:/serviceInspector [03:02] Makyo: so I should put that explicitly in the url when I click on "view" for the service? [03:02] m_3, No, sorry. Was just curious if you were using that. That's future. [03:02] (sorry) [03:02] nope, nothing fancy [03:02] Cool, thanks. [03:08] #1204330 [03:08] <_mup_> Bug #1204330: GUI deploys subordinate with 1 unit, causing errors in core [03:08] Makyo: do you have fix for the sub thing? do you need one? [03:09] bcsaller, I have a fix for if deployed from the GUI. [03:09] bcsaller, investigating the other part of the GUI not picking up is_subordinate from core [03:10] Makyo: status reporting beautifully this time around [03:10] I think ghost-inspector:deployCharm makes no effort to set numUnits when a sub, but it could be done in a different layer [03:10] bcsaller, Yeah, this is in charm-panel.js. Fix is to set zero if subordinate, and hide the num-units field. [03:11] Makyo: i.e., partially red bar... view reports one of four in error state which matches the CLI [03:11] Makyo: ahh, right, no flag yet :-/ wasn't thinking [03:11] Sorry, if subordinate, replace text input with hidden input, value=0 [03:11] m_3, Were the units deployed with the GUI, or CLI? [03:12] CLI [03:12] bcsaller: what do you need to do to import? I've gotten exports with S-d, but dragging that back in fails with the dndexport flag set? [03:12] m_3, thanks. Not sure what would be causing that :/ [03:12] Makyo: not sure what was different with that [03:12] right [03:13] so only the sub rendering problem remains [03:13] rick_h: the export format was changed to be deployer (quickly) but the import format is the old one, there are examples in the test dir [03:13] Core is reporting whether or not a service is subordinate only in the charm info, which sort of makes sense. [03:13] We're just expecting it in the service info [03:13] but I'll move forward assuming we won't have that for the morning [03:13] m_3, correct. [03:13] but that is a real issue, importing a deployer file should happen very soon though given we have a team on it [03:14] The current plan for the demo is to spin up the bundle from the CLI, then Mark will add some incomplete relations on-stage [03:14] bcsaller: k, I knew there was work underfoot, but hadn't realized it wasn't working in/out atm [03:14] in a past life it did [03:15] k... thanks gang! [03:15] you can still drag from one browser to another I think though [03:15] haven't tested that in a while though [03:15] #1204331 [03:15] <_mup_> Bug #1204331: GUI does not recognize subordinates from core [03:22] sorry m_3, seems we don't have a lot of good bits for you tonight :/ [03:26] rick_h: np, It'll still be interesting for mark to show on stage... somewhat complex stack even without the subs [03:27] if it's something that can land by tomorrow 7 or 8 pacific time, I'm happy to try again in a different environment then [03:28] I'll freeze this one and leave it for the demo as-is [03:29] m_3: yea, good luck! time for me to try to get to bed while it's still Tues. [12:39] jujugui, I'm going to make some small tweaks to Makyo's branch for #1204330, per my review and Rick's review, and land it. Then I'm going to tackle #1204330: I think we can use the charm information that we are already getting for config to set the subordinate value. If anyone is willing, able, and optimistic about their work speed to tackle either of those (we ideally have a release with these out in two hours fo [12:39] r OSCON), let me know. [12:39] <_mup_> Bug #1204330: GUI deploys subordinate with 1 unit, causing errors in core [12:39] <_mup_> Bug #1204330: GUI deploys subordinate with 1 unit, causing errors in core [12:39] sorry second one was #1204331 [12:39] <_mup_> Bug #1204331: GUI does not recognize subordinates from core [12:42] gary_poster: thanks, I'm not comfy trying to squeeze in a fix to code I've not peeked at as a bug fix pre-presentation but happy to help review and such as needed. [12:42] thanks rick_h [12:58] * bac reboots [13:13] jujugui, could someone please start up improv, run my branch (lp:~gary/juju-gui/core-sub-num-units) and verify that you can still deploy subordinates against pyjuju? [13:13] jujugui, second q: does someone have a working, recent juju core atm that they can help qa issues with? [13:14] jujugui, to be clear, we are in a critical race against the clock mode [13:14] gary_poster: I can do the first (improv) [13:14] benji, thank you [13:15] benji, general release qa would be good too, though I have another branch to try and fit in [13:15] gary_poster: I can do that [13:15] thank you [13:15] gary_poster: on the branch you gave, right? [13:15] benji, right [13:15] k [13:16] gary_poster: https://ec2-54-234-245-82.compute-1.amazonaws.com/ [13:17] frankban, fanstastic. that's my branch? could you give me password via some secure mechanism, or verify that deploying subordinates now works?\ [13:19] gary_poster: that's stable, I'll switch to your branch [13:19] frankban, thanks [13:21] gary_poster: I can't seem to build relations at all with that branch. [13:22] benji, excellent! :-) [13:22] pfft [13:23] benji, diff is small; any quick diagnosis? [13:24] gary_poster: well, with improv building relations seems to work; I was having the problem with sandbox [13:24] gary_poster: how do I make a subordinate relation? [13:24] benji, use a subordinate charm. puppet, for instance [13:25] gary_poster: subordinate relations appear to be fine [13:26] benji great thanks. sandbox issue may be related as well. more changes there in fakebackend. anything in console? [13:26] the one small thing is a style issue (which was probably pre-existent); when I click on the subordinate icon (the thing to the right of the service box) the number goes italic and is clipped slightly on the right [13:26] yeah, pre-existing, not sure what the intent is [13:27] gary_poster: relating apache to apache works in sandbox so we're at least as well off as we were there [13:28] benji, what was the sandbox issue then? [13:28] when creating a relation it would snap to a service but then ignore the click to finish creating the relation; I can't repro now [13:28] ok cool benji [13:29] benji, so improv and sandbox appear to qa OK for subordinate issue atm, yes? [13:29] gary_poster: correct [13:29] great thanks benji. quick exploratory testing while you are at it? [13:29] yep [13:29] ty [13:33] gary_poster: is this default icon issue in FF known? http://i.imgur.com/7gxOrUG.png?1 [13:33] benji, not sure; it's come and gone. rick_h ^^^ ? [13:34] odd that haproxy is right and nagios/puppet wrong [13:34] should be same code [13:35] benji: yes [13:35] benji: that's a known svg issue [13:35] thanks rick_h . why is haproxy ok? [13:36] hi gary_poster, i'm on orange call. can we push our 1:1 to 10:00? [13:36] gary_poster: the default icon is 160px svg, the category ones are 96px [13:36] bac, I thought was tomorrow? [13:36] just what we got from assets so guessing that's the issue [13:37] rick_h, ah gotcha thx [13:37] ah, right, we switched to wednesday for one week only. nm. i'll make the same request tomorrow, though. :) [13:37] bac :-) you already asked to switch with teknico . I said +1 [13:37] gary_poster: i did not see your reply. great. [13:38] bac, maybe I only thought +1 :-P sorry [13:38] gary_poster: np. could you update the calendar? [13:38] bac did you get teknico's +1? or was he out when you asked? [13:38] he's been out [13:39] gary_poster: other than this oddity in the console log, I can't find any QA problems. [13:39] Failed to load resource: the server responded with a status of 404 (Not Found) https://manage.jujucharms.com/api/2/charm/precise/drupal6-0/icon.svg [13:40] huh, doesn't look like a gui issue anyway benji. thank you very much! rick_h sinzui ^^^ ? [13:42] gary_poster, I think you have discovered a bug that adeuring just landed a fix for [13:42] sinzui, lol, cool [13:43] gary_poster, benji, we have a fix for the case users use a different name for charm in the metadata than the actual location they pushed the branch: https://manage.jujucharms.com/static/img/charm_160.svg [13:44] ^ is the real location [13:44] benji does dnd deploy work on improv? not working on core for some reason. frankban, same for you? [13:44] * sinzui will ask for a deploy in a few minutes [13:44] sinzui, great. does that also include the more colorful category icons, do you know? [13:44] gary_poster: I'm pretty sure it works. Verifying now. [13:44] thanks benji [13:44] gary_poster: bcsaller said last night that it's a format conflict right now [13:44] rick_h, what is? [13:45] gary_poster: the exported format isn't taken as the import format when we were trying to help m_3 last night [13:45] rick_h, no, that's bundle import export he was talking about [13:45] gary_poster: it works [13:45] benji thank you [13:45] gary_poster: ah sorry, ignore me. [13:47] gary_poster: dnd correctly creates a ghost in my environment, do I need to click deploy? [13:47] frankban, no, cool thanks [13:49] the subordinate relation ux leaves a lot to be desired :-/ [13:49] I keep forgetting that it is not a bug that the new relation disappears\ [13:50] jcsackett: linky for review? Sorry if I missed it in the hangout [13:50] rick_h, we can talk any time it is convenient to you today [13:52] sinzui: k, thanks. I'll bug you after coffee shop time when I can get back into the house then. [13:52] fab [13:53] gary_poster: i just requested swap day for next friday, not monday as i'd previously asked. hope that is ok. [13:53] bac, cool [13:56] rick_h, do you have time to review my branch: https://code.launchpad.net/~sinzui/charmworld/heartbeat/+merge/176530 [13:56] sinzui: definite [13:56] doh, can't tab complete any word you feel like it :/ [14:01] morning [14:03] rick_h: https://codereview.appspot.com/11696045/ [14:05] rick_h, sinzui I thought charms knew if they were subordinates. not true? [14:06] gary_poster: yes, it's in the BrowserCharm model at least. Makyo suspected an api change on the Juju side. I didn't look to compare if that's changed. [14:07] rick_h, ack thanks. right, it was a change on the service, but hopefully not on the charm [14:07] Charms should still know. [14:07] gary_poster: https://manage.jujucharms.com/api/2/charms?series=precise&text=nagios&type=approved so the nagios charm is showing is_subordinate [14:07] precise/nrpe-1 that is [14:08] Makyo, cool, hi. I have a branch that makes the changes rick and I mentioned. it appears it qas ok. I have a fix for the other bug--it takes subordinate value from charm, which should be fine, since we do the same kind of thing for endpoints [14:08] gary_poster, YEah, just prowling through email now. Will review the first real quick. [14:08] Makyo, rick_h only issue is that charm has correct is_subordinate value in place 1, and incorrect in place 2. not sure problem, but sure it is related to two model stuff somehow [14:09] rick_h, where is browser charm converted to normal charm again? [14:09] I mean old charm [14:09] gary_poster: sec, it's in the subapp/browser/views/charm.js and in the widgets/charm-token.js it's json-ified [14:09] gary_poster: we've not combined the two places yet [14:09] rick_h, ack looking thanks [14:10] gary_poster: _addCharmEnvironment is the method in charm.js [14:11] gary_poster: both models have is_subordinate so it should 'just work' cleanly in the casting [14:12] m_3 we are trying to have fixes for both subordinate bugs in a branch at least. let me know as you approach last minute. you would need to start another environment and deploy gui with "set juju-gui-source="BRANCH I GIVE YOU". Hopefully on last steps to stomp the subordinate display bug... [14:15] sinzui: feedback inbound [14:15] thank you [14:19] rick_h, about your feedback. I noticed yesterday that when I run the entire test suite, I loose my featured charms. I think something is using the real charms collection in a test [14:20] sinzui: orly? ugh. [14:20] rick_h, I agree with all your points and will make changes [14:20] sinzui: ok, well I think the idea stands that if not having them is a failure we should try to auto add them, but might be a follow up/different bug [14:20] sinzui: but thanks, will be nice to help debug issues [14:26] bac: I have a few hours of changes to make to two branches to get our API changes landable. There might be some confusion about doctype. Per https://code.launchpad.net/~sinzui/charmworld/bundles-api-2/+merge/176246 I will change the search calls to use _type, but I think we need to include doctype as data on the charm or bundle so that the client (juju-gui) knows what kind of object to instantiate. [14:28] sinzui: i had seen aaron's comments on that. will be glad to review when you're done [14:28] thank you bac [14:31] frankban, could you please switch your juju core charm to lp:~gary/juju-gui/bug1204331 and let me know when it is up? m_3 << I think that branch will work for you. we will test. keep the other env as backup and we can see if this works for your script [14:33] jujugui, I have a call now. could someone comfortable-ish with GUI (non-charm-browser) charm craziness and/or endpoints look at my commit above and see if they can figure out a nice way to test that? warning, I may ask you to follow through :-) [14:33] gary_poster: in progress [14:33] thanks frankban [14:33] frankban: lemme know if you want another set of eyes [14:35] hatch: "in progress" is referred to the juju gui in my env switching to another source, not to the last Gary's request. So, I guess it's all yours ;-) [14:37] oh haha, ok well in that case! I'll need the commit [14:37] It doesn't look like it's in my backlog [14:37] hatch: http://bazaar.launchpad.net/~gary/juju-gui/bug1204331/revision/888 [14:37] thanks son [14:38] my best gangsta [14:38] hatch: 'lp:~gary/juju-gui/bug1204331'.replace('lp:', 'code.launchpad.net/') [14:38] for future reference [14:38] and thank you chrome "recently closed tabs" [14:39] gary_poster: the environment is ready [14:40] frankban, thank you! [14:41] I really hate how hard it is to get to the actual edited files from these diffs [14:41] like SRSLY!!! [14:41] hatch: bzr switch trunk && bzr colo-branch help-gary && bzr merge lp:~gary/juju-gui/bug1204331 :P [14:42] that won't show me the diff in the file :P [14:43] bzr diff | vim - [14:43] which gives me the same information I have on that commit page [14:43] you tried.... [14:43] :P [14:43] what more do you need to get the 'edited files'? anyway, get to testing, less complaining :P [14:44] well to get the overall picture of the file [14:44] gota load the file into my brainpiler [14:44] which will then slowly execute the js incorrectly [14:44] :P [14:46] Inefficient :| [14:47] m_3 that branch works for me for both of your bugs [14:47] frankban, thank you done with env [14:48] gary_poster: you probably realize this....but this won't solve the issue for the ghost or new inspector [14:48] gary_poster: cool [14:50] gary_poster: so I would create/modify a unit test for the endpoints code to check for the subordinate flag, same goes for the charm model [14:51] a test for the inspector could also be added once we add that functionality [14:51] * hatch is driving towards more unit and less integration tests [14:51] hatch, ack. on call. I suggest proceeding with your previous branch, and we can talk after you are finished with it, or if I have a chance to revisit myself. thank you! [14:52] sure I'm just fixing up the tests now [14:52] np [15:24] gary_poster: thanks!... so does this gui need to be up during deployment of everything or can I tack it onto an existing env? [15:25] m_3, can tack it on [15:26] ack, thansk [15:26] sinzui: let me know when you want to chat. I'm back behind the desk. [15:27] rick_h, okay. I am with webops at the moment. I will ping you when I have time and attention [15:27] sinzui: rgr [15:29] I just found out my VM doesn't have VIM [15:29] haha [15:29] :-) [15:31] what is ^M when it's in a VIM diff? [15:31] they are showing up in the less files [15:31] hatch: windows line endings :/ [15:32] hatch: http://www.tech-recipes.com/rx/150/remove-m-characters-at-end-of-lines-in-vi/ [15:32] ACK! who's using winders??? [15:33] whoever wrote the cookies.less file [15:33] dun dun dunnnnnn [15:40] I have spent more time fixing the d3 lint errors than the tests lol - clearly there is a tooling issue here haha [15:44] Really? [15:44] yeah because I tried to make it not look stupid [15:45] clearly it had different plans [15:45] Yeah, the linter isn't a huge fan of chaining. [15:46] go linter :P [15:47] umm [15:47] I just tried to lbox and didn't get a cr url [15:47] :/ [15:47] see, you anger the linter and you pay the price! [15:47] cr and the linter are working together I see [15:47] well I'll show both of em! [15:47] RUN IT AGAIN! [15:48] now, who is really show'ing who as you re-run lbox :P [15:48] I just imagine them workin like they are in a coal mine [15:50] third time is the charm! [15:50] hatch: except in that particularly strained metaphor *you're* the canary. [15:51] lol damnit [15:51] jujugui call in 10, kanban now (Makyo is leader; sorry for stepping on you yesterday hatch) [15:52] s'ok! [15:53] yuss finally lbox worked [15:53] jujugui looking for reviews https://codereview.appspot.com/11351046 [15:54] gary_poster: lemme know what's next on the chopping block whenever you have a moment [15:55] cool hatch thanks. looking [15:56] On it. [15:58] jujugui call in 2 [16:03] Makyo: should we add anything to the charm details pane to indicate this charm is local/different? Is that already there in the inspector? [16:03] rick_h, That'd be a good idea. It's on the inspector in that it's local:, but something in the pane would be good. [16:05] gary_poster: should I log out to change the juju-gui-source? it worked fine when I destroyed the gui, then redeployed, then set juju-gui-source [16:05] gary_poster: seemed to be a no-op on this one I was logged into [16:06] gary_poster: very much don't want to have to rebuild this entire stack atm [16:06] m_3 you may need to clear out your browser cache [16:06] ah, ok [16:06] gary_poster: how can I check juju-gui version? [16:06] (branch) [16:07] nm, `juju get` wroks in go [16:15] gary_poster: looks great!!! thanks a ton for the help [16:15] yay awesome m_3 good luck [16:55] gary_poster: you said you were going to review my latest branch right? [16:59] hatch, yes, on it [16:59] alright great - no rush just wanted to make sure I didn't need another [17:07] Mark's keynote starts right away http://www.oscon.com/oscon2013/public/content/video [17:08] yep, watching now woot! [17:10] hehe ubuntu edge [17:11] get it out of the way [17:16] Oooooo [17:16] so happy, was thinking this was getting lost lately [17:16] :-) [17:18] Juju! [17:19] * gary_poster nervous [17:19] live demo.... [17:20] * rick_h ducks [17:20] woot, it loaded! [17:20] lol [17:20] lol [17:20] plz work [17:20] phew! [17:20] lol [17:20] yeah, I was worried too [17:21] heh [17:21] benji, he dragged, he dropped, he deployed! [17:21] and related! [17:21] YES! [17:22] why am I so nervous right now...lol [17:22] bcsaller, rock [17:23] YES! it's over! :-) [17:23] that was so awesome [17:23] and it rocked :-) [17:23] yeah, glad that all worked [17:23] too bad we're not at sprints. It'd be quit'ing time to go head out now [17:23] lol true [17:23] lol [17:23] "throw the mic down" lol [17:24] rofl [17:24] :-) [17:24] demo is back [17:25] not us though :-P [17:27] great keynote [17:27] \o/ [17:27] yay :-) [17:28] covered a bunch of stuff [17:28] ok hatch, back to review. I was trying to multitask and failed ;-) [17:28] yea, the spectrum [17:28] haha yeah I totally broke on the multi tasking too [17:28] he wasn't initially planning to cover the gui [17:28] but we all made it look so nice [17:28] exactly :-) [17:29] I'm so glad he did and that it worked out [17:29] that was awesome [17:29] making a release and deployment of the load fix would be good :-P [17:35] hi rick_h. I can hangout now or any time for the rest of your day. [17:35] hatch, LGTM with one concern [17:35] (minor, in review) [17:38] sinzui: rgr [17:39] sinzui: invite on the way [17:39] gary_poster: ok thanks [17:40] gary_poster: https://myupdesk.com/upwrite accommodates treadmills :) [17:40] hatch, heh that's really cool :-) [17:41] yeah I'm thinkin hard about buying one....I use whiteboards a lot heh [17:41] 'course it's more than twice the cost of my current desk :-P but the touch button height adjustment is a killer feature [17:42] it's over 4.5x the cost of my desk lol [17:43] * gary_poster decides it is time for lunch [17:44] yay, lunch [17:44] biab [17:54] is there a recording of the keynote? [18:03] that up desk has a minimum height exactly where my keyboard sits....hmm :) [18:20] sinzui: gary_poster I'm landing autocomplete behind a feature flag. It needs some UX love still, but functions. I'm wondering on priorites. keep with autocomplete? work on inspector charm details display/functionality? bugs like #1200743? something else? [18:20] <_mup_> Bug #1200743: complex search/view interactions in fullscreen fail to work [18:21] rick_h, The search navigation bugs really irk me. I'd like to so those bugs like the closed before adding new features. Putting it behind a feature flag is fine nonetheless [18:22] sinzui: ok, thanks [18:25] absolutely hilarious http://www.youtube.com/watch?v=Lf-WgUG8sR8 gary_poster you need to watch this....all the way to the end lol [18:30] curses! I have no lbox'ing light on my desktop [18:34] rick_h: http://blog.safaribooksonline.com/2013/07/16/javascript-powered-arduino-with-johnny-five/ [18:39] lol funny comment https://plus.google.com/113936232300062765333/posts/axBNnxtRzzk [18:40] hatch, they named me gerbrand anyway ;-) [18:41] like the author? [18:43] rick_h, sinzui, makes sense to me. I look forward to having autocomplete behind us though, so +1 on getting that handled. I think the charm inspector work is mostly done, although... [18:43] rick_h, would you be willing to write an email to Huw [18:43] describing what he needs to know/do about styling the inspector's charm panel? [18:43] the UX is minimal [18:43] I mean [18:43] we have had minimal direction [18:44] sure thing [18:45] so the request would be to approximate what little direction we have, filling in the rest with his own good taste and making as few changes as reasonable from the charm browser styling [18:45] rick_h, thank you! please cc me. but I think you can best direct him to the HTML architecture that he will know [18:45] ok will do [18:46] hatch, like my dad, and his dad, and his dad, and his dad, and...my full name is Gerbrand Poster IV; if we did a line of people in my family with my name and simply incremented then I would be XXIV [18:47] very cool [18:47] it's Dutch right? [18:48] hatch, yeah [18:48] so going back all that ways are you royalty or a peasant? ;) [18:51] hatch, heh, soldier, supposedly. name means "guard at the post with arrow of fire" or similar [18:52] ahh very cool :) [18:52] I don't know much of my history...so I made it up that I'm a traveler from the future [18:52] it's pretty complicated....woudln't make for a very good movie....but a quality book series [18:52] might be my big break....lol [18:52] lol [18:53] hatch btw ack on defined. ship it. [18:53] shipping! [18:55] :-) [18:56] jujgui charm programmers: I need two volunteers to review a frankban branch. IMO they usually rock fwiw. :-) https://codereview.appspot.com/11725044/ [18:56] jujugui I should say [18:56] however it is a bug 'un [18:57] * hatch looks at file extension.... [18:57] I can start on it in a few minutes [18:57] * hatch looks at node [18:57] * hatch looks at the file extensions.... [18:57] thanks bcsaller [18:57] sorry I'm out [18:57] :D [18:57] :-) [18:58] I'll be going through it for sure but I can't count to a quality review :) [18:58] cool [18:58] I figure this is how I'll learn python [18:59] gary_poster, bcsaller fwiw, i tracked down the issue re export. even if deployer does exports, i think its important for the gui to support it we want people to be able to capture scratches from jujucharms.com / mem envs. [18:59] hazmat, I was just about to thank you. saw bug comment and was looking at github [18:59] the issue seems to boil down to a yaml 1.1 (which is by far the most common) and yaml 1.2 compatibility issue [19:00] right [19:00] gary_poster, i've got a patch as well that fixes the issue [19:00] cool, I hadn't seen it yet [19:00] hazmat, awesome! that was next question :-) [19:00] thanks [19:00] not saying its the most elegant.. but it seems to work in light testing.. http://paste.ubuntu.com/5908577/ [19:01] hazmat: is there harm in quoting all the strings? [19:02] that does away with the aliases as well [19:02] bac, approved swap day fwiw [19:02] bcsaller, its ugly ;-) [19:03] bcsaller, ie. the only strings that need quoting are those that need quoting.. i mean part of the appeal of yaml is that its relative terse wrt to extraneous syntax. [19:04] like json [19:04] ;) [19:05] xjson for machines, yaml for humans ;-) [19:06] if YAML added only a couple syntaxy things it could easily be sent over the wire [19:06] kind of unfortunate really [19:11] rick_h: you're right - this recalc height method is too confusing [19:11] (see I eventually will admit I might be wrong) :P [19:12] * hazmat notes the date [19:13] lol [19:15] hatch: :P [19:15] hatch: yea, I've not gotten that far in my refactor :) [19:23] Hey chaps\ [19:24] Well done on the 1.0 release [19:24] (I'm guessing it's 1.0) [19:24] Looks great [19:24] goodspud: thanks [19:24] just imagine when it hits 1.0 how awesome it will be ;) [19:24] its 0.8 right now [19:25] appreciate you poping in here :) [19:25] All good. I like to see how my baby is growing [19:26] I mean "our" baby [19:26] I gave up parenting rights [19:26] lol [19:28] bcsaller: I found a 'bug' with the statusbar - it appears that when it's initially rendered it's 920px high for some reason...curious if you have any idea why that is? I can limit it with a css style but want to see if this is an actual bug or not [19:28] Nice to see you dropped the "health" circle. I never really liked it. My wireframes way back when had a simple line but "pressure" from up to forced it to change [19:28] from "up yop" [19:29] Ah crap. Typing while drinking whiskey isn't good [19:29] playing with the Balmer Curve? [19:30] Lets call it "experimenting" [19:31] Although I did do amazingly well bowling this afternoon [19:32] sounds like a successful experiement to me [19:33] hatch: I don't see that happening, initial height should be fontSize * 2 [19:33] I can demo it and the fix if you like [19:33] err + 2 [19:34] sure [19:34] guichat? [19:34] but of course [19:36] goodspud! [19:36] hazmat: hey dude [19:40] Oh, hey :) [19:41] Makyo: Yo [19:46] hi goodspud [19:47] Makyo, benji: a quiz: are you running the charmworld tests in an lxc or a "real" env (metal or vm)? [19:47] bac, Real. [19:47] hey goodspud! [19:47] bac: lxc on metal [19:47] and i predict benji will say lxc [19:47] yes [19:49] the lxc cloud images have the local tz set to utc. the problem was some of the date conversions were using fromtimestamp which returns a datetime in the local timezone, which looks like it is the day before wrt utc for those of us running in real environments. [20:10] bac: heh; nice bug [20:12] sinzui: can you review https://code.launchpad.net/~bac/charmworld/spurious-test-failure/+merge/176774 [20:13] I can [20:15] but will you? [20:29] sorry the power keeps going out here :/ [21:06] sinzui: thanks for the review. i don't see the issue with 'first_change', though. where did that code snippet come from? looking at the code base i don't see first_change being using in a way that'll break. [21:06] your other point about indexing into a potentially empty list was a good catch [21:07] bac: the code on 139 and 143 is doing charm.changes[-1]['created'] [21:07] if changes is an empty list, that breaks [21:07] sinzui: yeah that one i saw. just didn't see the dangerous use of 'first_change' [21:08] bac: charm.changes[-1] == charm.first_change [21:09] bac reports is the only module that isn't using charm.first_change [21:11] bac, now I recall the issue. maybe we don't want to change the odd use of [-1] [21:11] bac: the charm.changes is only the last 10 changes. We do extra work to get the true first change. [21:12] bac: If the plotting wants to true first change, we want to use first_change. [21:12] sinzui: i have http://paste.ubuntu.com/5908981/ and it seems like it should suffice. fwiw i never read [-1] as an odd use so maybe that's why i'm confused [21:14] bac, it is odd if you know that that will gives you a change from last week of juju-gui. The charm is much older than last week [21:15] bac that change is safe [21:15] ok, i'll resubmit [21:15] oh bugger. I think we have something even more accurate. [21:16] jujugui, anybody know if we recently somehow turned the YUI CSS sam skin on? If you try to delete a service from the environment, the box is a lot less attractive that it used to be (than it is on jujucharms.com) [21:16] gary_poster: yup [21:16] hatch, we turned sam on? [21:17] i thought yui3-sam was always on [21:17] bac: charm.date_created is the most accurate date of when a charm was created. The value also can be null if only the store knows about it [21:17] yeah I think bac and rick_h wanted it [21:17] Maybe Makyo and rick_h ? bac has been on charmworld lately [21:17] hatch: the slider uses sam skinning for rails, etc [21:17] I fought against it but was voted off the board [21:17] :) [21:17] ah [21:17] but... [21:18] it's ok on jujucharms.com [21:18] hatch: really? when was this? [21:18] this was only within the past week [21:18] oh no I am pretty sure it was added a couple weeks ago [21:18] since we made the release at the sprint last wednesday [21:18] oh [21:18] hatch, whoa, what? the skin has been in place from day 1. [21:18] We have never NOT had the Sam skin. [21:18] no I definitely remember yui3-skin-sam being added to body recently [21:18] yeah, i don't recall any battle royale over the skin [21:19] Makyo, hatch, bac, sorry, maybe this is a red herring. anyway, all I recall [21:19] hatch, It used to be on the parent div for the slider, but it has ALWAYS been part of the project. [21:19] hatch: sure but that wasn't its first use [21:19] I mean all I weant to say is that the destroy dialog got done broke in the past seven days [21:19] Makyo: +1 [21:19] * Makyo implemented it in the first place :S [21:20] * gary_poster wishes he had started his question in a different way :-P [21:20] having it on the container is fine - but I objected to it on the body [21:20] Sorry, carried away. Continue. [21:20] lol [21:20] all I got is this: [21:20] go to jujucharms.com and make a service and then delete it from the environment: nice dialog box [21:21] go to comingsoon and do the same: uglier dialog box [21:21] the styling that appears to be involved is sam styling [21:22] that is on the body [21:22] sinzui: i've pushed the changes for re-review [21:22] the yui3-skin-sam class is *not* on jujucharms.com bdy [21:22] body [21:22] * sinzui looks [21:22] that's all I've got :-P [21:22] sinzui: not including your latest comment about date_created [21:23] bac: sure. I think have a real date might break reporting. If someone really cares about accuracy, we can fix it later [21:24] moreover, if I remove the yui3-skin-sam class from body, then we go back to happy styling [21:24] so...hatch is on the right track somewhere or other, because that yui3-sam-skin class was only added since we made a release [21:24] 0.8.0 [21:24] gary_poster: I would propose a branch to remove that class from the body and put it only on the containers that absolutely require it [21:25] gary_poster, cool. Can we maybe move it to the parent class of the slider? If nothing else, that will be removed in the 'style slider' branch. [21:25] sinzui: sent to tarmac [21:25] * bac walks very patient dog [21:25] bac, did you provide a commit message? [21:25] although I don't see any styling on there that's from the sam skin style [21:25] It *looks* like that class is not necessary at all to the slider [21:25] sinzui: indeed i did [21:25] all good i see [21:26] gary_poster: no it is [21:26] gary_poster: it is my understanding that it is. it is specified on the div for the slider [21:26] it still has it on it's container [21:26] hatch, ah! [21:26] or, bac, ah! [21:26] someone, ah! [21:26] ah ha [21:27] that'll go away when someone skins up the new slider style [21:27] lol [21:27] um [21:28] I don't see the issue you're reporting though [21:28] when I remove the class the styles stay the same for me [21:28] right [21:28] that's what I was going to say [21:28] ohh wait [21:28] you're talking w/o the flag [21:29] yeah w/o the flag I see the issue [21:29] really? [21:29] I don't have flag on... [21:31] and there's already a div with the yui3-skin-sam class around the zoom [21:31] hatch what badness are you seeing when you remove the class from body? [21:32] when I remove the class it's back to normal [21:32] with it, it has some internal border in the popup alert [21:32] right [21:32] I was trying to dupe with the serviceInspector flag on [21:32] :) [21:32] but the zoom thing is alwats fine, right? [21:32] I can dupe with seviceInspector too [21:33] yes because it has skinsam on it's container [21:33] oh without it, it breaks the tabview in the charm browser [21:34] ah! [21:35] ok... [21:35] so we should be able to add it to the tabview container [21:36] hatch, yeah I was thinking of just putting it on the charm browser [21:36] yeah that appears to fix the issues [21:37] without introducing new ones [21:37] ^ key ingredient [21:37] :D [21:37] :-) [21:37] yui3-skin-sam is an artifact before they realized noone wants their styling and only wants the functionality [21:37] haha [21:49] except it was core to some of the functionality [21:50] anybody seen this recently? http://pastebin.ubuntu.com/5909097/ [21:51] trying to get a dev environment going to test a branch/bug fix, but npm is complaining about a checksum mismatch. [21:51] hazmat: yeah exactly - they now have it split between core css and style css in the new module format [21:52] specifically its on yui [21:52] looking at paste... [21:52] hatch, it looks like its the nodejs package for yui that's causing the issue [21:52] that's odd - I just installed that [21:53] I can't say I've ever seen that error [21:53] possibly a npm cache issue? [21:53] yeah.. retrying [21:56] yeah.. npm cache [21:57] sinzui, to follow up on redirects did you mention you were going to redirect for old charm urls? [21:57] :) glad I could help [21:57] arosales, they were deployed, and they did not work [21:58] sinzui, so still in progress? [21:58] or a no go [21:58] arosales, we believe there are conflicting redirect/rewrite rules in the production setup of apache [21:58] we will try again to fix the issue tomorrow when our webops is online [21:59] sinzui, ok thanks for continuing to work on it [21:59] we have a few askubuntu posts that are giving a blank page on jujucharms [21:59] ex http://askubuntu.com/questions/264673/juju-charm-zentyal-isssue and http://askubuntu.com/questions/268634/how-are-log-files-persisted-with-the-logstash-charm [21:59] * arosales sure there are others [21:59] gary_poster: yes, this was part of the autocomplete and bac had it in a branch that did something bac did back when I was first working on AC [21:59] oh dear [22:00] arosales, that url conflicts with juju-gui which believes it is a url that it can load [22:00] gary_poster: so it's used for the slider and the AC widget. Without it we'd need to copy all css rules that make the AC overlay work. It seemed less work to 'undo the damage' in the parts effected like the tabview widget [22:01] arosales, we weren't planning to support that URL as a redirect since the goal was/is to show charm details in the gui. [22:02] arosales, this may be addressable with the search story where we want juju-gui to support simple urls [22:02] rick_h, did you see my proposal in the email? [22:02] sinzui, sorry I am a bit confused [22:02] so old urls looks like [22:02] it dupes the class only twice and works afaik [22:02] https://jujucharms.com/charms/precise/logstash-indexer/ [22:03] We didn't discuss supporting user branches as redirects this week [22:03] and like [22:03] http://jujucharms.com/~christophe.sauthier/precise/zentyal [22:03] new urls look like https://jujucharms.com/precise/logstash-indexer-0/ [22:03] that link you showed me is the first time we have discussed user branches [22:03] sinzui, correct, not this week. however, it's been a goal to support old urls. I think we can support these in the GUI redirect rules themselves [22:04] sinzui, you are saying the gui/charm browser tries to parse both of those? [22:04] yes, and it fails [22:04] sinzui, I think we can make it succeed, don't you? [22:04] arosales, the redirects we setup are for features the juju-gui does not support [22:04] seems pretty straightforward on the face of it [22:04] gary_poster, absolutely [22:04] cool [22:04] ugh, making url parsing like that succeed will be a pain and complicate the browser dispatch code farther than it already is. [22:05] rick_h, really? can't we simply make the GUI do its own redirection? [22:05] gary_poster: just replied to the email. I'll try to do a follow up branch that gets autocomplete working again. I'm out tomorrow [22:06] gary_poster: right now that gui is doing a lot of parsing logic to determine if things are /search/something /sidebar/something /precise/charmid [22:06] rick_h, ack on autocomplete/sam skin, thanks [22:06] gary_poster: hmm, well in looking at the ones you linked only the /charms doesn't work currently [22:07] gary_poster: adding that isn't a huge pain as we can support it as we do /fullscreen /search and /sidebar now [22:07] rick_h, right I think we have two simle triggers [22:07] ^/charms [22:07] gary_poster, we have been burned by the complex redirection rules in the past. it is hard, but not impossible. We need to guarantee that we can recognise a simple url requesting a charm can be redirected to the new charm details URL. [22:07] and ^/~ [22:07] gary_poster: right, but /~ should work now? [22:07] * rick_h goes to find a charm with an owner to try [22:08] https://jujucharms.com/~juju-gui/precise/juju-gui does not [22:08] rick_h, correct! jcsackett added support for ~ 3 weeks ago [22:08] https://manage.jujucharms.com/~juju-gui/precise/juju-gui [22:08] ah [22:08] then when what we are encountering is the need to not strip off the last -foo I bet [22:08] gary_poster: right, we've had that bug for a little bit [22:09] sinzui: though I am not seeing https://jujucharms.com/~juju-gui/precise/juju-gui/ working and that should as well. I'm getting a 404 on https://manage.jujucharms.com/api/2/charm/~juju-gui/precise/juju-gui [22:09] sinzui: so that might be a bug in the api on charmworld. It should support a 3 part id I thought. :/ [22:10] rick_h, please specify a rev [22:10] https://manage.jujucharms.com/api/2/charm/~juju-gui/precise/juju-gui-0 [22:10] sinzui: doh! [22:10] right [22:10] https://jujucharms.com/~juju-gui/precise/juju-gui-9/ works [22:10] so this comes back to having some sort of 'HEAD' route for ease of typing and google-fu'ing [22:11] yes [22:12] rick_h, _ alway add -0 which works now. [22:12] when we have versions, I think we need to decide how to get HEAD [22:12] ok, so before I leave. Follow up branch for autocomplete/skin-sam and we can do a /charms redirect from within the Gui if we want and we still need to figure out what we want to do for a HEAD url for the other url. [22:13] rick_h, we want! really we want to show the sexy details for all charms [22:14] sinzui, rick_h, arosales is using -head for urls on juju.ubuntu.com [22:14] gary_poster, sinzui, rick_h so it "sounds" like redirects are still in the plan, but details on how that happens is still in the works [22:14] arosales, there are two sorts of redirects [22:14] one is redirects to manage.jujucharms.com [22:14] gary_poster, I can quickly update juju.u.c to have the correct URLs [22:14] this topic is not a redirect [22:14] right [22:14] it is about a supporting historic urls for charms [22:15] where are those anyway sinzui? deployed? [22:15] deployed and failed because they conflict with the production apache configs [22:15] the other is to do what sinzui describes [22:15] that means changes to the GUI [22:16] which hopefully we can get outr tomorrow in a release, and next week at the latest arosales [22:16] sinzui, ugh. :-/ do you see a resolution? [22:16] webops will return to work with new apache files, or we do imprerfect redirect support by only supporting http requested redirects to manage.jujucharms.com [22:17] gary_poster, this is a case where we have a dedicated webop, and he works on the issue during core hours [22:17] * arosales rephrases, redirectes to manage.jujucharms.com and supporting old charms URLs are still in plan it sounds like [22:17] arosales, yes, defeintely. sorry for runaround. [22:17] defintely [22:17] defintely! [22:17] ugh [22:17] :-) [22:17] arosales, yes 100% [22:17] definitely [22:17] lol [22:17] thanks gary_poster, rick_h, and sinzui [22:18] jcastro, had ran into a few blank pages at OSCON and was wondering about the status is why I brought it up. [22:18] well if jcastro needs it...tell him patches welcome :P [22:18] lol [22:21] ok, with that I'll see you all friday. Party on! [22:21] see you rick_h thanks [22:28] getting this error on make test-prod.. just curious if it rings any bells.. http://pastebin.ubuntu.com/5909182/ [22:30] hazmat, I think rick_h or Makyo had some issue like that 2 weeks ago. I think they had to do some extaordinary make clean step because the library was really installed correctly [22:31] sinzui, thanks [22:32] maybe s/was really/wasn't really/ [22:34] hmm [22:38] rick_h, I'll pass on the message :-) [22:39] hazmat, haven't seen. make clean-all rips out everything, though [22:44] gary_poster, are there up to date hacking docs around? [22:45] the ones i've perursed (hacking and docs/hacking.rst) seem a little dated [22:45] hazmat, if HACKING isn't up to date, then no. let us know what breaks and we'll fix it [22:45] mostly i'm wondering which npm mods need to be installed globally [22:45] maybe not tonight tho :-P [22:45] ah [22:46] oh.. that's there. [22:46] jshint, mocha-phantomjs, and phantomjs [22:46] y [22:46] its just a blast from the pass to see improv at the top of hacking docs ;-) [22:46] :-) [22:54] hmm.. still getting the error on a full reset. googling finds me.. this ref https://github.com/metaskills/mocha-phantomjs/issues/76 [22:55] it sounds like this needs a mocha version update for gui [22:55] uh oh [22:56] updates are very painful [22:56] but maybe you can apply Kapil magic and make it go away :-) [22:56] gary_poster, yeah.. it might be called not using lbox ;-) [22:56] heh [22:57] gary_poster, i'm just updating a library asset for js-yaml.min.js to fix the export issue, just wanted to try it the proper way.. but tbd. [22:57] cool hazmat. send a mail or file a bug so we don't lose that pain and can try to address? [22:58] k, i'll drop an email to gui [22:58] thank you [23:12] Morning