Re: [openstack-dev] [nova] placement/resource providers update 27

Thanks for resuming these, Chris, much appreciated. Comments inline. On 07/07/2017 07:44 AM, Chris Dent wrote: After 40 days in the desert I've returned with placement update 27. Unfortunately, as far as I can tell, no one did any updates while I was gone so I don't have anything to crib from

Re: [openstack-dev] [zun] Some general ZUN use case / drivers type questions

Hi Greg, Zun currently leverages the “--memory", “--cpu-period”, and “--cpu-quota” options to limit the CPU and memory. Zun does do resource tracking and scheduling right now, but this is temporary. The long-term plan is to switch to the Placement API [1] after it is spited out from Nova. [1]

Re: [openstack-dev] [neutron] writable mtu

On Wed, Jul 5, 2017 at 6:11 PM, Ian Wells wrote: > On 5 July 2017 at 14:14, Ihar Hrachyshka wrote: >> >> Heya, >> >> we have https://bugs.launchpad.net/neutron/+bug/1671634 approved for >> Pike that allows setting MTU for network on creation. > > >

Re: [openstack-dev] [neutron] writable mtu

On Wed, Jul 5, 2017 at 6:43 PM, Ian Wells wrote: > I think I misinterpreted: you'd enable all options and then deal with the > consequences in the backend code which has to implement one the of the > previously listed behaviours? That seems sane to me provided the

Re: [openstack-dev] [all][stable][ptls] Tagging mitaka as EOL

> On 2017-07-05 12:13, Joshua Hesketh wrote: > > Hi all, > > > > Very sorry for the delay on processing this request. I have now EOL'd > > stable/mitaka branches for projects listed in [1]. > > > > If there are any mistakes it should be possible to restore the branch > > at the correct

Re: [openstack-dev] [docs] [pbr] [ptl] [oslo] Removing pbr's custom 'build_sphinx' setuptools command

On 2017-07-07 11:20:30 -0400 (-0400), Doug Hellmann wrote: [...] > We also discussed changing the CI interface to build docs to use > the "tox -e docs" command like contributors generally run locally. [...] Better still, something like `tox -e venv -- sphinx-build` would be more in keeping with

Re: [openstack-dev] [tripleo] Queens PTG

On 07/04/2017 08:00 PM, Emilien Macchi wrote: > On Wed, Jun 28, 2017 at 9:37 PM, Giulio Fidente wrote: >> On 06/28/2017 04:35 PM, Emilien Macchi wrote: >>> Hey folks, >>> >>> Let's start to prepare the next PTG in Denver. >>> >>> Here's the schedule draft: >>>

[openstack-dev] [nova][cinder] Status update on 3.27 attachments integration

I wanted to provide an update on where we're at with the series of nova changes to integrate with the new style 3.27 volume attachments API. This is building a foundation between both projects for supporting multi-attach volumes in Nova in Queens. The series has 3 major changes:

Re: [openstack-dev] [neutron] [l2gw] DSVM gates for networking-l2gw

It may be a non-negligible effort to make ovs containerized in the namespace in the first place (that's one of the things we still miss in fullstack in neutron repo). I know that Terry Wilson had some code for that, but I can't find it right now. Ihar On Thu, Jul 6, 2017 at 1:57 AM, Ricardo

[openstack-dev] [tripleo] proposing Alex Schultz tripleo-core in all projects

Alex has demonstrated high technical and community skills in TripleO - where he's already core on THT, instack-undercloud, and puppet-tripleo - but also very involved in other repos. I propose that we extend his core status to all TripleO projects and of course trust him (like we trust all core

[openstack-dev] [TripleO] Forming our plans around Ansible

I proposed a session for the PTG (https://etherpad.openstack.org/p/tripleo-ptg-queens) about forming a common plan and vision around Ansible in TripleO. I think it's important however that we kick this discussion off more broadly before the PTG, so that we can hopefully have some agreement for

Re: [openstack-dev] [tripleo] proposing Alex Schultz tripleo-core in all projects

+1 He's a great reviewer On 7 Jul 2017 8:40 pm, "Emilien Macchi" wrote: > Alex has demonstrated high technical and community skills in TripleO - > where he's already core on THT, instack-undercloud, and puppet-tripleo > - but also very involved in other repos. > I propose

Re: [openstack-dev] [TripleO] Forming our plans around Ansible

On Fri, Jul 7, 2017 at 5:00 PM, Luke Hinds wrote: > I can't offer much in-depth feedback on the pros and cons of each scenario. > My main point would be to try and simplify as much as we can, rather then > adding yet more tooling to the stack. At the moment ooo is spread across

Re: [openstack-dev] [nova] placement/resource providers update 27

On 7/7/2017 6:44 AM, Chris Dent wrote: After 40 days in the desert I've returned with placement update 27. Unfortunately, as far as I can tell, no one did any updates while I was gone so I don't have anything to crib from to have the full story on what's going on. I suspect I will miss some

Re: [openstack-dev] [TripleO] Forming our plans around Ansible

On Fri, Jul 7, 2017 at 6:50 PM, James Slagle wrote: > I proposed a session for the PTG > (https://etherpad.openstack.org/p/tripleo-ptg-queens) about forming a > common plan and vision around Ansible in TripleO. > > I think it's important however that we kick this

Re: [openstack-dev] [TripleO] Forming our plans around Ansible

On Fri, Jul 7, 2017 at 1:50 PM, James Slagle wrote: > (0) tripleo-quickstart which follows the common and well accepted > approach to bundling a set of Ansible playbooks/roles. I don't want to de-rail the thread but I really want to bring some attention to a pattern that

Re: [openstack-dev] [neutron] writable mtu

On 7 July 2017 at 12:14, Ihar Hrachyshka wrote: > > That said: what will you do with existing VMs that have been told the > MTU of > > their network already? > > Same as we do right now when modifying configuration options defining > underlying MTU: change it on API layer,

Re: [openstack-dev] [TripleO] Forming our plans around Ansible

On Fri, Jul 7, 2017 at 5:31 PM, David Moreau Simard wrote: > On Fri, Jul 7, 2017 at 1:50 PM, James Slagle wrote: >> (0) tripleo-quickstart which follows the common and well accepted >> approach to bundling a set of Ansible playbooks/roles. > > I don't

Re: [openstack-dev] [docs] [pbr] [ptl] [oslo] Removing pbr's custom 'build_sphinx' setuptools command

On 07/07/2017 12:12 PM, Jeremy Stanley wrote: On 2017-07-07 11:20:30 -0400 (-0400), Doug Hellmann wrote: [...] We also discussed changing the CI interface to build docs to use the "tox -e docs" command like contributors generally run locally. [...] Better still, something like `tox -e venv --

Re: [openstack-dev] [nova] placement/resource providers update 27

2017-07-07 19:44 GMT+08:00 Chris Dent : > > After 40 days in the desert I've returned with placement update 27. > > Unfortunately, as far as I can tell, no one did any updates while I > was gone so I don't have anything to crib from to have the full > story on what's going

Re: [openstack-dev] [tripleo] proposing Alex Schultz tripleo-core in all projects

+1 to Alex On Fri, Jul 7, 2017 at 4:20 PM, Juan Antonio Osorio wrote: > +1 > > He's a great reviewer > > On 7 Jul 2017 8:40 pm, "Emilien Macchi" wrote: >> >> Alex has demonstrated high technical and community skills in TripleO - >> where he's already

Re: [openstack-dev] [TripleO] Forming our plans around Ansible

On Fri, Jul 7, 2017 at 10:17 PM, James Slagle wrote: > On Fri, Jul 7, 2017 at 5:00 PM, Luke Hinds wrote: > > I can't offer much in-depth feedback on the pros and cons of each > scenario. > > My main point would be to try and simplify as much as we can,

Re: [openstack-dev] [nova][placement] Add API Sample tests for Placement APIs

Thanks for your opinion and I totally agree with your suggestion to generate docs based on the verbose functionality for accuracy. but for one thing that I have observed is: In the current gabbi tests If nova is returning extra parameters for a specific micro-version, then the tests won't fail

Re: [openstack-dev] [Release-job-failures] Release of openstack/monasca-log-api failed

jenk...@openstack.org wrote: > - monasca-log-api-tarball > http://logs.openstack.org/ff/ff2f6a9660b478a2de6fd3ffa33c7dc9d0cd6892/release/monasca-log-api-tarball/cb3c8be/ > : FAILURE in 3m 07s The error is generated while building the tarball: can't copy 'etc/monasca/log-api.conf': doesn't exist

Re: [openstack-dev] [Vitrage] Collectd notification isn't shown on the Vitrage Graph

Now with the file attached From: "Afek, Ifat (Nokia - IL/Kfar Sava)" Date: Friday, 7 July 2017 at 12:41 To: "OpenStack Development Mailing List (not for usage questions)" Cc: "Tahhan, Maryam" Subject: Re:

Re: [openstack-dev] [tripleo] weekly meetings on #tripleo

On Wed, Jul 5, 2017 at 7:56 PM, Emilien Macchi wrote: > After reading http://lists.openstack.org/pipermail/openstack-dev/2017- > June/118899.html > - we might want to collect TripleO's community feedback on doing > weekly meetings on #tripleo instead of

[openstack-dev] [tc] Status update, July 7th

Hi! This is the weekly update on Technical Committee initiatives. You can find the full list of all open topics at: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee == Recently-approved changes == * Add "Glance Contributors" to top-5 wanted list [1] * Doc link updates: octavia *

Re: [openstack-dev] [Vitrage] Collectd notification isn't shown on the Vitrage Graph

Hi Volodymyr, Can you please enable debug information in vitrage.conf, restart vitrage-graph, and send me the vitrage-graph.log file (in the time where the alarm is raised)? I’ll try to understand why the alarm is not connected to the port. The definitions in collectd_conf.yaml seem correct.

Re: [openstack-dev] [tripleo] weekly meetings on #tripleo

+1 We can try this and see how it goes. On Thu, Jul 6, 2017 at 10:53 PM, Jason E. Rist wrote: > On 07/05/2017 11:40 AM, Ben Nemec wrote: >> I don't have a particularly strong opinion one way or another (probably >> because I tend to skip most of the meetings lately anyway...),

Re: [openstack-dev] [nova][placement] Add API Sample tests for Placement APIs

On Fri, 7 Jul 2017, Shewale, Bhagyashri wrote: Imagine one api with version x returning 5 attributes in a response and micro-version x.1 returning 6 attributes in a response and for some reasons there is a regression and the micro-version x starts returning 6 attributes instead of 5, then I

Re: [openstack-dev] [tripleo] weekly meetings on #tripleo

We have been holding RDO meetings in #rdo for as long as I can remember and I don't see anyone complaining. If someone asks a "support" type question during the meeting, we invite them to participate in the meeting and mention that we can help after the meeting is over. David Moreau Simard

Re: [openstack-dev] [tc] Status update, July 7th

Excerpts from Thierry Carrez's message of 2017-07-07 10:19:48 +0200: > > == Need for a TC meeting next Tuesday == > > I propose we have a meeting next week to discuss the next steps in > establishing the vision. I feel like we should approve it soon, > otherwise we'll get too close to the vision

[openstack-dev] [nova] placement/resource providers update 27

After 40 days in the desert I've returned with placement update 27. Unfortunately, as far as I can tell, no one did any updates while I was gone so I don't have anything to crib from to have the full story on what's going on. I suspect I will miss some relevant reviews when making this list. If

Re: [openstack-dev] [tc] Status update, July 7th

Let's do this! On Fri, Jul 7, 2017 at 8:46 AM, Jeremy Stanley wrote: > On 2017-07-07 10:19:48 +0200 (+0200), Thierry Carrez wrote: > [...] >> == Need for a TC meeting next Tuesday == >> >> I propose we have a meeting next week to discuss the next steps in >> establishing the

Re: [openstack-dev] [zun] Some general ZUN use case / drivers type questions

Hi Greg, Sorry for the confusion. I used the term “container-in-baremetal” to refer to a deployment pattern that containers are running on physical compute nodes (not an instance provided by Nova/Ironic). I think your second interpretation is right if “OpenStack Hosts” means a compute node. I

Re: [openstack-dev] [zun] Some general ZUN use case / drivers type questions

Hongbin, Thanks for the responses. A couple of follow up, clarifying questions ... · You mentioned that currently Zun supports the container-in-baremetal scenario ois this done by leveraging Ironic baremetal service ? § e.g. does Zun launch an Ironic baremetal instance (running

Re: [openstack-dev] [tc] Status update, July 7th

On 2017-07-07 10:19:48 +0200 (+0200), Thierry Carrez wrote: [...] > == Need for a TC meeting next Tuesday == > > I propose we have a meeting next week to discuss the next steps in > establishing the vision. I feel like we should approve it soon, > otherwise we'll get too close to the vision date

Re: [openstack-dev] [tripleo] I18n-themed Deep Dive - July 6th

Many thanks to those who could attend! The recording is available on BlueJeans [1] and YouTube [2] (thanks Carlos!). I also wrote up a transcript [3] if skimming is more your thing. Regards, Julie [1] https://bluejeans.com/s/XmuHa [2] https://www.youtube.com/watch?v=dmAw7b2yUEo [3]

Re: [openstack-dev] [nova][placement] Add API Sample tests for Placement APIs

On Fri, 7 Jul 2017, Chris Dent wrote: Thanks for sticking with this conversation and making your goals clear. Both of the pull requests were merged and there's now a new version of gabbi, 1.35.0, at: https://pypi.python.org/pypi/gabbi https://gabbi.readthedocs.io/en/latest/release.html#id1

[openstack-dev] [docs] [pbr] [ptl] [oslo] Removing pbr's custom 'build_sphinx' setuptools command

tl;dr: pbr's 'build_spinx' derivative is broken again, and we want to just remove the feature at this point. However, this is going to necessitate some mechanical changes for most projects with docs and this mail serves as a heads up and request for input before we proceed. -- Since pretty much

Re: [openstack-dev] [zun] Some general ZUN use case / drivers type questions

Thanks Hongbin. I’ve got zun setup in devstack now, so will play with it a bit to better understand. Although a couple more questions (sorry) · in the current zun implementation of containers directly on compute nodes, does zun leverage any of the docker capabilities to restrict the

Re: [openstack-dev] [tc] Status update, July 7th

On 07/07/2017 07:46 AM, Jeremy Stanley wrote: On 2017-07-07 10:19:48 +0200 (+0200), Thierry Carrez wrote: [...] == Need for a TC meeting next Tuesday == I propose we have a meeting next week to discuss the next steps in establishing the vision. I feel like we should approve it soon, otherwise

Re: [openstack-dev] [docs] [pbr] [ptl] [oslo] Removing pbr's custom 'build_sphinx' setuptools command

Excerpts from sfinucan's message of 2017-07-07 15:58:10 +0100: > tl;dr: pbr's 'build_spinx' derivative is broken again, and we want to just > remove the feature at this point. However, this is going to necessitate some > mechanical changes for most projects with docs and this mail serves as a

[openstack-dev] [acceleration]Cyborg Web API framework proposal

Hi all, As Pecan is a very lightweight web-framework which uses object-dispatch instead of declared routing and chains controller classes together to implement the API. It is becoming a de facto standard for Openstack projects(more and more projects have switched to it, such as neutron,

Re: [openstack-dev] [Vitrage] Collectd notification isn't shown on the Vitrage Graph

Hi Ifat, Sorry, I forgot to attach the topology dump. Attaching it now. Also, I’ve checked the topology, and looks like there is no relationship between neutron port and the alarm for some reason. Thanks and Regards, Volodymyr From: Afek, Ifat (Nokia - IL/Kfar Sava)

Re: [openstack-dev] [watcher] some database migration file skipped

Hi Yumeng Bao, By simply executing watcher-db-manage after creating database, All migration scripts are executed. Now I can try cron type audit interval. Thanks, Hidekazu Nakamura > -Original Message- > From: yumeng bao [mailto:yumeng_...@yahoo.com] > Sent: Friday, July 07, 2017 11:39

[openstack-dev] [Vitrage] Integration with doctor

Hi, For the integration Vitrage with doctor, I have some issues which need to be confirmed~ :) 1. Notification strategies: conservative (nova->Aodh) @Ifat In the host_down_scenarios.yaml[1], we only set the host state as error. But in doctor current use case, we need to call nova