<div>
            <div><p style="color: #a0a0a0;"><font class="Apple-style-span" color="#000000">Hi Ishii-san,</font></p><p style="color: #a0a0a0;"><font class="Apple-style-span" color="#000000"></font>On Tuesday, February 15, 2011 at 16:28, 石井 久治 wrote:</p>
                <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
                    <span><div><div>Hello Hiroshi-san<br><br> >> Do you mean that the former API is an interface that is<br> >> defined in OpenStack project, and the latter API is<br> >> a vendor specific API?<br> > My understanding is that yes, that's what he means.<br><br>I also think so.<br><br>In addition, I feel it is issue that what network functions should be <br>defined as generic API, and what network functions should be defined as <br>plugin specific API.<br>How do you think ?</div></div></span></blockquote><div>I propose to apply the following criteria to determine which operations belong to the generic API:</div><div>- any operation called by the compute service (Nova) directly MUST belong to the generic API;</div><div>- any operation called by users (REST API, etc.) MAY belong to the generic API;</div><div>- 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.</div><div><br></div><div>How about that?</div><div><br></div><div>Regards,</div><div>--</div><div>Romain Lenglet</div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><span></span><span></span><br><br>Thanks<br>Hisaharu Ishii<br><br><br>(2011/02/15 16:18), Romain Lenglet wrote:<br><blockquote type="cite"><div>Hi Hiroshi,<br>On Tuesday, February 15, 2011 at 15:47, Hiroshi DEMPO wrote:<br>Hello Hisaharu san<br><blockquote type="cite"><div><br>I am not sure about the differences between generic network API and<br>plugin X specific network service API.<br><br>Do you mean that the former API is an interface that is<br>defined in OpenStack project, and the latter API is<br>a vendor specific API?<br></div></blockquote><br>My understanding is that yes, that's what he means.<br><br>--<br>Romain Lenglet<br><blockquote type="cite"><div><br><br>Thanks<br>Hiroshi<br><br><blockquote type="cite"><div>-----Original Message-----<br>From: openstack-bounces+dem=<a href="mailto:ah.jp.nec.com@lists.launchpad.net">ah.jp.nec.com@lists.launchpad.net</a><br>[<a href="mailto:openstack-bounces">mailto:openstack-bounces</a>+dem=<a href="mailto:ah.jp.nec.com@lists.launchpad.ne">ah.jp.nec.com@lists.launchpad.ne</a><br>t] On Behalf Of 石井 久治<br>Sent: Thursday, February 10, 2011 8:48 PM<br>To: <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>Subject: Re: [Openstack] Network Service for L2/L3 Network<br>Infrastructure blueprint<br><br>Hi, all<br><br>As we have said before, we have started designing and writing<br>POC codes of network service.<br><br><blockquote type="cite"><div>- I know that there were several documents on the new network<br>service issue that were locally exchanged so far.<br>Why not collecting them into one place and share them<br></div></blockquote>publicly?<br><br>Based on these documents, I created an image of<br>implementation (attached). And I propose the following set of<br>methods as the generic network service APIs.<br>- create_vnic(): vnic_id<br> Create a VNIC and return the ID of the created VNIC.<br>- list__vnics(vm_id): [vnic_id]<br>  Return the list of vnic_id, where vnic_id is the ID of a VNIC.<br>- destroy_vnic(vnic_id)<br>  Remove a VNIC from its VM, given its ID, and destroy it.<br>- plug(vnic_id, port_id)<br>  Plug the VNIC with ID vnic_id into the port with ID<br>port_id managed by this network service.<br>- unplug(vnic_id)<br>  Unplug the VNIC from its port, previously plugged by<br>calling plug().<br>- create_network(): network_id<br>  Create a new logical network.<br>- list_networks(project_id): [network_id]<br>  Return the list of logical networks available for<br>project with ID project_id.<br>- destroy_network(network_id)<br>  Destroy the logical network with ID network_id.<br>- create_port(network_id): port_id<br>  Create a port in the logical network with ID<br>network_id, and return the port's ID.<br>- list_ports(network_id): [port_id]<br>  Return the list of IDs of ports in a network given its ID.<br>- destroy_port(port_id)<br>  Destroy port with ID port_id.<br><br>This design is a first draft.<br>So we would appreciate it if you would give us some comments.<br><br>In parallel with it, we are writing POC codes and uploading<br>it to "lp:~ntt-pf-lab/nova/network-service".<br><br>Thanks,<br>Hisaharu Ishii<br><br><br>(2011/02/02 19:02), Koji IIDA wrote:<br><blockquote type="cite"><div>Hi, all<br><br><br>We, NTT PF Lab., also agree to discuss about network service at the<br>Diablo DS.<br><br>However, we would really like to include network service in<br></div></blockquote>the Diablo<br><blockquote type="cite"><div>release because our customers strongly demand this feature. And we<br>think that it is quite important to merge new network<br></div></blockquote>service to trunk<br><blockquote type="cite"><div>soon after Diablo DS so that every developer can contribute their<br>effort based on the new code.<br><br>We are planning to provide source code for network service<br></div></blockquote>in a couple<br><blockquote type="cite"><div>of weeks. We would appreciate it if you would review it<br></div></blockquote>and give us<br><blockquote type="cite"><div>some feedback before the next design summit.<br><br>Ewan, thanks for your making new entry at wiki page (*1).<br></div></blockquote>We will also<br><blockquote type="cite"><div>post our comments soon.<br><br>(*1) <a href="http://wiki.openstack.org/NetworkService">http://wiki.openstack.org/NetworkService</a><br><br><br>Thanks,<br>Koji Iida<br><br><br>(2011/01/31 21:19), Ewan Mellor wrote:<br><blockquote type="cite"><div>I will collect the documents together as you suggest, and<br></div></blockquote></div></blockquote>I agree that we need to get the requirements laid out again.<br><blockquote><blockquote type="cite"><div><br>Please subscribe to the blueprint on Launchpad -- that way<br></div></blockquote></blockquote>you will be notified of updates.<br><blockquote><blockquote type="cite"><div><br><a href="https://blueprints.launchpad.net/nova/+spec/bexar-network-service">https://blueprints.launchpad.net/nova/+spec/bexar-network-service</a><br><br>Thanks,<br><br>Ewan.<br><br><blockquote type="cite"><div>-----Original Message-----<br>From: openstack-bounces+ewan.mellor=<a href="mailto:citrix.com@lists.launchpad.net">citrix.com@lists.launchpad.net</a><br></div></blockquote></div></blockquote></blockquote>[<a href="mailto:openstack-bounces">mailto:openstack-bounces</a>+ewan.mellor=<a href="mailto:citrix.com@lists.launchpad.net">citrix.com@lists.launchpad.net</a><br><blockquote><blockquote><blockquote type="cite"><div>]<br>On Behalf Of Masanori ITOH<br>Sent: 31 January 2011 10:31<br>To: <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>Subject: Re: [Openstack] Network Service for L2/L3 Network<br>Infrastructure blueprint<br><br>Hello,<br><br>We, NTT DATA, also agree with majority of folks.<br>It's realistic shooting for the the Diablo time frame to have the<br>new network service.<br><br>Here are my suggestions:<br><br>  - I know that there were several documents on the new network<br>service issue<br>  that were locally exchanged so far.<br>  Why not collecting them into one place and share them<br></div></blockquote></blockquote></blockquote>publicly?<br><blockquote><blockquote><blockquote type="cite"><div><br>  - I know that the discussion went into a bit<br></div></blockquote></blockquote></blockquote>implementation details.<br><blockquote><blockquote><blockquote type="cite"><div>  But now, what about starting the discussion from the<br></div></blockquote></blockquote></blockquote>higher level<br><blockquote><blockquote><blockquote type="cite"><div>  design things (again)? Especially, from the<br></div></blockquote></blockquote></blockquote>requirements level.<br><blockquote><blockquote><blockquote type="cite"><div><br>Any thoughts?<br><br>Masanori<br><br><br>From: John Purrier<<a href="mailto:john@openstack.org">john@openstack.org</a>><br>Subject: Re: [Openstack] Network Service for L2/L3 Network<br>Infrastructure blueprint<br>Date: Sat, 29 Jan 2011 06:06:26 +0900<br><br><blockquote type="cite"><div>You are correct, the networking service will be more<br></div></blockquote></div></blockquote></blockquote></blockquote>complex than<br><blockquote><blockquote><blockquote type="cite"><div><blockquote type="cite"><div>the<br></div></blockquote>volume<br><blockquote type="cite"><div>service. The existing blueprint is pretty comprehensive,<br></div></blockquote></div></blockquote></blockquote></blockquote>not only<br><blockquote><blockquote><blockquote type="cite"><div><blockquote type="cite"><div>encompassing the functionality that exists in today's network<br>service<br></div></blockquote>in<br><blockquote type="cite"><div>Nova, but also forward looking functionality around flexible<br>networking/openvswitch and layer 2 network bridging<br></div></blockquote></div></blockquote></blockquote></blockquote>between cloud<br><blockquote><blockquote><blockquote type="cite"><div><blockquote type="cite"><div>deployments.<br><br>This will be a longer term project and will serve as the bedrock<br>for<br></div></blockquote>many<br><blockquote type="cite"><div>future OpenStack capabilities.<br><br>John<br><br>-----Original Message-----<br>From: openstack-bounces+john=<a href="mailto:openstack.org@lists.launchpad.net">openstack.org@lists.launchpad.net</a><br></div></blockquote></div></blockquote></blockquote></blockquote>[<a href="mailto:openstack-bounces">mailto:openstack-bounces</a>+john=<a href="mailto:openstack.org@lists.launchpad.net">openstack.org@lists.launchpad.net</a>]<br><blockquote><blockquote><blockquote type="cite"><div><blockquote type="cite"><div>On<br></div></blockquote>Behalf<br><blockquote type="cite"><div>Of Thierry Carrez<br>Sent: Friday, January 28, 2011 1:52 PM<br>To: <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>Subject: Re: [Openstack] Network Service for L2/L3 Network<br></div></blockquote>Infrastructure<br><blockquote type="cite"><div>blueprint<br><br>John Purrier wrote:<br><blockquote type="cite"><div>Here is the suggestion. It is clear from the response<br></div></blockquote></div></blockquote></div></blockquote></blockquote></blockquote>on the list<br><blockquote><blockquote><blockquote type="cite"><div>that<br><blockquote type="cite"><div>refactoring Nova in the Cactus timeframe will be too risky,<br></div></blockquote>particularly as<br><blockquote type="cite"><div>we are focusing Cactus on Stability, Reliability, and<br></div></blockquote></div></blockquote></blockquote></blockquote>Deployability<br><blockquote><blockquote><blockquote type="cite"><div>(along<br><blockquote type="cite"><div>with a complete OpenStack API). For Cactus we should leave the<br></div></blockquote>network and<br><blockquote type="cite"><div>volume services alone in Nova to minimize destabilizing the code<br></div></blockquote>base. In<br><blockquote type="cite"><div>parallel, we can initiate the Network and Volume Service<br></div></blockquote></div></blockquote></blockquote></blockquote>projects<br><blockquote><blockquote><blockquote><blockquote type="cite"><div>in Launchpad and allow the teams that form around these<br></div></blockquote></blockquote></blockquote></blockquote>efforts to<br><blockquote><blockquote><blockquote type="cite"><div><blockquote type="cite"><div>move<br></div></blockquote>in<br><blockquote type="cite"><div>parallel, perhaps seeding their projects from the<br></div></blockquote></div></blockquote></blockquote></blockquote>existing Nova code.<br><blockquote><blockquote><blockquote type="cite"><div><blockquote><blockquote type="cite"><div><br>Once we complete Cactus we can have discussions at the Diablo DS<br></div></blockquote></blockquote>about<br><blockquote type="cite"><div>progress these efforts have made and how best to move<br></div></blockquote></div></blockquote></blockquote></blockquote>forward with<br><blockquote><blockquote><blockquote type="cite"><div>Nova<br><blockquote type="cite"><div>integration and determine release targets.<br><br>I agree that there is value in starting the proof-of-concept work<br></div></blockquote>around<br><blockquote type="cite"><div>the network services, without sacrificing too many developers to<br>it,<br></div></blockquote>so<br><blockquote type="cite"><div>that a good plan can be presented and discussed at the<br></div></blockquote></div></blockquote></blockquote></blockquote>Diablo Summit.<br><blockquote><blockquote><blockquote type="cite"><div><blockquote type="cite"><div><br>If volume sounds relatively simple to me, network sounds<br></div></blockquote>significantly<br><blockquote type="cite"><div>more complex (just looking at the code ,network manager code is<br>currently used both by nova-compute and nova-network to<br></div></blockquote></div></blockquote></blockquote></blockquote>modify the<br><blockquote><blockquote><blockquote type="cite"><div>local<br><blockquote type="cite"><div>networking stack, so it's more than just handing out IP<br></div></blockquote></div></blockquote></blockquote></blockquote>addresses<br><blockquote><blockquote type="cite"><div><blockquote type="cite"><div><blockquote type="cite"><div>through an API).<br><br>Cheers,<br><br>--<br>Thierry Carrez (ttx)<br>Release Manager, OpenStack<br><br>_______________________________________________<br>Mailing list: <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>Unsubscribe : <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>More help : <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a><br><br><br>_______________________________________________<br>Mailing list: <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>Unsubscribe : <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>More help : <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a><br></div></blockquote><br>_______________________________________________<br>Mailing list: <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>Unsubscribe : <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>More help : <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a><br></div></blockquote><br>_______________________________________________<br>Mailing list: <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>Unsubscribe : <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>More help : <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a><br></div></blockquote></blockquote></div></blockquote>_______________________________________________<br>Mailing list: <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>Unsubscribe : <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>More help : <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a><br><br>Attachments:<br>- smime.p7s<br></div></blockquote></div></blockquote><br>_______________________________________________<br>Mailing list: <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>Unsubscribe : <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>More help   : <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a><br></div></div></span>
                
                
                
                
                </blockquote>
                
                <div>
                    <br>
                </div>
            </div>
        </div>