-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable petsets in origin #9972
Enable petsets in origin #9972
Conversation
Has a mostly green run, would like to get this in @liggitt |
That integration flake is killing us. |
app: mysql | ||
annotations: | ||
pod.alpha.kubernetes.io/initialized: "true" | ||
pod.alpha.kubernetes.io/init-containers: '[ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SCC checks these, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Update our hack script for tests to pull in this example each time so we don't lose it |
Name: PetSetControllerRoleName, | ||
}, | ||
Rules: []authorizationapi.PolicyRule{ | ||
// PetSetController.podCache.ListWatch |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This means its not using a shared informer. Either you wired it wrong or we need an upstream fix.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It didn't require this to work, I'm again just following the pattern in this file which is agnostic of shared informer.
I think I'm going to curate the examples list and focus on one or two that work, and point people to upstream. |
I'm going to enable these for read write for admin/edit now, rather than later, because there may not be a later and I don't want to hold QE up. Admins can always deny them if they have a problem. |
You know we're only getting to do this because he's on vacation. I think you should now merge something crazy of mine :) |
I hate you both |
I don't anticipate pet set problems, and if we get the "insecure role" I'll move them there. |
Trying the examples out is mostly a DNS problem at this point (the upstream DNS code is opaquely tested, so I'm not even sure what format they are expecting, or whether they don't even work on centos for some reason). |
DNS is broken in Kubernetes (ish), sorting out in 29420 |
Good news! DNS was broken on our side. Fixing. And adding mor tests. |
@smarterclayton What are the precise rules on hostname annotations? If you enable them here, it may have an impact on the service serving cert signer. @liggitt There were issues with the first upstream implementations of this hostname thing. Is it good now? |
Rules are they have to be set on the pod. So create/update on pods allows you to add public DNS names under the controlling service. |
I'm not aware of any security issues w.r.t. hostname annotation upstream in the current design. |
0e46f68
to
2e1f4d0
Compare
Hells yeah! going to make status work real quick. On Tue, Jul 26, 2016 at 11:17 PM, OpenShift Bot notifications@github.com
|
Ok, petset is now no longer in an embarrassing state in Origin. DNS is now conformant with Kube (tim's tests do not test what he thinks they test), the galera example worked for me with no modification except adding host path volumes to my system, and oc status is not terrible:
I made a structural change to the graph to prepare for more than one controller (replaced ManagedByRC with ManagedByControllers, cleaned up some abstractions slightly) although I did not add petset vs RC fighting. I'll open an issue to replace our complicated "this manages this" with "this is covered by this controller" as the idle PR covers. |
[test] |
ManagedByRCEdgeKind = "ManagedByRC" | ||
// ManagedByControllerEdgeKind goes from Pod to ReplicationController when the Pod satisfies the ReplicationController's label selector | ||
// TODO: rename to ManagedByController, make generic to controller ref | ||
ManagedByControllerEdgeKind = "ManagedByRC" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's change the constant now.
This pull got a lot bigger while my back was turned. |
}, | ||
// PetSetController.podClient | ||
{ | ||
Verbs: sets.NewString("get", "create", "delete", "update"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
api group
minor comments, didn't review the dns bits, lgtm otherwise. |
Make a minor change to prepare for generic controller references (since PetSets and RCs could conflict over pods).
Evaluated for origin test up to cc58509 |
continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/7527/) |
} | ||
} | ||
|
||
matchHostname := len(segments) > 3 && !hasAllPrefixedSegments(segments[3:4], "_") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The godoc at the top of this function should be updated to clarify that we now either return a hash of the IP or a hostname value. Additionally, it would be very useful to people looking at/reviewing this code in the future if there were comments added before each "branch point"/conditional indicating which subquery they were matching (for instance, AFAICT, this one might read "matchHostname indicates we are matching ...endpoints, and not _endpoints...svc")
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do a follow up PR with comments - saw this after I hit the big red. Keep commenting please.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also: nit: I think this would be clearer as !strings.HasPrefix(segments[3], "_")
(the use of the single-element slice here seems ad bit odd to me...)
[merge] talked through DNS stuff with Jordan and will get more review later. |
continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/7527/) (Image: devenv-rhel7_4758) |
Evaluated for origin merge up to cc58509 |
@@ -187,20 +187,29 @@ func TestDNS(t *testing.T) { | |||
expect: []*net.IP{&headlessIP}, | |||
}, | |||
{ // specific port of a headless service | |||
dnsQuestionName: "unknown-port-2345.e1.headless.default.svc.cluster.local.", | |||
dnsQuestionName: "_http._tcp.headless.default.svc.cluster.local.", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like none of these exercise the _<protocol>.<svc>.<ns>.svc
case (wildcard port match), so there should probably be such a test here. Furthermore, it looks like none of these test the .endpoints.cluster.local
queries, and that seems like it would be valuable to test here as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those are tested in the extended DNS test and the test-cmd DNS test.
On Thu, Aug 4, 2016 at 11:02 PM, Solly Ross notifications@github.com
wrote:
In test/integration/dns_test.go
#9972 (comment):@@ -187,20 +187,29 @@ func TestDNS(t _testing.T) {
expect: []_net.IP{&headlessIP},
},
{ // specific port of a headless service
dnsQuestionName: "unknown-port-2345.e1.headless.default.svc.cluster.local.",
dnsQuestionName: "_http._tcp.headless.default.svc.cluster.local.",
It looks like none of these exercise the _...svc case
(wildcard port match), so there should probably be such a test here.
Furthermore, it looks like none of these test the .endpoints queries, and
that seems like it would be valuable to test here as well.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openshift/origin/pull/9972/files/cc585097d4706f1d49fb9a451760f38e9863a794#r73636324,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABG_pymEzpOhGu0rsHQnD2TGkhSFO4LAks5qcqeugaJpZM4JRYA_
.
Overall, I think the DNS stuff in general looks ok, but it seems like there are a couple of paths missing from the integration tests, and the DNS code really needs better commenting. The flow of the DNS code is somewhat convoluted (not particularly because of this PR, just in general), so I think comments to the effect of |
[test]