Thanks Dan. I am pretty much in line with your thinking.
From: Dan Wendlandt [mailto:d...@nicira.com] Sent: Monday, September 19, 2011 1:03 PM To: Sumit Naiksatam (snaiksat) Cc: Salvatore Orlando; Ram Durairaj (radurair); netstack@lists.launchpad.net Subject: Re: [Netstack] Proposing sessions for Openstack design summitq Hi Sumit, I definitely agree with there being different levels of roll-back. I'm curious, does this match your thinking? - rollback within the plugin: if a plugin is unable to achieve a configuration specified by the logical model, it may choose to roll back one or more steps of the virtual/physical switch configuration it performed. However, the plugin does not rollback the actual logical model. Instead, the plugin exposes the fact that the logical configuration could not be achieved by showing an error value for the "operational status" of a network or port (inline with previous discussions about async APIs). - rollback of logical operations: an entity driving the Quantum API may notice that the operational status of a port or network is down and choose to roll back the logical configuration to a previous state (e.g., delete a created port). Doing so requires understanding only the logical model, not the plugin implementation. Dan On Mon, Sep 19, 2011 at 12:49 PM, Sumit Naiksatam (snaiksat) <snaik...@cisco.com> wrote: Thanks Dan for your response. I think the rollback could/would happen at different levels of abstraction, and how effectively it could be done would depend on the context available at that level of abstraction. I do like your idea of putting the onus of initiating the rollback to a different (possibly orchestration as you point out) service, it definitely simplifies things. However, it's likely that some or all the context has been lost when the higher level service decides to rollback. To effectively target the rollback, I was thinking that the plugin would be in the best position to know what steps it needs to rollback if it is not able to support a particular call to an operation. In such a case, it would be helpful to have a generic framework which all plugins can use as a mechanism to rollback in case of failure. To give you an example, let's say an operation create_foo() requires the steps A, B, and C to be completed before an instance of resource "foo" is created. If steps A & B are successful (which internally might result in some device and system configurations) but C is not, then the plugin is not able to create the instance of resource "foo". At this point, it will be beneficial to have the knowledge to rollback steps A and B. Each plugin implementation might come up with a way of doing this, but I think a more generic framework might be beneficial to the community. I am also trying to extend this to discussion on Troubleshooting & Diagnostics in general (cases where failures occur and rollback is not done properly). Based on your comments below, let me put a place holder for discussions around "Quantum Scheduler Interface & Reservation Semantics". We can roll this into a different session if there is an overlap. Thanks, ~Sumit. From: Dan Wendlandt [mailto:d...@nicira.com] Sent: Monday, September 19, 2011 12:16 PM To: Sumit Naiksatam (snaiksat) Cc: Salvatore Orlando; Ram Durairaj (radurair); netstack@lists.launchpad.net Subject: Re: [Netstack] Proposing sessions for Openstack design summitq On Mon, Sep 19, 2011 at 10:22 AM, Sumit Naiksatam (snaiksat) <snaik...@cisco.com> wrote: Hi All, Here are a few more issues which we think need to be tackled - * A framework for Rollback after Operation Failure, Troubleshooting & Diagnostics: The realization of the APIs supported by the Quantum service (such as create_network, create_port) results in a series of steps in the plugin implementation, and which often touch heterogeneous independent systems (in the management plane). If one of these steps fails, it might be required to rollback the entire operation or a part of it (depending on the context of the operation). It would be desirable to have the ability to define checkpoints in the system such that in the event of a failure, one can rollback the state of the system to previous checkpoint. It's easier to achieve this functionality with a database since most implementations support check pointing and rollback. However, a more sophisticated framework will be required to handle other management systems or devices which are touched by the plugin in order complete an operation. Hi Sumit, Would such a mechanism would be specific to a particular plugin, or am I misunderstanding what your are describing? My thinking on this front has been pretty simple: the plugin is constantly trying to make the virtual/physical switch configuration match the logical model exposed by the API. If the plugin is not able to achieve that, it would expose this fact via the "operational status" (TBD in API v1.1). The user of the Quantum API (possibly an orchestration service) would then have the option to detect the error and "roll-back" the logical model to a previous state. * Reservation Semantics (relevant to the discussion around L2 & L3 core capabilities): Neither Nova nor Quantum supports the reservation of resources. In order to support certain use cases wherein the goal is to provide a necessary level of QoS, it might be required to support a mechanism which will support the advance reservation of resources, such that all of the required resources are available at a designated time. (This is just one use case, the requirement for reservation in general is well understood.) Scheduler interface exposed by Quantum (relevant to the discussion around L2 & L3 core capabilities): While a meta-scheduler (which can perform multi-constrained decisions based on availability of heterogeneous resources) is required (and is being pursued in the context of the Scheduler Service), we also need a normalized mechanism on the network service side to expose the network-specific information to the meta-scheduler. This mechanism should be fairly generic such that the meta-scheduler would not need to have deep understanding of the underlying network realization. This definitely makes sense and was the topic of a fair amount of discussion at the last summit as well. The need to expose + reserve resources is probably general across many OpenStack services, so it would be good to make sure we do this in a way that is consistent with the general OpenStack goals (no need to re-invent the wheel). * A Default Plugin Implementation based on Linux bridge (currently Linux bridge is nova configuration, but bridge is a network artifact) * A basic security-groups plugin based on Netfilter (currently Nova does a lot of iptables configuration) Both seem achievable. I would also be very interested in the asynchronous API discussions, so kindly loop me in as well. oh definitely, all sessions will be available :) Thanks, ~Sumit. From: netstack-bounces+snaiksat=cisco....@lists.launchpad.net [mailto:netstack-bounces+snaiksat <mailto:netstack-bounces%2Bsnaiksat> =cisco....@lists.launchpad.net] On Behalf Of Salvatore Orlando Sent: Monday, September 19, 2011 8:36 AM To: Ram Durairaj (radurair); netstack@lists.launchpad.net Cc: Thierry Carrez Subject: Re: [Netstack] Proposing sessions for Openstack design summitq Hi Ram, Thanks for sharing your proposed sessions for the design summit. I think that for this summit we will not be creating blueprints and them propose them for "sprint" as we did for Diablo, but we should rather propose sessions on the summit.openstack.org/sessions. However, since we are going to have our own track, it will be good to hear some organizational details from Thierry how many sessions we can fit in it. All the elements in your list make perfect sense for me. However, I'm afraid I do not understand very well what do you mean by "Hybrid Cloud Service Framework". Can you elaborate a bit more on this? I think your list is not very far from mine, and we can probably merge them as follows: 1. L3 networking services (beyond IPAM) 2. Higher layer network services (L4/L7) 1. Firewall and Security Groups 2. Network Acceleration Services Insertion Framework LB, Symmetric services - Acceleration services and so on 3. NAT 4. VPN Access 3. Quantum "Basic" Plugin 1. Linux Bridge 2. Solution supporting all hypervisor platforms including ESX/Hyper-V 4. Hybrid Cloud Service Framework 5. Quantum API v1.1 1. Synchronous vs Asynchronous behaviour and concept of "Operational Status" 2. Improvements such as Filtering, Rate Limiting, Resource Links, pagination 6. Cloud Bridging APIs in Quantum From: Ram Durairaj (radurair) [mailto:radur...@cisco.com] Sent: 19 September 2011 16:21 To: Salvatore Orlando; netstack@lists.launchpad.net Cc: Thierry Carrez Subject: RE: [Netstack] Proposing sessions for Openstack design summitq Hello Salvatore and all: We suppose to have a Netstack track...Its good to follow-up with Thierry to group all the Net stack related blueprint and sessions in one track for all the interested community participants to contribute and discuss. In addition to the list, here are few more items from our side: 1. L3 Service - As a service as Quantum 2. Hybrid Cloud Service Framework 3. Network Acceleration Services Insertion Framework (LB, Symmetric services - Acceleration services and so on) 4. Quantum Asynchronous API mode 5. Quantum Security Groups support 6. Quantum "Basic Plugin (Linux bridge?) Few more services we are discussing internally and we will add them here. Thanks Ram From: netstack-bounces+radurair=cisco....@lists.launchpad.net [mailto:netstack-bounces+radurair <mailto:netstack-bounces%2Bradurair> =cisco....@lists.launchpad.net] On Behalf Of Salvatore Orlando Sent: Monday, September 19, 2011 7:49 AM To: netstack@lists.launchpad.net Subject: [Netstack] Proposing sessions for Openstack design summitq Hello fellow NetStackers, The list of proposed session at http://summit.openstack.org/sessions is filling up, and I think it is time we start proposing our own sessions as well. Actually, there are already two accepted sessions for NetStack: 1. Donabe/API models: http://summit.openstack.org/sessions/view/29 2. Continuous integration planning: http://summit.openstack.org/sessions/view/35 On top of these two, I would also consider having the following sessions (in order of importance): 1. Higher layer network services (L4/L7), e.g.: Firewall, NAT, VPN 2. Improved authorization framework for Quantum, with a full RBAC model. 3. Quantum API v1.1 a. Synchronous vs Asynchronous behaviour and concept of "Operational Status" b. Improvements such as Filtering, Rate Limiting, Resource Links, pagination 4. Cloud Bridging APIs in Quantum What's your opinion? Cheers, 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
