Hi,
I recently came across an object store that could disable container
listing and thereby give better performance. By disable, it meant that
a call to list the entries in a container would simply return an empty
status code of 200 without any object names.
I guess this is possible only if the e
Chuck made some interesting suggestions on the Openstack-Swift irc
channel related to this topic. Noting them down her in case this
benefits others.
1. Changing the partition power of the object server rings. I was
running with a partition power of 8. I ran some experiments changing
this to 4 and
As the services I described were the first things that came into my mind with
regards to high availability in Barbican I assumed that there was probably a
better strategy.
If the strategy is as you've described then that's great - even I can
understand that!
-Rob
>
> Our plan for deployment
You are welcome.
Mark
From: Douglas Mendizabal [mailto:douglas.mendiza...@rackspace.com]
Sent: Wednesday, March 19, 2014 11:31 AM
To: Miller, Mark M (EB SW Cloud - R&D - Corvallis); Ferreira, Rafael; Remo
Mattei; Wyllys Ingersoll; openstack@lists.openstack.org
Subject: Re: [Openstack] [Barbican]
> -Original Message-
> From: Clint Byrum [mailto:cl...@fewbar.com]
> Sent: 19 March 2014 18:22
> To: openstack
> Subject: Re: [Openstack] [Barbican] Key Recovery / Availability
>
> Excerpts from Clark, Robert Graham's message of 2014-03-19 07:41:35 -
> 0700:
> > Has there been much discu
Our plan for deployment is exactly as Clark described:
* Several API nodes behind a load balancer
* PostgreSQL master/slave replication
* HSMs in HA paired mode
* Several Worker nodes
I’m also curios as to why this would be considered “clunky”?
-Doug
On 3/19/14, 1:21 PM, "Clint Byrum" wrote:
Hello Mark,
I apologize for the late reply. Just wanted to say thanks for adding this
to the wiki. We really appreciate your contribution to the project! :)
-Doug
From: , "Mark M (EB SW Cloud - R&D - Corvallis)"
Date: Friday, March 14, 2014 at 4:50 PM
To: Douglas Mendizabal , "Ferreira,
Excerpts from Clark, Robert Graham's message of 2014-03-19 07:41:35 -0700:
> Has there been much discussion on how to ensure that keys are
> recoverable in the event that Barbican has some sort of horrific
> failure?
>
> I suppose a HA frontend, Redundant Keystore Databases and HA paired HSMs
> w
Hi,
We are working on OpenStack deployment inside my company. We need a QoS
solution to control the quality of network traffic between VMs and network
nodes. But it seems to be the missing feature on Havana release, doesn't
it? So, is there any alternative or work-around solution for our problem?
Hi,
I would like to understand better how cells work in terms of networking and
there is very little documentation.
1. Will it be possible to specify which cell to boot a server into?
2. Will servers on one cell be able to resolve and connect to servers
another cell?
Thanks,
Shay
___
Has there been much discussion on how to ensure that keys are
recoverable in the event that Barbican has some sort of horrific
failure?
I suppose a HA frontend, Redundant Keystore Databases and HA paired HSMs
would be the most obvious non-code-writing path but this feels pretty
clunky, I was wond
wrote on 03/19/2014 01:56:07 AM:
> @Mike: as you can see from the below output that I am able to
> create alarms, but I would like to know where these logs are getting
> generated after alarm triggered ? I have mentioned ‘log://’.
>
> But there is nothing in my logfile:
Sorry, I am not famili
Hi everyone,
I have configured openstack Havana on ubutu server 12.04. I have a three
server a controller, a compute and a network node. I have used neutron for
networking with openvswitch. I can deply and run an instance. But i can't
ping the floatting ip associated with the instance. I added icm
Hi there,
I'm experiencing a problem while attaching a volume to a VM; this is
what I see in nova.log:
Command: sudo nova-rootwrap /etc/nova/rootwrap.conf iscsiadm -m node
-T iqn.2010-10.org.openstack:volume-0c623f91-9a90-4ff5-805c-8e5861e3c92d
-p 127.0.0.1:3260 --rescan
If I give the same
The OpenStack Technical Committee ("TC") recently adopted the following
resolutions:
* Project "Sahara" (formerly known as Savanna), from the Data processing
service program, graduated from incubation and will be made a part of
the integrated release for Juno (Oct 2014).
http://git.openstack.org/
15 matches
Mail list logo