[00:14] :-) === schwuk_away is now known as schwuk === anthonydillon is now known as antdillon [11:46] Hi guys, is there anyone online from the juju gui team? [11:51] antdillon: yep [11:52] rick_h, Hey, thanks. Just a quick question about the browse section of jujucharms.com [11:52] antdillon: sure thing [11:53] rick_h, Were linking directly to charms from the new juju.u.com website [11:53] antdillon: ok [11:53] rick_h, For example using this URL: https://jujucharms.com/precise/mongodb-15/ [11:53] rick_h, Is there a way to link that wont go out of date? [11:53] antdillon: yep, so for now it needs to be -HEAD vs -15 [11:54] antdillon: in the future we hope to be able to drop that, but it's not complete yet [11:54] rick_h, As in https://jujucharms.com/mongodb-15/ [11:54] antdillon: oh...ditch the precise...ugh no. We don't have anything for that and not sure it would work as most charms don't exist outside of precise atm [11:54] rick_h, Because we dont want to link them to percise when saucy is out [11:55] https://jujucharms.com/fullscreen/search/?series=raring&text= for instance is raring's charm list [11:56] antdillon: yea sorry, we'll have to deal with updates when we know we want to update them. I don't think you'll want saucy links when saucy is out [11:56] antdillon: you'll want to use https://jujucharms.com/precise/mongodb-HEAD [11:59] rick_h, Ok cool, I'll leave it with precise in the url [11:59] rick_h, Thanks for the help. Might be worth thinking about creating short links to the charms for sharing [12:00] antdillon: yep, it's a bit complicated since you need to match your juju environment version to the charm version and such [12:00] antdillon: but will bring it up on the call today and might be a good sprint topic in Oct [12:00] rick_h, https://jujucharms.com/precise/mongodb-HEAD/ the tweet link tweets to https://jujucharms.com/precise/mongodb-15/ [12:01] antdillon: yea, we should fix that. -HEAD is relatively new [12:01] rick_h, Cool thanks [12:08] hey antdillon. charms are per series, and generally in Juju we care about the LTS charms not the dev/6 mo. release charms. So what you raise is an interesting question but not pressing until we start thinking about T/14.04 [12:08] (the next LTS IIRC) [12:20] gary_poster, Cool I understand [12:20] cool [12:20] gary_poster, So should use -HEAD for all charms? [12:22] antdillon, yes, for now. [12:23] gary_poster: i'm here today [12:23] yay bac! 100%, or? [12:23] as in feeling 100% [12:24] no, but i'm faking it. :) [12:25] bac, heh, ok, take it easy [12:31] hey guys, what does the charm use to serve the pages? Apache? [12:31] marcoceppi, atm, yes. with bundle work upcoming, it will be a custom Tornado server [12:32] marcoceppi, btw, one of hatch or Makyo will join you guys in doc sprint when their day starts in a few hours [12:50] can someone tell me the commands in the CLI to import and export a bundle or charm to Juju? [12:51] gary_poster: rick_h ^ [12:51] luca__: I'm not sure I've not tried it out yet :/ [12:51] bac: or marcoceppi do you know? [12:51] rick_h: useless! :P [12:51] luca__, you use the juju deployer, not the CLI [12:51] luca__: as usual :) [12:52] I mean, that is the CLI, not juju itself :-) [12:52] luca__: there is no cli yet, though I'm trying to write a plugin for it [12:52] For exporting an environment [12:52] importing you use juju-deployer [12:52] marcoceppi, I thought Kapil was working on the exporter, or had one? [12:52] so if I want to import and export something now via the terminal, how do I do that? [12:53] gary_poster: maybe? we had jitsu export, but those aren't compatible IIRC [12:53] I want the commands for the juju.ubuntu.com website [12:53] marcoceppi, yeah I thought Kapil was adding it to deployer. maybe a good idea to sync up with him [12:53] gary_poster: ack, thanks [12:53] luca__, there is no export command at this time [12:53] gary_poster: right [12:53] gary_poster: ok [12:53] gary_poster: and is there a way to interrogate the charm store via the command line? like search for stuff? see a list of charms? [12:54] luca__: there's a set of tools called `charm-tools` that can search the store and list charms [12:54] luca__: oh oh, this one I do know :P [12:54] luca__: they're being rewritten to be executed as `juju charm search`, etc [12:54] marcoceppi: oh, heads up, api3 with bundle support is coming soon [12:54] marcoceppi: in case this is what's using the charmworld api [12:54] rick_h: I have no idea what that means, but is sounds awesome [12:55] luca__, for import...I think it is nasty: you have to get a certain branch (https://code.launchpad.net/~juju-deployers/juju-deployer/darwin) and then...I forget [12:55] I mean, nasty in comparison to "install package foo" [12:55] marcoceppi: how soon will that happen? [12:55] luca__: you can install charm-tools right now and use them as `charm search`, `charm list`, etc [12:55] guihelp: could anyone please review https://codereview.appspot.com/13424043 ? thanks! [12:56] marcoceppi: I linked you to http://bazaar.launchpad.net/~juju-jitsu/charmworld/trunk/view/head:/docs/api.rst so it means a nwe version of the api with bundles support is coming [12:56] luca__: it's got a lot of tools actually, ppa:juju/pkgs to install charm-tools [12:56] frankban: looking [12:56] rick_h: thank you [12:56] rick_h: ah, awesome! will v2 stay around for a while? [12:56] marcoceppi: yes, but won't get bundles so limited to old scope [12:56] rick_h: ack, thanks for the heads up [12:57] luca__, this is pertinent to your deployer import questions: https://docs.google.com/a/canonical.com/document/d/1i_sdbswSovHygc8URsh30zTBx_2G9VZBLlb3qbUmfCM/edit#heading=h.8dx2qatdl279 [12:58] luca__, prerequisites section and #1 of "Steps to be done in front of a live audience" [13:00] gary_poster: I see, thanks [13:03] morning [13:03] hatch: morning, want to chat when you get your morning cup of joe please [13:04] rick_h: prolly won't be for another 30 [13:04] hatch: np, just putting in first dibs since you stuck your head up :P [13:04] morning hatch. :-) You and/or Makyo are scheduled to join in doc sprint today. I'm loathe to lose either of you, but given constraint and inspector work, I'm inclined to ask Makyo to do it. That postpones his Go relation work. Is that ok? [13:07] bac: I'm documenting the 3.0 API. It looks like a 3-part bundle-id is always treated as owner/basket/bundle, never basket/revision/bundle. Do we consider this a bug? [13:07] gary_poster: yep that'll be fine, I would like to push to get the inspector unflagged [13:08] great hatch, thanks [13:08] bac: I think you worked on the view that renders /bundles/{basket}/{bundle}/json. Is that right? [13:08] frankban: thanks a ton for the QA/review I'll look into fixing that shortly [13:09] hatch: np [13:09] benji: yes [13:09] benji: abentley we have a view /json? [13:09] luca__: antdillon hey guys looks like the place in Heathrow that sells sims is in terminal 1 security and I land in 3, do you know of anywhere else close that I should go to pick up a sim card? [13:09] bac: I can't seem to see a view for /bundles/{basket}/{bundle} (no "json"), do you know if that exists? [13:10] rick_h: I didn't think so. [13:10] abentley: yea, that was the 'old' api stuff so same to dupe it over [13:11] hatch, Near terminal 3 or the office? [13:11] rick_h: "same to dupe it over"? [13:12] abentley: /same/shame to pull that convention over [13:12] rick_h: +1 [13:12] benji: no it has not been implemented as it was going to be part of the SEO work [13:12] antdillon: well I plan on going from the airport to the science and natural history museum (sunday) so i'd like to get it before then but close to the office would suffice as well and I can pick it up Monday [13:12] bac: ok, thanks for verifying [13:17] gary_poster: I am going to 1) test the charm-upgrade + set builtin-server story, 2) make fixes if required and then 3) merge juju-gui into charmers. is it ok? [13:17] frankban, yes, thank you! [13:18] abentley: i'm not sure about your question based on the URLs we listed in the google docs "spec". [13:25] bac: So, on API 3, there's a way to get a specific revision of an unpromulgated charm: owner/basket/revision/bundle. For a promulgated charm, basket/revision/bundle won't work. That seem asymmetrical, though perhaps the intent is that you use owner/basket/revision/bundle for that, too? [13:27] hatch, You should be able to walk into any phone shops in london and pick up a sim card. There are hundreds in london (like starbucks) [13:29] abentley: that is my recollection of the discussion. if we have a use case for the api to support unrevisioned access let's list it in the doc. [13:30] bac: We already have unrevisioned access. What we don't have is revisioned access with unspecified owner. [13:35] abentley: how would that work? revisioned access for a bundle with no specified owner? two different people could have a given (basket, bundle) at the same revision. which do we pick? [13:36] bac: We would pick the promulgated one, as we do for two-element bundle ids like "basket/bundle". [13:41] antdillon: ohh ok :) any certain network I should try and get on? [13:41] I'll likely be using primarily data [13:43] hatch, EE is good, I use them. You might be able to get 4G? [13:43] ahh cool [13:43] I think I am stuck on GSM because of the radios in my phone [13:43] they use a different 4g frequency here I think [13:43] hatch, Then you'll be flighting, 4G is faster then most wifi's [13:44] yeah that's the same here [13:44] hatch, Ah ok [13:44] I just don't want to spend $0.65/txt, $2/min, $15/MB :) [13:45] Of course, that's nuts! [13:46] I think I'll add everyone to my G+ and then use hangouts to communicate once I Have data [13:46] assuming others have data.... [13:53] rick_h: can i get you to look at https://codereview.appspot.com/13289046 ? [13:53] jcsackett: sure thing [13:54] rick_h: We were going to have "/download" for bundles so that deployer could use those urls directly. bac changed "/download" to "/json" for consistency with charms. [13:55] jcsackett, I didn't see you were back. how are you? [13:55] abentley: not following. What's /download for? [13:55] gary_poster: i'm alright. tho my typing speed is considerably slower. :-P [13:55] jcsackett, ack. glad you are on the mend. not sure if I want to hear exactly what happened or if I would faint. :-) [13:57] rick_h: $juju deployer -c http://manage.jujucharms.com/bundles/~owner/basket/revision/bundle [13:57] abentley: ah, interesting. I didn't realize that deployer was grabbing from charmworld vs the store like charms. [13:58] rick_h: We don't store bundles in the store at all. [13:58] abentley: ok, so ignore me if /json isn't part of matching the deprecated api [13:58] Found a weird bug in the GUI [13:58] abentley: hmm, so the deployer won't set the json request headers to send the response on headers vs url change? [13:58] marcoceppi: shoot man [13:59] rick_h: I still think it should be /download, not /json. [13:59] abentley: yea, I'd prefer that it send content-type in the request but oh well [14:00] rick_h: putting it in the URL rather than request headers makes it much easier for a user to control. [14:00] abentley: yea, understand. [14:01] rick_h: Also, we can provide a download link that way. [14:02] rick_h: yesterday I searched and visisted ~marcoceppi/precise/discourse, which took me to ~marcoceppi/precise/discourse-20. So I went to -HEAD because I wanted to refresh it after I updated the charm in the store and watch the magic. Now when I search the URL it takes me to is -21 but the content is still -20 (as well as -HEAD) it's like there's some severe cache or something [14:02] rick_h: does https://jujucharms.com/~marcoceppi/precise/discourse-21/ show location as -20 ? [14:02] marcoceppi: yea, looking [14:03] marcoceppi: and shows head as r64? [14:03] marcoceppi: maybe ingest error on changes? [14:03] rick_h: ready when you are [14:03] marcoceppi: run proof? [14:04] hatch: I'm good I think. [14:04] rick_h: just shows a W about hook not executable [14:04] rick_h: ok in guichat [14:04] rick_h: the change was purely hook based, nothing in metadata changed [14:04] but the serach results show the right version (commits and downloads) [14:04] and takes me to -21 [14:04] marcoceppi: will have to look into staging to see if there's an import error [14:04] rick_h: ack, gotchya [14:05] marcoceppi: I'm all confused, the branch is r64, the rev in the file is 17 [14:05] marcoceppi: so not sure where the 20/21 is even coming from tbh [14:05] rick_h: that's charm-store version [14:06] rick_h: which is independent of bzr version and local revision file [14:06] * marcoceppi holds back on this [14:06] marcoceppi: k, will check in a sec. [14:07] bac: When a 3-element bundle-id is specified, it looks like we treat the three elements as owner, basket, bundle, but then we return only promulgated bundles. Is this a bug? [14:08] abentley: could have a look here: https://code.launchpad.net/~adeuring/charmworld/spurious-failures-2/+merge/183183 (a bit longer than the core 5 lines I expected yesterday, but not terribly long either...) [14:09] adeuring: sure. [14:13] adeuring: r=me. Thanks. [14:14] thanks [14:15] perhaps it is abentley. please file a bug or make a note in the doc if you wouuld. [14:26] bac: I've filed bug #1218949 [14:26] <_mup_> Bug #1218949: Cannot retrieve head revision of an un-promulgated bundle over API 3. [14:26] thanks abentley [14:35] jcsackett: inboud [14:37] marcoceppi: cool yea seeing the store sees https://store.juju.ubuntu.com/charm-info?charms=cs:~marcoceppi/precise/discourse 21 [14:38] bac: gary_poster there's a config conflict in comingsoon it looks like? [14:38] http://comingsoon.jujucharms.com/juju-ui/assets/config.js [14:38] rick_h: i'll look [14:38] than kyou [14:38] thanks bac [14:40] ok now where was I [14:44] abentley: have a sec to give me a hand searching this issue for marcoceppi? [14:44] rick_h: sure. [14:45] abentley: guichat? [14:45] rick_h: yup. [14:46] rick_h: try now [14:47] Hey Makyo, I want to reply to rogpeppe's email in which he asked me what the ordering change was that broke the GUI. IIRC, new relations were being sent before services? That doesn't sound right unless the deployer was involved. any quick details I can pass on? [14:48] gary_poster, units before services; when we were receiving units after services, the delta triggered adding the unit to a ModelList attached to the service. If it was before, the service didn't exist. The solution was sorting the deltas [14:48] cool thanks Makyo, will pass on [14:51] marcoceppi: so working on it still, it's fine on staging http://staging.jujucharms.com/api/2/charm/~marcoceppi/precise/discourse-21 and the proof errors listing in production appears to only do reviewed charms so filed #1218966, [14:51] <_mup_> Bug #1218966: proof errors appear to only display for revewied charms [14:52] marcoceppi: have to go to IS now and have them help get at the logs on production to see what error is thrown. Note that, on production, it stopped at r60, so r61 probably introduced something it didn't like. https://manage.jujucharms.com/api/2/charm/~marcoceppi/precise/discourse-21 [14:52] rick_h: thanks, I wanted to blog/share that link eventually, so I appreciate you looking in to it [14:52] gary_poster: charmers' charm is up to date [14:53] awesome, frankban thanks. Do you want to send out an announcement/request for testing, or do you want me to? [14:53] * marcoceppi looks at rev 60 [14:53] * marcoceppi 61* [14:54] gary_poster: please do it, thanks! for the jujucharms.com upgrade i'd wait till Monday [14:54] ack frankban, completely agree :-) [14:54] gary_poster: the upgrade being: 1) upgrade-charm and 2) set builtin-server=true [14:54] cool [14:55] frankban: gary_poster does the constraints issue that hatch is working on effect release though? e.g. will users end up not beign able to deploy? [14:55] rick_h, no. frankban made a charm release not a gui release [14:55] with the new inspector [14:55] gary_poster: k, ignore me then. [14:55] :-) np [14:56] marcoceppi: heads up that I do see these errors http://paste.mitechie.com/show/1012/ not sure if those are outdated or what. [14:56] my laptop has been acting up today.......plz don't break plz don't break plz don't break [14:56] rick_h: redmine and charm-helper are dead and gone, not sure why it's pulling those [14:57] gary_poster: FWIW, we can know from the outside if a GUI is run by the Tornado server visiting the /gui-server-info URL (without the trailing slash) [14:57] ah cool frankban good to know, ty [14:59] rick_h: thanks for the review. good catch on the needed cleanup. [15:01] * benji wonders if the call time has changed. [15:04] jujugui - guichat 4 mins ago! [15:05] hatch, calendar says 9:30? [15:05] for real??? [15:05] jujugui postponed 30 minutes [15:05] lol [15:05] oops we all missed that [15:11] bac or benji: could you please review https://code.launchpad.net/~abentley/charmworld/api3-docs/+merge/183206 ? [15:12] abentley: I'll take a look [15:13] benji: Thanks. [15:20] jujugui call in 10 kanban now. [15:22] abentley: why is bundles/bundleid plural? [15:22] rick_h: I don't know. I didn't implement it. [15:22] abentley: ok [15:23] abentley: r=me [15:25] rick_h: Thanks, but benji was looking at that. [15:25] abentley: ok [15:25] abentley: well, you can have two, figured I'd peek at since I'll be looking shortly [15:25] rick_h: Cool. [15:25] abentley / rick_h: well if we have one, that is enough [15:26] I did enjoy the ASCII art table, though. [15:26] benji: abentley bac is there any opposition to dropping the s on bundles/bundleid for consistency ? [15:26] benji: Yay for ASCII art in ReST. [15:26] rick_h: I am in favour of dropping the s. [15:28] abentley: if you /really/ like reST tables, have I got something for you: http://pythonhosted.org/manuel/table-example.html#fit-table-example [15:30] (and that document which shows how to write tests to test documents, itself includes tests to show that the document is correct) [15:30] jujugui call now [15:30] rick_h: i am not opposed. [15:31] bac: yay! [15:31] jcsackett, ping for call if you can come [15:46] bac: can you drive by that on your current work or should I create a seperate branch? [15:49] rick_h: i'll do it as a follow-on. i'll make a card [16:32] abentley: filed a bug based ont he log from prod. https://bugs.launchpad.net/charmworld/+bug/1219001 [16:32] <_mup_> Bug #1219001: production error on several charms "KeyError: 'branch_deleted'" [16:32] abentley: looks like a bunch of charms are hitting this keyerror and don't get ingested [16:32] jujugui ok well if anyone wants to mee up sunday during the day or for supper/after pm me your cell # [16:32] rick_h: saw. Huh. [16:33] hatch, I'll probably email you in that case. won't have data [16:33] if you miss it np [16:34] gary_poster: sure thing - my plan is to head from the airport to get a sim then to the science/history museum [16:34] ok cool [16:34] texts cost me $0.65 so I want to get that new sim asap :) [16:35] gary_poster: I've found a charm bug in the wss url handling when a real pyjuju env is used. Will self review, land, and include in charmers ASAP: https://codereview.appspot.com/13432043 [16:35] rick_h: I don't understand how we get that far without setting branch_deleted. [16:35] thank you frankban [16:35] frankban: so in moving the constraints stuff into the env/store/python.js deploy method that fixes rapi and go sandbox but breaks python sandbox :/ [16:36] so not sure what's up with that....sandbox must be broken === TheRealMue is now known as TheMue [16:36] hatch: ISTM that the python sandbox still expects to be able to call deploy passing an array of constraints [16:36] hatch: maybe? [16:36] rick_h: That data should already be set when charms are enqueued. [16:37] abentley: k, did you want the log file? [16:37] frankban: so I put the formatting in the deploy method in python.js so it's breaking somewhere after the rpc call [16:37] rick_h: Yes, please. [16:37] abentley: it's 30M compressed so didn't send/attachj it [16:38] so must be fakebackend.js is broken then? [16:38] abentley: uploading, will take a sec [16:40] hatch: and sandbox receives the rpc call right? [16:44] frankban: I can never remember the sequence of events, putting in breakpoints now heh [16:44] marcoceppi: got the logs off production there's a bug for it to follow #1219001. Sorry for the issue [16:44] <_mup_> Bug #1219001: production error on several charms "KeyError: 'branch_deleted'" [16:54] frankban: found the problem, it's in the Service model [16:54] gary_poster: charmers updated [16:54] hatch: interesting [16:56] rick_h: I don't see any KeyError on branch_deleted since June 13. I don't think it can be the cause of this issue. [16:57] abentley: oh, crap I went to the end of the file and searched backwards for discourse and didn't read the timestamp :/ [16:58] * Makyo runs to go get the phone unlocked for real. [16:58] abentley: oh...then my bad, let me invalid that bug and go back. [16:58] hatch: constraintsStr getter? [16:58] rick_h: oh, branch_deleted ? [16:59] marcoceppi: ignore me, I found an error in the log from a month ago..back to researching [17:00] frankban: yeah - I don't see any other place to modify the constraints data [17:01] whoa, just lost power...on laptop battery atm. [17:01] hatch: good luck, and have a nice weekend! [17:01] note to self, put desktop on UPS [17:01] frankban: could change it back in the fakebackend [17:01] frankban: you too! see you Monday/Tuesday [17:08] yay power is back [17:08] I don't know anyone else with an off brand phone with a micro sim hah, guess I'll just have to buy the unlock code and hope it works once I get there :) [17:12] abentley: so I don't see anything in the log. I do notice that discourse r64 is listed in the http://manage.jujucharms.com/recently-changed view [17:12] abentley: so now wondering if there's a mongo vs ES issue? is recently changed pulled straight from mongo while the charm data is pulled from ES? or not true? [17:24] oh sweet check out the new relation lines on the GUI http://www.ubuntu.com/cloud (scroll down) [17:37] heh cool [17:38] * hatch wonders who's repo that's in lol [17:38] I actually think they look pretty cool [17:39] of course they are missing the labels but the green adds some nice color [17:39] it could even indicate relation status (if there is such a thing) [17:40] rick_h: so documentation to get the lxc and go stuff up and running? [17:41] unless you just want to QA this branch for me and we can do that later [17:41] (would be my preference :) ) [17:48] hatch: :P I can QA [17:48] hatch: http://marcoceppi.com/2013/07/compiling-juju-and-the-local-provider/ is what I went with [17:48] well, some of that, not all needed [17:48] environments is a 2-liner change and juju switch ftw [17:49] rick_h: ok just linting and making sure the tests pass then I'll repropose [17:49] thanks [17:49] hatch: rgr [17:49] I just really want to get this landed instead of potentially fighting getting the system up and running [17:49] hatch: I recommend just using juju-core from ppa:juju/devel, the local provider afterwards is pretty easy [17:50] marcoceppi: so instead of compiling from source [17:50] hatch: yea, don't compile [17:50] I didn't do that part [17:50] ok cool - I'll keep notes of what I do then and write another blog post about it [17:50] just ppa and then walked through the rest for environment/starting up [17:50] can't hurt right? :) [17:50] hatch: +1 [17:50] hatch: Yeah, that was me being lazy and killing two birds with one blog post [17:51] lazy lazy [17:51] hey are you still in Japan? [17:52] I just realized it's probably 2am there if you are :D [17:53] abentley: guess not, both _find_charm and series_charm_changes are on mongo [17:56] rick_h: https://codereview.appspot.com/13252045/ this fixes the bug but not frankbanks request to normalize the config formatting [17:56] that's coming soon, just wanted to get that bug qa'd first [17:57] hatch: ok, so I'm doing the -core qa section? [17:57] yes plz [17:57] rick_h: wouldn't hurt to do the others too, it's pretty quick [17:57] hatch: ok, starting up [18:00] thanks [18:05] rick_h: did you QA my branch, or do i need to hunt down QA? [18:06] jcsackett: sorry, did not QA. I can shortly [18:12] rick_h: It looks like something is wrong with the way we find the head revision in mongo. I don't know whether it's a bug in the data or a bug in the code. Elasticsearch does recognize that 21 is the head revision. [18:12] rick_h: I thought recently-changed was all-mongo. === schwuk is now known as schwuk_away [18:12] abentley: yea, I think it is. Both seem all mongo. [18:13] abentley: sorry, back/forth in qa'ing/etc. [18:13] abentley: so the api uses sort=[('store_data.revision', pymongo.DESCENDING)]) [18:13] abentley: and the charm_changes don't specify a sort :/ [18:14] rick_h: This uses elasticsearch: https://manage.jujucharms.com/api/3/search?series=precise&owner=marcoceppi&name=discourse [18:14] rick_h: cool, thanks. [18:14] abentley: right, but https://manage.jujucharms.com/api/2/charm/~marcoceppi/precise/discourse-21 is what I was looking at pulling old data [18:14] abentley: that's using charm/_find_charm right? [18:15] abentley: we were looking at why https://manage.jujucharms.com/api/2/charm/~marcoceppi/precise/discourse-HEAD returns rev 60 in the changelog and links to disource-20 [18:16] rick_h: Right, it's using _find_charm. [18:18] So, when does this UI show up? http://www.ubuntu.com/cloud [18:19] rick_h: And I'm saying I don't know whether it's a bug in the code or the data, but Elasticsearch looks right. So it's less likely to be a bug in the data. [18:19] abentley: right, gotcha [18:19] rick_h: Because we update them in sync. [18:19] abentley: I figured since the recent changed had the data it was maybe how the query/data was looked at [18:20] rick_h: Haven't had a chance to look at that implementation yet.... [18:20] hatch: I can't deploy anything. I get the error "Could not deploy the requested service." with/without constraints [18:20] what's the error in the console? [18:20] abentley: can I hand this off to you then? I've got to qa hatch and jcsackett's stuff atm and you're closer to the action [18:20] hatch: none :/ [18:21] guichat? [18:21] hatch: sure [18:21] rick_h: okay. [18:21] hatch: if it'll load for me [18:22] hatch: invite me in please [18:23] ok sec [18:47] jujuhelp how would I get debug js files in a charm deployed jujugui? [18:47] hey rick_h [18:47] do you have sinzui-like powers for the store? [18:48] rick_h, look in charm options. looking for you... [18:48] actually, I mean abentley [18:48] jcastro: how so? [18:48] gary_poster: yea, don't see any 'debug' charm options [18:48] so we renamed the rack charm to "rails" [18:48] https://jujucharms.com/fullscreen/search/precise/rails-1/?series=precise&text=rails&type=approved [18:48] but this is not showing the proper charm [18:48] mims said something like "they need to flush" [18:49] rick_h, :-( you are right. I think t must be conflated.looking [18:49] jcastro: I don't think he has special powers. I think he has to hand-craft urls, but I can do that, too. [18:49] awesome [18:49] gary_poster: i've tried logging into the service and running make devel, but then it can't talk to the back end [18:49] jcastro: You know that the store doesn't have a concept of rename, right? [18:50] gary_poster: I tried to set the back end to go, no sandbox, and I just get ws errors [18:50] abentley: hah, nice. [18:50] gary_poster: I assume I'm missing whatever listens on the ws end for go [18:51] abentley: hi [18:51] abentley: so we just need to get any cache related to lp:charms/rails and lp:charms/rack regenerated [18:51] rick_h, I'm guessing source mapping is insufficient [18:51] m_3: Why do you say that? [18:52] abentley: so we removed lp:charms/rack [18:52] rick_h, staging turns on debug mode :-( [18:52] abentley: and pushed an --overwrite to lp:charms/rails [18:52] we should have a separate flagfor that [18:52] gary_poster: yea, ok cool [18:53] abentley: the overwrite was from a lp:~charmers/charms/precise/rack/trunk branch [18:53] abentley: and there is no longer a ~charmers owned "rack" branch [18:53] so flushing those from the cache and re-injesting lp:charms/rails should handle the changes we need [18:54] m_3: There is nothing that would make the "rack" charm disappear. The charm store deliberately never deletes anything, regardless of whether you delete the branch. [18:54] abentley: ok, that's secondary to getting it to recognize the overwrite of lp:charms/rails [18:56] abentley: note that the previous version of lp:charms/rails had bzr revno of like 44... the new one has like bzr revno of 11 or 12 [18:57] m_3: Are you talking about the charm store or the charm browser? [18:58] abentley: both ideally... I haven't tested if the store is seeing the latest... only the browser [18:58] * m_3 testing store now [19:05] gary_poster: ping, can you join guichat? [19:06] rick_h, yes, 60 sec === schwuk_away is now known as schwuk [19:14] m_3: This looks related to the issue marcoceppi was having; If you search, you find precise/rails-1, but when you try to look up precise/rails-1, you get precise/rails-0. [19:15] m_3: I think it is unlikely that clearing squid is going to change that. [19:17] abentley: bummer [19:17]