On Thu, Oct 20, 2011 at 9:45 AM, Dan Wendlandt <d...@nicira.com> wrote:
>
>
> On Thu, Oct 20, 2011 at 2:48 AM, Salvatore Orlando <
> salvatore.orla...@eu.citrix.com> wrote:
>>
>> ** **
>>
>> - 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.
>>
>
>
> Awesome, sounds like we're very much on the same page.
>
> And just to be clear, I'm fine with there being more states than UP and
> DOWN if people want. My goal is just to make sure that they have very
> clear meanings for both the user. The example of distinguishing between a
> port that has no attachment and one that has an attachment that was unable
> to be wired is one such example.
>
> Dan
>
Reviving this thread as we're actually reviewing this patch right now. The
only big question left in my mind after the first round of reviews is what
set of "states" we should support. The thread above arrived at just "UP"
and "DOWN". Adding "UNKNOWN" for plugins that do not implement the
interface, as discussed during a previous meeting, makes sense.
I think we agree that the primary goal of operational status is to
communicate whether a quantum port is "live" (i.e., has something attached
that is capable of sending and receiving packets). My basic physical
world analog is the port link light on a switch. "UP" and "DOWN" seems
sufficient for this, though in some cases physical switches may expose
different error states with different colors. For starters, I think I'll
probably stick to UP/DOWN when implementing operational status for the OVS
plugin, but I think its fine to leave the PROVISIONING state in for other
plugins where it may be more relevant. I assume there is no requirement
that a plugin expose a "PROVISIONING" state if it is not relevant to the
plugin?
Also, if a port's admin state is "DOWN", is its operational status always
"DOWN" as a result, or could it be "UP"? Reaching back to the physical
switch analogy, I believe if a switch port is admin down the link status
will always be down. People who deal with physical switches more than me
should feel free to correct me :)
Relevant code from the patch is below.
Thanks again for the patch!
Dan
30 class OperationalStatus: 31 """ Enumeration for operational status
32 33 UP : the resource is available (operationall up) 34
DOWN : the resource is not operational; this might indicate 35
a failure in the underlying switching fabric. 36
PROVISIONING: the plugin is creating or updating the resource 37
in the underlying switching fabric 38 UNKNOWN: the
plugin does not support the operational status concept. 39 """ 40
UP = "UP" 41 DOWN = "DOWN" 42 PROVISIONING = "PROVISIONING" 43
UNKNOWN = "UNKNOWN"
>
> ****
>>
>> 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
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira Networks: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp
