Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug

Hi! The issue with join is just a yaql bug that is already fixed. The problem with yaqluator is that it doesn't use the latest yaql library. Another problem is that it does't sets options correctly. As a result it is possible to bring the site down with a query that produces endless collection

Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug

If I understand the meaning of “join” function correctly then from user perspective this behavior in Mistral and Yaqluator is a bug because we’re joining two collections similar to how it works in SQL so the correct result should be: [[1, 3], [2, 3]] I.e. collection consisting of two

Re: [openstack-dev] [kuryr] kuryr-libnetwork split

Hello Everybody !!! As we discussed in the meeting yesterday, I have submitted restructured patches now in kuryr-lib and kuryr-libnetwork to address only dropping non-relevant code and adding kuryr-lib as dependency to kuryr-libnetwork. Please provide review comments so that i quickly reiterate

Re: [openstack-dev] [all][Python 3.4-3.5] Async python clients

On 4 July 2016 at 19:58, Julien Danjou wrote: > On Mon, Jul 04 2016, Denis Makogon wrote: > > > What would be the best place to submit spec? > > The cross project spec repo? > > https://git.openstack.org/cgit/openstack/openstack-specs/ > > -- > Julien Danjou > /* Free

Re: [openstack-dev] [Openstack-operators] [gnocchi] profiling and benchmarking 2.1.x

hi folks, i didn't get as far as i'd hope so i've decided to release what i have currently and create another deck for more 'future enhancements' benchmarking. the following deck aims to show how performance changes as you scale out Ceph and some configuration options that can help stabilise

[openstack-dev] [tacker] Weekly meeting agenda - July 5, 2016

https://wiki.openstack.org/wiki/Meetings/Tacker 1600 UTC Tuesday @ #openstack-meeting - Announcements - Audit Event Log - https://review.openstack.org/321370 - Network Services Descriptor (NSD) - https://review.openstack.org/304667 - Grooming Midcycle Meetup topics - -

[openstack-dev] [neutron][alembic] Upgrade of db with alembic migration script

Hello, I'm working on patch to add QoS ingress bandwidth limit to Neutron currently: https://review.openstack.org/303626 and I have small problem with db upgrade with alembic. Problem description: In qos_bandwidth_limit_rules table now there is foreign key "qos_policy_id" with unique constraint.

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

If you have any topic for our weekly meeting tomorrow, please add it here: https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160705 If no topic, we will postpone the meeting to next week. Thanks, On Tue, Jun 28, 2016 at 11:06 AM, Emilien Macchi wrote: >

Re: [openstack-dev] [kolla] Stability and reliability of gate jobs

I mentioned this on IRC to some extent but I'm going to post it here for posterity. I think we can all agree that Integration tests are pretty darn important and I'm convinced I don't need to remind you why. I'm going to re-iterate that I am very concerned about the state of the jobs but also

Re: [openstack-dev] [Fuel] - Nominate Maksim Malchuk to Fuel Library Core

Hi All, I'm very appreciate being a part of the Fuel project as core reviewers team! Thank you all for nomination and for +1s! On Mon, Jul 4, 2016 at 12:17 PM, Sergii Golovatiuk wrote: > Hi, > > Please welcome Maksim as he's just joined fuel-library Core Team! > > --

Re: [openstack-dev] [nova] gate testing with lvm imagebackend

On 05/10/2016 04:47 PM, Matt Riedemann wrote: On 5/10/2016 5:14 PM, Chris Friesen wrote: For what it's worth, we've got internal patches to enable cold migration and resize for LVM-backed instances. We've also got a proof of concept to enable thin-provisioned LVM to get rid of the huge

[openstack-dev] [Glare] No meeting today - 07/04/2016

Hi, We’re cancelling team meeting today because a bunch of team members are on holidays or won’t be able to attend. Best regards, Mikhail Fedosin __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

[openstack-dev] [Infra] Meeting Tuesday July 5th at 19:00 UTC

Hi everyone, The OpenStack Infrastructure (Infra) team is having our next weekly meeting on Tuesday July 5th, at 19:00 UTC in #openstack-meeting Meeting agenda available here: https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting Anyone is welcome to to add agenda

Re: [openstack-dev] [manila][stable] liberty periodic bitrot jobs have been failing more than a week

On 07/03/2016 09:19 AM, Matt Riedemann wrote: On 7/1/2016 8:18 PM, Ravi, Goutham wrote: Thanks Matt. https://review.openstack.org/#/c/334220 adds the upper constraints. -- Goutham On 7/1/16, 5:08 PM, "Matt Riedemann" wrote: The manila periodic stable/liberty

[openstack-dev] [Smaug]- IRC Meeting today (05/07) - 0900 UTC SM,

Hi All, We will hold our weekly IRC meeting today (Tuesday, 05/07) at 0900 UTC in #openstack-meeting Please review the proposed meeting agenda here: https://wiki.openstack.org/wiki/Meetings/smaug Please feel free to add to the agenda any subject you would like to discuss. Thanks, Saggi

Re: [openstack-dev] [murano] Fail to install murano in Pro environment / Ansible cookbook for murano

Hi Alioune! Can you please share which versions of murano and existing cloud do you have?  I would bet that you’re using stable/liberty murano, or earlier. The code you mentioned has been refactored in stable/mitaka [1] This was done, because oslo.messaging has merged a commit [2], that

Re: [openstack-dev] [kolla][ironic] My thoughts on Kolla + BiFrost integration

I'd be cautious about how much of customization we allow. But don't forget that Kolla itself and BiFrost will be effectively separate. Run bifrost, run every customization playbook you want on host, run kolla-host-bootstrap playbook for installation of docker and stuff and then run kolla. This

Re: [openstack-dev] [all][Python 3.4-3.5] Async python clients

Denis Makagon wrote: > I'm using event loop with uvloop policy, so i must stay non-blocked > within main thread and don't mess up with GIL by instantiating new thread. You won't be blocked or "messed up" with GIL as long as new thread is I/O bound. Background thread is a good solution in such

[openstack-dev] [murano] Fail to install murano in Pro environment / Ansible cookbook for murano

Hi all, I'm trying to install murano in existing openstack platform following [1]. So the installation process fails at step [2] with this error. Any suggestion for solving that ? Is there existing murano playbook for easy deployment with ansible ? You can find my murano.conf in [3] [1]

Re: [openstack-dev] [all][Python 3.4-3.5] Async python clients

2016-07-04 16:47 GMT+03:00 Roman Podoliaka : > That's exactly what https://github.com/koder-ua/os_api is for: it > polls status changes in a separate thread and then updates the > futures, so that you can wait on multiple futures at once. > > This is what i exactly want

[openstack-dev] [storlets] changes to .functests

Hi all, patch https://review.openstack.org/#/c/334878/ introduces a (bonus) change to the functests. The functests script need to get a flavour: jenkins | dev the dev flavour skips slow tests such as 1GB PUT. When invoked from tox it uses the jenkins flavour which executes everything. this is

[openstack-dev] [mistral] No meeting today - 07/04/2016

Hi, We’re cancelling team meeting today because a bunch of team members are on holidays or won’t be able to attend. Renat Akhmerov @Nokia __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

Re: [openstack-dev] [all][Python 3.4-3.5] Async python clients

That's exactly what https://github.com/koder-ua/os_api is for: it polls status changes in a separate thread and then updates the futures, so that you can wait on multiple futures at once. On Mon, Jul 4, 2016 at 2:19 PM, Denis Makogon wrote: > > > 2016-07-04 13:22 GMT+03:00

Re: [openstack-dev] [Openstack-operators] [nova] Fail build request if we can't inject files?

On 7/4/2016 3:40 AM, Daniel P. Berrange wrote: Won't the user provided files also get made available by the config drive / metadata service ? I think that's the primary reason for file injection not being a fatal problem. Oh that and the fact that we've wanted to kill it for at least 3 years

Re: [openstack-dev] [Openstack-operators] [nova] Fail build request if we can't inject files?

Hi all, > Won't the user provided files also get made available by the config drive / > metadata service ? I believe, they should. Not sure it's the same problem, so just FYI: we recently encountered an issue with VFAT formatted config drives when nova-compute is deployed on CentOS or RHEL:

Re: [openstack-dev] [Heat][Senlin] Deprecation roadmap for Heat's Autoscaling resources?

Hello, On 07/04/2016 02:52 PM, Thomas Herve wrote: On Mon, Jul 4, 2016 at 2:06 PM, Johannes Grassler wrote: [...] Right now OS::Heat::AutoScalingGroup and friends still exist, even in the master branch. Are they slated for removal at some stage or will they remain

Re: [openstack-dev] [Heat][Senlin] Deprecation roadmap for Heat's Autoscaling resources?

On Mon, Jul 4, 2016 at 2:06 PM, Johannes Grassler wrote: > Hello, > > I just noticed the note at the top of > : > > | The content on this page is obsolete. The autoscaling solution is > offloaded from Heat to Senlin since

Re: [openstack-dev] [tripleo] Nodes management in our shiny new TripleO API

On Mon, Jul 4, 2016 at 5:12 PM, Steven Hardy wrote: > Hi Dmitry, > > I wanted to revisit this thread, as I see some of these interfaces > are now posted for review, and I have a couple of questions around > the naming (specifically for the "provide" action): > > On Thu, May

Re: [openstack-dev] [charms] inclusion of charm-helpers (LGPL licensed)

Hi Billy On Thu, 30 Jun 2016 at 17:24 Billy Olsen wrote: > I suspect that the reactive charming model wouldn't have this issue > due to the ability to essentially statically link the libraries via > wheels/pip packages. If that's the case, it's likely possible to > follow

[openstack-dev] [puppet] retiring puppet-openstack-release-tools

Hi, Before managing releases with OpenStack release team, we had our own scripts, I suggest we retire the repo to avoid confusion and do some cleanup. I'll propose a patch that retire openstack/puppet-openstack-release-tools, feel free to give feedback on this proposal. Note: most of the tools

Re: [openstack-dev] [grenade] upgrades vs rootwrap

On Mon, Jul 04, 2016 at 01:59:09PM +0200, Thierry Carrez wrote: [...] > The issue here is that oslo.rootwrap uses config files to determine > what to allow, but those are not really configuration files as far > as the application using them is concerned. Those must match the > code being executed.

[openstack-dev] [Heat][Senlin] Deprecation roadmap for Heat's Autoscaling resources?

Hello, I just noticed the note at the top of : | The content on this page is obsolete. The autoscaling solution is offloaded from Heat to Senlin since Mitaka. Right now OS::Heat::AutoScalingGroup and friends still exist, even in the master

Re: [openstack-dev] [grenade] upgrades vs rootwrap

Angus Lees wrote: Ack. Ok .. so what's the additional difficulty around config files? It sounds like we can replace all the config files with something completely different during the update phase, if we wanted to do so. Indeed, it sounds like there isn't even a need to manage a deprecation

Re: [openstack-dev] [magnum][heat] Global stack-list for Magnum service user

Hello, Thanks for the exhaustive comment on the issue. Won't help much in the short term, but it's good to see there will eventually be a way to sort this out properly! On 07/04/2016 12:50 PM, Steven Hardy wrote: On Mon, Jul 04, 2016 at 11:43:47AM +0200, Johannes Grassler wrote: [Magnum's

Re: [openstack-dev] [tripleo] Nodes management in our shiny new TripleO API

Hi Dmitry, I wanted to revisit this thread, as I see some of these interfaces are now posted for review, and I have a couple of questions around the naming (specifically for the "provide" action): On Thu, May 19, 2016 at 03:31:36PM +0200, Dmitry Tantsur wrote: > The last step before the

[openstack-dev] [Openstack]-Help required for configuring GBP in Openstack Kilo

Hello Team, I have an Openstack Kilo three node setup. It has one controller, one compute and one neutron node. I am using OVS switch as soft switch between compute and neutron nodes. Now, I need GBP to be configured on this existing Openstack. All the documents that I could find have only

Re: [openstack-dev] [nova] Non-priority feature freeze and FFEs

On 01.07.2016 23:03, Matt Riedemann wrote: > We're now past non-priority feature freeze. I've started going through > some blueprints and -2ing them if they still have outstanding changes. I > haven't gone through the full list yet (we started with 100). > > I'm also building a list of

Re: [openstack-dev] [all][Python 3.4-3.5] Async python clients

2016-07-04 13:22 GMT+03:00 Roman Podoliaka : > Denis, > > > Major problem > > appears when you trying to provision resource that requires to have some > > time to reach ACTIVE/COMPLETED state (like, nova instance, stack, trove > > database, etc.) and you have to use

Re: [openstack-dev] [magnum][heat] Global stack-list for Magnum service user

On Mon, Jul 04, 2016 at 11:43:47AM +0200, Johannes Grassler wrote: > Hello, > > Magnum has a periodic task that checks the state of the Heat stacks it creates > for its bays. It does this across all users/tenants that have Magnum bays. > Currently it uses a global stack-list operation to query

[openstack-dev] [cinder][nova] Today's Cinder-Nova API changes meeting is cancelled

Hi, The today's meeting is cancelled due to the holiday in the U.S. The next meeting will be held next Monday (July 11th), 1700 UTC on #openstack-meeting-cp. Thanks and Best Regards, /Ildikó __ OpenStack Development

Re: [openstack-dev] Troubleshooting and ask.openstack.org

Adam Young wrote: [...] I know we getting nuked on the Wiki. What I would like to be able to generate is Frequently Asked Questions (FAQ) page, but as a living document. Small correction... As explained in my summary of wiki use cases[1], we are removing "reference" documentation from the

Re: [openstack-dev] [magnum][heat] Global stack-list for Magnum service user

Hi Johannes, this is still not too optimal, as AFAIK admin role is still global, so admin in tenant also means admin of whole OpenStack, thus it still can assign himself/whomever the 'service' role and get access to global stack list. Best solution would probably be to create a separate domain

Re: [openstack-dev] [all][Python 3.4-3.5] Async python clients

Denis, > Major problem > appears when you trying to provision resource that requires to have some > time to reach ACTIVE/COMPLETED state (like, nova instance, stack, trove > database, etc.) and you have to use polling for status changes and in > general polling requires to send HTTP requests

Re: [openstack-dev] [all][Python 3.4-3.5] Async python clients

On Mon, Jul 4, 2016 at 11:59 AM, Julien Danjou wrote: > On Mon, Jul 04 2016, Antoni Segura Puimedon wrote: > > > for the neutron clients now we use a thread executor from the asyncio > loop > > any time > > we do neutron client request. > > It's a good trade-off, but it won't

Re: [openstack-dev] [all][Python 3.4-3.5] Async python clients

2016-07-04 12:40 GMT+03:00 Antoni Segura Puimedon < toni+openstac...@midokura.com>: > > > On Mon, Jul 4, 2016 at 11:16 AM, Julien Danjou wrote: > >> On Sun, Jun 26 2016, Denis Makogon wrote: >> >> > I know that some work in progress to bring Python 3.4 compatibility to >> >

Re: [openstack-dev] [all][Python 3.4-3.5] Async python clients

On Mon, Jul 04 2016, Antoni Segura Puimedon wrote: > for the neutron clients now we use a thread executor from the asyncio loop > any time > we do neutron client request. It's a good trade-off, but it won't be as good as going full on async I/O. :) -- Julien Danjou # Free Software hacker #

Re: [openstack-dev] [all][Python 3.4-3.5] Async python clients

On Mon, Jul 04 2016, Denis Makogon wrote: > What would be the best place to submit spec? The cross project spec repo? https://git.openstack.org/cgit/openstack/openstack-specs/ -- Julien Danjou /* Free Software hacker https://julien.danjou.info */ signature.asc Description: PGP

[openstack-dev] [magnum][heat] Global stack-list for Magnum service user

Hello, Magnum has a periodic task that checks the state of the Heat stacks it creates for its bays. It does this across all users/tenants that have Magnum bays. Currently it uses a global stack-list operation to query these Heat stacks:

Re: [openstack-dev] [all][Python 3.4-3.5] Async python clients

On Mon, Jul 4, 2016 at 11:16 AM, Julien Danjou wrote: > On Sun, Jun 26 2016, Denis Makogon wrote: > > > I know that some work in progress to bring Python 3.4 compatibility to > > backend services and it is kinda hard question to answer, but i'd like to > > know if there are

Re: [openstack-dev] [all][Python 3.4-3.5] Async python clients

2016-07-04 12:16 GMT+03:00 Julien Danjou : > On Sun, Jun 26 2016, Denis Makogon wrote: > > > I know that some work in progress to bring Python 3.4 compatibility to > > backend services and it is kinda hard question to answer, but i'd like to > > know if there are any plans to

Re: [openstack-dev] [Fuel] - Nominate Maksim Malchuk to Fuel Library Core

Hi, Please welcome Maksim as he's just joined fuel-library Core Team! -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Tue, Jun 28, 2016 at 1:06 PM, Adam Heczko wrote: > Although I'm not Fuel core, +1 from me to Maksim. Maksim is not only > excellent

Re: [openstack-dev] [all][Python 3.4-3.5] Async python clients

On Sun, Jun 26 2016, Denis Makogon wrote: > I know that some work in progress to bring Python 3.4 compatibility to > backend services and it is kinda hard question to answer, but i'd like to > know if there are any plans to support asynchronous HTTP API client in the > nearest future using

Re: [openstack-dev] [Openstack-operators] [nova] Fail build request if we can't inject files?

On Sun, Jul 03, 2016 at 10:08:04AM -0500, Matt Riedemann wrote: > I want to use the gate-tempest-dsvm-neutron-full-ssh in nova since it runs > ssh validation + neutron + config drive + metadata service, which will test > the virtual device tagging 2.32 microversion API (added last week). > > The

Re: [openstack-dev] [daisycloud-core] [kolla] Kolla Mitaka requirementssupported by CentOS

Hi, > 发件人: Haïkel > As one of RDO maintainer, I strongly invite kolla, not to use EPEL. > It's proven very hard to prevent EPEL pushing broken updates, or push > updates to fit OpenStack requirements. > Actually, all the dependency above but ansible, docker and

[openstack-dev] 答复: [probably forge email可能是仿冒邮件]Re: [daisycloud-core] Kolla Mitaka requirementssupported by CentOS

Hi Haïkel > Actually, all the dependency above but ansible, docker and git python > modules are in CentOS Cloud SIG repositories. > If you are interested to work w/ CentOS Cloud SIG, we can add missing > dependencies in our repositories. So currently Jinja2 version >= 2.8 is already in the

Re: [openstack-dev] [daisycloud-core] [kolla] Kolla Mitaka requirementssupported by CentOS

> As one of RDO maintainer, I strongly invite kolla, not to use EPEL. > It's proven very hard to prevent EPEL pushing broken updates, or push > updates to fit OpenStack requirements. > Actually, all the dependency above but ansible, docker and git python > modules are in CentOS Cloud SIG

Re: [openstack-dev] [kolla][ironic] My thoughts on Kolla + BiFrost integration

Hi Steve I'm just suggesting the bi-frost stuff allow sufficient 'hooks' for operators to insert site specific setup. Not that Kolla/Bi-Frost try to handle 'everything'. For instance LDAP... Horizon integration with LDAP would certainly be within Kolla's perview. However, operators also

Re: [openstack-dev] [neutron][upgrades] Bi-weekly upgrades work status. 6/20/2016

Very glad to see *Bi-weekly Upgrades Work Status*, besides, we (UnitedStack) are also writing a Chinese version of weekly neutron status: http://bit.ly/29nTorX We wrote from 4.3 and now have wrote 12 pieces. :-D Wei Wang 2016-06-20 21:58 GMT+08:00 Ihar Hrachyshka : > Hi

Re: [openstack-dev] [kuryr] kuryr-libnetwork split

On Fri, Jul 1, 2016 at 7:58 PM, Doug Hellmann wrote: > Excerpts from Jeremy Stanley's message of 2016-07-01 15:05:30 +: > > On 2016-07-01 08:26:13 -0500 (-0500), Monty Taylor wrote: > > [...] > > > Check with Doug Hellman about namespaces. We used to use them in some >

Re: [openstack-dev] Openstack Mitaka Neutron LBaaS Question

Hi! You also have to configure Octavia on your controller. The most straightforward way would be to follow the steps that are done in Octavia DevStack plugin . There is also an overview presentation

Re: [openstack-dev] New Python35 Jobs coming

Le 04/07/2016 à 07:59, Denis Makogon a écrit : Then let it run for a day or two in our CI, discuss with neutron team, and send a patch for project-config to change the setup, Can confirm that nova, glance, cinder, heat clients are py35 compatible. tox.ini of Nova, Swift and Trove need

[openstack-dev] [tricircle]

Hello everyone, I am trying to run DevStack on Ubuntu 14.04 in a single VirtualBox. An error turns up before it successfully starts. Yesterday I clarified this question not clearly enough，so I make a supplication for it. My steps are: 1), Git clone DevStack, 2), Copy devstack/local.conf.sample

Re: [openstack-dev] [nova][infra][ci] bulk repeating a test job on a single review in parallel ?

On Fri, Jul 01, 2016 at 02:35:34PM +, Jeremy Stanley wrote: > On 2016-07-01 15:39:10 +0200 (+0200), Kashyap Chamarthy wrote: > > [Snip description of some nice debugging.] > > > > > I'd really love it if there was > > > > > > 1. the ability to request checking of just specific jobs eg > > >

Re: [openstack-dev] [mistral][osc-lib][openstackclient] is it too early for orc-lib?

Ok, based on what has been said here I suggest we keep this code for now. The changes were really minimal. If it creates some problems for us we can always easily revert. Renat Akhmerov @Nokia > On 01 Jul 2016, at 04:57, Steve Martinelli wrote: > > The crux of this,

Re: [openstack-dev] [Nova] Questions about instance actions' update and finish

I'm willing to work on this, should this be a Blueprint for O? On Sun, Jul 3, 2016 at 9:05 PM, Matt Riedemann wrote: > On 7/3/2016 6:21 AM, Alex Xu wrote: > >> >> >> 2016-07-02 2:32 GMT+08:00 Sean Dague > >: >> >> >> On

Re: [openstack-dev] New Python35 Jobs coming

2016-07-04 8:18 GMT+03:00 Andreas Jaeger : > On 07/03/2016 09:26 PM, Henry Gessau wrote: > > Clark Boylan wrote: > >> The infra team is working on taking advantage of the new Ubuntu Xenial > >> release including running unittests on python35. The current plan