I'm using a devstack-configured box with all the latest code and am running
into DeprecationWarning wherever weob.Request.str_[GET,PUT,cookies,params] are
accessed (they are being replaced by unicode equivalents). Since Python < 2.7
does not ignore DeprecationWarning, and I am running on Python
Hi Keven,
On 2012-03-08, at 8:31 AM, Kevin L. Mitchell wrote:
> On Wed, 2012-03-07 at 22:40 -0800, Maru Newby wrote:
>> I'm using a devstack-configured box with all the latest code and am
>> running into DeprecationWarning wherever
>> weob.Request.str_[GET,PUT,cookies,
On 2012-03-09, at 7:52 AM, Jay Pipes wrote:
>> The data is stored in a python dictionary, inside of the metadata table.
>> You will not be able to use SQL without an unwieldy wildcard search. IMO
>> this seems overly complicated for a core function of the tool, and possibly
>> the reason why
Hi Joe,
There's one huge difference between page deduplication and object
deduplication: Page size is small and predictable, whereas object size is not.
Given this, full compares would not be a good way to implement performant
object deduplication in swift.
Thanks,
Maru
On 2012-03-10, at
> It combines a quick has to identify candidates that might be
> duplicates, but relies on comparison to ensure that the match is real,
> and not just a hash collision.
>
> See the source of all knowledge:
> http://en.wikipedia.org/wiki/Rsync#Algorithm
>
>
>
>
>
>
I'd like to write unit tests for keystone.middleware.swift_auth in advance of
some functional changes (adding support for unauthenticated container sync and
referrer access). It appears that swift_auth lacks unit tests, though. Is
this due to its dependency on swift, or is there another reason
ave swift.common.*/swiftclient go to
> another package but that's probably a discussion for Folsom summit.
>
> On Tue, Mar 20, 2012 at 3:33 AM, Maru Newby wrote:
>> I'd like to write unit tests for keystone.middleware.swift_auth in advance
>> of some functional changes
Hi Jay,
On 2012-03-22, at 2:13 PM, Jay Pipes wrote:
>
> Object Imports
> ==
>
> In addition, the following DOES NOT appear in Glance's section on imports:
>
> - Do not import objects, only modules
>
> Nowhere in PEP8 does it mention anything about not importing objects. In
> fact,
Hi Andy,
On 2012-03-22, at 10:00 PM, Andy Smith wrote:
> The rule is there because it makes it obvious where you are using objects
> from (and they aren't in the current namespace), prevents that "where is this
> defined -scan around the file- oh, it is being imported from this other
> thing,
The Keystone repo currently contains the following Swift-specific wsgi
middleware modules:
https://github.com/openstack/keystone/blob/master/keystone/middleware/s3_token.py
https://github.com/openstack/keystone/blob/master/keystone/middleware/swift_auth.py
Neither module depends directly on Keys
Agreed that s3_token belongs in Swift, and as per Joshua, ec2_token probably
belongs in Nova.
Cheers,
Maru
On 2012-04-11, at 3:07 PM, Chmouel Boudjnah wrote:
> On Thu, Apr 12, 2012 at 12:01 AM, Joshua Harlow
> wrote:
> This also seems to make sense for other items in that directory /middlew
Hi John,
On 2012-04-11, at 8:03 PM, John Dickinson wrote:
> I do not think that these pieces of middleware belong in the core swift repo.
Understood.
> 1) Including them in swift would require swift to depend on keystone for full
> testing.
As I mentioned in my initial email, the modules in
The rest api is the default interface, and the client tools target that
interface. Since the clients are cli more than python api, they can be used by
any language that can use a shell. What exactly does reimplementing the
clients for the sake of testing accomplish? Double the maintenance eff
The swift probetests are broken:
https://bugs.launchpad.net/swift/+bug/1014931
Does the swift team intend to maintain probetests going forward? Given how
broken they are at present (bad imports, failures even when imports are fixed),
it would appear that probetests are not gating commits. Tha
Have I missed a response in the past week?
On 2012-06-19, at 12:14 PM, Jay Pipes wrote:
> On 06/19/2012 11:10 AM, Maru Newby wrote:
>> The swift probetests are broken:
>>
>> https://bugs.launchpad.net/swift/+bug/1014931
>>
>> Does the swift team intend to
I see that support for PKI Signed Tokens has been added to Keystone without
support for token revocation. I tried to raise this issue on the bug report:
https://bugs.launchpad.net/keystone/+bug/1003962/comments/4
And the review:
https://review.openstack.org/#/c/7754/
I'm curious as to whether
til revocation support became
available.
Thanks,
Maru
On 2012-08-01, at 9:47 PM, Adam Young wrote:
> On 08/01/2012 09:19 PM, Maru Newby wrote:
>>
>> I see that support for PKI Signed Tokens has been added to Keystone without
>> support for token revocation. I t
> On 08/01/2012 11:05 PM, Maru Newby wrote:
>>
>> Hi Adam,
>>
>> I apologize if my questions were answered before. I wasn't aware that what
>> I perceive as a very serious security concern was openly discussed. The
>> arguments against revocat
make it
> happen instead of name calling and asserting how the developers doing the
> work are screwing up.
>
> - joe
>
> On Aug 1, 2012, at 8:05 PM, Maru Newby wrote:
>> Hi Adam,
>>
>> I apologize if my questions were answered before. I wasn't aware th
09 AM, Adam Young wrote:
> On 08/01/2012 09:19 PM, Maru Newby wrote:
>>
>> I see that support for PKI Signed Tokens has been added to Keystone without
>> support for token revocation. I tried to raise this issue on the bug report:
>>
>> https://bugs.launchpa
Hi Salvatore,
I see you're working on getting plugins testable with tox:
https://review.openstack.org/#/c/11922/
What about keeping the plugins isolated for testing purposes? I have been
unable to work on it yet, but I was thinking it might be a good idea to move
the plugins out of the main t
While following the saio instructions
(http://swift.openstack.org/development_saio.html) I ran into a problem with
the swift-core ppa. I get the following on apt-get update after adding the ppa
repo:
W: Failed to fetch
http://ppa.launchpad.net/swift-core/ppa/ubuntu/dists/lucid/main/binary-amd
Please disregard. I've added a bug in launchpad and submitted a fix to gerrit.
Apologies for the newb email.
Thanks!
Maru
On 2011-12-16, at 7:24 PM, Maru Newby wrote:
> While following the saio instructions
> (http://swift.openstack.org/development_saio.html) I ran into a p
-1 on multi-distribution devstack. Being cross-platform is arguably a place
where chef/puppet/cfengine automation comes into play, and that's not where
devstack's self-declared mission lies.
+1 to continuing to have Ubuntu be the reference devstack target. Maintaining
support for an apt-based
I've submitted a Swift AIO cookbook for review:
https://review.openstack.org/#change,3613
It follows the latest single-node AIO instructions pretty much to the letter,
so the resulting environment is well-documented. We use this cookbook as the
basis for building Swift development environments
f devstack, written in python,
> but also can run in rhel 6.2, ubuntu 11 and work is being done for fedora 16.
>
> Josh
>
> On 2/6/12 9:51 PM, "Maru Newby" wrote:
>
> -1 on multi-distribution devstack. Being cross-platform is arguably a place
> where chef/
> it shouldn’t be, but only if u let it. General life principle :-)
>
> On 2/7/12 1:36 PM, "Maru Newby" wrote:
>
> Hi Josh,
>
> Devstack in bash will only get more complicated and harder to maintain as
> time goes on. Supporting multiple distros would a
Is there any interest in adding unittest2 to the test dependencies for
openstack projects? I have found its enhanced assertions and 'with
self.assertRaises' very useful in writing tests. I see there have been past
bugs that mentioned unittest2, and am wondering if the reasons for not adopting
Hi Jay,
On 2012-03-02, at 10:17 AM, Jay Pipes wrote:
>
> ++ to unittest2. Frankly, it's a dependency of sqlalchemy, so it gets
> installed anyway during any installation. Might as well use it IMHO.
Good to know!
>> Separately, is the use of mox open to discussion? mock was recently added
>
Hi Mark,
Where are you attempting to execute ping against the internal ip from? Based
on that guide, the internal ip would only be routable on the compute or network
nodes, and it should be possible to ping the VM from either.
If you are unable to ping the internal ip from one of those nodes
On Apr 29, 2013, at 6:03 PM, yulin...@dell.com wrote:
>
>
> Hi,
>
> I’m new to Quantum and trying to set up an openstack quantum environment.
>
> I installed a single node environment using DevStack(on a VM) successfully. I
> noticed that by default there is no log files for quantum. I tr
.
> Thanks,
>
> YuLing
>
> -Original Message-
> From: Maru Newby [mailto:ma...@redhat.com]
> Sent: Tuesday, April 30, 2013 2:03 AM
> To: C, Yuling
> Cc: openstack@lists.launchpad.net
> Subject: Re: [Openstack] anyone has a sample quantum.conf file that
> configu
an get the physical
> NIC port MAC from Openstack Quantum? The plugin configured in my environment
> is OVS plugin.
>
> Thanks,
>
> YuLing
>
> -----Original Message-
> From: Maru Newby [mailto:ma...@redhat.com]
> Sent: Tuesday, April 30, 2013 11:32 AM
&g
33 matches
Mail list logo
