[Openstack] Network Service for L2/L3 Network Infrastructure blueprint
Dan Wendlandt
dan at nicira.com
Mon Feb 21 20:01:44 UTC 2011
On Mon, Feb 21, 2011 at 11:06 AM, Salvatore Orlando <
Salvatore.Orlando at eu.citrix.com> 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 at nicira.com]
> *Sent:* 21 February 2011 18:11
> *To:* Salvatore Orlando
> *Cc:* Erik Carlin; Ishimoto, Ryu; openstack at lists.launchpad.net
>
> *Subject:* Re: [Openstack] Network Service for L2/L3 Network
> Infrastructure blueprint
>
>
>
>
>
> 2011/2/21 Salvatore Orlando <Salvatore.Orlando at eu.citrix.com>
>
>
>
> 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 at lists.launchpad.net] *On Behalf Of *Erik Carlin
> *Sent:* 21 February 2011 14:57
> *To:* Ishimoto, Ryu
>
>
> *Cc:* openstack at lists.launchpad.net
> *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 at midokura.jp> 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 at lab.ntt.co.jp>
>
> 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 at midokura.jp>
> >
> >> 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 at rackspace.com>
> >>
> >> 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 at midokura.jp>
> >>> Date: Tue, 15 Feb 2011 17:03:57 +0900
> >>> To: 石井 久治<ishii.hisaharu at lab.ntt.co.jp>
> >>> Cc:<openstack at lists.launchpad.net>
> >>>
> >>> 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 at lists.launchpad.net
>
> >>> [mailto:openstack-bounces<openstack-bounces>+dem=
> >>> ah.jp.nec.com at lists.launchpad.ne
> >>> t] On Behalf Of 石井 久治
> >>> Sent: Thursday, February 10, 2011 8:48 PM
> >>> To: openstack at lists.launchpad.net
> >>> 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 at lists.launchpad.net
> >>>
>
> >>> [mailto:openstack-bounces<openstack-bounces>+ewan.mellor=
> >>> citrix.com at lists.launchpad.net
> >>>
> >>> ]
> >>> On Behalf Of Masanori ITOH
> >>> Sent: 31 January 2011 10:31
> >>> To: openstack at lists.launchpad.net
> >>> 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 at openstack.org>
> >>> 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 at lists.launchpad.net
> >>>
>
> >>> [mailto:openstack-bounces<openstack-bounces>+john=
> >>> openstack.org at lists.launchpad.net]
> >>>
> >>> On
> >>>
> >>> Behalf
> >>>
> >>> Of Thierry Carrez
> >>> Sent: Friday, January 28, 2011 1:52 PM
> >>> To: openstack at lists.launchpad.net
> >>> 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 at lists.launchpad.net
> >>> Unsubscribe : https://launchpad.net/~openstack
> >>> More help : https://help.launchpad.net/ListHelp
> >>>
> >>>
> >>> _______________________________________________
> >>> Mailing list: https://launchpad.net/~openstack
> >>> Post to : openstack at lists.launchpad.net
> >>> Unsubscribe : https://launchpad.net/~openstack
> >>> More help : https://help.launchpad.net/ListHelp
> >>>
> >>>
> >>> _______________________________________________
> >>> Mailing list: https://launchpad.net/~openstack
> >>> Post to : openstack at lists.launchpad.net
> >>> Unsubscribe : https://launchpad.net/~openstack
> >>> More help : https://help.launchpad.net/ListHelp
> >>>
> >>>
> >>> _______________________________________________
> >>> Mailing list: https://launchpad.net/~openstack
> >>> Post to : openstack at lists.launchpad.net
> >>> Unsubscribe : https://launchpad.net/~openstack
> >>> More help : https://help.launchpad.net/ListHelp
> >>>
> >>> _______________________________________________
> >>> Mailing list: https://launchpad.net/~openstack
> >>> Post to : openstack at lists.launchpad.net
> >>> Unsubscribe : https://launchpad.net/~openstack
> >>> More help : https://help.launchpad.net/ListHelp
> >>>
> >>> Attachments:
> >>> - smime.p7s
> >>>
> >>>
> >>> _______________________________________________
> >>> Mailing list: https://launchpad.net/~openstack
> >>> Post to : openstack at lists.launchpad.net
> >>> Unsubscribe : https://launchpad.net/~openstack
> >>> More help : https://help.launchpad.net/ListHelp
> >>>
> >>>
> >>> _______________________________________________ Mailing list:
> >>> https://launchpad.net/~openstack Post to :
> openstack at 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 at rackspace.com, and delete the original message.
> >>> Your cooperation is appreciated.
> >>>
> >>>
> >>
> >
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack at lists.launchpad.net
> 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 at rackspace.com, and delete the original message.
>
> Your cooperation is appreciated.
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack at lists.launchpad.net
> 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110221/9c1dc294/attachment.html>
More information about the Openstack
mailing list