search

jkoelker / quark

This is my fork, Quark is now at https://github.com/rackerlabs/quark
Apache License 2.0
0 stars 2 forks source link

What if quark port delete had varying levels of success? #102

Closed MattDietz closed 9 years ago

MattDietz commented 11 years ago

Currently, deleting a port in quark succeeds regardless of whether or not the call to the backend succeeds. The problem is the delete call still responds with failure. Meanwhile, a list for ports shows the port in question is now removed.

Instead of simply calling this a bug and re-adding the port, what if we set a secret state field in the database that could designate a port as being "deleted" but not removed from the backend yet?

asadoughi commented 11 years ago

Are we talking a similar field to that of the deallocated fields of MAC addresses and IP addresses? I think we already need to re-factor those implementations so I'm against adding more state to the port in a similar fashion until we come up with a cleaner, less bug-prone way to implement it.

MattDietz commented 11 years ago

I'm open to suggestions, though what's the bug prone bit now?

asadoughi commented 11 years ago

There are multiple ways to allocate/deallocate an ip from a port and covering all the cases has been a path of trial-and-error. I haven't had a chance to reflect on a possible, better implementation.

MattDietz commented 11 years ago

Ahh, yeah, ok. That makes sense. This was more of an open question. We need an issue tag for "hypotheticals and rhetoric" I guess.