Re: [Netstack] [Quantum] plugin -> backend

Yes, we've had this discussion many times :) I agree that people find the term "plugin" confusing, but each time we've talked about it, we've failed to find a single term that is substantially better to warrant the confusion likely to be caused by renaming. In some cases I've started using the te

Re: [Netstack] [Quantum][Nova] requested_id and port spec

Hi Yong > Hi Nachi, > It is seemingly a way to make it work, but I think we are thinking to > provide 'port-id' or just 'port' to specify the top resource in quantum API. > fix ip is not one. > > Besides, Port can be assigned to more than one fixed IP. Ah, It it true. OK I'll implement port id ve

Re: [Netstack] [Quantum] plugin -> backend

Hi, I believe there are two topics of discussion here, one of which is the terminology. The way things are implemented today, I agree that the “plugin” terminology seems a bit confusing. However, probably the bigger topic of discussion is what kind of a design is preferable, “backend” versus “p

Re: [Netstack] [Quantum][Nova] requested_id and port spec

Hi Nachi,It is seemingly a way to make it work, but I think we are thinking to provide 'port-id' or just 'port' to specify the top resource in quantum API. fix ip is not one.Besides, Port can be assigned to more than one fixed IP.Imagine in horizon, we created many networks, ports and subnets, but

Re: [Netstack] [Quantum] plugin -> backend

Hi,Add it into openstack-dev and [quantum] into the subject.Yes, 'backend' seems better than 'plugin' for our case here.Our plugin is a must for quantum server to work,  while 'plugin' tends to make us think it will provide more functionalities if we plug it in.And I don't think our plugin is 'plu

[Netstack] [Quantum][Nova] requested_id and port spec

Hi Dan,folks As we talked in netstack IRC meetins, I submit this as bug. https://bugs.launchpad.net/nova/+bug/1031096 I tried to write this, but the code looks very ugly in order to keep backward compatibility. So I wanna propose an alternative design. In this design, we will use fixed_ip as a t

[Netstack] plugin -> backend

Æ!! Hi folks! I was concerned to bring the "plugins" discussion because it looks like a bikeshedding and it probably was discussed before, but I think it will be beneficial at all. What motivated me to bring the discussion was the Metaplugin implementation (https://review.openstack.org/#/c/1018

Re: [Netstack] Openstack+Quantum+OVS Internals - Doubts

Also I hope you have gone through this, http://docs.openstack.org/api/openstack-network/1.0/content/ Thanks, Hitesh On Mon, Jul 30, 2012 at 7:17 AM, hitesh wadekar wrote: > Hi Trinath, > > Can you please check out this pdf and let me know your questions get > resolved or not? > > ( > http://qco

Re: [Netstack] Openstack+Quantum+OVS Internals - Doubts

Hi Trinath, Can you please check out this pdf and let me know your questions get resolved or not? ( http://qconlondon.com/dl/qcon-london-2012/slides/SalvatoreOrlando_QuantumVirtualNetworksForOpenStackClouds.pdf Also, whatever Darragh has been given links also useful. I will update you more on t

Re: [Netstack] Openstack+Quantum+OVS Internals - Doubts

Hi, I saved this sequence diagram some time ago. But I can't remember where I got it.  https://docs.google.com/open?id=0B0HB7skV7D-ATWZ1R1I5VlYyNFk It is correct for Essex, but I don't know about Folsom. Regards, Darragh. > > From: Trinath Somanchi >To: ""

[Netstack] Openstack+Quantum+OVS Internals - Doubts

Hi Guys- I have found the solution to my Second Doubt Link: http://docs.openstack.org/developer/nova/devref/rpc.html and Thanks Emilien for clearing my 3rd Doubt. But still in need of help. Can you any one validate my understanding with the data flow in Nova+Quantum scenario for bringing up t