* [ior] MAISTRA-1400 Add IOR to Pilot

* [MAISTRA-1089][MAISTRA-1400][MAISTRA-1744][MAISTRA-1811]: Add IOR to Pilot (maistra#135) (maistra#240)

* MAISTRA-1400: Add IOR to Pilot (maistra#135)

* MAISTRA-1400: Add IOR to Pilot

* [MAISTRA-1744] Add route annotation propagation (maistra#158)

* MAISTRA-1811 Store resourceVersion of reconciled Gateway resource (maistra#190)

* MAISTRA-1089 Add support for IOR routes in all namespaces (maistra#193)

* MAISTRA-2131: ior: honor Gateway's httpsRedirect (maistra#276)

If Gateway's httpsRedirect is set to true, create the OpenShift Route
with Insecure Policy set to `Redirect`.

Manual cherrypick from maistra#269.

* MAISTRA-2149: Make IOR robust in multiple replicas (maistra#282)

In scenarios where multiple replicas of istiod are running,
only one IOR should be in charge of keeping routes in sync
with Istio Gateways. We achieve this by making sure IOR only
runs in the leader replica.

Also, because leader election is not 100% acurate, meaning
that for a small window of time there might be two instances
being the leader - which could lead to duplicated routes
being created if a new gateway is created in that time frame -
we also change the way the Route name is created: Instead of
having a generateName field, we now explicitly pass a name to
the Route object to be created. Being deterministic, it allows
the Route creation to fail when there's already a Route object
with the same name (created by the other leader in that time frame).

Use an exclusive leader ID for IOR

* Manual cherrypick of maistra#275

* MAISTRA-1813: Add unit tests for IOR (maistra#286)

* MAISTRA-2051 fixes for maistra install

* MAISTRA-2164: Refactor IOR internals (maistra#295)

Instead of doing lots of API calls on every event - this
does not scale well with lots of namespaces - keep the state
in memory, by doing an initial synchronization on start up and
updating it when receiving events.

The initial synchronization is more complex, as we have to deal with
asynchronous events (e.g., we have to wait for the Gateway store to
be warmed up). Once it's initialized, handling events as they arrive
becomes trivial.

Tests that make sure we do not make more calls to the API server than
the necessary were added, to avoid regressions.

* MAISTRA-2205: Add an option to opt-out for automatic route creation

If the Istio Gateway contains the annotation `maistra.io/manageRoute: false`
then IOR ignores it and doesn't attempt to create or manage route(s) for
this Gateway.

Also, ignore Gateways with the annotation `istio: egressgateway` as
these are not meant to have routes.

* Add integration test for IOR

Signed-off-by: Jacek Ewertowski <jewertow@redhat.com>

* OSSM-1442: IOR: Ignore UPDATE events if resourceVersions are the same (maistra#516)

* OSSM-1442: IOR: Ignore UPDATE events if resourceVersions are the same

For some obscure reason, it looks like we may receive UPDATE events with
the new object being equal to the old one. As IOR always delete and
recreate routes when receiving an UPDATE event, this might lead to some
service downtime, given for a few moments the route will not exist.

We guard against this behavior by comparing the `resourceVersion` field
of the new object and the one stored in the Route object.

* Add test

Co-authored-by: Brian Avery <bavery@redhat.com>
Co-authored-by: Jonh Wendell <jonh.wendell@redhat.com>

Fix debug log formatting

OSSM-1800: Copy gateway labels to routes

Simplify the comparison of resource versions

We store the gateway resource version (the whole metadata actually) in the `syncRoute` object.
There's no need to loop over the routes to perform the comparison.

This also fix the corner case where the gateway has one host and for
some reason OCP rejects the creation of the route (e.g., when hostname is already
taken). In this case the `syncRoute` object exists with zero routes in
it. Thus the loop is a no-op and the function wrongly returns with an
error of `eventDuplicatedMessage`. By comparing directly using the
`syncRoute.metadata` we fix this.

OSSM-1105: Support namespace portion in gateway hostnames

They are not used by routes, so we essentially ignore the namespace part
- anything on the left side of a "namespace/hostname" string.

* [ior] MAISTRA-1400 Add IOR to Pilot

* [MAISTRA-1089][MAISTRA-1400][MAISTRA-1744][MAISTRA-1811]: Add IOR to Pilot (maistra#135) (maistra#240)

* MAISTRA-1400: Add IOR to Pilot (maistra#135)

* MAISTRA-1400: Add IOR to Pilot

* [MAISTRA-1744] Add route annotation propagation (maistra#158)

* MAISTRA-1811 Store resourceVersion of reconciled Gateway resource (maistra#190)

* MAISTRA-1089 Add support for IOR routes in all namespaces (maistra#193)

* MAISTRA-2131: ior: honor Gateway's httpsRedirect (maistra#276)

If Gateway's httpsRedirect is set to true, create the OpenShift Route
with Insecure Policy set to `Redirect`.

Manual cherrypick from maistra#269.

* MAISTRA-2149: Make IOR robust in multiple replicas (maistra#282)

In scenarios where multiple replicas of istiod are running,
only one IOR should be in charge of keeping routes in sync
with Istio Gateways. We achieve this by making sure IOR only
runs in the leader replica.

Also, because leader election is not 100% acurate, meaning
that for a small window of time there might be two instances
being the leader - which could lead to duplicated routes
being created if a new gateway is created in that time frame -
we also change the way the Route name is created: Instead of
having a generateName field, we now explicitly pass a name to
the Route object to be created. Being deterministic, it allows
the Route creation to fail when there's already a Route object
with the same name (created by the other leader in that time frame).

Use an exclusive leader ID for IOR

* Manual cherrypick of maistra#275

* MAISTRA-1813: Add unit tests for IOR (maistra#286)

* MAISTRA-2051 fixes for maistra install

* MAISTRA-2164: Refactor IOR internals (maistra#295)

Instead of doing lots of API calls on every event - this
does not scale well with lots of namespaces - keep the state
in memory, by doing an initial synchronization on start up and
updating it when receiving events.

The initial synchronization is more complex, as we have to deal with
asynchronous events (e.g., we have to wait for the Gateway store to
be warmed up). Once it's initialized, handling events as they arrive
becomes trivial.

Tests that make sure we do not make more calls to the API server than
the necessary were added, to avoid regressions.

* MAISTRA-2205: Add an option to opt-out for automatic route creation

If the Istio Gateway contains the annotation `maistra.io/manageRoute: false`
then IOR ignores it and doesn't attempt to create or manage route(s) for
this Gateway.

Also, ignore Gateways with the annotation `istio: egressgateway` as
these are not meant to have routes.

* Add integration test for IOR

Signed-off-by: Jacek Ewertowski <jewertow@redhat.com>

* OSSM-1442: IOR: Ignore UPDATE events if resourceVersions are the same (maistra#516)

* OSSM-1442: IOR: Ignore UPDATE events if resourceVersions are the same

For some obscure reason, it looks like we may receive UPDATE events with
the new object being equal to the old one. As IOR always delete and
recreate routes when receiving an UPDATE event, this might lead to some
service downtime, given for a few moments the route will not exist.

We guard against this behavior by comparing the `resourceVersion` field
of the new object and the one stored in the Route object.

* Add test

Co-authored-by: Brian Avery <bavery@redhat.com>
Co-authored-by: Jonh Wendell <jonh.wendell@redhat.com>

Fix debug log formatting

OSSM-1800: Copy gateway labels to routes

Simplify the comparison of resource versions

We store the gateway resource version (the whole metadata actually) in the `syncRoute` object.
There's no need to loop over the routes to perform the comparison.

This also fix the corner case where the gateway has one host and for
some reason OCP rejects the creation of the route (e.g., when hostname is already
taken). In this case the `syncRoute` object exists with zero routes in
it. Thus the loop is a no-op and the function wrongly returns with an
error of `eventDuplicatedMessage`. By comparing directly using the
`syncRoute.metadata` we fix this.

OSSM-1105: Support namespace portion in gateway hostnames

They are not used by routes, so we essentially ignore the namespace part
- anything on the left side of a "namespace/hostname" string.

* [ior] MAISTRA-1400 Add IOR to Pilot

* [MAISTRA-1089][MAISTRA-1400][MAISTRA-1744][MAISTRA-1811]: Add IOR to Pilot (maistra#135) (maistra#240)

* MAISTRA-1400: Add IOR to Pilot (maistra#135)

* MAISTRA-1400: Add IOR to Pilot

* [MAISTRA-1744] Add route annotation propagation (maistra#158)

* MAISTRA-1811 Store resourceVersion of reconciled Gateway resource (maistra#190)

* MAISTRA-1089 Add support for IOR routes in all namespaces (maistra#193)

* MAISTRA-2131: ior: honor Gateway's httpsRedirect (maistra#276)

If Gateway's httpsRedirect is set to true, create the OpenShift Route
with Insecure Policy set to `Redirect`.

Manual cherrypick from maistra#269.

* MAISTRA-2149: Make IOR robust in multiple replicas (maistra#282)

In scenarios where multiple replicas of istiod are running,
only one IOR should be in charge of keeping routes in sync
with Istio Gateways. We achieve this by making sure IOR only
runs in the leader replica.

Also, because leader election is not 100% acurate, meaning
that for a small window of time there might be two instances
being the leader - which could lead to duplicated routes
being created if a new gateway is created in that time frame -
we also change the way the Route name is created: Instead of
having a generateName field, we now explicitly pass a name to
the Route object to be created. Being deterministic, it allows
the Route creation to fail when there's already a Route object
with the same name (created by the other leader in that time frame).

Use an exclusive leader ID for IOR

* Manual cherrypick of maistra#275

* MAISTRA-1813: Add unit tests for IOR (maistra#286)

* MAISTRA-2051 fixes for maistra install

* MAISTRA-2164: Refactor IOR internals (maistra#295)

Instead of doing lots of API calls on every event - this
does not scale well with lots of namespaces - keep the state
in memory, by doing an initial synchronization on start up and
updating it when receiving events.

The initial synchronization is more complex, as we have to deal with
asynchronous events (e.g., we have to wait for the Gateway store to
be warmed up). Once it's initialized, handling events as they arrive
becomes trivial.

Tests that make sure we do not make more calls to the API server than
the necessary were added, to avoid regressions.

* MAISTRA-2205: Add an option to opt-out for automatic route creation

If the Istio Gateway contains the annotation `maistra.io/manageRoute: false`
then IOR ignores it and doesn't attempt to create or manage route(s) for
this Gateway.

Also, ignore Gateways with the annotation `istio: egressgateway` as
these are not meant to have routes.

* Add integration test for IOR

Signed-off-by: Jacek Ewertowski <jewertow@redhat.com>

* OSSM-1442: IOR: Ignore UPDATE events if resourceVersions are the same (maistra#516)

* OSSM-1442: IOR: Ignore UPDATE events if resourceVersions are the same

For some obscure reason, it looks like we may receive UPDATE events with
the new object being equal to the old one. As IOR always delete and
recreate routes when receiving an UPDATE event, this might lead to some
service downtime, given for a few moments the route will not exist.

We guard against this behavior by comparing the `resourceVersion` field
of the new object and the one stored in the Route object.

* Add test

Co-authored-by: Brian Avery <bavery@redhat.com>
Co-authored-by: Jonh Wendell <jonh.wendell@redhat.com>

Fix debug log formatting

OSSM-1800: Copy gateway labels to routes

Simplify the comparison of resource versions

We store the gateway resource version (the whole metadata actually) in the `syncRoute` object.
There's no need to loop over the routes to perform the comparison.

This also fix the corner case where the gateway has one host and for
some reason OCP rejects the creation of the route (e.g., when hostname is already
taken). In this case the `syncRoute` object exists with zero routes in
it. Thus the loop is a no-op and the function wrongly returns with an
error of `eventDuplicatedMessage`. By comparing directly using the
`syncRoute.metadata` we fix this.

OSSM-1105: Support namespace portion in gateway hostnames

They are not used by routes, so we essentially ignore the namespace part
- anything on the left side of a "namespace/hostname" string.

* [ior] MAISTRA-1400 Add IOR to Pilot

* [MAISTRA-1089][MAISTRA-1400][MAISTRA-1744][MAISTRA-1811]: Add IOR to Pilot (maistra#135) (maistra#240)

* MAISTRA-1400: Add IOR to Pilot (maistra#135)

* MAISTRA-1400: Add IOR to Pilot

* [MAISTRA-1744] Add route annotation propagation (maistra#158)

* MAISTRA-1811 Store resourceVersion of reconciled Gateway resource (maistra#190)

* MAISTRA-1089 Add support for IOR routes in all namespaces (maistra#193)

* MAISTRA-2131: ior: honor Gateway's httpsRedirect (maistra#276)

If Gateway's httpsRedirect is set to true, create the OpenShift Route
with Insecure Policy set to `Redirect`.

Manual cherrypick from maistra#269.

* MAISTRA-2149: Make IOR robust in multiple replicas (maistra#282)

In scenarios where multiple replicas of istiod are running,
only one IOR should be in charge of keeping routes in sync
with Istio Gateways. We achieve this by making sure IOR only
runs in the leader replica.

Also, because leader election is not 100% acurate, meaning
that for a small window of time there might be two instances
being the leader - which could lead to duplicated routes
being created if a new gateway is created in that time frame -
we also change the way the Route name is created: Instead of
having a generateName field, we now explicitly pass a name to
the Route object to be created. Being deterministic, it allows
the Route creation to fail when there's already a Route object
with the same name (created by the other leader in that time frame).

Use an exclusive leader ID for IOR

* Manual cherrypick of maistra#275

* MAISTRA-1813: Add unit tests for IOR (maistra#286)

* MAISTRA-2051 fixes for maistra install

* MAISTRA-2164: Refactor IOR internals (maistra#295)

Instead of doing lots of API calls on every event - this
does not scale well with lots of namespaces - keep the state
in memory, by doing an initial synchronization on start up and
updating it when receiving events.

The initial synchronization is more complex, as we have to deal with
asynchronous events (e.g., we have to wait for the Gateway store to
be warmed up). Once it's initialized, handling events as they arrive
becomes trivial.

Tests that make sure we do not make more calls to the API server than
the necessary were added, to avoid regressions.

* MAISTRA-2205: Add an option to opt-out for automatic route creation

If the Istio Gateway contains the annotation `maistra.io/manageRoute: false`
then IOR ignores it and doesn't attempt to create or manage route(s) for
this Gateway.

Also, ignore Gateways with the annotation `istio: egressgateway` as
these are not meant to have routes.

* Add integration test for IOR

Signed-off-by: Jacek Ewertowski <jewertow@redhat.com>

* OSSM-1442: IOR: Ignore UPDATE events if resourceVersions are the same (maistra#516)

* OSSM-1442: IOR: Ignore UPDATE events if resourceVersions are the same

For some obscure reason, it looks like we may receive UPDATE events with
the new object being equal to the old one. As IOR always delete and
recreate routes when receiving an UPDATE event, this might lead to some
service downtime, given for a few moments the route will not exist.

We guard against this behavior by comparing the `resourceVersion` field
of the new object and the one stored in the Route object.

* Add test

Co-authored-by: Brian Avery <bavery@redhat.com>
Co-authored-by: Jonh Wendell <jonh.wendell@redhat.com>

Fix debug log formatting

OSSM-1800: Copy gateway labels to routes

Simplify the comparison of resource versions

We store the gateway resource version (the whole metadata actually) in the `syncRoute` object.
There's no need to loop over the routes to perform the comparison.

This also fix the corner case where the gateway has one host and for
some reason OCP rejects the creation of the route (e.g., when hostname is already
taken). In this case the `syncRoute` object exists with zero routes in
it. Thus the loop is a no-op and the function wrongly returns with an
error of `eventDuplicatedMessage`. By comparing directly using the
`syncRoute.metadata` we fix this.

OSSM-1105: Support namespace portion in gateway hostnames

They are not used by routes, so we essentially ignore the namespace part
- anything on the left side of a "namespace/hostname" string.

* [ior] MAISTRA-1400 Add IOR to Pilot

* [MAISTRA-1089][MAISTRA-1400][MAISTRA-1744][MAISTRA-1811]: Add IOR to Pilot (maistra#135) (maistra#240)

* MAISTRA-1400: Add IOR to Pilot (maistra#135)

* MAISTRA-1400: Add IOR to Pilot

* [MAISTRA-1744] Add route annotation propagation (maistra#158)

* MAISTRA-1811 Store resourceVersion of reconciled Gateway resource (maistra#190)

* MAISTRA-1089 Add support for IOR routes in all namespaces (maistra#193)

* MAISTRA-2131: ior: honor Gateway's httpsRedirect (maistra#276)

If Gateway's httpsRedirect is set to true, create the OpenShift Route
with Insecure Policy set to `Redirect`.

Manual cherrypick from maistra#269.

* MAISTRA-2149: Make IOR robust in multiple replicas (maistra#282)

In scenarios where multiple replicas of istiod are running,
only one IOR should be in charge of keeping routes in sync
with Istio Gateways. We achieve this by making sure IOR only
runs in the leader replica.

Also, because leader election is not 100% acurate, meaning
that for a small window of time there might be two instances
being the leader - which could lead to duplicated routes
being created if a new gateway is created in that time frame -
we also change the way the Route name is created: Instead of
having a generateName field, we now explicitly pass a name to
the Route object to be created. Being deterministic, it allows
the Route creation to fail when there's already a Route object
with the same name (created by the other leader in that time frame).

Use an exclusive leader ID for IOR

* Manual cherrypick of maistra#275

* MAISTRA-1813: Add unit tests for IOR (maistra#286)

* MAISTRA-2051 fixes for maistra install

* MAISTRA-2164: Refactor IOR internals (maistra#295)

Instead of doing lots of API calls on every event - this
does not scale well with lots of namespaces - keep the state
in memory, by doing an initial synchronization on start up and
updating it when receiving events.

The initial synchronization is more complex, as we have to deal with
asynchronous events (e.g., we have to wait for the Gateway store to
be warmed up). Once it's initialized, handling events as they arrive
becomes trivial.

Tests that make sure we do not make more calls to the API server than
the necessary were added, to avoid regressions.

* MAISTRA-2205: Add an option to opt-out for automatic route creation

If the Istio Gateway contains the annotation `maistra.io/manageRoute: false`
then IOR ignores it and doesn't attempt to create or manage route(s) for
this Gateway.

Also, ignore Gateways with the annotation `istio: egressgateway` as
these are not meant to have routes.

* Add integration test for IOR

Signed-off-by: Jacek Ewertowski <jewertow@redhat.com>

* OSSM-1442: IOR: Ignore UPDATE events if resourceVersions are the same (maistra#516)

* OSSM-1442: IOR: Ignore UPDATE events if resourceVersions are the same

For some obscure reason, it looks like we may receive UPDATE events with
the new object being equal to the old one. As IOR always delete and
recreate routes when receiving an UPDATE event, this might lead to some
service downtime, given for a few moments the route will not exist.

We guard against this behavior by comparing the `resourceVersion` field
of the new object and the one stored in the Route object.

* Add test

Co-authored-by: Brian Avery <bavery@redhat.com>
Co-authored-by: Jonh Wendell <jonh.wendell@redhat.com>

Fix debug log formatting

OSSM-1800: Copy gateway labels to routes

Simplify the comparison of resource versions

We store the gateway resource version (the whole metadata actually) in the `syncRoute` object.
There's no need to loop over the routes to perform the comparison.

This also fix the corner case where the gateway has one host and for
some reason OCP rejects the creation of the route (e.g., when hostname is already
taken). In this case the `syncRoute` object exists with zero routes in
it. Thus the loop is a no-op and the function wrongly returns with an
error of `eventDuplicatedMessage`. By comparing directly using the
`syncRoute.metadata` we fix this.

OSSM-1105: Support namespace portion in gateway hostnames

They are not used by routes, so we essentially ignore the namespace part
- anything on the left side of a "namespace/hostname" string.

* [ior] MAISTRA-1400 Add IOR to Pilot

* [MAISTRA-1089][MAISTRA-1400][MAISTRA-1744][MAISTRA-1811]: Add IOR to Pilot (maistra#135) (maistra#240)

* MAISTRA-1400: Add IOR to Pilot (maistra#135)

* MAISTRA-1400: Add IOR to Pilot

* [MAISTRA-1744] Add route annotation propagation (maistra#158)

* MAISTRA-1811 Store resourceVersion of reconciled Gateway resource (maistra#190)

* MAISTRA-1089 Add support for IOR routes in all namespaces (maistra#193)

* MAISTRA-2131: ior: honor Gateway's httpsRedirect (maistra#276)

If Gateway's httpsRedirect is set to true, create the OpenShift Route
with Insecure Policy set to `Redirect`.

Manual cherrypick from maistra#269.

* MAISTRA-2149: Make IOR robust in multiple replicas (maistra#282)

In scenarios where multiple replicas of istiod are running,
only one IOR should be in charge of keeping routes in sync
with Istio Gateways. We achieve this by making sure IOR only
runs in the leader replica.

Also, because leader election is not 100% acurate, meaning
that for a small window of time there might be two instances
being the leader - which could lead to duplicated routes
being created if a new gateway is created in that time frame -
we also change the way the Route name is created: Instead of
having a generateName field, we now explicitly pass a name to
the Route object to be created. Being deterministic, it allows
the Route creation to fail when there's already a Route object
with the same name (created by the other leader in that time frame).

Use an exclusive leader ID for IOR

* Manual cherrypick of maistra#275

* MAISTRA-1813: Add unit tests for IOR (maistra#286)

* MAISTRA-2051 fixes for maistra install

* MAISTRA-2164: Refactor IOR internals (maistra#295)

Instead of doing lots of API calls on every event - this
does not scale well with lots of namespaces - keep the state
in memory, by doing an initial synchronization on start up and
updating it when receiving events.

The initial synchronization is more complex, as we have to deal with
asynchronous events (e.g., we have to wait for the Gateway store to
be warmed up). Once it's initialized, handling events as they arrive
becomes trivial.

Tests that make sure we do not make more calls to the API server than
the necessary were added, to avoid regressions.

* MAISTRA-2205: Add an option to opt-out for automatic route creation

If the Istio Gateway contains the annotation `maistra.io/manageRoute: false`
then IOR ignores it and doesn't attempt to create or manage route(s) for
this Gateway.

Also, ignore Gateways with the annotation `istio: egressgateway` as
these are not meant to have routes.

* Add integration test for IOR

Signed-off-by: Jacek Ewertowski <jewertow@redhat.com>

* OSSM-1442: IOR: Ignore UPDATE events if resourceVersions are the same (maistra#516)

* OSSM-1442: IOR: Ignore UPDATE events if resourceVersions are the same

For some obscure reason, it looks like we may receive UPDATE events with
the new object being equal to the old one. As IOR always delete and
recreate routes when receiving an UPDATE event, this might lead to some
service downtime, given for a few moments the route will not exist.

We guard against this behavior by comparing the `resourceVersion` field
of the new object and the one stored in the Route object.

* Add test

Co-authored-by: Brian Avery <bavery@redhat.com>
Co-authored-by: Jonh Wendell <jonh.wendell@redhat.com>

Fix debug log formatting

OSSM-1800: Copy gateway labels to routes

Simplify the comparison of resource versions

We store the gateway resource version (the whole metadata actually) in the `syncRoute` object.
There's no need to loop over the routes to perform the comparison.

This also fix the corner case where the gateway has one host and for
some reason OCP rejects the creation of the route (e.g., when hostname is already
taken). In this case the `syncRoute` object exists with zero routes in
it. Thus the loop is a no-op and the function wrongly returns with an
error of `eventDuplicatedMessage`. By comparing directly using the
`syncRoute.metadata` we fix this.

OSSM-1105: Support namespace portion in gateway hostnames

They are not used by routes, so we essentially ignore the namespace part
- anything on the left side of a "namespace/hostname" string.

* [ior] MAISTRA-1400 Add IOR to Pilot

* [MAISTRA-1089][MAISTRA-1400][MAISTRA-1744][MAISTRA-1811]: Add IOR to Pilot (maistra#135) (maistra#240)

* MAISTRA-1400: Add IOR to Pilot (maistra#135)

* MAISTRA-1400: Add IOR to Pilot

* [MAISTRA-1744] Add route annotation propagation (maistra#158)

* MAISTRA-1811 Store resourceVersion of reconciled Gateway resource (maistra#190)

* MAISTRA-1089 Add support for IOR routes in all namespaces (maistra#193)

* MAISTRA-2131: ior: honor Gateway's httpsRedirect (maistra#276)

If Gateway's httpsRedirect is set to true, create the OpenShift Route
with Insecure Policy set to `Redirect`.

Manual cherrypick from maistra#269.

* MAISTRA-2149: Make IOR robust in multiple replicas (maistra#282)

In scenarios where multiple replicas of istiod are running,
only one IOR should be in charge of keeping routes in sync
with Istio Gateways. We achieve this by making sure IOR only
runs in the leader replica.

Also, because leader election is not 100% acurate, meaning
that for a small window of time there might be two instances
being the leader - which could lead to duplicated routes
being created if a new gateway is created in that time frame -
we also change the way the Route name is created: Instead of
having a generateName field, we now explicitly pass a name to
the Route object to be created. Being deterministic, it allows
the Route creation to fail when there's already a Route object
with the same name (created by the other leader in that time frame).

Use an exclusive leader ID for IOR

* Manual cherrypick of maistra#275

* MAISTRA-1813: Add unit tests for IOR (maistra#286)

* MAISTRA-2051 fixes for maistra install

* MAISTRA-2164: Refactor IOR internals (maistra#295)

Instead of doing lots of API calls on every event - this
does not scale well with lots of namespaces - keep the state
in memory, by doing an initial synchronization on start up and
updating it when receiving events.

The initial synchronization is more complex, as we have to deal with
asynchronous events (e.g., we have to wait for the Gateway store to
be warmed up). Once it's initialized, handling events as they arrive
becomes trivial.

Tests that make sure we do not make more calls to the API server than
the necessary were added, to avoid regressions.

* MAISTRA-2205: Add an option to opt-out for automatic route creation

If the Istio Gateway contains the annotation `maistra.io/manageRoute: false`
then IOR ignores it and doesn't attempt to create or manage route(s) for
this Gateway.

Also, ignore Gateways with the annotation `istio: egressgateway` as
these are not meant to have routes.

* Add integration test for IOR

Signed-off-by: Jacek Ewertowski <jewertow@redhat.com>

* OSSM-1442: IOR: Ignore UPDATE events if resourceVersions are the same (maistra#516)

* OSSM-1442: IOR: Ignore UPDATE events if resourceVersions are the same

For some obscure reason, it looks like we may receive UPDATE events with
the new object being equal to the old one. As IOR always delete and
recreate routes when receiving an UPDATE event, this might lead to some
service downtime, given for a few moments the route will not exist.

We guard against this behavior by comparing the `resourceVersion` field
of the new object and the one stored in the Route object.

* Add test

Co-authored-by: Brian Avery <bavery@redhat.com>
Co-authored-by: Jonh Wendell <jonh.wendell@redhat.com>

Fix debug log formatting

OSSM-1800: Copy gateway labels to routes

Simplify the comparison of resource versions

We store the gateway resource version (the whole metadata actually) in the `syncRoute` object.
There's no need to loop over the routes to perform the comparison.

This also fix the corner case where the gateway has one host and for
some reason OCP rejects the creation of the route (e.g., when hostname is already
taken). In this case the `syncRoute` object exists with zero routes in
it. Thus the loop is a no-op and the function wrongly returns with an
error of `eventDuplicatedMessage`. By comparing directly using the
`syncRoute.metadata` we fix this.

OSSM-1105: Support namespace portion in gateway hostnames

They are not used by routes, so we essentially ignore the namespace part
- anything on the left side of a "namespace/hostname" string.

* [ior] MAISTRA-1400 Add IOR to Pilot

* [MAISTRA-1089][MAISTRA-1400][MAISTRA-1744][MAISTRA-1811]: Add IOR to Pilot (maistra#135) (maistra#240)

* MAISTRA-1400: Add IOR to Pilot (maistra#135)

* MAISTRA-1400: Add IOR to Pilot

* [MAISTRA-1744] Add route annotation propagation (maistra#158)

* MAISTRA-1811 Store resourceVersion of reconciled Gateway resource (maistra#190)

* MAISTRA-1089 Add support for IOR routes in all namespaces (maistra#193)

* MAISTRA-2131: ior: honor Gateway's httpsRedirect (maistra#276)

If Gateway's httpsRedirect is set to true, create the OpenShift Route
with Insecure Policy set to `Redirect`.

Manual cherrypick from maistra#269.

* MAISTRA-2149: Make IOR robust in multiple replicas (maistra#282)

In scenarios where multiple replicas of istiod are running,
only one IOR should be in charge of keeping routes in sync
with Istio Gateways. We achieve this by making sure IOR only
runs in the leader replica.

Also, because leader election is not 100% acurate, meaning
that for a small window of time there might be two instances
being the leader - which could lead to duplicated routes
being created if a new gateway is created in that time frame -
we also change the way the Route name is created: Instead of
having a generateName field, we now explicitly pass a name to
the Route object to be created. Being deterministic, it allows
the Route creation to fail when there's already a Route object
with the same name (created by the other leader in that time frame).

Use an exclusive leader ID for IOR

* Manual cherrypick of maistra#275

* MAISTRA-1813: Add unit tests for IOR (maistra#286)

* MAISTRA-2051 fixes for maistra install

* MAISTRA-2164: Refactor IOR internals (maistra#295)

Instead of doing lots of API calls on every event - this
does not scale well with lots of namespaces - keep the state
in memory, by doing an initial synchronization on start up and
updating it when receiving events.

The initial synchronization is more complex, as we have to deal with
asynchronous events (e.g., we have to wait for the Gateway store to
be warmed up). Once it's initialized, handling events as they arrive
becomes trivial.

Tests that make sure we do not make more calls to the API server than
the necessary were added, to avoid regressions.

* MAISTRA-2205: Add an option to opt-out for automatic route creation

If the Istio Gateway contains the annotation `maistra.io/manageRoute: false`
then IOR ignores it and doesn't attempt to create or manage route(s) for
this Gateway.

Also, ignore Gateways with the annotation `istio: egressgateway` as
these are not meant to have routes.

* Add integration test for IOR

Signed-off-by: Jacek Ewertowski <jewertow@redhat.com>

* OSSM-1442: IOR: Ignore UPDATE events if resourceVersions are the same (maistra#516)

* OSSM-1442: IOR: Ignore UPDATE events if resourceVersions are the same

For some obscure reason, it looks like we may receive UPDATE events with
the new object being equal to the old one. As IOR always delete and
recreate routes when receiving an UPDATE event, this might lead to some
service downtime, given for a few moments the route will not exist.

We guard against this behavior by comparing the `resourceVersion` field
of the new object and the one stored in the Route object.

* Add test

Co-authored-by: Brian Avery <bavery@redhat.com>
Co-authored-by: Jonh Wendell <jonh.wendell@redhat.com>

Fix debug log formatting

OSSM-1800: Copy gateway labels to routes

Simplify the comparison of resource versions

We store the gateway resource version (the whole metadata actually) in the `syncRoute` object.
There's no need to loop over the routes to perform the comparison.

This also fix the corner case where the gateway has one host and for
some reason OCP rejects the creation of the route (e.g., when hostname is already
taken). In this case the `syncRoute` object exists with zero routes in
it. Thus the loop is a no-op and the function wrongly returns with an
error of `eventDuplicatedMessage`. By comparing directly using the
`syncRoute.metadata` we fix this.

OSSM-1105: Support namespace portion in gateway hostnames

They are not used by routes, so we essentially ignore the namespace part
- anything on the left side of a "namespace/hostname" string.

* [ior] MAISTRA-1400 Add IOR to Pilot

* [MAISTRA-1089][MAISTRA-1400][MAISTRA-1744][MAISTRA-1811]: Add IOR to Pilot (maistra#135) (maistra#240)

* MAISTRA-1400: Add IOR to Pilot (maistra#135)

* MAISTRA-1400: Add IOR to Pilot

* [MAISTRA-1744] Add route annotation propagation (maistra#158)

* MAISTRA-1811 Store resourceVersion of reconciled Gateway resource (maistra#190)

* MAISTRA-1089 Add support for IOR routes in all namespaces (maistra#193)

* MAISTRA-2131: ior: honor Gateway's httpsRedirect (maistra#276)

If Gateway's httpsRedirect is set to true, create the OpenShift Route
with Insecure Policy set to `Redirect`.

Manual cherrypick from maistra#269.

* MAISTRA-2149: Make IOR robust in multiple replicas (maistra#282)

In scenarios where multiple replicas of istiod are running,
only one IOR should be in charge of keeping routes in sync
with Istio Gateways. We achieve this by making sure IOR only
runs in the leader replica.

Also, because leader election is not 100% acurate, meaning
that for a small window of time there might be two instances
being the leader - which could lead to duplicated routes
being created if a new gateway is created in that time frame -
we also change the way the Route name is created: Instead of
having a generateName field, we now explicitly pass a name to
the Route object to be created. Being deterministic, it allows
the Route creation to fail when there's already a Route object
with the same name (created by the other leader in that time frame).

Use an exclusive leader ID for IOR

* Manual cherrypick of maistra#275

* MAISTRA-1813: Add unit tests for IOR (maistra#286)

* MAISTRA-2051 fixes for maistra install

* MAISTRA-2164: Refactor IOR internals (maistra#295)

Instead of doing lots of API calls on every event - this
does not scale well with lots of namespaces - keep the state
in memory, by doing an initial synchronization on start up and
updating it when receiving events.

The initial synchronization is more complex, as we have to deal with
asynchronous events (e.g., we have to wait for the Gateway store to
be warmed up). Once it's initialized, handling events as they arrive
becomes trivial.

Tests that make sure we do not make more calls to the API server than
the necessary were added, to avoid regressions.

* MAISTRA-2205: Add an option to opt-out for automatic route creation

If the Istio Gateway contains the annotation `maistra.io/manageRoute: false`
then IOR ignores it and doesn't attempt to create or manage route(s) for
this Gateway.

Also, ignore Gateways with the annotation `istio: egressgateway` as
these are not meant to have routes.

* Add integration test for IOR

Signed-off-by: Jacek Ewertowski <jewertow@redhat.com>

* OSSM-1442: IOR: Ignore UPDATE events if resourceVersions are the same (maistra#516)

* OSSM-1442: IOR: Ignore UPDATE events if resourceVersions are the same

For some obscure reason, it looks like we may receive UPDATE events with
the new object being equal to the old one. As IOR always delete and
recreate routes when receiving an UPDATE event, this might lead to some
service downtime, given for a few moments the route will not exist.

We guard against this behavior by comparing the `resourceVersion` field
of the new object and the one stored in the Route object.

* Add test

Co-authored-by: Brian Avery <bavery@redhat.com>
Co-authored-by: Jonh Wendell <jonh.wendell@redhat.com>

Fix debug log formatting

OSSM-1800: Copy gateway labels to routes

Simplify the comparison of resource versions

We store the gateway resource version (the whole metadata actually) in the `syncRoute` object.
There's no need to loop over the routes to perform the comparison.

This also fix the corner case where the gateway has one host and for
some reason OCP rejects the creation of the route (e.g., when hostname is already
taken). In this case the `syncRoute` object exists with zero routes in
it. Thus the loop is a no-op and the function wrongly returns with an
error of `eventDuplicatedMessage`. By comparing directly using the
`syncRoute.metadata` we fix this.

OSSM-1105: Support namespace portion in gateway hostnames

They are not used by routes, so we essentially ignore the namespace part
- anything on the left side of a "namespace/hostname" string.

OSSM-1650 Make sure initialSync and event loop behave the same (maistra#551)

* [ior] MAISTRA-1400 Add IOR to Pilot

* [MAISTRA-1089][MAISTRA-1400][MAISTRA-1744][MAISTRA-1811]: Add IOR to Pilot (maistra#135) (maistra#240)

* MAISTRA-1400: Add IOR to Pilot (maistra#135)

* MAISTRA-1400: Add IOR to Pilot

* [MAISTRA-1744] Add route annotation propagation (maistra#158)

* MAISTRA-1811 Store resourceVersion of reconciled Gateway resource (maistra#190)

* MAISTRA-1089 Add support for IOR routes in all namespaces (maistra#193)

* MAISTRA-2131: ior: honor Gateway's httpsRedirect (maistra#276)

If Gateway's httpsRedirect is set to true, create the OpenShift Route
with Insecure Policy set to `Redirect`.

Manual cherrypick from maistra#269.

* MAISTRA-2149: Make IOR robust in multiple replicas (maistra#282)

In scenarios where multiple replicas of istiod are running,
only one IOR should be in charge of keeping routes in sync
with Istio Gateways. We achieve this by making sure IOR only
runs in the leader replica.

Also, because leader election is not 100% acurate, meaning
that for a small window of time there might be two instances
being the leader - which could lead to duplicated routes
being created if a new gateway is created in that time frame -
we also change the way the Route name is created: Instead of
having a generateName field, we now explicitly pass a name to
the Route object to be created. Being deterministic, it allows
the Route creation to fail when there's already a Route object
with the same name (created by the other leader in that time frame).

Use an exclusive leader ID for IOR

* Manual cherrypick of maistra#275

* MAISTRA-1813: Add unit tests for IOR (maistra#286)

* MAISTRA-2051 fixes for maistra install

* MAISTRA-2164: Refactor IOR internals (maistra#295)

Instead of doing lots of API calls on every event - this
does not scale well with lots of namespaces - keep the state
in memory, by doing an initial synchronization on start up and
updating it when receiving events.

The initial synchronization is more complex, as we have to deal with
asynchronous events (e.g., we have to wait for the Gateway store to
be warmed up). Once it's initialized, handling events as they arrive
becomes trivial.

Tests that make sure we do not make more calls to the API server than
the necessary were added, to avoid regressions.

* MAISTRA-2205: Add an option to opt-out for automatic route creation

If the Istio Gateway contains the annotation `maistra.io/manageRoute: false`
then IOR ignores it and doesn't attempt to create or manage route(s) for
this Gateway.

Also, ignore Gateways with the annotation `istio: egressgateway` as
these are not meant to have routes.

* Add integration test for IOR

Signed-off-by: Jacek Ewertowski <jewertow@redhat.com>

* OSSM-1442: IOR: Ignore UPDATE events if resourceVersions are the same (maistra#516)

* OSSM-1442: IOR: Ignore UPDATE events if resourceVersions are the same

For some obscure reason, it looks like we may receive UPDATE events with
the new object being equal to the old one. As IOR always delete and
recreate routes when receiving an UPDATE event, this might lead to some
service downtime, given for a few moments the route will not exist.

We guard against this behavior by comparing the `resourceVersion` field
of the new object and the one stored in the Route object.

* Add test

Co-authored-by: Brian Avery <bavery@redhat.com>
Co-authored-by: Jonh Wendell <jonh.wendell@redhat.com>

Fix debug log formatting

OSSM-1800: Copy gateway labels to routes

Simplify the comparison of resource versions

We store the gateway resource version (the whole metadata actually) in the `syncRoute` object.
There's no need to loop over the routes to perform the comparison.

This also fix the corner case where the gateway has one host and for
some reason OCP rejects the creation of the route (e.g., when hostname is already
taken). In this case the `syncRoute` object exists with zero routes in
it. Thus the loop is a no-op and the function wrongly returns with an
error of `eventDuplicatedMessage`. By comparing directly using the
`syncRoute.metadata` we fix this.

OSSM-1105: Support namespace portion in gateway hostnames

They are not used by routes, so we essentially ignore the namespace part
- anything on the left side of a "namespace/hostname" string.

OSSM-1650 Make sure initialSync and event loop behave the same (maistra#551)

* [ior] MAISTRA-1400 Add IOR to Pilot

* [MAISTRA-1089][MAISTRA-1400][MAISTRA-1744][MAISTRA-1811]: Add IOR to Pilot (#135) (#240)

* MAISTRA-1400: Add IOR to Pilot (#135)

* MAISTRA-1400: Add IOR to Pilot

* [MAISTRA-1744] Add route annotation propagation (#158)

* MAISTRA-1811 Store resourceVersion of reconciled Gateway resource (#190)

* MAISTRA-1089 Add support for IOR routes in all namespaces (#193)

* MAISTRA-2131: ior: honor Gateway's httpsRedirect (#276)

If Gateway's httpsRedirect is set to true, create the OpenShift Route
with Insecure Policy set to `Redirect`.

Manual cherrypick from #269.

* MAISTRA-2149: Make IOR robust in multiple replicas (#282)

In scenarios where multiple replicas of istiod are running,
only one IOR should be in charge of keeping routes in sync
with Istio Gateways. We achieve this by making sure IOR only
runs in the leader replica.

Also, because leader election is not 100% acurate, meaning
that for a small window of time there might be two instances
being the leader - which could lead to duplicated routes
being created if a new gateway is created in that time frame -
we also change the way the Route name is created: Instead of
having a generateName field, we now explicitly pass a name to
the Route object to be created. Being deterministic, it allows
the Route creation to fail when there's already a Route object
with the same name (created by the other leader in that time frame).

Use an exclusive leader ID for IOR

* Manual cherrypick of #275

* MAISTRA-1813: Add unit tests for IOR (#286)

* MAISTRA-2051 fixes for maistra install

* MAISTRA-2164: Refactor IOR internals (#295)

Instead of doing lots of API calls on every event - this
does not scale well with lots of namespaces - keep the state
in memory, by doing an initial synchronization on start up and
updating it when receiving events.

The initial synchronization is more complex, as we have to deal with
asynchronous events (e.g., we have to wait for the Gateway store to
be warmed up). Once it's initialized, handling events as they arrive
becomes trivial.

Tests that make sure we do not make more calls to the API server than
the necessary were added, to avoid regressions.

* MAISTRA-2205: Add an option to opt-out for automatic route creation

If the Istio Gateway contains the annotation `maistra.io/manageRoute: false`
then IOR ignores it and doesn't attempt to create or manage route(s) for
this Gateway.

Also, ignore Gateways with the annotation `istio: egressgateway` as
these are not meant to have routes.

* Add integration test for IOR

Signed-off-by: Jacek Ewertowski <jewertow@redhat.com>

* OSSM-1442: IOR: Ignore UPDATE events if resourceVersions are the same (#516)

* OSSM-1442: IOR: Ignore UPDATE events if resourceVersions are the same

For some obscure reason, it looks like we may receive UPDATE events with
the new object being equal to the old one. As IOR always delete and
recreate routes when receiving an UPDATE event, this might lead to some
service downtime, given for a few moments the route will not exist.

We guard against this behavior by comparing the `resourceVersion` field
of the new object and the one stored in the Route object.

* Add test

Co-authored-by: Brian Avery <bavery@redhat.com>
Co-authored-by: Jonh Wendell <jonh.wendell@redhat.com>

Fix debug log formatting

OSSM-1800: Copy gateway labels to routes

Simplify the comparison of resource versions

We store the gateway resource version (the whole metadata actually) in the `syncRoute` object.
There's no need to loop over the routes to perform the comparison.

This also fix the corner case where the gateway has one host and for
some reason OCP rejects the creation of the route (e.g., when hostname is already
taken). In this case the `syncRoute` object exists with zero routes in
it. Thus the loop is a no-op and the function wrongly returns with an
error of `eventDuplicatedMessage`. By comparing directly using the
`syncRoute.metadata` we fix this.

OSSM-1105: Support namespace portion in gateway hostnames

They are not used by routes, so we essentially ignore the namespace part
- anything on the left side of a "namespace/hostname" string.

OSSM-1650 Make sure initialSync and event loop behave the same (#551)