Mark IDL's as "in production"

[HelloGrayson]

Currently IDL has the effect of assuming all IDL's are "in production" - that is to say, everyone is viewing IDL as if they could download the thrift files and immediately start calling these services in prod.

This isn't the case, and it will get worse when we have include support across the board, since shared IDL's will need to be committed to master in order for child services to begin implementing them.

I suggest we create an idl mark command or something similarly named, that users can integrate with their deploy systems to mark IDL's as "in production".

Thoughts? cc @uber/rpc

[willfrew]

+1

[andrewdeandrade]

Our current publishing strategy (and what the readme encourages) is to run idl publish as an automated process. Our current approach to automation only runs idl publish as a Phabricator Herald rule when an arc diff is landed on master. So for our purposes, every published idl is the idl on master.

Now our current m.o. at Uber is that you should always deploy what is on master. i.e. once you run arc land you are then expected to deploy to production and monitor your deployment to make sure everything went smoothly (in case automated tests didn't catch a problem that only happens in production). Since we have an expectation that master represents production, there is only a very tiny window between when an idl is published by CI and when it is available in production.

An alternative approach would be to run idl publish not as part of CI upon landing on master, but to run idl publish as a pre-deploy task.

With all this in mind, I don't see the value of this feature since you'd still want to automate marking what idl is in production and the approach to doing that would be no different than the approach to automating publishing. As such, this is a wontfix unless someone has additional reasons for how idl mark would be semantically different from idl publish.

[andrewdeandrade]

Furthermore, since publish works by only updating idl files by hashed idl content comparison, rollbacks that trigger idl publish would also have the effect of rolling back the published idl to the previous state.

[prashantv]

I disagree that there's only a tiny window between when an idl is published at when it's available in production. There's a few things that can happen:

• There is no requirement or expectation that you deploy a change as soon as you land it. A lot of changes can be queued up, waiting for the next release.
• A deploy may be rolled back, so the window would grow larger
• Thrift changes can be made independently of code changes that actually add the functionality

I like the idea of running idl publish as a pre-deploy task though. It does seem like that'll fix the issues, without requiring a separate command.

[blampe]

+1 to @prashantv and @breerly.