Re: [openstack-dev] [nova] config options: IRC meeting at Jan. 11th

Esra Celik wrote on 01/12/2016 12:55:25 PM: > From: Esra Celik > To: "OpenStack Development Mailing List (not for usage questions)" > , Markus Zoeller/Germany/IBM@IBMDE > Date: 01/12/2016 12:55 PM > Subject: Re: [openstack-dev] [nova] config options: IRC meeting at Jan. 11th > > I think we ha

Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC

The issue with this data is that who says something is not a good metric. For example, this shows that I attended more than twice as many afternoon meetings as the morning meetings when I know I actually only missed a couple of morning ones. I just don't say anything unless there is something that

Re: [openstack-dev] [kolla] Introduction of Heka in Kolla

On 12 Jan 2016 at 13:24:26, Kwasniewska, Alicja (alicja.kwasniew...@intel.com) wrote: Unfortunately I do not have any experience in working or testing Heka, so it’s hard for me to compare its performance vs Logstash performance. However I’ve read that Heka possess a lot advantages over Logstas

Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC

Tony Breeds wrote: On Tue, Jan 12, 2016 at 01:27:30PM +0100, Ihar Hrachyshka wrote: Agreed with Gary on behalf of my European compatriots. (Note that I *personally* +1’d the patch because I don’t mind, doing late hours anyway; but it’s sad it was ninja merged without giving any chance for thos

Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC

Doug Wiegley wrote: I don’t think it ninja merged. It had plenty of reviews, and was open during international hours. I don’t have any issue there. I merely meant it was merged too quick. I did not know some people feel the 'ninja merge’ term has negative flavor. What’s your definition

Re: [openstack-dev] [TripleO] Driving workflows with Mistral

Hi, Seems like most of the questions raised in the thread have been answered. Just some clarifications on Mistral+Zaqar from my side: Mistral integration with Zaqar still doesn’t exist although has been very much wanted for a while. In its most trivial form it’s just a matter of adding Zaqar ac

Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC

Kevin Benton wrote: The issue with this data is that who says something is not a good metric. For example, this shows that I attended more than twice as many afternoon meetings as the morning meetings when I know I actually only missed a couple of morning ones. I just don't say anything un

[openstack-dev] [nova] nova unit tests failing with os-win 0.1.0

This post is just to make you aware that there was an issue in the last 24 hours which might have hit your patches: https://bugs.launchpad.net/nova/+bug/1533290 Regards, Markus Zoeller (markus_z) __ OpenStack Development Mai

[openstack-dev] [infra][all] "openstack-meeting-cp" == "openstack-meeting-5"?

Hi, I'd like to revive the nova-bugs-team IRC meeting and I'm looking for a channel to use. I've seen that there is an "openstack-meeting-cp" channel. The other channels are already in use for the timeslots I envisioned. Is this channel solely for (future) cross-project efforts or can I use it to

Re: [openstack-dev] [TripleO] Removing unused/deprecated template parameters?

IIRC some of them were already marked (via a comment) as deprecated. +1 to cleaning up the parameters. I think it should be done as soon as possible, as the existence of some of them makes the usage of the templates quite confusing. BR On Tue, Jan 12, 2016 at 10:47 PM, Steven Hardy wrote: > Hi

[openstack-dev] [TripleO] Should we have a TripleO API, or simply use Mistral?

Hey all, I realize now from the title of the other TripleO/Mistral thread [1] that the discussion there may have gotten confused. I think using Mistral for TripleO processes that are obviously workflows - stack deployment, node registration - makes perfect sense. That thread is exploring practic

[openstack-dev] [magnum] Nesting /containers resource under /bays

I've recently been gathering feedback about the Magnum API and one of the things that people commented on? was the global /containers endpoints. One person highlighted the danger of UUID collisions: """ It takes a container ID which is intended to be unique within that individual cluster. Per

Re: [openstack-dev] [TripleO] Removing unused/deprecated template parameters?

On 01/13/2016 10:33 AM, Juan Antonio Osorio wrote: IIRC some of them were already marked (via a comment) as deprecated. +1 to cleaning up the parameters. I think it should be done as soon as possible, as the existence of some of them makes the usage of the templates quite confusing. BR On T

Re: [openstack-dev] [infra][all] "openstack-meeting-cp" == "openstack-meeting-5"?

Markus Zoeller wrote: I'd like to revive the nova-bugs-team IRC meeting and I'm looking for a channel to use. I've seen that there is an "openstack-meeting-cp" channel. The other channels are already in use for the timeslots I envisioned. Is this channel solely for (future) cross-project efforts

[openstack-dev] [neutron] Testing Neutron with latest OVS

Hi all, recently I was working on firewall driver [1] that requires latest features in OVS, specifically conntrack support. In order to get the driver tested, we need to have the latest OVS kernel modules on machines running tests but AFAIK there is no stable "2.5 like" release of OVS yet. Facing

Re: [openstack-dev] [kolla] Introduction of Heka in Kolla

On Tue, Jan 12, 2016 at 5:36 PM, Michał Jastrzębski wrote: > So tracebacks sort of works, they're there just ugly. That's why I'm > also happy if we change rsyslog to heka. > > Eric, I hope I wont ask too much, but could you please prepare PoC of > kolla+heka, for what I care heka can log to local

Re: [openstack-dev] [kolla] Introduction of Heka in Kolla

Hi Alicja Thank you for your comments. Answers and comments below. On Tue, Jan 12, 2016 at 1:19 PM, Kwasniewska, Alicja wrote: > Unfortunately I do not have any experience in working or testing Heka, so > it’s hard for me to compare its performance vs Logstash performance. However > I’ve rea

[openstack-dev] [vitrage] Vitrage meeting minutes

Hi, You can find the meeting minutes of Vitrage meeting: http://eavesdrop.openstack.org/meetings/vitrage/2016/vitrage.2016-01-13-09.00.html Meeting log: http://eavesdrop.openstack.org/meetings/vitrage/2016/vitrage.2016-01-13-09.00.log.html See you next week, Ifat.

Re: [openstack-dev] [nova][neutron][os-vif] os-vif core review team membership

On Tue, Jan 12, 2016 at 10:28:49PM +, Mooney, Sean K wrote: > > -Original Message- > > From: Moshe Levi [mailto:mosh...@mellanox.com] > > Sent: Tuesday, January 12, 2016 4:23 PM > > To: Russell Bryant; Daniel P. Berrange; openstack- > > d...@lists.openstack.org > > Cc: Jay Pipes; Mooney

[openstack-dev] [Nova] [Live Migration] topics for midcycle

Hi All, Following up on a question raised in the live migration meeting yesterday about organizing topics for the mid cycle: please add topic suggestions to https://etherpad.openstack.org/p/mitaka-nova-midcycle and we will review them in next week's meeting. Paul Paul Murray Technical Lead, H

Re: [openstack-dev] [kolla] Introduction of Heka in Kolla

On Tue, Jan 12, 2016 at 8:26 PM, Steven Dake (stdake) wrote: > Eric, > > Thanks for using the mailing list for this discussion. I like to see more > mailing list conversations on big changes related to kolla, which this one > is :) > Responses inline. > > Please put document #3 (the design docume

Re: [openstack-dev] [infra][all] "openstack-meeting-cp" == "openstack-meeting-5"?

Thierry Carrez wrote on 01/13/2016 10:44:04 AM: > From: Thierry Carrez > To: openstack-dev@lists.openstack.org > Date: 01/13/2016 10:44 AM > Subject: Re: [openstack-dev] [infra][all] "openstack-meeting-cp" == > "openstack-meeting-5"? > > Markus Zoeller wrote: > > I'd like to revive the nova-bu

Re: [openstack-dev] [keystone][security] New BP for anti brute force in keystone

Hi, Can't you just do some rate limiting at your webserver level ? On Tue, Jan 12, 2016 at 3:55 PM, McPeak, Travis wrote: > One issue to be aware of is the use of this as a Denial of Service > vector. Basically an attacker can use this to lock out key accounts > by continuously sending invalid

[openstack-dev] [all] "Upstream Development" track at the Austin OpenStack Summit

Hi everyone, As you may have already noticed in the CFP[1], in Austin for the first time we'll have a conference track clearly targeted to upstream OpenStack developers (us all on this mailing-list). It will run on the Monday, /before/ the design summit tracks start, so it should actually be

Re: [openstack-dev] [Bareon][Fuel] Dynamic allocation algorithm

Hi. Very good documentation. For Integer Solution you can use bytes instead of megabytes. Hence N bytes will be unallocated in the worst case. I didn't find solution for problem: - Don’t allocate a single volume on ssd and hdd Best regards, Svechnikov Artur On Tue, Jan 12, 2016 at 9:37 PM,

Re: [openstack-dev] [infra][all] "openstack-meeting-cp" == "openstack-meeting-5"?

Markus Zoeller wrote: Understood. Would it then be possible to create a new channel "openstack-meeting-5"? The short time span I have as an overlap with the US folks already uses all existing 4 meeting rooms. We limit the number of channels by design, to limit the number of concurrent meetings

Re: [openstack-dev] [kolla] Introduction of Heka in Kolla

Eric, Patrick, Simon, Clark thanks for your comments. I don't know Heka, so that's why I ask a lot of questions. I hope you are fine with that:) I am not against Heka, I was just curious how reliable it is and how much experience you have with setting it up in Docker environment in order to kn

Re: [openstack-dev] [Bareon][Fuel] Dynamic allocation algorithm

Hi Artur, You are correct, we probably may consider using bytes instead of megabytes. Regarding to question "ssd vs hdd", user can describe which space is better to allocate on ssd and which is better on hdd, the mechanism is completely data driven, it can be done using "best_with_disks" [0], in

[openstack-dev] [Fuel] Repositories on master node and delivering updates

Hi, There was a request to deliver updates to master node some time ago. As a result of subsequent discussion in email thread and several offline discussions a document [1] was created that describes existing situation with repositories on master node, and a proposal on delivering updates. Please

Re: [openstack-dev] [chef] deprecation and removal of old branches

Hi, i talked to infra and they can remove all of our old branches, but would also like us to tag them first. To do this, i (as the PTL) need to push these signed tags directly to gerrit. To be able to do this i need to adapt our gerrit acls and allow this. While i walked through the whole proce

[openstack-dev] [neutron][neutron-lib] Proposal for callback mechanism migration

Reposted: as I had a typo in subject line that affected filtering of message... I wanted to float two ideas related to the neutron callback mechanism that is being moved to neutron-lib. 1) API The current API uses kwargs as a way for the notifier to pass information to the subscribers listening (

[openstack-dev] [kolla] Heka v ELK stack logistics

Hey folks, I'd like to have a mailing list discussion about logistics of the ELKSTACK solution that Alicja has sorted out vs the Heka implementation that Eric is proposing. My take on that is Eric wants to replace rsyslog and logstash with Heka. That seems fine, but I want to make certain thi

[openstack-dev] [nova][bugs] nova-bugs-team IRC meeting

Hey folks, I'd like to revive the nova-bugs-team IRC meeting. As I want to chair those meetings in my "bug czar" role, the timeslots are bound to my timezone (UTC+1). The two bi-weekly alternating slots I have in mind are: * Tuesdays, 10:00 UTC biweekly-odd (to get folks to the east of me) * Tu

Re: [openstack-dev] [nova] config options: IRC meeting at Jan. 11th

- Orijinal Mesaj - > Kimden: "Markus Zoeller" > Kime: "OpenStack Development Mailing List" > > Gönderilenler: 13 Ocak Çarşamba 2016 10:36:56 > Konu: Re: [openstack-dev] [nova] config options: IRC meeting at Jan. 11th > Esra Celik wrote on 01/12/2016 12:55:25 PM: > > From: Esra Celik

[openstack-dev] [kolla] Can Heka solve all the deficiencies in the current rsyslog implementation: was Re: [kolla] Introduction of Heka in Kolla

Eric, Apologies for top post, not really sure where in this thread to post this list of questions as its sort of a change in topic so I changed the subject line :) 1. Somewhere I read when researching this Heka topic, that Heka cannot log all details from /dev/log. Some services like mariadb for

[openstack-dev] [Fuel] New version of fuel-devops (2.9.16)

Hi All, We are going to update the 'fuel-devops' framework on our product CI to the version 2.9.16 on Friday, 15 Jan. This is bugfix update. Changes since 2.9.15: - Default memory size for Fuel master node updated to 3Gb [1] - Added support for creation Fuel master node with Centos 7 from fu

Re: [openstack-dev] [kolla] Heka v ELK stack logistics

So is it decided that we want Heka instead of ELK in Kolla and that it is just a matter of time, then ? Clark Boyle put forward some very good points [1] which seem to have gone sadly mostly ignored. What are we trying to address by replacing ELK ? Performance ? Clark's numbers are far from being

[openstack-dev] [Oslo][all] os-profiler under Oslo umbrella

Team, Oslo folks have voted[1] to be the home for the osprofiler project[2]. Several projects are already using osprofiler. One example of work in flight is for Nova[3]. Please take a look at the README to see the features/description, in a nutshell it will allow operators / end users to drill do

[openstack-dev] Add Monasca Client to global reqs

Guys, I just updated the requirements patch to update the monasca client to the global reqs. It now points to the latest version 1.0.27 that has all the compatible libraries (thanks Joe). https://review.openstack.org/#/c/251674/ Please review it so we can merge it. Thanks, Fabio ___

[openstack-dev] [Monasca] Add Monasca Client to global reqs

Guys, I just updated the requirements patch to update the monasca client to the global reqs. It now points to the latest version 1.0.27 that has all the compatible libraries (thanks Joe). https://review.openstack.org/#/c/251674/ Please review it so we can merge it. Thanks, Fabio ___

Re: [openstack-dev] [kolla] Heka v ELK stack logistics

From: David Moreau Simard mailto:d...@redhat.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Wednesday, January 13, 2016 at 5:55 AM To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack

Re: [openstack-dev] App dev guides update [nova] [keystone] [cinder] [swift] [glance] [neutron] [trove] [heat] [manila] [ceilometer] [sahara] [senlin]

Anne, thank you for this update. And thank you to the contributors who improved the SDK and developer guide documentation. Fantastic work, all of you! Best, -jay On 01/13/2016 12:18 AM, Anne Gentle wrote: Hi all, I wanted to be sure to post to the dev, docs, and user mailing lists about the p

[openstack-dev] [nova] path forward on making project_id optional in API URLs

There is a snag at the moment in making project_id optional in API URLs because of how python routes modules works. When we call mapper.resource(...) it's creating a series of mapper.connect(...) calls to setup routes. This just adds items to a dictionary. When we later use the mapper to match a r

Re: [openstack-dev] [TripleO] Should we have a TripleO API, or simply use Mistral?

On Wed, 2016-01-13 at 04:41 -0500, Tzu-Mainn Chen wrote: > Hey all, > > I realize now from the title of the other TripleO/Mistral thread [1] > that > the discussion there may have gotten confused.  I think using Mistral > for > TripleO processes that are obviously workflows - stack deployment, > n

Re: [openstack-dev] [keystone][security] New BP for anti brute force in keystone

A standard method of rate limiting for OpenStack services would be a good thing to figure out. On Jan 13, 2016 02:56, "Jordan Pittier" wrote: > Hi, > Can't you just do some rate limiting at your webserver level ? > > On Tue, Jan 12, 2016 at 3:55 PM, McPeak, Travis > wrote: > >> One issue to be a

Re: [openstack-dev] [keystone][security] New BP for anti brute force in keystone

This needs to be proposed as a spec, not just a blueprint. For what it is worth, this has been discussed many times and it was determined that keystone as a project was not interested in really managing the life cycle of passwords on this front. Since we support the use of real Identity Stores and

Re: [openstack-dev] [api][all] api variation release by release

On 1/13/2016 12:11 AM, joehuang wrote: Thanks for the information, it's good to know the documentation. The further question is whether there is any XML format like document will be published for each release and all core projects, so that other cloud management software can read the changes

Re: [openstack-dev] [nova] path forward on making project_id optional in API URLs

As a note, there is potential that this will require older deployments that have historical names migrated to update project IDs to hex-strings. These are a minority of deployments at best, but this should be considered in the proposal so if this goes forward we can clearly communicate this change

Re: [openstack-dev] [Manila] Midcycle meetup

Is there a link to the topics or schedule? - Luis - Original Message - From: "Ben Swartzlander" To: "OpenStack Development Mailing List (not for usage questions)" Sent: Wednesday, December 9, 2015 8:25:55 PM Subject: Re: [openstack-dev] [Manila] Midcycle meetup On 12/04/2015 04:42 PM,

[openstack-dev] [neutron] [QoS] Phantom meeting

Hi everybody, We held a short meeting today because the calendar was saying today we had another biweekly meeting, regardless of having another one last week. So I guess next week we have no meeting unless we want to have another short one too. Minutes are here: http://eavesdrop

Re: [openstack-dev] [Manila] Midcycle meetup

https://etherpad.openstack.org/p/manila-mitaka-midcycle On Wed, Jan 13, 2016 at 4:51 PM, Luis Pabon wrote: > Is there a link to the topics or schedule? > > - Luis > > - Original Message - > From: "Ben Swartzlander" > To: "OpenStack Development Mailing List (not for usage questions)" < >

Re: [openstack-dev] [Manila] Midcycle meetup

https://etherpad.openstack.org/p/manila-mitaka-midcycle Clinton On 1/13/16, 9:51 AM, "Luis Pabon" wrote: >Is there a link to the topics or schedule? > >- Luis > >- Original Message - >From: "Ben Swartzlander" >To: "OpenStack Development Mailing List (not for usage questions)" > >Sent:

[openstack-dev] [nova] wrong disk usage for volume-backed instances

Hello, This issue has been active since mid 2014 and still hasn't got any resolution or fixes merged. I'm pushing for a fix to this issue and anybody with help or feedback is welcome. Please see my last comment on https://bugs.launchpad.net/nova/+bug/1469179 regarding the old review which could b

Re: [openstack-dev] [kolla] Heka v ELK stack logistics

Hello guys, So 2 cents from me: As sdake said, Heka seems to be replacement of rsyslog rather than logstash. If it can replace both, even better, we end up with one less dependency, and less dependencies are good. So I'd rather wait with making this decision before Eric presents PoC he promised he

[openstack-dev] [openstack-ansible][security] Should the playbook stop on certain tasks?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey there, After presenting openstack-ansible-security at the Security Project Mid-Cycle meeting yesterday, the question came up around how to handle situations where automation might cause problems. For example, the STIG requires[1] that all sys

Re: [openstack-dev] [nova] path forward on making project_id optional in API URLs

On Wed, 13 Jan 2016, Sean Dague wrote: Because this regex is built from a dictionary, hash seed matters, and it is not stable which will get precedence. Ow[1]. I'd like to propose for Nova we restrict project_id in the URL to [0-9a-f]+, which is any valid hex string. Ints are a subset of thi

Re: [openstack-dev] [nova] config options: IRC meeting at Jan. 11th

Esra Celik wrote on 01/13/2016 01:29:12 PM: > From: Esra Celik > To: "OpenStack Development Mailing List (not for usage questions)" > > Date: 01/13/2016 01:30 PM > Subject: Re: [openstack-dev] [nova] config options: IRC meeting at Jan. 11th > > > > I do also realize now that I didn't make yo

[openstack-dev] [Cinder] [Manila] NetApp CI will be offline next week

Hi all, The physical equipment that runs the NetApp CI system is scheduled to be moved to a new building next week. In order to accommodate this move we will be taking the NetApp CI system offline at EOB on Friday Jan 15 and plan to have it back up and running by EOB on Monday Jan 25. I just

Re: [openstack-dev] [Cinder] [Manila] NetApp CI will be offline next week

On 01/13/2016 10:43 AM, Kerr, Andrew wrote: > Hi all, > > The physical equipment that runs the NetApp CI system is scheduled to be > moved to a new building next week. In order to accommodate this move we will > be taking the NetApp CI system offline at EOB on Friday Jan 15 and plan to > have

[openstack-dev] [sahara] Sahara scenario tests freeze

Hi folks, please, stop merging scenario tests CRs to the scenario tests, their unit tests and scenarios itself. We're now in progress of moving them to the separated repository. Thanks. -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Principal Software Engi

Re: [openstack-dev] [nova] path forward on making project_id optional in API URLs

On 01/13/2016 10:31 AM, Chris Dent wrote: > On Wed, 13 Jan 2016, Sean Dague wrote: > >> Because this regex is built from a dictionary, hash seed matters, and it >> is not stable which will get precedence. > > Ow[1]. > >> I'd like to propose for Nova we restrict project_id in the URL to >> [0-9a-

[openstack-dev] [release][keystone] keystonemiddleware release 4.1.0 (mitaka)

We are tickled pink to announce the release of: keystonemiddleware 4.1.0: Middleware for OpenStack Identity This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/keystonemiddleware With package available at: https://pypi.p

[openstack-dev] [release][keystone] keystoneauth release 2.2.0 (mitaka)

We are eager to announce the release of: keystoneauth 2.2.0: Authentication Library for OpenStack Identity This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/keystoneauth With package available at: https://pypi.python.o

[openstack-dev] [Neutron] Gate failure

It's the usual time of the week where I submit the dreaded email Please do not push anything in the queue until change [1] merges. Cheers, Armando [1] https://review.openstack.org/#/c/266885/ __ OpenStack Development Mai

Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC

On 12 January 2016 at 20:07, Kyle Mestery wrote: > On Tue, Jan 12, 2016 at 5:28 PM, Doug Wiegley < > doug...@parksidesoftware.com> wrote: > >> I don’t think it ninja merged. It had plenty of reviews, and was open >> during international hours. I don’t have any issue there. >> >> I don’t like the

Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC

On Wed, Jan 13, 2016 at 12:01 PM, Armando M. wrote: > > > On 12 January 2016 at 20:07, Kyle Mestery wrote: > >> On Tue, Jan 12, 2016 at 5:28 PM, Doug Wiegley < >> doug...@parksidesoftware.com> wrote: >> >>> I don’t think it ninja merged. It had plenty of reviews, and was open >>> during internat

Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC

On Wed, Jan 13, 2016 at 02:59:35AM CST, Ihar Hrachyshka wrote: > Kevin Benton wrote: > > >The issue with this data is that who says something is not a good metric. > >For example, this shows that I attended more than twice as many afternoon > >meetings as the morning meetings when I know I actual

Re: [openstack-dev] [TripleO] Should we have a TripleO API, or simply use Mistral?

- Original Message - > On Wed, 2016-01-13 at 04:41 -0500, Tzu-Mainn Chen wrote: > > Hey all, > > > > I realize now from the title of the other TripleO/Mistral thread [1] > > that > > the discussion there may have gotten confused.  I think using Mistral > > for > > TripleO processes that ar

Re: [openstack-dev] [TripleO] Removing unused/deprecated template parameters?

On Tue, 2016-01-12 at 20:47 +, Steven Hardy wrote: > Hi all, > > I've noticed that we have a fairly large number of unused parameters > in > t-h-t, some of which are marked deprecated, some aren't. > > Since we moved tripleoclient to use parameter_defaults everywhere, I > think > it should be

[openstack-dev] Further closing the holes that let gate breakage happen

Hi, I was looking at the most recent gate breakage in Neutron [1], fixed by [2]. This gate breakage was held off for some time by the upper-constraints.txt file. This is great progress and I applaud it. I'll continue to cheer on this effort. Now to the next problem. If my assessment of this

Re: [openstack-dev] [nova] config options: IRC meeting at Jan. 11th

- Orijinal Mesaj - > Kimden: "Markus Zoeller" > Kime: "OpenStack Development Mailing List (not for usage questions)" > > Gönderilenler: 13 Ocak Çarşamba 2016 17:38:21 > Konu: Re: [openstack-dev] [nova] config options: IRC meeting at Jan. 11th > Esra Celik wrote on 01/13/2016 01:29:12 P

Re: [openstack-dev] [api][all] api variation release by release

On 01/12/2016 09:55 PM, Matt Riedemann wrote: Nova and Ironic already support microversioned APIs. Cinder and Neutron are working on it I think, and there could be others. just as a heads up, sahara is also working towards implementing microversions in its next api[1] regards, mike [1]: htt

[openstack-dev] [zuul][infra] Synchronizing state of Zuul with Gerrit

Today we had a change [0] that somehow weren't being picked up by Zuul to gate queue although it had Workflow+1 and Verified+1. Only after I added another Workflow+1 it did get Zuul's attention. I don't know what exactly happen, but it seems Zuul didn't notice (lost) either initial Verified+1 or Wo

[openstack-dev] [Cinder] [Ironic] Attach Cinder Volume to the Ironic Instance without Nova Step-by-Step guide

Hi team, In scope of 'use-cinder-without-nova' blueprint [1] I've created PoC code [2] with detailed instructions how to attach volumes inside Ironic or Nova instances. Detailed instructions could be found on my blog [3]. Any feedback are welcome! [1] https://github.com/openstack/cinder-specs/b

Re: [openstack-dev] [Heat] Status of the Support Conditionals in Heat templates

On 12/15/2015 12:07 PM, Fox, Kevin M wrote: My $0.02: heat as it is today, requires all users to be devops, and to carefully craft the templates launched specific to the cloud and the particular app they are trying to write. Making sharing code between heat users difficult. This means the potent

Re: [openstack-dev] [kolla] Can Heka solve all the deficiencies in the current rsyslog implementation: was Re: [kolla] Introduction of Heka in Kolla

Some random thoughts... I've been looking into how to log our production docker containers better, and a couple of things have shown up that may be of interest to you... 1, docker now has a journald backend. so rather then log to files, you just set your daemons to log to stdout, and docker+jou

[openstack-dev] [app-catalog] IRC Meeting Thursday January 14th at 17:00UTC

Join us tomorrow for our weekly meeting, January 14th at 17:00UTC in #openstack-meeting-3. The agenda can be found here, and please add to it if you want to get something on the agenda: https://wiki.openstack.org/wiki/Meetings/app-catalog Tomorrow we hope to have someone from Mistral joining to d

[openstack-dev] Shovel (RackHD/OpenStack)

Hi All, I'm pleased to announce a new application called 'Shovel 'that is now available in a public repository on GitHub (https://github.com/keedya/Shovel). Shovel is a server with a set of APIs that wraps around RackHD/Ironic's existing APIs allowing users to find Baremetal Compute nodes that

Re: [openstack-dev] Further closing the holes that let gate breakage happen

On 13 January 2016 at 11:24, Carl Baldwin wrote: > Hi, > > I was looking at the most recent gate breakage in Neutron [1], fixed > by [2]. This gate breakage was held off for some time by the > upper-constraints.txt file. This is great progress and I applaud it. > I'll continue to cheer on this

Re: [openstack-dev] [puppet] list of blockers to deploy mitaka

A quick update. CentOS jobs are all green. Ubuntu jobs are green for scenario002 and red for scenario001 because of [1] which will be resolved on Thursday 14th. The only remaining blocker is [2] and [3]. Please help to review these patches so we can bump our CI to Mitaka OpenStack codebase. [1]

Re: [openstack-dev] Shovel (RackHD/OpenStack)

On 01/13/2016 03:28 PM, Keedy, Andre wrote: Hi All, I’m pleased to announce a new application called ‘Shovel ‘that is now available in a public repository on GitHub (https://github.com/keedya/Shovel). Shovel is a server with a set of APIs that wraps around RackHD/Ironic’s existing APIs allowing

Re: [openstack-dev] [nova][libvirt] VIR_MIGRATE_NON_SHARED_INC works more like full copy in block migration ?

On 01/12/2016 05:35 AM, Kashyap Chamarthy wrote: On Sun, Jan 10, 2016 at 06:07:33PM +0800, Luo Gangyi wrote: Hi devs, Do you test the difference between within and without VIR_MIGRATE_NON_SHARED_INC ? When I add VIR_MIGRATE_NON_SHARED_INC in block_migration_flags in nova, nova block migratio

[openstack-dev] [nova][stable] Proposal to add Tony Breeds to nova-stable-maint

I'm formally proposing that the nova-stable-maint team [1] adds Tony Breeds to the core team. I don't have a way to track review status on stable branches, but there are review numbers from gerrit for stable/liberty [2] and stable/kilo [3]. I know that Tony does a lot of stable branch reviews

Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

On Wed, Jan 13, 2016 at 4:50 AM, Jakub Libosvar wrote: > Hi all, > > recently I was working on firewall driver [1] that requires latest > features in OVS, specifically conntrack support. In order to get the > driver tested, we need to have the latest OVS kernel modules on machines > running tests

Re: [openstack-dev] [openstack-ansible][security] Should the playbook stop on certain tasks?

I’m pretty new to openstack-ansible-security but based on my use cases which are as much About using this for verification as they are for building secure boxes my preference would be 3) Use an Ansible callback plugin to catch these and print them at the end of the playbook run -Rob On 13

Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

On 01/13/2016 03:59 PM, Assaf Muller wrote: > On Wed, Jan 13, 2016 at 4:50 AM, Jakub Libosvar wrote: >> Hi all, >> >> recently I was working on firewall driver [1] that requires latest >> features in OVS, specifically conntrack support. In order to get the >> driver tested, we need to have the lat

Re: [openstack-dev] Shovel (RackHD/OpenStack)

> -Original Message- > From: Jay Pipes [mailto:jaypi...@gmail.com] > Sent: Wednesday, January 13, 2016 8:53 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] Shovel (RackHD/OpenStack) > > On 01/13/2016 03:28 PM, Keedy, Andre wrote: > > Hi All, I'm pleased to annou

Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

On 01/13/2016 04:42 AM, Jamie Hannaford wrote: I've recently been gathering feedback about the Magnum API and one of the things that people commented on​ was the global /containers endpoints. One person highlighted the danger of UUID collisions: """ It takes a container ID which is intended to

Re: [openstack-dev] [puppet] list of blockers to deploy mitaka

On 01/13/2016 03:41 PM, Emilien Macchi wrote: > A quick update. > > CentOS jobs are all green. > Ubuntu jobs are green for scenario002 and red for scenario001 because of > [1] which will be resolved on Thursday 14th. > > The only remaining blocker is [2] and [3]. > > Please help to review thes

Re: [openstack-dev] [nova][stable] Proposal to add Tony Breeds to nova-stable-maint

On 01/13/2016 03:59 PM, Matt Riedemann wrote: > I'm formally proposing that the nova-stable-maint team [1] adds Tony > Breeds to the core team. > > I don't have a way to track review status on stable branches, but there > are review numbers from gerrit for stable/liberty [2] and stable/kilo [3]. >

Re: [openstack-dev] Further closing the holes that let gate breakage happen

On 01/13/2016 03:41 PM, Armando M. wrote: > > > On 13 January 2016 at 11:24, Carl Baldwin > wrote: > > Hi, > > I was looking at the most recent gate breakage in Neutron [1], fixed > by [2]. This gate breakage was held off for some time by the > upper

Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

> -Original Message- > From: Russell Bryant [mailto:rbry...@redhat.com] > Sent: Wednesday, January 13, 2016 9:19 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [neutron] Testing Neutron with latest OVS > > On 01/13/2016 03:59 PM, Assaf

Re: [openstack-dev] Shovel (RackHD/OpenStack)

Hey Jay! (yeah, I’m here and lurking in the corners, albeit with a different email at the moment) Yep - RackHD was created by a company that was acquired by EMC to attack the lowest-level of hardware automation. EMC was interesting in pushing that into Open Source, and surprisingly I was completel

Re: [openstack-dev] [all] re-introducing twisted to global-requirements

On 8 January 2016 at 08:09, Jim Rollenhagen wrote: > Hi all, > > A change to global-requirements[1] introduces mimic, which is an http > server that can mock various APIs, including nova and ironic, including > control of error codes and timeouts. The ironic team plans to use this > for testing py

Re: [openstack-dev] [infra][all] "openstack-meeting-cp" == "openstack-meeting-5"?

On Wed, Jan 13, 2016 at 12:11:27PM +0100, Thierry Carrez wrote: > One possible solution here would be to check if the meetings currently > scheduled on your ideal slots are actually still using the spot, as there > are a non-trivial amount of dead meetings around. You can ping me on IRC so > that

Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

On Wed, Jan 13, 2016 at 03:57:37PM CST, Mooney, Sean K wrote: > One of the ideas that I have been thinking about over the last month or two > is do we > Want to create a dedicated library file in devstack to support compilation > and installation > Of ovs. So, my suggestion is as follows: creat

Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

On Wed, Jan 13, 2016 at 04:47:19PM CST, Sean M. Collins wrote: > I'd prefer to see small, very specific DevStack plugins that have narrow > focus, and jobs that need them for specific things adding them to their > local.conf settings explicitly via enable_repo lines. Sorry, enable_plugin lines -

[openstack-dev] [nova][cinder] How will nova advertise that volume multi-attach is supported?

tl;dr - do we need a REST API microversion for multi-attach support in nova? The details: The volume multi-attach series in nova, starting here [1], has run into an upgrade problem. Basically, there is code in liberty which doesn't pass an instance uuid and volume id to the block_device_mapp

Re: [openstack-dev] [oslo][osdk] PrettyTable needs a home in OpenStack

On 11 January 2016 at 10:27, Doug Hellmann wrote: > ... > > > There are a few libraries on the list, too (automaton, ironic-lib), and > that's confusing. It would be interesting to know how they're using > table output. > > Doug > > As far as ironic-lib goes, I took a look. It isn't using PrettyT

Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

Hi Jamie, I would like to clarify several things. First, a container uuid is intended to be unique globally (not within individual cluster). If you create a container with duplicated uuid, the creation will fail regardless of its bay. Second, you are in control of the uuid of the container tha

  1   2   >