[openstack-dev] [midonet] What repos to migrate to OpenStack infrastructure

Hi all, Trying to prepare moving our repos to the OpenStack infrastructure, I got reminded just how many repos we have in our GitHub organization [1] - and how many of those seem to be deprecated or tangential. Now, do we still want to migrate them? Pretty sure the answer is "no" for the deprecat

Re: [openstack-dev] [magnum][api] Looking for a Cross-Project Liaison for the API Working Group

Adrian, If need more than one alternates, I would like to be that. Thanks & Best Regards Hou Ming Wang On Wed, Dec 2, 2015 at 2:32 PM, 王华 wrote: > Adrian, > I would like to be an alternate. > > Regards > Wanghua > > > On Wed, Dec 2, 2015 at 10:19 AM, Adrian Otto > wrote: > >> Everett, >> >> Th

[openstack-dev] [tricircle] weekly meeting of Dec.2

Hi, Let’s have regular meeting today starting UTC1300 at #openstack-meeting. The networking proposal is updated in the document, and a proposal for stateless PoC also was updated in the doc. https://docs.google.com/document/d/18kZZ1snMOCD9IQvUKI5NVDzSASpw-QKj7l2zNqMEd3g/edit?usp=sharing Best Re

Re: [openstack-dev] [magnum][api] Looking for a Cross-Project Liaison for the API Working Group

Adrian, I would like to be an alternate. Regards Wanghua On Wed, Dec 2, 2015 at 10:19 AM, Adrian Otto wrote: > Everett, > > Thanks for reaching out. Eli is a good choice for this role. We should > also identify an alternate as well. > > Adrian > > -- > Adrian > > > On Dec 1, 2015, at 6:15 PM,

Re: [openstack-dev] [nova][glance][cinder][neutron]How to make use of x-openstack-request-id

Hi Tan, Most of the OpenStack RESTful API returns `X-Openstack-Request-Id` in the API response header but this request id is not available to the caller from the python client. When you use --debug option from command from the command prompt using client, you can see `X-Openstack-Request-Id`

Re: [openstack-dev] Gerrit Upgrade 12/16

On 12/01/2015 06:38 PM, Spencer Krum wrote: > There is a thread beginning here: > http://lists.openstack.org/pipermail/openstack-dev/2015-October/076962.html > which covers what to expect from the new software. Nice! This is awesome: the new review panel lets you edit files on the web interface. N

Re: [openstack-dev] [OpenStack-docs] [Openstack-i18n] DocImpact Changes

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/12/15 12:53, Armando M. wrote: > On 24 November 2015 at 13:11, Lana Brindley > wrote: > > Hi Akihiro, > > Judging by most of the bugs we see in the openstack-manuals queue, the > bugs that will be raised in projects' own queues will usually

Re: [openstack-dev] [Openstack-i18n] DocImpact Changes

On 24 November 2015 at 13:11, Lana Brindley wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi Akihiro, > > Judging by most of the bugs we see in the openstack-manuals queue, the > bugs that will be raised in projects' own queues will usually be against > their own developer docume

[openstack-dev] [ironic]Create vm fails when using IronicDriver

hi, all I install Ironic in my devstack by following the document http://docs.openstack.org/developer/ironic/dev/dev-quickstart.html. But I meet a problem now. Create a vm fail by nova by using IronicDriver. My nova.conf like this: ./nova.conf:scheduler_host_manager = nova.scheduler.ironic

[openstack-dev] Gerrit Upgrade 12/16

Hi All, The infra team will be taking gerrit offline for an upgrade on December 16th. We will start the operation at 17:00 UTC and will continue until about 21:00 UTC. This outage is to upgrade Gerrit to version 2.11. The IP address of Gerrit will not be changing. There is a thread beginning her

Re: [openstack-dev] [magnum][api] Looking for a Cross-Project Liaison for the API Working Group

Everett, Thanks for reaching out. Eli is a good choice for this role. We should also identify an alternate as well. Adrian -- Adrian > On Dec 1, 2015, at 6:15 PM, Qiao,Liyong wrote: > > hi Everett > I'd like to take it. > > thanks > Eli. > >> On 2015年12月02日 05:18, Everett Toews wrote: >> H

Re: [openstack-dev] [magnum][api] Looking for a Cross-Project Liaison for the API Working Group

hi Everett I'd like to take it. thanks Eli. On 2015年12月02日 05:18, Everett Toews wrote: Hello Magnumites, The API Working Group [1] is looking for a Cross-Project Liaison [2] from the Magnum project. What does such a role entail? The API Working Group seeks API subject matter experts for eac

Re: [openstack-dev] [nova] [ironic] Hardware composition

On Tue, Dec 1, 2015 at 12:07 PM, Andrew Laski wrote: > On 12/01/15 at 03:44pm, Vladyslav Drok wrote: > >> Hi list! >> >> There is an idea of making use of hardware composition (e.g. >> >> http://www.intel.com/content/www/us/en/architecture-and-technology/rack-scale-architecture/intel-rack-scale-a

Re: [openstack-dev] [tripleo][ironic][heat] Adding back the tripleo check job

On Tue, Dec 1, 2015 at 3:22 AM, Steven Hardy wrote: > On Mon, Nov 30, 2015 at 03:35:13PM -0800, Devananda van der Veen wrote: > >On Mon, Nov 30, 2015 at 3:07 PM, Zane Bitter > wrote: > > > > On 30/11/15 12:51, Ruby Loo wrote: > > > >On 30 November 2015 at 10:19, Derek Higgins >

Re: [openstack-dev] [magnum] Mesos Conductor

Hi, Sorry I was off for some days because of health issues. So I think the work items for this BP[1] are: 1)Add support to accept json file in container-create command2)Handle JSON input in docker_conductor3)Implement mesos conductor for container create,delete and list. Correct me if I am wrong.

Re: [openstack-dev] [Murano] 'NoMatchingFunctionException: No function "#operator_." matches supplied arguments' error when adding an application to an environment

Thanks Stan. It makes sense now. I was able to see the yaml in the database, but I agree that the cached file extension should change to avoid confusion. I appreciate your thorough response. Regards, --Vahid From: Stan Lagun To: "OpenStack Development Mailing List (not for usage questi

Re: [openstack-dev] [tripleo][ironic][heat] Adding back the tripleo check job

On 01/12/15 06:22, Steven Hardy wrote: > +1 > > I don't think it hurts to turn it on, but tbh I'm uncomfortable with the > mental overhead of a non-voting job that I have to manually treat as a > voting job. If it's stable enough to make it a voting job, I'd prefer we > j

Re: [openstack-dev] [Fuel][FFE] Disabling HA for RPC queues in RabbitMQ

Hello All! Well, side-effects (or any other effects) are quite obvious and predictable - this will decrease availability of RPC queues a bit. That's for sure. However, Dmitry's guess is that the overall messaging backplane stability increase (RabitMQ won't fail too often in some cases) would comp

[openstack-dev] [searchlight][ceilometer][qa][infra] Elasticsearch 2.0 client release

Hi, The elasticsearch 2.0 python client is not backwards compatible with the 1.x client nor server. Currently global-requirements has no upper cap on it; I've proposed https://review.openstack.org/252075 to cap it under version 2.0 on the basis that devstack installs elasticsearch 1.x and I ima

[openstack-dev] [nfv][telco] Telco Working Group Meeting Reminder - Wednesday December 2nd at 1400 UTC in #openstack-meeting-alt

Hi all, This week's Telco Working Group meeting [1] is on Wednesday December 2nd at 1400 UTC in #openstack-meeting-alt [2]. The proposed agenda is here: https://etherpad.openstack.org/p/nfv-meeting-agenda Thanks, Steve [1] http://eavesdrop.openstack.org/#Telco_Working_Group_meeting [2] h

Re: [openstack-dev] [Fuel] CentOS7 Merging Plan

With bit more details, I hope this covers all the risks and decision points now. First of all, current list of outstanding commits: https://etherpad.openstack.org/p/fuel_on_centos7 The above list has two sections: backwards compatible changes that can be merged one at a time even if the rest of C

[openstack-dev] [magnum][api] Looking for a Cross-Project Liaison for the API Working Group

Hello Magnumites, The API Working Group [1] is looking for a Cross-Project Liaison [2] from the Magnum project. What does such a role entail? The API Working Group seeks API subject matter experts for each project to communicate plans for API updates, review API guidelines with their project’s

Re: [openstack-dev] [api] consolidate IRC change with #openstack-sdk?

On Nov 30, 2015, at 7:58 AM, michael mccune wrote: > > On 11/30/2015 08:45 AM, Sean Dague wrote: >> Ok, I'm going to assume with no real disagreement we're agreed here. I'm >> moving the api-wg notifications to #openstack-sdks now - >> https://review.openstack.org/#/c/251357/1/gerritbot/channels.

Re: [openstack-dev] [Openstack-operators] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

On Tue, Dec 1, 2015 at 1:57 AM, Steve Martinelli wrote: > Trying to summarize here... > > - There isn't much interest in keeping eventlet around. > - Folks are OK with running keystone in a WSGI server, but feel they are > constrained by Apache. > - uWSGI could help to support multiple web server

Re: [openstack-dev] [all][glance] Add Sabari Kumar Murugesan

Thank you all for the support. It's a big responsibility and I hope to do my best. - Sabari On Tue, Dec 1, 2015 at 11:01 AM, Flavio Percoco wrote: > On 23/11/15 17:20 -0300, Flavio Percoco wrote: > >> Greetings, >> >> I'd like to propose adding Sabari Kumar Murugesan to the glance-core >> team.

Re: [openstack-dev] [Openstack-operators] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

I just upgraded to keystone liberty for one of my production clouds, and went with apache since eventlet was listed as deprecated. It was pretty easy. Just ran into one issue. RadosGW wouldn't work against it until I added "WSGIChunkedRequest On'" in the config. otherwise, the config as shipped

Re: [openstack-dev] [TripleO/heat] openstack debug command

On 02/12/15 03:18, Lennart Regebro wrote: On Tue, Dec 1, 2015 at 3:39 AM, Steve Baker wrote: I mean _here_ https://review.openstack.org/#/c/251587/ OK, that's great! If you want any help implementing it, I can try. Hey Lennart, help is always appreciated. I can elaborate on the implementa

Re: [openstack-dev] [openstack-ansible] Install Openstack-Ansible

On Tue, 2015-12-01 at 20:35 +0530, Sharma Swati6 wrote: > However, I just want to know if I have to implement this in > openstack-ansible, or for that matter, I want to add any new > component to it, are there any steps or guidelines to be followed. > For example, first I create containers and ment

Re: [openstack-dev] [nova]New Quota Subteam on Nova

So whats needed to build out that 'framework'? Is it just dispatching provision requests to nova, and then seeing when the quota becomes out of sync, and then backtracking through logs and notifications (+- other) to then figure out the root cause? Or is that framework some kind of local func

Re: [openstack-dev] [nova] [ironic] Hardware composition

On 12/01/15 at 03:44pm, Vladyslav Drok wrote: Hi list! There is an idea of making use of hardware composition (e.g. http://www.intel.com/content/www/us/en/architecture-and-technology/rack-scale-architecture/intel-rack-scale-architecture-resources.html) to create nodes for ironic. The current pr

[openstack-dev] [Fuel] Feature Freeze Exception Request: Task Based Deployment in Astute

Hi, Folks ** Intro * During Iteration 3 our Enhancements Team as long as other folks worked on the feature called "Task Based Deployment with Astute". Here is a link to its blueprint: https://blueprints.launchpad.net/fuel/+spec/task-based-deployment-astute Major implication of this feature compl

Re: [openstack-dev] [Fuel][FFE] Disabling HA for RPC queues in RabbitMQ

Hi, -1 for FFE for disabling HA for RPC queue as we do not know all side effects in HA scenarios. On Tue, Dec 1, 2015 at 7:34 PM, Dmitry Mescheryakov < dmescherya...@mirantis.com> wrote: > Folks, > > I would like to request feature freeze exception for disabling HA for RPC > queues in RabbitMQ [

Re: [openstack-dev] [Fuel] Patch size limit

Hi, On Tue, Dec 1, 2015 at 5:41 PM, Michael Krotscheck wrote: > TL/DR: I think you're trying to solve the problem the wrong way. If you're > trying to reduce the burden of large patches, I feel the project in > question should distribute the burden of reviewing the big ones so one > person's no

Re: [openstack-dev] [nova]New Quota Subteam on Nova

I am highly supportive for the idea of Nova Quota sub-team, for something as complex as Quota, as it helps to move quickly on reviews and changes. Agree with John, a test framework to test quotas will be helpful and can be one of the first task the Nova Quota sub team can focus on as that will lay

[openstack-dev] [Magnum] Networking Subteam Meeting

All, I will be on leave this Thursday and will be unable to chair the Networking Subteam meeting. Please respond if you would like to chair the meeting. Otherwise, we will not have a meeting this week and pick things back up on 12/10. Regards, Daneyon Hansen ___

Re: [openstack-dev] [keystone]Different projects authentication strategy

On 12/01/2015 01:23 AM, 1021710773 wrote: Every Developers, Hello. I here would like to ask some questions about policy rules. Now the policy rules of openstack in keystone and other projects are set in policy.json, in other words, the policy rules are equal to each projects. And the co

Re: [openstack-dev] [Fuel] Nominating Roman Prykhodchenko to python-fuelclient cores

+1 -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Tue, Dec 1, 2015 at 6:15 PM, Aleksey Kasatkin wrote: > +1. > No doubts. ) > > > Aleksey Kasatkin > > > On Tue, Dec 1, 2015 at 5:49 PM, Dmitry Pyzhov > wrote: > >> Guys, >> >> I propose to promote Roman Prykhodchenko to pytho

Re: [openstack-dev] [oslo][all] The lock files saga (and where we can go from here)

Excerpts from Joshua Harlow's message of 2015-12-01 09:28:18 -0800: > Sean Dague wrote: > > On 12/01/2015 08:08 AM, Duncan Thomas wrote: > >> > >> On 1 December 2015 at 13:40, Sean Dague >> > wrote: > >> > >> > >> The current approach means locks block on their own, are

Re: [openstack-dev] [all][glance] Add Sabari Kumar Murugesan

On 23/11/15 17:20 -0300, Flavio Percoco wrote: Greetings, I'd like to propose adding Sabari Kumar Murugesan to the glance-core team. Sabari has been contributing for quite a bit to the project with great reviews and he's also been providing great feedback in matters related to the design of the

[openstack-dev] [Fuel][FFE] Disabling HA for RPC queues in RabbitMQ

Folks, I would like to request feature freeze exception for disabling HA for RPC queues in RabbitMQ [1]. As I already wrote in another thread [2], I've conducted tests which clearly show benefit we will get from that change. The change itself is a very small patch [3]. The only thing which I want

[openstack-dev] [Fuel] Disabling HA for RPC queues in RabbitMQ

Hello guys, I would like to propose to disable HA for OpenStack RPC queues. The rationale is to reduce load on RabbitMQ by removing necessity for it to replicate messages across the cluster. You can find more details about proposal in spec [1]. To what is in the spec I can add that I've ran a tes

[openstack-dev] [Fuel] Responsibility for merging change requests to fuel-main

Hi all, according to numerous requests from fuel engineers ci-team 30 Nov updated the iso in Fuel CI (from ISO#199 to ISO#230). New iso had the last of the code from the fuel master which pass bvt tests. But ISO had the critical bug[0] which broke CI for fuel-library repository. There were 2 ways t

Re: [openstack-dev] [Neutron] Evolving the stadium concept

On 30 November 2015 at 23:43, Gal Sagie wrote: > To me, and i could got it wrong, the stadium means two main things: (At > this point in time) > > 1) Remove/ease the burden of OpenStack governance and extra job for > projects/drivers that implement Neutron and are "relatively small" > This sa

Re: [openstack-dev] [Neutron] Evolving the stadium concept

On 1 December 2015 at 03:03, Neil Jerram wrote: > On 01/12/15 10:42, Thierry Carrez wrote: > > Armando M. wrote: > >> [...] > >> So my question is: would revisiting/clarifying the concept be due after > >> some time we have seen it in action? I would like to think so. > > I also think it's time t

Re: [openstack-dev] [Neutron] Evolving the stadium concept

On 1 December 2015 at 02:40, Thierry Carrez wrote: > Armando M. wrote: > > [...] > > So my question is: would revisiting/clarifying the concept be due after > > some time we have seen it in action? I would like to think so. > > I also think it's time to revisit this experience now that it's been

Re: [openstack-dev] [Neutron] Evolving the stadium concept

On 1 December 2015 at 02:40, Neil Jerram wrote: > On 01/12/15 05:16, Doug Wiegley wrote: > > Part of the issue is that in a year, we added all the repos above. And > > all of said repos were all heading over to infra with the same newbie > > questions/mistakes. Not a bad thing in and of itself, b

Re: [openstack-dev] [TripleO] RFC: profile matching

Sorry for not getting to this earlier. Some thoughts inline. On 11/09/2015 08:51 AM, Dmitry Tantsur wrote: > Hi folks! > > I spent some time thinking about bringing profile matching back in, so > I'd like to get your comments on the following near-future plan. > > First, the scope of the probl

Re: [openstack-dev] [swift] [oslo.messaging] [fuel] [ha] Is Swift going to support oslo.messaging?

Hi, Current scheme supports only one RabbitMQ node with url parameter. That's not true, you can pass many hosts via the url like that: rabbit://user:pass@host1:port1,user:pass@host2:port2/vhost http://docs.openstack.org/developer/oslo.messaging/transport.html#oslo_messaging.TransportURL Bu

Re: [openstack-dev] [Fuel] Nominating Dmitry Burmistrov to core reviewers of fuel-mirror

Vladimir, if you've been behind of this, could you please share further plans in separate email thread or (better) provide plans in README in the repo, so everyone can be aware of planned changes and can review them too? If you or someone else propose a change, please post a link here... Thanks,

Re: [openstack-dev] [oslo][all] The lock files saga (and where we can go from here)

Sean Dague wrote: On 12/01/2015 08:08 AM, Duncan Thomas wrote: On 1 December 2015 at 13:40, Sean Daguemailto:s...@dague.net>> wrote: The current approach means locks block on their own, are processed in the order they come in, but deletes aren't possible. The busy lock would m

Re: [openstack-dev] [swift] [oslo.messaging] [fuel] [ha] Is Swift going to support oslo.messaging?

> > Denis, I actually don't think that Swift needs to use oslo.messaging at > all. The middleware loads the rabbit configuration for the Notifier class > from the CONF object here: > > https://github.com/openstack/ceilometermiddleware/blob/master/ceilometermiddleware/swift.py#L112 > and that conf o

Re: [openstack-dev] [cross-project] Cross-project Liaisons

Excerpts from Mike Perez's message of 2015-12-01 08:45:30 -0800: > On 09:29 Dec 01, Doug Hellmann wrote: > > Excerpts from Mike Perez's message of 2015-11-30 17:30:52 -0800: > > > Hello all, > > > > > > Currently for cross-project specs, the author of the spec spends the time > > > to > > > expla

Re: [openstack-dev] [oslo][all] The lock files saga (and where we can go from here)

On 12/01/2015 08:08 AM, Duncan Thomas wrote: > > > On 1 December 2015 at 13:40, Sean Dague > wrote: > > > The current approach means locks block on their own, are processed in > the order they come in, but deletes aren't possible. The busy lock would > mean d

Re: [openstack-dev] [Fuel] Nominating Roman Prykhodchenko to python-fuelclient cores

+1. No doubts. ) Aleksey Kasatkin On Tue, Dec 1, 2015 at 5:49 PM, Dmitry Pyzhov wrote: > Guys, > > I propose to promote Roman Prykhodchenko to python-fuelclient cores. He is > the main contributor and maintainer of this repo. And he did a great job > making changes toward OpenStack recommenda

Re: [openstack-dev] [Fuel] Remove nova-network as a deployment option in Fuel?

Hi, we have plugins for neutron (DVS and NSX). We'll finish the work on component registry . You could safely remove nova-network altogether. On Tue, Dec 1, 2015 at 5:49 PM, Sheena Gregson wrote: > We do support Neutron for vCenter, but – as I mentioned

Re: [openstack-dev] [oslo][all] The lock files saga (and where we can go from here)

So my takeaway is we need each project to have something like: https://gist.github.com/harlowja/b4f0ddadbda1f92cc1e2 That could possibly exist in oslo (I just threw it together) but the idea is that a thread/greenthread would run that 'run_forever' method in that code and it would periodically

Re: [openstack-dev] [cross-project] Cross-project Liaisons

On 09:29 Dec 01, Doug Hellmann wrote: > Excerpts from Mike Perez's message of 2015-11-30 17:30:52 -0800: > > Hello all, > > > > Currently for cross-project specs, the author of the spec spends the time to > > explain why a certain feature makes sense to be across multiple projects. > > This > > a

Re: [openstack-dev] [Fuel] Patch size limit

TL/DR: I think you're trying to solve the problem the wrong way. If you're trying to reduce the burden of large patches, I feel the project in question should distribute the burden of reviewing the big ones so one person's not stuck doing them all. That also means you can keep that patch in mental

Re: [openstack-dev] [swift] [oslo.messaging] [fuel] [ha] Is Swift going to support oslo.messaging?

On 12/01/2015 08:17 AM, Richard Hawkins wrote: ​Is it possible to write the functionality you desire in your own middleware for Swift that lives outside of the Swift code? I would favor that approach for the following reasons: * You would have more control over code/changes so your middleware c

Re: [openstack-dev] [Fuel] Patch size limit

Hi Maciej, thank you for bringing this up, +1, but we should discuss the limit, personally for me it's ok to review 400loc patches, if the patch covers only one bug-fix/feature implementation. So if everybody is agree, we should: 1. update contribution guide 2. create a task for *non-voting* gate

Re: [openstack-dev] [cross-project] Cross-project Liaisons

On 11/30/2015 08:30 PM, Mike Perez wrote: Hello all, Currently for cross-project specs, the author of the spec spends the time to explain why a certain feature makes sense to be across multiple projects. This also includes giving technical solutions for it working with a variety of services and

Re: [openstack-dev] [neutron][neutron-*] Notice! pylint breakage

Infra did not want to update requirements for master. I found a solution for VPN on master, namely pinning pylint and astroid in tox.ini (we already have a dependency for pylint in tox.ini). I'm thinking that for VPN on Kilo, we could cherry pick that change, rather than employ https://review.ope

[openstack-dev] [Fuel] Nominating Roman Prykhodchenko to python-fuelclient cores

Guys, I propose to promote Roman Prykhodchenko to python-fuelclient cores. He is the main contributor and maintainer of this repo. And he did a great job making changes toward OpenStack recommendations. Cores, please reply with your +1/-1. signature.asc Description: Message signed with OpenPGP

Re: [openstack-dev] [Neutron] need help in translating sql query to sqlalchemy query

On 12/01/2015 09:06 PM, Sean M. Collins wrote: On Tue, Dec 01, 2015 at 10:22:41AM EST, Venkata Anil wrote: Thanks Sean. I will check that. Meanwhile I tried this and it is working port1 = orm.aliased(models_v2.Port, name="port1") port2 = orm.aliased(models_v2.Port, name="po

[openstack-dev] [Fuel] Configuration management for Fuel 7.0

Hello, folks. We need any kind of CM for Fuel 7.0. Otherwise new project with 800+ nodes will be near impossible to support. Customer always wants to change something. In our opinion, there are two major approaches for CM: #1 Independent CM (Puppet master, Chef, Ansible, whatever) #2 Fuel-based

Re: [openstack-dev] [Neutron] need help in translating sql query to sqlalchemy query

On Tue, Dec 01, 2015 at 10:22:41AM EST, Venkata Anil wrote: > Thanks Sean. I will check that. > > Meanwhile I tried this and it is working > > port1 = orm.aliased(models_v2.Port, name="port1") > port2 = orm.aliased(models_v2.Port, name="port2") > router_intf_qry = > contex

Re: [openstack-dev] [Fuel] CentOS7 Merging Plan

Hi, in your plan you need to have an item about updating ISO on fuel-library CI gates. Regards, Alex On Tue, Dec 1, 2015 at 4:11 PM, Sergii Golovatiuk wrote: > Hi, > > On Tue, Dec 1, 2015 at 3:58 PM, Dmitry Teselkin > wrote: > >> Hello, >> >> We're almost got green BVT on custom CentOS7 ISO a

Re: [openstack-dev] [kolla] ValueError: No JSON object could be decoded

Hello, First of all, this is not a mailing list for debugging, I invite you sir/madam to join us on #kolla and ask questions there. Second, this doesn't help whole lot, we can get to the source of problem, but we need your help with that, so let me invite you again to our #kolla channel. Third, it

Re: [openstack-dev] [Neutron] need help in translating sql query to sqlalchemy query

Thanks Sean. I will check that. Meanwhile I tried this and it is working port1 = orm.aliased(models_v2.Port, name="port1") port2 = orm.aliased(models_v2.Port, name="port2") router_intf_qry = context.session.query(RouterPort.router_id).join((port1, port1.id==RouterPort.p

Re: [openstack-dev] [neutron][neutron-*] Notice! pylint breakage

Should we not be updating this in the requirements project? From: Paul Michali mailto:p...@michali.net>> Reply-To: OpenStack List mailto:openstack-dev@lists.openstack.org>> Date: Tuesday, December 1, 2015 at 4:50 PM To: OpenStack List mailto:openstack-dev@lists.openstack.org>> Subject: Re: [open

Re: [openstack-dev] [Openstack-operators] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

On Tuesday 01 December 2015 08:50:14 Lance Bragstad wrote: > On Tue, Dec 1, 2015 at 6:05 AM, Sean Dague wrote: > > > > From an interop perspective, this concerns me a bit. My > > understanding is that Apache is specifically needed for > > Federation. Federation is the norm that we want for enviro

Re: [openstack-dev] [puppet] weekly meeting #61

On 11/29/2015 03:35 PM, Emilien Macchi wrote: > Hello! > > Here's an initial agenda for our weekly meeting, Tuesday at 1500 UTC > in #openstack-meeting-4: > > https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151201 We did our (short) meeting, you ca

[openstack-dev] [nova] Milestone 13.0.0.0b1 (aka. Mitaka-1) to be cut tomorrow

Hi, As you probably know, the Mitaka Release schedule for Nova defines a first milestone between Dec 1-3 [1] We had an hard dependency for translations and reno changes [2] but now everything is landed in tree. As a consequence, the release patch is provided for cutting the milestone right

Re: [openstack-dev] [Fuel] CentOS7 Merging Plan

Hi, On Tue, Dec 1, 2015 at 3:58 PM, Dmitry Teselkin wrote: > Hello, > > We're almost got green BVT on custom CentOS7 ISO and it seems that it's > the time to discuss the plan how this feature could be merged. > > This is not the only one feature that is in a queue. Unfortunately, > almost any ot

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

Fox, this is one of the reasons. There are others listed in my original letter. Guys, I have prepared two patches [1] and [2] that can properly deploy the master node. I still have not got any positive feedback on the spec [3]. My intention was to wait until Centos 7 feature is merged and then to

Re: [openstack-dev] Install Openstack-Ansible

Hi Major, Thanks for your prompt response. I will plan to create a spec for Designate. However, I just want to know if I have to implement this in openstack-ansible, or for that matter, I want to add any new component to it, are there any steps or guidelines to be followed. For example, first

Re: [openstack-dev] [nova][libvirt] Native AIO mode - RFC

Hello! Bumping up this thread as there've been some updates in the specs discussion [1] regarding native AIO stability & performance. Seems there's also movement in the related qemu development (see inline comments). Best regards Silvan [1] https://review.openstack.org/#/c/232514/7/specs/mitaka/ap

[openstack-dev] [Fuel] CentOS7 Merging Plan

Hello, We're almost got green BVT on custom CentOS7 ISO and it seems that it's the time to discuss the plan how this feature could be merged. This is not the only one feature that is in a queue. Unfortunately, almost any other feature will be broken if merged after CentOS7, so it was decided to m

Re: [openstack-dev] [neutron][neutron-*] Notice! pylint breakage

Some additional info... astroid upstream folks are going to try to push for pylint 1.4.5 that pins to astroid 1.3.8. If that happens, we could just pin pylint at 1.4.5. Ref: https://bitbucket.org/logilab/astroid/issues/275/140-and-141-fail-to-work-with-pylint-144 It sounds like we don't need to p

Re: [openstack-dev] [Fuel] Remove nova-network as a deployment option in Fuel?

We do support Neutron for vCenter, but – as I mentioned a few months ago – we do not yet have a fully vetted way to deploy the multi-hypervisor use case with both KVM/QEMU and vCenter. This depends on our ability to select multiple networking options and align them to the correct hypervisors. P

Re: [openstack-dev] [Openstack-operators] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

On Tue, Dec 1, 2015 at 6:05 AM, Sean Dague wrote: > On 12/01/2015 01:57 AM, Steve Martinelli wrote: > > Trying to summarize here... > > > > - There isn't much interest in keeping eventlet around. > > - Folks are OK with running keystone in a WSGI server, but feel they are > > constrained by Apach

Re: [openstack-dev] [cross-project] Cross-project Liaisons

Excerpts from Mike Perez's message of 2015-11-30 17:30:52 -0800: > Hello all, > > Currently for cross-project specs, the author of the spec spends the time to > explain why a certain feature makes sense to be across multiple projects. This > also includes giving technical solutions for it working

Re: [openstack-dev] [Fuel] Patch size limit

Neil, just to clarify: moved/renamed files are marked as "R" so I think there may be some way to ignore such files when counting LOC. Maciej, I completely agree with you. It's pretty hard to review such big change,and takes a lot of time which could be saved by submitting smaller patches. +1 On

Re: [openstack-dev] [Fuel] Nominating Dmitry Burmistrov to core reviewers of fuel-mirror

Thomas, You are right about two independent modules in the repo. That is because the former intention was to get rid of fuel-mirror (and fuel-createmirror) and perestroika and leave only packetary there. Packetary is to be developed so it is able to build not only repositories but packages as wel

Re: [openstack-dev] [TripleO/heat] openstack debug command

On Tue, Dec 1, 2015 at 3:39 AM, Steve Baker wrote: > I mean _here_ > > https://review.openstack.org/#/c/251587/ OK, that's great! If you want any help implementing it, I can try. //Lennart __ OpenStack Development Mailing L

Re: [openstack-dev] [tripleo][ironic][heat] Adding back the tripleo check job

On 30/11/15 22:18, Steven Hardy wrote: On Mon, Nov 30, 2015 at 12:51:53PM -0500, Ruby Loo wrote: On 30 November 2015 at 10:19, Derek Higgins wrote: Hi All, Â Â A few months tripleo switch from its devtest based CI to one that was based on instack. Before doing this w

Re: [openstack-dev] [cross-project] Cross-project Liaisons

As someone who's surprised more than one team with a patch that apparently came from left field (until I pointed out the x-project spec), I'm totally for this. Michael On Tue, Dec 1, 2015 at 1:45 AM Thierry Carrez wrote: > Mike Perez wrote: > > [...] > > I would like to propose cross-project li

[openstack-dev] [nova] [ironic] Hardware composition

Hi list! There is an idea of making use of hardware composition (e.g. http://www.intel.com/content/www/us/en/architecture-and-technology/rack-scale-architecture/intel-rack-scale-architecture-resources.html) to create nodes for ironic. The current proposal is: 1. To create hardware-compositor ser

Re: [openstack-dev] [ceilometer][aodh][vitrage] Raising custom alarms in AODH

Thanks for the quick reply. We have a few more questions, for clarification: 1. Does AODH currently support raising alarms on resources not modeled in OpenStack? For example, raising an alarm on a Switch? Or does each alarm have to relate to a resource ID (or IDs)( 2. What we feel is missing i

Re: [openstack-dev] [all] [glance] Proposal to add Abhishek to Glance core team

> -Original Message- > From: Nikhil Komawar [mailto:nik.koma...@gmail.com] > Sent: Tuesday, December 01, 2015 6:21 AM > To: OpenStack Development Mailing List (not for usage questions); Kekane, > Abhishek > Subject: [openstack-dev] [all] [glance] Proposal to add Abhishek to Glance > core te

Re: [openstack-dev] [nova] Versioned notifications... who cares about the version?

> -Original Message- > From: Andrew Laski [mailto:and...@lascii.com] > Sent: November 30, 2015 20:32 > On 11/30/15 at 07:32am, Sean Dague wrote: > >On 11/24/2015 10:09 AM, John Garbutt wrote: > >> On 24 November 2015 at 15:00, Balázs Gibizer > >> wrote: > From: Andrew Laski [mailto:an

Re: [openstack-dev] [neutron] Purpose and documentation of the API

On Tue, Dec 01, 2015 at 07:16:00AM EST, Neil Jerram wrote: > _What is important: the API, or documented use cases?_ Both are important - however I think I understand what you are trying to tease out. > > Being theoretically inclined, I tend to assume that if an API exists, it > is the primary th

Re: [openstack-dev] [ceilometer][aodh][vitrage] Raising custom alarms in AODH

On Tue, Dec 01 2015, AFEK, Ifat (Ifat) wrote: > In Vitrage, we would like to evaluate and correlate different kinds of alarms: > AODH threshold alarms, event alarms, Nagios alarms, Ganglia alarms, Zabbix > alarms, etc. This includes alarms on physical resources that are not part of > OpenStack, li

Re: [openstack-dev] [swift] [oslo.messaging] [fuel] [ha] Is Swift going to support oslo.messaging?

?Is it possible to write the functionality you desire in your own middleware for Swift that lives outside of the Swift code? I would favor that approach for the following reasons: * You would have more control over code/changes so your middleware could stabilize and mature faster (don't have

Re: [openstack-dev] [ceilometer][aodh][vitrage] Raising custom alarms in AODH

Hi, After some further discussions with Vitrage team, let me go one step back and ask a more basic question: In Vitrage, we would like to evaluate and correlate different kinds of alarms: AODH threshold alarms, event alarms, Nagios alarms, Ganglia alarms, Zabbix alarms, etc. This includes alar

Re: [openstack-dev] [oslo][all] The lock files saga (and where we can go from here)

On 1 December 2015 at 13:40, Sean Dague wrote: > > The current approach means locks block on their own, are processed in > the order they come in, but deletes aren't possible. The busy lock would > mean deletes were normal. Some extra cpu spent on waiting, and lock > order processing would be non

Re: [openstack-dev] [neutron][L3][DVR][arp]

Some one posted a bug [1] for vlan arp responder and vlan l2population, which use the merged patch [2] for supporting the same thing in the ofagent So for DVR for vlan, I think we can continue with the bug fix above. [1] https://bugs.launchpad.net/neutron/+bug/1413056 [2] https://review

Re: [openstack-dev] Install Openstack-Ansible

On Tue, 2015-12-01 at 13:41 +0530, Sharma Swati6 wrote: > The ansible playbooks are running as of now and as per my > understanding, it is only installing the basic (main) openstack > components. > > How to install other Openstack components like Designate, Ironic, > etc. Please let me know the st

Re: [openstack-dev] [Neutron] need help in translating sql query to sqlalchemy query

Consult the API: http://docs.sqlalchemy.org/en/latest/orm/query.html#sqlalchemy.orm.query.Query.join In fact, there is already one join happening a couple lines above your change: https://github.com/openstack/neutron/blob/stable/liberty/neutron/db/l3_db.py#L800 Most likely, you will also need t

Re: [openstack-dev] [QA][Infra] Continuous OpenStack quality monitoring and quality improvement plan

2015.12.01. 13:45 keltezéssel, Andreas Jaeger írta: > On 2015-12-01 13:30, Péter Hegedűs wrote: >> Dear OpenStack QA and Dev Team, >> >> A small group at the Software Engineering Department of the University >> of Szeged, Hungary is working on the quality improvements of OpenStack >> modules in col

  1   2   >