@Christopher I am looking at 6f371a5a799bcbfb3b0dc95da11ba2ebc771b125 for sprint against d24b3dcb7de3c77caa299694d31f5f7f9bd1a2ff for phabricator as a next deployment here. Do you see a problem with that?

Phab-01 is currently a this version(ing) now

spoke with @Awjrichards who is going to put phab-01 through it's paces for some QA by the 22nd of april

@chasemp The premise that is being put forth that upstream revision https://secure.phabricator.com/D12304 from 8 April (which matches the commit hash you mentioned) is assumed to work with a Sprint commit from 27 March is incorrect. The Sprint version should always be ahead of the Phabricator version.

However, it is entirely possible to update compatibility with the latest Phabricator changes and push a new Sprint revision before the 22 April, which I assume is the planned deployment date. There are a couple outstanding issues that perhaps should be addressed as well before the deployment.

1. Defining a puppet (or manuall) metthod to put static files (images, etc.) from extensions in /webroot. This is mentioned in 6f371a5a799bcbfb3b0dc95da11ba2ebc771b125.

2. Also, T89865. This could be resolved downstream if people want it to change.

In T89830#1193412, @Christopher wrote:

@chasemp The premise that is being put forth that upstream revision https://secure.phabricator.com/D12304 from 8 April (which matches the commit hash you mentioned) is assumed to work with a Sprint commit from 27 March is incorrect. The Sprint version should always be ahead of the Phabricator version.

However, it is entirely possible to update compatibility with the latest Phabricator changes and push a new Sprint revision before the 22 April, which I assume is the planned deployment date. There are a couple outstanding issues that perhaps should be addressed as well before the deployment.

1. Defining a puppet (or manuall) metthod to put static files (images, etc.) from extensions in /webroot. This is mentioned in 6f371a5a799bcbfb3b0dc95da11ba2ebc771b125.

2. Also, T89865. This could be resolved downstream if people want it to change.

@Christopher:

• Regarding versions and compatibility, you tell me what version you want to land on :) I picked HEAD for phab since it seemed the natural place to ask. If you can retrofit sounds good.

• On static files in webroot. That diff is pretty unreviewably large and difficult to consume, I don't see notes on what files and why? Can you elaborate on what you need?

• On T89865...default work boards is an eye sore in some cases, but it is a mistake to shim a "fix" into the entirely unrelated Sprint application because it works in similar trenches. I would much rather have a local patch unrelated to the sprint app where we can judge the ongoing maintenance effort individually. Than to try to be opportunistic and end up piling on unrelated behavior in the sprint extension.

@chasemp See T95469, The Sprint production branch tag release/2015-04-22 is the "ready to go" version. There are 4 static files located in Sprint/rsrc/webroot-static that should be copied to /phabricator/webroot/rsrc/libext. 3 are images (arrows that indicate the sort direction in the tables) and 1 is an SWF that enables clipboard access for a new data export feature from the tables.

I agree with you about the questionable use of Sprint to implement a fix that is really an upstream issue. It is, however, a rather simple change. 1 line and the whole issue goes away (at least until upstream changes things again...). Also, I am not happy with the current confusing split in routing to the Sprint board if a user clicks on the tag and the regular board if someone clicks on the project name. This should be made consistent and making both just default to the project profile seems to be a sensible course.

In T89830#1198389, @Christopher wrote:

1 line and the whole issue goes away

The thing is, there is no agreement among us about "the issue", and therefore we cannot say that there is agreement on that 1 line solution either. I think it is healthy to keep the Sprint features within the Sprint scope, without affecting Phabricator's behavior out of that scope.

In T89830#1198471, @Qgil wrote:

In T89830#1198389, @Christopher wrote:

1 line and the whole issue goes away

The thing is, there is no agreement among us about "the issue", and therefore we cannot say that there is agreement on that 1 line solution either. I think it is healthy to keep the Sprint features within the Sprint scope, without affecting Phabricator's behavior out of that scope.

++

In T89830#1198389, @Christopher wrote:

@chasemp See T95469, The Sprint production branch tag release/2015-04-22 is the "ready to go" version. There are 4 static files located in Sprint/rsrc/webroot-static that should be copied to /phabricator/webroot/rsrc/libext. 3 are images (arrows that indicate the sort direction in the tables) and 1 is an SWF that enables clipboard access for a new data export feature from the tables.

I agree with you about the questionable use of Sprint to implement a fix that is really an upstream issue. It is, however, a rather simple change. 1 line and the whole issue goes away (at least until upstream changes things again...). Also, I am not happy with the current confusing split in routing to the Sprint board if a user clicks on the tag and the regular board if someone clicks on the project name. This should be made consistent and making both just default to the project profile seems to be a sensible course.

@mmodell ...since you gents are taking this over. What do you think about the static resources for sprint app?

@chasemp: you mean, what do I think about where they should be hosted? I suppose I'm fine with copying them in to rsrc, we should just add the location to .git/info/exclude so that they don't cause git conflicts. Or manage the files with puppet if you wanna be anal about it ;)

I would say add them to .gitignore but that in it's self adds potential conflicts (when upstream changes the .gitignore file)

so as we discussed in IRC: probably best to make a symlink in rsrc, managed by puppet, which points to a directory inside the checkout of the sprint extension, where the actual static files will be. @Christopher: does that sound ok to you?

@mmoddell Sounds fine. If possible, it may be worthwhile to take on T94171 if there is time. Will the symlink have to updated if the repo name changes?

https://gerrit.wikimedia.org/r/205723

@Christopher: I'm not sure what the exact solution is for T94171. Just rename the git workdir in /srv/phab/libext?

I am not sure about the process for moving an existing git repository, but the place to request new repos is here http://www.mediawiki.org/wiki/Git/New_repositories/Requests. QChris handled the original create, so he is on the CC list for this task.

But, since the upgrade puppet patch is in play already, I guess that this can wait.

T95469 is still open. And T95469#1217373 in combination with

In T95469#1222775, @KLans_WMF wrote:

• I would strongly recommend against releasing this as it is currently implemented for the following

leads to the decision that we are not deploying today (2015-04-22).

https://phabricator.wikimedia.org/T95469#1227540

Notes on an upgrade in case I'm not around:

1. Stage the next tags for arc/phab/phutil/sprint https://gerrit.wikimedia.org/r/#/c/205723/
2. Merge the commit^
3. puppet agent --test will show the local tags now do not match the defined tags but will not change as long the lock file exists
4. I am paranoid so I make a local backup service apache2 stop && /srv/phab/phabricator/bin/storage dump | gzip > /srv/dumps/T89830.sql.gz. In case of real external backup restore contact @Springle
5. service puppet stop
6. In /etc/phab_epipe.conf change maint = false to maint = true (this makes sure email interaction will be bounced)
7. sudo /usr/local/sbin/phab_update_tag <= make sure things are stopped, remove lock files (one per repo), update repos to latest tag, run scheme upgrade (this user has creds the app user doesn't), and start things up again
8. update security repo in libext if necessary

NOTES:

• users will almost immediately be using / adding new info to phab when it comes back up...I tend to use a hack that allows me to see phab while denying others. An example of this hack I put on iridium here /root/temp/etc/apache2/sites-enabled/50-phabricator.conf. There are other ways to do this and it's not strictly necessary it's just my process.

• the command to checkout a tag in a repo is 'git remote update && git fetch --tags && git checkout tags/<MYTAG>`

@mmodell Sprint tag release/2015-05-06 has been created. Sprint master is merged into production and is (AFAIK) current with upstream Phabricator HEAD.

Seems like things are ready to go.

@Christopher: Thanks!

What about the 'security.allow-outbound-http' option that is now obsolete (and will/can be removed with https://gerrit.wikimedia.org/r/#/c/208848/)? Do we need to set the alternative (security.outbound-blacklist) before the deployment?

In T89830#1262132, @Negative24 wrote:

What about the 'security.allow-outbound-http' option that is now obsolete (and will/can be removed with https://gerrit.wikimedia.org/r/#/c/208848/)? Do we need to set the alternative (security.outbound-blacklist) before the deployment?

@mmodell^

FWIW we set security.allow-outbound-http out of desire and architectural necessity, the phab box is not allowed to call out and it only causes operations that timeout for users. There isn't a risk necessarily other than less than ideal behavior for users trying to do something like use gravatar.