Re: [openstack-dev] [Mistral] Local vs. Scalable Engine

“In process” is fine to me. Winson, please register a blueprint for this change and put the link in here so that everyone can see what it all means exactly. My feeling is that we can approve and get it done pretty soon. Renat Akhmerov @ Mirantis Inc. On 25 Feb 2014, at 12:40, Dmitri Zimine

Re: [openstack-dev] [nova] Future of the Nova API

On Mon, 24 Feb 2014 17:37:04 -0800 Dan Smith wrote: > > onSharedStorage = True > > on_shared_storage = False > > This is a good example. I'm not sure it's worth breaking users _or_ > introducing a new microversion for something like this. This is > definitely what I would call a "purity" concern

[openstack-dev] [neutron] Significance of subnet_id for LBaaS Pool

Hi All, 'subnet_id' attribute of LBaaS Pool resource has been documented as "The network that pool members belong to" However, with 'HAProxy' driver, it allows to add members belonging to different subnets/networks to a lbaas Pool. It also allows to create VIP from a separate subnet than the

Re: [openstack-dev] [Mistral] Porting executor and engine to oslo.messaging

Winson, While you're looking into this and working on the design, may be also think through other executor/engine communications. We talked about executor communicating to engine over 3 channels (DB, REST, RabbitMQ) which I wasn't happy about ;) and put it off for some time. May be it can be

Re: [openstack-dev] [Mistral] Local vs. Scalable Engine

I agree with Winson's points. Inline. On Feb 24, 2014, at 8:31 PM, Renat Akhmerov wrote: > > On 25 Feb 2014, at 07:12, W Chan wrote: > >> As I understand, the local engine runs the task immediately whereas the >> scalable engine sends it over the message queue to one or more executors. >

Re: [openstack-dev] [Neutron]Do you think tanent_id should be verified

2014-02-25 11:25 GMT+08:00 Dong Liu : > Thanks Jay, now I know maybe neutron will not handle tenant > creating/deleting notifications which from keystone. > > There is another question, such as creating subnet request body: > { > "subnet": { > "name": "test_subnet", > "enable_dhcp": true

Re: [openstack-dev] [keystone] Notification When Creating/Deleting a Tenant in openstack

Hi Lance, And I'm doing the same. With the resource ID from the notification, I'm using the keystoneclient to get the project name. Regards, Nader. On Mon, Feb 24, 2014 at 10:50 AM, Lance D Bragstad wrote: > Response below. > > > Best Regards, > > Lance Bragstad > ldbra...@us.ibm.com > > Nad

Re: [openstack-dev] [Mistral] Plugin architecture for custom actions?

Yes, it’s one of the important things that we would like to implement. It’s not the highest priority right now but we definitely need to do that. Dmitri Zimine and I talked about it and at some point Dmitri wanted to start working on it. However, we can decide to rearrange our plans within the t

Re: [openstack-dev] [Mistral] Local vs. Scalable Engine

On 25 Feb 2014, at 07:12, W Chan wrote: > As I understand, the local engine runs the task immediately whereas the > scalable engine sends it over the message queue to one or more executors. Correct. > In what circumstances would we see a Mistral user using a local engine (other > than test

Re: [openstack-dev] [Mistral] Porting executor and engine to oslo.messaging

On 25 Feb 2014, at 02:21, W Chan wrote: > Renat, > > Regarding your comments on change https://review.openstack.org/#/c/75609/, I > don't think the port to oslo.messaging is just a swap from pika to > oslo.messaging. OpenStack services as I understand is usually implemented as > an RPC clie

[openstack-dev] Help a poor Nova Grizzy Backport Bug Fix

Hi all, I have a Nova Grizzly backport bug[1] in review[2] that has been hanging around for 4 months waiting for one more +2 from a stable team person. If there's someone kind enough to bump this through, it'd be appreciated ;) Thanks in advance, Michael... [1] https://launchpad.net/bugs/11885

Re: [openstack-dev] [neutron]The mechanism of physical_network & segmentation_id is logical?

Yes. You are right. The bp has implemented this function. Thank you very much. 2014-02-25 11:01 GMT+08:00 Robert Kukura : > On 02/24/2014 09:11 PM, 黎林果 wrote: >> Bob, >> >> Thank you very much. I have understood. >> >> Another question: >> When create network with provider, if the network type i

[openstack-dev] Re： [neutron]The mechanism of physical_network & segmentation_id is logical?

2014-02-24 21:50 GMT+08:00 Robert Kukura : > On 02/24/2014 07:09 AM, 黎林果 wrote: >> Hi stackers, >> >> When create a network, if we don't set provider:network_type, >> provider:physical_network or provider:segmentation_id, the >> network_type will be from cfg, but the other tow is from db's first

Re: [openstack-dev] [Neutron]Do you think tanent_id should be verified

Thanks Jay, now I know maybe neutron will not handle tenant creating/deleting notifications which from keystone. There is another question, such as creating subnet request body: { "subnet": { "name": "test_subnet", "enable_dhcp": true, "network_id": "57596b26-080d-4802-8cce-4318b7e

[openstack-dev] [Mistral] std:repeat action

Hi everyone, I have put down my thoughts about the standard repeat action blueprint. https://blueprints.launchpad.net/mistral/+spec/mistral-std-repeat-action I have added link to an etherpad document which explore a few alternatives of the approach. I have explored details of how the std:repeat

Re: [openstack-dev] [nova] Question about USB passthrough

Hi, It is a good implementation of USB redirection function of http://usbip.sourceforge.net/. But now I more concern about how to provide USB passthrough. Now that USB devices are used so widely in private/hybrid cloud like used as USB key, and there are no technical issues in libvirt/qemu. I

Re: [openstack-dev] [neutron]The mechanism of physical_network & segmentation_id is logical?

On 02/24/2014 09:11 PM, 黎林果 wrote: > Bob, > > Thank you very much. I have understood. > > Another question: > When create network with provider, if the network type is VLAN, the > provider:segmentation_id must be specified. > > In function: def _process_provider_create(self, context, attrs) > >

Re: [openstack-dev] [nova] Future of the Nova API

> -Original Message- > From: Christopher Yeoh [mailto:cbky...@gmail.com] > Sent: Tuesday, February 25, 2014 6:35 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [nova] Future of the Nova API > > > - twice the code > > - different enough

[openstack-dev] Nova Bug Scrub meeting

Hi all - i have set up the nova bug scrub meeting for Wednesdays at 1630 UTC in the #openstack-meeting-3 IRC channel The first meeting will be all about triaging the 117 un-triaged bugs (here). https://wiki.openstack.org/wiki/Meetings/NovaBugScrub#Weekly_OpenStack_Nova_Bug_Scrub_Meeting We

Re: [openstack-dev] [Mistral] Plugin architecture for custom actions?

Hi Winson, I think this is a good idea to support pluggable interface for actions. I think you can submit a BP for that. There is a python library stevedore developed in OpenStack community. I don't know the details but it looks like this library is intended to help build plugins. Thanks Georgy

Re: [openstack-dev] [nova] Future of the Nova API

CC'ing the openstack-operators mailing list to get a wider set of feedback on this question. On 02/24/2014 05:26 PM, Christopher Yeoh wrote: >> 1) Continue as we have been, and plan to release v3 once we have a >> compelling enough feature set. > > So I think we should release in Juno even if its

Re: [openstack-dev] [neutron]The mechanism of physical_network & segmentation_id is logical?

Bob, Thank you very much. I have understood. Another question: When create network with provider, if the network type is VLAN, the provider:segmentation_id must be specified. In function: def _process_provider_create(self, context, attrs) I think it can come from the db too. If get from db fail

[openstack-dev] [Horizon] Live migration

Dear Horizon developers, I think that the blueprint to add live migrations support to Horizon[0] was incorrectly labeled as a duplicate of the earlier migrate-instance blueprint[1]. [0] https://blueprints.launchpad.net/horizon/+spec/live-migration [1] https://blueprints.launchpad.net/horizon/+spe

Re: [openstack-dev] [Neutron][LBaaS] Object Model discussion

Hi y'all, Jay, in the L7 example you give, it looks like you're setting SSL parameters for a given load balancer front-end. Do you have an example you can share where where certain traffic is sent to one set of back-end nodes, and other traffic is sent to a different set of back-end nodes based on

Re: [openstack-dev] 答复: [OpenStack-dev][Nova] Can we add one configuration item for cache-using in libvirt/hypervisor?

*I think domain attribute is more appropriate than nova.conf node config, need to consider across host task like **migrate and live-migrate :)* 2014-02-24 10:45 GMT+08:00 zhangyu (AI) : > Sure, hard-coding seems weird… > > > > However, a global configuration here dominates all domains. It might

[openstack-dev] [Mistral] Plugin architecture for custom actions?

Will Mistral be supporting custom actions developed by users? If so, should the Actions module be refactored to individual plugins with a dynamic process for action type mapping/lookup? Thanks. Winson ___ OpenStack-dev mailing list OpenStack-dev@lists.o

Re: [openstack-dev] [nova] Future of the Nova API

On 02/24/2014 08:31 PM, Christopher Yeoh wrote: > On Mon, 24 Feb 2014 18:17:34 -0500 > Sean Dague wrote: > >> On 02/24/2014 06:13 PM, Chris Friesen wrote: >>> On 02/24/2014 04:59 PM, Sean Dague wrote: >>> So, that begs a new approach. Because I think at this point even if we did put out

Re: [openstack-dev] [nova] Future of the Nova API

On 02/24/2014 08:16 PM, Christopher Yeoh wrote: > On Mon, 24 Feb 2014 16:20:12 -0800 > Dan Smith wrote: >>> So the deprecation message in the patch says: >>> >>>LOG.warning(_('XML support has been deprecated and will be >>> removed in the Juno release.')) >>> >>> perhaps that shou

Re: [openstack-dev] [nova] Future of the Nova API

> onSharedStorage = True > on_shared_storage = False This is a good example. I'm not sure it's worth breaking users _or_ introducing a new microversion for something like this. This is definitely what I would call a "purity" concern as opposed to "usability". Things like the twenty different date

Re: [openstack-dev] Incubation Request: Murano

Hi Thierry, Let me clarify the situation with existing programs and projects overlap. First of all, I would like to separate questions about what program Murano as a project can fit and about any overlap with existing projects in the official programs. We position Application Catalog as a proje

Re: [openstack-dev] [nova] Future of the Nova API

On Mon, 24 Feb 2014 18:17:34 -0500 Sean Dague wrote: > On 02/24/2014 06:13 PM, Chris Friesen wrote: > > On 02/24/2014 04:59 PM, Sean Dague wrote: > > > >> So, that begs a new approach. Because I think at this point even > >> if we did put out Nova v3, there can never be a v4. It's too much, > >>

Re: [openstack-dev] [nova] Future of the Nova API

On Mon, 24 Feb 2014 16:20:12 -0800 Dan Smith wrote: > > So the deprecation message in the patch says: > > > >LOG.warning(_('XML support has been deprecated and will be > > removed in the Juno release.')) > > > > perhaps that should be changed :-) > > Maybe, but I think we can c

Re: [openstack-dev] [All] Fixed recent gate issues

> https://review.openstack.org/74451 doesn't solve the issue completely, we have > SKIP_EXERCISES=boot_from_volume,bundle,client-env,euca,swift,client-args > but failure is now in Grenade's Javelin script: > > + swift upload javelin /etc/hosts > ...(same Traceback)... > [ERROR] /opt/stack/new/grena

[openstack-dev] Hacking and PEP 257: Extra blank line at end of multi-line docstring

Seeking some clarification on the OpenStack hacking guidelines for multi-string docstrings. Q: In OpenStack projects, is a blank line before the triple closing quotes recommended (and therefore optional - this is what PEP-257 seems to suggest), required, or explicitly rejected (which could be o

Re: [openstack-dev] Incubation Request: Murano

On Mon, 2014-02-24 at 11:24 +0100, Thierry Carrez wrote: > Mark Washenberger wrote: > > Prior to this email, I was imagining that we would expand the Images > > program to go beyond storing just block device images, and into more > > structured items like whole Nova instance templates, Heat templat

Re: [openstack-dev] [Neutron][IPv6] tox error

When I see a fox, it is usually running b-( = )) Sent from my iPhone > On Feb 24, 2014, at 6:08 PM, Shixiong Shang > wrote: > > Hi, guys: > > I run into this error while running fox…..but it gave me this error…Seems > like it is related to Neutron LB. Did you see this issue before? If so, ho

Re: [openstack-dev] [nova] Future of the Nova API

> So the deprecation message in the patch says: > >LOG.warning(_('XML support has been deprecated and will be > removed in the Juno release.')) > > perhaps that should be changed :-) Maybe, but I think we can continue with the plan to rip it out in Juno. In the past when we've a

Re: [openstack-dev] [nova] Future of the Nova API

On Mon, 24 Feb 2014 15:54:42 -0800 Morgan Fainberg wrote: > Yes, micro-versioning is most likely a better approach, and I’m a fan > of using that to gain the benefits of V3 without changing for the > sake of change. Ideally in a versioned API we should be versioning a > smaller surface area than

[openstack-dev] [Mistral] Local vs. Scalable Engine

As I understand, the local engine runs the task immediately whereas the scalable engine sends it over the message queue to one or more executors. In what circumstances would we see a Mistral user using a local engine (other than testing) instead of the scalable engine? If we are keeping the local

[openstack-dev] [Tripleo][CI] check-tripleo outage

Today we had an outage of the tripleo test cloud :(. tl;dr: - we were down for 14 hours - we don't know the fundamental cause - infra were not inconvenienced - yaaay - its all ok now. Read on for more information, what little we have. We don't know exactly why it happened yet, but the contro

Re: [openstack-dev] [nova] Future of the Nova API

On Mon, 24 Feb 2014 17:47:51 -0500 Russell Bryant wrote: > On 02/24/2014 05:26 PM, Christopher Yeoh wrote: > >>> - Whilst we have existing users of the API we also have a lot more > >>> users in the future. It would be much better to allow them to > >>> use the API we want to get to as soon as p

Re: [openstack-dev] [nova] Future of the Nova API

Yes, micro-versioning is most likely a better approach, and I’m a fan of using that to gain the benefits of V3 without changing for the sake of change. Ideally in a versioned API we should be versioning a smaller surface area than “THE WHOLE API” if at all possible. If we kept the old “version”

Re: [openstack-dev] [nova] Future of the Nova API

On 02/24/2014 05:17 PM, Sean Dague wrote: On 02/24/2014 06:13 PM, Chris Friesen wrote: On 02/24/2014 04:59 PM, Sean Dague wrote: So, that begs a new approach. Because I think at this point even if we did put out Nova v3, there can never be a v4. It's too much, too big, and doesn't fit in the i

Re: [openstack-dev] [nova] Future of the Nova API

On 02/24/2014 06:31 PM, Jay Pipes wrote: > On Mon, 2014-02-24 at 17:59 -0500, Sean Dague wrote: >> So we do really need to be pragmatic here as well. Because our >> experience with v3 so far has been doing a major version bump on Nova is >> a minimum of 2 years, and that doesn't reach a completion

Re: [openstack-dev] [nova] Future of the Nova API

On Tue, 2014-02-25 at 09:11 +1030, Christopher Yeoh wrote: > On Mon, 24 Feb 2014 11:48:41 -0500 > Jay Pipes wrote: > > It's not about "forcing" providers to support all of the public API. > > It's about providing a single, well-documented, consistent HTTP REST > > API for *consumers* of that API.

Re: [openstack-dev] [nova] Future of the Nova API

On Mon, 2014-02-24 at 17:59 -0500, Sean Dague wrote: > So we do really need to be pragmatic here as well. Because our > experience with v3 so far has been doing a major version bump on Nova is > a minimum of 2 years, and that doesn't reach a completion point that > anyone's happy with to switch ove

Re: [openstack-dev] [nova] Future of the Nova API

On Mon, 2014-02-24 at 14:01 -0800, Morgan Fainberg wrote: > TL;DR, “don’t break the contract”. If we are seriously making > incompatible changes (and we will be regardless of the direction) the > only reasonable option is a new major version. 100% agreement. Note that when I asked Chris when we w

[openstack-dev] [Neutron] tox error (errors4neutron)

Hi, guys: I run into this error while running tox…..Seems like it is related to Neutron LB. Did you see this issue before? If so, how to fix it? Thanks! Shixiong shshang@net-ubuntu2:~/github/neutron$ tox -v -e py27 ……... tests.unit.test_wsgi.XMLDictSerializerTest.test_xml_with_utf8\xa2\xb

Re: [openstack-dev] [nova] Future of the Nova API

On 02/24/2014 06:13 PM, Chris Friesen wrote: > On 02/24/2014 04:59 PM, Sean Dague wrote: > >> So, that begs a new approach. Because I think at this point even if we >> did put out Nova v3, there can never be a v4. It's too much, too big, >> and doesn't fit in the incremental nature of the project.

Re: [openstack-dev] [nova] Future of the Nova API

On 02/24/2014 04:59 PM, Sean Dague wrote: So, that begs a new approach. Because I think at this point even if we did put out Nova v3, there can never be a v4. It's too much, too big, and doesn't fit in the incremental nature of the project. Does it necessarily need to be that way though? Mayb

[openstack-dev] [Neutron][IPv6] tox error

Hi, guys: I run into this error while running fox…..but it gave me this error…Seems like it is related to Neutron LB. Did you see this issue before? If so, how to fix it? Thanks! Shixiong shshang@net-ubuntu2:~/github/neutron$ tox -v -e py27 ……... tests.unit.test_wsgi.XMLDictSerializerTes

Re: [openstack-dev] [nova] Future of the Nova API

On 02/24/2014 05:49 PM, Michael Davies wrote: > On Tue, Feb 25, 2014 at 8:31 AM, Morgan Fainberg > wrote: > > On the topic of backwards incompatible changes: > > I strongly believe that breaking current clients that use the APIs > directly is the worst opti

Re: [openstack-dev] [nova] Future of the Nova API

It's really easy to just say "don't break the contract." Until we got the level of testing that we currently have in Tempest, the contract was broken pretty regularly. I'm sure there are still breaks in it around the edges where we aren't clamping down on people today. So the history of v2 is far

Re: [openstack-dev] [nova] Future of the Nova API

On Tue, Feb 25, 2014 at 8:31 AM, Morgan Fainberg wrote: > On the topic of backwards incompatible changes: > > I strongly believe that breaking current clients that use the APIs > directly is the worst option possible. All the arguments about needing to > know which APIs work based upon which back

Re: [openstack-dev] [nova] Future of the Nova API

On 02/24/2014 05:26 PM, Christopher Yeoh wrote: >>> - Whilst we have existing users of the API we also have a lot more >>> users in the future. It would be much better to allow them to use >>> the API we want to get to as soon as possible, rather than trying >>> to evolve the V2 API and forci

Re: [openstack-dev] [nova] Future of the Nova API

On Mon, 24 Feb 2014 11:48:41 -0500 Jay Pipes wrote: > It's not about "forcing" providers to support all of the public API. > It's about providing a single, well-documented, consistent HTTP REST > API for *consumers* of that API. Whether a provider chooses to, for > example, deploy with nova-networ

Re: [openstack-dev] [nova] Future of the Nova API

On 02/24/2014 04:01 PM, Morgan Fainberg wrote: TL;DR, “don’t break the contract”. If we are seriously making incompatible changes (and we will be regardless of the direction) the only reasonable option is a new major version. Agreed. I don't think we can possibly consider making backwards-in

Re: [openstack-dev] [Murano] Object-oriented approach for defining Murano Applications

Hi Keith, Thank you for bringing up this question. We think that it could be done inside Heat. This is a part of our future roadmap to bring more stuff to Heat and pass all actual work to the heat engine. However it will require a collaboration between Heat and Murano teams, so that is why we want

Re: [openstack-dev] [nova] Future of the Nova API

> The API layer is a actually quite a very thin layer on top of the > rest of Nova. Most of the logic in the API code is really just > checking incoming data, calling the underlying nova logic and then > massaging what is returned in the correct format. So as soon as you > change the format the cos

Re: [openstack-dev] [nova] Future of the Nova API

On 02/24/2014 05:01 PM, Morgan Fainberg wrote: > On the topic of backwards incompatible changes: > > I strongly believe that breaking current clients that use the APIs > directly is the worst option possible. All the arguments about needing > to know which APIs work based upon which backend driver

Re: [openstack-dev] [nova] Future of the Nova API

On Mon, 24 Feb 2014 11:13:11 -0500 Russell Bryant wrote: > > Yes, this is a major concern. It has taken an enormous amount of work > to get to where we are, and v3 isn't done. It's a good time to > re-evaluate whether we are on the right path. So I think its important to point out that we pret

Re: [openstack-dev] [Murano] Object-oriented approach for defining Murano Applications

On Mon, Feb 24, 2014 at 4:20 PM, Georgy Okrokvertskhov < gokrokvertsk...@mirantis.com> wrote: > Hi Keith, > > Thank you for bringing up this question. We think that it could be done > inside Heat. This is a part of our future roadmap to bring more stuff to > Heat and pass all actual work to the he

[openstack-dev] [nova] why doesn't _rollback_live_migration() always call rollback_live_migration_at_destination()?

I'm looking at the live migration rollback code and I'm a bit confused. When setting up a live migration we unconditionally run ComputeManager.pre_live_migration() on the destination host to do various things including setting up networks on the host. If something goes wrong with the live mig

Re: [openstack-dev] Sent the first batch of invitations to Atlanta's Summit

Make sure that you also log in, or have your username and password handy before you redeem it. If you click a link to send a password reset, you'll lose your session, and the invite code is a one-time use – I had to dig through my history to get the URL back, since the back button did not work

Re: [openstack-dev] [nova] Future of the Nova API

On the topic of backwards incompatible changes: I strongly believe that breaking current clients that use the APIs directly is the worst option possible. All the arguments about needing to know which APIs work based upon which backend drivers are used are all valid, but making an API incompatib

[openstack-dev] [Ironic] Starting to postpone work to Juno

Hi all, For the last few meetings, we've been discussing how to prioritize the work that we need to get done as we approach the close of Icehouse development. There's still some distance between where we are and where we need to be -- integration with other projects (eg. Nova), CI testing of that

Re: [openstack-dev] Sent the first batch of invitations to Atlanta's Summit

On 02/17/2014 05:21 PM, Steve Kowalik wrote: > I found it completely non-obvious too, and had to go back and look for > the link. If the promotion code text box was always visible with the > Apply button grayed out when the text box is empty, I think that would help. Unfortunately the site is mana

Re: [openstack-dev] [Murano] Object-oriented approach for defining Murano Applications

Have you considered writing Heat resource plug-ins that perform (or configure within other services) instance snapshots, backups, or whatever other maintenance workflow possibilities you want that don't exist? Then these maintenance workflows you mention could be expressed in the Heat template

Re: [openstack-dev] [nova] Future of the Nova API

On Mon, 24 Feb 2014 07:56:19 -0800 Dan Smith wrote: > > - We want to make backwards incompatible changes to the API > > and whether we do it in-place with V2 or by releasing V3 > > we'll have some form of dual API support burden. > > IMHO, the cost of maintaining both APIs (which are largely

Re: [openstack-dev] [Neutron][LBaaS] Object Model discussion

Hi Jay, Thanks for suggestions. I get the idea. I'm not sure the essence of this API is much different then what we have now. 1) We operate on parameters of loadbalancer rather then on vips/pools/listeners. No matter how we name them, the notions are there. 2) I see two opposite preferences: one i

Re: [openstack-dev] [savanna] Nominate Andrew Lazarew for savanna-core

Unanimously. Congratulations, Andrew, welcome to the core team! On Fri, Feb 21, 2014 at 4:46 PM, Matthew Farrellee wrote: > On 02/19/2014 05:40 PM, Sergey Lukjanov wrote: > >> Hey folks, >> >> I'd like to nominate Andrew Lazarew (alazarev) for savanna-core. >> >> He is among the top reviewers

Re: [openstack-dev] [Neutron][LBaaS] Feedback on SSL implementation

Hi, Barbican is the storage option we're considering, however it seems that there's not much progress with incubation of it. Another week point of our current state is a lack of secure communication between neutron server and the agent, but that is solvable. Thanks, Eugene. On Fri, Feb 21, 201

Re: [openstack-dev] bug 1203680 - fix requires doc

On 02/24/2014 03:10 PM, Ben Nemec wrote: > On 2014-02-21 17:09, Sean Dague wrote: >> On 02/21/2014 05:28 PM, Clark Boylan wrote: >>> On Fri, Feb 21, 2014 at 1:00 PM, Ben Nemec >>> wrote: On 2014-02-21 13:01, Mike Spreitzer wrote: https://bugs.launchpad.net/devstack/+bug/1203680 is l

Re: [openstack-dev] [Neutron][LBaaS] Object Model discussion

Thanks, Eugene! I've given the API a bit of thought today and jotted down some thoughts below. On Fri, 2014-02-21 at 23:57 +0400, Eugene Nikanorov wrote: > Could you provide some examples -- even in the pseudo-CLI > commands like > I did below. It's really difficult to unde

Re: [openstack-dev] OpenStack and GSoC 2014

So happy to hear that! Congrats all! 2014-02-24 16:16 GMT-03:00 Davanum Srinivas : > Hi all, > > We're in! Just got notified by Admin Team that our Organization > Application has been accepted. I've updated the etherpad with the full > responses from them. > > https://etherpad.openstack.org/p/gs

Re: [openstack-dev] bug 1203680 - fix requires doc

On 2014-02-21 17:09, Sean Dague wrote: On 02/21/2014 05:28 PM, Clark Boylan wrote: On Fri, Feb 21, 2014 at 1:00 PM, Ben Nemec wrote: On 2014-02-21 13:01, Mike Spreitzer wrote: https://bugs.launchpad.net/devstack/+bug/1203680 is literally about Glance but Nova has the same problem. There is

[openstack-dev] Satori Project Update (Configuration Discovery)

We had our first team meeting[1] today and will be holding weekly team meetings on Mondays at 15:00 UTC on #openstack-meeting-alt. An early prototype of Satori is available on pypi [2]. We’re working towards adding the following features before making an announcement to the user list on availab

Re: [openstack-dev] [nova] Simulating many fake nova compute nodes for scheduler testing

Thanks John, I also think it is a good idea to test the algorithm at unit test level, but I will like to try out over amqp as well, that is, we process and threads talking to each other over rabbit or qpid. I'm trying to test out performance as well. Regards, David Peraza -Original Messag

[openstack-dev] [Mistral] Porting executor and engine to oslo.messaging

Renat, Regarding your comments on change https://review.openstack.org/#/c/75609/, I don't think the port to oslo.messaging is just a swap from pika to oslo.messaging. OpenStack services as I understand is usually implemented as an RPC client/server over a messaging transport. Sync vs async calls

[openstack-dev] [infra] Meeting Tuesday February 25th at 19:00 UTC

Hi everyone, The OpenStack Infrastructure (Infra) team is hosting our weekly meeting tomorrow, Tuesday February 25th, at 19:00 UTC in #openstack-meeting Meeting agenda available here: https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is welcome to to add agenda items) Everyone in

[openstack-dev] OpenStack and GSoC 2014

Hi all, We're in! Just got notified by Admin Team that our Organization Application has been accepted. I've updated the etherpad with the full responses from them. https://etherpad.openstack.org/p/gsoc2014orgapp thanks, dims ___ OpenStack-dev mailing

Re: [openstack-dev] Missing tests

HI! I'm sorry it took me this long to answer you. During the fixtures of the UT , there must be somewhere where you can add the extensions to load them, so their tests won't break.Could you send me a link to your patch in gerrit? From: Vinod Kumar Boppanna [mailto:vinod.kumar.boppa...@cern.ch] S

Re: [openstack-dev] [Neutron] L3 HA VRRP concerns

Hi Assaf, some comments inline. As a general comment, I'd prefer to move all the discussions to gerrit since the patches are now in review. This unless you have design concerns (the ones below look more related to the implementation to me) Salvatore On 24 February 2014 15:58, Assaf Muller wrot

Re: [openstack-dev] [keystone] Notification When Creating/Deleting a Tenant in openstack

Response below. Best Regards, Lance Bragstad ldbra...@us.ibm.com Nader Lahouti wrote on 02/24/2014 11:31:10 AM: > From: Nader Lahouti > To: "OpenStack Development Mailing List (not for usage questions)" > , > Date: 02/24/2014 11:37 AM > Subject: Re: [openstack-dev] [keystone] Notification W

Re: [openstack-dev] [Neutron] ERROR: InvocationError: when running tox

Thanks guys. Yes, Ben, I can see oslo.config installed in tox sub-directory. I will try to wipe tox out and try again. You are right though, the tox.ini only has site-packages for Jenkins noted. Sean, I think your first email response might be right. I am running on a Mac instead of Ubuntu box. I

Re: [openstack-dev] [Murano] Object-oriented approach for defining Murano Applications

Hi Stan, It is good that we are on a common ground here :) Of course this can be done by Heat. In fact - it will be, in the very same manner as it always was, I am pretty sure we've discussed this many times already. When Heat Software config is fully implemented, it will be possible to use it in

Re: [openstack-dev] [Neutron] ERROR: InvocationError: when running tox

On 2014-02-24 09:02, Randy Tuttle wrote: > Has anyone experienced this issue when running tox. I'm trying to figure if > this is some limit of tox environment or something else. I've seen this > referenced in other projects, but can't seem to zero in on a proper fix. > > tox -e py27 > > [.

Re: [openstack-dev] [nova] Question about USB passthrough

On 02/24/2014 01:10 AM, Liuji (Jeremy) wrote: > Hi, Boris and all other guys: > > I have found a BP about USB device passthrough in > https://blueprints.launchpad.net/nova/+spec/host-usb-passthrough. > I have also read the latest nova code and make sure it doesn't support USB > passthrough by no

Re: [openstack-dev] [Neutron][LBaaS] Object Model discussion

Folks, So far everyone agrees that the model should be pure logical, but no one came up with the API and meaningful implementation details (at least at idea level) of such obj model. As I've pointed out, 'pure logical' object model has some API and user experience inconsistencies that we need to s

Re: [openstack-dev] [Ironic] ilo driver need to submit a code change in nova ironic driver

Hi Barmawer, Currently the Ironic Nova driver is blocked from merging. The Ironic team is working on getting all the pieces in place for our C.I. testing. At this point I would say your best path is to create your patch with 51328 as a dependency. Please note that the nova driver will most likely

Re: [openstack-dev] [nova] Future of the Nova API

On 2/24/2014 10:13 AM, Russell Bryant wrote: On 02/24/2014 01:50 AM, Christopher Yeoh wrote: Hi, There has recently been some speculation around the V3 API and whether we should go forward with it or instead backport many of the changes to the V2 API. I believe that the core of the concern is

Re: [openstack-dev] [nova] Question about USB passthrough

On Mon, 2014-02-24 at 04:10 +, Liuji (Jeremy) wrote: > I have found a BP about USB device passthrough in > https://blueprints.launchpad.net/nova/+spec/host-usb-passthrough. > I have also read the latest nova code and make sure it doesn't support > USB passthrough by now. > > Are there any pro

Re: [openstack-dev] [Neutron][LBaaS] Object Model discussion

Hi, I also agree that the model should be pure logical. I think that the existing model is almost correct but the pool should be made pure logical. This means that the vip <>pool relationships needs also to become any to any. Eugene, has rightfully pointed that the current "state" management

Re: [openstack-dev] [keystone] Notification When Creating/Deleting a Tenant in openstack

Hi Swann, I was able to listen to keystone notification by setting notifications in the keystone.conf file. I only needed the notification (CURD) for project and handle it in my plugin code so don't need ceilometer to handle them. The other issue is that the notification is only for limited to res

Re: [openstack-dev] [Neutron][LBaaS] Object Model discussion

Mark, I'm not sure I understand what are implementation details in the workflow I have proposed in the email above, could you point to them? Thanks, Eugene. On Mon, Feb 24, 2014 at 8:31 PM, Mark McClain wrote: > > On Feb 21, 2014, at 1:29 PM, Jay Pipes wrote: > > I disagree on this point. I

[openstack-dev] [gantt] scheduler sub-group meeting tomorrow (2/25)

All- I'm tempted to cancel the gantt meeting for tomorrow. The only topics I have are the no-db scheduler update (we can probably do that via email) and the gantt code forklift (I've been out with the flu and there's no progress on that). I'm willing to chair but I'd like to have some specifi

Re: [openstack-dev] [nova][libvirt] Is there anything blocking the libvirt driver from implementing the host_maintenance_mode API?

On 02/20/2014 11:38 AM, Matt Riedemann wrote: On 2/19/2014 4:05 PM, Matt Riedemann wrote: The os-hosts OS API extension [1] showed up before I was working on the project and I see that only the VMware and XenAPI drivers implement it, but was wondering why the libvirt driver doesn't - either no

Re: [openstack-dev] [Neutron] ERROR: InvocationError: when running tox

Sorry - fired off this e-mail without looking too closely at your log output - I just saw the escape characters and the long lines from tox and it reminded me of the last discussion we had about it. It's probably not the same error as I was describing. That's the tough thing that I strongly dislik

[openstack-dev] [Mistral] Community meeting minutes - 02/24/2014

Folks, Thanks for joining us at #openstack-meeting. Here are the links to the meeting minutes and log: Minutes: http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-02-24-16.00.html Log: http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-02-24-16.00.log.html Next m

Re: [openstack-dev] [nova] Future of the Nova API

On 02/24/2014 01:50 AM, Christopher Yeoh wrote: > Hi, > > There has recently been some speculation around the V3 API and whether > we should go forward with it or instead backport many of the changes > to the V2 API. I believe that the core of the concern is the extra > maintenance and test burden

  1   2   >