I now think the right approach is to move to shift the implementation
of network operations to
'nova' cli and giving up 'nova-manage' cli for a permanent solution because:
a. use of nova-manage sub-cmds seems to be deprecated.
b. nova cli accepts tokens and have caching options
c. other projects s
Yes we did play around with Quantum some time back. But it needs more work.
Our goal is to de-centralize nova network using Openvswitch,
Controller for openvswitch & flowvisor. For Quantum, we would expect
it to hold network information like network nodes, existing network
slices and other relaven
Hi Dave,
Thanks for sharing this. I had been independently working on this a few
days back, and wanted to compare notes with you (I saw other emails as
well on this topic, hence thought it might be helpful to have a broader
discussion).
For the localrc files,
* Would it be better to use HOST_IP_
Yes, Rohit these changes are valid. The thing you pointed out about
making authentication working
with Devstack and Quantum is also perfect. I didn't propose to update
the documentation because
things are not perfect and I needed to test everything.
In the other email thread "Enabling Quantum Auth
Hi Salvatore,
Thanks for this nice synopsis of the issues that need consideration.
Specifically on the topic of VIF drivers - I do agree that it's rather
cumbersome to deal with Quantum drivers in Nova. I think this issue
would have been much easier to tackle with if there was one generic
mechan
I had tried to resolve this issue at my end just prior to RC1 period as
well (had pointed it out to a limited group then). Couple of config
changes in quantum.conf that worked for me are as follows -
[filter:authN]
#this is using the default auth_token.py in keystone middleware
paste.filter_
Hi Gary,
The Quantum Administrator Guide has a section on Quantum + Keystone:
http://docs.openstack.org/incubation/openstack-network/admin/content/ch_quantum-keystone-authn-authz.html
Unfortunately, it seems like these instructions are out of date, as the
quantum middleware seems to have been rem
Hi Dan:
I am new to this project, so please bear with newbie questions ...
perhaps my wiki-fu is just weak today!
To participate on basic community projects like these, how do we get
started? (in terms of co-ordination with others who might be working
on it already, or even other teams like horiz
Hi Dan:
I have been working on that as well, and can help with that. How do I get
started with that? Is there a blueprint to work with, or should I followup
directly with devstack developers?
Regards,
Mandeep
On Tue, Feb 21, 2012 at 1:17 PM, Dan Wendlandt wrote:
> Hi folks,
>
> Its seems we ha
Hi Netstackers,
It's good to see so many people contributing to this discussion. I particularly
appreciate the fact that a lot of the contributors to this thread are not among
the 'usual' Quantum faces... this surely means the community is growing!
It is my opinion that during Folsom we should
On 03/20/2012 01:53 AM, Dan Wendlandt wrote:
> Not sure how many people might be on netstack but not the main openstack
> ML, but Thierry cut the official version of the Quantum RC1 today.
>
> I'm working with folks from Red Hat & Ubuntu to get binary packages
> based on the RC1 for final testing
+1 to scalability. I put a placeholder session already for that I
think you need to consider openstack scalability as a whole w. Quantum -
also related to our scale testing infra for quantum+nova.
debo
-Original Message-
From: netstack-bounces+dedutta=cisco@lists.launchpad.net
[
We would also like to cover some topics that relate to running Quantum at
scale. This would include API rate limiting and caching, understanding the
models for scaling out the service and where we should make things more
asynchronous (or not) to enable increased throughput.
As far as votes for
On Wed, Mar 21, 2012 at 9:04 AM, Sumit Naiksatam (snaiksat)
wrote:
> Hi Tomasz,
>
> A few points to note, and this might make things clearer:
>
> * The gateway initialization happens in a separate driver (I am referring to
> the part of the code which you did not find), please take a look at the
Thanks Jason for the idea.
I am not sure how good is an idea of running two endpoints for quantum
- one with 'noauth' and one with 'keystone'.
If you have seen any such use case with other services please let me know.
Nova defines two piplines: 'noauth' and 'keystone' and it chooses
between them
Hi Tomasz,
A few points to note, and this might make things clearer:
* The gateway initialization happens in a separate driver (I am referring to
the part of the code which you did not find), please take a look at the
QuantumLinuxBridgeInterfaceDriver class inside:
nova/network/linux_net.py
*
Hi,
Comments inline
On Wed, Mar 21, 2012 at 12:18 AM, Sumit Naiksatam (snaiksat)
wrote:
>
> Hi Tomasz,
>
>
>
> Thanks for your note. I am not sure I completely understand the problems you
> are facing. Please note that the patch you have referred to introduces the
> VIF-driver for Quantum’s Li
17 matches
Mail list logo
