exoscale / python-exoscale

Python bindings for the Exoscale APIs
https://exoscale.github.io/python-exoscale/
ISC License
14 stars 7 forks source link

Creating compute instance with security group generates error messags #48

Closed philipp-weiss closed 5 months ago

philipp-weiss commented 1 year ago

Hi everyone,

I am getting multiple error messages when I try to create an instance with a security group. I created the security group beforehand on the web interface.

from exoscale.api.v2 import Client

client_key = '...'
client_secret = '...'
zone = 'de-fra-1'

client = Client(client_key, client_secret, zone=zone)

name = 'testname'
standard_micro_instance_id = '71004023-bb72-4a97-b1e9-bc66dfce9470'
instance_type = client.get_instance_type(id=standard_micro_instance_id)

ubuntu_22_04_image_id = '67756dc3-a1de-4abd-abcf-843ef9223bb6'
template = client.get_template(id=ubuntu_22_04_image_id)

security_group_id = '59378c27-c232-4079-9e18-dd68b2c75011'
security_group = client.get_security_group(id=security_group_id)

ssh_key = {'name': 'TESTKEYPAIR'}

server = client.create_instance(name=name, ssh_key=ssh_key, instance_type=instance_type, template=template, public_ip_assignment='inet4', disk_size=10, security_groups=[security_group])

print(security_group)
print(server)

Output:

Security group: {'id': '59378c27-c232-4079-9e18-dd68b2c75011', 'name': 'test', 'description': '', 'visibility': 'private', 'rules': [{'id': '845f79b6-1e5c-4613-a59d-f3a36cbb16cc', 'protocol': 'tcp', 'flow-direction': 'ingress', 'description': 'SSH', 'network': '0.0.0.0/0', 'start-port': 22, 'end-port': 22}]}

Server: {'errors': [{'in': [2, 'exoscale.entity.instance/security-groups', 0, 'exoscale.entity.security-group/visibility'], 'path': 'security-groups[0].visibility', 'message': 'should be one of :private, :public'}, {'in': [2, 'exoscale.entity.instance/security-groups', 0, 'exoscale.entity.security-group/rules', 0], 'path': 'security-groups[0].rules[0]', 'message': "null OR missing keys 'flow-direction', 'protocol'"}, {'in': [2, 'exoscale.entity.instance/security-groups'], 'path': 'security-groups', 'message': 'should be nil'}], 'message': "Invalid value in security-groups[0].visibility - should be one of :private, :public\nInvalid value in security-groups[0].rules[0] - null OR missing keys 'flow-direction', 'protocol'\nInvalid value in security-groups - should be nil\n"}

Any idea what the problem is?

brutasse commented 1 year ago

Hi @philipp-weiss,

When passing related resources, only the resource identifier (usually, the UUID and when there is none, the name) is needed to identify the resource. You can directly pass your security group using its id (same for your other related resources if you know them by their ID):

security_group = {"id": "59378c27-c232-4079-9e18-dd68b2c75011"}
server = client.create_instance(name=name, ssh_key=ssh_key, instance_type=instance_type, template=template, public_ip_assignment='inet4', disk_size=10, security_groups=[security_group])

This is the API denying a richer representation of the security group, but there's no reason your code shouldn't work as-is. We'll have a look, keeping this open in the meantime.

philipp-weiss commented 1 year ago

Hi @brutasse,

thank you for the quick reply. It works perfectly fine using just the IDs. It would be great if you could add some documentation as this did not become quite clear from the V2 API reference.

brutasse commented 5 months ago

@philipp-weiss I'm closing this given that this particular client interface has been deprecated, but this is on our radar for the newer client as well.

disenchant commented 2 months ago

@brutasse unfortunately this issue still seems to be present in the current 0.9.1 version of the library. Your proposed workaround of limiting the map to just the id key still works but would be nice if the security groups gathered e.g. with get_security_group could directly be used without stripping information from it first.

brutasse commented 2 months ago

@disenchant yes, absolutely - this is more an inconsistency between our API specs and the API handlers. I would prefer this to be addressed outside of client libraries, and I wanted to confirm that this is on our radar.