sorry , i did not use keystone
On Tue, Dec 6, 2011 at 7:10 PM, crayon_z crayon@gmail.com wrote:
**
Hi, pf shineyear.
It seems that you use swauth or tempauth as the auth system for Swift.
Have you tried the keystone auth system? How to make a container private
with keystone auth
why you do not try to swauth? it's create enough i think...
On Tue, Dec 6, 2011 at 7:10 PM, crayon_z crayon@gmail.com wrote:
**
Hi, pf shineyear.
It seems that you use swauth or tempauth as the auth system for Swift.
Have you tried the keystone auth system? How to make a container
Dear Anne, Stefano and stackers,
I've seen a few mails passing around, on the documentation topic.
I've quickly looked at the source, and found my comment would still be relevant.
So here we go:
you seem to have the exact same documentation needs and issues I've
faced some time ago:
- being
Hi Soren,
Had a quick look at the quote and your question below.
From reading the mailing list, it appears that Scott Mosen and possibly Jay
Pipes are the experts on 'container type'.
I'll let them step in and field this question...
DL
-Original Message-
From: Soren Hansen
Stefano Maffulli wrote:
On Mon, 2011-12-05 at 09:51 +0100, Thierry Carrez wrote:
AskBot (Python/Django, GPL) - http://askbot.com/
Used by Fedora at http://ask.fedoraproject.org/questions/, can use
Launchpad OpenID for auth.
I looked at AskBot doesn't seem to have any mechanism to build a
Hi Anne,
I think that's it :)
Thanks for your help
Best regards
Khaled
From: a...@openstack.org
Date: Mon, 5 Dec 2011 07:46:25 -0600
Subject: Re: [Openstack] S3 API for Swift
To: khaled-...@hotmail.com
CC: openstack@lists.launchpad.net
Hi Khaled -
Is this what you are looking for?
On Mon, Dec 05, 2011 at 09:07:06PM -0500, Lorin Hochstein wrote:
On Dec 4, 2011, at 7:46 AM, Soren Hansen wrote:
2011/12/4 Lorin Hochstein lo...@isi.edu:
Some of the LXC-related issues we've run into:
- The CPU affinity issue on LXC you mention. Running LXC with OpenStack,
you
Hello everyone,
Our general meeting will take place at 21:00 UTC this Tuesday in
#openstack-meeting on IRC. PTLs, if you can't make it, please name a
substitute on [2].
We will focus on reviewing progress towards essex-2. We are one week
away from cutting the milestone-proposed branch, so new
hi,all
when use crendentials to ask for a unscoped token,should keystone offers
more info such as endpoints and user info? is it a bug or for other use?
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Hi,
Will this module sync the configurations between the different nodes in
the system? That is, if the cloud has a number of Compute modules
running. Will the updated configuration on one of them be replicated to
the additional nodes? If so then this is great, if not, would it be
possible to
So the general consensus so far on this discussion seems to be:
(0) The 2011.3 release PPA bears false expectations and should be
removed now. In the future, we should not provide such PPAs: 0-day
packages for the release should be available from the last milestone
PPA anyway.
(1) OpenStack, as
Hi Arnaud -
Asciidoc is great and we can work it into our toolchain. O'Reilly
offers authors the option of either authoring in DocBook (which is
most of our source on docs.openstack.org) or Asciidoc.
I like to accept documentation in any format - even Word docs printed
and handed to me from a
The unscoped token keystone returns to you allows you to call GET /tenants
and exchange your unscoped token for one scoped to a tenant. This is
documented in the API developer guide, but the following functional test
illustrates the flow from a client perspective pretty well:
Thierry,
I'm not clear on who will be maintaining the stable/diablo branch. The people
such as EPEL for RedHat systems need to have something with the appropriate bug
fixes back ported.
There are an increasing number of sites looking to deploy in production and
cannot follow the latest
On 06 Dec 2011 - 10:11, Duncan McGreggor wrote:
On 06 Dec 2011 - 14:28, Thierry Carrez wrote:
So the general consensus so far on this discussion seems to be:
(0) The 2011.3 release PPA bears false expectations and should be
removed now. In the future, we should not provide such PPAs:
Lendro Reox asked:
We're replicating our datacenter in another location (something like Amazons
east and west coast) , thinking about our applications and
our use of Swift, is there any way that we can set up weights for our
datanodes so if a request enter via for example DATACENTER 1 ,
On Tue, 6 Dec 2011 10:11:28 -0800
Duncan McGreggor dun...@dreamhost.com wrote:
On 06 Dec 2011 - 14:28, Thierry Carrez wrote:
So the general consensus so far on this discussion seems to be:
(0) The 2011.3 release PPA bears false expectations and should be
removed now. In the future, we
Caitlin,
Thanks for your quick response, so ther isnt any way, if a request come
inside DATACENTER 1 and the random mechanism of swift tells to search for
the object on the DATACENTER 2, is no way to avoid it.
What about container sync ?
Regards
On Tue, Dec 6, 2011 at 3:49 PM, Caitlin Bestler
Overall, I think it's a great thing to have commonality between the projects on
option names and environment variables. I think it's worthwhile to push for
that in the swift cli tool in the essex timeframe.
On the topic of common config libraries, though, I think the differences are
less
On Tue, Dec 6, 2011 at 10:11 AM, Duncan McGreggor dun...@dreamhost.com wrote:
On 06 Dec 2011 - 14:28, Thierry Carrez wrote:
So the general consensus so far on this discussion seems to be:
(0) The 2011.3 release PPA bears false expectations and should be
removed now. In the future, we should
You could try to use the container sync added in 1.4.4.
The scheme would be to setup 2 separate clusters in each data center.
Obviously requests will be satisfied locally.
You will also setup your containers identically, and configure them to
sync, to make sure data is available in both DC's.
On Tue, Dec 6, 2011 at 2:22 PM, John Dickinson
john.dickin...@rackspace.com wrote:
Overall, I think it's a great thing to have commonality between the projects
on option names and environment variables. I think it's worthwhile to push
for that in the swift cli tool in the essex timeframe.
On Tue, Dec 06, 2011 at 12:04:53PM -0800, Dong-In David Kang wrote:
- Original Message -
On Mon, Dec 05, 2011 at 09:07:06PM -0500, Lorin Hochstein wrote:
On Dec 4, 2011, at 7:46 AM, Soren Hansen wrote:
2011/12/4 Lorin Hochstein lo...@isi.edu:
Some of the
Tim Bell wrote:
I'm not clear on who will be maintaining the stable/diablo branch. The
people such as EPEL for RedHat systems need to have something with the
appropriate bug fixes back ported.
There are an increasing number of sites looking to deploy in production and
cannot follow the
(4) OpenStack will accept and foster a new project, one that is not
focused on development, but rather the distribution and it's general
stability. This distro project will be responsible for advocating on
behalf of various operating systems/distros/sponsoring vendors for bugs
that affect
Duncan McGreggor wrote:
On 06 Dec 2011 - 14:28, Thierry Carrez wrote:
So the general consensus so far on this discussion seems to be:
(0) The 2011.3 release PPA bears false expectations and should be
removed now. In the future, we should not provide such PPAs: 0-day
packages for the release
sorry, should have included the link:
http://swift.openstack.org/overview_container_sync.html
On Tue, Dec 6, 2011 at 2:49 PM, andi abes andi.a...@gmail.com wrote:
You could try to use the container sync added in 1.4.4.
The scheme would be to setup 2 separate clusters in each data center.
Hi,
So I was the developer who added support for LXC support initially, I
have some comments in line
On Tue, 6 Dec 2011 12:04:53 -0800 (PST)
Dong-In David Kang dk...@isi.edu wrote:
- Original Message -
On Mon, Dec 05, 2011 at 09:07:06PM -0500, Lorin Hochstein wrote:
On
We need more than 'just' packaging it is using the testing, documentation
and above all care to produce *and* maintain a stable release that production
sites can rely on for 6-12 months and know that others are relying on it too.
Who is going to make the judgement that a bug fix to the
2011/12/6 Jay Pipes jaypi...@gmail.com:
On Fri, Dec 2, 2011 at 3:48 AM, Soren Hansen so...@linux2go.dk wrote:
2011/12/1 Jay Pipes jaypi...@gmail.com:
There are basically two things that are relevant: The image type and the
container format.
The image type can be either of kernel, ramdisk,
On 06 Dec 2011 - 13:52, Duncan McGreggor wrote:
On 06 Dec 2011 - 21:14, Thierry Carrez wrote:
Tim Bell wrote:
I'm not clear on who will be maintaining the stable/diablo branch.
The people such as EPEL for RedHat systems need to have something
with the appropriate bug fixes back
On 12/06/2011 12:06 PM, Jay Pipes wrote:
On Tue, Dec 6, 2011 at 2:22 PM, John Dickinson
john.dickin...@rackspace.com wrote:
Overall, I think it's a great thing to have commonality between the projects
on option names and environment variables. I think it's worthwhile to push
for that in
The purpose of the stable branch and the maint team that theirry mentioned
earlier is to vet patches. Are you suggesting that we need a point release
system for openstack outside of relying on distros to pick release points?
Vish
On Dec 6, 2011, at 1:21 PM, Tim Bell wrote:
We need more
- Original Message -
Hi,
So I was the developer who added support for LXC support initially, I
have some comments in line
On Tue, 6 Dec 2011 12:04:53 -0800 (PST)
Dong-In David Kang dk...@isi.edu wrote:
- Original Message -
On Mon, Dec 05, 2011 at 09:07:06PM
Packaging is just a minor step and the last one. But also an important
one. Without propering packaging, installation and updates can be a real
pain. We should give packaging a lot of love, but there is people much
more prepared to do it, and with a little of help, can do a great job.
When one
Hi Anne,
2011/12/6 Anne Gentle a...@openstack.org
Hi Arnaud -
Asciidoc is great and we can work it into our toolchain. O'Reilly
offers authors the option of either authoring in DocBook (which is
most of our source on docs.openstack.org) or Asciidoc.
great thing!
I like to accept
hi all , i just found that swift use urllib.quote and urllib.unquote to
process request url.
but in php urlencode or rawurlencode process result is very different from
python's
for example:
org: http://www.brighthost.com/test space~.html
php urlencode:
On 06 Dec 2011 - 23:56, Loic Dachary wrote:
On 12/06/2011 09:24 PM, Thierry Carrez wrote:
Duncan McGreggor wrote:
On 06 Dec 2011 - 14:28, Thierry Carrez wrote:
So the general consensus so far on this discussion seems to be:
(0) The 2011.3 release PPA bears false expectations and should
Greetings:
This is most likely to be an administration problem, but I am trying to
use it as a hook to gain understanding into workings of Swift.
I have a test cluster with 2 VMs and 4 nodes. At some point, I reinstalled
one of the nodes, and now this 404 happens from time to time:
Dec 6
Hello Everyone,
The Nova subteams have now been active for a month and a half. Some things are
going very well, and others could use a little improvement. To keep things
moving forward, I'd like to make the following changes:
1) Weekly meeting for team leads. This is a time for us to discuss
all swift use UTC time (gmtime) not local time
so if any one want to analysis the log or write some plugin for slogging,
please comfirm you already exchange your time to UTC time
or your total calculate will not correct
___
Mailing list:
On Mon, 2011-12-05 at 15:36 -0800, Vishvananda Ishaya wrote:
Just read through the description and the code. I don't have any
issues with the way it is implemented, although others may have some
suggestions/tweaks. I think it is most important to get the common
code established, so I'm up
The stable team with Duncan's additions would fully address my concerns.
Tim
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help :
On Mon, 2011-12-05 at 15:32 -0800, Andy Smith wrote:
Took a look over the wiki for this. The approach is very similar to one
I've used recently so I wanted to bring up something that looks like it may
have been overlooked.
In testing it is frequent practice that you want to ensure global
44 matches
Mail list logo