Mark McLoughlin wrote:
> I'd like to put my name forward as a candidate for openstack-common PTL.
As an election official, I confirm that you're eligible to that position.
--
Thierry Carrez (ttx)
Release Manager, OpenStack
___
Mailing list: https://la
Hi,
I'd like to put my name forward as a candidate for openstack-common PTL.
I helped start the project with Jason Kölker in January and wrote the
plan we've been following:
http://wiki.openstack.org/CommonLibrary
Since then, I've been doing reviews, triaging bugs and organizing the
blueprint
On 07/10/2012 12:49 PM, Gary Kotton wrote:
> On 07/10/2012 06:29 PM, Eric Windisch wrote:
>>> 2. I based my integration on the patch
>>> https://review.openstack.org/#/c/9166/. A number of files were missing.
>>> Should this have specifically mentioned the missing files or should the
>>> rpc part h
On Tue, 2012-07-10 at 13:36 -0400, Eric Windisch wrote:
> >
> > The bigger issue is getting people to do the reviews...
> >
>
> Here is the link for those that want to help:
> https://review.openstack.org/#/q/status:open+project:openstack/openstack-common+branch:master+topic:bug/1021459,n,z
Co
>
> The bigger issue is getting people to do the reviews...
>
Here is the link for those that want to help:
https://review.openstack.org/#/q/status:open+project:openstack/openstack-common+branch:master+topic:bug/1021459,n,z
Regards,
Eric Windisch
_
On Tuesday, July 10, 2012 at 13:24 PM, Jason Kölker wrote:
> The zeromq tests are failing in jenkins. I created bug
> https://bugs.launchpad.net/openstack-common/+bug/1023060 for this.
> Anyone with an interest in ZeroMQ support, please help to resolve this
> bug.
>
I'm maintaining this code
The zeromq tests are failing in jenkins. I created bug
https://bugs.launchpad.net/openstack-common/+bug/1023060 for this.
Anyone with an interest in ZeroMQ support, please help to resolve this
bug.
Happy Hacking!
7-11
___
Mailing list: https://launchp
On 07/10/2012 06:29 PM, Eric Windisch wrote:
In addition to this I have a few additional questions and or concerns:
1. When we import code from openstack common the test cases for the
modules are not imported (maybe I missed something with running setup).
When the code is copied the imports are u
>
> In addition to this I have a few additional questions and or concerns:
> 1. When we import code from openstack common the test cases for the
> modules are not imported (maybe I missed something with running setup).
> When the code is copied the imports are updated. It would be nice to
> kno
On 07/10/2012 11:03 AM, Gary Kotton wrote:
> 1. When we import code from openstack common the test cases for the
> modules are not imported (maybe I missed something with running setup).
> When the code is copied the imports are updated. It would be nice to
> know that the auto tests are also run i
Hi,
I am in the process of integrating the RPC code from OpenStack common
into Quantum. I initially started working with qpid as the backend
implementation. I ran into problems due to the fact that
control_exchange is defined as 'nova'. This is in
quantum/openstack/common/rpc/__init__.py where
There's a new version of pep8 out today (1.3.1) which fixes a few
indentation cases of if statements that were broken in 1.3.
Sergio
On Sun, Jun 17, 2012 at 9:01 PM, Adrian Smith wrote:
> pep8 1.3 (released 15-Jun) is much stricter about the indentation used
> on continuation lines.
>
> After u
pep8 1.3 (released 15-Jun) is much stricter about the indentation used
on continuation lines.
After upgrading we started seeing quite a few instances of E127,E128...
"E127 continuation line over-indented for visual indent".
Adrian
On 17 June 2012 17:52, Jay Pipes wrote:
> What version of pep8
What version of pep8 are you using? The errors look to be warnings that
are no longer printed in more modern versions of pep8...
All the best,
-jay
On 06/17/2012 03:42 AM, Gary Kotton wrote:
Hi,
Over the weekend patches were made to Quantum to support Pep 1.3.
Some of the patches were in the o
Hi,
Over the weekend patches were made to Quantum to support Pep 1.3.
Some of the patches were in the openstack common code. I have opened a
bug to address this in the openstack common code
(https://bugs.launchpad.net/openstack-common/+bug/1014216)
I am currently updating the common code and wil
Can't wait for openstack-common to be usable for Quantum as well. Here is
our write-up of code in Quantum that seems generic (and is likely
"borrowed" from other openstack project):
http://wiki.openstack.org/QuantumOpenstackCommon
Would love to get much of this into openstack-common.
Dan
On Th
Yippe common code that people can share! Win!
On 1/26/12 8:32 AM, "Mark McLoughlin" wrote:
Hey,
On Tue, 2012-01-03 at 16:57 +, Mark McLoughlin wrote:
> The openstack-common project intends to produce a python library containing
> infrastructure code shared by OpenStack projects. The APIs p
Hey,
On Tue, 2012-01-03 at 16:57 +, Mark McLoughlin wrote:
> The openstack-common project intends to produce a python library containing
> infrastructure code shared by OpenStack projects. The APIs provided by the
> project should be high quality, stable, consistent and generally useful.
Jas
Openstack-common could be great. There are lots of use cases that make a lot of
sense to put in openstack common. Configuration loading, context, some aspects
of logging, wsgi middleware, some parts of utils--those seem to me like great
opportunities to save time and effort, both writing and rea
> -Original Message-
> From: Mark McLoughlin [mailto:mar...@redhat.com]
> Sent: 03 January 2012 13:35
> To: Ewan Mellor
> Cc: openstack@lists.launchpad.net; Jason Koelker
> Subject: RE: [Openstack] openstack-common
>
> On Tue, 2012-01-03 at 19:54 +, Ewan Mello
On 01/03/2012 02:11 PM, Jason Kölker wrote:
> On Tue, 2012-01-03 at 21:38 +, Mark McLoughlin wrote:
>>> As a related note, I'm going to get the current repo moved in to gerrit
>>> today or tomorrow.
>>
>> It's more Jason's call, but I think we're basically asking you to hold
>> off on that fo
On Tue, 2012-01-03 at 13:49 -0800, Monty Taylor wrote:
> > It's more Jason's call, but I think we're basically asking you to hold
> > off on that for a little while. We may decide to start a new repo.
>
> Oh - ok. My bad - I'll learn to read entire threads next time...
>
> Let let me know when i
On Tue, 2012-01-03 at 21:38 +, Mark McLoughlin wrote:
> > As a related note, I'm going to get the current repo moved in to gerrit
> > today or tomorrow.
>
> It's more Jason's call, but I think we're basically asking you to hold
> off on that for a little while. We may decide to start a new rep
On 01/03/2012 01:38 PM, Mark McLoughlin wrote:
> On Tue, 2012-01-03 at 13:04 -0800, Monty Taylor wrote:
>> Operationally they'll need to be able to make the change in a way that
>> it can be sequenced. We don't have a concept of simultaneous tied
>> changes. So a the change you describe would nee
On Tue, 2012-01-03 at 13:04 -0800, Monty Taylor wrote:
> Operationally they'll need to be able to make the change in a way that
> it can be sequenced. We don't have a concept of simultaneous tied
> changes. So a the change you describe would need to look like:
>
> Land change to openstack-common t
On Tue, 2012-01-03 at 19:54 +, Ewan Mellor wrote:
> I'd love to see openstack-common get off the ground, so I'm all in
> favor of this.
>
> One question: why do you feel that you need such strong backwards
> compatibility? If someone makes a change in openstack-common and
> makes simultaneous
On 01/03/2012 02:54 PM, Ewan Mellor wrote:
I'd love to see openstack-common get off the ground, so I'm all in favor of
this.
One question: why do you feel that you need such strong backwards
compatibility? If someone makes a change in openstack-common and makes
simultaneous changes in all Op
> Ewan.
>
>> -Original Message-
>> From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net
>> [mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net]
>> On Behalf Of Mark McLoughlin
>> Sent: 03 January 2012 08:58
>> To: openstack@
On Tue, 2012-01-03 at 19:54 +, Ewan Mellor wrote:
> I'd love to see openstack-common get off the ground, so I'm all in
> favor of this.
>
> One question: why do you feel that you need such strong backwards
> compatibility? If someone makes a change in openstack-common and
> makes simultaneous
ts.launchpad.net
> Cc: Jason Koelker
> Subject: [Openstack] openstack-common
>
> Hey,
>
> As Jason says - another year, another openstack-common thread! :-)
>
> I've just written up the plan Jason and I have for openstack-common:
>
>http://wiki.openstack.org/Comm
Hey,
As Jason says - another year, another openstack-common thread! :-)
I've just written up the plan Jason and I have for openstack-common:
http://wiki.openstack.org/CommonLibrary
(also pasted below to make it easier to reply to)
I guess what we're trying to do is quickly get this thing in
Here's the start of a skeleton project:
https://github.com/openstack/openstack-skeleton
Fork away. We can use the pull requests for discussion about what's
best practice, what isn't, etc...
-jay
On Tue, Jul 26, 2011 at 8:26 AM, Thierry Carrez wrote:
> Brian Lamar wrote:
>> I love the idea of h
Brian Lamar wrote:
> I love the idea of having an openstack-common project. However, the prospect
> of creating such a project is daunting and quite difficult.
> [...]
Thanks for bringing up the subject ! I think there are two types of
benefits from this:
The first is, like you said, to lower th
One thing that might be added would be dynamic module and class
loading. This has implications for flags/options and help output as
well. It is something nova does, and I suspect keystone and others
will need to do as well.
On Mon, Jul 25, 2011 at 2:59 PM, Devin Carlen wrote:
> If by mini-proje
+1
On Jul 25, 2011, at 11:59 AM, Devin Carlen wrote:
> If by mini-projects you mean small and separate projects, then I don't think
> that makes sense.
>
> All we need for this is a single project that contains submodules that don't
> contain unnecessary dependencies on other submodules wit
If by mini-projects you mean small and separate projects, then I don't think
that makes sense.
All we need for this is a single project that contains submodules that don't
contain unnecessary dependencies on other submodules within the common project.
So lots of bite size pieces that can be us
ge-
> From: "Glen Campbell"
> Sent: Monday, July 25, 2011 1:20pm
> To: "Brian Lamar" ,
> "openstack@lists.launchpad.net"
> Subject: Re: [Openstack] OpenStack Common
>
> Would it better to break it down even further? I.e., instead of trying t
All,
I love the idea of having an openstack-common project. However, the prospect of
creating such a project is daunting and quite difficult.
It's my belief that standardizing/collecting common logic into a single module
will be beneficial to our current code-base and allow for future projects
Would it better to break it down even further? I.e., instead of trying to
put ALL the common code into one project, create mini projects for
common-logging, common-configuration, etc. That would permit other
projects to adopt what they need, when they need it, rather than trying to
integrate the en
on project.
-Original Message-
From: "Glen Campbell"
Sent: Monday, July 25, 2011 1:20pm
To: "Brian Lamar" , "openstack@lists.launchpad.net"
Subject: Re: [Openstack] OpenStack Common
Would it better to break it down even further? I.e., instead of trying to
40 matches
Mail list logo
