Hi Dan, Thanks for your feedback! Replies inline.
From: Dan Wendlandt [mailto:d...@nicira.com] Sent: 20 October 2011 03:40 To: Salvatore Orlando Cc: netstack@lists.launchpad.net Subject: Re: [Netstack] Wiki page for operational status in Quantum API On Wed, Oct 19, 2011 at 4:19 AM, Salvatore Orlando <salvatore.orla...@eu.citrix.com<mailto:salvatore.orla...@eu.citrix.com>> wrote: Hi fellow netstackers, As agreed during yesterday's meeting, here's a wiki page with the specification for the operational status support in the API: http://wiki.openstack.org/QuantumOpStatus Great write-up Salvatore! A couple comments/questions: - would another way of saying "Failures in Quantum Networks" be "failures in implementing the logical Quantum network on the switching infrastructure managed by the Quantum plugin"? I usually think of the term "Quantum network" as referring to a logical entity, which itself cannot fail. May just be a slightly different mental model. You're right. I'll fix the wording on the sentence. - "Some plugins can immediately return with an error code". Can you elaborate on this? I would have thought that a plugin would always accept and perform any legal modification to the logical model. The plugin's ability to actually implement the logical model would be exposed ONLY via the operational status. How does this compare to your thinking? I think you point in bold is something we definitely agree on, so I don't think we can be that far apart :) I think that what I wrote is not exactly what I meant. Yes the plugin definitely accepts and performs any legal modification to the logical model. Then when they propagate this change to the physical/virtual switching layer, there might be errors, which cause the 'running' configuration to be different from the 'logical' one. The operational status is the only way in which this situation is exposed to users. - I don't totally follow the diagram, though I'm not sure that is critical :) I agree with all of the text, I'm just not sure I understand all of the boxes and arrows. I would have expected the boxes on the right side to be something that is contained within the plugin, not as a separate element. I wanted to capture the difference between the logical and physical set of objects. The box for the plugin should contain the logical model as well, as you pointed out. - The question of what enums to expose is interesting. At the most simple level, all the user cares about is "UP" or "DOWN". I can think of two reasons we may want to do more: 1) The system believes the current state to be transient, and thus wants to let the user know that a change without user action is expect. This seems to be the goal with something like "PROVISIONING". 2) The system believes the user may be able to do something to fix the problem. For example, the attachment-id is not found, so perhaps the user needs to correct the attachment-id, or make sure the VM with that attachment-id is actually running. I'm not sure I understand difference between "DOWN" and "FAILED". Thinking through various plugin scenarios, I think in practice it could be hard to know when to use one versus the other as a developer. Similarly, I'm not sure how the user interprets either field differently. One might try to have both a general "error" state and more specific error states like "attachment-id" not found, but even that can get tricky as it may be that an attachment-id is not found because the plugin's connection to the switch is down, not because the attachment-id actually doesn't exist. In my opinion a case for "DOWN" would be a port without an attachment (or with a wrong attachment); on the other hand, a case for FAILED would be the failure of a physical switch in the network or an hypervisor. I don't have very strong opinion on the set of possible operational states. IMHO, having just UP and DOWN is fine for a start. We can probably start with them and then see in course of action if we might want something more. - I had been thinking about a detailed operational status string as well. It definitely seems to be information the service provider would want for troubleshooting. The tricky thing is that I'm not sure such a plugin-specific value belongs in a logical API. For example, would a provider want to broadcast to tenants that it is using plugin X or plugin Y? Maybe we should expose this in a different way that makes it easier to have it be part of an admin API but not the tenant API? That's a good point. Unfortunately I cannot thing of a detailed operational status info which would not be plugin-specific, meaning that different plugins can generate different strings. If this information is needed by the service provider only, than it makes sense to move it into an Admin API (on this note, are we planning to do some work on it?); similarly to the operational status enum, we can say that we will not have a detailed status string in the API; if then in course of action we find a use case for it, we will add it. Again, great work on this write-up! Regards, Salvatore -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net<mailto:netstack@lists.launchpad.net> Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira Networks, Inc. www.nicira.com<http://www.nicira.com> | www.openvswitch.org<http://www.openvswitch.org> Sr. Product Manager cell: 650-906-2650 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
