Re: [openstack-dev] [Heat] convergence rally test results (so far)

Hi Angus, Thanks for doing the tests with convergence. We are now assured that convergence has not impacted the performance in a negative way. Given that, in convergence, a stack provisioning process goes through a lot of RPC calls, it puts a lot of load on the message broker and the request

Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2

Yes, I added it Sent from my iPhone > On Aug 31, 2015, at 01:19, Brandon Logan wrote: > > Vivek, > Is there a wiki or some document somewhere that explains how to get this > running? Sorry if it's been posted somewhere else and I missed it. > >> On Sun,

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

Even if this version is fixed for valid_mac, it appears the netaddr authors made the decision to make a backwards incompatible change WRT to the 'broadcast' attribute on IPNetwork objects that have CIDRs of /31 and /32. This means that all future versions of netaddr will be incompatible with the

Re: [openstack-dev] [Neutron] [DVR] easyOVS -- Smart tool to use/debug Neutron/DVR

Hi, It's Interesting! I have three points for you here. a.Support packet tracking which show the path of a packet traveled on the host, even on the source/destination host. b.Given a communication type and packet characteristic to find out the fault point. For example, if you want VM1 talk with

Re: [openstack-dev] [oslo] About "logging-flexibility"

Hi, Dims, and Oslo team members, > > > We can talk more about it on next > > > Monday's Oslo meeting. Please let us know and i'll add a topic > > > there if you can make it. I have uploaded a patch about logging-flexibility[1]. https://review.openstack.org/#/c/218139/ This is a single patch

[openstack-dev] [Neutron] [DVR] easyOVS -- Smart tool to use/debug Neutron/DVR

Hi, One suggestion from my side is checking nova security groups against iptable rules for each vm.Doing this will ensure that there are no unwanted holes in security (for example, accidental messing up of iptable rules). Thanks -Vikas Choudhary

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

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

[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

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

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

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

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

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

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:

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

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

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

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:

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

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

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

[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

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

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][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

[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

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

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

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

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 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:

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

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

[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:

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

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

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

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

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

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

[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

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 >> >

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 > Reply-To: OpenStack List

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

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

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] [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'...

[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

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

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

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,

[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

[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

[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

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] 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] [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

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

[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

[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

[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-*

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

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

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

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

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

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

[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

[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

[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

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

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:

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

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] 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

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

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,

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

[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

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,

[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 *

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.

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

[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: 

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 >

[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

[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:

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

Re: [openstack-dev] [Heat] Use block_device_mapping_v2 for swap?

At 2015-08-28 21:48:11, "marios" wrote: >I am working with the OS::Nova::Server resource and looking at the tests >[1], it should be possible to just define 'swap_size' and get a swap >space created on the instance: > > NovaCompute: >type: OS::Nova::Server >

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

Hi Xianshan , So after starting nodepool you have configured the slave in Jenkins or it was done automatically? On Mon, Aug 31, 2015 at 1:15 PM, Xie, Xianshan wrote: > Hi, all, > > I`m trying to run the job "dsvm-tempest-full" in a slave node which > built and managed

Re: [openstack-dev] [Heat] Use block_device_mapping_v2 for swap?

On 31/08/15 11:19, TIANTIAN wrote: > > > At 2015-08-28 21:48:11, "marios" wrote: >> I am working with the OS::Nova::Server resource and looking at the tests >> [1], it should be possible to just define 'swap_size' and get a swap >> space created on the instance: >> >>

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

On Sun, 2015-08-30 at 12:49 +, Jeremy Stanley wrote: > On 2015-08-30 10:23:32 +0200 (+0200), Thomas Bechtold wrote: > [...] > > Maybe the tarball won't be regenerated if only a new git tag is > > pushed? > > In that case the latest commit-id doesn't change but the content of > > the > >

Re: [openstack-dev] [Gnocchi] Added Ilya Tyaptin as core reviewer

​Thank you very much! Best regards, Tyaptin Ilia On Fri, Aug 28, 2015 at 10:32 PM, gord chung wrote: > > On 28/08/15 02:48 PM, Julien Danjou wrote: > > Hi fellows, > > Ilya did a few good contributions to Gnocchi, especially around the > InfluxDB driver, so I'm glad to add

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

Hi Kevin, I currently have an example of this kind of thing that I'm working on, and I'd appreciate hearing your view on what is the best solution. My requirement was to change some of the command line options with which the DHCP agent invokes Dnsmasq. My first implementation of this was in

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

Hi, all, I`m trying to run the job "dsvm-tempest-full" in a slave node which built and managed by the nodepool. But I got the following error messages: -- 14:45:48 + timeout -s 9 174m /opt/stack/new/devstack-gate/devstack-vm-gate.sh 14:45:48 timeout: failed to run command

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

> On 31 Aug 2015, at 08:19, Kevin Benton wrote: > > Even if this version is fixed for valid_mac, it appears the netaddr authors > made the decision to make a backwards incompatible change WRT to the > 'broadcast' attribute on IPNetwork objects that have CIDRs of /31 and /32.

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

Hi, Abhishek, Yes. Now, our nodepool can launch slave nodes and add them into Jenkins server automatically. But unfortunately there are still same errors. Xiexs From: Abhishek Shrivastava [mailto:abhis...@cloudbyte.com] Sent: Monday, August 31, 2015 4:07 PM To: OpenStack Development

[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] 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.

  1   2   >