Update: 2017/09/29

There are at 2 servers available to us (thanks, @dr0ptp4kt) that were earmarked for another project but aren't yet in use. There might be another two but this hasn't been confirmed yet. Alternatively, there's some planned capacity available in "the SCB cluster", which is shared infrastructure managed by the Services and Ops teams.

For the former, we'll need to work with Ops to:

1. Re-image the machines.
2. Puppetize and Scap3ize.
3. Set up DNS entries.
   1. This is blocked on us coming up with a name 😉
4. Define/deploy the Varnish VCL.

For the latter we'll need to:

1. Fill out a service deployment request with as much information as possible, including required external DNS entries and Varnish VCL.
2. Follow this well-written tutorial to Puppetize, Scap3ize, and Dockerize.
   • The tutorial advises that this is done in parallel with #1.

Looking at previous service deployment requests (T105538, T117560, T128463), these requests seem to be completed in 2-3 months.

Next Steps

1. Create security review tasks for the Marvin codebase and any unreviewed dependencies.
2. Get more detail on the timeline for the first case.
   • In particular, I intend to clarify whether the first case can also be handled with a service deployment request but for specific hardware.

Update: 2017/10/04

There are an additional 2 servers available to us (thanks, @Fjalapeno). If we were to use these servers to deploy Marvin, then we'd have to yield them back to Readers Infra as and when they gear up to deploy the Push-Notification-Service during Q3/Q4 this fiscal year.

In T177057#3646622, @phuedx wrote:

There are at 2 servers available to us (thanks, @dr0ptp4kt) that were earmarked for another project but aren't yet in use. There might be another two but this hasn't been confirmed yet. Alternatively, there's some planned capacity available in "the SCB cluster", which is shared infrastructure managed by the Services and Ops teams.

For the former, we'll need to work with Ops to:

1. Re-image the machines.
2. Puppetize and Scap3ize.
3. Set up DNS entries.
   1. This is blocked on us coming up with a name 😉
4. Define/deploy the Varnish VCL.

Next Steps

2. Get more detail on the timeline for the first case.
   • In particular, I intend to clarify whether the first case can also be handled with a service deployment request but for specific hardware.

@akosiaris, @Joe:

Context: Marvin is the next generation of the mobile site. It's a Node.js web server that serves content and static assets.

We're looking to deploy Marvin for a limited alpha test at the end of Q3. We'll be deploying to either a couple of machines or to the SCB. I'm aware that if we were to deploy it to the SCB, then we should fill out a service deployment request. However, if we were to deploy to other hardware, should we still fill out a service deployment request or is there another process that we have to follow?

I've pinged you both because you've both been active on service deployment requests in the past. If you were the wrong people to ping, then I apologise.

@phuedx I'm a bit perplexed here. I know that you people were invited to discuss Marvin's architecture via the RfC process, and from what I understood, the invite was declined as Marvin is an experiment, and now we want to deploy it to production?

What did I miss here?

Can I get some context: what's the architecture here? What will this service call? what will call it?

So I'd say you need to do both the following things:

• Discuss the overall architecture of this service with the TechCom
• Prepare the usual new service request form, discuss the implications with ops

This comes a long way before we have to worry about hardware resources for a service. I would argue it should've happened when you started developing something that needs to run in production.

From a TechCom perspective, it seems like an RFC will be a necessary step before getting too far into planning a deployment (even alpha).

It would be reasonable to have informal discussions with TechCom prior to entering the RFC process, or it would also be reasonable to jump straight into filing an RFC, and then have conversations in that context.

Here is a page describing the RFC process, but feel free to reach out to me or any TechCom member if you would like any help or guidance.
https://www.mediawiki.org/wiki/Requests_for_comment/Process

In T177057#3657399, @Joe wrote:

What did I miss here?

This task is for defining the steps to follow to get the project to production, see description:

Epic to track progress and info about setting up the production deployment.

Ongoing through Q2 & Q3

Outline

• Research & investigation for defining the work

In T177057#3657399, @Joe wrote:

Can I get some context: what's the architecture here? What will this service call? what will call it?

So I'd say you need to do both the following things:

• Discuss the overall architecture of this service with the TechCom
• Prepare the usual new service request form, discuss the implications with ops

This comes a long way before we have to worry about hardware resources for a service. I would argue it should've happened when you started developing something that needs to run in production.

Thanks for the questions and information! That helps us a lot define the specific steps to follow to successfully deploy. We'll refine the outline of things to do to include your comments 👍

In T177057#3657864, @ksmith wrote:

From a TechCom perspective, it seems like an RFC will be a necessary step before getting too far into planning a deployment (even alpha).

It would be reasonable to have informal discussions with TechCom prior to entering the RFC process, or it would also be reasonable to jump straight into filing an RFC, and then have conversations in that context.

Here is a page describing the RFC process, but feel free to reach out to me or any TechCom member if you would like any help or guidance.
https://www.mediawiki.org/wiki/Requests_for_comment/Process

Thanks for the info and link @ksmith, @phuedx has started to define the work at T177464: Submit an RFC and discuss it with TechCom 👍