On Thu, Oct 20, 2011 at 9:21 AM, Sumit Naiksatam (snaiksat) < snaik...@cisco.com> wrote:
> Hi Salv, Echo Dan’s suggestions and comments, great write-up.**** > > ** ** > > Just a general comment (& this is a nit) – “Examples of situations in which > a resource might not be operative include faults, insufficient capabilities > in the physical or virtual switching layer, or simply, in the case of ports, > the fact that there's no attachment plugged into it (i.e.: link down).”*** > * > > ** ** > > How about we add the example of the resource being currently provisioned, > that to me seems to be the predominant use case for providing this status. > > **** > > ** ** > > On a slightly different note, there was also a suggestion to have a label > or tag per resource. Are we still planning to have that? It will be helpful > to have that attribute. > I think this would be a valuable capability. Want to work on that Sumit? It would be great to get others helping out Salvatore on API-related tasks, as his plate is always more than overflowing :) Dan > **** > > ** ** > > Thanks,**** > > ~Sumit. **** > > ** ** > > *From:* netstack-bounces+snaiksat=cisco....@lists.launchpad.net [mailto: > netstack-bounces+snaiksat=cisco....@lists.launchpad.net] *On Behalf Of > *Salvatore > Orlando > *Sent:* Thursday, October 20, 2011 2:49 AM > *To:* Dan Wendlandt > > *Cc:* netstack@lists.launchpad.net > *Subject:* Re: [Netstack] Wiki page for operational status in Quantum API* > *** > > ** ** > > 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> 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 > 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 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~**** > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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
