-
Notifications
You must be signed in to change notification settings - Fork 33
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
Add support for project sail #323
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #323 +/- ##
==========================================
- Coverage 65.42% 64.85% -0.57%
==========================================
Files 35 35
Lines 3800 3807 +7
==========================================
- Hits 2486 2469 -17
- Misses 1122 1138 +16
- Partials 192 200 +8
Flags with carried forward coverage won't be shown. Click here to find out more.
|
@adam-cattermole is that an attempt to fix #299 ? |
Yes it is, still a WIP though |
d422ea8
to
8073ad3
Compare
a160ad3
to
3b76423
Compare
I'm still looking at the other points in the to do section but given they could be follow ups I've marked ready for review |
@adam-cattermole I am a fan of using project sail in regular development but I think we need to be careful to ensure we are still staying compatible with "regular" istio installs |
I've left the original install options in the Makefile but added a commit moving to installing project sail locally. Will need an additional change to the docs as there is a minor difference in how we access the deployed application. I'll make a change to have the integration tests run on each istio install type - that might be enough to make sure we aren't breaking anything on each PR. |
0231512
to
ad4678b
Compare
@@ -8,12 +8,9 @@ metadata: | |||
spec: | |||
gatewayClassName: istio | |||
listeners: | |||
- name: default |
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.
I don't mind the name change, but any specific reason to change it?
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 was just to match the naming when retrieving the port from the gateway as used in the istio docs - no real reason though we can leave it as default and I can update the exports in each of the guides
port: 80 | ||
protocol: HTTP | ||
allowedRoutes: | ||
namespaces: | ||
from: All | ||
addresses: |
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.
glad we can remove this,but does it cause any issues with other user-guides?
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.
On a sail install this part of the spec gets populated when it creates the loadbalancer service so it should be present anyway. I'll double check that I didn't miss any user guides though.
rawValues: | ||
gateways: | ||
istio-ingressgateway: | ||
autoscaleEnabled: false |
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.
be good to get a couple of comments as to what it does or why its needed?
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 was just to match our original local deploy configuration but isn't necessary and could be removed https://github.com/Kuadrant/kuadrant-operator/blob/main/config/dependencies/istio/istio-operator.yaml#L48-L54
assert.Equal(t, wrapper.GetConfigObject(), ist) | ||
} | ||
|
||
func TestSailWrapper_GetMeshConfig(t *testing.T) { |
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.
do we want to cover the error cases?
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.
Couple of small comments but the changes look reasonable to me. I don't want to approve this as I don't work in the kuadrant-operator enough. Will leave that to @eguzki @guicassolato or @alexsnaps
I will try out the verification steps next
Note I will try it on kubernetes via https://github.com/maistra/istio-operator/tree/maistra-3.0
ad4678b
to
bd080f1
Compare
bd080f1
to
57ed8b9
Compare
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.
I only have one comment
.PHONY: sail-install | ||
sail-install: kustomize | ||
$(MAKE) install-metallb | ||
$(KUSTOMIZE) build $(ISTIO_INSTALL_DIR)/sail | kubectl apply -f - |
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 could be replaced with kubectl apply -k $(ISTIO_INSTALL_DIR)/sail
I believe. The default version ov kustomize shipped with kubectl might be missing features required, but I have yet to hit this issue.
This does raise a second question. We are controlling the version of kustomize but not kubectl. Should we be controlling the kubectl version?
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.
I see your suggestion, but given we use this for all of our kustomize uses elsewhere I think it would be strange to have this single occurrence use kubectl apply -k
. Perhaps we should have a follow up issue to replace all $(KUSTOMIZE) build .. | kubectl apply -f
if we think that makes sense? Perhaps we want more fine-grained control over the kustomize version so we're not tied to a specific version of kubectl.
I was able to work with this in kubernetes. https://gist.github.com/maleck13/eb5860181404f055ac5ec64d81945a4f @alexsnaps @adam-cattermole this ready to merge? |
@maleck13 I'm happy with the changes but I think we could use an approving review from service protection |
return nil, err | ||
} else { | ||
// Error is NoMatchError so check for Istio CR instead | ||
ist := &istiov1alpha1.Istio{} |
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.
Is this CR watched by the istio operator too?
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.
Yep it is (the project sail install / not istioctl install which still uses IstioOperator
CR)
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 way the sail project is added through a wrapper follows the same pattern as the alternatives, however this clearly exposes that we need to find a more declarative way of choosing what mesh provider we are installing. I'd say it's OK now, but we need to consider kickstarting a RFC, say part of the Kuadrant CR spec definitions efforts going like Kuadrant/architecture#5, Kuadrant/architecture#18 and Kuadrant/architecture#6
Changes
Istio
CR that provides themeshConfig
instead of anIstioOperator
CR for the sail operatorSailWrapper
for updating themeshConfig
stored in theIstio
CRIstioOperator
presence first, thenIstio
, then fall back to OSSM 2.xTODO:
Istio
type I've included the maistra operator as a go dep but I think I'm leaning toward duplicating the types as done prior in our https://github.com/Kuadrant/kuadrant-operator/tree/main/api/external/maistra folder rather than including all of these dep changes in the go.mod - Edit: changed my mind here and I think we should just include the types and deal with it for now, in case the API or interaction with it changes we can keep pulling this and potentially do this down the line.istioctl
Install Steps:
① Setup OpenShift cluster
Create an OpenShift cluster and follow the first two steps to install Project Sail and Istio using the guide here https://github.com/maistra/istio-operator/blob/maistra-3.0/bundle/README.md - note you should name your
Istio
CRistiocontrolplane
.② Install Gateway API CRDs
③ Install Kuadrant Operator from this branch
Create a new namespace called
kuadrant-system
:Create a
CatalogSource
:Navigate to OperatorHub on the
openshift-marketplace
project and select Kuadrant Operator from this catalog source (kuadrant-operator-catalog
). Install with selected namespace set tokuadrant-system
and other settings left as default.Request an instance of Kuadrant in the
kuadrant-system
namespace:④ Check loadbalancer quota
You need space for a loadbalancer for istio to create. Within the administration settings in the Openshift Developer Portal for All Projects, navigate to Administration -> ResourceQuotas -> loadbalancer-quota.
Update
spec.quota.hard.services.loadbalancers
if you have insufficient space.⑤ Deploy the toystore application
This creates the toystore
Deployment
,Service
as well as a Gateway APIGateway
andHTTPRoute
:Ensure that the
toystore-gateway
is Accepted and Programmed. You can then test access to the service.Set the environment variables:
Curl the toystore endpoints:
⑥ Create a simple AuthPolicy
Create secrets to use for this authentication:
Send requests to the protected gateway:
⑦ Create a simple RateLimitPolicy
Lets apply a rate limit to our
/cars
endpoint:Test the endpoint: