Open Stack

2011/2/14 石井 久治 <ishii.hisaharu at lab.ntt.co.jp>

> 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=
>> eu.citrix.com at lists.launchpad.net] On Behalf Of ?? ??
>> Sent: 10 February 2011 11:48
>> 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+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+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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110214/438ef694/attachment.html>