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

Reply via email to