[
https://issues.apache.org/jira/browse/DTACLOUD-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13484794#comment-13484794
]
Marios Andreou commented on DTACLOUD-351:
-----------------------------------------
Hi Dies:
First off, thanks for your patience - I know you are keen to get this resolved.
As we discussed, the API returns 204 after a succesful DELETE firewall
operation, but this status code would be misleading since there is no guarantee
that the op *was* succesful/completed. I don't like the Thread.new mainly
because of this uncertainty... a new Thread is started and there is no way to
know how it ends.. succesfully (i.e. client.destroy_vsys succeeds) or not.
However, I don't know how else we could handle this situation.
One alternative I thought of was to handle the client.destroy_vsys in the call
to GET /api/firewalls.
1. The 'delete firewall' operation just makes the call to client.stop_efm(fw_id)
2. When client requests list (or even a single) firewall, don't display any
firewalls that have a state other than 'running' (or whatever the equivalent is
in fgcp).
3. Any firewalls that are in that 'stopped' state should be deleted with the
client.destroy_vsys
But this is also problematic for at least 2 reasons: in step 1 above you'd
return a 204 but the firewall isn't actually 'deleted' - only stopped, AND,
there is no guarantee that clients will 'refresh' and call GET /api/firewalls
in order to actually destroy firewalls that are just sitting there in the
'stopped' state.
So, my suggestion is perhaps a combination of the two:
1. keep your thread.new.
2. return a 202 from delete firewall - as this more accurately portrays what is
happening. Document this difference (notes for specific drivers and perhaps
also under the delete /api/firewalls call).
3. When listing firewalls, try and destroy any that are in the stopped state as
an added guard against the destroy failing in the Thread.new of the delete
firewall method.
what do you think?
marios
> fgcp: serverType for FWs changed to 'firewall' which is not in server type
> list
> -------------------------------------------------------------------------------
>
> Key: DTACLOUD-351
> URL: https://issues.apache.org/jira/browse/DTACLOUD-351
> Project: DeltaCloud
> Issue Type: Bug
> Components: Server
> Environment: fgcp
> Reporter: Dies Koper
> Assignee: Marios Andreou
> Attachments: 0001-fgcp-take-fw-out-of-instance-list.patch
>
>
> fgcp API changed: it now returns 'firewall' for FWs, which is not listed in
> server type list.
> This causes issues for cimi /machines API which cross-references with
> hardware_profiles output.
> Better to remove FW instances from instance list altogether.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
