warning on network phase

[chrislovecnm]

This will allow for further network configurations such as ignoring tags, not having IG, not having NAT gateways. These are multiple issues that we can close with this. This would also allow for the use of private networks in regions that do not support nat gateways. A user couple build the network themselves and build there own nat boxes.

Fixes: #780, #1530, #971

[chrislovecnm]

/assign @justinsb

[justinsb]

The default should be enforcement. We can discuss a feature flag or something like that for "just warn", but I would strongly prefer to add features where they are missing, not just turn off our verification. It's too much of a time sink otherwise to find out what went wrong - both for the user & for us.

private networks in regions that do not support NAT gateways

Let's add support for this

[chrislovecnm]

@justinsb we can disagree on this one. There are just too many different crazy network configs out there, and we cannot hope to support them all. I agree that we should implicitly support no gateway, and I have a PR inbound. Let's bring this up on next developer office hours.

@andrewsykim @blakebarnett @sethpollack any opinion on this?

You guys may not be familiar with the new phases, but in a nutshell, @justinsb has broken up iam, network, cluster into different phases. Each phase can be run separately. During the cluster phase, it is checking that networking phase has been completed as specified, but I would like to relax that check to just a warning, not requiring the network that we recommend/expected.

[andrewsykim]

Skipping network config verifications sounds like it could lead to more issues down the road. Exposing and letting users change the lifecycle for each phase definitely seems reasonable though.

[chrislovecnm]

Sounds like we need a lifecycle API section then ;)

[k8s-github-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: chrislovecnm

Associated issue: 780

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

Needs approval from an approver in each of these OWNERS Files:

• OWNERS [chrislovecnm]

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

[justinsb]

My instinct would be that we don't want an API section, we want flags on kops update instead.

[chrislovecnm]

@justinsb we can do flags, but I am wondering if this needs to be in the API, because of kops server.

[justinsb]

I would love to get it so that network is a separate object (see #3191), which is how I see it being in the API.

But I'm not sure how putting a field into the API would really work, because you would typically want to run both lifecycles at different times on the same Cluster object. I don't think it makes sense to change the object so that the different phases run (?) Am I missing a trick?

[k8s-github-robot]

@chrislovecnm PR needs rebase

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close