On Wed, 2012-06-06 at 15:41 -0400, Mark Washenberger wrote:
> Sorry if this has already been posted somewhere and I just can't find it,
> but is there an openstack common weekly meeting where you guys talk about
> your blueprints and determine what is going into common and in what form?
> I think
> But the reality is that projects which use openstack-common need to be
> prepared that someday they might re-sync with latest openstack-common
> using update.py and find the API has changed.
That sounds good, especially during the early parts of incubation.
> In the absence of someone appearing
On Wed, 2012-06-06 at 12:05 -0400, Doug Hellmann wrote:
> Ceilometer is currently importing bits we need either directly from nova or
> openstack-common (by "importing" I mean literally using the "import"
> statement in our code, not copying the required modules into the ceilometer
> code base). I
On Wed, Jun 6, 2012 at 10:58 AM, Mark McLoughlin wrote:
> On Tue, 2012-06-05 at 17:25 -0400, Mark Washenberger wrote:
> >
> > "Mark McLoughlin" said:
> >
> > > On Tue, 2012-06-05 at 12:21 -0400, Mark Washenberger wrote:
> > >> > http://wiki.openstack.org/CommonLibrary#Incubation
> > >>
> > >> On
On Tue, 2012-06-05 at 17:25 -0400, Mark Washenberger wrote:
>
> "Mark McLoughlin" said:
>
> > On Tue, 2012-06-05 at 12:21 -0400, Mark Washenberger wrote:
> >> > http://wiki.openstack.org/CommonLibrary#Incubation
> >>
> >> Once an api is in incubation, if you make a change to it, you are
> >> exp
On 06/05/2012 05:35 PM, Russell Bryant wrote:
> On 06/05/2012 05:25 PM, Mark Washenberger wrote:
>>
>>
>> "Mark McLoughlin" said:
>>
>>> On Tue, 2012-06-05 at 12:21 -0400, Mark Washenberger wrote:
> http://wiki.openstack.org/CommonLibrary#Incubation
Once an api is in incubation, if y
On 06/05/2012 05:25 PM, Mark Washenberger wrote:
>
>
> "Mark McLoughlin" said:
>
>> On Tue, 2012-06-05 at 12:21 -0400, Mark Washenberger wrote:
http://wiki.openstack.org/CommonLibrary#Incubation
>>>
>>> Once an api is in incubation, if you make a change to it, you are
>>> expected to updat
"Mark McLoughlin" said:
> On Tue, 2012-06-05 at 12:21 -0400, Mark Washenberger wrote:
>> > http://wiki.openstack.org/CommonLibrary#Incubation
>>
>> Once an api is in incubation, if you make a change to it, you are
>> expected to update all the other openstack projects (not just core
>> projects
On Tue, Jun 5, 2012 at 1:00 PM, Mark McLoughlin wrote:
> On Tue, 2012-06-05 at 12:48 -0400, Duncan McGreggor wrote:
>> +1 :-)
>
> In all seriousness - Mark made two separate points. Which one are you
> top-posting a +1 to?
Ah, sorry -- I'll be more explicit. Condensing my previous comments:
if gl
On Tue, 2012-06-05 at 12:48 -0400, Duncan McGreggor wrote:
> +1 :-)
In all seriousness - Mark made two separate points. Which one are you
top-posting a +1 to?
> On Fri, Jun 1, 2012 at 10:37 AM, Mark Washenberger
> wrote:
> > Hi Mark,
> >
> > Please forgive the top-posting! I always get way too w
On Tue, 2012-06-05 at 12:21 -0400, Mark Washenberger wrote:
> > http://wiki.openstack.org/CommonLibrary#Incubation
>
> Once an api is in incubation, if you make a change to it, you are
> expected to update all the other openstack projects (not just core
> projects?) to make them work with the new
+1 :-)
d
On Fri, Jun 1, 2012 at 10:37 AM, Mark Washenberger
wrote:
> Hi Mark,
>
> Please forgive the top-posting! I always get way too wordy with
> inline replies.
>
> Regarding configuration, I think there is another option I'd like us
> to adopt. We should implement the code as in your option
> http://wiki.openstack.org/CommonLibrary#Incubation
Once an api is in incubation, if you make a change to it, you are expected to
update all the other openstack projects (not just core projects?) to make them
work with the new api. Am I understanding this requirement correctly? If so,
how is t
On Fri, 2012-06-01 at 10:37 -0400, Mark Washenberger wrote:
> Hi Mark,
>
> Please forgive the top-posting! I always get way too wordy with
> inline replies.
>
> Regarding configuration, I think there is another option I'd like us
> to adopt. We should implement the code as in your option #1, but
Hi Mark,
Please forgive the top-posting! I always get way too wordy with
inline replies.
Regarding configuration, I think there is another option I'd like us
to adopt. We should implement the code as in your option #1, but then
implement convenience factories that give the appearance of option #3
On Fri, Jun 1, 2012 at 3:46 AM, Gary Kotton wrote:
> On 06/01/2012 12:47 AM, Russell Bryant wrote:
>
>> On 05/31/2012 04:21 PM, Mark McLoughlin wrote:
>>
>>> I expect to do a pretty detailed review of the patch to add rpc to
>>> openstack-common and make some API design recommendations. But I thi
On 06/01/2012 12:47 AM, Russell Bryant wrote:
On 05/31/2012 04:21 PM, Mark McLoughlin wrote:
I expect to do a pretty detailed review of the patch to add rpc to
openstack-common and make some API design recommendations. But I think
we'll have to balance some of those design ideas between "stuff w
On 05/31/2012 04:21 PM, Mark McLoughlin wrote:
> I expect to do a pretty detailed review of the patch to add rpc to
> openstack-common and make some API design recommendations. But I think
> we'll have to balance some of those design ideas between "stuff we
> really should fix before it goes into o
On Thu, May 31, 2012, Mark McLoughlin wrote:
> On Thu, 2012-05-31 at 08:58 -0700, Johannes Erdfelt wrote:
> > My XenAPI idempotency branch delays ACKs until after it's done
> > processing the message to ensure we get the message again after
> > restart.
> >
> > https://review.openstack.org/#/c/73
On Thu, May 31, 2012 at 4:21 PM, Mark McLoughlin wrote:
> Hi Mark,
>
> On Thu, 2012-05-31 at 10:48 -0400, Mark Washenberger wrote:
>>
>> "Jay Pipes" said:
>> > On 05/29/2012 04:04 AM, Mark McLoughlin wrote:
>> >> Adopting this pattern across all projects will actually help
>> >> openstack-common
On Thu, 2012-05-31 at 08:58 -0700, Johannes Erdfelt wrote:
> > * let the consumer code decide when to ack a message
> >(although maybe the concept of acking doesn't exist for all
> implementations?)
>
> My XenAPI idempotency branch delays ACKs until after it's done
> processing the message to
Hi Mark,
On Thu, 2012-05-31 at 10:48 -0400, Mark Washenberger wrote:
>
> "Jay Pipes" said:
> > On 05/29/2012 04:04 AM, Mark McLoughlin wrote:
> >> Adopting this pattern across all projects will actually help
> >> openstack-common more generally. For example, Russell is moving the RPC
> >> code i
On Thu, May 31, 2012 at 11:26 AM, Doug Hellmann
wrote:
>
>
> On Thu, May 31, 2012 at 10:48 AM, Mark Washenberger
> wrote:
>>
>>
>>
>> "Jay Pipes" said:
>> > On 05/29/2012 04:04 AM, Mark McLoughlin wrote:
>> >> Adopting this pattern across all projects will actually help
>> >> openstack-common mo
On Thu, May 31, 2012, Mark Washenberger wrote:
> * not be tied up with eventlet on the consumer side
Yes!
> * let the consumer code decide when to ack a message
>(although maybe the concept of acking doesn't exist for all
> implementations?)
My XenAPI idempotency branch delays ACKs until
On Thu, May 31, 2012 at 10:48 AM, Mark Washenberger <
mark.washenber...@rackspace.com> wrote:
>
>
> "Jay Pipes" said:
> > On 05/29/2012 04:04 AM, Mark McLoughlin wrote:
> >> Adopting this pattern across all projects will actually help
> >> openstack-common more generally. For example, Russell is
"Jay Pipes" said:
> On 05/29/2012 04:04 AM, Mark McLoughlin wrote:
>> Adopting this pattern across all projects will actually help
>> openstack-common more generally. For example, Russell is moving the RPC
>> code into openstack-common and it has a bunch of configuration options.
>> If it can as
On 05/29/2012 04:04 AM, Mark McLoughlin wrote:
Hey,
I had the chance to discuss the "global conf" issue with a good number
of folks at the design summit and the conclusion I came away with was
that opinions range from "meh, it's fairly inelegant but I don't care
much either way" to "I actually l
On Tue, May 29, 2012 at 4:04 AM, Mark McLoughlin wrote:
> Hey,
>
> I had the chance to discuss the "global conf" issue with a good number
> of folks at the design summit and the conclusion I came away with was
> that opinions range from "meh, it's fairly inelegant but I don't care
> much either wa
Hey,
I had the chance to discuss the "global conf" issue with a good number
of folks at the design summit and the conclusion I came away with was
that opinions range from "meh, it's fairly inelegant but I don't care
much either way" to "I actually like the simplicity" to "we use global
conf, it wo
Hi Joe,
On Mon, 2012-03-12 at 17:42 -0700, Joseph Heck wrote:
> I personally don't have a huge preference one way or the other. I've
> used a global object for configuration in applications, and find it
> immensely convenient, and the methods that Mark (and others) have put
> into the openstack/co
On 03/12/2012 08:58 PM, Adam Young wrote:
Also, these global objects force us to do a bunch of hacks in unit
tests. We need to do tricks to ensure the object is initialized as
we want. We also need to save and restore its state between runs.
I don't agree with the statement that
Also, these global objects force us to do a bunch of hacks in unit
tests. We need to do tricks to ensure the object is initialized as
we want. We also need to save and restore its state between runs.
I don't agree with the statement that they force "a bunch of hacks,"
I personally don't have a huge preference one way or the other. I've used a
global object for configuration in applications, and find it immensely
convenient, and the methods that Mark (and others) have put into the
openstack/common/cfg seem pretty amenable to adding on options as needed - top
Really not trying to derail, but
"Mark McLoughlin" said:
>
> [..]
>> > Also, these global objects force us to do a bunch of hacks in unit
>> > tests. We need to do tricks to ensure the object is initialized as
>> > we want. We also need to save and restore its state between runs.
>>
Hey,
On Tue, 2012-03-06 at 14:44 -0800, Andy Smith wrote:
> This is going to be a somewhat verbose reply.
Positively terse by my standards :)
> TL;DR:
>
> Summary, I'd like cfg.py to be config.py (pipe dream, I'm sure, but I
> don't really agree with the abbreviation), to provide a global
> con
This is going to be a somewhat verbose reply.
TL;DR:
Summary, I'd like cfg.py to be config.py (pipe dream, I'm sure, but I don't
really agree with the abbreviation), to provide a global configuration
object,
and to have shortcuts for registration of options, that projects should
standardize on. A
How about decorators? For example:
@cfg.used_here(
cfg.IntOpt('one_opt', default=1),
cfg.StrOpt('other_opt', default="www"))
def func([self, ]conf, arg1, arg2):
do_smth_with(conf.one_opt, conf.other_opt)
Of course, this used_here should be able to receive a list of opts and
to be appl
Hey,
The original cfg design[1] assumed certain usage patterns that I hoped
would be adopted by all projects using it. In gerrit, we're debating a
set of patch to make keystone use these patterns:
https://review.openstack.org/4547
I thought it was best to move some of that discussion here sinc
38 matches
Mail list logo
