On Tue, Sep 20, 2011 at 8:59 AM, Salvatore Orlando < salvatore.orla...@eu.citrix.com> wrote:
> :**** > > · Quantum: Integrating Advanced Network Services is proposed > twice. Is that because we feel we need more time (110 mins) to discuss > higher-layer services? > Also, I think there might an overlap with “Network Services Insertion”, and > I would consider merging this sessions.**** > > I noticed that this issue and a few others were showing up as duplicates. > Looking at the URLs, it seems like they are in fact two different session > registrations, so I am going to ask Thierry to delete one. Glancing at what > Edgar has written up so far, it seems like the content of the two sessions > will be sufficiently different, though we probably want to schedule them > back to back (or merge them into a single jumbo discussion). Too me this is > a pretty fundamental topic, as there are a lot of proposals around > introducing particular higher-level services. **** > > ** ** > > [Salvatore]: It is my impression that both proposal aim at defining a > solution for running higher-layer services on top of Quantum. However, I > will let the author of the proposals elaborate on this, as I’m just trying > to guess from the session description. This is a very fundamental topic for > me as well. > > It is extremely important for me that the network services for the Essex > release will be at least on a par, feature-wise, with what is currently > offered by nova-network. > I couldn't agree more :) There's actually a significant amount of work here just to get DHCP, floating IPs, VPN, NAT, the metadata server, etc fully integrated into the Quantum model, which is why I want to make sure we don't get ahead of ourselves proposing too many other whizbang services without first focusing on parity as you suggest. I filed a session for us to talk about this: http://summit.openstack.org/sessions/view/68 (probably an early phase 3?). Dan **** > > · Compute Port Aware Scheduler: in my opinion we might probably > want to consider this session in the Nova/General track, or at least, once > it is accepted, “alert” nova developers that this session is of interest for > them as well.**** > > Agreed, I think the previous thread with Sumit about scheduling probably > applies to this session as well. **** > > **** > > · Netstack L3 service: I think we should clarify how this service > differs from Melange.**** > > ** ** > > I suspect this is about introducing L3 dataplane forwarding capability, not > IPAM, but I will let the actual proposer clarify :) **** > > ** ** > > [Salvatore]: I also have the impression this about L3 forwarding or IP > routing. Let’s wait for Ram to clarify!**** > > **** > > **** > > Cheers,**** > > Salvatore**** > > **** > > **** > > *From:* Sumit Naiksatam (snaiksat) [mailto:snaik...@cisco.com] > *Sent:* 19 September 2011 21:38 > *To:* Dan Wendlandt**** > > > *Cc:* Salvatore Orlando; Ram Durairaj (radurair); > netstack@lists.launchpad.net**** > > *Subject:* RE: [Netstack] Proposing sessions for Openstack design summitq* > *** > > **** > > 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=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=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 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~**** > > > > **** > > ** ** > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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