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