Hi Salvatore/Dan, Yes, we can take a look a this. Salvatore we will sync
with you on a separate thread on how to go about it.

 

Thanks,

~Sumit.

 

From: Salvatore Orlando [mailto:salvatore.orla...@eu.citrix.com] 
Sent: Thursday, October 20, 2011 10:22 AM
To: Sumit Naiksatam (snaiksat); Dan Wendlandt
Cc: netstack@lists.launchpad.net
Subject: RE: [Netstack] Wiki page for operational status in Quantum API

 

Re label/tags: yes, I remember that, and I think it would be quite
useful as well.

Nevertheless, this wiki page was just for the operational status work
item. 

 

Sumit, do you reckon you or somebody else on your team might have some
spare cycles to spend on tags/labels?

 

Regards,

Salvatore

 

From: Sumit Naiksatam (snaiksat) [mailto:snaik...@cisco.com] 
Sent: 20 October 2011 17:22
To: Salvatore Orlando; Dan Wendlandt
Cc: netstack@lists.launchpad.net
Subject: RE: [Netstack] Wiki page for operational status in Quantum API

 

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.

 

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
~~~~~~~~~~~~~~~~~~~~~~~~~~~

-- 
Mailing list: https://launchpad.net/~netstack
Post to     : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstack
More help   : https://help.launchpad.net/ListHelp

Reply via email to