Hi, thanks for this!

This is interesting, some feedback from my side:

• What is the intended audience? If it's an SRE or at least someone who knows what LVS is, it's pretty fine, but it needs to be denoted clearly that it assumes knowledges of what LVS is. If it's someone else and not an SRE person (or at least someone who knows what LVS is), the first question doesn't even make sense without knowledge of what LVS is.
• Closely related, when and how is this to be used ? As in, is this going to be added and augment some already existing process like the one used by https://phabricator.wikimedia.org/project/profile/1305/? From the description (gitlab/mailman/etc) it looks like not, just making sure. So, it will be more like part of a wikitech doc used to ease SRE lives? If yes, it looks pretty ok to me.
• Depending on the intended audience, k8s inclusion might or might not make sense. Networking in our k8s services cluster is pretty well defined and SvcOps takes care of the networking stuff already and hides the implementation details from requestors (which is usually the rest of the org). So, if this isn't intended for general audience and added to an already existing process, we can skip k8s as it will only add confusion.

Audience is indeed SREs, to be used to help them know what the (high level and preferred) options are when deploying a new service.
Service-deployment-requests is nice, I'd imagine SRE using that flowchart to know how the service request would fit in our infra.

For k8s I'd imagine something basic at the very beginning to know if it should go the k8s path or the LVS path. Unless it's more complicated than that.

In T279296#6979590, @ayounsi wrote:

Audience is indeed SREs, to be used to help them know what the (high level and preferred) options are when deploying a new service.

OK, good to know. Thanks!

Service-deployment-requests is nice, I'd imagine SRE using that flowchart to know how the service request would fit in our infra.

We 'd need to expand the scope of that a bit to accommodate generic new service requests, up to now it's mostly a way to let SRE Service Operations know and respond to requests for incoming projects. That being said, it's mostly generic enough to allow for that anyway, we 'd just need to communicate it better.

For k8s I'd imagine something basic at the very beginning to know if it should go the k8s path or the LVS path. Unless it's more complicated than that.

Well, technically, we still do LVS configuration even if its is k8s, however it's rather standardized. So probably the 2 paths should be named otherwise but +1 on the premise.