topic Re: It seems that R80.10 VSec doesn't support openstack higher than Mitaka (due the placement API) in Cloud Firewall

It seems that R80.10 VSec doesn't support openstack higher than Mitaka (due the placement API)

Andrea_Francesc — Tue, 29 May 2018 18:06:42 GMT

Starting with OCATA placement API have become mandatory in every Openstack deployment.

Unfortunately it seems that CheckPoint integration with openstack get confused with this new endpoint.

In fact before placement there was only a service-type under nova, that was compute.:

#openstack endpoint list | grep nova
| 8413db31b008469ea0ebd3529b07078d | RegionOne | nova | compute | True | public | http://x.y.z.w:8774/v2.1 |
| ea733c09627c4a1f8bc9a9c90c6099e5 | RegionOne | nova | compute | True | admin | http://x.y.z.w:8774/v2.1 |
| fd12c313db914695a63f730330fedbf4 | RegionOne | nova | compute | True | internal | http://x.y.z.w:8774/v2.1 |

With the addition of placement service, now, when you ask for nova endpoints, you get 'compute' and 'placement'.


#openstack endpoint list | grep nova
| 3248904d9d2b4983a9f1b30fda68c9b2 | RegionOne | nova | placement | True | admin | http://x.y.z.w:8778/ |
| 3ba077c236b14d9fbb18e2cbe2fd61fd | RegionOne | nova | placement | True | internal | http://x.y.z.w:8778/ |
| 6539258c683146e8bc80a924c7a00d0a | RegionOne | nova | placement | True | public | http://x.y.z.w:8778/ |
| 8413db31b008469ea0ebd3529b07078d | RegionOne | nova | compute | True | public | http://x.y.z.w:8774/v2.1 |
| ea733c09627c4a1f8bc9a9c90c6099e5 | RegionOne | nova | compute | True | admin | http://x.y.x.w:8774/v2.1 |
| fd12c313db914695a63f730330fedbf4 | RegionOne | nova | compute | True | internal | http://x.y.z.w:8774/v2.1 |

When you try to get items from the datacenter objects VSec incorrectly tries to ask for 'servers/list' to the placement api instead of the compute api, getting a 404.

Removing the placement endpoints fixes the problem but leaves openstack in unusable state.

Apparently this is due to the code inside "openstack_plugin.jar", specifically the ServiceType.class which defines:

public enum ServiceType
{
 IDENTITY("keystone", "identity"), COMPUTE("nova", "compute"), IMAGE("glance", "image"), BLOCK_STORAGE("cinder", "volume"), OBJECT_STORAGE("object-store", "object-store"), NETWORK("neutron", "network"), EC2("ec2", "ec2"), TELEMETRY("ceilometer", "metering"), ORCHESTRATION("heat", "orchestration"), SAHARA("sahara", "data_processing"), UNKNOWN("NA", "NA");
...

which doesn't handle the ambiguity of nova/compute vs nova/placement.

Sometimes, depending on the order the service catalog is returned, it succeded to get the correct endpoint.

Does anyone know if there's a solution for this?

Thanks.

Andrea

Re: It seems that R80.10 VSec doesn't support openstack higher than Mitaka (due the placement API)

PhoneBoy — Fri, 01 Jun 2018 19:29:57 GMT

Just a guess, but I suspect we'll have to fix the CloudGuard Controller to support this new endpoint.

Will check.

Re: It seems that R80.10 VSec doesn't support openstack higher than Mitaka (due the placement API)

Merav_Sapir — Sun, 03 Jun 2018 09:49:45 GMT

Assuming you are referring to the changes in Keystone API version -

Currently CloudGuard controller supports only v2. In the next JHF over R80.10 (not yet released), OpenStack v2 and v3 will be supported.

Re: It seems that R80.10 VSec doesn't support openstack higher than Mitaka (due the placement API)

Andrea_Francesc — Fri, 08 Jun 2018 11:45:13 GMT

Hello Merav,

thank you for your answer, but I believe that the point is not the support for keystone v2 or v3 rather that the controller does not handle the fact that under nova (> ocata) two endpoints (compute and placement) could be found instead of the one (compute) that used to be in past versions and it routes the request incorrectly.

We implemented a workaround in haproxy to fix this.

Everytime a request comes for placement api from checkpoint we assume that it was intended for compute, thus we send it to the correct endpoint.

Like this:

frontend nova_api_placement-front
   bind x.y.z.w:8778
   option httplog
   option forwardfor except 127.0.0.0/8
   option http-server-close
   timeout client 600s
   acl checkpoint src a.b.c.d
   reqrep ^([^\ :]*)\ /(.*) \1\ /v2.1/\2 if checkpoint
   use_backend nova_api_os_compute-back if checkpoint
   mode http
   default_backend nova_api_placement-back

When the request comes from checkpoint it matches the acl and we rewrite the url (adding /v2.1 ) and use the compute backend instead of the default placement.

This way works.

Bye,

Andrea