Incorrect/incomplete EC2 DescribeVpcEndpointServicesResponse

Last year the code for describe_vpc_endpoint_services was committed, but the implementation markdown file wasn’t updated to mark this API as implemented. I assume that’s because the code is incomplete? I do know that the response for this API doesn’t match what I’m seeing from AWS.

moto’s response to this API:

<DescribeVpcEndpointServicesResponse xmlns="http://ec2.amazonaws.com/doc/2016-11-15/">
  <requestId>19a9ff46-7df6-49b8-9726-3df27527089d</requestId>
  <serviceNameSet/>
  <serviceDetailSet/>
</DescribeVpcEndpointServicesResponse>

AWS’s response to this API:

<DescribeVpcEndpointServicesResponse xmlns="http://ec2.amazonaws.com/doc/2016-11-15/">
    <requestId>95501499-94d6-44fa-bf6c-cd556b0acd36</requestId>
    <serviceDetailSet>
        <item>
            <acceptanceRequired>false</acceptanceRequired>
            <availabilityZoneSet>
                <item>us-east-1a</item>
                <item>us-east-1b</item>
                <item>us-east-1c</item>
                <item>us-east-1d</item>
                <item>us-east-1e</item>
                <item>us-east-1f</item>
            </availabilityZoneSet>
            <baseEndpointDnsNameSet>
                <item>config.us-east-1.vpce.amazonaws.com</item>
            </baseEndpointDnsNameSet>
            <managesVpcEndpoints>false</managesVpcEndpoints>
            <owner>amazon</owner>
            <privateDnsName>config.us-east-1.amazonaws.com</privateDnsName>
            <privateDnsNameVerificationState>verified</privateDnsNameVerificationState>
            <privateDnsNameSet>
                <item>
                    <privateDnsName>config.us-east-1.amazonaws.com</privateDnsName>
                </item>
            </privateDnsNameSet>
            <serviceId>vpce-svc-xxxxxxxxxxxx</serviceId>
            <serviceName>com.amazonaws.us-east-1.config</serviceName>
            <serviceType>
                <item>
                    <serviceType>Interface</serviceType>
                </item>
            </serviceType>
            <tagSet/>
            <vpcEndpointPolicySupported>true</vpcEndpointPolicySupported>
        </item>
    </serviceDetailSet>
    <serviceNameSet>
        <item>com.amazonaws.us-east-1.config</item>
    </serviceNameSet>
</DescribeVpcEndpointServicesResponse>

[bblommers]

Thanks for the investigation @kbalk. That sounds like a good approach overall. Two minor points:

class MotoAPIBackend: define a new method all_default_vpc_endpoint_services() that when invoked would call the default_vpc_endpoint_service() method for all the loaded backends.

The MotoAPI should really be reserved for operations that are specific to Moto, independent of AWS. So the method is a good idea, but this may be better placed somewhere else - maybe just part of VPCBackend? Alternatively just a separate service/utility class, to ensure that this logic is independent (and independently testable) from other EC2 logic.

Alternatively, the list of ServiceDetails could be created once all the backends were loaded. Does this sound ok?

Generating this list once could lead to a bug where people use context managers:

@mock_sts
@mock_ec2
def test():
    describe_vpc_endpoint_services()  # Generates the list with EC2 and STS
    with mock_transcribe():
        # do other things
        describe_vpc_endpoint_services()  # Generates the list with EC2 and STS - but this should now also include Transcribe

Granted, it’s an edge use case - but it would lead to unexpected behaviour, which is never good. I don’t imagine generating the list would take that long anyway, so let’s just regenerate every time. We can revisit that assumption if it turns out to be too optimistic.

[bblommers]

What do you mean by ‘run through’? I meant that get_vpc_endpoint_services would return the default services (appropriately filtered ofcourse).