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. * 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. * 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) I would also be very interested in the asynchronous API discussions, so kindly loop me in as well. 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
