Hello.
If we have two computes, and each is network node, that means both hosts
a router.
Let say we have two tenants with two instance and two compute hosts.
Compute1-tenant1-instance1
compute2-tenant2-instance2
But neutron have no idea about this. Someone asks him 'put router to any
l3-ag
On 12/20/2014 11:16 PM, George Shuklin wrote:
> do 'network node on compute' is kinda sad
Why?
Thomas
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Directions:
nova->switch port, switch port -> glance, glance->switch port (to
swift). I assume traffic from switch to swift outside installation.
Glance-api receive and send same amount of traffic. It sounds like a
minor issue until you starts to count CPU IRQ time of network card
(doubled co
This is great info, George.
Could you explain the 3x snapshot transport under the traditional Glance
setup, please?
I understand that you have compute —> glance, and glance —> swift. But
what’s the third transfer?
Thanks!
Mike
On 1/21/15, 10:36 AM, "George Shuklin" wrote:
>Ok, news so
Ok, news so far:
It works like a magic. Nova have option
[glance]
host=127.0.0.1
And I do not need to cheat with endpoint resolving (my initial plan was
to resolve glance endpoint to 127.0.0.1 with /etc/hosts magic). Normal
glance-api reply to external clients requests
(image-create/download/
+1
On Sun, Jan 18, 2015 at 10:05 PM, Jay Pipes wrote:
> On 01/15/2015 05:20 PM, George Shuklin wrote:
>
>> Hello everyone.
>>
>> One more thing in the light of small openstack.
>>
>> I really dislike tripple network load caused by current glance snapshot
>> operations. When compute do snapshot,
On 01/15/2015 05:20 PM, George Shuklin wrote:
Hello everyone.
One more thing in the light of small openstack.
I really dislike tripple network load caused by current glance snapshot
operations. When compute do snapshot, it playing with files locally,
than it sends them to glance-api, and (if gl
On Dec 22, 2014 1:58 PM, "Tom Fifield" wrote:
>
> On 21/12/14 08:09, matt wrote:
> > the only issue with nova-network here is that it's FINALLY slated to be
> > removed in the next release.
This is simply not true. While we are trying to deprecate nova network this
hasn't happened yet.
>
> Is it
We do not using centralized storages (all instances running with local
drives). And I just can't express my happiness about this. Every time
monitoring send me '** PROBLEM ALERT bla-bla-bla', I know it not a big
deal. Just one server.
I do not want to turn gray prematurely. Just light glance o
That specific bottleneck can be solved by running glance on ceph, and
running ephemeral instances also on ceph. Snapshots are a quick backend
operation then. But you've made your installation on a house of cards.
On Thursday, January 15, 2015, George Shuklin
wrote:
> Hello everyone.
>
> One more
Hello everyone.
One more thing in the light of small openstack.
I really dislike tripple network load caused by current glance snapshot
operations. When compute do snapshot, it playing with files locally,
than it sends them to glance-api, and (if glance API is linked to
swift), glance sends t
forgot to send this email before
On 01/09/2015 12:50 AM, Kris G. Lindgren wrote:
>>> neutron net-create --shared should do the trick
>>
>> I guess the problem is that I was creating *external* _and_ *shared*
>> network, but if I don't want to use floating IPs from that network I
>> probably don't
Wow. Real problem. I check it - it allows one tenant to interrupt
traffic on other. I was not able to intercept TCP traffic, victim lost
connection and TCP was struggling with retransmissions, but it was not
good.
But idea of 'no routers in software' is too appealing. I think I'll
stick with
George,
>From past experience you can not have both nova and neutron security
groups enabled at the same time.
If you use nova security groups - then I believe they have the appropriate
stuff in place to prevent the arp spoofing and other associated stuff.
However - if you want the ability to app
On 01/09/2015 09:25 PM, Kris G. Lindgren wrote:
> Also, If you are running this configuration you should be aware of the
> following bug:
>
> https://bugs.launchpad.net/neutron/+bug/1274034
>
> And the corresponding fix: https://review.openstack.org/#/c/141130/
>
> Basically - Neutron security grou
Also, If you are running this configuration you should be aware of the
following bug:
https://bugs.launchpad.net/neutron/+bug/1274034
And the corresponding fix: https://review.openstack.org/#/c/141130/
Basically - Neutron security group rules do nothing to protect against arp
spoofing/poisoning
On 1/8/15, 4:34 AM, "Antonio Messina" wrote:
>On Thu, Jan 8, 2015 at 12:12 PM, gustavo panizzo (gfa)
>wrote:
>>
>>
>> On 01/08/2015 07:01 PM, Antonio Messina wrote:
>>>
>>> On Thu, Jan 8, 2015 at 11:53 AM, gustavo panizzo (gfa)
>>>
>>> wrote:
>>
>>
i may be wrong as i haven't tested
On Thu, Jan 8, 2015 at 12:12 PM, gustavo panizzo (gfa)
wrote:
>
>
> On 01/08/2015 07:01 PM, Antonio Messina wrote:
>>
>> On Thu, Jan 8, 2015 at 11:53 AM, gustavo panizzo (gfa)
>> wrote:
>
>
>>>
>>> i may be wrong as i haven't tested that on juno, but in icehouse and
>>> havana
>>> i've setup ext
On 01/08/2015 07:01 PM, Antonio Messina wrote:
On Thu, Jan 8, 2015 at 11:53 AM, gustavo panizzo (gfa)
wrote:
i may be wrong as i haven't tested that on juno, but in icehouse and havana
i've setup external/provider networks one for each tenant
Ah, ok, this is the point. What I would like
On Thu, Jan 8, 2015 at 11:53 AM, gustavo panizzo (gfa)
wrote:
> On 01/08/2015 06:36 PM, Antonio Messina wrote:
>> On Fri, Dec 26, 2014 at 12:31 AM, George Shuklin
>> wrote:
>>>
>>> Report on progress so far:
>>>
>>> I was able to fix policies (nova/neutron) to allow tennants to plug to
>>> 'own'
On 01/08/2015 06:36 PM, Antonio Messina wrote:
Hi all, I'm also interested in this setup.
On Fri, Dec 26, 2014 at 12:31 AM, George Shuklin
wrote:
Report on progress so far:
I was able to fix policies (nova/neutron) to allow tennants to plug to 'own'
external networks, found and report few b
Hi all, I'm also interested in this setup.
On Fri, Dec 26, 2014 at 12:31 AM, George Shuklin
wrote:
> Report on progress so far:
>
> I was able to fix policies (nova/neutron) to allow tennants to plug to 'own'
> external networks, found and report few bugs about error messaging in ML2,
> got worki
Report on progress so far:
I was able to fix policies (nova/neutron) to allow tennants to plug to
'own' external networks, found and report few bugs about error messaging
in ML2, got working dhcp-agent (on external network! haha). Right now it
works with cirros (even metadata is ok), but does
quot;
mailto:openstack-operators@lists.openstack.org>>
Subject: Re: [Openstack-operators] Small openstack
Sounds like a solid way to approach it george. I hope you can document and
share your methods and experiences.
Sounds like this would be helpful to folks setting up small test environm
Sounds like a solid way to approach it george. I hope you can document and
share your methods and experiences.
Sounds like this would be helpful to folks setting up small test
environments.
On Mon, Dec 22, 2014 at 4:35 PM, George Shuklin
wrote:
> Thank you for everyone!
>
> After some lurking
Thank you for everyone!
After some lurking around I found rather unusual way: use external
networks on per-tennant based with directly attached interfaces. This
will not only eliminate neutron nodes (as heavy server), but will remove
NAT and simplify everything for tenant. All we need just a s
On 21/12/14 08:09, matt wrote:
> the only issue with nova-network here is that it's FINALLY slated to be
> removed in the next release.
Is it? :) Based on recent emails, it seems like the requisite migration
path might not make it (and here's also hoping that DVR improves). The
other thing to note
On 12/20/14 2:16 PM, George Shuklin wrote:
I've suddenly got request for small installation of openstack (about 3-5
computes).
They need almost nothing (just a management panel to span simple
instances, few friendly tennants), and I curious, is nova-network good
solution for this? They don't wa
On 12/21/2014 10:42 AM, Xav Paice wrote:
On 21/12/14 11:16, George Shuklin wrote:
Hello.
I've suddenly got request for small installation of openstack (about
3-5 computes).
They need almost nothing (just a management panel to span simple
instances, few friendly tennants), and I curious, is nov
On 21/12/14 11:16, George Shuklin wrote:
> Hello.
>
> I've suddenly got request for small installation of openstack (about
> 3-5 computes).
>
> They need almost nothing (just a management panel to span simple
> instances, few friendly tennants), and I curious, is nova-network good
> solution for th
And network node goes to...? I mean, you suggest to use one compute as
network node? IMHO it gonna be really unbalanced. And
neutron-on-the-every-compute (DVVR) is tech. preview yet...
On 12/21/2014 01:09 AM, matt wrote:
the only issue with nova-network here is that it's FINALLY slated to
be r
missed that last question.
yes i've put management services on compute nodes in mild production. It
works fine.
-matt
On Sat, Dec 20, 2014 at 6:09 PM, matt wrote:
> the only issue with nova-network here is that it's FINALLY slated to be
> removed in the next release.
>
> so yes it will work,
the only issue with nova-network here is that it's FINALLY slated to be
removed in the next release.
so yes it will work, and it may even be optimal for this size deployment,
but it will NOT be at all future proofed.
I'd go with neutron as of now.
-matt
On Sat, Dec 20, 2014 at 5:16 PM, George S
Hello.
I've suddenly got request for small installation of openstack (about 3-5
computes).
They need almost nothing (just a management panel to span simple
instances, few friendly tennants), and I curious, is nova-network good
solution for this? They don't want network node and do 'network n
34 matches
Mail list logo
