[00:02:13] madhuvishy: funny for dec totals check out with november, but distribution of Offset+underestimate is very different [00:22:04] nuria_: I think the original query was slightly off and joal fixed some stuff [00:23:20] madhuvishy: k, let's talk about it tomorrow, were both quqries off (uniques) and offset? or only teh offset one? [00:23:22] *the [00:24:20] nuria_: I think offset one [00:24:30] that [00:24:34] is the one i know [00:25:44] madhuvishy: man .. then i do not see how totals could be about same than in november.....ah wait [00:27:43] nuria_: I had a comment on your patch. -1-ed so we dont merge it [00:27:54] madhuvishy: good, will look [00:28:00] awesome [01:13:37] (CR) Bearloga: "Fixes coming in the next patchset." (9 comments) [analytics/refinery/source] - https://gerrit.wikimedia.org/r/254461 (https://phabricator.wikimedia.org/T118218) (owner: Bearloga) [02:00:22] milimetric: code pushed to gerrit for RB [10:52:21] (PS1) Joal: [WIP] Correct AppSession Metrics job [analytics/refinery/source] - https://gerrit.wikimedia.org/r/268639 [12:01:32] (PS2) Joal: Update AppSession Metrics (typing and sorting) [analytics/refinery/source] - https://gerrit.wikimedia.org/r/268639 (https://phabricator.wikimedia.org/T125960) [12:05:42] (PS1) Joal: Bump mobile app session metrics driver mem to 4G [analytics/refinery] - https://gerrit.wikimedia.org/r/268649 (https://phabricator.wikimedia.org/T125960) [12:41:38] !log Restart Mobile App sesion metric with manual upgrade of Spark driver memory through oozie config [13:06:28] hi, I'm looking for a hive query that would me allow me to select a random value in a group [13:06:41] Hi dcausse [13:06:51] I'm not sure I understand, ;et me rephrase [13:06:58] I tried RANK() over (PARTITION by csr.ip ORDER BY rand()) [13:07:23] You have a column in hive, and you'd like to get a random value among the ones present in the column ? [13:07:57] I group by ip, but I want to take only query by ip [13:08:04] *I group by ip, but I want to take only one query by ip [13:08:27] ok, and you'd like this query to be a random one [13:08:37] yes that would be perfect [13:08:45] instead of the first [13:08:49] hm [13:08:54] yes ideally [13:09:30] the rank() *seems* to work but if I remove ORDER by rand() I see duplicates ip so I'm not sure it really works [13:09:36] I think the idea of using OVER PARTITION is good [13:12:19] But you need to use FIRST_VALUE instead of RANK [13:12:35] ah [13:13:01] well I wrap the query in a FROM ( ... ) WHERE rank = 1 [13:13:11] Yeah, that should do though [13:13:22] but first_value sounds more appropriate [13:14:53] dcausse: Let me know if it does the trick :) [13:15:03] joal: sure, thanks! :) [13:19:30] hmm: FAILED: NullPointerException null [13:19:54] dcausse: do you mind sharing the query on gist or something ? [13:20:19] joal: https://phabricator.wikimedia.org/P2572 [13:20:33] * joal reads [13:21:37] joal: my bad forgot to cleanup something, it's running now [13:23:22] joal: I updated the paste, I see results. I'll try to wrap it inside a count(*) or distinct to see if it actually works [13:27:32] no I have duplicated ips :/ [13:27:41] Yes, I'm sure you have :) [13:29:00] Give me a minute, trying somethin [13:29:06] sure [13:34:27] dcausse: Commented on your paste: https://phabricator.wikimedia.org/P2572 [13:34:38] joal: looking [13:36:53] joal: awesome thanks! [13:37:05] np dcausse :) [13:37:14] analytics SQL is tricky ! [13:37:31] indeed! [14:43:58] *waves at the A-Team* [14:44:25] o/ [14:44:37] So, I'm looking at puppetizing some of the crons I currently have running on my user on stat1002. mainly the running of scripts stored in https://github.com/wikimedia/analytics-limn-wikidata-data [14:45:20] I guess doing what I am doing now but just having it in puppet on the same machine would be fine? [14:46:13] I guess otto would be the best person to talk to this about? [14:48:49] addshore: definitely, but having those scripts in puppet and adding them to the stat1002's config shouldn't be a problem [14:49:07] might be a new role added to the host [14:49:17] not sure if it would be too much though [14:49:25] elukey: awesome [14:49:40] but.. let's ask to ottomata first :D [14:49:54] okay! [14:50:35] The biggest question I have is would it be okay to have the scripts pulled in from that gerrit repo so that I can still update them as I normally would [14:50:56] I understand access to that gerrit repo would likely have to be restricted to people that also have access to the analytics cluster [14:51:02] I'll wait for otto ;) [14:51:18] but yeh, it would be great to move this away from just a pile of scripts in my user cron :D [14:51:34] Especially when they make such lovely looking things https://grafana.wikimedia.org/dashboard/db/wikidata ;) [14:52:59] morniiing [14:56:08] addshore: for the crons we could add a class to the analytics role (maybe?) but I am not sure about where to put the scripts. It might be totally unrelated [14:56:51] elukey: indeed, could probably just add them to the analytics role, though a feel a little bit of seperation might be wise :) [14:57:14] yep definitely [14:59:51] ottomata: mind if I send you a pastebin of what I said just before you arrived? :) [15:00:25] sure [15:00:32] https://www.irccloud.com/pastebin/rQxP186C/ [15:02:53] addshore: do these crons push to git, or is the repo just pulled so the code can run? [15:03:12] Just pulled so it can run [15:06:25] Some use hive, some use the mysql replica, some make some internal api calls and some make some external api calls, then sending numbers to graphite [15:06:46] A mixture of bash and php currently [15:07:05] aye ok, how often do you make changes to it? [15:07:28] In theory not very often [15:07:39] hm k [15:07:50] but it would be great to be able to make changes as freely as I currently can (without using puppet that is) [15:08:00] rather than making a change and having to wait for ops ;) [15:08:30] ja that would be fine, so you might want to use git-deploy AKA trebuchet to deploy your repo from deployment.eqiad.wmnet [15:08:32] https://wikitech.wikimedia.org/wiki/Trebuchet [15:08:38] (or scap3 if you want to be new and fancy) [15:08:44] actually, you might want to start with scap3 [15:08:56] https://doc.wikimedia.org/mw-tools-scap/index.html [15:09:12] they can help you a lot witih that over in #wikimedia-releng [15:09:27] that'll allow you to do deployments of your repo in gerrit to stat1002 (or wherever) [15:09:40] once there [15:09:41] hmmmm [15:09:48] you want crons puppetized, ehHhhh/ [15:09:49] :) [15:09:57] yeh ;) [15:10:21] ottomata: what about a new role and/or a special class in analytics for these kind of things? [15:10:23] you want them puppetized just so that they are not lost if the server dies or moves, and so someone else in the future can maintain them? [15:10:33] ottomata: indeed [15:10:39] yeah, elukey if we do puppetize this stuff, then a new role or module would make sense [15:11:03] My idea was have the gerrit repo with the scripts in which basicaly only I can merge into, that be cloned and pulled by puppet [15:11:07] and then the crons also in puppet [15:11:36] ja, the clone is possible [15:11:44] But yeh, I have no idea if there is a better / prefered solution! [15:11:50] deployment is a little more normal, but a git clone is fine i think [15:12:12] I imagine with the clone and pull though you will want the gerrit repo to be rather locked down? [15:12:35] addshore: do you know what wikidatabuilder is? [15:12:38] its a puppet module [15:12:42] yeh! I wrote it ;) [15:12:54] well, I wrote the original version ;) [15:13:15] Hence why I have this idea in my head :D [15:13:45] But that only runs on labs! [15:14:05] ah [15:14:16] addshore: what is it compared to what you are trying to do now? [15:14:23] would it make sense to have a single wikidata module [15:14:26] that these are both grouped in? [15:15:36] well, these need to run on production, the reason the other one is labs was because of github and composer [15:16:07] some of the scripts in this new thing actually dont have anything to do with wikidata ;) It's more of a general WMDE-metric thing [15:16:30] the current gerrit repo name is misleading in literally every way! [15:16:58] hehe, ja, can/should you change that :) ? i appreciate the caveat in the readme [15:17:35] yeh, it should probably be moved before anything with puppet happens [15:17:49] either the WMDE stuff and the wikibase stuff should be split out, or it should just be some wmde-analytics thing [15:17:57] the question is where exactly in gerrit to put it [15:18:23] I guess analytics/wmde would do? [15:18:26] there is a wikidata root [15:18:28] project [15:18:41] but its not just wikidata ;) [15:18:57] wmde root woudl be fine, i supose? [15:19:06] perhaps! [15:19:43] aude, jzerebecki, has a wmde root repo ever been discussed before on gerrit? [15:21:19] addshore: what is a root repo? [15:21:40] https://gerrit.wikimedia.org/r/#/admin/projects/wikidata [15:28:21] well, ottomata I'll look at fixing the location of the repo and then draft a module for you to review (or something) :) [15:28:43] addshore: no we never discussed something like that, but go for it if it makes sense [15:29:18] addshore: aye, i thikn a wmde project root and a module for your thing make sense [15:29:23] not sure about module name [15:29:27] maybe just wmde, but maybe not :/ [15:29:28] :) [15:29:39] wmde/analytics ;) [15:29:41] haha [15:29:50] sure! :) [15:29:59] although, you might bite yourself later with something so generic [15:30:06] is all wmde analytics going to go in tihs repo [15:30:06] ? [15:30:24] I could split it into wmde/analytics/wikidata and wmde/analytics/wishlist [15:30:26] ir something [15:30:29] *or [15:30:48] that would be a logical split [15:32:21] oh, there is also a jar file it needs :P I guess that will have to be in another repe (that scans dumps) [15:32:22] *repo [15:33:13] there is already an analytics/ root repo in gerrit [15:33:27] maybe analytics/wmde/wikidata [15:33:39] yep, thats also an option [15:33:58] the question is would wmde have more repos to expand into this with time [15:35:54] ottomata: https://gerrit.wikimedia.org/r/#/c/268682 is a first attempt for a new Burrow lag email.. the template is basically the same but with a "Format" line [15:36:06] the next step would be to change it with info that we need [15:36:20] or maybe with a better format [15:37:45] let me know if makes any sense [15:37:47] :) [15:39:36] elukey: mostly looks good [15:39:50] if default-email.tmpl doesn't exist in puppet though (i don't see it) [15:39:57] this module will not be usable with the default you've given [15:40:03] also, i'd avoid putting 'analytics' in the module [15:40:12] the module is standalone now, and should be usable in any context [15:40:38] the parameterization of $email_template is good though [15:40:50] elukey: what is different about this email template vs the default? [15:41:41] so default-email.tmpl is shipped with burrow and was hardcoded in the erb template, this is why I put it as default [15:41:56] harcoded where? [15:41:57] the analytics template has, for now, only the "Format" line [15:42:16] burrow.cfg.erb [15:42:19] ah [15:42:20] yeah ok [15:42:32] so, probably you should add the default-email.tmpl to puppet [15:42:34] in the module [15:42:39] so everything works with the module as is [15:42:46] in the X days/month we might want to add more info, so there will be a handy file [15:42:46] and then, you can do one of 2 options: [15:43:11] 1. if this template is really analytics specific, move it out of the burrow module (maybe just in templates/analytics) for now [15:43:21] hmmm [15:43:22] actually [15:44:02] hmm, yeah ok that is fine [15:44:03] yeah [15:44:06] so either that [15:44:06] or [15:44:32] 2. name this template something else that is not use specific, and keep it in the module as another optional template [15:44:42] does that make sense? [15:45:13] yep sure, I would go for 2. [15:45:42] k cool [15:45:56] the default template though it is shipped with Burrow [15:45:59] its ok [15:46:01] you can add it to puppet too [15:46:03] IF [15:46:05] okok [15:46:06] you want it to be the default [15:46:17] if you really want this puppet module to override the default shipped with burrow [15:46:26] then you can use yours (with a different name) and just keep it in the module [15:46:34] as the defeault value of $email_template [15:47:02] it would make sense, and it is the way that we use now [16:17:26] ahhh make sense! [16:18:26] so probably [16:18:31] you should make the path always be [16:18:37] /etc/burrow/email.tmpl [16:18:38] or osmething [16:18:47] and param the puppet template path [16:18:59] that way users of the module can make custom templates without editing the module [16:19:33] that was exactly what I was trying to do, but I missed it :D [16:20:18] I wanted to ask the user to set $email_template [16:20:26] like something-something.tmpl [16:20:38] hey ottomata you wanna help me merge the config change and deploy restbase? [16:20:40] https://gerrit.wikimedia.org/r/#/c/268560/ [16:20:41] and then use the variable in /etc/burrow/tc.. [16:21:06] yeah you don't need to use the variable in burrow.cfg though, ja [16:21:11] your path will always be the same on the server [16:21:24] you'll just render different content for that file based on what the user gives in puppet [16:21:44] milimetric: , uh yes! but i just merged a patch to restart kafka1012 broker [16:21:50] let me make sure it is not going to explode first [16:21:56] no worries, or rush [16:22:06] I was out for the morning but I'm around now [16:33:31] hehe, almost elukey [16:33:35] the path has to be [16:33:42] 'burrow/lag-alert-email.tmpl' [16:33:53] since the file is in the burrow module's template/ dir [16:34:00] aaahahhhhhhhhhhhhhhhhhhhhhhhhh you areeeee rigghhtttttttttttttttttt [16:34:08] iiiiii aaaammmm tiiirrreeeedddd [16:34:10] oh [16:34:10] :D [16:34:16] elukey: why not just call the file email.tmpl [16:34:16] ? [16:34:32] why lag-alert-email.tmpl? [16:34:54] good point [16:36:11] oook milimetric we can do your thing [16:36:15] is it easy? [16:36:19] will things explode? [16:36:24] should we wait til after standup? [16:38:09] (CR) Ottomata: [C: 2 V: 2] Bump mobile app session metrics driver mem to 4G [analytics/refinery] - https://gerrit.wikimedia.org/r/268649 (https://phabricator.wikimedia.org/T125960) (owner: Joal) [16:39:41] haha [16:39:42] elukey: [16:39:48] $email_template = 'burrow/email.tmpl', [16:39:50] is what you want [16:39:56] it's not easy, things will not explode though [16:40:00] otherwise folks custom files won't work [16:40:05] we had to refactor the configuration in puppet [16:40:17] so we have to deploy the code change, and then apply the puppet config change [16:40:26] but if we do it one machine at a time [16:40:35] we can test and make sure it goes ok without hurting anyone [16:40:41] we can do it after standup - it might take a while [16:40:51] ottomata, I wanted user to put only the name of the template rather than the path, but I'll amend it [16:40:54] yeah, let's do that, i want to go home right after standup, then we can do [16:41:01] elukey: they will ahve to [16:41:07] because they won't be adding custom templates to the burrow module [16:41:16] you are trying to separate concerns here [16:41:31] say services decides to want to have a special email template for their change propogation uses of kafka [16:41:46] they will commit a change-prop-email.tmpl of their own [16:41:51] probably to some services based role [16:41:56] or modoule [16:42:02] maybe [16:42:12] $email_template = 'burrow/email.tmpl', [16:42:15] modules/role/templates/services/change/burrow-email.tmpl [16:42:18] yes elukey [16:42:18] then [16:42:21] when they set up burrow [16:42:23] and content => template($email_template), [16:42:25] they'd do [16:42:33] yes [16:42:35] yep I got it, sorry [16:42:58] they'd do class { 'burrow': ... email_template => 'role/services/change/burrow-email.tmpl' ... } [16:43:02] without having to modify the burrow module at all [16:47:51] kafka1012 is up \o/ [16:52:18] patch looks good elukey! [16:52:35] I am terribly sorry for sending it 100 times :( [16:53:07] hehe, no prob :) [16:53:16] ja 1012 back up, still catching up with webrequest topics [16:53:17] thanks for the reviews, really appreciated :) [16:53:19] gonna take a while ai think [16:53:20] ja! [16:53:55] madhuvishy: let's talk about https://gerrit.wikimedia.org/r/#/c/268682/9 after the standup if you want! [16:54:23] I changed a bit the email format but there is a loooot to improve [17:00:43] a-team: stabddduppp [17:03:15] Analytics-Kanban: Eventlogging should start with one bad kafka broker, retest that is the case - https://phabricator.wikimedia.org/T125228#2002587 (madhuvishy) Tested this on labs - EL works fine if brokers go down by killing kafka in any of the brokers. The consumers fail though, if you kill it in other ways... [17:15:30] ottomata1: it looks like we are not giving the email template any variables from the puppet classes - would it be better to have in files than templates? cc: elukey [17:18:51] maybe! i thought that too, but perhaps we will [17:19:06] ottomata1: yeah - it's not really erb either [17:19:11] madhuvishy: actually, the real real real proper thing to do would make email_template_source and/or email_template_content params [17:19:17] so that you coul duse either [17:19:18] like [17:19:23] email_template_content => template('...') [17:19:26] or [17:19:36] email_template_source => ('puppet:///...') [17:19:42] but, i don't care that much at this stage :) [17:19:48] we can make that better later if we want to [17:20:04] ottomata1: hmmm - well at this point it seems to me like it belongs in files/ but you know better :) [17:20:13] it technically does [17:20:17] but i don't really care [17:20:22] ha ha [17:20:23] someone could [17:20:29] ok i'll comment :P [17:20:30] potentially pass a path to an erb template [17:20:32] and use some variable [17:22:31] yeah - and at that point it could become a template? i'm not sure about provisions for the future. [17:24:58] madhuvishy, ottomata1: let me know how you guys want to proceed, not that urgent. I don't mind modifying the CR a bit more do be more generic [17:25:31] at the same time though it would be great to commit something in the next days so we should choose the end result :) [17:26:50] hey analyticians, we now have separate metrics for WMF networks vs. the rest of the world, and it seems that pageviews is primarily accesses from our networks (labs): https://grafana.wikimedia.org/dashboard/db/pageviews [17:27:20] *accessed [17:27:50] (CR) Nuria: [C: 2 V: 2] Implement a Tabular Layout [analytics/dashiki] - https://gerrit.wikimedia.org/r/267045 (https://phabricator.wikimedia.org/T118329) (owner: Milimetric) [17:37:25] madhuvishy: let's talk later about burrow changes and how to get values from hiera [17:39:24] nuria_: the way I was testing it was to add articles to https://analytics.wmflabs.org/demo/pageview-api/ and check out the network tab (for a long date range). It seems to me that when I'm asking for articles I already fetched, it gets them in around 50-100 ms. [17:39:37] that's not awesome for an API, but it's not terrible [17:39:39] Analytics: Add the possibility to introduce new email templates to Burrow - https://phabricator.wikimedia.org/T126008#2002721 (elukey) p:Triage>Normal [17:40:16] Analytics-Kanban: Add the possibility to introduce new email templates to Burrow - https://phabricator.wikimedia.org/T126008#2002705 (elukey) [17:50:33] (PS8) Bearloga: Functions for categorizing queries. [analytics/refinery/source] - https://gerrit.wikimedia.org/r/254461 (https://phabricator.wikimedia.org/T118218) [18:02:18] going offline a-team! Have a good day/weekend! [18:03:21] I decided with Madhu to wait a bit for the Burrow CR [18:03:39] to figure out if we can move the config files [18:03:44] byyyyeeeee o/ [18:05:30] have a good weekend elukey [18:38:05] (CR) Milimetric: "tiny grammar nit, I'm just gonna fix it and merge." (2 comments) [analytics/dashiki] - https://gerrit.wikimedia.org/r/259437 (https://phabricator.wikimedia.org/T110351) (owner: Madhuvishy) [18:38:09] (PS9) Milimetric: Set up fabric to deploy dashboards powered by dashiki [analytics/dashiki] - https://gerrit.wikimedia.org/r/259437 (https://phabricator.wikimedia.org/T110351) (owner: Madhuvishy) [18:39:19] milimetric: yay, think we can start setting up our new dashiki instance next? :) [18:39:59] (PS10) Milimetric: Set up fabric to deploy dashboards powered by dashiki [analytics/dashiki] - https://gerrit.wikimedia.org/r/259437 (https://phabricator.wikimedia.org/T110351) (owner: Madhuvishy) [18:40:15] (CR) Milimetric: [C: 2 V: 2] "so cool! :)" [analytics/dashiki] - https://gerrit.wikimedia.org/r/259437 (https://phabricator.wikimedia.org/T110351) (owner: Madhuvishy) [18:40:49] milimetric: also - for that submodules thing in wikimetrics-deploy not working - can you try adding your username to the ssh:// url in .gitmodules. like milimetric@... [18:41:29] hm, yeah, but then wouldn't my name be hardcoded there? [18:42:11] and yeah, we could set up dashiki-01 and switch the proxies, sure [18:42:43] I'm gonna get through your wikimetrics docker change first [18:45:13] madhuvishy: ^ and it worked, but I had to also prepend milimetric@ to the submodules section in .git/config [18:46:22] milimetric: aah okay - don't know why it's needed - i'll see if i can figure it out. i thought if we did ssh:// url without username it'll pick it up [18:47:27] yeah, weird [19:05:36] (CR) Milimetric: "lgtm, some grammar nits on the README" (4 comments) [analytics/wikimetrics] - https://gerrit.wikimedia.org/r/267172 (https://phabricator.wikimedia.org/T123749) (owner: Madhuvishy) [19:05:53] madhuvishy: I'm feeling a little sick so I'm gonna take a break see if it goes away [19:06:13] I'll fix up the nits I pointed out on that readme ^ [19:10:01] milimetric: I'll do it ;) [19:10:07] take care! [19:14:13] (PS11) Madhuvishy: Use docker to develop wikimetrics [analytics/wikimetrics] - https://gerrit.wikimedia.org/r/267172 (https://phabricator.wikimedia.org/T123749) [19:35:29] (PS2) Madhuvishy: Make google javascript origin configurable [analytics/wikimetrics-deploy] - https://gerrit.wikimedia.org/r/268198 [19:36:12] (CR) Madhuvishy: [C: 2 V: 2] "Minor change - self merging." [analytics/wikimetrics-deploy] - https://gerrit.wikimedia.org/r/268198 (owner: Madhuvishy) [19:37:47] (PS1) Madhuvishy: Make uwsgi stop and start instead of restart temporarily [analytics/wikimetrics-deploy] - https://gerrit.wikimedia.org/r/268724 [19:38:17] (CR) Madhuvishy: [C: 2 V: 2] "Minor fix - self merging." [analytics/wikimetrics-deploy] - https://gerrit.wikimedia.org/r/268724 (owner: Madhuvishy) [19:44:12] (CR) Milimetric: [C: 2 V: 2] Use docker to develop wikimetrics [analytics/wikimetrics] - https://gerrit.wikimedia.org/r/267172 (https://phabricator.wikimedia.org/T123749) (owner: Madhuvishy) [19:45:07] ooh, I still feel weird, must've eaten something wrong [19:45:23] milimetric: :/ [19:45:25] madhuvishy: let's clean up dashiki? We still can't kill limn1 after that, but it'll be another step [19:45:36] milimetric: yes! [19:45:39] (we can't kill it 'cause there are some limn dashboards) [19:45:46] also, do you want to try deploying wikimetrics? [19:45:53] nothing should change or break [19:45:56] um... nah, you did it right? [19:46:04] but the code changes can go to prod [19:46:10] no the docker changes [19:46:25] but you deployed the code changes yesterday, no? [19:46:31] I see the new version of the form [19:46:49] ummmm - yes! those are your changes. the dockerfile patch - is also a code change to wikimetrics [19:47:05] and even though it has no effect on the site - it should still be deployeD? [19:47:09] but that's just a config change, not a code change, prod doesn't need it right? [19:47:27] that's true - when we deploy next - it'll all go though [19:47:33] we can deploy it along with the next change whenever that is, especially since it's friday [19:47:37] cool [19:47:38] okay [19:47:45] I like to stick to front-end stuff only that's easy like dashiki [19:48:05] alright. do you want to add the other dashboards to the config? [19:48:09] k, so I'll deploy all the dashiki-configured ones over to dashiki-01, and then there's no way to test them until we switch the DNS right? [19:48:18] well [19:48:18] yeah, I'll submit a patch with all of them [19:48:24] you can do dashiki-staging-01 [19:48:36] i have a couple -test domains set up [19:48:37] and then we can test with curl and faking the requesting host? [19:48:48] oh, right, [19:48:56] for language-reportcard-test and edit-analysis-test [19:49:00] you can do the same [19:49:11] well, why don't we just have dashiki-deploy-test and then we can re-use that [19:49:31] milimetric: dashiki-staging-01 is that instance [19:49:39] the test domains are just proxies [19:50:04] right, but it's annoying to keep setting them up, I mean when we test a deploy, we can always override the host to dashiki-deploy-test [19:50:14] just to make sure it's working, then we only need one proxy [19:50:19] ah [19:50:23] that may not work [19:50:37] apache is looking for the /srv/static/hostname folder [19:50:43] so [19:50:44] oh right, 'course [19:50:47] if we do this way [19:51:00] you should always deploy to dashiki-test.wmflabs.org [19:51:12] right, and then the folder would be wrong [19:51:16] and i dont know if thatsa a good idea [19:51:47] ok, maybe that's all overkill anyway - like what can really go wrong with a dashiki deploy... [19:51:56] I'll make the configs and think about it meantime [19:51:56] you can do fab dashboard:edit-analysis,hostname=dashiki-test.wmflabs.org staging deploy [19:52:04] and do the same to test one by one [19:52:07] but [19:52:20] i'd rather just have test domains for all the dashboards [19:52:25] so you can test 2 at a time [19:52:44] and folks developing them can use the test ones [19:54:56] and in the config.yaml file has edit-analysis.wmflabs.org configured as hostname - while deploying to staging, you'd definitely have to override the hostname [19:55:09] may be we can force that to avoid deploying to prod [19:55:45] I was thinking it was good the way you have it now, where edit-analysis-test is in the config.yaml and if you want to go to prod you have to override it [19:56:11] milimetric: that would work too [19:56:16] i can force that behavior [19:56:29] would have to swap the order of the tasks in the deploy command [19:56:47] milimetric: it should be fab staging dashboard:name deploy [19:57:05] because dashboard now needs to be aware of what the stage is [19:57:19] hm [19:57:50]