And for another recent one that came out yesterday:
Interesting to read for those who are using mongodb + openstack...
https://aphyr.com/posts/322-call-me-maybe-mongodb-stale-reads
-Josh
Joshua Harlow wrote:
Joshua Harlow wrote:
Kevin Benton wrote:
Timestamps are just one way (and likely
questions)
Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?
- Original Message -
From: joehuang joehu...@huawei.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Sent: Sunday, April 12, 2015 3:46:24 AM
Subject
- Original Message -
From: joehuang joehu...@huawei.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Sent: Friday, April 17, 2015 9:46:12 AM
Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?
Hi, Attila
- Original Message -
From: joehuang joehu...@huawei.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Sent: Sunday, April 12, 2015 3:46:24 AM
Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?
As Kevin
)
-Original Message-
From: Neil Jerram [mailto:neil.jer...@metaswitch.com]
Sent: Wednesday, April 15, 2015 9:46 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?
Hi again Joe, (+ list)
On 11/04/15 02:00, joehuang wrote:
Hi, Neil,
See
Huang ( Joe Huang )
-Original Message-
From: Neil Jerram [mailto:neil.jer...@metaswitch.com]
Sent: Thursday, April 16, 2015 5:15 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?
Thanks Joe, I really
questions)
Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?
Hi Joe,
Many thanks for your reply!
On 09/04/15 03:34, joehuang wrote:
Hi, Neil,
From theoretic, Neutron is like a broadcast domain, for example, enforcement of DVR and
security group has to touch each regarding host where
(not for usage questions)
Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?
Hi Joe,
Many thanks for your reply!
On 09/04/15 03:34, joehuang wrote:
Hi, Neil,
From theoretic, Neutron is like a broadcast domain, for example,
enforcement of DVR and security group has to touch each
@lists.openstack.org
Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?
Hi again Joe, (+ list)
On 11/04/15 02:00, joehuang wrote:
Hi, Neil,
See inline comments.
Best Regards
Chaoyi Huang
From: Neil Jerram [neil.jer...@metaswitch.com]
Sent
: [openstack-dev] [neutron] Neutron scaling
datapoints?
__ __
Which periodic updates did you have in mind to eliminate?
One of the
few remaining ones I can think of is sync_routers but it
would be
great if you can
Huang )
-Original Message-
From: Joshua Harlow [mailto:harlo...@outlook.com]
Sent: Monday, April 13, 2015 11:11 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?
joehuang wrote:
Hi, Kevin and Joshua
-Original Message-
From: Attila Fazekas [mailto:afaze...@redhat.com]
Sent: Monday, April 13, 2015 3:19 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?
- Original Message -
From: joehuang
- Original Message -
From: joehuang joehu...@huawei.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Sent: Sunday, April 12, 2015 1:20:48 PM
Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?
Hi, Kevin
- Original Message -
From: Kevin Benton blak...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Sent: Sunday, April 12, 2015 4:17:29 AM
Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?
So IIUC
Kevin Benton wrote:
Timestamps are just one way (and likely the most primitive), using
redis (or memcache) key/value and expiry are another (and letting
memcache or redis expire using its own internal algorithms), using
zookeeper ephemeral nodes[1] are another... The point being that its
:* Re: [openstack-dev] [neutron] Neutron scaling datapoints?
Timestamps are just one way (and likely the most primitive), using redis
(or memcache) key/value and expiry are another (and letting memcache or
redis expire using its own internal algorithms), using zookeeper
ephemeral nodes[1] are another
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?
Timestamps are just one way (and likely the most primitive), using redis (or
memcache) key/value and expiry are another (and letting memcache or redis
expire using
:59
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?
The TCP/IP stack keeps track of connections as a combination of IP + TCP port.
The two byte port limit doesn't matter unless all of the agents are connecting
Kevin Benton wrote:
So IIUC tooz would be handling the liveness detection for the agents.
That would be nice to get ride of that logic in Neutron and just
register callbacks for rescheduling the dead.
Where does it store that state, does it persist timestamps to the DB
like Neutron does? If so,
Timestamps are just one way (and likely the most primitive), using redis
(or memcache) key/value and expiry are another (and letting memcache or
redis expire using its own internal algorithms), using zookeeper ephemeral
nodes[1] are another... The point being that its backend specific and tooz
(not for usage questions)
*Subject:* Re: [openstack-dev] [neutron] Neutron scaling datapoints?
The TCP/IP stack keeps track of connections as a combination of IP + TCP
port. The two byte port limit doesn't matter unless all of the agents are
connecting from the same IP address, which shouldn't
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Sent: Thursday, April 9, 2015 5:01:45 PM
Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?
Hi Joe,
Many thanks for your reply!
On 09/04/15
)
*Subject:* Re: [openstack-dev] [neutron] Neutron scaling datapoints?
Which periodic updates did you have in mind to eliminate? One of the
few remaining ones I can think of is sync_routers but it would be great if
you can enumerate the ones you observed because eliminating overhead in
agents
So IIUC tooz would be handling the liveness detection for the agents. That
would be nice to get ride of that logic in Neutron and just register
callbacks for rescheduling the dead.
Where does it store that state, does it persist timestamps to the DB like
Neutron does? If so, how would that scale
)
openstack-dev@lists.openstack.org
Sent: Thursday, April 9, 2015 5:01:45 PM
Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?
Hi Joe,
Many thanks for your reply!
On 09/04/15 03:34, joehuang wrote:
Hi, Neil,
From theoretic, Neutron is like a broadcast domain
Hi, Neil,
See inline comments.
Best Regards
Chaoyi Huang
From: Neil Jerram [neil.jer...@metaswitch.com]
Sent: 09 April 2015 23:01
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Neutron scaling
Hi Joe,
Many thanks for your reply!
On 09/04/15 03:34, joehuang wrote:
Hi, Neil,
From theoretic, Neutron is like a broadcast domain, for example, enforcement of DVR and security
group has to touch each regarding host where there is VM of this project resides. Even using SDN controller,
the
Hi Mike,
Many thanks for your reply!
On 08/04/15 17:56, Mike Spreitzer wrote:
Are you looking at scaling the numbers of tenants, Neutron routers, and
tenant networks as you scale hosts and guests? I think this is a
plausible way to grow. The compartmentalizations that comes with
growing
Are you looking at scaling the numbers of tenants, Neutron routers, and
tenant networks as you scale hosts and guests? I think this is a
plausible way to grow. The compartmentalizations that comes with growing
those things may make a difference in results.
Thanks,
Mike
From: Neil Jerram
Hi, Neil,
From theoretic, Neutron is like a broadcast domain, for example, enforcement
of DVR and security group has to touch each regarding host where there is VM
of this project resides. Even using SDN controller, the touch to regarding
host is inevitable. If there are plenty of physical
30 matches
Mail list logo