On 10 September 2014 17:20, Chris Friesen
wrote:
> I see that the OpenStack high availability guide is still recommending the
> active/standby method of configuring RabbitMQ.
>
> Has anyone tried using active/active with mirrored queues as recommended
> by the RabbitMQ developers? If so, what pr
On 09/10/2014 03:18 PM, Gordon Sim wrote:
> On 09/10/2014 09:58 AM, Flavio Percoco wrote:
>> To clarify the doubts of what Zaqar is or it's not, let me quote what's
>> written in the project's overview section[0]:
>>
>> "Zaqar is a multi-tenant cloud messaging service for web developers.
>
> H
Fixed the issue and it's a boneheaded one as I suspected.
I need to initialize the type ala wtypes.IPv4AddressType() instead of
just wtypes.IPv4AddressType.
Does appear that the validation for the IPv4AddressType has a bug where
is should return the value, but there is no return at all.
Thanks,
Good catch John, and good work Angus! ;)
This will save a lot of headaches.
- Original Message -
> On Mon, 8 Sep 2014 05:25:22 PM Jay Pipes wrote:
> > On 09/07/2014 10:43 AM, Matt Riedemann wrote:
> > > On 9/7/2014 8:39 AM, John Schwarz wrote:
> > >> Hi,
> > >>
> > >> Long story short: f
Thanks! Exactly what I was looking for.
On Sep 11, 2014, at 12:38 AM, Russell Bryant wrote:
> On 09/11/2014 01:32 AM, Joe Cropper wrote:
>> Hi Folks,
>>
>> Just wondering if the nova-specs master branch will have a ‘kilo’
>> directory created soon for Kilo proposals? I have a few things I’d li
On 09/11/2014 01:32 AM, Joe Cropper wrote:
> Hi Folks,
>
> Just wondering if the nova-specs master branch will have a ‘kilo’
> directory created soon for Kilo proposals? I have a few things I’d like
> to submit, just looking for the proper home.
There's some more info on that here:
http://lists.
Hi Folks,
Just wondering if the nova-specs master branch will have a ‘kilo’ directory
created soon for Kilo proposals? I have a few things I’d like to submit, just
looking for the proper home.
Thanks,
Joe
___
OpenStack-dev mailing list
OpenStack-dev@
> On 10 Sep 2014, at 5:20 PM, Chris Friesen wrote:
>
> Has anyone tried using active/active with mirrored queues as recommended by
> the RabbitMQ developers? If so, what problems did you run into?
We've been running like that for over a year, with the only
___
On 09/11/2014 12:52 AM, Angus Lees wrote:
> So easy/obvious it probably isn't even worth mentioning:
>
> Drop support for python2.6
Yeah, that's been the plan. We discussed this at the Juno summit and
representatives from most (all?) distributions carrying OpenStack were
there. Dropping in Kilo
On 09/10/2014 10:35 PM, Armando M. wrote:
> Hi,
>
> I devoured this thread, so much it was interesting and full of
> insights. It's not news that we've been pondering about this in the
> Neutron project for the past and existing cycle or so.
>
> Likely, this effort is going to take more than two
On Mon, 8 Sep 2014 05:25:22 PM Jay Pipes wrote:
> On 09/07/2014 10:43 AM, Matt Riedemann wrote:
> > On 9/7/2014 8:39 AM, John Schwarz wrote:
> >> Hi,
> >>
> >> Long story short: for future reference, if you initialize an eventlet
> >> Timeout, make sure you close it (either with a context manager
So easy/obvious it probably isn't even worth mentioning:
Drop support for python2.6
--
- Gus
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I'm having an issue where incoming validation of a complex type with a an
attribute of type IPv4Address is failing validation when it is a correct ipv4
address. Same is happening for UuidType and IPv6AddressType. I am using using
Pecan with WSME 0.6.1 and python 2.7.6.
Complex Type:
class Loa
Hi,
I devoured this thread, so much it was interesting and full of
insights. It's not news that we've been pondering about this in the
Neutron project for the past and existing cycle or so.
Likely, this effort is going to take more than two cycles, and would
require a very focused team of people
On 09/10/2014 12:56 PM, Monty Taylor wrote:
> I reject soundly and fundamentally the idea that Open Source projects
> NEED a commercial ecosystem to provide solid quality software.
That's not what I said. I said that assuring the quality of code on a
public repository is not necessarily something
On Wed, 10 Sep 2014 10:14:32 AM Sean Dague wrote:
> Going through the untriaged Nova bugs, and there are a few on a similar
> pattern:
>
> Nova operation in progress takes a while
> Crosses keystone token expiration time
> Timeout thrown
> Operation fails
> Terrible 500 error sent back to user
On 9/10/14, 3:58 PM, "Devananda van der Veen"
wrote:
>I'm going to assume that, for these benchmarks, you configured all the
>services optimally.
Sorry for any confusion; I am not trying to hide anything about the setup.
I thought I was pretty transparent about the way uWSGI, MongoDB, and Redis
- Original Message -
> From: "Steven Hardy"
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Sent: Thursday, September 11, 2014 1:55:49 AM
> Subject: Re: [openstack-dev] [all] [clients] [keystone] lack of retrying
> tokens leads to overall OpenStack fragility
>
On Thu, Sep 11, 2014 at 8:11 AM, Jay Pipes wrote:
> a) Sorting out the common code is already accounted for in Dan B's original
> proposal -- it's a prerequisite for the split.
Its a big prerequisite though. I think we're talking about a release
worth of work to get that right. I don't object to
Agreed - I’ll draft up a formal proposal in the next week or two and we can
focus the discussion there. Thanks for the feedback - this provides a good
framework for implementation considerations.
- Joe
On Sep 10, 2014, at 6:00 PM, Russell Bryant wrote:
> On 09/10/2014 06:46 PM, Joe Cropper wr
+1, Chris.
I think the key thing here is that such race conditions can already happen if
timed just right, unless there’s been some additional checks put in place in
the compute API layer since I last scanned the code. We could even look at
some x-process locking mechanisms as well if we think
On 09/10/2014 06:46 PM, Joe Cropper wrote:
> Hmm, not sure I follow the concern, Russell. How is that any different
> from putting a VM into the group when it’s booted as is done today?
> This simply defers the ‘group insertion time’ to some time after
> initial the VM’s been spawned, so I’m not
Being in the incubator won't help with this if it's a different repo as
well.
On Wed, Sep 10, 2014 at 7:22 AM, Robert Kukura
wrote:
>
> On 9/9/14, 7:51 PM, Jay Pipes wrote:
>
>> On 09/09/2014 06:57 PM, Kevin Benton wrote:
>>
>>> Hi Jay,
>>>
>>> The main component that won't work without direct i
On 09/10/2014 04:16 PM, Russell Bryant wrote:
On Sep 10, 2014, at 2:03 PM, Joe Cropper
wrote:
I would like to craft up a blueprint proposal for Kilo to add two
simple extensions to the existing server group APIs that I believe
will make them infinitely more usable in any ‘real world’ scenari
Hmm, not sure I follow the concern, Russell. How is that any different from
putting a VM into the group when it’s booted as is done today? This simply
defers the ‘group insertion time’ to some time after initial the VM’s been
spawned, so I’m not sure this creates anymore race conditions than w
On 09/10/2014 04:11 PM, Jay Pipes wrote:
On 09/10/2014 05:55 PM, Chris Friesen wrote:
If each hypervisor team mostly only modifies their own code, why would
there be conflict?
As I see it, the only causes for conflict would be in the shared code,
and you'd still need to sort out the issues wi
James Polley writes:
> On Thu, Sep 11, 2014 at 6:52 AM, James E. Blair wrote:
>
>> Steven Hardy writes:
>>
>> > Yeah, I don't know what the optimal solution is - my attention has
>> recently
>> > been drawn to queries generated via gerrit-dash-creator, which I'm
>> finding
>> > help a lot.
>>
>
> On Sep 10, 2014, at 2:03 PM, Joe Cropper wrote:
>
> I agree, Chris. I think a number of folks put in a lot of really great work
> into the existing server groups and there has been a lot of interest on their
> usage, especially given that the scheduler already has some constructs in
> pla
On 09/10/2014 05:55 PM, Chris Friesen wrote:
On 09/10/2014 02:44 AM, Daniel P. Berrange wrote:
On Tue, Sep 09, 2014 at 05:14:43PM -0700, Stefano Maffulli wrote:
I have the impression this idea has been circling around for a while but
for some reason or another (like lack of capabilities in
On 09/10/2014 02:44 AM, Daniel P. Berrange wrote:
On Tue, Sep 09, 2014 at 05:14:43PM -0700, Stefano Maffulli wrote:
I have the impression this idea has been circling around for a while but
for some reason or another (like lack of capabilities in gerrit and
other reasons) we never tried to impl
I'm trying to find a way to create a set of servers and attach a new volume
to each server.
I first tried to use block_device_mapping but that requires an existing
snapshot or volume and the deployment would fail when Rackspace
intermittently timed out trying to create the new volume from a snapsh
On Sep 10, 2014, at 5:20 PM, Brant Knudson wrote:
>
>
> On Tue, Sep 9, 2014 at 4:19 PM, Sean Dague wrote:
> As we try to stabilize OpenStack Juno, many server projects need to get
> out final client releases that expose new features of their servers.
> While this seems like not a big deal, ea
On Thu, Sep 11, 2014 at 6:52 AM, James E. Blair wrote:
> Steven Hardy writes:
>
> > Yeah, I don't know what the optimal solution is - my attention has
> recently
> > been drawn to queries generated via gerrit-dash-creator, which I'm
> finding
> > help a lot.
>
> This is one of several great solu
On Tue, Sep 9, 2014 at 4:19 PM, Sean Dague wrote:
> As we try to stabilize OpenStack Juno, many server projects need to get
> out final client releases that expose new features of their servers.
> While this seems like not a big deal, each of these clients releases
> ends up having possibly desta
On Sep 10, 2014, at 5:05 PM, Chmouel Boudjnah wrote:
> Doug Hellmann writes:
>
>> I have completed a series of patches [1] for (I think) all of the
>> specs repositories to add RSS feeds so that when specs are approved
>> and merged they are easily publicized.
>
> Col, thanks for setting
On Sep 10, 2014, at 5:07 PM, James E. Blair wrote:
> Doug Hellmann writes:
>
>> I originally thought we would want to add these feeds to
>> planet.openstack.org, but given the length of some of the specs I’m
>> less sure of that. Instead, now I think it would be better to
>> publicize the list
Doug Hellmann writes:
> I have completed a series of patches [1] for (I think) all of the
> specs repositories to add RSS feeds so that when specs are approved
> and merged they are easily publicized.
Col, thanks for setting this up.
[...]
> I originally thought we would want to add these
On Wed, 10 Sep 2014, Jay Pipes wrote:
There would be an Oslo library that would store the codification of the
resource classes and actions, along with the mapping of (resource_class,
action, version) to the JSONSchema document describing the payload field.
This seems reasonable with two cave
Doug Hellmann writes:
> I originally thought we would want to add these feeds to
> planet.openstack.org, but given the length of some of the specs I’m
> less sure of that. Instead, now I think it would be better to
> publicize the list of URLs for people who want to subscribe to some or
> all of
On Sep 10, 2014, at 4:34 PM, Yuriy Taraday wrote:
>
>
> On Tue, Sep 9, 2014 at 9:58 PM, Doug Hellmann wrote:
>
> On Sep 9, 2014, at 10:51 AM, Sean Dague wrote:
>
> > On 09/09/2014 10:41 AM, Doug Hellmann wrote:
> >>
> >> On Sep 8, 2014, at 8:18 PM, James E. Blair wrote:
> >>
> >>> Sean Da
I agree, Chris. I think a number of folks put in a lot of really great work
into the existing server groups and there has been a lot of interest on their
usage, especially given that the scheduler already has some constructs in place
to piggyback on them.
I would like to craft up a blueprint p
On Tue, Sep 9, 2014 at 12:19 PM, Kurt Griffiths
wrote:
> Hi folks,
>
> In this second round of performance testing, I benchmarked the new Redis
> driver. I used the same setup and tests as in Round 1 to make it easier to
> compare the two drivers. I did not test Redis in master-slave mode, but
> t
I have completed a series of patches [1] for (I think) all of the specs
repositories to add RSS feeds so that when specs are approved and merged they
are easily publicized.
The feeds are generated using a new sphinx plugin yasfb ("yet another sphinx
feed builder”). There is no need to explicitl
Steven Hardy writes:
> Yeah, I don't know what the optimal solution is - my attention has recently
> been drawn to queries generated via gerrit-dash-creator, which I'm finding
> help a lot.
This is one of several great solutions to the problem. Any query in
Gerrit can include an age specifier.
On Tue, Sep 9, 2014 at 9:58 PM, Doug Hellmann wrote:
>
> On Sep 9, 2014, at 10:51 AM, Sean Dague wrote:
>
> > On 09/09/2014 10:41 AM, Doug Hellmann wrote:
> >>
> >> On Sep 8, 2014, at 8:18 PM, James E. Blair wrote:
> >>
> >>> Sean Dague writes:
> >>>
> The crux of the issue is that zookee
On 09/10/2014 02:13 PM, Chris Friesen wrote:
As it stands, it seems that waiting for the RPC call to time out blocks
_report_state() from running again in report_interval seconds, which delays the
service update until the RPC timeout period expires.
Just noticed something...
In the case of
On 09/03/2014 11:37 AM, Joe Gordon wrote:
As you all know, there has recently been several very active discussions
around how to improve assorted aspects of our development process. One idea
that was brought up is to come up with a list of cycle goals/project
priorities for Kilo [0].
To that end
On 2014-09-10 12:19:08 -0700 (-0700), Vishvananda Ishaya wrote:
> I don’t think this is a viable option for us, but if we were going
> to do it, we would probably be better off using
> https://code.google.com/p/rietveld/ as a base, since it is
> actually written in python.
The proposal floated in
Hi,
I'm running Havana and I'm seeing some less-than-ideal behaviour on rabbitmq
failover. I'd like to figure out if this is expected behaviour or if something
is going wrong.
We're running rabbitmq in active/standby mode with DRBD storage. On the
controller the timeline looks like this:
07
On Wed, Sep 10, 2014 at 05:53:57PM +, Lokare, Bageshree wrote:
> Hello OpenStack Team,
>
> I have a use case where I want to host/manage a mix environment with VM's and
> baremetal servers through Overcloud (Horizon/CLI). To be specific, I am
> looking for an ability to create a new server o
Hey all,
I have written a abandon notifier script for swift. The idea is it does a
gerrit query for changes that haven't been updated for 4 weeks, has a
negative score and isn't WIP. It then sends an email notification warning
the owner that the change is being considered as an abandoned change an
On 09/10/2014 07:29 PM, Clint Byrum wrote:
Excerpts from Gordon Sim's message of 2014-09-10 06:18:52 -0700:
On 09/10/2014 09:58 AM, Flavio Percoco wrote:
Other OpenStack components can integrate with Zaqar to surface events
to end users and to communicate with guest agents that run in the
> Jay Pipes - Wednesday, September 10, 2014 3:56 PM
>On 09/03/2014 11:21 AM, Sandy Walsh wrote:
>> On 9/3/2014 11:32 AM, Chris Dent wrote:
>>> I took some notes on this a few weeks ago and extracted what seemed
>>> to be the two main threads or ideas the were revealed by the
>>> conversation that h
On 09/10/2014 10:29 AM, Stefano Maffulli wrote:
On 09/05/2014 12:36 PM, Tim Bell wrote:
How can the average deployer know whether a stackforge is
a. An early prototype which has completed (such as some of the
early LBaaS packages)
b. A project which has lost its initial steam and fur
-Original Message-
From: Daniel P. Berrange [mailto:berra...@redhat.com]
Sent: Wednesday, September 10, 2014 1:45 AM
On Tue, Sep 09, 2014 at 05:14:43PM -0700, Stefano Maffulli wrote:
> > To me, this means you don't really want a sin bin where you dump
> > drivers and tell them not to come
I want to clarify this. Jshint is not a requirement. It is not in
requirements.txt or test-requirements.txt nor is it a hard system
requirement.
Jshint is treated as an optional tool that can either be installed via tox
in the jshint testenv which uses npm to pull it down, or by manual
install. Th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/10/2014 02:26 PM, Dan Smith wrote:
>> 1) Is this tested anywhere? There are no unit tests in the patch
>> and it's not clear to me that there would be any Tempest coverage
>> of this code path. Providing this and having it break a couple
>> of
On 09/09/2014 07:04 PM, Samuel Merritt wrote:
On 9/9/14, 4:47 PM, Devananda van der Veen wrote:
On Tue, Sep 9, 2014 at 4:12 PM, Samuel Merritt
wrote:
On 9/9/14, 12:03 PM, Monty Taylor wrote:
[snip]
So which is it? Because it sounds like to me it's a thing that actually
does NOT need to diver
When a group of us met recently we discussed documenting the contribution
process to the PHP SDK. I've now done so and it's available at
https://wiki.openstack.org/wiki/OpenStack-SDK-PHP/Process.
If there are any questions or comments I'd be happy to talk about them.
__
On Sep 5, 2014, at 4:12 AM, Sean Dague wrote:
> On 09/05/2014 06:40 AM, Nikola Đipanov wrote:
>>
>>
>> Just some things to think about with regards to the whole idea, by no
>> means exhaustive.
>
> So maybe the better question is: what are the top sources of technical
> debt in Nova that we n
On 09/10/2014 03:14 PM, Ben Nemec wrote:
> On 09/10/2014 01:13 PM, Dan Smith wrote:
>>> As far as I understand it, though, that's a patch for a
>>> read-only mode. It seems bizzare, and possibly dangerous, to
>>> proxy read commands, but not write commands. It gives the
>>> impression that everyt
> 1) Is this tested anywhere? There are no unit tests in the patch and
> it's not clear to me that there would be any Tempest coverage of this
> code path. Providing this and having it break a couple of months down
> the line seems worse than not providing it at all. This is obviously
> fixable
On Sep 4, 2014, at 8:33 AM, Daniel P. Berrange wrote:
> On Thu, Sep 04, 2014 at 01:36:04PM +, Gary Kotton wrote:
>> Hi,
>> I do not think that Nova is in a death spiral. I just think that the
>> current way of working at the moment is strangling the project. I do not
>> understand why we nee
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/10/2014 01:13 PM, Dan Smith wrote:
>> As far as I understand it, though, that's a patch for a
>> read-only mode. It seems bizzare, and possibly dangerous, to
>> proxy read commands, but not write commands. It gives the
>> impression that everyt
On Sep 4, 2014, at 3:24 AM, Daniel P. Berrange wrote:
> Position statement
> ==
>
> Over the past year I've increasingly come to the conclusion that
> Nova is heading for (or probably already at) a major crisis. If
> steps are not taken to avert this, the project is likely to lo
On 09/03/2014 11:21 AM, Sandy Walsh wrote:
On 9/3/2014 11:32 AM, Chris Dent wrote:
I took some notes on this a few weeks ago and extracted what seemed
to be the two main threads or ideas the were revealed by the
conversation that happened in this thread:
* At the micro level have versione
Excerpts from Gordon Sim's message of 2014-09-10 06:18:52 -0700:
> On 09/10/2014 09:58 AM, Flavio Percoco wrote:
> > To clarify the doubts of what Zaqar is or it's not, let me quote what's
> > written in the project's overview section[0]:
> >
> > "Zaqar is a multi-tenant cloud messaging service
On 09/03/2014 11:37 AM, Joe Gordon wrote:
> As you all know, there has recently been several very active discussions
> around how to improve assorted aspects of our development process. One idea
> that was brought up is to come up with a list of cycle goals/project
> priorities for Kilo [0].
>
> T
On Wed, Sep 10, 2014 at 12:34 PM, Stefano Maffulli
wrote:
> On 09/10/2014 02:27 AM, Sylvain Bauza wrote:
>> Well, both proposals can be done : we can create subteams and the
>> Subteam-Approval Gerrit label right know before Kilo, and we could split
>> the virt repos by later once the interfaces a
> As far as I understand it, though, that's a patch for a read-only
> mode. It seems bizzare, and possibly dangerous, to proxy read
> commands, but not write commands. It gives the impression that
> everything's fine until it's not fine (because someone tried to use
> an existing script to do a c
On Wed, Sep 10, 2014 at 04:37:14PM +, Jeremy Stanley wrote:
> On 2014-09-10 09:57:17 +0100 (+0100), Steven Hardy wrote:
> > I can understand this argument, and perhaps an auto-abandon with a
> > long period like say a month for the submitter to address comments
> > and reset the clock would be
Thanks! Looks good. Only thing I noticed was that footnotes were still
referenced, but did not appear at the bottom of the page.
On 9/10/14, 6:16 AM, "Flavio Percoco" wrote:
>I've collected the information from both performance tests and put it in
>the project's wiki[0] Please, double check :D
I don't get that logic at all.
Proxying the read commands means that monitoring or report scripts will
work fine. Actual state transition scripts, which can't really work
correctly, as there are too many differences, won't.
-Sean
On 09/10/2014 12:57 PM, Solly Ross wrote:
> As far as I un
On Wed, Sep 10, 2014 at 7:13 AM, Thierry Carrez wrote:
> Joe Gordon wrote:
>> To that end, I would like to propose an exercise as discussed in the TC
>> meeting yesterday [1]:
>> Have anyone interested (especially TC members) come up with a list of
>> what they think the project wide Kilo cycle go
Hello OpenStack Team,
I have a use case where I want to host/manage a mix environment with VM's and
baremetal servers through Overcloud (Horizon/CLI). To be specific, I am looking
for an ability to create a new server on baremetal machine (instead of Vm)
through Horizon and manage the instance
> -Original Message-
> From: Stefano Maffulli [mailto:stef...@openstack.org]
> Sent: 10 September 2014 19:29
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Zaqar] Comments on the concerns arose during
> the TC meeting
>
> On 09/05/2014 12:36 PM, Tim Bell wrote:
What you are finding is the same as I found, which raised my concern.
Thanks for the pointer to legal-disc...@lists.openstack.org, I will post
the question there (let the lawyers figure it out).
On 9/10/2014 12:16 PM, Solly Ross wrote:
- Original Message -
From: "Jeremy Stanley"
On 09/10/2014 02:27 AM, Sylvain Bauza wrote:
> Well, both proposals can be done : we can create subteams and the
> Subteam-Approval Gerrit label right know before Kilo, and we could split
> the virt repos by later once the interfaces and prereqs are done.
That's what I mean in fact: create sub tea
On 09/05/2014 12:36 PM, Tim Bell wrote:
> How can the average deployer know whether a stackforge is
>
> a. An early prototype which has completed (such as some of the
> early LBaaS packages)
>
> b. A project which has lost its initial steam and further
> investment is not foreseen
>
>
- Original Message -
> From: "Jeremy Stanley"
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Sent: Wednesday, September 10, 2014 1:10:18 PM
> Subject: Re: [openstack-dev] [Horizon] Licensing issue with using JSHint in
> build
>
> On 2014-09-10 13:00:29 -0400
On 2014-09-10 13:00:29 -0400 (-0400), Solly Ross wrote:
> JSHint *isn't* Douglas Crockford. It was written by someone who
> (understandably) thought Douglas Crockford had some good ideas,
> but was overzealous.
[...]
Overzealous enough to copy his code.
> The license is as such:
> https://github.
On 2014-09-10 10:56:37 -0500 (-0500), Aaron Sahlin wrote:
[...]
> Did Horizon get permission or find some way around the licensing
> issue?
It's worth mentioning that he seems to consider the free software
legal concerns around his license choice amusing and will
apparently, upon request, provide
On Sep 10, 2014, at 4:11 AM, Li Tianqing wrote:
> After some research, i find the reason for the cycle reference. In closure,
> the _fix_paswords.func_closre reference the _fix_passwords. So the
> cycle reference happened.
> And in https://thp.io/2012/python-gc/python_gc_final_2012-01-22.pdf
JSHint *isn't* Douglas Crockford. It was written by someone who
(understandably)
thought Douglas Crockford had some good ideas, but was overzealous. It does
mostly the
same things, but is more lenient with regards to style elements.
The license is as such: https://github.com/jshint/jshint/blob
As far as I understand it, though, that's a patch for a read-only mode. It
seems bizzare, and possibly dangerous, to proxy read commands, but not write
commands. It gives the impression that everything's fine until it's not fine
(because someone tried to use an existing script to do a create c
On 2014-09-10 09:57:17 +0100 (+0100), Steven Hardy wrote:
> I can understand this argument, and perhaps an auto-abandon with a
> long period like say a month for the submitter to address comments
> and reset the clock would be a reasonable compromise?
Perhaps, but the old script lacked a bunch of
I thought it might be helpful to show a sample of the output from the
proxied commands: Please find the example here:
http://paste.openstack.org/show/Em861wMwFvrFlsWkugfX
Chris Krelle
NobodyCam
On Wed, Sep 10, 2014 at 7:33 AM, Sean Dague wrote:
> On 09/09/2014 11:22 PM, Russell Bryant wrote
Hi,
you described transport mechanism for running commands based on facts, we
have another one, which stores
all business logic in nailgun and only provides orchestrator with set of
tasks to execute. This is not a problem.
I am talking about API for plugin writer/developer. And how implement it t
On Wed, Sep 10, 2014 at 10:01 AM, Matt Riedemann
wrote:
>
>
> On 9/9/2014 4:19 PM, Sean Dague wrote:
>>
>> As we try to stabilize OpenStack Juno, many server projects need to get
>> out final client releases that expose new features of their servers.
>> While this seems like not a big deal, each o
On Wed, Sep 10, 2014 at 3:44 AM, Daniel P. Berrange wrote:
> On Tue, Sep 09, 2014 at 05:14:43PM -0700, Stefano Maffulli wrote:
>> > To me, this means you don't really want a sin bin where you dump
>> > drivers and tell them not to come out until they're fit to be
>> > reviewed by the core; You wan
I noticed that the build is using JSHint now, and before I consider
syncing it with the proposed options from the JavaScript best practices
(https://review.openstack.org/#/c/117595/), I wanted to double check and
be sure Horizon got past the legal problem with the good/evil licensing.
Some bac
On Wed, Sep 10, 2014 at 10:14:32AM -0400, Sean Dague wrote:
> Going through the untriaged Nova bugs, and there are a few on a similar
> pattern:
>
> Nova operation in progress takes a while
> Crosses keystone token expiration time
> Timeout thrown
> Operation fails
> Terrible 500 error sent ba
Hi,
as for execution of arbitrary code across the OpenStack cluster - I was
thinking of mcollective + fact filters:
1) we need to start using mcollective facts [0] [2] - we don't
use/configure this currently
2) use mcollective execute_shell_command agent (or any other agent) with
fact filter [1]
我将从 2014/09/10 开始离开办公室，到 2014/09/11 时返回。
我将在回来之后答复您的消息。
ZTE Information Security Notice: The information contained in this mail (and
any attachment transmitted herewith) is privileged and confidential and is
intended for the exclusive use
Sean Dague wrote:
> All the various bug triage graphs point out to webnumbr urls from our
> wiki - https://wiki.openstack.org/wiki/BugTriage
>
> All of webnumbr appears to be dead and not returning any data.
>
> Why this service was used predates me. Does anyone know why? Anyone know
> if it's go
Hi,
I see that the OpenStack high availability guide is still recommending
the active/standby method of configuring RabbitMQ.
Has anyone tried using active/active with mirrored queues as recommended
by the RabbitMQ developers? If so, what problems did you run into?
Thanks,
Chris
_
On 10/09/14 22:51, Sean Dague wrote:
> All the various bug triage graphs point out to webnumbr urls from our
> wiki - https://wiki.openstack.org/wiki/BugTriage
>
> All of webnumbr appears to be dead and not returning any data.
>
> Why this service was used predates me. Does anyone know why? Anyon
Also, how about checking for duplicated name? That it matches standard for
DNS?
> return u"{node_id}".format(node_id=instance.name.lower())
you could just "return instance.name.lower()" I believe..
On Wed, Sep 10, 2014 at 7:00 PM, Igor Kalnitsky
wrote:
> Hi Dmitry,
>
> It's not as easy as you
Hi folks,
Some of you may know that there is ongoing work to achieve kindof
data-driven orchestration
for Fuel. If this is new to you, please get familiar with spec:
https://review.openstack.org/#/c/113491/
Knowing that running random command on nodes will be probably most usable
type of
orchest
Bug squash day worked well on 9/9 -- squashing and triaging bugs, bringing
the openstack-manuals backlog to about 400, with 50 in progress even now!
The openstack-api-site backlog went to about 200 with 15 in progress. We
also had some fairly new docs contributors join in -- thank you everyone
who
1 - 100 of 156 matches
Mail list logo
