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

[Andrea_Francesc]

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

[PhoneBoy]

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

Will check.

[Merav_Sapir]

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.

[Andrea_Francesc]

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