[07:20] mornin' all [07:23] rogpeppe1: Morning [07:23] huwshimi: hiya [10:44] morning all [10:44] https://github.com/juju/cmd/pull/2 rogpeppe1 frankban kind of cool, pull request on that already [10:44] rick_h_: yeah. just looking at it [10:47] rick_h_: nice! [10:55] frankban: if you get a sec can you look at the latest brew error for quickstart? [10:55] rick_h_: link? [10:55] https://github.com/Homebrew/homebrew/pull/30070 [10:55] http://bot.brew.sh/job/Homebrew%20Pull%20Requests/11953/version=mavericks/console in particular [10:58] rick_h_: yeah, that's the error from last Friday. We should change the test section of the formula to something like [10:59] system "#{HOMEBREW_PREFIX}/bin/juju-quickstart", "--version" [10:59] rick_h_: so using the dashed juju-quickstart [10:59] frankban: oh, sorry. I thuoght it was newer since then [10:59] frankban: ignore me then, my bad. [10:59] rick_h_: np [12:28] hi frankban, i reviewed your branch. thanks. [12:28] bac: thanks! [12:35] bac: landed [13:22] morning all. [13:40] rick_h_: do you remember the address of the production charmstore? [13:41] frankban: https://store.juju.ubuntu.com/charm-info?charms=cs:precise/juju-gui [13:41] rick_h_: thanks [13:49] frankban, rick_h_: homebrew jenkins is happy. all i did was change the minimal test from 'juju quickstart --version' to 'juju-quickstart --version'. [13:50] bac: \o/ [13:50] both work on a live system. unsure why their minimal jenkins CI fails [13:50] https://github.com/Homebrew/homebrew/pull/30070 [13:50] bac: because in your system you have a configured juju home [13:50] frankban: but --version should cause it to hop out early, no? [13:51] bac: there is a juju-core bug which prevents arguments to be passed to plugins if a default environment cannot be found [13:51] frankban: oh really? well that sure explains a lot [13:52] bac: for that reason, in their platform --version is never passed, and quickstart correctly starts the interactive session [13:52] mystery solved [13:56] rick_h_: i'm moving the brew acceptance card back to tracking and not review since it is out of our hands and relying on brew upstream. [14:31] bac: awesome thanks, sorry was on the phone. Awesome that jenkins is now happy [14:32] jujugui luca jujucharms.com updated and released woot [14:32] Yay! [14:32] rick_h_: ace, good job everyone! [14:34] jujugui interesting http://arstechnica.com/information-technology/2014/06/new-internet-explorer-developer-channel-gives-devs-a-taste-of-whats-to-come/ [14:35] Nice [14:53] jujugui call in 8 [15:00] jujugui call in 1 [15:00] jcsackett [15:08] luca: can you point me to the dropbox folder with all the machine view workflow designs? Having a hard time tracking the link down right now. [15:08] kadams54: it's in google docs [15:09] rick_h_: ah yes, so it is [15:10] kadams54: which work flows are you looking for in particular? and do you want wireframes or visuals? [15:12] luca: everything… and visuals. Assuming the stuff in Google Docs is up-to-date, it looks like what I need. [15:12] rick_h_: i still have no travel auth [15:12] kadams54: all visuals in google docs should be up to date [15:13] bac: yea me either. I've got a 1-1 with mramm today and I'll bring it up [15:13] jujugui who has gotten auth ? [15:13] rick_h_: oh, ok. based on your comment to move forward i assumed people had [15:13] bac: oh, did you not get hte email to file a request? [15:14] rick_h_: yes, i did that [15:14] rick_h_: just no auth to actually book [15:14] Based on what I see in the spreadsheet, I think hatch is the only one who's been auth'd to book. [15:14] yep, ok will bug mramm in our 1-1 today [15:14] I have the flights in there that I'm going to request once I get auth, but they're subject to change. [15:15] kadams54: I’ve shared the juju universe flows out with you, it shows you how everything fits together. Machine view is pretty comprehensive in their. [15:16] luca: Great. Trying to make sure we're not missing any of the flows. [15:16] kadams54: cool, thanks [15:17] kadams54: https://drive.google.com/a/canonical.com/#folders/0B7XG_QBXNwY1aVh1cC0wU0JRaW8 is the dropbox stuff that you're thinking of [15:17] Figured as much… [15:17] cool [15:19] rick_h_: created a new bug: https://bugs.launchpad.net/juju-gui/+bug/1330520 [15:19] <_mup_> Bug #1330520: When dragging a unit drop zones should be clearly marked. [15:20] rick_h_: woah, whats mup? [15:20] luca: rgr ty much [15:20] luca: watches for bug # and such to provide helpful links [15:20] luca: so you can do #1330529 [15:20] luca: oh hmm, maybe #1330520 [15:20] test #1330520 [15:20] <_mup_> Bug #1330520: When dragging a unit drop zones should be clearly marked. [15:20] <_mup_> Bug #1330520: When dragging a unit drop zones should be clearly marked. [15:21] will it'll load the bug details [15:21] that’s cool [15:21] yea [15:21] luca: on the designs there's a lack of 'add to bare metal'? [15:22] rick_h_: you can add that [15:22] luca: ok [15:31] rick_h_ kadams54 yes I've authed and booked [15:33] rick_h_, kadams54: +1 on the mramm needs to auth travel. [15:41] jcsackett if you don't want to use Y.later with periodic you can use https://developer.mozilla.org/en-US/docs/Web/API/window.setInterval there will be no difference in execution, just don't have to rely on YUI if you don't want [15:44] hmmm, /me sees timeout relatedish stuff and gets nervous [15:44] rick_h_ async all the things!!!! [15:45] :P [15:45] yea, but async and tests that pass all the time seems to be the oopsie [15:46] well I suppose the good part to using Y.later is that it can be stubbed out to make it synchronous for the tests [15:46] all good, you guys know what you're up to. Just caught a whiff :P [15:47] oh I'm with you on that one - there was a reason the state stuff is all synchronous now :D [15:48] frankban: reminder that today is your qa day. If you get a chance maybe do a pass through the brew stuff or something to do a bit of qa. [15:49] hatch: you're on deck tomorrow. [15:49] righton [15:49] if async doesnt work you're not using enough. [15:49] :p [15:49] that's promises :P [15:50] rick_h_: sure, I'll do it, thanks [15:51] frankban: thanks, I will one day figure out how to remember to check qa day before the standup. [15:51] :D [15:53] luca hey I just looked at your Machine_View_Drop_States pdf an have one technical concern [15:54] hatch: shoot [15:54] luca if we have to change 1000's of machines dom elements when the user starts to drag there could possibly be a performance issue there [15:55] hatch: thats an interesting concern which we don’t think about :P [15:55] hatch: yea, we might have to do some management of the viewable area [15:55] haha, well that's why you have us :D [15:55] luca there are potentially ways we can mitigate that but it would be great if you could maybe look into alternate approaches to this [15:55] hatch: I think we can move forward with the interaction, and maybe look at optimizaitons of viewable area, css single dom updates, etc [15:56] hatch: as long as we don't change dimensions of the existing containers a show/hide situation should be pretty quick. [15:57] rick_h_: hatch is it all ok? [15:57] yeah - I'm just worried that at scale there could be a delay. We may have to do some viewable-area stuff anyways for the current implementations at real scale [15:58] hatch: but if we can do simple show/hide stuff I htink browsers take care of the viewable area for us. There's potential at least. [15:58] yeah - I'm thinking that we might have to render/destroy elements as we scroll depending on the size of the env [15:59] hatch: yea, we'd not want to do that [15:59] hatch: but we've got an overall perf issue to investigate as well [15:59] yeah [15:59] hatch: but at some point, when your environment is 1000 machine, are you doing to want to drag/drop a service in the GUI and find that #835? [15:59] or just cli it [16:00] luca ok I've been convinced that we can do it then look at ways to fix it if it's a problem :) [16:00] rick_h_ yeah that's a good point [16:00] lol [16:00] hatch: yea, good to be aware of for sure [16:00] lol [16:00] thanks guys [16:01] luca ok ONE more question [16:01] :) [16:01] in a small env, when the user is dragging, they may want to see what services are on the machines already and the specs of it? before dropping [16:01] maybe we change the name of the machine to be "Add to machine XXX" instead of changing the whole token? [16:03] ^ luca [16:32] Anyone know what hotel we'll be staying at in London? [16:33] kadams54: not confirmed yet, what's up? [16:33] Shopping for a chip-and-pin card; most of the US ones seem to be travel-related loyalty cards for airlines or hotels. [16:34] kadams54: ah yea. last time we were here: https://www.google.com/maps/place/citizenM+hotel+London+Bankside/@51.5054283,-0.0994532,19z/data=!4m6!1m3!3m2!1s0x487604c3abe490a3:0xfe2b1e24d4edbed9!2sCanonical+Group+Limited!3m1!1s0x0:0x81fe4478ab140a51 [16:34] kadams54: I will say I had issues with cards. Soemtimes I could use it once and then not again [16:34] but managed to get by ok without a chip/pin card so far in all our travels [16:34] though couple of times had to deal with local cash and work with others on the team [16:35] london was ok with swipe cards, best place of many we've been to [16:35] Yeah… I wasn't a big fan of my experience in Montreal for Pycon, so I'm ready to just make the jump. [16:35] My bank will be offering them this year, but not soon enough for the trip. [16:40] Right now this looks like the best option for me: http://www.cashpassport.com/http://www.cashpassport.com/ [16:40] er [16:40] http://www.cashpassport.com/ [16:53] hmm there is a hadoop charm from charmers that's failing on charmworld [16:54] this is the link https://manage.jujucharms.com/api/3/charm/trusty/hadoop-0 [16:54] ^ lazyPower [16:54] it's showing up in the 'New' results [16:54] hatch: yeah, why is this borked? [16:54] http://i.imgur.com/I3L2bIA.png [16:55] metadata isnt loading, icons missing [16:55] it passes proof [16:55] hmm bac can you provide any insight into ^ [16:55] the manage link returns "no_such_charm" [16:56] whaaaaa [16:56] * lazyPower scratches head [16:56] did i do something stupid during the promulgation process maybe? [16:56] probably :P [16:56] honestly I have no idea ;) [16:56] i mean, i'll own it. I probably did something dumb [16:56] thats toatally within my realm of capabilities [16:57] rick_h_ any idea how to investigate this issue? ^ [16:58] hatch: in a meeting, not sure atm. Can peek later or ask jcsackett or bac for assistance [16:58] jcsackett: ping [16:58] ok np [16:58] jcsackett: i think i did something stupid... [16:59] lazyPower lets just say you DID do something to put it into this state, the process should be simplified in a way in which it's not possible :) [16:59] it's a very odd state imho heh [17:00] hatch: looking at my bzr refs, everything is 1:1 with previous promulgations [17:00] lazyPower: https://store.juju.ubuntu.com/charm-info?charms=cs:trusty/hadoop [17:00] lazyPower: can you juju publish it? [17:01] lazyPower: rev0 seems odd [17:01] lazyPower: but yea, maybe the /interesting url is loading bad charms [17:01] lazyPower: please file a bug [17:01] ack. i just ran juju publish [17:02] lazyPower: ok, sometimes juju publish points out an error that we've missed in charmworld [17:03] cs:~charmers/trusty/hadoop-0 - its returning what i would expect [17:03] inc. bug [17:03] rick_h_: quickstart QA seems ok on osx, Unfortunately I've found an old HP Cloud env to no longer work. Filed bug 1330553 and created a card [17:03] <_mup_> Bug #1330553: Align quickstart to the latest HP Cloud configuration options [17:03] frankban: rgr, ty much [17:03] qa day strikes again! :) [17:04] * jcsackett returns from lunch, tries to catch up on pings. [17:05] lazyPower: what exactly is the problem? the trusty/hadoop-0 should be promulgated, but isn't in charmworld? [17:05] jcsackett: it's showing as a new charm in /interesting, but isn't in charmworld to be able to load [17:05] https://jujucharms.com/trusty/hadoop-0/ [17:06] :-) [17:06] jujugui lf a quick review/qa https://github.com/juju/juju-gui/pull/389 [17:07] jcsackett: right. Is it heresy if i run charm promulgate over what should be promulgated already to ensure it wasn't an intermittant connectivity issue during the promulgation? [17:07] this would then be retargeted @ charmtools vs charmworld [17:07] lazyPower: i don't know if it would be heresy, tbh. [17:08] lazyPower: but it does look sort of...partially promulgated, in that gui is looking along the wrong path. eg, http://comingsoon.jujucharms.com/~charmers/trusty/hadoop-0/ *does* find it. [17:09] so partially meaning it has been read as a promulgation or as just a bzr push or combination of both? [17:09] this is where my knowledge of the store goes grey, i dont really understand the guts of the process server-side [17:09] jcsackett: I wonder if rev 0 is getting cast as a false value or something odd [17:09] lazyPower: yeah...the store bits are outside my knowledge as well. :/ [17:10] lazyPower: can you push another rev and get that to 1? [17:10] rick_h_: sure [17:10] rick_h_: it's weird, actually, look at the URL when you hover over the token vs what you dispatch to when you click it. [17:10] rick_h_: why is GUI eating the ~charmers? [17:10] jcsackett: because it's promulgated, it's not supposed to be required [17:11] rick_h_: ok, but gui doesn't know its promulgated--this may be ingest error. charmworld doesn't list as promulgated either. i'm +1 on update rev and "re promulgate." unless there's a way to unpromulgate and then redo it. [17:11] jcsackett: yea [17:13] rick_h_, jcsackett - pushed to rev1 && promulgated again [17:13] lazyPower: and now we wait for ingest. [17:14] jujugui anyone available for a qa and review on https://github.com/juju/juju-gui/pull/389 it's just a small code removal branch, more are coming [17:16] hatch: looking. [17:17] thx [17:22] rick_h_, lazyPower: figured out the problem, according to heartbeat, charmworld hasn't ingested since yesterday. [17:22] jcsackett: interesting, wonder how the charm was in the 'new' in interesting [17:23] rick_h_: it was new yesterday--pushed up on the 13th. [17:23] gotcha [17:23] * jcsackett hopes it's reproduced on a server we control... [17:24] jcsackett: yea, we need to ping webops then to get it restarted or something. Get a hole of the app.log and app-exceptions.log [17:24] hold bah [17:25] rick_h_: yup. [17:28] jcsackett: well thats clever. Thanks for the heads up jcsackett. i hope this re-promulgate didn't just tank the process [17:28] lmk if thats the case, I'll unprom and restart [17:28] lazyPower: doubt it. process was kicked before you did it. [17:29] jujugui running to old house over lunch, back in a few. [18:31] jcsackett: doesn't appear to have fixed itself over lunch. [18:32] lazyPower: no indeed. i'm still digging into it, but no fix yet. [18:32] ack. thanks for taking a look. [18:32] rick_h_: is there a way to just kick ingest? been so long since i poked at it i don't know if there is. [18:33] jcsackett: it's a process running by supervisor and needs to be running/restarted there [18:34] https://bugs.launchpad.net/charmworld/+bug/1330582 -- i left this behind to track progress if its not as simple as kicking ingest [18:40] rick_h_: do we have any objection to just having them start/stop supervisor and worker on production and seeing if we're good? [18:40] jcsackett: that's fine, I just want to make sure we do get the logs from the app and supervisor for the last ingest timeframe to see if there's anything we can address. [18:40] jcsackett: but running > * [18:41] app and app-exception have nothing. [18:42] jcsackett: then yea, if it's not ingesting did supervisor kill/not restart or something? [18:42] rick_h_: that i don't know; i can't find a copy of a log with supervisor info to request, and i can't get into QA to double check logs. do we have docs on logs? [18:45] i also can't find the difference between start/stop supervisor and start/stop worker, which bugs me since i added it way back when and the failure to doc is mine. [18:45] always hate it when the person i should be mad at is me. :p [18:59] yeah that guys sucks sometimes [18:59] he is totally unable to take constructive criticism....lol [19:14] jujugui: could someone review changes just to the quickstart README file? https://codereview.appspot.com/109050044 [19:14] sure [19:14] hey hatch there was a canadian warship in port down here this weekend. loading up on rum, i guess. [19:15] bac maybe you're Canadian now? ;) [19:15] nah, they couldn't have gotten past our mighty fort [19:15] lol [19:16] or if they did, they would've succumbed to dysentery. that's the way it always played out. [19:16] haha, playing some Oregon Trail? [19:16] no, that literally is the story of every invasion since 1650 [19:16] oh haha ok then [19:18] bac so I understand why you would include the pip instructions, I'm just not sure why anyone would do that if they also require brew [19:18] wow, the markdown preview in atom is nice [19:19] be sure to turn off the tracking - they send all of your filenames to the mothership [19:19] hatch: i started to go into that but didn't. it could be useful if, for instance, a newer version were on pypi that hadn't made it into the brew repository yet. [19:19] lazyPower: with bac's help looks like we got ingest going again--i'll check on your hadoop charm soon to see if it updates. [19:19] that is not an unusual occurence since we control pypi but have to wait on approval for brew [19:19] jcsackett: ack. thanks again! [19:19] bac: hatch or other platforms that use pypi (linux platforms) [19:20] true true ok thx bac [19:20] rick_h_ this is only under the OSX instructions [19:20] hatch: well, it does occur for the ubuntu instructions too [19:20] right [19:20] but not the brew/pip part [19:20] lgtm'd [19:21] hatch: i did turn off the tracking. but just in case i call all of my files github-sux.rst [19:21] LOL [19:26] thanks hatch [19:30] np [19:40] jujugui running to the post office and will pick up the boy on my way back. I'll be around some tonight if you need anything, but afk for a bit. [19:42] lazyPower: new ingest has completed, that hadoop charm still looks goofed. :/ [19:50] :| [19:57] jcsackett: well, i'm at a loss. should I unpromulgate it for now and pin it as a follow up? [19:58] my normal source of info is out today on swap. [20:12] Hello Juju GUI folks [20:12] afternoon arosales [20:12] hi [20:13] so everyone loves your quickstart :-) [20:13] and who wouldn't [20:13] :-) [20:13] thanks [20:13] but the only docs, I know of are, http://blog.mitechie.com/2014/03/17/juju-quickstart-and-the-power-of-bundles/ [20:13] ah, i knew there'd be a but [20:13] lol! [20:13] Is there some docs we could move into juju.ubuntu.com/docs [20:14] :-) [20:14] arosales it's definitely an issue that's been raised, if you wouldn't mind sending an email to the peeps mailing list rick can queue it up [20:14] he is out atm [20:14] hatch: will do [20:15] awesome thanks, I'd also love to see some docs in the juju docs [20:15] arosales: there is the readme but it is only a starting point: http://bazaar.launchpad.net/~juju-gui/juju-quickstart/trunk/view/head:/README.rst [20:15] hatch: do you prefer juju-gui-peeps or juj-gui? [20:16] probably peeps [20:16] lazyPower: i would unpromulgate it for now, and pin for follow up. [20:16] bac we should be able to translate the blog post and readme into a managable juju.u.c/ doc page [20:16] lazyPower: it seems like the actual store isn't updating--i'm unsure who to go to about that. [20:16] arosales: what happened to the docs jcastro wrote for juju.ubuntu.com/docs? [20:17] rick_h_: did he write docs? [20:17] arosales: originally he wrote the docs when we first released quickstart so we didn't add any [20:17] oh he's back :) [20:17] arosales: we had a card to do so but he landed some [20:17] :P [20:17] * rick_h_ clones docs [20:17] * arosales looking . . .. [20:19] if he did he didn't put link it to https://juju.ubuntu.com/docs/getting-started.html where it ideally should be [20:19] arosales: there is some mention on https://juju.ubuntu.com/docs/charms-bundles.html [20:19] castro! ;-) [20:19] hmm, https://juju.ubuntu.com/docs/charms-bundles.html#local-deploy-via-command-line is all I can find now but I swear he had large chunks of docs [20:19] I recall having the card to do the work and moving it to done because jcastro beat us to it [20:20] I think all jcastro did was the bundles deploy docs [20:20] :-( [20:20] arosales: ok, we'll add a card to flesh out some more. I know there were some references removed because quickstart didn't work on all OSs [20:20] arosales: but didn't realize how wiped it had been I guess [20:20] rick_h_: ok do you want to send a mail to the juju-gui or juju-gui-peeps list [20:21] I'll also put a card on our board for jcastro to sync with you on juju quickstart being on the getting started page. [20:21] arosales: I guess sure. We'll have the readme, but if you've got specific goals for docs at certain places please email or file a bug so we can make sure we address it properly [20:21] rick_h_: really needs a blend of http://blog.mitechie.com/2014/03/17/juju-quickstart-and-the-power-of-bundles/ and http://bazaar.launchpad.net/~juju-gui/juju-quickstart/trunk/view/head:/README.rst [20:22] examples, screen shots, user walkthrough [20:22] arosales: ok, but that seems like a dedicate page vs appending to the getting-started? [20:22] but the content is there given things haven't changed [20:23] rick_h_: well we should at mention, he if you want to use our tool to help you get stated hit [20:23] and make that prominent [20:23] s/he/hey/ [20:23] I wonder if we can talk jcastro into making getting started on windows a diff section, then linux/osx can be quickstart centric [20:23] arosales: ok, we'll see what we can come up with and iterate on it [20:24] we should also ask is quickstart the recommended way for users to actually get started on Juju [20:24] arosales: I know that's jcastro's vision but without osx/windows he backtracked [20:24] I would say yes, but perhaps folks also want manual steps, which we can provide, but we should be promoting quickstart [20:24] arosales: but sure thing, valid question. [20:24] right now we don't even mention it [20:24] rgr [20:24] rick_h_: I"ll put a card on the board [20:25] arosales: cool thanks for bringing it up. We can definitely do better [20:27] got a ping on "juju is apt-get for the cloud, but I still need help getting started." [20:27] * arosales thought of quick start which led me here [20:28] yea, that was kind of the goal of quickstart. simply the getting started part [20:28] * rick_h_ is following backlog conversation that led to this in #juju [21:13] jujugui looking for a review and qa on another code removal branch https://github.com/juju/juju-gui/pull/390 [21:13] hatch: looking [21:14] thanks [21:14] rick_h_ any preference on what I should jump on next [21:14] ? [21:16] hatch: looking [21:17] hatch: the charm details hidden by default? Last IL cleanup in maint [21:17] cool on it [21:18] hatch: hopefully nice and easy, then would love you and Makyo to ponder on the ghost stuff, ghost delete relation card, ghost config card [21:19] yeah that sounds good - has there been any discussion about the ecs stuff moving to core or was the pushed off to next cycle? We want to make sure the api's are at least somewhat compatible :) [21:19] yea, no ecs stuff this cycle [21:20] sounds good [21:28] kadams54: :P hey that cruft was important hard stuff :P [21:28] and ty hatch for removing the evils [21:28] rick_h_: no doubt, no doubt. But now it's just unused code :-( [21:29] Dusty bunnies of what had been. [21:29] kadams54: just givin you a hard time about calling my old stuff cruft :P [21:30] lol [21:30] now if we could just get design to quit changing their minds :P [22:59] Morning [23:07] morning huwshimi [23:07] hatch: Hey [23:20] hatch: If you get a chance would you mind casting an eye over https://github.com/juju/juju-gui/pull/385 to see if my changes are ok? [23:22] oh right - I think there was something that needed doing [23:22] one sec [23:26] huwshimi just a single comment - after looking at it again I saw what you were doing so just added a comment request [23:26] hatch: Thanks