On 11 Apr 2015 02:04, Jeremy Stanley fu...@yuggoth.org wrote:
On 2015-04-11 01:28:51 +0300 (+0300), Duncan Thomas wrote:
[...]
We will not be merging any drivers without stable 3rd party CI in
future
[...]
For clarity, hopefully this is stable testing reporting on changes
to the project
On 11 Apr 2015 02:04, Jeremy Stanley fu...@yuggoth.org wrote:
On 2015-04-11 01:28:51 +0300 (+0300), Duncan Thomas wrote:
[...]
We will not be merging any drivers without stable 3rd party CI in
future
[...]
For clarity, hopefully this is stable testing reporting on changes
to the project
Sorry for top posting - I wasn't subscribed to the doc list before
clarkb told me about this thread. Warning ... rage coming ... if you
don't want to read rage on a Saturday, I recommend skipping this email.
a) There may be a doc bug here, but I'm not 100% convinced it's a doc
bug - I'll try to
Attention voters, ballots have been sent to one of your Gerrit
additional E-mail Addresses. Due to this error we must cancel this
election and start a new one. Any vote that has already been cast is
null and void.
The title of the new poll is changed to New OpenStack ... PTL Election
and all
Sorry all for this breakage; I've been on vacation and didn't set up adequate
cover.
Thanks for disabling it and we'll let everyone know when the job is ready to
start commenting and hopefully voting on changes in the very near future.
Regards,
Bob
Hi,
Can a core please take a look at https://review.openstack.org/#/c/171037. The
CI is broken due to commit e7ae5bb7fbdd5b79bde8937958dd0a645554a5f0.
Thanks
Gary
__
OpenStack Development Mailing List (not for usage
Looks like our SSL certificate has expired for the currently active CI
cloud. We are working on getting a new one generated and installed.
Until then CI jobs won't get processed.
Dan
__
OpenStack Development Mailing List
Hi Kiall,
Thanks for getting back.
Yes, I understand that Designate is providing the API interface to push data
into a DNS namespace, so not really related to the region concept in the same
way as nova or most other OpenStack services.
I think the problem I am highlighting here is that of
As Kevin talking about agents, I want to remind that in TCP/IP stack, port (
not Neutron Port ) is a two bytes field, i.e. port ranges from 0 ~ 65535,
supports maximum 64k port number.
above 100k managed node means more than 100k L2 agents/L3 agents... will be
alive under Neutron.
Want
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 be the case unless
compute nodes connect to the rabbitmq server via one IP address running
port
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
11 matches
Mail list logo
