On Tue, Aug 9, 2011 at 1:41 AM, Salvatore Orlando <
salvatore.orla...@eu.citrix.com> wrote:

> Hi Dan, ****
>
> ** **
>
> Let’s finalize a decision on the target API version in today’s meeting. **
> **
>
> As we’re quite close to a major deadline, I’d focus more on delivering
> what’s been previously agreed on rather than on discussing enhancements,
> even if rather important.
>

Definitely agree.


> ****
>
> ** **
>
> In order to get to the bottom of our differences, let me ask you a simple
> question:****
>
> ** **
>
> We are writing a client application for quantum. The client at a certain
> point creates a resource, say a network.****
>
> The client then will create a bunch of port on this network. ****
>
> Will it execute the “create port” operation immediately after creating the
> network, or will it wait for the network to be “operationally ready” and
> then submit the “port create” operations?
>

Yes, I was thinking that the client would be able to create the ports
immediately.  Of course, the client could always choose to poll until the
network was "operationally ready" before creating the ports if it wanted to,
since this operational status would be exposed via the API.

Replies inline, but all of them are affirmative, so fingers crossed, I think
we're pretty close.

Dan


> ****
>
> ** **
>
> I also have a few comments inline.****
>
> ** **
>
> Cheers,****
>
> Salvatore****
>
> ** **
>
> *From:* Dan Wendlandt [mailto:d...@nicira.com]
> *Sent:* 09 August 2011 01:21
>
> *To:* Salvatore Orlando
> *Cc:* netstack@lists.launchpad.net
> *Subject:* Re: [Netstack] Quantum API resource status proposal****
>
> ** **
>
> Hi Salvatore, I think we're getting close :)****
>
> ** **
>
> As you mentioned in the bug, I agree that the "status" attributes are not
> critical for the v1.0 API, so delaying them until 1.1 so we can make sure
> we're on the same page seems like a good decision.  ****
>
> ** **
>
> Some comments inline,****
>
> ** **
>
> Dan****
>
> On Mon, Aug 8, 2011 at 3:29 PM, Salvatore Orlando <
> salvatore.orla...@eu.citrix.com> wrote:****
>
> Hi Dan, ****
>
> Thanks for your comments.****
>
>  ****
>
> I have a few replies inline.****
>
> I hope in tomorrow’s meeting we can at least finalize a decision on whether
> we want or not some form of “state” concept in API 1.0.****
>
>  ****
>
> Salvatore****
>
>  ****
>
> *From:* Dan Wendlandt [mailto:d...@nicira.com]
> *Sent:* 08 August 2011 20:00****
>
>
> *To:* Salvatore Orlando
> *Cc:* netstack@lists.launchpad.net
> *Subject:* Re: [Netstack] Quantum API resource status proposal****
>
>  ****
>
> Thanks for the explanation Salvatore, very helpful to understand where you
> are coming from.****
>
>  ****
>
> I think we're approaching this from slightly different angles, but aren't
> too far off.  My thinking was that most (all?) plugins will operate in a way
> that they store the data resulting from a web service call before returning
> (e.g., receive the call, update the database, return).  The corresponding
> "wiring" work to configure switch could then likely happen asynchronously.
>   ****
>
>  ****
>
> Agreed.****
>
>  ****
>
> This model gives you the nice properties that once I've done a create, I
> can always use the identifiers returned in the create response in subsequent
> calls without having to do any polling.  I wonder if it is possible that we
> instead just say that the API should not return an identifier from a create
> call until it is ready to accept subsequent calls using the returned
> identifier (note: this says nothing about whether that functionality is
> "wired", which may happen asynchronously, just whether the existence of an
> API object has been stored).  It seems like a plugin should be able to store
> and return the data with minimal effort, but perhaps I'm missing a scenario
> where this wouldn't be the case.  ****
>
>  ****
>
> It looks like you are separating “API objects”, which are stored by the
> plugin upon API calls, from “wired objects”, which are the actual bits
> configured for making virtual networks work. I totally agree on this
> separation.****
>
> ** **
>
> ** **
>
> Yes, that is correct.  Let's use that terminology to stay consistent. I
> think of there being a set of logical "API objects", which can be modified
> by the client at any point.  The plugin in then responsible for mapping the
> configuration described in the "API objects" to actual "wired objects",
> which it may do asynchronously.  The client should always be able to check
> on whether the plugin has completed the task of mapping the "API object" to
> the "wired object" (in my previous email I think we were referring to this
> as "link status" or "operational status").  ****
>
> ** **
>
> Right. So we definitely agree that we need a concept of “OPERATIONAL
> STATUS” which is attached to the “API OBJECT”. Client applications always
> deal with “API OBJECTS”, and are not even aware of “WIRED OBJECTS”. The
> notion of operational status allows client applications to understand
> whether the “WIRED OBJECTS(s)” mapped to a given API OBJECT are in status
> that can be operated on.
>

yes, I think we're on the same page.  operational status indicates whether
actual forwarding of packets is inline with the connectivity described by
the API model.


>  ****
>
>  ****
>
> However, it also seems to me that in your view the API should be happy to
> operate as long as an “API object” exists regardless of whether the
> corresponding “wired object” has been created or not. ****
>
> For instance let’s imagine we want to do the following operations: ****
>
> 1.       Create port on network****
>
> 2.       Plug interface****
>
>  ****
>
> The client first executes the first operation. The plugin creates the API
> object, returns it to the caller; “wired” objects creation could still be in
> progress, but the API object is there; the client is therefore able to run
> the second operation. ****
>
>  ****
>
> I think this would simplify clients, ****
>
>  ****
>
> This would indeed simplify a lot the client, because the concept of state
> provisioning would be totally superfluous. If the client has an API object
> identifier, it can operate on it; simple as that. ****
>
> However, we also have to ask ourselves whether this model is simple or
> simplistic. Can we always assume that a client can operate without knowing
> anything about whether the “wired objects” have been created or not?****
>
> ** **
>
> I definitely didn't mean to imply that.  ****
>
> ** **
>
> Sorry about that. I must have misunderstood your previous email.
>

No worries.  Getting consistent terminology is always the hardest part :)


> ****
>
> ** **
>
> I agree that the client should be able to know whether the underlying
> "wired objects" have been created (e.g., via an exposed "operational status"
> as described above), I just don't think that the status of the "wired
> object" should affect whether you can operation on the "API object".  ****
>
>  ****
>
>  ****
>
> Let’s imagine the provisioning process for operation #1 takes a long time.
> The API returns the port identifier to the client, which then invokes the
> operation for plugging the interface. ****
>
> At this stage the “wired” port object is not yet ready, but the API object
> is there in the DB. ****
>
> From what I’ve seen in this thread it seems we are considering the
> following options:****
>
> 1.       The API object has a notion of “state”, which reflect the state
> of the underlying wired object. If the wired object (port in this case), has
> not yet been created, the state for the API object will be “BUILDING”,
> “PROVISIONING”, “INPROGRESS”, or something like that. This would be what I
> was proposing to do with the “resource status” proposal****
>
> 2.       The API object is updated regardless of the state of the
> underlying “wired” object(s). The actual success/completion of the “Plug”
> operation will be reported by the “Logical status” associated with the port;
> for instance while the wired objects are being created, the status will be
> “DOWN”.****
>
> I think what I was shooting for was some kind of mix of #1 and #2:  "API
> objects" can be updated regardless of the underlying "wired objects", but a
> "resource status" always tells you if there is a difference between the
> connectivity described by the "API object" and the reality of packet
> forwarding done in the "wired object".  ****
>
> ** **
>
> I like this dualism. The model described by the API objects is an ideal
> world, more like a diagram on the whiteboard, where everything works
> magically. Wired objects instead represent the “ugly” real world, where
> things take time to complete, and failures tend to occur. Resource status is
> the thing that warns of a delta between the API object model and the wired
> object model. This reminds me a bit configuration management systems J
>

That's a great description of what I was thinking.  Exactly right.



> ****
>
>
> Is it possible that the "resource status" described in your #1 is similar
> to the "operational status" I described above?  I tend to see the "resource
> status" as being either "up" or "down", with down having a variety of
> explanations why things are "down" if (e.g., building,
> interface-id-not-found, internal-error, resources-not-available, etc.)  **
> **
>
> ** **
>
> Yes, it is. We already clarified this in a previous post on this thread.
> And this is also not very dissimilar from the concept of “server status” in
> nova. Atlas-LB too has a very similar concept for LB server provisioning.*
> ***
>
> ** **
>
> This sounds pretty similar to what you're talking about with #1, so I'm
> hoping we're thinking close to the same thing.  :)****
>
> ** **
>
> Hopefully yes!
>

Great!




> ****
>
> ** **
>
>  ****
>
> 3.       Don’t care about the state of the “wired” object. If the API
> object is there, operate on it; the plugin will take care of the rest and
> the client is supposed to be unaware of what the plugin does behind the
> covers.****
>
> ** **
>
> Definitely agree that this is not the way to go :) ****
>
> ** **
>
> Good. We can definitely discard this option (which is what the current API
> does J )****
>
>  ****
>
>  ****
>
> I’m in favour of approach #1, and I see it as a generalization of approach
> #2, as it doesn’t seem to me that the concept of logical status for a port
> clashes with the concept of provisioning state. I’m not in favour of
> approach #3, as I reckon the client wants to (and deserves to J) know
> whether the actual “wired object” have been created and are working as
> expected.****
>
>  ****
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 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

Reply via email to