Hi Tom,
Thank you for preparing translation. In Japan, Kato-san just called volunteers
for Japanese. I'll join them.
On 2015年5月1日 12:01:50 GMT+09:00, Tom Fifield wrote:
>Hi,
>
>I just clicked "Mark This Page for Translation", which should fix this,
>I think.
>
>"""
>The page ReleaseNotes/Kilo h
Am 01.05.2015 um 02:21 schrieb Samuel Merritt:
>
> It seems like 1430268763.41931.data would be in the same allocation group as
> objects/757/a94/bd77129a1cae9e32381776e322efca94, and
> bd77129a1cae9e32381776e322efca94 would be in the same allocation
> group as objects/757/a94, and so on. Thus,
On 5/1/15 7:55 AM, Uwe Sauter wrote:
Am 01.05.2015 um 02:21 schrieb Samuel Merritt:
It seems like 1430268763.41931.data would be in the same allocation group as
objects/757/a94/bd77129a1cae9e32381776e322efca94, and
bd77129a1cae9e32381776e322efca94 would be in the same allocation
group as obj
Hello Stackers,
I am using the Havana version of OpenStack in our cloud. I am noticing a
strange behavior while booting the VM. When I boot a VM using a bare Ubuntu
14.04 image and pass the user-data option, in the console I am able to see the
output generated by the script. When I boot a VM fr
On 01.05.15 20:33, Samuel Merritt wrote:
> On 5/1/15 7:55 AM, Uwe Sauter wrote:
>>
>>
>> Am 01.05.2015 um 02:21 schrieb Samuel Merritt:
>>>
>>> It seems like 1430268763.41931.data would be in the same allocation
>>> group as
>>> objects/757/a94/bd77129a1cae9e32381776e322efca94, and
>>> bd77129a1cae
On 5/1/15 12:37 PM, Christian Schwede wrote:
On 01.05.15 20:33, Samuel Merritt wrote:
On 5/1/15 7:55 AM, Uwe Sauter wrote:
Am 01.05.2015 um 02:21 schrieb Samuel Merritt:
It seems like 1430268763.41931.data would be in the same allocation
group as
objects/757/a94/bd77129a1cae9e32381776e322ef
Dear all,
I have a problem when configuring LBaaS in Juno.
Our setup is an OpenStack Juno with 2 controller and 2 network nodes in HA,
using HAproxy & Keepalived.
After playing with the Havana version, where services were not in HA (just
1 controller and 1 network-node) and where everything was w
>> http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/cmds/xfsprogs.git;a=blob;f=mkfs/xfs_mkfs.c;h=5084d755;hb=HEAD#l688
>>
>> Might be a good idea to do some benchmarking with different AG numbers?
>
>
> Could be useful, but we should first get Swift to not dump everything in the
> same AG. Otherwise, th
