Re: [openstack-dev] Neutron Distributed Virtual Router

I'm +1 for 'provider'. 2013/12/9 Akihiro Motoki : > Neutron defines "provider" attribute and it is/will be used in advanced > services (LB, FW, VPN). > Doesn't it fit for a distributed router case? If we can cover all services > with one concept, it would be nice. > > According to this thread, w

Re: [openstack-dev] [Horizon] Less compiler dependency

On 11/12/13 01:06 +0800, Thomas Goirand wrote: On 12/10/2013 11:41 PM, Jiri Tomasek wrote: On 12/09/2013 12:47 PM, Jaromir Coufal wrote: So I would like to ask everybody, if we can reconsider this dependency and find some other alternative. I know we moved from nodejs, because it is packaging n

Re: [openstack-dev] [heat] Stack preview

Excerpts from Richard Lee's message of 2013-12-10 09:46:49 -0800: > Hey all, > > We're working on a > blueprint > that > adds the ability to preview what a given template+parameters would create > in terms of resources. We think this woul

Re: [openstack-dev] Unified Guest Agent proposal

Excerpts from Dmitry Mescheryakov's message of 2013-12-10 08:25:26 -0800: > And one more thing, > > Sandy Walsh pointed to the client Rackspace developed and use - [1], [2]. > Its design is somewhat different and can be expressed by the following > formulae: > > App -> Host (XenStore) <-> Guest A

Re: [openstack-dev] Unified Guest Agent proposal

Excerpts from Dmitry Mescheryakov's message of 2013-12-10 08:15:15 -0800: > Guys, > > I see two major trends in the thread: > > * use Salt > * write our own solution with architecture similar to Salt or MCollective > > There were points raised pro and contra both solutions. But I have a > conc

[openstack-dev] [heat] Stack preview

Hey all, We're working on a blueprint that adds the ability to preview what a given template+parameters would create in terms of resources. We think this would provide significant value for blueprint authors and for other heat users that

Re: [openstack-dev] Neutron Distributed Virtual Router

NSX makes firewall distributed also. So besides VPN, before neutron implements FW also in a distributed fashion, it might be another reason that people need existing router. Discussion about advanced services and dvr is recorded here: https://etherpad.openstack.org/p/Distributed-Virtual-Router Bes

Re: [openstack-dev] [neutron] Third party Neutron plugin testingmeeting

+1 for 1700UTC Thursday on IRC -Original Message- From: Kyle Mestery [mailto:mest...@siliconloons.com] Sent: Tuesday, December 10, 2013 9:21 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] Third party Neutron plugin testing meeti

Re: [openstack-dev] [neutron] Third party Neutron plugin testing meeting

> > > > +1 for the meeting time. Any particular reason for voice over IRC? > > > We kind of decided that doing this over voice initially would be expedient, > but I am fine with moving to IRC. If I don't hear objections, lets assume we > will meet at 1700UTC Thursday on #openstack-meeting-alt.

Re: [openstack-dev] [Tripleo] Core reviewer update Dec

Excerpts from Robert Collins's message of 2013-12-09 16:31:37 -0800: > On 6 December 2013 21:56, Jaromir Coufal wrote: > > > > > Hey there, > > > > thanks Rob for keeping eye on this. Speaking for myself, as current > > non-coder it was very hard to keep pace with others, especially when UI was >

Re: [openstack-dev] [neutron] Third party Neutron plugin testing meeting

On Dec 10, 2013, at 10:45 AM, "Veiga, Anthony" wrote: > -Original Message- > From: Kyle Mestery > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > > Date: Tuesday, December 10, 2013 10:48 > To: "OpenStack Development Mailing List (not for usage questions)" > >

Re: [openstack-dev] [Horizon] Less compiler dependency

On 12/10/2013 11:41 PM, Jiri Tomasek wrote: > On 12/09/2013 12:47 PM, Jaromir Coufal wrote: >> So I would like to ask everybody, if we can reconsider this dependency >> and find some other alternative. I know we moved from nodejs, because >> it is packaging nightmare. But honestly, better to invest

Re: [openstack-dev] Performance Regression in Neutron/Havana compared to Quantum/Grizzly

On Tue, Dec 10, 2013 at 7:48 AM, Nathani, Sreedhar (APS) wrote: > My setup has 17 L2 agents (16 compute nodes, one Network node). Setting the > minimize_polling helped to reduce the CPU > utilization by the L2 agents but it did not help in instances getting the IP > during first boot. > > With t

Re: [openstack-dev] Catalog type naming guidelines

On 12/10/2013 09:57 AM, Sergey Lukjanov wrote: Hi, we have a concern about the correct catalog type naming for projects who'd like to have a name like "data processing". It looks like space char is not the best choice, so, mainly we're trying to choose between '-' and '_'. Currently only only sw

Re: [openstack-dev] [UX] Weekly topic - Horizon Navigation

This topic has been available on ux-askbot and ux Google+ forum before that for months. Based on that alone, I don’t believe the vote was limited. All input was taken and considered. In the end, there are strong opinions on both sides. What the final outcome was… We’ll implement the vertical

Re: [openstack-dev] [heat] Core criteria, review stats vs reality

On Tue, Dec 10, 2013 at 11:26 AM, Thierry Carrez wrote: > That's why I thought > creating VIP parties for +2 reviewers (or giving them special badges or > T-shirts) is spreading the wrong message, and encourage people to hang > on to the extra rights associated with the duty. > +1 million Chmou

Re: [openstack-dev] [neutron] Third party Neutron plugin testing meeting

-Original Message- From: Kyle Mestery Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Tuesday, December 10, 2013 10:48 To: "OpenStack Development Mailing List (not for usage questions)" Subject: [openstack-dev] [neutron] Third party Neutron plugin testing m

Re: [openstack-dev] [keystone] Service scoped role definition

Hi David, I am cool with the proposal, just wanted to grad you attention on may question which I asked in my last email (which is below) Q. what if two (or more) endpoints want to have same role_name for a service (nova.east.admin, nova.west.admin, nova.north.admin .)? (Can we think of ad

Re: [openstack-dev] [ironic][qa] How will ironic tests run in tempest?

On 12/09/2013 01:37 PM, Devananda van der Veen wrote: On Fri, Dec 6, 2013 at 2:13 PM, Clark Boylan mailto:clark.boy...@gmail.com>> wrote: We can test the ironic services, database, and the driver interfaces by using our "fake" driver within a single devstack VM today (I'm not sure the exercise

Re: [openstack-dev] OK to Use Flufl.enum

On 12/10/2013 11:26 AM, Alex Gaynor wrote: >>> from flufl.enum import IntEnum >>> class A(IntEnum): ... a = 3 ... >>> A.a If the __repr__ is *really* the only value of IntEnum, I'm less than impressed. -jay On Tue, Dec 10, 2013 at 8:23 AM, Jay Pipes mailto:jaypi...@gmail.com>> wrote:

Re: [openstack-dev] [TripleO][Tuskar] Icehouse Requirements

On 2013/09/12 23:38, Tzu-Mainn Chen wrote: Thanks for the explanation! I'm going to claim that the thread revolves around two main areas of disagreement. Then I'm going to propose a way through: a) Manual Node Assignment I think that everyone is agreed that automated node assignment through

Re: [openstack-dev] OK to Use Flufl.enum

On Tue, Dec 10, 2013 at 5:23 PM, Jay Pipes wrote: > The IntEnum is my new definition of the most worthless class ever invented > in the Python ecosystem -- taking the place of zope.interface on my > personal wall of worthlessness. this is the kind of things you can do with the new Enums : htt

Re: [openstack-dev] OK to Use Flufl.enum

>>> from flufl.enum import IntEnum >>> class A(IntEnum): ... a = 3 ... >>> A.a Alex On Tue, Dec 10, 2013 at 8:23 AM, Jay Pipes wrote: > On 12/10/2013 09:55 AM, Adam Young wrote: > >> On 12/10/2013 05:24 AM, Flavio Percoco wrote: >> >>> On 09/12/13 19:45 -0800, Alex Gaynor wrote: >>> W

Re: [openstack-dev] Unified Guest Agent proposal

And one more thing, Sandy Walsh pointed to the client Rackspace developed and use - [1], [2]. Its design is somewhat different and can be expressed by the following formulae: App -> Host (XenStore) <-> Guest Agent (taken from the wiki [3]) It has an obvious disadvantage - it is hypervisor depen

Re: [openstack-dev] [Horizon] Less compiler dependency

On 10/12/13 16:41 +0100, Jiri Tomasek wrote: On 12/09/2013 12:47 PM, Jaromir Coufal wrote: Hey all Horizoners, This is last time I am trying to bring this concern up (well at least last time for a while :)). But... Watching latest progress with updating Bootstrap to v3 and dealing with co

Re: [openstack-dev] [Neutron] DHCP Agent Reliability

On Dec 10, 2013, at 6:36 PM, Isaku Yamahata wrote: > On Mon, Dec 09, 2013 at 08:43:59AM +1300, > Robert Collins wrote: > listening: when an agent connects after an outage, it first starts listening, then does a poll for updates it missed. >>> >>> Are you suggesting that processing o

Re: [openstack-dev] OK to Use Flufl.enum

On 12/10/2013 09:55 AM, Adam Young wrote: On 12/10/2013 05:24 AM, Flavio Percoco wrote: On 09/12/13 19:45 -0800, Alex Gaynor wrote: Would it make sense to use the `enum34` package, which is a backport of teh enum package from py3k? +1 This is what we were using in Marconi. So... they seem t

Re: [openstack-dev] Unified Guest Agent proposal

Guys, I see two major trends in the thread: * use Salt * write our own solution with architecture similar to Salt or MCollective There were points raised pro and contra both solutions. But I have a concern which I believe was not covered yet. Both solutions use either ZeroMQ or message queues

Re: [openstack-dev] [Nova] New API requirements, review of GCE

Yes, I understand it perfectly, Cristopher, and cannot agree more. It's just more work to reach this right now than use what's present. Still in my opinion even in a mid-run just till IceHouse release it might be less work overall. I'm going to think it over. Alex 10.12.2013 17:47, Christophe

[openstack-dev] Fwd: [qa][tempest] Bug Triage Day - Thu 12th - Prep

would be nice to participate for the ppl interested with tempest Chmouel. -- Forwarded message -- From: Adalberto Medeiros Date: Tue, Dec 10, 2013 at 3:52 PM Subject: [openstack-dev] [qa][tempest] Bug Triage Day - Thu 12th - Prep To: OpenStack Development Mailing List Hi all!

[openstack-dev] [neutron] Third party Neutron plugin testing meeting

Last week I took an action item to organize a meeting for everyone who is doing third-party testing in Neutron for plugins, whether this is vendor or Open Source based. The idea is to share ideas around setups and any issues people hit. I'd like to set this meeting up for this week, Thursday at 170

Re: [openstack-dev] [Nova] New API requirements, review of GCE

Does nova actually have add-ons infrastructure in which our GCE API can fit? I see the plugins with xen-server only and have found this link: http://docs.openstack.org/developer/nova/api/nova.openstack.common.plugin.plugin.html. Is it the thing? I'm trying to understand what you meant by this: "

Re: [openstack-dev] Catalog type naming guidelines

On Tue, Dec 10, 2013 at 3:57 PM, Sergey Lukjanov wrote: > we have a concern about the correct catalog type naming for projects who'd > like to have a name like "data processing". just out of interests why is it a problem and need to be standardized, isn't that supposed to be a free form field?

[openstack-dev] Hyper-V Meeting Cancelled

Hi All, I will be unable to attend the Hyper-V meeting today and as such will need to postpone the discussion until next week. Peter J. Pouliot CISSP Sr. SDET OpenStack Microsoft New England Research & Development Center 1 Memorial Drive Cambridge, MA 02142 P: 1.(857).4536436 E: ppoul...@micros

Re: [openstack-dev] OK to Use Flufl.enum

On 2013-12-09 21:37, Adam Young wrote: While Python 3 has enumerated types, Python 2 does not, and the standard package to provide id, Flufl.enum, is not yet part of our code base. Is there any strong objection to including Flufl.enum? http://pythonhosted.org/flufl.enum/ It makes for some very

Re: [openstack-dev] [Horizon] Less compiler dependency

On 12/09/2013 12:47 PM, Jaromir Coufal wrote: Hey all Horizoners, This is last time I am trying to bring this concern up (well at least last time for a while :)). But... Watching latest progress with updating Bootstrap to v3 and dealing with compiling issues, I am more and more concerned abo

[openstack-dev] [rally] Weekly Rally meeting

Hi all, we would like to inform you that there will be a weekly Rally team meeting today at 17:00 UTC. The meeting will be held in the *#openstack-meeting*channel. We also encourage you to check out our weekly update post: https://wiki.openstack.org/wiki/Rally/Updates. Best regards, Mikhail Dub

Re: [openstack-dev] [keystone][heat] ec2tokens, v3 credentials and request signing

On Tue, Dec 10, 2013 at 08:12:17AM -0600, Dolph Mathews wrote: > On Mon, Dec 9, 2013 at 9:08 PM, Adam Young wrote: > > > > > > > > > On 12/09/2013 05:34 PM, Steven Hardy wrote: > > > >> Hi all, > >> > >> I have some queries about what the future of the ec2tokens API is for > >> keystone, context

Re: [openstack-dev] [Nova] New API requirements, review of GCE

On 12/10/2013 08:47 AM, Christopher Yeoh wrote: > On Tue, Dec 10, 2013 at 11:36 PM, Alexandre Levine > mailto:alev...@cloudscaling.com>> wrote: > > Russell, > > I'm a little confused about importing it into stackforge repository. > Please clarify it for me. > Right now our code is

Re: [openstack-dev] [Ceilometer] [Rally] Does Ceilometer affect instance creation?

On Tue, Dec 10 2013, Nadya Privalova wrote: > Yes, I use the same SQL for Nova and Ceilometer. Thanks for pointing this > out. My bad, I didn't take it into account. So if we want to use Ceilometer > + MySQL in production (in theory :) ) we need to use separate controllers > with Ceilometer's MySQ

[openstack-dev] Catalog type naming guidelines

Hi, we have a concern about the correct catalog type naming for projects who'd like to have a name like "data processing". It looks like space char is not the best choice, so, mainly we're trying to choose between '-' and '_'. Currently only only swift has an catalog type named with '-': 'object-s

Re: [openstack-dev] OK to Use Flufl.enum

On 12/10/2013 05:24 AM, Flavio Percoco wrote: On 09/12/13 19:45 -0800, Alex Gaynor wrote: Would it make sense to use the `enum34` package, which is a backport of teh enum package from py3k? +1 This is what we were using in Marconi. So... they seem to be doing something different from Flufl,

[openstack-dev] [qa][tempest] Bug Triage Day - Thu 12th - Prep

Hi all! We have the Tempest Bug Triage Day this Thursday and there are a few points to start digging and investigating from now on. First let me share the guidelines link (Openstack Wiki for Bug Triage): https://wiki.openstack.org/wiki/BugTriage Starting from that, there are a few issues an

Re: [openstack-dev] [Ceilometer] [Rally] Does Ceilometer affect instance creation?

Julien, Yes, I use the same SQL for Nova and Ceilometer. Thanks for pointing this out. My bad, I didn't take it into account. So if we want to use Ceilometer + MySQL in production (in theory :) ) we need to use separate controllers with Ceilometer's MySQL only. And each controller may run it's own

Re: [openstack-dev] [keystone][heat] ec2tokens, v3 credentials and request signing

On Mon, Dec 9, 2013 at 9:08 PM, Adam Young wrote: > > > > On 12/09/2013 05:34 PM, Steven Hardy wrote: > >> Hi all, >> >> I have some queries about what the future of the ec2tokens API is for >> keystone, context as we're looking to move Heat from a horrible mixture of >> v2/v3 keystone to just v3

Re: [openstack-dev] Incubation Request for Barbican

> I'd like to look at keeping things simple when they can be simple. I >need to understand why there¹s > already a key distribution service under keystone? > > >https://review.openstack.org/#/c/40692/18/openstack-identity-api/v3/src/ma >rkdown/identity-api-v3-os-kds-ext.md I¹ve said before that I

Re: [openstack-dev] [TripleO][Tuskar] Icehouse Requirements

On 2013/09/12 21:22, Robert Collins wrote: Ironic today will want IPMI address + MAC for each NIC + disk/cpu/memory stats For registration it is just Management MAC address which is needed right? Or does Ironic need also IP? I think that MAC address might be enough, we can display IP in detail

Re: [openstack-dev] [Nova] New API requirements, review of GCE

On Tue, Dec 10, 2013 at 11:36 PM, Alexandre Levine wrote: > Russell, > > I'm a little confused about importing it into stackforge repository. > Please clarify it for me. > Right now our code is a part of nova itself, adding lots of files and > changing several of existing, namely: service.py, cmd

Re: [openstack-dev] [olso] [cinder] upgrade issues in lock_path in cinder after oslo utils sync

On 12/09/2013 05:18 PM, Mark McLoughlin wrote: > On Mon, 2013-12-09 at 11:11 -0600, Ben Nemec wrote: >> On 2013-12-09 10:55, Sean Dague wrote: >>> On 12/09/2013 11:38 AM, Clint Byrum wrote: Excerpts from Sean Dague's message of 2013-12-09 08:17:45 -0800: > On 12/06/2013 05:40 PM, Ben Nemec

Re: [openstack-dev] [Oslo] First steps towards amqp 1.0

On 10/12/13 12:15 +, Gordon Sim wrote: On 12/09/2013 11:29 PM, Mark McLoughlin wrote: On Mon, 2013-12-09 at 16:05 +0100, Flavio Percoco wrote: Sounds sane to me. To put it another way, assuming all AMQP 1.0 client libraries are equal, all the operator cares about is that we have a driver th

[openstack-dev] [UX] Weekly topic - Horizon Navigation

Dear OpenStack community, each week we are going to highlight some interesting and important UX topics here on the mailing list (though I will be referencing a lot to the Askbot tool, which we use for discussions). At the moment, we are asking for attention for *Horizon's navigation redesign

Re: [openstack-dev] [Nova] New API requirements, review of GCE

Russell, I'm a little confused about importing it into stackforge repository. Please clarify it for me. Right now our code is a part of nova itself, adding lots of files and changing several of existing, namely: service.py, cmd/api.py, setup.cfg, api-paste.ini and nova.conf.sample. This is onl

Re: [openstack-dev] TransportURL and virtualhost/exchnage (was Re: [Oslo] Layering olso.messaging usage of config)

Hi Mark, Thanks for the response! Some further followup inline... On 12/09/2013 09:53 PM, Mark McLoughlin wrote: It's not a completely unreasonable approach to take, but my thinking was that a transport URL connects you to a conduit which multiple applications could be sharing so you need the a

Re: [openstack-dev] Performance Regression in Neutron/Havana compared to Quantum/Grizzly

Hello Peter, I have merged the code of following patches for minimize_polling setting and enabled minimize_polling in all the L2 agents https://review.openstack.org/45676 https://review.openstack.org/45677 https://review.openstack.org/45678 https://review.openstac

Re: [openstack-dev] [Oslo] First steps towards amqp 1.0

On 12/10/2013 12:36 AM, Mike Wilson wrote: This is the first time I've heard of the dispatch router, I'm really excited now that I've looked at it a bit. Thx Gordon and Russell for bringing this up. I'm very familiar with the scaling issues associated with any kind of brokered messaging solution.

Re: [openstack-dev] [Ceilometer] [Rally] Does Ceilometer affect instance creation?

Nadya, Julien, We are working around profiling system based on logs. This will allows us to detect bottlenecks. We should make a couple of small patches in each project to support profiling. As we are going to be well integrated with OpenStack infrastructure we are going to use Ceilometer as a l

Re: [openstack-dev] [Oslo] First steps towards amqp 1.0

On 12/09/2013 11:29 PM, Mark McLoughlin wrote: On Mon, 2013-12-09 at 16:05 +0100, Flavio Percoco wrote: Greetings, As $subject mentions, I'd like to start discussing the support for AMQP 1.0[0] in oslo.messaging. We already have rabbit and qpid drivers for earlier (and different!) versions of A

Re: [openstack-dev] [Oslo] First steps towards amqp 1.0

On 12/09/2013 10:37 PM, Russell Bryant wrote: On 12/09/2013 05:16 PM, Gordon Sim wrote: On 12/09/2013 07:15 PM, Russell Bryant wrote: Understood. The Dispatch Router was indeed created from an understanding of the limitations and drawbacks of the 'federation' feature of qpidd (which was the prim

Re: [openstack-dev] OK to Use Flufl.enum

Adam, I don't see it in the global requirements [1], needs to be added there first i think. -- dims [1] https://github.com/openstack/requirements/blob/master/global-requirements.txt On Tue, Dec 10, 2013 at 5:24 AM, Flavio Percoco wrote: > On 09/12/13 19:45 -0800, Alex Gaynor wrote: >> >> Woul

Re: [openstack-dev] [Ceilometer] Nomination of Sandy Walsh to core team

Thanks John, happy to help out if possible and I agree that events could use some extra attention. -S From: Herndon, John Luke [john.hern...@hp.com] Sent: Monday, December 09, 2013 5:30 PM To: OpenStack Development Mailing List (not for usage questions) S

Re: [openstack-dev] Scheduler sub-group agenda 12/10

Hi all, We made a etherpad about memcached based scheduler: https://etherpad.openstack.org/p/scheduler-design-proposal Best regards, Boris Pavlovic On Tue, Dec 10, 2013 at 8:16 AM, Dugger, Donald D wrote: > 1) Scheduler as a Service (review BP > https://blueprints.launchpad.net/nova/+spec/f

Re: [openstack-dev] [Openstack-security] Neutron security groups for L2 networks in Havana

Hi Aaron, I missed the latest mail of this thread in my mailbox, so pasting the content of your response below. *The issue is that the nova-api says that by default every instance needs tobe in a default security group that blocks all ingress traffic from outsideand allows all ingress from insta

Re: [openstack-dev] [Ceilometer] [Rally] Does Ceilometer affect instance creation?

On Tue, Dec 10 2013, Nadya Privalova wrote: Hi Nadya, > Guys, if you have any questions or comments you are welcome! I think that > 2x difference between avg time in "empty lab" and "5 sec polling" scenario > is not a bad result. But 100 instances that were being monitored during the > test is no

Re: [openstack-dev] [Neutron] DHCP Agent Reliability

On Dec 5, 2013, at 4:43 PM, Édouard Thuleau wrote: > There also another bug you can link/duplicate with #1192381 is > https://bugs.launchpad.net/neutron/+bug/1185916. > I proposed a fix but it's not the good way. I abandoned it. > > Édouard. Thank you for pointing this out! m. __

Re: [openstack-dev] [Heat] workflow for fixes involving numerous changes

On Tue, Dec 10, 2013 at 11:45:11AM +0200, Pavlo Shchelokovskyy wrote: > Hi all, > I am fixing assertions in unittests now (initially > https://bugs.launchpad.net/heat/+bug/1259023). I've seen that Clint have > split this bug into three separate bugs, one per assertion misuse type. As > these change

Re: [openstack-dev] [Neutron] DHCP Agent Reliability

On Tue, Dec 10, 2013 at 06:35:38PM +0900, Maru Newby wrote: > > On Dec 10, 2013, at 4:47 PM, Isaku Yamahata wrote: > > > On Tue, Dec 10, 2013 at 07:28:10PM +1300, > > Robert Collins wrote: > > > >> On 10 December 2013 19:16, Isaku Yamahata wrote: > >> > >>> Answering myself. If connection

[openstack-dev] [Ceilometer] [Rally] Does Ceilometer affect instance creation?

Hi guys, I decided to forward this message to dev list too. On the previous week I was investigating Ceilometer performance. And this letter is a brief description of my results. Lab description: 3 controllers 187 computes HA: Galera for MySQL memcached is on, RabbitMQ in HA mode Ceilometer proc

Re: [openstack-dev] [heat] Core criteria, review stats vs reality

Robert Collins wrote: > I think you have a very different definition of -core to the rest of > OpenStack. I was actually somewhat concerned about the '+2 Guard the > gate stuff' at the summit because it's so easily misinterpreted - and > there is a meme going around (I don't know if it's true or no

Re: [openstack-dev] OK to Use Flufl.enum

On 09/12/13 19:45 -0800, Alex Gaynor wrote: Would it make sense to use the `enum34` package, which is a backport of teh enum package from py3k? +1 This is what we were using in Marconi. Alex On Mon, Dec 9, 2013 at 7:37 PM, Adam Young wrote: While Python 3 has enumerated types, Python

Re: [openstack-dev] [Oslo] First steps towards amqp 1.0

On 09/12/13 17:37 -0500, Russell Bryant wrote: On 12/09/2013 05:16 PM, Gordon Sim wrote: On 12/09/2013 07:15 PM, Russell Bryant wrote: [...] One other pattern that can benefit from intermediated message flow is in load balancing. If the processing entities are effectively 'pulling' messages,

Re: [openstack-dev] Is there anyway to contribute to "Settings" from your own dashboard plugin.

On 12/09/2013 07:31 PM, vibhu wrote: > I am trying to enhance openstack horizon and would like to have my own > settings in the top level panel of "Settings". Is there a way to enhance > and contribute to this in my own django plugin. > Thanks for your help > -- pat You should take a look at http:/

[openstack-dev] [Heat] workflow for fixes involving numerous changes

Hi all, I am fixing assertions in unittests now (initially https://bugs.launchpad.net/heat/+bug/1259023). I've seen that Clint have split this bug into three separate bugs, one per assertion misuse type. As these changes will affect many files (practically every file in the tests), I would like to

[openstack-dev] [Swift] 1.11.0 release candidate

Hi everyone, A milestone-proposed branch was created for Swift in preparation for the 1.11.0 release, expected on Thursday. Please test the proposed delivery to ensure no critical regression found its way in. Release-critical fixes might be backported to the milestone-proposed branch until final

Re: [openstack-dev] [Neutron] DHCP Agent Reliability

On Mon, Dec 09, 2013 at 08:43:59AM +1300, Robert Collins wrote: > >> listening: when an agent connects after an outage, it first starts > >> listening, then does a poll for updates it missed. > > > > Are you suggesting that processing of notifications and full state > > synchronization are able

Re: [openstack-dev] [Neutron] DHCP Agent Reliability

On Dec 10, 2013, at 4:47 PM, Isaku Yamahata wrote: > On Tue, Dec 10, 2013 at 07:28:10PM +1300, > Robert Collins wrote: > >> On 10 December 2013 19:16, Isaku Yamahata wrote: >> >>> Answering myself. If connection is closed, it will reconnects automatically >>> at rpc layer. See neutron.openst

[openstack-dev] [Scheduler] about scheduler-as-a-service

we know that there is a scheduler-as-a-service[1] working in progress now, aiming at smart resource placement and also providing the instance group API work for nova. But what I wonder is does it include the feature of DRS(Distributed Resource Scheduler, something like that), as it is in vCenter[2

[openstack-dev] [Cinder] suggestion to a new driver

Hello all! we're developing a new storage appliance and per one of our customers would like to build a cinder driver. i kept digging into the documentation for the past 2 weeks and could not find anything that described the code level of API. i.e. nothing describes what each function should receiv

Re: [openstack-dev] [TripleO][Tuskar] Icehouse Requirements

On 2013/09/12 17:15, Tzu-Mainn Chen wrote: - As an infrastructure administrator, Anna wants to be able to unallocate a node from a deployment. Why? Whats her motivation. One plausible one for me is 'a machine needs to be serviced so Anna wants to remove it from the dep

Re: [openstack-dev] [Keystoneclient] [Keystone] [Solum] Last released version of keystoneclient does not work with python33

On 10 Dec 2013, at 09:20, Morgan Fainberg wrote: > I think the correct way to sync is to run the update.py script and submit a > review (I don’t think it’s changed recently). Seems pretty straightforward then, thanks. let see how the review goes here then : https://review.openstack.org/#/c

Re: [openstack-dev] [keystone] Service scoped role definition

How about the following which clearly separates naming and scoping constraints { "role": { "id": "76e72a", "domain_id" = "--id--",(optional, if present, role is named by specific domain) "project_id" = "--id--",(optional, if present, role is named by project)

Re: [openstack-dev] [Keystoneclient] [Keystone] [Solum] Last released version of keystoneclient does not work with python33

Hi Chmouel, I think the correct way to sync is to run the update.py script and submit a review (I don’t think it’s changed recently).   Cheers, Morgan On December 9, 2013 at 23:58:42, Chmouel Boudjnah (chmo...@enovance.com) wrote: On Fri, Dec 6, 2013 at 4:30 PM, Dolph Mathews wrote: ++ and

<    1   2