Re: [openstack-dev] [magnum] Difference between certs stored in keystone and certs stored in barbican

> -Original Message- > From: Adrian Otto [mailto:adrian.o...@rackspace.com] > Sent: 01 September 2015 07:03 > To: OpenStack Development Mailing List (not for usage questions) > > Subject: Re: [openstack-dev] [magnum] Difference between certs stored in > keystone and certs stored in barbica

[openstack-dev] [magnum] Difference between certs stored in keystone and certs stored in barbican

Thanks Adrian for description. If i could understand correctly,magnum clients will be use barbican for authentication as coes dont support keystone for operations like pod-creation etc and for rest of the project clients like nova/glance pythonclients, keystone will continue to serve. Please cor

Re: [openstack-dev] [Neutron] Netaddr 0.7.16 and gate breakage

On Tue, Sep 1, 2015 at 3:15 AM, Carl Baldwin wrote: > On Mon, Aug 31, 2015 at 11:02 AM, Armando M. wrote: >> On 31 August 2015 at 09:53, Jeremy Stanley wrote: >>> On 2015-08-31 10:33:07 -0600 (-0600), Carl Baldwin wrote: >>> > I was under the impression that we had a plan to stop allowing these

Re: [openstack-dev] Adding 'server_type' field to Baymodel

HI Vikas, The server_type (old name was platform, we corrected it to be more proper, 'server_type') was introduced for wide support, like baremetal cases, etc. For other parts it is hardcode 'vm' now, as 'vm' was and still are supported.(it is widely used for VM cases in dev/test) For baremetal

Re: [openstack-dev] [magnum] Difference between certs stored in keystone and certs stored in barbican

Simply put, Keystone is designed to generate tokens that are to be used for authentication and RBAC. Systems like Kunernetes do not support Keystone auth, but do support TLS. Using TLS provides a solution that is compatible with using these systems outside of an OpenStack cloud. Barbican is de

Re: [openstack-dev] [Blazar] Anyone interested?

All, I'd like to propose use of #openstack-blazar for further communication and coordination. Nikolay Starodubtsev Software Engineer Mirantis Inc. Skype: dark_harlequine1 2015-08-31 19:44 GMT+03:00 Fuente, Pablo A : > Yes, Blazar is a really interesting project. I worked on it some time ag

Re: [openstack-dev] Weekly Meeting on Sep 1

Hi Ian, murano IRC weekly meeting. today at 17 UTC. Nikolay Starodubtsev Software Engineer Mirantis Inc. Skype: dark_harlequine1 2015-08-31 23:11 GMT+03:00 Ian Cordasco : > > > On 8/31/15, 13:59, "Serg Melikyan" wrote: > > >Hi folks, > > > > > >I want to let you know that I would not be a

[openstack-dev] [neutron] subnetallocation is in core resource, while there is a extension for it?

Hi, neutron guys,look at https://github.com/openstack/neutron/blob/master/neutron/extensions/subnetallocation.py,which defines an extension Subnetallocation but defines no extension resource. Actually, it is implementedin core resource.So I think we should remove this extension. I filed a bug

[openstack-dev] [magnum] Difference between certs stored in keystone and certs stored in barbican

Hi, Can anybody please point me out some etherpad discussion page/spec that can help me understand why we are going to introduce barbican for magnum when we already had keystone for security management? -Vikas Choudhary

[openstack-dev] Adding 'server_type' field to Baymodel

Hi Team, I have a doubt.What all values 'server type' field that is being used in below function call can have? *get_template_definition(cls, server_type, os, coe*) Everywhere in code currently its value is 'vm' only. for example in classes representing template definitions(mesos, k8s and swarm)

Re: [openstack-dev] [Neutron] DHCP configuration

+1 common.config should be global and general while agent.config should be local and related to the special back-end. Maybe, we can add different prefix to the same option. Germy On Mon, Aug 31, 2015 at 11:13 PM, Kevin Benton wrote: > neutron.common.config should have general DHCP options that

[openstack-dev] Intel PCI CI down today due to testing scripts bug

Hello OpenStackers! The Intel PCI CI, due to test scripts bug( recently added) is failing to report results to OpenStack Jenkins third-party tests. We had identify this bug and the scripts had rolled back to verified version. Now we are discussing this with infra team to bring it back ASAP.

Re: [openstack-dev] [puppet] CI: make heat, Ironic, glance beaker non voting on trusty

I did https://review.openstack.org/219078 to disable the voting on these jobs. Matt, usually packages are in a better shape after official releases... Let's hope they will be :-) On 08/31/2015 05:54 PM, Matt Fischer wrote: > +1, I guess we need to watch and see if they pass eventually but that's

[openstack-dev] [nova] Nova API sub-team meeting

Hi, We have weekly Nova API meeting this week. The meeting is being held tomorrow Tuesday UTC1200. In other timezones the meeting is at: EST 08:00 (Tue) Japan 21:00 (Tue) China 20:00 (Tue) United Kingdom 13:00 (Tue) The proposed agenda and meeting details are here: https://wiki.openstack.org/

[openstack-dev] [ironic] weekly subteam status report

Hi, Following is the subteam report for Ironic. As usual, this is pulled directly from the Ironic whiteboard[0] and formatted. Bugs (dtantsur) As of Mon, Aug 31 (diff with Aug 24) - Open: 144 (+3). 9 new (+4), 50 in progress, 0 critical, 13 high and 10 (+1) incomplete - Nova bugs wit

Re: [openstack-dev] [murano] Proposing Nikolai Starodubtsev for core

+1 On Mon, Aug 31, 2015 at 3:45 PM, Kirill Zaitsev wrote: > I’m pleased to nominate Nikolai for Murano core. > > He’s been actively participating in development of murano during liberty > and is among top5 contributors during last 90 days. He’s also leading the > CloudFoundry integration initiat

[openstack-dev] [murano] Proposing Nikolai Starodubtsev for core

I’m pleased to nominate Nikolai for Murano core. He’s been actively participating in development of murano during liberty and is among top5 contributors during last 90 days. He’s also leading the CloudFoundry integration initiative. Here are some useful links: Overall contribution: http://stac

Re: [openstack-dev] [tripleo] CLI and RHEL registration of overcloud nodes

On 08/26/2015 11:00 AM, Steven Hardy wrote: > On Wed, Aug 26, 2015 at 05:28:47PM +0200, Jan Provazník wrote: >> Hi, >> although rdomanager-oscplugin is not yet under TripleO it should be soon, so >> sending this to TripleO audience. >> >> Satellite registration from user's point of view is now done

Re: [openstack-dev] sqlalchemy-migrate 0.9.8 released

On 8/31/2015 4:30 PM, Jeremy Stanley wrote: On 2015-08-31 16:23:14 -0500 (-0500), Matt Riedemann wrote: I've released 0.10.0: https://pypi.python.org/pypi/sqlalchemy-migrate/0.10.0 With an intermediate 0.9.9 you could have avoided leaving things broken while requirements gets updated. Consi

[openstack-dev] Cross-Project meeting, Tue Sept 1st, 21:00 UTC

Dear PTLs, cross-project liaisons and anyone else interested, We'll have a cross-project meeting tomorrow at 21:00 UTC, with the following agenda: * Review past action items: - Meeting Chair still needed for October 13 - ttx to create a summit session about crossproject discussion & meetings * Te

Re: [openstack-dev] [puppet] CI: make heat, Ironic, glance beaker non voting on trusty

+1, I guess we need to watch and see if they pass eventually but that's no guarantee that they won't break again in L or M etc. On Mon, Aug 31, 2015 at 3:48 PM, Emilien Macchi wrote: > So it he has been more than one month Ubuntu doesn't provide fixes for > Heat, Ironic, and Glance. > It's block

[openstack-dev] [puppet] CI: make heat, Ironic, glance beaker non voting on trusty

So it he has been more than one month Ubuntu doesn't provide fixes for Heat, Ironic, and Glance. It's blocking our CI to merge patches so I propose we make beaker jobs non voting on trusty for the three components only. It would remain voting on centos7 so I think it's fine. Once they provide stab

Re: [openstack-dev] sqlalchemy-migrate 0.9.8 released

On 2015-08-31 16:23:14 -0500 (-0500), Matt Riedemann wrote: > I've released 0.10.0: > > https://pypi.python.org/pypi/sqlalchemy-migrate/0.10.0 With an intermediate 0.9.9 you could have avoided leaving things broken while requirements gets updated. Consider that a "revert" of tagging. > I have a

Re: [openstack-dev] sqlalchemy-migrate 0.9.8 released

On 2015-08-31 21:23:01 + (+), Jeremy Stanley wrote: > Slightly simplified since it looks like sqlalchemy-migrate only has > a master branch at the moment... > > 1. tag 0.9.7 as 0.9.9 > > 2. tag 0.9.8 as 0.10.0 > > 3. introduce a stable/kilo version cap of <0.10.0 in requirements Er, act

Re: [openstack-dev] sqlalchemy-migrate 0.9.8 released

On 8/31/2015 4:18 PM, Jeremy Stanley wrote: On 2015-08-31 15:59:27 -0500 (-0500), Matt Riedemann wrote: [...] I'll have to cap migrate <0.9.8 in stable/kilo g-r...damn. Given that PBR only handles 3-component version numbers, what will you tag the next sqlalchemy-migrate security backport to

Re: [openstack-dev] sqlalchemy-migrate 0.9.8 released

On 2015-08-31 21:18:33 + (+), Jeremy Stanley wrote: > On 2015-08-31 15:59:27 -0500 (-0500), Matt Riedemann wrote: > [...] > > I'll have to cap migrate <0.9.8 in stable/kilo g-r...damn. > > Given that PBR only handles 3-component version numbers, what will > you tag the next sqlalchemy-migr

Re: [openstack-dev] sqlalchemy-migrate 0.9.8 released

On 2015-08-31 15:59:27 -0500 (-0500), Matt Riedemann wrote: [...] > I'll have to cap migrate <0.9.8 in stable/kilo g-r...damn. Given that PBR only handles 3-component version numbers, what will you tag the next sqlalchemy-migrate security backport to kilo with? Could we tag 0.10.0 now, backport a

Re: [openstack-dev] [neutron][gate] please stop approving patches until netaddr issue is solved

I was just looking at this, it appears that keystonemiddleware caps pbr to <1.0 so pulls down 0.11. http://logs.openstack.org/87/218987/1/check/gate-tempest-dsvm-large-ops/a32152f/logs/devstacklog.txt.gz#_2015-08-31_20_28_11_159 different job but same result. Clark On Mon, Aug 31, 2015, at 01:55

Re: [openstack-dev] sqlalchemy-migrate 0.9.8 released

On 8/31/2015 1:57 PM, Matt Riedemann wrote: https://pypi.python.org/pypi/sqlalchemy-migrate/0.9.8 I wanted to get a release out before dependency freeze for liberty. This is just a bug fix release, mostly to get the py34 job voting on the repo. Change log: mriedem@ubuntu:~/git/sqlalchemy-mi

Re: [openstack-dev] [neutron][gate] please stop approving patches until netaddr issue is solved

On 31 August 2015 at 11:41, Armando M. wrote: > > On 31 August 2015 at 10:44, Edgar Magana wrote: > >> Yeah!! >> > > Well don't get so excited, the check queue is hovering over the 200 mark, > so. > > well, that didn't last long: We're failing now raise VersionConflict(dist, req).with_con

[openstack-dev] [all] some in-repo documentation improvements

I recently added some features to stevedore and oslo.config to integrate them with Sphinx. In stevedore this lets us document the members of a particular plugin set that are provided by a given repository (or its dependencies). In oslo.config the integration lets us document the discovered configur

[openstack-dev] [Tacker][NFV] Heads up: switch over to master

Tacker dev & user teams: This shouldn't be a news to folks regularly attending tacker weekly meetings. For others, until now Tacker code base was using stable/kilo dependencies. Now we will be switching over to use master based dependencies using [1] and [2]. We are now close to merging these two

[openstack-dev] [Ironic] ironic-lib updates

Hi all, As you know, we've been working toward moving some code to ironic-lib[0] to be consumed by both Ironic and ironic-python-agent. Today I've created a new Launchpad project[1] for ironic-lib, as the managed release process requires a separate Launchpad for each deliverable. I've also submi

Re: [openstack-dev] [neutron][fwaas][dvr] FWaaS with DVR

Carl, Thanks for the reply. I agree that FWaaS with DVR and FWaaS - Security Groups API Alignment affect each other. My hope was that we could narrow down FWaaS with DVR first, so that we do not have to try to address everything in the enhanced FWaaS API incorporating Security Group functional

Re: [openstack-dev] [ironic] final release in Liberty cycle

On Thu, Aug 27, 2015 at 10:53:43PM -0400, Ruby Loo wrote: > Hi, > > As (most of) you are aware, in this cycle, ironic decided to switch to a > feature-based release model[0]. > > Our first semver release, 4.0.0, was tagged this week but a few more things > need to be ironed out still (hopefully t

Re: [openstack-dev] [nova][bugs] more specific tags?

On 8/28/2015 10:37 AM, Markus Zoeller wrote: This is a proposal to enhance the list of offical tags for our bugs in Launchpad. During the tagging process in the last weeks it seems to me that some of the tags are too coarse-grained. Would you see a benefit in enhancing the official list to more

Re: [openstack-dev] Weekly Meeting on Sep 1

On 8/31/15, 13:59, "Serg Melikyan" wrote: >Hi folks, > > >I want to let you know that I would not be able to chair tomorrow's >weekly meeting, Nikolai Starodubtsev is going to temporary replace me on >this meeting. > > >-- >Serg Melikyan, Senior Software Engineer at Mirantis, Inc. > >http://mi

Re: [openstack-dev] Feature Freeze - Finer details(?)

Excerpts from Davanum Srinivas (dims)'s message of 2015-08-31 12:36:26 -0700: > Thierry, Doug, > > Is this what we will be doing? If so, when can we schedule step #1? > > #1 Freeze all external libs in G-R (other than oslo and openstack python > libs) We typically do that at the same time as fea

Re: [openstack-dev] [nova][ceilometer] cputime value resets on restart/shutdown

On Mon, Aug 31 2015, gord chung wrote: > i think that's the reason the bug is raised... that's not what cumulative > means. by definition it should increase over each successive value. Well in a perfect world it would not, but with computers and numbers coded in bit it does. The bug about that i

[openstack-dev] Feature Freeze - Finer details(?)

Thierry, Doug, Is this what we will be doing? If so, when can we schedule step #1? #1 Freeze all external libs in G-R (other than oslo and openstack python libs) #2 Cut oslo libraries based on Step #1 #3 Update G-R with list of oslo libraries based on step #2 #4 Release OpenStack python-* librari

[openstack-dev] [Infra] Meeting Tuesday September 1st at 19:00 UTC

Hi everyone, The OpenStack Infrastructure (Infra) team is having our next weekly meeting on Tuesday September 1st, 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 inter

[openstack-dev] [nova] ProviderFirewallRules still available?

I saw this thread, "Undead DB objects: ProviderFirewallRule and InstanceGroupPolicy?" [1] Seems to be in the process of getting removed from the DB, but are provider level firewalls still available? I still see a lot of code that indicates it does [2] I traced it to here, but not sure where th

Re: [openstack-dev] [Infra][Cross Project] Proposing a centralized location for code coverage reports

On 2015-08-31 14:49:33 -0400 (-0400), Ronald Bradford wrote: [...] > fungi provided https://review.openstack.org/#/c/192253/ which is a > draft spec for a much wider ci-watch effort however I see this a > more specific example. I am seeking feedback from various projects > on interest, concerns and

Re: [openstack-dev] [nova][ceilometer] cputime value resets on restart/shutdown

On 31/08/2015 1:06 PM, Julien Danjou wrote: On Mon, Aug 31 2015, gord chung wrote: for context, we have an open bug in Ceilometer where the value used to capture cputime of an instance is being reset whenever the instance is restarted or shutdown[1]. this seems to be the expected behaviour fo

[openstack-dev] Weekly Meeting on Sep 1

Hi folks, I want to let you know that I would not be able to chair tomorrow's weekly meeting, Nikolai Starodubtsev is going to temporary replace me on this meeting. -- Serg Melikyan, Senior Software Engineer at Mirantis, Inc. http://mirantis.com | smelik...@mirantis.com +7 (495) 640-4904, 0261

Re: [openstack-dev] [puppet] [tc] applying for vulnerability:managed tag

Some questions: What would constitute a vulnerability for openstack-puppet since we're mainly consuming the upstream code? Would having an insecure default value on a parameter meet the criteria? What if the upstream default is also bad? We certainly also have some examples that should never be

[openstack-dev] sqlalchemy-migrate 0.9.8 released

https://pypi.python.org/pypi/sqlalchemy-migrate/0.9.8 I wanted to get a release out before dependency freeze for liberty. This is just a bug fix release, mostly to get the py34 job voting on the repo. Change log: mriedem@ubuntu:~/git/sqlalchemy-migrate$ git log --oneline --no-merges 0.9.7..

[openstack-dev] [cinder] os-brick release before dependency freeze

Dependency freeze [1] is this week (9/1-9/3) [2]. We need to get a release of os-brick out that includes the rootwrap filter change [3] since both cinder and nova need that for liberty deployments (need is maybe too strong? want/should have is maybe better). That will allow moving the devstac

[openstack-dev] [Infra][Cross Project] Proposing a centralized location for code coverage reports

Hi All, In last week's Cross Project IRC meeting [1] I sought to determine the merits and feasibility of having a central web location for code coverage of various/all OpenStack projects. Presently a few projects add code coverage as a non-voting gate and that provides a per-commit viewing option

Re: [openstack-dev] [neutron][gate] please stop approving patches until netaddr issue is solved

On 31 August 2015 at 10:44, Edgar Magana wrote: > Yeah!! > Well don't get so excited, the check queue is hovering over the 200 mark, so. > > From: "Armando M." > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > Date: Monday, August 31, 2015 at 10:26 AM > To: "Open

Re: [openstack-dev] Capturing program architecture

On 8/30/2015 11:19 PM, Adam Lawson wrote: Hi everyone! I'm trying to capture how each program is constructed for the purposes of writing a new set of OpenStack deep dive training material and wondering what is considered the best place to gi for this level of information? Such as breaking down

Re: [openstack-dev] [nova] periodic task

On 8/27/2015 1:22 AM, Gary Kotton wrote: > > > On 8/25/15, 2:43 PM, "Andrew Laski" wrote: > >> On 08/25/15 at 06:08pm, Gary Kotton wrote: >>> >>> >>> On 8/25/15, 9:10 AM, "Matt Riedemann" wrote: >>> On 8/25/2015 10:03 AM, Gary Kotton wrote: > > > On 8/25/15, 7:04 A

[openstack-dev] [puppet] [tc] applying for vulnerability:managed tag

Hi, I would like the feedback from the community about applying (or not) to the vulnerability:managed tag [1]. Being part of OpenStack ecosystem and the big tent, Puppet OpenStack project might want to follow some other projects in order to be consistent in Security management procedures. I belie

Re: [openstack-dev] [mistral] Displaying wf hierarchy in CLI

Would u guys have any use for the following being split out into its own library? https://github.com/openstack/taskflow/blob/master/taskflow/types/tree.py It already has a pformat method that could be used to do your drawing of the 'tree'... http://docs.openstack.org/developer/taskflow/types

Re: [openstack-dev] [neutron][gate] please stop approving patches until netaddr issue is solved

Yeah!! From: "Armando M." Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Monday, August 31, 2015 at 10:26 AM To: "OpenStack Development Mailing List (not for usage questions)" Subject: Re: [openstack-dev] [neutron][gate] please stop approving patches until netaddr

Re: [openstack-dev] [magnum] versioned objects changes

On 8/26/15 4:47 AM, Grasza, Grzegorz wrote: Hi, I noticed that right now, when we make changes (adding/removing fields) in https://github.com/openstack/magnum/tree/master/magnum/objects , we don't change object versions. The idea of objects is that each change in their fields should be

Re: [openstack-dev] [neutron][gate] please stop approving patches until netaddr issue is solved

On 31 August 2015 at 06:18, Ihar Hrachyshka wrote: > Hi all, > > I see neutron folks pushing more neutron patches into the gate. They are > all doomed to fail until [1] is resolved. So please stop approving patches, > we only make harm by resetting the gate, with no chance to pass it. > > PS: it

Re: [openstack-dev] [nova] periodic task

On 08/25/2015 08:04 AM, Matt Riedemann wrote: On 8/24/2015 9:32 PM, Gary Kotton wrote: In item #2 below the reboot is down via the guest and not the nova api’s :) From: Gary Kotton mailto:gkot...@vmware.com>> Reply-To: OpenStack List mailto:openstack-dev@lists.openstack.org>> Date: Monday, Au

Re: [openstack-dev] [Neutron] Netaddr 0.7.16 and gate breakage

On Mon, Aug 31, 2015 at 11:02 AM, Armando M. wrote: > > > On 31 August 2015 at 09:53, Jeremy Stanley wrote: >> >> On 2015-08-31 10:33:07 -0600 (-0600), Carl Baldwin wrote: >> > I was under the impression that we had a plan to stop allowing these >> > external updates break our gate jobs. >> [...]

[openstack-dev] [mistral] Displaying wf hierarchy in CLI

Team, I’d like to discuss https://blueprints.launchpad.net/mistral/+spec/mistral-execution-origin . To summarize what it’s about: imagine that we have a workflow which calls other workflows and those workflows call some w

Re: [openstack-dev] [Neutron] Netaddr 0.7.16 and gate breakage

On Mon, Aug 31, 2015 at 10:50 AM, Armando M. wrote: > You missed 'weekends' :) I did miss weekends! While I went about my life last night blissfully unaware of the problems that were brewing, you were on top of things and came to our rescue. I thank you for your efforts and time, truly. > Not

Re: [openstack-dev] [Neutron] Netaddr 0.7.16 and gate breakage

On 31 August 2015 at 09:53, Jeremy Stanley wrote: > On 2015-08-31 10:33:07 -0600 (-0600), Carl Baldwin wrote: > > I was under the impression that we had a plan to stop allowing these > > external updates break our gate jobs. > [...] > > We do, and it succeeded in protecting master branch integrat

Re: [openstack-dev] [barbican] python-barbicanclient-master.tar.gz outdated on tarballs.openstack.org

On 2015-08-31 12:46:59 +0200 (+0200), Thomas Bechtold wrote: > Can you point me to the code where this needs to be implemented? http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/python-jobs.yaml?id=a533c10#n188 http://git.openstack.org/cgit/openstack-infra/project-con

Re: [openstack-dev] [ANN] OpenStack Kilo on Ubuntu fully automated with Ansible! Ready for NFV L2 Bridges via Heat!

Thiago, Sorry for not replying inline, OWA is all I have access to today. We too have the ability to run everything on an AIO (all in one) which can be accomplished with a single command: --- # Command to run an AIO bash <(curl -s https://raw.githubusercontent.com/stackforge/os-ansible-deploy

Re: [openstack-dev] [nova][ceilometer] cputime value resets on restart/shutdown

On Mon, Aug 31 2015, gord chung wrote: > for context, we have an open bug in Ceilometer where the value used to capture > cputime of an instance is being reset whenever the instance is restarted or > shutdown[1]. this seems to be the expected behaviour for libvirt driver[2] but > it conflicts with

Re: [openstack-dev] [neutron][fwaas][dvr] FWaaS with DVR

Hi, I did take the opportunity to read through your etherpad today. Many of the solutions that you propose have been discussed in the past but there just hasn't been a traction on the problem. You did a fine job of writing this up and I think we should use your etherpad as a central point for di

[openstack-dev] [mistral] Team meeting minutes - 08/31/2015

Thanks a lot for joining today’s meeting folks! Meeting minutes: http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-08-31-16.20.html Meeting log: http://eavesdrop.openstack.org/meetings/mistral/

Re: [openstack-dev] [Nova] Placing VMs based on multiple criteria

Hi all, I'd appreciate if the experts can point me in one direction or another. If there are existing mechanisms, we don't want to reinvent the wheel. If there aren't, I'd be interested in exploring clean ways to extend and enhance nova scheduling. Thank you very much. Cheers, Sundar From

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

Thanks, Kevin and Ihar, for your advice on this. I think I know what to do with my change now, and I hope I haven't too much hijacked the previous direction of this thread. Regards, Neil From: Kevin Benton Sent: Monday, 31 August 2015 16:38 To: OpenStack Development Mailing List (not fo

Re: [openstack-dev] [Neutron] Netaddr 0.7.16 and gate breakage

On 2015-08-31 10:33:07 -0600 (-0600), Carl Baldwin wrote: > I was under the impression that we had a plan to stop allowing these > external updates break our gate jobs. [...] We do, and it succeeded in protecting master branch integration test jobs from this new netaddr release: https://revie

Re: [openstack-dev] [nova][bugs] more specific tags?

On 08/28/2015 11:37 AM, Markus Zoeller wrote: This is a proposal to enhance the list of offical tags for our bugs in Launchpad. During the tagging process in the last weeks it seems to me that some of the tags are too coarse-grained. Would you see a benefit in enhancing the official list to more

Re: [openstack-dev] [Neutron] Netaddr 0.7.16 and gate breakage

On 31 August 2015 at 09:33, Carl Baldwin wrote: > I was under the impression that we had a plan to stop allowing these > external updates break our gate jobs. It seems extremely unwise to > allow these forces outside of our control to disrupt us so much > especially in such a large project as Ne

Re: [openstack-dev] [Blazar] Anyone interested?

Yes, Blazar is a really interesting project. I worked on it some time ago and I really enjoy it. Sadly my obligations at work don't let me to still working on it, but I', happy that there still some interest in Blazar. Pablo. On 31/08/15 09:19, Zhenyu Zheng wrote: Hello, It seems like an interes

Re: [openstack-dev] [Neutron] Netaddr 0.7.16 and gate breakage

I was under the impression that we had a plan to stop allowing these external updates break our gate jobs. It seems extremely unwise to allow these forces outside of our control to disrupt us so much especially in such a large project as Neutron. We lose a lot of valuable time to these. I though

[openstack-dev] [Neutron] Kuryr - Virtual Sprint (9/8 - 9/9)

Hello Everyone, We had an IRC meeting today [1] and we talked about the virtual sprint. I have opened an etherpad [2] so everyone can suggest and add points to the agenda. We will set the agenda topics end of this week or starting next week just before the sprint (depending on what progress we ma

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

On 08/31/2015 01:50 AM, Kevin Benton wrote: The purpose of big tent isn't to have a bunch of sub-projects change the neutron core APIs and reference in ways they deem necessary. That will lead to a terrible user experience where the core functionality changes depending on which sub-projects are l

Re: [openstack-dev] [ANN] OpenStack Kilo on Ubuntu fully automated with Ansible! Ready for NFV L2 Bridges via Heat!

Hey guys, I know, the Ansible deployment (https://github.com/stackforge/os-ansible-deployment) is impressive... But, for our need, we required something much simpler, that could be deployed in an all-in-one fashion, without LXC containers for each service, Ansible against localhost to simplify

Re: [openstack-dev] [neutron][gate] please stop approving patches until netaddr issue is solved

On 08/31/2015 11:32 AM, Kevin Benton wrote: > Thanks for the clarification. I had thought that, after a short period > of time, changes would always have to go back through the check tests > before hitting the gate. We used to do that, however people grumbled quite a bit about the fact that patche

[openstack-dev] [nova][ceilometer] cputime value resets on restart/shutdown

hi i'm reaching out for help understanding meter values across hypervisors. for context, we have an open bug in Ceilometer where the value used to capture cputime of an instance is being reset whenever the instance is restarted or shutdown[1]. this seems to be the expected behaviour for libvi

Re: [openstack-dev] [Neutron] [horizon] Netaddr 0.7.16 and gate breakage

Horizon also needs to backport this change - https://jenkins07.openstack.org/job/gate-horizon-python27/4803/console https://review.openstack.org/#/c/198089/ is a stable/kilo patch failing on the same test failure. -Sean On 08/31/2015 10:48 AM, Akihiro Motoki wrote: > For Horizon, the fix

Re: [openstack-dev] [api][keystone][openstackclient] Standards for object name attributes and filtering

On 08/27/2015 11:28 PM, Chen, Wei D wrote: > > I agree that return 400 is good idea, thus client user would know what > happened. > +1, I think a 400 is the sensible choice here. It'd be much more likely to help devs catch their errors . -- Ryan Brown / Software Engineer, Openstack / Red Hat,

Re: [openstack-dev] [neutron][gate] please stop approving patches until netaddr issue is solved

For all VPN commits that I had previously gave a +2, I added a WIP (not ready for review). Regards, On Mon, Aug 31, 2015 at 11:34 AM Kevin Benton wrote: > Thanks for the clarification. I had thought that, after a short period of > time, changes would always have to go back through the check te

Re: [openstack-dev] [monasca] Monasca weekly meetings in IRC, datetime proposal

This is just a reminder that the Monasca weekly meeting will be moving to a new day and use of IRC this week. See, http://eavesdrop.openstack.org/#Monasca_Team_Meeting for more details Day: Weekly on Wednesday Time: 1500 UTC IRC: openstack-meeting-3 Agenda: https://etherpad.openstack.org/p/monasc

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

No, I wouldn't consider that to be monkey-patching. That's something that we have a pluggable driver interface for. As Ihar pointed out, you will have to be careful maintaining it since the class you are subclassing may move or alter the '_build_cmdline_callback' method, but that isn't a huge deal.

Re: [openstack-dev] [neutron][gate] please stop approving patches until netaddr issue is solved

Thanks for the clarification. I had thought that, after a short period of time, changes would always have to go back through the check tests before hitting the gate. On Mon, Aug 31, 2015 at 8:27 AM, Clark Boylan wrote: > If the check tests ran prior to the netaddr release and got a +1 any > appr

Re: [openstack-dev] [neutron][gate] please stop approving patches until netaddr issue is solved

On 08/31/2015 11:28 AM, Ihar Hrachyshka wrote: >> On 31 Aug 2015, at 17:20, Kevin Benton wrote: >> >> Why would they reset the gate? Shouldn't they just fail the check test? > > I think if it has an old +1 vote it may consider the vote good enough to push > the patch in the gate directly. Corre

Re: [openstack-dev] [neutron][gate] please stop approving patches until netaddr issue is solved

> On 31 Aug 2015, at 17:20, Kevin Benton wrote: > > Why would they reset the gate? Shouldn't they just fail the check test? I think if it has an old +1 vote it may consider the vote good enough to push the patch in the gate directly. Ihar signature.asc Description: Message signed with OpenPG

Re: [openstack-dev] [neutron][gate] please stop approving patches until netaddr issue is solved

If the check tests ran prior to the netaddr release and got a +1 any approvals will put them straight into the gate. They will only go through check first (and fail there) if they do not already have a +1 from Jenkins. When they fail in the gate they reset all the changes behind them. When you hav

Re: [openstack-dev] [neutron][gate] please stop approving patches until netaddr issue is solved

Why would they reset the gate? Shouldn't they just fail the check test? On Mon, Aug 31, 2015 at 6:18 AM, Ihar Hrachyshka wrote: > Hi all, > > I see neutron folks pushing more neutron patches into the gate. They are > all doomed to fail until [1] is resolved. So please stop approving patches, > w

Re: [openstack-dev] [Neutron] DHCP configuration

neutron.common.config should have general DHCP options that aren't specific to the reference DHCP agent. neutron.agent.dhcp.config should have all of the stuff specific to our agent and dnsmasq. On Mon, Aug 31, 2015 at 7:54 AM, Gal Sagie wrote: > Hello all, > > I went over the code and noticed t

Re: [openstack-dev] [Neutron] [horizon] Netaddr 0.7.16 and gate breakage

> On 31 Aug 2015, at 16:48, Akihiro Motoki wrote: > > For Horizon, the fix is now in the gate queue. > https://review.openstack.org/#/c/218786/ > It only skips the related test, but the failing test is specific to vendor > plugin implementation > and we can explore the fix later. > > Regarding

Re: [openstack-dev] [Neutron] [horizon] Netaddr 0.7.16 and gate breakage

Given that Horizon unit test breakage was introduced simultaneously with the breakage of 2 integration tests, the latter ones have the same nature. Thus integration tests are going to fail until the related Neutron patch is merged. On Mon, Aug 31, 2015 at 5:50 PM Akihiro Motoki wrote: > For Hori

[openstack-dev] [Neutron] DHCP configuration

Hello all, I went over the code and noticed that we have default DHCP configuration both in neutron/common/config.py (dhcp_lease_duration , dns_domain and dhcp_agent_notification) But also we have it in neutron/agent/dhcp/config.py (DHCP_AGENT_OPTS, DHCP_OPTS) I think we should consider merging

Re: [openstack-dev] [Neutron] [horizon] Netaddr 0.7.16 and gate breakage

For Horizon, the fix is now in the gate queue. https://review.openstack.org/#/c/218786/ It only skips the related test, but the failing test is specific to vendor plugin implementation and we can explore the fix later. Regarding the stable releases, Horizon may also need the similar version cap fo

Re: [openstack-dev] [third-party] [CI] The dsvm-tempest-full job failed

Hi Xiexs, After the jobs starts and the nodepool node is marked “used’ use the nodepool hold command. This will prevent it from being deleted until you do so manually. Ramy From: Xie, Xianshan [mailto:xi...@cn.fujitsu.com] Sent: Monday, August 31, 2015 12:46 AM To: OpenStack Development Mailin

[openstack-dev] [mistral] Team meeting - 08/31/2015

Hi, This is a reminder about the team meeting that we’ll have to day at #openstack-meeting at 16.20 UTC. Please note that it’s 16.20 UTC for today, not 16.00. Agenda: Review action items Current status (progress, issues, roadblocks, further plans) Liberty-3 progress Open discussion Renat Akhm

Re: [openstack-dev] [Openstack] [ANN] OpenStack Kilo on Ubuntu fully automated with Ansible! Ready for NFV L2 Bridges via Heat!

Or you could use the excellent modules provided by the openstack-ansible contributor team: https://github.com/openstack-ansible/openstack-ansible-modules/blob/master/keystone_service Best, -jay On 08/31/2015 08:54 AM, Jose Manuel Ferrer Mosteiro wrote: Nice job. I am doing a vmware vcenter li

[openstack-dev] [ceilometer] proposal to add Liusheng to Ceilometer core

hi, we'd like to nominate Liusheng to the Ceilometer core team. he has been a leading contributor in Ceilometer, provides solid reviews, and regularly adds ideas for new improvements. as we did last time, please vote here: https://review.openstack.org/#/c/218819/ . if for whatever reason you

[openstack-dev] [neutron][gate] please stop approving patches until netaddr issue is solved

Hi all, I see neutron folks pushing more neutron patches into the gate. They are all doomed to fail until [1] is resolved. So please stop approving patches, we only make harm by resetting the gate, with no chance to pass it. PS: it is the same for all neutron stadium projects, so *aas and pyth

[openstack-dev] [ceilometer] proposal to add Pradeep Kilambi to Ceilometer core

hi, we'd like to nominate Pradeep Kilambi to the Ceilometer core team. he has contributed by adding declarative meter support in Ceilometer and provides feedback/input in regards to packaging and design. as we did last time, please vote here: https://review.openstack.org/#/c/218822/ . if for

  1   2   >