sorry , i did not use keystone
On Tue, Dec 6, 2011 at 7:10 PM, crayon_z 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 system? It seems
why you do not try to swauth? it's create enough i think...
On Tue, Dec 6, 2011 at 7:10 PM, crayon_z 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 keysto
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 able
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 [m
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 bu
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
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 :
> >> Some of the LXC-related issues we've run into:
> >>
> >> - The CPU affinity issue on LXC you mention. Running LXC with OpenStack,
> >> y
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 fea
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
Uns
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 addre
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,
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 brie
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:
keystone.test.functio
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 deve
Hey All,
I've been working on a spec to cleanup VNC consoles for consistency and
xs/libvirt parity: http://wiki.openstack.org/VNCConsoleCleanup (related to
blueprint https://blueprints.launchpad.net/nova/+spec/vnc-console-cleanup )
The proposal aims to create a consistent (ie hypervisor independe
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 should be available
List,
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 , then we want the main
c
Hi Soren, thanks for your detailed input. Comments inline...
On Fri, Dec 2, 2011 at 3:48 AM, Soren Hansen wrote:
> 2011/12/1 Jay Pipes :
>> structure tar'd up. However, I think this can be more easily
>> accomplished by consolidating the disk and container formats in the
>> 2.0 API to just a sing
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
I like the code and would support enhancing Glance with this.
-jay
On Mon, Dec 5, 2011 at 6:36 PM, 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
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 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 p
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 w
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 import
On Tue, Dec 6, 2011 at 10:11 AM, 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
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.
You
- 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 :
> > >> Some of the LXC-related issues we've run into:
> > >>
> > >> - The CPU affinity issue on LXC you
On Tue, Dec 6, 2011 at 2:22 PM, John Dickinson
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 the topic of common co
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 :
> > > >> Some of
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 follo
>
>
> (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 af
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
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 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.
> Obviously requests
Thank you all ! I been reading the container sync functionality, we will
walk that path for sure, i just was hoping that a magic conf flag like
"preferred_datanodes =" exists hahaha :)
Best regards
Lean
On Tue, Dec 6, 2011 at 5:42 PM, andi abes wrote:
> sorry, should have included the link:
>
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 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 late
2011/12/6 Jay Pipes :
> On Fri, Dec 2, 2011 at 3:48 AM, Soren Hansen wrote:
>> 2011/12/1 Jay Pipes :
>> There are basically two things that are relevant: The image type and the
>> container format.
>>
>> The image type can be either of kernel, ramdisk, filesystem, iso9660,
>> disk, or "other".
> W
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 ported.
> >
> > There are an increasing number of sit
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
On 12/06/2011 12:06 PM, Jay Pipes wrote:
> On Tue, Dec 6, 2011 at 2:22 PM, John Dickinson
> 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 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 t
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 be
>>> removed now. In the future, we
- 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 wrote:
>
> >
> >
> > - Original Message -
> > > On Mon, Dec 05, 2011 at 09:07:0
"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
> 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 documentation in any
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: http%3A%2F%2Fwww.brighthost.com%2Ftest+s
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 expec
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 19:0
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: https://launchp
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 : https://help.launc
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
53 matches
Mail list logo
