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 tried to
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
configures a valid quantum.log file?
On Apr 29, 2013, at 6:03 PM, yulin
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
To: C, Yuling
Cc: openstack@lists.launchpad.net
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
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
, 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.launchpad.net/keystone/+bug/1003962/comments/4
/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 revocation support, as you've described them, seem to be:
- it's
up.
- joe
On Aug 1, 2012, at 8:05 PM, Maru Newby mne...@internap.com 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 revocation support, as you've
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
-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 tried to raise this issue on the bug report:
https://bugs.launchpad.net/keystone/+bug/1003962/comments
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 maintain probetests going forward? Given how
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.
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
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 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
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 harlo...@yahoo-inc.com
wrote:
This also seems to make sense for other items in
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,
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, PEP8
a discussion for Folsom summit.
On Tue, Mar 20, 2012 at 3:33 AM, Maru Newby mne...@internap.com wrote:
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
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
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
that the match is real,
and not just a hash collision.
See the source of all knowledge:
http://en.wikipedia.org/wiki/Rsync#Algorithm
On Sat, Mar 10, 2012 at 1:15 PM, Maru Newby mne...@internap.com wrote:
Hi Joe,
There's one huge difference between page deduplication and object
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
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
-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
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
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
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 problem
28 matches
Mail list logo
