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
| spec: | ||
| gatewayClassName: istio | ||
| listeners: | ||
| - name: default |
There was a problem hiding this comment.
I don't mind the name change, but any specific reason to change it?
There was a problem hiding this comment.
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
| allowedRoutes: | ||
| namespaces: | ||
| from: All | ||
| addresses: |
There was a problem hiding this comment.
glad we can remove this,but does it cause any issues with other user-guides?
There was a problem hiding this comment.
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.
be good to get a couple of comments as to what it does or why its needed?
There was a problem hiding this comment.
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.
do we want to cover the error cases?
There was a problem hiding this comment.
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
| .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.
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.
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.
Is this CR watched by the istio operator too?
There was a problem hiding this comment.
Yep it is (the project sail install / not istioctl install which still uses IstioOperator CR)
didierofrivia
left a comment
There was a problem hiding this comment.
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
IstioCR that provides themeshConfiginstead of anIstioOperatorCR for the sail operatorSailWrapperfor updating themeshConfigstored in theIstioCRIstioOperatorpresence first, thenIstio, then fall back to OSSM 2.xTODO:
Istiotype 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.istioctlInstall 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
IstioCRistiocontrolplane.② 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-marketplaceproject and select Kuadrant Operator from this catalog source (kuadrant-operator-catalog). Install with selected namespace set tokuadrant-systemand other settings left as default.Request an instance of Kuadrant in the
kuadrant-systemnamespace:④ 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.loadbalancersif you have insufficient space.⑤ Deploy the toystore application
This creates the toystore
Deployment,Serviceas well as a Gateway APIGatewayandHTTPRoute:Ensure that the
toystore-gatewayis 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
/carsendpoint:Test the endpoint: