On Wed, Oct 19, 2011 at 4:19 AM, Salvatore Orlando < 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. - "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 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. - 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. - 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? Again, great work on this write-up! **** > > ** ** > > Regards,**** > > Salvatore**** > > -- > Mailing list: https://launchpad.net/~netstack > Post to : netstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~netstack > More help : https://help.launchpad.net/ListHelp > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira Networks, Inc. www.nicira.com | 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
