Skip to content
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

Migrate Ingress from API extensions/v1beta1 to networking.k8s.io/v1beta1 #1039

Merged
merged 8 commits into from
May 14, 2020

Conversation

rubenvp8510
Copy link
Collaborator

Signed-off-by: Ruben Vargas ruben.vp8510@gmail.com

@codecov
Copy link

codecov bot commented Apr 26, 2020

Codecov Report

Merging #1039 into master will increase coverage by 0.45%.
The diff coverage is 66.92%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1039      +/-   ##
==========================================
+ Coverage   64.23%   64.69%   +0.45%     
==========================================
  Files          83       86       +3     
  Lines        6627     7013     +386     
==========================================
+ Hits         4257     4537     +280     
- Misses       2229     2313      +84     
- Partials      141      163      +22     
Impacted Files Coverage Δ
pkg/inventory/ingress.go 100.00% <ø> (ø)
pkg/strategy/strategy.go 95.53% <ø> (-0.67%) ⬇️
pkg/controller/jaeger/ingress.go 78.37% <20.00%> (+0.60%) ⬆️
pkg/autodetect/main.go 82.35% <25.00%> (-4.36%) ⬇️
pkg/ingress/ingress.go 68.75% <68.75%> (ø)
pkg/ingress/query.go 100.00% <100.00%> (ø)
pkg/strategy/all_in_one.go 90.69% <0.00%> (-4.43%) ⬇️
pkg/deployment/agent.go 96.18% <0.00%> (-3.82%) ⬇️
pkg/deployment/ingester.go 96.24% <0.00%> (-3.76%) ⬇️
pkg/deployment/collector.go 96.77% <0.00%> (-3.23%) ⬇️
... and 18 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f2eded8...2a5286f. Read the comment docs.

@@ -3,7 +3,7 @@ package ingress
import (
"fmt"

extv1beta1 "k8s.io/api/extensions/v1beta1"
extv1beta1 "k8s.io/api/networking/v1beta1"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: extv1beta1 -> netv1beta1?

@@ -49,7 +49,7 @@ func (i *QueryIngress) Get() *extv1beta1.Ingress {
return &extv1beta1.Ingress{
TypeMeta: metav1.TypeMeta{
Kind: "Ingress",
APIVersion: "extensions/v1beta1",
APIVersion: "networking/v1beta1",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be networking.k8s.io/v1beta1, as shown in https://kubernetes.io/docs/concepts/services-networking/ingress/#the-ingress-resource.

Signed-off-by: Ruben Vargas <ruben.vp8510@gmail.com>
@rubenvp8510 rubenvp8510 changed the title Migrate Ingress from API extensions/v1beta1 to networking.k8s.io/v1beta1 WIP Migrate Ingress from API extensions/v1beta1 to networking.k8s.io/v1beta1 Apr 28, 2020
Signed-off-by: Ruben Vargas <ruben.vp8510@gmail.com>
@pavolloffay
Copy link
Member

Q: should be extensions.ingresses removed from roles? Could auto-detection use the newer/older API based on the platform version as opposed to just disabling the ingress if we it runs on the old platform?

@rubenvp8510
Copy link
Collaborator Author

Could auto-detection use the newer/older API based on the platform version as opposed to just disabling the ingress if we it runs on the old platform?

About the role, I'm still not sure if we need to remove or may be have two versions, for your question about disabling the ingress, yes, the idea is to detect the platform and use the properly API. I added some code that does that, I still need to update the ingress code (and may be the tests).

Signed-off-by: Ruben Vargas <ruben.vp8510@gmail.com>
@rubenvp8510
Copy link
Collaborator Author

Not sure if this is a good solution for use both APIs

I'm using the new Ingress type for all ingress code, but changed to old API just at the time of consuming it. (on create, delete, update etc..)

@objectiser
Copy link
Contributor

@rubenvp8510 sounds like a reasonable approach to me.

Signed-off-by: Ruben Vargas <ruben.vp8510@gmail.com>
@rubenvp8510 rubenvp8510 changed the title WIP Migrate Ingress from API extensions/v1beta1 to networking.k8s.io/v1beta1 Migrate Ingress from API extensions/v1beta1 to networking.k8s.io/v1beta1 May 6, 2020
@rubenvp8510
Copy link
Collaborator Author

I added tests to this.

Not sure what should we do with roles, We can create the roles now because both APIs are present in the actual k8s versions, but once k8s removes the extension.ingresses, the role creation might fails.

Should we leave it as it is for now? or create two roles.yaml files one with extension and other with networking? @pavolloffay @objectiser

@objectiser
Copy link
Contributor

@rubenvp8510 I think, as this is for supporting older versions of k8s, then having a separate role.yaml (and cluster_role.yaml) is probably fine - just need to make it clear in the install instructions.

@pavolloffay
Copy link
Member

If the old API groups are noop in the new cluster versions (which I think they are) we can keep it in the single file. It's easier to maintain and easier to deploy for users.

@objectiser
Copy link
Contributor

According to this post, k8s 1.22 will stop serving the deprecated API (ingress) - so we still have a bit of time until that happens. So it should be fine to include both in the same file for now as @pavolloffay suggests.

However we would need to check if it is a noop, once 1.22 is out. Or do a test by trying to include a non-existent api.

@rubenvp8510
Copy link
Collaborator Author

If the old API groups are noop in the new cluster versions (which I think they are) we can keep it in the single file. It's easier to maintain and easier to deploy for users.

Definitely, will be easier to maintain, an is the option I would prefer, the only remain question is if it will work on 1.22.

@objectiser
Copy link
Contributor

the only remain question is if it will work on 1.22.

@rubenvp8510 Agree, but we have plenty of time before 1.22 is available, so for now we can have the two versions included.

@rubenvp8510
Copy link
Collaborator Author

rubenvp8510 commented May 11, 2020

the only remain question is if it will work on 1.22.

@rubenvp8510 Agree, but we have plenty of time before 1.22 is available, so for now we can have the two versions included.

Yes, just may be we would want to file a ticket to don't forget this?

Also I'm not very confident about tests I did here., those might could start failing when the old API won't be available (or does nothing (noop)). So Do you have any suggestions?

@pavolloffay
Copy link
Member

+1 on a ticket to remove it in 1.22

We can have an e2e test that checks that the API is available.

@objectiser
Copy link
Contributor

@kevinearls Could you give this PR a test?

if viper.Get("ingress-api") == ExtensionAPI {
extIngressList := c.fromNetToExt(*obj)
err := c.client.Update(ctx, &extIngressList, opts...)
if err != nil {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not necessary, could just return c.client.Update...

if viper.Get("ingress-api") == ExtensionAPI {
extIngressList := c.fromNetToExt(*obj)
err := c.client.Delete(ctx, &extIngressList, opts...)
if err != nil {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment as above.

if viper.Get("ingress-api") == ExtensionAPI {
extIngressList := c.fromNetToExt(*obj)
err := c.client.Create(ctx, &extIngressList, opts...)
if err != nil {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above.

assert.NoError(t, err)
assert.Equal(t, 1, len(extIngressList.Items))

// Should return 0 (not using extension API)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this say "not using networking API"?

Copy link
Member

@pavolloffay pavolloffay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, Just minor comments. It would be good to test this though in a real cluster.

@@ -6,6 +6,8 @@ import (
"sync"
"time"

"github.com/jaegertracing/jaeger-operator/pkg/ingress"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it should go to group import 3


// List is a wrap function that calls k8s client List with extend or networking API.
func (c *Client) List(ctx context.Context, list *netv1beta.IngressList, opts ...client.ListOption) error {
if viper.Get("ingress-api") == ExtensionAPI {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be at client init time. I guess nobody will enable extensions API dynamically

},
ObjectMeta: ingress.ObjectMeta,
Spec: netv1beta.IngressSpec{
Backend: &netv1beta.IngressBackend{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whet if backend is not defined? In the fromNetToExt ingress.Spec.Backend is checked to see if nil.

@kevinearls
Copy link
Contributor

@rubenvp8510 @objectiser Tests have passed on an OCP 4.4 cluster

Signed-off-by: Ruben Vargas <ruben.vp8510@gmail.com>
Signed-off-by: Ruben Vargas <ruben.vp8510@gmail.com>
@kevinearls
Copy link
Contributor

@rubenvp8510 I ran into one small problem when running on OCP. I get the following log messages every 5 seconds

time="2020-05-14T15:29:25Z" level=info msg="Auto-detected ingress api" ingress-api=networking
time="2020-05-14T15:29:30Z" level=info msg="Auto-detected ingress api" ingress-api=networking

@rubenvp8510
Copy link
Collaborator Author

@kevinearls I think this is due this logs:

https://github.com/jaegertracing/jaeger-operator/pull/1039/files#diff-c2bdb352258b22c51211b662ef5489fbR143

I can remove those log lines or change the detection to another place.

Signed-off-by: Ruben Vargas <ruben.vp8510@gmail.com>
func NewIngressClient(client client.Client, reader client.Reader) *Client {
usedAPI := NetworkingAPI
if viper.Get("ingress-api") != nil {
usedAPI = viper.Get("ingress-api").(string)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is viper.GetString() so the type assertion is not needed

@rubenvp8510
Copy link
Collaborator Author

@kevinearls @pavolloffay @objectiser I changed the detection place and address the comments.
Could you please review?

Thanks

@rubenvp8510 rubenvp8510 force-pushed the TRACING-1115 branch 2 times, most recently from 92eaa82 to 50999d0 Compare May 14, 2020 16:18
Signed-off-by: Ruben Vargas <ruben.vp8510@gmail.com>
@pavolloffay pavolloffay merged commit ee0ead3 into jaegertracing:master May 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants