Re: [openstack-dev] [nova][neutron] New BP for live migration with direct pci passthru

Ping... -Original Message- From: Xie, Xianshan [mailto:[email protected]] Sent: Tuesday, February 02, 2016 7:12 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova][neutron] New BP for live migration with direct pci passthru Hi, all,

Re: [openstack-dev] [TripleO] Stable branch policy for Mitaka

On Wed, Feb 10, 2016 at 07:05:41PM +0100, James Slagle wrote: >On Wed, Feb 10, 2016 at 4:57 PM, Steven Hardy wrote: > > Hi all, > > We discussed this in our meeting[1] this week, and agreed a ML > discussion > to gain consensus and give folks visibility of the outcome wou

[openstack-dev] [Swift] Erasure coding and geo replication

After looking at: https://www.youtube.com/watch?v=9YHvYkcse-k I have a question (that follows on from Bruno's) about using erasure coding with geo replication. Now the example given to show why you could/should not use erasure coding with geo replication is somewhat flawed as it is immediate

[openstack-dev] [neutron][dnsmasq]DNS redirection by dnsmasq

hi, guys. Most of us know about DNS redirection. I think that we can implement DNS redirection in Neutron. In dnsmasq, there is a option named "--cname"(http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html), we can use this option to implement this function. What about your id

Re: [openstack-dev] [tripleO][Neutron] Appropriate location for networking-* pythonclient extensions

On Mon, Feb 15, 2016 at 12:26:13AM +0500, Fawad Khaliq wrote: >Hi Triple-O folks, >I am trying to understand how the notion of overcloud and undercloud would >play with the Neutron subprojects. Neutron has sub-projects like >networking-l2gw [1], networking-bgpvpn [2] etc, which have

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

Le 15/02/2016 06:21, Cheng, Yingxin a écrit : Hi, I’ve uploaded a prototype https://review.openstack.org/#/c/280047/ to testify its design goals in accuracy, performance, reliability and compatibility improvements. It will also be an Austin Summit

Re: [openstack-dev] [all][tc] Proposal: Separate design summits from OpenStack conferences

> > Honestly I don't know of any communication between two cores at a +2 > > party that couldn't have just as easily happened surrounded by other > > contributors. Nor, I hope, does anyone put in the substantial > > reviewing effort required to become a core in order to score a few > > free beers

Re: [openstack-dev] [tripleO][Neutron] Appropriate location for networking-* pythonclient extensions

Hi Steve, Thanks a lot for the detailed response. On Mon, Feb 15, 2016 at 2:15 PM, Steven Hardy wrote: > On Mon, Feb 15, 2016 at 12:26:13AM +0500, Fawad Khaliq wrote: > >Hi Triple-O folks, > >I am trying to understand how the notion of overcloud and undercloud > would > >play with t

Re: [openstack-dev] [Fuel] Nominate Fedor Zhadaev for the fuel-menu-core team

Well, voting period is over and there's no objections from cores. So I'm going to add Fedor to fuel-menu-core group. Congrats Fedor! :) On Mon, Feb 8, 2016 at 2:34 PM, Aleksey Kasatkin wrote: > +1 > > > Aleksey Kasatkin > > > On Mon, Feb 8, 2016 at 12:04 PM, Tatyana Leontovich > wrote: >> >> +1

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

Thanks Sylvain, 1. The below ideas will be extended to a spec ASAP. 2. Thanks for providing concerns I've not thought it yet, they will be in the spec soon. 3. Let me copy my thoughts from another thread about the integration with resource-provider: The idea is about "Only compute node knows i

Re: [openstack-dev] [Fuel] Nominate Fedor Zhadaev for the fuel-menu-core team

Thank you! -- Kind Regards, Fedor Zhadaev skype: zhadaevfm IRC: fzhadaev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.

Re: [openstack-dev] [Fuel] Nominate Fedor Zhadaev for the fuel-menu-core team

Congrats! On Mon, Feb 15, 2016 at 1:08 PM, Fedor Zhadaev wrote: > Thank you! > -- > Kind Regards, > Fedor Zhadaev > > skype: zhadaevfm > IRC: fzhadaev > > __ > OpenStack Development Mailing List (not for usage questions) >

[openstack-dev] [Bareon] Weekly update

Hi, After the discussion with some folks, we agreed that it might be useful for the community to start sending weekly updates on what Bareon team is working on and what is our progress. So here is a first weekly update from Bareon team. 1. Data pipelines for Nailgun integration (changing provisi

Re: [openstack-dev] [Nova] Update on live migration priority

On Fri, Feb 12, 2016 at 04:21:27PM +, Murray, Paul (HP Cloud) wrote: > This time with a tag in case anyone is filtering... Yep, I was filtering, and would've missed it without your tag. :-) > From: Murray, Paul (HP Cloud) > Sent: 12 February 2016 16:16 > To: [email protected]

Re: [openstack-dev] [Swift] Erasure coding and geo replication

Hello Mark, AFAIK, a few reasons for that we still are in working progress for erasure code + geo replication. >> and expect to survive a region outage... >> >> With that I mind I did some experiments (Liberty swift) and it looks to me >> like if you have: >> >> - num_data_frags < num_nodes in

Re: [openstack-dev] [Horizon][Trove] Horizon-Trove External Repository

Hi, Is there proper documentation how to add localization for external plugins that use AngularJS? Thanks, Omer Etrog Vitrage Team     From: Thai Q Tran [mailto:[email protected]] Sent: Thursday, December 03, 2015 11:44 PM To: [email protected] Cc: Vince Brunssen Subject: [openst

Re: [openstack-dev] [Horizon][Trove] Horizon-Trove External Repository

On 2016-02-15 11:32, Omer (Nokia - IL) Etrog wrote: > Hi, > Is there proper documentation how to add localization for external plugins > that use AngularJS? http://docs.openstack.org/infra/manual/creators.html#enabling-translation-infrastructure Note that the translation team only translates of

Re: [openstack-dev] [Fuel] Nominate Fedor Zhadaev for the fuel-menu-core team

Well done, Fedor! Congrats! -Dmitry. On Mon, Feb 15, 2016 at 1:12 PM, Maksim Malchuk wrote: > Congrats! > > > On Mon, Feb 15, 2016 at 1:08 PM, Fedor Zhadaev > wrote: > >> Thank you! >> -- >> Kind Regards, >> Fedor Zhadaev >> >> skype: zhadaevfm >> IRC: fzhadaev >> >> __

Re: [openstack-dev] Octavia (LBaaS) license question

OpenStack is using KVM and Linux as reference implementation, both are GPL. From: Gal Sagie [mailto:[email protected]] Sent: Sunday, February 14, 2016 8:47 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] Octavia (LBaaS) license question Hello All, I

[openstack-dev] [ironic] Baremetal Deploy Ramdisk functional testing

Re-sending with Ironic stamp… Folks, please see below: > > Hi All, > > In bareon [1] we have test framework to test deploy ramdsik with bareon > inside (baremetal deployments). This is a functional testing, we do a full > partitioning/image_deployment in a VM, then reboot to see if tenant ima

Re: [openstack-dev] [TripleO] Stable branch policy for Mitaka

On 02/15/2016 03:59 AM, Steven Hardy wrote: > On Wed, Feb 10, 2016 at 07:05:41PM +0100, James Slagle wrote: >>On Wed, Feb 10, 2016 at 4:57 PM, Steven Hardy wrote: >> >> Hi all, >> >> We discussed this in our meeting[1] this week, and agreed a ML >> discussion >> to gain c

[openstack-dev] [Kuryr] IRC Meeting today (2/15) - 1500 UTC

Hello All We will have an IRC meeting today (Monday, 2/15) at 1500 UTC in #openstack-meeting-4 Please review the expected meeting agenda here: https://wiki.openstack.org/wiki/Meetings/Kuryr You can view last meeting action items and logs here: http://eavesdrop.openstack.org/meetings/kuryr/2016/k

Re: [openstack-dev] [nova][glance][barbican][kite][requirements] pycrypto vs pycryptodome

2016-02-14 23:16 GMT+01:00 Davanum Srinivas : > Hi, > > Short Story: > pycryptodome if installed inadvertently will break several projects: > Example : https://review.openstack.org/#/c/279926/ > > Long Story: > There's a new kid in town pycryptodome: > https://github.com/Legrandin/pycryptodome > >

Re: [openstack-dev] [all] Any projects using sqlalchemy-utils?

On Fri, Feb 12 2016, Corey Bryant wrote: > taskflow started using it recently, however it's only needed for a single > type in taskflow (JSONType). I'm wondering if it's worth the effort of > maintaining it and it's dependencies in Ubuntu main or if perhaps we can > just revert this bit to define

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

We have weekly Nova API meeting tomorrow. The meeting is being held Tuesday UTC1200. The proposed agenda and meeting details are here: https://wiki.openstack.org/wiki/Meetings/NovaAPI Please feel free to add items to the agenda. Thanks ___

Re: [openstack-dev] [nova][glance][barbican][kite][requirements] pycrypto vs pycryptodome

On 14/02/16 17:16 -0500, Davanum Srinivas wrote: Hi, Short Story: pycryptodome if installed inadvertently will break several projects: Example : https://review.openstack.org/#/c/279926/ Long Story: There's a new kid in town pycryptodome: https://github.com/Legrandin/pycryptodome Because pycryp

Re: [openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?

On Fri, 12 Feb 2016, Doug Wiegley wrote: It hurts discoverability, and “expectedness”. If I’m new to openstack, having it default boot unusable just means the first time I use ’nova boot’, I’ll end up with a useless VM. People don’t read docs first, it should “just work” as far as that’s sane. A

Re: [openstack-dev] [all] Any projects using sqlalchemy-utils?

On Mon, Feb 15, 2016 at 7:57 AM, Julien Danjou wrote: > On Fri, Feb 12 2016, Corey Bryant wrote: > > > taskflow started using it recently, however it's only needed for a single > > type in taskflow (JSONType). I'm wondering if it's worth the effort of > > maintaining it and it's dependencies in

Re: [openstack-dev] [magnum]swarm + compose = k8s?

Hi all, A few thoughts to add: I like the idea of isolating the masters so that they are not tenant-controllable, but I don't think the Magnum control plane is the right place for them. They still need to be running on tenant-owned resources so that they have access to things like isolated tenant

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

Le 15/02/2016 10:48, Cheng, Yingxin a écrit : Thanks Sylvain, 1. The below ideas will be extended to a spec ASAP. Nice, looking forward to it then :-) 2. Thanks for providing concerns I’ve not thought it yet, they will be in the spec soon. 3. Let me copy my thoughts from another threa

Re: [openstack-dev] [magnum] Re: Assistance with Magnum Setup

Hi Hongbin, There is an online dev-quickstart guide that I have been using to install Magnum. This guide is intended to install magnum with devstack however the guide seems to not include all the information needed to connect magnum, Barbican and keystone which is where my problems are showing

[openstack-dev] [keystone] Testing schema migrations was RE: [grenade][keystone] Keystone multinode grenade

> From: Morgan Fainberg [mailto:[email protected]] >> >> Keystone stable working with master db seems like an interesting bit, are >> there already tests for that? > >Not yet. Right now there is only a unit test, checking obvious >incompatibilities. > > As an FYI, this test was reverted

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/15/2016 03:27 AM, Sylvain Bauza wrote: > - can we have the feature optional for operators One thing that concerns me is the lesson learned from simply having a compute node's instance information sent and persisted in memory. That was resiste

[openstack-dev] [fuel] Move virtualbox scripts to a separate directory

Dear colleagues, I'd like to announce that we are next to moving fuel-main/virtualbox directory to a separate git repository. This directory contains a set of bash scripts that could be used to easily deploy Fuel environment and try to deploy OpenStack cluster using Fuel. Virtualbox is used as a v

[openstack-dev] [Fuel][QA] New runner for fuel-qa system tests

Hi all! Please be informed that we merged a new runner for fuel-qa system tests [1] : run_system_test.py Features of new runner: - auto discovering all test in both test suites ([2] and [3]) - show the groups from the test suites - explain content of groups - run the several groups at the same t

Re: [openstack-dev] [all] tenant vs. project

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/12/2016 07:40 PM, Adam Young wrote: > Tenant never quite made sense to me. A tenant is the person that > occupies an apartment or building, but not the building itself. For public clouds, where you have customers sharing resources on the sam

Re: [openstack-dev] [Horizon] eslint without color?

On 2016-02-15 16:45:09 +1100 (+1100), Richard Jones wrote: > I'm just curious why our eslint configuration (in packages.json) > specifies --no-color. It's much harder to spot the errors without > color, and I always end up running it manually to get the color. > Also, karma output has color, so why

Re: [openstack-dev] [all][tc] Proposal: Separate design summits from OpenStack conferences

On Mon, 2016-02-15 at 04:36 -0500, Eoghan Glynn wrote: > > > > Honestly I don't know of any communication between two cores at a > > > +2 party that couldn't have just as easily happened surrounded by > > > other contributors. Nor, I hope, does anyone put in the > > > substantial reviewing effor

[openstack-dev] [puppet] weekly meeting #70

Hello We'll have our weekly meeting tomorrow at 3pm UTC on #openstack-meeting4. https://wiki.openstack.org/wiki/Meetings/PuppetOpenStack As usual, free free to bring topics in this etherpad: https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160216 We'll also have open discussio

Re: [openstack-dev] [all][tc] Proposal: Separate design summits from OpenStack conferences

On 2016-02-15 04:36:25 -0500 (-0500), Eoghan Glynn wrote: [...] > Traditionally all ATCs earn a free pass for summit, whereas the > other attendees pay $600 or more for entry. I'm wondering if (a) > there's some cross-subsidization going on here and (b) if the > design summit was cleaved off, would

Re: [openstack-dev] [HA][RabbitMQ][messaging][Pacemaker][operators] Improved OCF resource agent for dynamic active-active mirrored clustering

Hello! A quick status update inline: On 23.10.2015 10:01, Bogdan Dobrelya wrote: > Hello. > I'm glad to announce that the pacemaker OCF resource agent for the > rabbitmq clustering, which was born in the Fuel project initially, now > available and maintained upstream! It will be shipped with the >

Re: [openstack-dev] [fuel] Fuel plugins: lets have some rules

Dmitry, So this changes the workflow for the devopses, the fuel plugin repo creators under Openstack namespace. As I understand, development of every new fuel plugin must be now started in a private github repo first, and when a developer(s) decide they want to go level higher they request for

Re: [openstack-dev] [all][tc] Proposal: Separate design summits from OpenStack conferences

On Feb 15, 2016, at 7:59 AM, Jeremy Stanley wrote: > >> On 2016-02-15 04:36:25 -0500 (-0500), Eoghan Glynn wrote: >> [...] >> Traditionally all ATCs earn a free pass for summit, whereas the >> other attendees pay $600 or more for entry. I'm wondering if (a) >> there's some cross-subsidization goi

[openstack-dev] [neutron] Mitaka Mid-Cycle Coding Sprint Registration

Hi folks! The mid-cycle is almost upon us. IBM, as the sponsor company, is requesting some information from everyone is registered (name, email, company, US citizen or not), so please make sure to register on the Eventbrite site I've created here [1]. If everyone who's attending could please do th

[openstack-dev] [puppet] Push Mitaka beta tag

Hi, While Puppet modules releases are independently managed, we have some requests from both RDO & Debian folks to push a first tag in our Puppet modules, for Mitaka release, so they can start provide Mitaka packaging based on tag, and not on commits. This is something we never did before, usuall

Re: [openstack-dev] [oslo][all] Announcing our new Olso Project

For the #OpenStack Mitaka M3 freeze and final release we have made it even easier to play and win Oslo Bingo. Simply pick the next release word. Free entry at http://j.mp/Oslo-bingo-Mitaka Follow the results on Twitter - https://twitter.com/OsloBingo Ronald Bradford Web Site: http://ronaldbradfo

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

On 13.02.2016 02:42, Carl Baldwin wrote: > On Fri, Feb 12, 2016 at 5:01 AM, Ihar Hrachyshka wrote: It is only internal implementation changes. That's not entirely true, is it? There are config variables to change and it opens up the possibility of a scenario that the operator m

Re: [openstack-dev] [neutron] Mitaka Mid-Cycle Coding Sprint Registration

On 02/15/2016 04:06 PM, Kyle Mestery wrote: > Hi folks! > > The mid-cycle is almost upon us. IBM, as the sponsor company, is > requesting some information from everyone is registered (name, email, > company, US citizen or not), so please make sure to register on the > Eventbrite site I've created

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

Fuelers, Task based deployment engine has been enabled in master (Fuel 9.0) by default [0] [0] - https://review.openstack.org/#/c/273693/ WBR, Alexey Shtokolov 2016-02-09 21:57 GMT+03:00 Vladimir Kuklin : > Folks > > It seems that docker removal spoilt our celebration a bit. Here is a bug > li

[openstack-dev] [mistral] Mistral team meeting minutes

Thank you for attending the meeting today! Next meeting is scheduled on 22 Feb. It is non-working day in Russia so Renat, Anastasia and I very likely won't come to the meeting. Minutes: http://eavesdrop.openstack.org/meetings/mistral/2016/mistral.2016-02-15-16.00.html Log: http://eavesdrop.opens

Re: [openstack-dev] [neutron] Mitaka Mid-Cycle Coding Sprint Registration

On Mon, Feb 15, 2016 at 10:33 AM, Anita Kuno wrote: > On 02/15/2016 04:06 PM, Kyle Mestery wrote: >> Hi folks! >> >> The mid-cycle is almost upon us. IBM, as the sponsor company, is >> requesting some information from everyone is registered (name, email, >> company, US citizen or not), so please m

[openstack-dev] [Monasca] Alarm generation from a sequence of events

Hello, We come across the following interesting BP in the last weekly meeting: https://blueprints.launchpad.net/monasca/+spec/alarmsonlogs Understood how the non-periodic nature of log events to be taken care of (by introducing period = -1 in value-meta). Just wondering can it be possible to

[openstack-dev] [cross-project] Meeting, Tue February 16th, 21:00 UTC

Hi all, We will be having a meeting tomorrow February 16th at 21:00 UTC in the #openstack-meeting-cp channel. * Team announcements (horizontal, vertical, diagonal) * A Common Policy Scenario Across All Projects [1] * Support for 4-byte unicode for naming volume, snapshot, instance etc.(sheel,

Re: [openstack-dev] [Horizon][Trove] Horizon-Trove External Repository

Great article Andreas!   For angular translation to work, you'll need to reference https://github.com/openstack/horizon/blob/master/horizon/utils/babel_extract_angular.py which the guide already covers.   To use it, see https://angular-gettext.rocketeer.be/dev-guide/annotate/ for examples.    

[openstack-dev] [barbican] Nominating Fernando Diaz for Barbican Core

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi All, I would like to nominate Fernando Diaz for the Barbican Core team. Fernando has been an enthusiastic contributor since joining the Barbican team. He is currently the most active non-core reviewer on Barbican projects for the last 90 days. [

Re: [openstack-dev] [barbican] Nominating Fernando Diaz for Barbican Core

+1 ! On Mon, Feb 15, 2016 at 7:45 PM, Douglas Mendizábal < [email protected]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hi All, > > I would like to nominate Fernando Diaz for the Barbican Core team. > Fernando has been an enthusiastic contributor since joining

Re: [openstack-dev] [magnum]swarm + compose = k8s?

Regarding to the COE mode, it seems there are three options: 1. Place both master nodes and worker nodes to user’s tenant (current implementation). 2. Place only worker nodes to user’s tenant. 3. Hide both master nodes and worker nodes from user’s tenant. Frankly, I don’t kno

Re: [openstack-dev] [puppet] Push Mitaka beta tag

Emilien, More tags like this cannot hurt, it makes it easier to follow things, thanks for doing this. On Mon, Feb 15, 2016 at 9:13 AM, Emilien Macchi wrote: > Hi, > > While Puppet modules releases are independently managed, we have some > requests from both RDO & Debian folks to push a first ta

Re: [openstack-dev] [puppet] Push Mitaka beta tag

So is it implied that a version "8.0.0b1" of a puppet module works with the "8.0.0b1" of it's parent project ? This has some implications, it means there are expectations that puppet-openstack is able to keep up with upstream changes throughout the cycle. We've gotten pretty good at following trun

Re: [openstack-dev] [nova][glance][barbican][kite][requirements] pycrypto vs pycryptodome

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I had not previously heard of pycryptodome. Is this supposed to be a drop-in replacement for pycrypto? If so then it sounds like they're doing a terrible job of it. The plan for Barbican has been to wait for pyca/cryptography [1] to add support for

Re: [openstack-dev] [nova][glance][barbican][kite][requirements] pycrypto vs pycryptodome

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 One more thing: I forgot to point out that pyca/cryptography is already part of global-requirements. [1] - - Douglas Mendizábal [1] http://git.openstack.org/cgit/openstack/requirements/tree/global-require ments.txt#n25 On 2/15/16 12:24 PM, Douglas

Re: [openstack-dev] [barbican] Nominating Fernando Diaz for Barbican Core

+1 On 2/15/16, 12:45 PM, "Douglas Mendizábal" wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA512 > >Hi All, > >I would like to nominate Fernando Diaz for the Barbican Core team. >Fernando has been an enthusiastic contributor since joining the >Barbican team. He is currently the most activ

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

Aleksey, great news! On Mon, Feb 15, 2016 at 7:36 PM, Alexey Shtokolov wrote: > Fuelers, > > Task based deployment engine has been enabled in master (Fuel 9.0) by > default [0] > > [0] - https://review.openstack.org/#/c/273693/ > > WBR, Alexey Shtokolov > > 2016-02-09 21:57 GMT+03:00 Vladimir Ku

[openstack-dev] [TripleO] Thoughts about the relationship between RDO and TripleO

Howdy, The spec to replace instack-virt-setup[1] got me thinking about the relationship between RDO and TripleO. Specifically, when thinking about where to store/create an undercloud.qcow2 image, and if this effort is worth duplicating. Originally, I agreed with the comments on the spec wrt the f

[openstack-dev] [cinder][all] Integration python-*client tests on gates

Hi all, I'll talk mostly about python-cinderclient but the same question could be related for other clients. Now, for python-cinderclient we've got to kinds for functional/integrated jobs: 1) gate-cinderclient-dsvm-functional - a very limited (for now) set of functional tests, most of them were

Re: [openstack-dev] [TripleO] Thoughts about the relationship between RDO and TripleO

On Mon, Feb 15, 2016 at 2:05 PM, John Trowbridge wrote: > Howdy, > > The spec to replace instack-virt-setup[1] got me thinking about the > relationship between RDO and TripleO. Specifically, when thinking about > where to store/create an undercloud.qcow2 image, and if this effort is > worth duplic

Re: [openstack-dev] Google Sumer of Code 2016 - Call for ideas and mentors (deadline 19/02/2016)

Friendly reminder, we are still looking for mentors and internship ideas. Join us [0] and submit your internship project ideas in [1]. The deadline for our application as mentoring organization is 19/02/2016 [0] https://wiki.openstack.org/wiki/GSoC2016 [1] https://wiki.openstack.org/wiki/Internsh

Re: [openstack-dev] [cinder][all] Integration python-*client tests on gates

On Mon, Feb 15, 2016, at 11:48 AM, Ivan Kolodyazhny wrote: > Hi all, > > I'll talk mostly about python-cinderclient but the same question could be > related for other clients. > > Now, for python-cinderclient we've got to kinds for functional/integrated > jobs: > > 1) gate-cinderclient-dsvm-func

Re: [openstack-dev] [nova][glance][barbican][kite][requirements] pycrypto vs pycryptodome

Douglas, Which means we should make sure pysaml2 and paramiko do switch to the " pyca/cryptography" ASAP. However, what do we do in the mean time? -- Dims On Mon, Feb 15, 2016 at 1:30 PM, Douglas Mendizábal wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > One more thing: I forgot

Re: [openstack-dev] [barbican] Nominating Fernando Diaz for Barbican Core

+1 He is a great addition to the Barbican community. -Nate On Mon, Feb 15, 2016 at 1:34 PM, Dave McCowan (dmccowan) wrote: > +1 > > On 2/15/16, 12:45 PM, "Douglas Mendizábal" > wrote: > >>-BEGIN PGP SIGNED MESSAGE- >>Hash: SHA512 >> >>Hi All, >> >>I would like to nominate Fernando Diaz

Re: [openstack-dev] [ironic] Baremetal Deploy Ramdisk functional testing

On Mon, Feb 15, 2016 at 01:48:11PM +0200, Maksym Lobur wrote: > Re-sending with Ironic stamp… Folks, please see below: Hi, I meant to reply to this earlier, but didn't get to it, sorry for that. > > > > > Hi All, > > > > In bareon [1] we have test framework to test deploy ramdsik with bareon

Re: [openstack-dev] [puppet] Push Mitaka beta tag

On 02/15/2016 01:16 PM, David Moreau Simard wrote: > So is it implied that a version "8.0.0b1" of a puppet module works > with the "8.0.0b1" of it's parent project ? No, releases are not synced with OpenStack projects. The only thing we currently guarantee is that 8.0.0b1 will work with what our

Re: [openstack-dev] [TripleO] Thoughts about the relationship between RDO and TripleO

On 02/15/2016 02:50 PM, James Slagle wrote: > On Mon, Feb 15, 2016 at 2:05 PM, John Trowbridge wrote: >> Howdy, >> >> The spec to replace instack-virt-setup[1] got me thinking about the >> relationship between RDO and TripleO. Specifically, when thinking about >> where to store/create an undercl

[openstack-dev] Reminder/request for cross-project stable CPLs to be in #openstack-stable IRC

This came up in today's stable team meeting, but cross-project liaisons for stable branches [1] should be available in the #openstack-stable IRC channel. By default if a project doesn't have a stable CPL, then the PTL is the rep. This is more or less just to improve communication between the s

Re: [openstack-dev] [all][requirements] Why do we use pip install -U as our install_command

On 11 February 2016 at 16:09, Clark Boylan wrote: > The reason that I remember off the top of my head is because we spent > far too much time telling people to run `tox -r` when their code failed > during Jenkins testing but ran just fine locally. It removes a > significant amount of debugging ove

Re: [openstack-dev] Proposal: Separate design summits from OpenStack conferences

I think this will be very detrimental to development community. The best feedback we get is from user/customer community that are at the summit but most likely will not attend separate design summit. I will ignore financial implication of 2 separate summits. -Original Message- From: Eogh

Re: [openstack-dev] [Nova][Glance]Glance v2 api support in Nova

On 12/02/16 18:24 +0300, Mikhail Fedosin wrote: Hello! In late December I wrote several messages about glance v2 support in Nova and Nova's xen plugin. Many things have been done after that and now I'm happy to announce that there we have a set of commits that makes Nova fully v2 compatible (xen

Re: [openstack-dev] [TripleO] Stable branch policy for Mitaka

I like any formal documented process. Having only bug fixes for stable releases is a good and consistent stand. But we are bumping into fundamental issue of integrated release. By the time release comes out the new functionality of nova, or neutron or most other components do not triple heat temp

[openstack-dev] [Nova][API] Does nova API allow the server_id parem as DB index?

I guess others may ask the same questions. I read the nova API doc: such as this API: http://developer.openstack.org/api-ref-compute-v2.1.html#showServer GET /v2.1/​{tenant_id}​/servers/​{server_id}​ *Show server details* *Request parameters* ParameterStyleTypeDescription tenant_id URI csapi:UU

[openstack-dev] [OpenStack-Ansible] Meetings this week

Hi everyone, Due to being active at the Ops Mid Cycle, the OpenStack-Ansible Mid Cycle and Ansiblefest this week the bug triage and community meetings this week will not be taking place. We'll resume the normal scheduled meetings next week. Thanks, Jesse IRC: odyssey4me

[openstack-dev] [tricircle] weekly meeting of Feb.17th

Hi, After the Chinese new year festival, let's resume the weekly meeting, and agenda as following. Agenda: # Progress of To-do list review: https://etherpad.openstack.org/p/TricircleToDo # SEG # Quota management # exception logging, flavor mapping # Pod scheduling # L2 networking across pods Be

Re: [openstack-dev] [Nova] Should we signal backwards incompatible changes in microversions?

Regards Ghanshyam Mann On Mon, Feb 15, 2016 at 12:07 PM, Alex Xu wrote: > If we support 2.x.y, when we bump 'x' is a problem. We didn't order the API > changes for now, the version of API change is just based on the order of > patch merge. For support 2.x.y, we need bump 'y' first for back-compa

[openstack-dev] [release][oslo] futurist 0.12.0 release (mitaka)

We are delighted to announce the release of: futurist 0.12.0: Useful additions to futures, from the future. This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/futurist With package available at: https://pypi.python.org/

[openstack-dev] [release][oslo] oslo.db 4.5.0 release (mitaka)

We are glad to announce the release of: oslo.db 4.5.0: Oslo Database library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.db With package available at: https://pypi.python.org/pypi/oslo.db Please report issu

[openstack-dev] [release][oslo] oslo.privsep 1.1.0 release (mitaka)

We are thrilled to announce the release of: oslo.privsep 1.1.0: OpenStack library for privilege separation This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.privsep With package available at: https://pypi.python.o

[openstack-dev] [release][oslo] oslo.log 3.0.0 release (mitaka)

We are content to announce the release of: oslo.log 3.0.0: oslo.log library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.log With package available at: https://pypi.python.org/pypi/oslo.log Please report iss

[openstack-dev] [release][oslo] oslo.rootwrap 4.0.0 release (mitaka)

We are amped to announce the release of: oslo.rootwrap 4.0.0: Oslo Rootwrap This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.rootwrap With package available at: https://pypi.python.org/pypi/oslo.rootwrap Please

[openstack-dev] [release][oslo] oslo.service 1.5.0 release (mitaka)

We are pleased to announce the release of: oslo.service 1.5.0: oslo.service library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.service With package available at: https://pypi.python.org/pypi/oslo.service P

[openstack-dev] [release][oslo] oslo.config 3.7.0 release (mitaka)

We are jazzed to announce the release of: oslo.config 3.7.0: Oslo Configuration API This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.config With package available at: https://pypi.python.org/pypi/oslo.config Ple

[openstack-dev] [release][oslo] oslo.reports 1.5.0 release (mitaka)

We are jubilant to announce the release of: oslo.reports 1.5.0: oslo.reports library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.reports With package available at: https://pypi.python.org/pypi/oslo.reports

[openstack-dev] [release][oslo] oslo.utils 3.6.0 release (mitaka)

We are satisfied to announce the release of: oslo.utils 3.6.0: Oslo Utility library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.utils With package available at: https://pypi.python.org/pypi/oslo.utils Pleas

[openstack-dev] [release][oslo] oslo.vmware 2.4.0 release (mitaka)

We are stoked to announce the release of: oslo.vmware 2.4.0: Oslo VMware library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.vmware With package available at: https://pypi.python.org/pypi/oslo.vmware Please

[openstack-dev] [release][oslo] osprofiler 1.1.0 release (mitaka)

We are happy to announce the release of: osprofiler 1.1.0: OpenStack Profiler Library This release is part of the mitaka release series. With package available at: https://pypi.python.org/pypi/osprofiler For more details, please see below. Changes in osprofiler 1.0.1..1.1.0 --

[openstack-dev] [release][oslo] oslo.versionedobjects 1.6.0 release (mitaka)

We are pleased to announce the release of: oslo.versionedobjects 1.6.0: Oslo Versioned Objects library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.versionedobjects With package available at: https://pypi.pyt

[openstack-dev] [release][oslo] taskflow 1.28.0 release (mitaka)

We are pleased to announce the release of: taskflow 1.28.0: Taskflow structured state management library. This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/taskflow With package available at: https://pypi.python.org/py

[openstack-dev] [release][oslo] oslo.messaging 4.3.0 release (mitaka)

We are pumped to announce the release of: oslo.messaging 4.3.0: Oslo Messaging API This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.messaging With package available at: https://pypi.python.org/pypi/oslo.messaging

[openstack-dev] [release][oslo] tooz 1.31.0 release (mitaka)

We are stoked to announce the release of: tooz 1.31.0: Coordination library for distributed systems. This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/tooz With package available at: https://pypi.python.org/pypi/tooz

Re: [openstack-dev] [Nova][API] Does nova API allow the server_id parem as DB index?

On Mon, Feb 15, 2016 at 6:03 PM, 少合冯 wrote: > I guess others may ask the same questions. > > I read the nova API doc: > such as this API: > http://developer.openstack.org/api-ref-compute-v2.1.html#showServer > > GET /v2.1/​{tenant_id}​/servers/​{server_id}​ > *Show server details* > > > *Request

Re: [openstack-dev] [nova][all] Deprecation policy between projects

On 14/02/2016 8:32 AM, Ken'ichi Ohmichi wrote: > Hi, > > Do we have any deprecation policies between projects? > When we can remove old drivers of the other projects after they were > marked as deprecated? > In nova, there are many drivers for the other projects and there are > patches which remo

Re: [openstack-dev] [Nova][API] Does nova API allow the server_id parem as DB index?

I don't think our API supports get servers by DB index is good idea. So I prefer we remove it in the future with microversions. But for now, yes, it is here. 2016-02-16 8:03 GMT+08:00 少合冯 : > I guess others may ask the same questions. > > I read the nova API doc: > such as this API: > http://deve

  1   2   >