Use pointer for HTTPPathMatch

[nak3]

What this PR does / why we need it:

Currently Path field in HTTPRoute is defined by non-pointer. It is not
consistent with HTTPHeaderMatch and hits an issue like #563.

Hence this patch changes to use pointer for HTTPPathMatch.

What type of PR is this?

/kind cleanup

Which issue(s) this PR fixes:

Fixes #563

Does this PR introduce a user-facing change?:

NONE

[k8s-ci-robot]

Hi @nak3. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[hbagdi]

Interesting. HTTPHeaderMatch is a pointer because there is no default value for it. This was not a pointer because this couldn't have a nil value since it has a default.

[robscott]

Thanks for this PR @nak3! We discussed this at today's community meeting and realized this was a bit more complicated than I initially thought. It seems like we'll probably need to change all references to optional structs in this API to pointers if this pattern applies broadly. Before we do that, we want to make sure we're completely understanding why this is happening for requests from client-go but not kubectl. If you (or anyone) are able to try creating the same resource with a yaml manifest, I'd like to confirm that is working for the same config client-go is failing with.

This does feel like a significant issue and a gap in our testing, I just want to make sure that we're correctly understanding the scope and solution here.

[robscott]

/ok-to-test

[robscott]

@danehans or @hbagdi did either of you get time to look into this? It does seem like we need to switch to a pointer here but I haven't had the time to verify yet myself.

[robscott]

Thanks @nak3! I've created #576 to track follow up on this so we can go ahead and get this in.

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: nak3, robscott

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [robscott]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment