2011/2/14 石井 久治 <[email protected]> > Hi Salvatore, > > Thank you for your questions and suggestions. > > > If I got your design right, the network manager in the current nova >> implementation (Flat & VLAN) will become plugins. And a plugin can be >> divided into a "management" component (the one which runs on the network >> node) and an "agent" (the component running on the compute node). Is that >> correct? >> > Yes, it's exactly correct. > > > implies that there should be an association between the network entity and >> the plugin type. >> > In my current opinion, the network plugins should be possible to be > selected per project instead of network. When a project is created, the user > should be allowed to specify which type of plugin to use. After that, the > user should be allowed to get the plugin to create network with plugin > specific parameters. For this reason a column which describes the plugin > type should be added to the project table of the DB and the type of plugin > should be added to the create_project method as an optional parameter. > > > I'm not totally sure about the virtual port concept. Do we really need it? >> Wouldn't be easier to have a model in which VIF are directly connected to >> logical switches and virtual port are implicitly assigned? >> > I also think that your design is simpler. > However for example considering live migration of VM, the concepts of > "virtual port" can assure the compute manager that the network environment > behind the port will be kept.
+1 for having separate virtual NIC and virtual port concepts. Those are different kinds of resources: - a virtual NIC is a resource of the host where the VM with that NIC is running, and may be as little as a TAP interface, or as much as a dedicated hardware network interface; - a virtual port is a network resource, and may correspond to QoS guarantees (e.g. minimum rate, maximum delay, etc.), a given network topology it gives access to, packet filtering settings (iptables-like rules), etc. One will typically want to control and identify those resources separately. > > > Finally, have you already got some design ideas concerning how to provide >> L4/L7 services (for instance firewall, DHCP, DNS, load balancing, etc.) to >> nova networks? >> > I'm designing only how to migrate current network model(firewall and DHCP) > to the plugin now. > > Cheers, > Hisaharu Ishii > > > > (2011/02/11 1:19), Salvatore Orlando wrote: > >> Hi Hisaharu, >> >> Thanks for sharing this design proposal and the POC code. >> I will have a look at the code as soon as possible. >> At a first glance, I think the design that you are proposing is in line >> with the goals of the network service blueprint ( >> http://wiki.openstack.org/NetworkService) >> >> If I got your design right, the network manager in the current nova >> implementation (Flat& VLAN) will become plugins. And a plugin can be >> divided into a "management" component (the one which runs on the network >> node) and an "agent" (the component running on the compute node). Is that >> correct? >> Also, from your design it seems it should be possible to have different >> plugins running together in the same deployment. This makes a lot of sense >> to me, and IMHO, implies that there should be an association between the >> network entity and the plugin type. When a network is created, the user >> should be allowed to specify which type of plugin should be handling that >> network. For this reason I think maybe the create_network API should accept >> the type of plugin as an optional parameter, in order to route the request >> to the appropriate network node. If no parameter is provided then the >> request would be routed to a 'default' network node. >> I also noticed you are introducing the concepts of "logical switch" and >> "virtual port". While I totally agree on the logical switch concept, I'm not >> totally sure about the virtual port concept. Do we really need it? Wouldn't >> be easier to have a model in which VIF are directly connected to logical >> switches and virtual port are implicitly assigned? >> >> Finally, have you already got some design ideas concerning how to provide >> L4/L7 services (for instance firewall, DHCP, DNS, load balancing, etc.) to >> nova networks? >> >> Cheers, >> Salvatore >> >> -----Original Message----- >> From: openstack-bounces+salvatore.orlando=eu.citrix.com@ >> lists.launchpad.net [mailto:openstack-bounces+salvatore.orlando= >> [email protected]] On Behalf Of ?? ?? >> Sent: 10 February 2011 11:48 >> To: [email protected] >> 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: [email protected] >>>>> [mailto:[email protected] >>>>> ] >>>>> On Behalf Of Masanori ITOH >>>>> Sent: 31 January 2011 10:31 >>>>> To: [email protected] >>>>> 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<[email protected]> >>>>> 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: [email protected] >>>>>> [mailto:[email protected]] >>>>>> On >>>>>> >>>>> Behalf >>>>> >>>>>> Of Thierry Carrez >>>>>> Sent: Friday, January 28, 2011 1:52 PM >>>>>> To: [email protected] >>>>>> 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 : [email protected] >>>>>> Unsubscribe : https://launchpad.net/~openstack >>>>>> More help : https://help.launchpad.net/ListHelp >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Mailing list: https://launchpad.net/~openstack >>>>>> Post to : [email protected] >>>>>> Unsubscribe : https://launchpad.net/~openstack >>>>>> More help : https://help.launchpad.net/ListHelp >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~openstack >>>>> Post to : [email protected] >>>>> Unsubscribe : https://launchpad.net/~openstack >>>>> More help : https://help.launchpad.net/ListHelp >>>>> >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~openstack >>>> Post to : [email protected] >>>> Unsubscribe : https://launchpad.net/~openstack >>>> More help : https://help.launchpad.net/ListHelp >>>> >>>> >>> >>> >> >> >> > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
