openstack team mailing list archive

[Dan Wendlandt <dan@xxxxxxxxxx>]

Hi John,

I believe you are asking specifically about the case when two deployments
under different administrative control are running openstack and would like
to "link" networks.

For this, I could imagine a openstack-to-openstack VPN (OS2OS-VPN) service
that had an API something like:

get_vpn_terminator_address()  // returns all addresses/ports needed to
access this instances VPN connectivity from a remote data center
get_access_credentials(network-id) -> returns IPsec-credential   // returns
VPN credentials to access a specific network
create_remote_link(network-id, remote-vpn-address, IPsec-credential)  //
tells this OS2OS-VPN service to create a link with a remote OS2OS-VPN
service using a specific credential

The tenant both runs openstack locally and is a customer of the provider, so
it can make API calls to both openstack instances.

Now, to link network 'ABC' on the tenant's local deployment with network
'XYZ' on the cloud provider's deployment, the tenant woud make the following
API calls:

To tenant OS controller:
C1 = get_access_credential('ABC')
A1 = get_vpn_terminator_address()

To provider OS controller:
C2 = get_access_credential('XYZ')
IP2 = get_vpn_terminator_address()

To tenant OS controller:
create_remote_link('ABC', A2, C2)

To provider OS controller:
create_remote_link('XYZ', A1, C1)

Again, this is just a toy API, but it should get the idea across.

Dan


On Mon, Feb 21, 2011 at 12:39 PM, John Purrier <john@xxxxxxxxxxxxx> wrote:

> Dan, I like the #1 approach. Since I noticed you split out VPN services as
> well, how do you think virtual networks that span deployments will work? One
> use case is I have deployed Nova inside my datacenter and want to create a
> pool of compute resources in my friendly public cloud provider. At the
> network level I want this to be a singular private network that compute
> resources from my private cloud and compute resources I pay for in the
> public cloud can attach to. I want complete end-to-end security and
> isolation at the network layer in the public cloud.
>
>
>
> Thanks,
>
>
>
> John
>
>
>
> *From:* openstack-bounces+john=openstack.org@xxxxxxxxxxxxxxxxxxx [mailto:
> openstack-bounces+john=openstack.org@xxxxxxxxxxxxxxxxxxx] *On Behalf Of *Dan
> Wendlandt
> *Sent:* Monday, February 21, 2011 2:02 PM
> *To:* Salvatore Orlando
>
> *Cc:* openstack@xxxxxxxxxxxxxxxxxxx
> *Subject:* Re: [Openstack] Network Service for L2/L3 Network
> Infrastructure blueprint
>
>
>
>
>
> On Mon, Feb 21, 2011 at 11:06 AM, Salvatore Orlando <
> Salvatore.Orlando@xxxxxxxxxxxxx> wrote:
>
> Dan,
>
>
>
> I agree with you on the notion of a ‘network’. That is exactly the same
> concept I was trying to expressing in my previous message.
>
>
>
> I also agree that each plugin might respond in a different way to the
> ‘create_network’ call.
>
> However, I believe there is a rather remarkable difference between creating
> a collection of ports with shared connectivity, and creating a network with
> a  NAT gateway, a VPN access gateway, a DHCP server, and possibly a DNS
> server, as it is in the current vlan manager J ! That is to say that the
> result of an API call, create_network in this case, should always be the
> same regardless of the plugin used. Distinct plugins might use different
> technologies, but the final results for the API user should always be the
> same.
>
>
>
>
>
> For instance, in the nova vlan manager scenario, the create_network
> operation, part of the core API, will set up basic connectivity (i.e.: vlan
> interfaces and bridges on hypervisors), whereas another bunch of operations,
> part of the extension API, would deal with setting up the IP range, the DHCP
> server, NAT configuration, VPN access and so on.
>
>
>
>
> Hi Salvatore,
>
>
>
> I think the is exactly the discussion we should be having :)   I should
> have been more clear in my last email to make a distinction between what
> should be "possible" and what I think is the "right" way to expose the
> existing nova functionality.  I actually think we're basically on the same
> page.
>
>
>
> In my view,  VPN, DHCP, DNS, etc are "network-related" functionality, but
> do not belong as part of the core network API.  These network-related
> services might be configured in one of several ways:
>
>
>
> 1) network-related service can be managed by the cloud tenant or provider
> via an Openstack API or API extension.  In this case, I feel that the
> cleanest way to model this would be to have a separate service (e.g., a DHCP
> service) that itself can attach to a network, just like a vNIC from the
> compute service can attach itself to a particular network.  (Note: when I
> say "separate service", I mean that this service is cleanly decoupled from
> the core network service with respect to enabling/disabling the
> functionality.   I am not making a statement about what repository the code
> should live in).
>
> 2) a network-related service like DHCP may not be closely integrated with
> Openstack, for example, being completely managed by the cloud provider in a
> traditional manner.  In this case, the cloud provider is responsible for
> making sure the VM connectivity from the "create_network" call provides
> access to a physical data center network that hosts this service.  Its
> pretty common for VMs to have an interface that maps to a physical
> "services" network within the data center that hosts things like DNS,
> storage, etc.
>
> 3) a network service plugin could implement this functionality as part of
> its definition of a "create_network".
>
>
>
> With respect to "porting" the existing nova functionality to the network
> service for common consumption, my feeling is that #1 would be the best
> model, which I believe is what you are proposing as well.   Still, I think
> something like #3 should be "possible" within the network service mechanism
> that we agree on.  In fact, #3 and #2 are really very similar, as they are
> both cases of the cloud provider deploying systems to provide
> network-related functionality without exposing it via the openstack API.
>
>
>
> Dan
>
>
>
>
>
>
>
>
>
> Salvatore
>
>
>
>
>
> *From:* Dan Wendlandt [mailto:dan@xxxxxxxxxx]
> *Sent:* 21 February 2011 18:11
> *To:* Salvatore Orlando
> *Cc:* Erik Carlin; Ishimoto, Ryu; openstack@xxxxxxxxxxxxxxxxxxx
>
>
> *Subject:* Re: [Openstack] Network Service for L2/L3 Network
> Infrastructure blueprint
>
>
>
>
>
> 2011/2/21 Salvatore Orlando <Salvatore.Orlando@xxxxxxxxxxxxx>
>
>
>
> Note that in create_network there is no assumption on the range of floating
> IPs. IMHO, The above listed APIs are good enough to provide a generic
> virtual L2-network which can then be assigned exclusively to a project, thus
> making it an isolated L2 network.
>
> I also believe these operations fulfil all the criteria listed by Romain
> for having them in the generic API, whereas create_network(address_prefix)
> clearly violates criterion #4 as we cannot assume every network plugin will
> provide IPv4 NAT.
>
>
>
> Hi folks.  While I agree that the current Nova model of a "network"
> requires IPv4 NAT, I feel that the concept is actually quite a bit more
> general and I think the API should reflect this :)
>
>
>
> At the bexar summit we advocated for an abstract notion of a network that
> was a "collection of ports with shared connectivity".  The key part of this
> definition is that it does NOT mandate a particular service model (L2/L3,
> L3-only) or set of available services (e.g., NAT, FW, VPN).  Any plugin
> would be free to provide a particular service model, or create networks that
> offer built-in services.  For example, a plugin that maps to the existing
> Nova "private" functionality might respond to a "create_network" call by
> assigning a L2 VLAN to a customer and also provisioning a NAT gateway on
> that VLAN.  Another plugin might do something entirely different, not using
> NAT at all.
>
>
>
> Romain raised a good question of whether "create_network" makes sense in
> the "core" API.  I would argue that having a notion of a "network" that
> joins "ports" will be most intuitive to how people think about networking,
> and that having an intuitive API is a plus.  Every virtualization platform
> that I can think of has some notion of a "network" that joins "ports"
> (XenServer Networks, vmware port groups, cisco 1000v port profiles, hyper-v
> virtual networks), not to mention the clear analogy to the physical world of
> plugging physical wires into ports on the same switch or set of
> interconnected switches.
>
>
>
> Regarding the example when having a notion of a "network" in the API might
> be clunky because it requires one "network" per "port".  First, requiring
> two API calls instead of one for a particular scenario of using a API
> doesn't strike me as terrible, since APIs are meant to be automated.  More
> importantly though, I don't think the one network per port would actually be
> required for this scenario.  I would have modeled this as a single "network"
> per-tenant that provides the "service" of L2 VPN connectivity access back to
> that tenant's environment.  I think the reason for our disconnect may be
> that I see the API only as a way of describing the connectivity that the VMs
> sees (all VMs get L2 VPN access to this tenant's remote network), not
> necessarily describing the underlying implementation of that connectivity
> (each VM has its own bridge with the VM interface and the openvpn tunnel
> interface).   This is why in the network service write-up we presented at
> bexar we referred to the API networks as "logical networks", as they only
> describe what connectivity a VM should get, not necessarily the
> implementation of that connectivity (which will likely vary per plugin).
>
>
>
>  Dan
>
>
>
>
>
>
>
> Then, assuming that the above listed APIs are sufficient to setup a Layer-2
> virtual network, what should we do about IP addressing? (By IP addressing I
> just mean a strategy for associating an IP subnet of private addresses to
> the network). Do we want to use the create_network API call, adding a
> parameter for the CIDR, or do we want to define a different API, for
> instance create_subnet(network_id,cidr)?
>
>
>
> Regards,
>
> Salvatore
>
>
>
> *From:* openstack-bounces+salvatore.orlando=eu.citrix.com@
> lists.launchpad.net [mailto:openstack-bounces+salvatore.orlando=
> eu.citrix.com@xxxxxxxxxxxxxxxxxxx] *On Behalf Of *Erik Carlin
> *Sent:* 21 February 2011 14:57
> *To:* Ishimoto, Ryu
>
>
> *Cc:* openstack@xxxxxxxxxxxxxxxxxxx
> *Subject:* Re: [Openstack] Network Service for L2/L3 Network
> Infrastructure blueprint
>
>
>
> From a Rackspace perspective, we definitely want the network service to
> support a L2 service model.  I think VLANs should be the default out of the
> box option but other more service provider scale L2 alternatives should also
> be supported.  Let's just decide that L2 is in.
>
>
>
> Other thoughts?
>
>
>
> Erik
>
> Sent from my iPhone
>
>
> On Feb 21, 2011, at 6:06 AM, "Ishimoto, Ryu" <ryu@xxxxxxxxxxx> wrote:
>
>
>
> It seems that there must be a decision made to what extent should an
> OpenStack 'network service' is expected to support.  Should it support
> L2-only networks?  Or should it assume ONLY the IP-based network services to
> be available?   Looking at http://wiki.openstack.org/NetworkService, there
> doesn't seem to be any demand for L2 networks, but should it assume there
> won't be any in the future?
>
>
>
> As Romain and Hisaharu-san suggested, if OpenStack is to support L2
> networks, then it would make sense to simply have the Virtual NICs(network
> interfaces associated with VMs) and their mapping to Virtual Ports(logical
> ports to plug VNICs into for network connectivity) be generic.  If OpenStack
> is going to support ONLY IP-based networks, and assumes that every VNIC is
> assigned an IP, then the generic API should be defined accordingly.  Either
> way, it would be very helpful to decide on this soon.
>
>
>
> What do you think?
>
>
>
> Thanks,
>
> Ryu
>
>
>
>
>
> 2011/2/17 石井 久治 <ishii.hisaharu@xxxxxxxxxxxxx>
>
> Romain,
>
> Please call me hisaharu :)
>
> I have read your proposal and felt the below point is important.
>
> >     - create_network(address_prefix): network_id
>
> >         This cannot be part of the API because it violates criterion 4):
> a
> > network service plugin may not support NATted IPv4 networks, for instance
> a
> > plugin that supports only pure L2 private Ethernet networks to
> interconnect
> > VMs.
>
> On the other hand this was said in the document Erik referred.
> > Implementors are only required to implement the core API.
>
> Should we allow a network plugin which has no functions to allocate IP
> addresses to VMs but provides L2 reachability to users?
> If so, the core API should have no APIs related to IP address.
>
> Thanks,
> Hisaharu Ishii
>
>
>
> (2011/02/16 10:04), Romain Lenglet wrote:
> > Ishii-san,
> >
> > Re-reading the proposal you sent on Feb. 2nd, I realized that you didn't
> > separate between generic operations and plugin-specific operations. I
> > thought you did, sorry. I propose to rewrite your spec into one API and
> two
> > (optional) extensions:
> >
> > - network service API (plugin-agnostic):
> >      - list_vnics(): [vnic_id]
> >          Return the list of vnic_id created by the tenant (project),
> where
> > vnic_id is the ID of a VNIC.
> >      - destroy_vnic(vnic_id)
> >          Remove a VNIC from its VM, given its ID, and destroy it.
> >      - plug(vnic_id, port_id)
> >          Plug the VNIC with ID vnic_id into the port with ID port_id,
> both
> > managed by this network service.
> >      - unplug(vnic_id)
> >          Unplug the VNIC from its port, previously plugged by calling
> plug().
> >      - list_ports(): [port_id]
> >          Return the list of IDs of ports created by the tenant (project).
> >      - destroy_port(port_id)
> >          Destroy port with ID port_id.
> >
> > - Ethernet VNIC API extension:
> >      - create_vnic([mac_address]): vnid_id
> >          Create a VNIC and return the ID of the created VNIC. Associate
> the
> > given MAC address with the VNIC, or associate a random unique MAC with it
> if
> > not given.
> >          This cannot be part of the API because it violates criterion 4):
> we
> > plan to implement non-Ethernet virtual devices to connect VMs, so this
> > operation cannot be implemented in that specific plugin.
> >
> > - NATed IPv4 network API extension:
> >      - create_network(address_prefix): network_id
> >          Create a new logical network with floating addresses in the
> given
> > address range, and return the network ID.
> >          This cannot be part of the API because it violates criterion 4):
> a
> > network service plugin may not support NATted IPv4 networks, for instance
> a
> > plugin that supports only pure L2 private Ethernet networks to
> interconnect
> > VMs. Moreover, the notion of "logical network" doesn't make sense in all
> > cases: one can imagine a network plugin where every port is implemented
> by a
> > separate Layer-2 OpenVPN connection to a tenant's private physical
> Ethernet
> > network, in which case there is no notion of "logical network" (or it
> would
> > require users to create a separate logical network for every port / VNIC,
> > which would be very inconvenient).
> >      - list_networks(): [network_id]
> >          Return the list of IDs of logical networks created by the tenant
> > (project).
> >          This cannot be part of the API because it violates criterion 4):
> > idem, the notion of "logical network" is not plugin-agnostic.
> >      - destroy_network(network_id)
> >          Destroy the logical network with ID network_id.
> >          This cannot be part of the API because it violates criterion 4):
> > idem, the notion of "logical network" is not plugin-agnostic.
> >      - create_port(network_id): port_id
> >          Create a port in the logical network with ID network_id,
> associate a
> > floating address to it, and return the port's ID.
> >          This cannot be part of the API because it violates criterion 4):
> > idem, the notion of "logical network" is not plugin-agnostic.
> >
> > What do you think of that new version of the API spec?
> > Do you agree with the split into API+extensions?
> >
> > Regards,
> > --
> > Romain Lenglet
> >
> > 2011/2/16 Romain Lenglet<romain@xxxxxxxxxxx>
> >
> >> Hi Erik,
> >>
> >> Thanks for your comments.
> >>
> >> There doesn't seem to be a consensus to use "core API + extensions" vs.
> >> multiple APIs?
> >> Anyway, I don't see any issues with specifying a "core API" for network
> >> services, and a "core API" for network agents, corresponding exactly to
> >> NTT's Ishii-san's "generic APIs", and specifying all the non-generic,
> >> plugin-specific operations in extensions.
> >> If the norm becomes to have a core API + extensions, then the network
> >> service spec will be modified to follow that norm. No problem.
> >>
> >> The important point we need to agree on is what goes into the API, and
> what
> >> goes into extensions.
> >>
> >> Let me rephrase the criteria that I proposed, using the "API" and
> >> "extensions" terms:
> >> 1) any operation called by the compute service (Nova) directly MUST be
> >> specified in the API;
> >> 2) any operation called by users / admin tools MAY be specified in the
> API,
> >> but not necessarily;
> >> 3) any operation specified in the API MUST be independent from details
> of
> >> specific network service plugins (e.g. specific network models, specific
> >> supported protocols, etc.), i.e. that operation can be supported by
> every
> >> network service plugin imaginable, which means that:
> >> 4) any operation that cannot be implemented by all plugins MUST be
> >> specified in an extension, i.e. if one comes up with a counter-example
> >> plugin that cannot implement that operation, then the operation cannot
> be
> >> specified in the API and MUST be specified in an extension.
> >>
> >> Do we agree on those criteria?
> >>
> >> I think Ishii-san's proposal meets those criteria.
> >> Do you see any issues with Ishii-san's proposal regarding the split
> between
> >> core operations and extension operations?
> >> If you think that some operations that are currently defined as
> extensions
> >> in Ishii-san's proposal should be in the API, I'll be happy to try to
> give
> >> counter-examples of network service plugins that can't implement them.
> :)
> >>
> >> Regards,
> >> --
> >> Romain Lenglet
> >>
> >>
> >> 2011/2/16 Erik Carlin<erik.carlin@xxxxxxxxxxxxx>
> >>
> >>   My understanding is that we want a single, canonical OS network
> service
> >>> API.  That API can then be implemented by different "service engines"
> on
> >>> that back end via a plug-in/driver model.  The way additional features
> are
> >>> added to the canonical API that may not be core or for widespread
> adoption
> >>> (e.g. something vendor specific) is via extensions.  You can take a
> look at
>
> >>> the proposed OS compute API spec<
> http://wiki.openstack.org/OpenStackAPI_1-1>to see how extensions are
> implemented there.  Also, Jorge Williams has done
> >>> a good write up of the concept here<
> http://wiki.openstack.org/JorgeWilliams?action=AttachFile&do=view&target=Extensions.pdf
> >
>
> >>> .
> >>>
> >>>   Erik
> >>>
> >>>    From: Romain Lenglet<romain@xxxxxxxxxxx>
> >>> Date: Tue, 15 Feb 2011 17:03:57 +0900
> >>> To: 石井 久治<ishii.hisaharu@xxxxxxxxxxxxx>
> >>> Cc:<openstack@xxxxxxxxxxxxxxxxxxx>
> >>>
> >>> Subject: Re: [Openstack] Network Service for L2/L3 Network
> Infrastructure
> >>> blueprint
> >>>
> >>>    Hi Ishii-san,
> >>>
> >>> On Tuesday, February 15, 2011 at 16:28, 石井 久治 wrote:
> >>>
> >>>   Hello Hiroshi-san
> >>>
> >>>>> Do you mean that the former API is an interface that is
> >>>>> defined in OpenStack project, and the latter API is
> >>>>> a vendor specific API?
> >>>> My understanding is that yes, that's what he means.
> >>>
> >>> I also think so.
> >>>
> >>> In addition, I feel it is issue that what network functions should be
> >>> defined as generic API, and what network functions should be defined as
> >>> plugin specific API.
> >>> How do you think ?
> >>>
> >>> I propose to apply the following criteria to determine which operations
> >>> belong to the generic API:
> >>> - any operation called by the compute service (Nova) directly MUST
> belong
> >>> to the generic API;
> >>> - any operation called by users (REST API, etc.) MAY belong to the
> generic
> >>> API;
> >>> - any operation belonging to the generic API MUST be independent from
> >>> details of specific network service plugins (e.g. specific network
> models,
> >>> specific supported protocols, etc.), i.e. the operation can be
> supported by
> >>> every network service plugin imaginable, which means that if one can
> come up
> >>> with a counter-example plugin that cannot implement that operation,
> then the
> >>> operation cannot belong to the generic API.
> >>>
> >>>   How about that?
> >>>
> >>>   Regards,
> >>> --
> >>> Romain Lenglet
> >>>
> >>>
> >>>
> >>> Thanks
> >>> Hisaharu Ishii
> >>>
> >>>
> >>> (2011/02/15 16:18), Romain Lenglet wrote:
> >>>
> >>> Hi Hiroshi,
> >>> On Tuesday, February 15, 2011 at 15:47, Hiroshi DEMPO wrote:
> >>> Hello Hisaharu san
> >>>
> >>>
> >>> I am not sure about the differences between generic network API and
> >>> plugin X specific network service API.
> >>>
> >>> Do you mean that the former API is an interface that is
> >>> defined in OpenStack project, and the latter API is
> >>> a vendor specific API?
> >>>
> >>>
> >>> My understanding is that yes, that's what he means.
> >>>
> >>> --
> >>> Romain Lenglet
> >>>
> >>>
> >>>
> >>> Thanks
> >>> Hiroshi
> >>>
> >>>   -----Original Message-----
> >>> From: openstack-bounces+dem=ah.jp.nec.com@xxxxxxxxxxxxxxxxxxx
>
> >>> [mailto:openstack-bounces<openstack-bounces>+dem=
> >>> ah.jp.nec.com@xxxxxxxxxxxxxxxxxx
> >>> t] On Behalf Of 石井 久治
> >>> Sent: Thursday, February 10, 2011 8:48 PM
> >>> To: openstack@xxxxxxxxxxxxxxxxxxx
> >>> Subject: Re: [Openstack] Network Service for L2/L3 Network
> >>> Infrastructure blueprint
> >>>
> >>> Hi, all
> >>>
> >>> As we have said before, we have started designing and writing
> >>> POC codes of network service.
> >>>
> >>>   - I know that there were several documents on the new network
> >>> service issue that were locally exchanged so far.
> >>> Why not collecting them into one place and share them
> >>>
> >>> publicly?
> >>>
> >>> Based on these documents, I created an image of
> >>> implementation (attached). And I propose the following set of
> >>> methods as the generic network service APIs.
> >>> - create_vnic(): vnic_id
> >>> Create a VNIC and return the ID of the created VNIC.
> >>> - list__vnics(vm_id): [vnic_id]
> >>> Return the list of vnic_id, where vnic_id is the ID of a VNIC.
> >>> - destroy_vnic(vnic_id)
> >>> Remove a VNIC from its VM, given its ID, and destroy it.
> >>> - plug(vnic_id, port_id)
> >>> Plug the VNIC with ID vnic_id into the port with ID
> >>> port_id managed by this network service.
> >>> - unplug(vnic_id)
> >>> Unplug the VNIC from its port, previously plugged by
> >>> calling plug().
> >>> - create_network(): network_id
> >>> Create a new logical network.
> >>> - list_networks(project_id): [network_id]
> >>> Return the list of logical networks available for
> >>> project with ID project_id.
> >>> - destroy_network(network_id)
> >>> Destroy the logical network with ID network_id.
> >>> - create_port(network_id): port_id
> >>> Create a port in the logical network with ID
> >>> network_id, and return the port's ID.
> >>> - list_ports(network_id): [port_id]
> >>> Return the list of IDs of ports in a network given its ID.
> >>> - destroy_port(port_id)
> >>> Destroy port with ID port_id.
> >>>
> >>> This design is a first draft.
> >>> So we would appreciate it if you would give us some comments.
> >>>
> >>> In parallel with it, we are writing POC codes and uploading
> >>> it to "lp:~ntt-pf-lab/nova/network-service".
> >>>
> >>> Thanks,
> >>> Hisaharu Ishii
> >>>
> >>>
> >>> (2011/02/02 19:02), Koji IIDA wrote:
> >>>
> >>> Hi, all
> >>>
> >>>
> >>> We, NTT PF Lab., also agree to discuss about network service at the
> >>> Diablo DS.
> >>>
> >>> However, we would really like to include network service in
> >>>
> >>> the Diablo
> >>>
> >>> release because our customers strongly demand this feature. And we
> >>> think that it is quite important to merge new network
> >>>
> >>> service to trunk
> >>>
> >>> soon after Diablo DS so that every developer can contribute their
> >>> effort based on the new code.
> >>>
> >>> We are planning to provide source code for network service
> >>>
> >>> in a couple
> >>>
> >>> of weeks. We would appreciate it if you would review it
> >>>
> >>> and give us
> >>>
> >>> some feedback before the next design summit.
> >>>
> >>> Ewan, thanks for your making new entry at wiki page (*1).
> >>>
> >>> We will also
> >>>
> >>> post our comments soon.
> >>>
> >>> (*1) http://wiki.openstack.org/NetworkService
> >>>
> >>>
> >>> Thanks,
> >>> Koji Iida
> >>>
> >>>
> >>> (2011/01/31 21:19), Ewan Mellor wrote:
> >>>
> >>> I will collect the documents together as you suggest, and
> >>>
> >>>   I agree that we need to get the requirements laid out again.
> >>>
> >>>
> >>> Please subscribe to the blueprint on Launchpad -- that way
> >>>
> >>>   you will be notified of updates.
> >>>
> >>>
> >>> https://blueprints.launchpad.net/nova/+spec/bexar-network-service
> >>>
> >>> Thanks,
> >>>
> >>> Ewan.
> >>>
> >>>   -----Original Message-----
> >>> From: openstack-bounces+ewan.mellor=citrix.com@xxxxxxxxxxxxxxxxxxx
> >>>
>
> >>>    [mailto:openstack-bounces<openstack-bounces>+ewan.mellor=
> >>> citrix.com@xxxxxxxxxxxxxxxxxxx
> >>>
> >>>   ]
> >>> On Behalf Of Masanori ITOH
> >>> Sent: 31 January 2011 10:31
> >>> To: openstack@xxxxxxxxxxxxxxxxxxx
> >>> Subject: Re: [Openstack] Network Service for L2/L3 Network
> >>> Infrastructure blueprint
> >>>
> >>> Hello,
> >>>
> >>> We, NTT DATA, also agree with majority of folks.
> >>> It's realistic shooting for the the Diablo time frame to have the
> >>> new network service.
> >>>
> >>> Here are my suggestions:
> >>>
> >>> - I know that there were several documents on the new network
> >>> service issue
> >>> that were locally exchanged so far.
> >>> Why not collecting them into one place and share them
> >>>
> >>>   publicly?
> >>>
> >>>
> >>> - I know that the discussion went into a bit
> >>>
> >>>   implementation details.
> >>>
> >>>   But now, what about starting the discussion from the
> >>>
> >>>   higher level
> >>>
> >>>   design things (again)? Especially, from the
> >>>
> >>>   requirements level.
> >>>
> >>>
> >>> Any thoughts?
> >>>
> >>> Masanori
> >>>
> >>>
> >>> From: John Purrier<john@xxxxxxxxxxxxx>
> >>> Subject: Re: [Openstack] Network Service for L2/L3 Network
> >>> Infrastructure blueprint
> >>> Date: Sat, 29 Jan 2011 06:06:26 +0900
> >>>
> >>>   You are correct, the networking service will be more
> >>>
> >>>    complex than
> >>>
> >>>    the
> >>>
> >>> volume
> >>>
> >>> service. The existing blueprint is pretty comprehensive,
> >>>
> >>>    not only
> >>>
> >>>    encompassing the functionality that exists in today's network
> >>> service
> >>>
> >>> in
> >>>
> >>> Nova, but also forward looking functionality around flexible
> >>> networking/openvswitch and layer 2 network bridging
> >>>
> >>>    between cloud
> >>>
> >>>    deployments.
> >>>
> >>> This will be a longer term project and will serve as the bedrock
> >>> for
> >>>
> >>> many
> >>>
> >>> future OpenStack capabilities.
> >>>
> >>> John
> >>>
> >>> -----Original Message-----
> >>> From: openstack-bounces+john=openstack.org@xxxxxxxxxxxxxxxxxxx
> >>>
>
> >>>    [mailto:openstack-bounces<openstack-bounces>+john=
> >>> openstack.org@xxxxxxxxxxxxxxxxxxx]
> >>>
> >>>    On
> >>>
> >>> Behalf
> >>>
> >>> Of Thierry Carrez
> >>> Sent: Friday, January 28, 2011 1:52 PM
> >>> To: openstack@xxxxxxxxxxxxxxxxxxx
> >>> Subject: Re: [Openstack] Network Service for L2/L3 Network
> >>>
> >>> Infrastructure
> >>>
> >>> blueprint
> >>>
> >>> John Purrier wrote:
> >>>
> >>> Here is the suggestion. It is clear from the response
> >>>
> >>>     on the list
> >>>
> >>>   that
> >>>
> >>> refactoring Nova in the Cactus timeframe will be too risky,
> >>>
> >>> particularly as
> >>>
> >>> we are focusing Cactus on Stability, Reliability, and
> >>>
> >>>    Deployability
> >>>
> >>>   (along
> >>>
> >>> with a complete OpenStack API). For Cactus we should leave the
> >>>
> >>> network and
> >>>
> >>> volume services alone in Nova to minimize destabilizing the code
> >>>
> >>> base. In
> >>>
> >>> parallel, we can initiate the Network and Volume Service
> >>>
> >>>    projects
> >>>
> >>>    in Launchpad and allow the teams that form around these
> >>>
> >>>    efforts to
> >>>
> >>>    move
> >>>
> >>> in
> >>>
> >>> parallel, perhaps seeding their projects from the
> >>>
> >>>    existing Nova code.
> >>>
> >>>
> >>> Once we complete Cactus we can have discussions at the Diablo DS
> >>>
> >>>   about
> >>>
> >>> progress these efforts have made and how best to move
> >>>
> >>>    forward with
> >>>
> >>>   Nova
> >>>
> >>> integration and determine release targets.
> >>>
> >>> I agree that there is value in starting the proof-of-concept work
> >>>
> >>> around
> >>>
> >>> the network services, without sacrificing too many developers to
> >>> it,
> >>>
> >>> so
> >>>
> >>> that a good plan can be presented and discussed at the
> >>>
> >>>    Diablo Summit.
> >>>
> >>>
> >>> If volume sounds relatively simple to me, network sounds
> >>>
> >>> significantly
> >>>
> >>> more complex (just looking at the code ,network manager code is
> >>> currently used both by nova-compute and nova-network to
> >>>
> >>>    modify the
> >>>
> >>>   local
> >>>
> >>> networking stack, so it's more than just handing out IP
> >>>
> >>>    addresses
> >>>
> >>>     through an API).
> >>>
> >>> Cheers,
> >>>
> >>> --
> >>> Thierry Carrez (ttx)
> >>> Release Manager, OpenStack
> >>>
> >>> _______________________________________________
> >>> Mailing list: https://launchpad.net/~openstack
> >>> Post to : openstack@xxxxxxxxxxxxxxxxxxx
> >>> Unsubscribe : https://launchpad.net/~openstack
> >>> More help : https://help.launchpad.net/ListHelp
> >>>
> >>>
> >>> _______________________________________________
> >>> Mailing list: https://launchpad.net/~openstack
> >>> Post to : openstack@xxxxxxxxxxxxxxxxxxx
> >>> Unsubscribe : https://launchpad.net/~openstack
> >>> More help : https://help.launchpad.net/ListHelp
> >>>
> >>>
> >>> _______________________________________________
> >>> Mailing list: https://launchpad.net/~openstack
> >>> Post to : openstack@xxxxxxxxxxxxxxxxxxx
> >>> Unsubscribe : https://launchpad.net/~openstack
> >>> More help : https://help.launchpad.net/ListHelp
> >>>
> >>>
> >>> _______________________________________________
> >>> Mailing list: https://launchpad.net/~openstack
> >>> Post to : openstack@xxxxxxxxxxxxxxxxxxx
> >>> Unsubscribe : https://launchpad.net/~openstack
> >>> More help : https://help.launchpad.net/ListHelp
> >>>
> >>>    _______________________________________________
> >>> Mailing list: https://launchpad.net/~openstack
> >>> Post to : openstack@xxxxxxxxxxxxxxxxxxx
> >>> Unsubscribe : https://launchpad.net/~openstack
> >>> More help : https://help.launchpad.net/ListHelp
> >>>
> >>> Attachments:
> >>> - smime.p7s
> >>>
> >>>
> >>> _______________________________________________
> >>> Mailing list: https://launchpad.net/~openstack
> >>> Post to : openstack@xxxxxxxxxxxxxxxxxxx
> >>> Unsubscribe : https://launchpad.net/~openstack
> >>> More help : https://help.launchpad.net/ListHelp
> >>>
> >>>
> >>>    _______________________________________________ Mailing list:
> >>> https://launchpad.net/~openstack Post to :
> openstack@lists.launchpad.netUnsubscribe :
> >>> https://launchpad.net/~openstack More help :
> >>> https://help.launchpad.net/ListHelp
> >>>
> >>> Confidentiality Notice: This e-mail message (including any attached or
> >>> embedded documents) is intended for the exclusive and confidential use
> of the
> >>> individual or entity to which this message is addressed, and unless
> otherwise
> >>> expressly indicated, is confidential and privileged information of
> Rackspace.
> >>> Any dissemination, distribution or copying of the enclosed material is
> prohibited.
> >>> If you receive this transmission in error, please notify us immediately
> by e-mail
> >>> at abuse@xxxxxxxxxxxxx, and delete the original message.
> >>> Your cooperation is appreciated.
> >>>
> >>>
> >>
> >
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
>
> Confidentiality Notice: This e-mail message (including any attached or
>
> embedded documents) is intended for the exclusive and confidential use of the
>
> individual or entity to which this message is addressed, and unless otherwise
>
> expressly indicated, is confidential and privileged information of Rackspace.
>
> Any dissemination, distribution or copying of the enclosed material is prohibited.
>
> If you receive this transmission in error, please notify us immediately by e-mail
>
> at abuse@xxxxxxxxxxxxx, and delete the original message.
>
> Your cooperation is appreciated.
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~