Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

Igor, It seems you are proposing an IKEA approach to plugins. Take Fuel's example plugin, add in the current Fuel release, and then build it. We maintained these plugins in the past, but now it should a manual step to test it out on the current release. What would be a more ideal situation that

[openstack-dev] [glance] Remove `run_tests.sh` and `tools/*`

Hey Folks, I'm looking at doing some cleanups in our repo and I would like to start by deprecating the `run_tests` script and the contents in the `tools/` dir. As far as I can tell, no one is using this code - we're not even using it in the gate - as it was broken until recently, I believe. The

Re: [openstack-dev] [all][i18n] Liaisons for I18n

Tony Breeds wrote: On Mon, Feb 29, 2016 at 05:26:44PM +0800, Ying Chun Guo wrote: If you are interested to be a liaison and help translators, input your information here: https://wiki.openstack.org/wiki/CrossProjectLiaisons#I18n . So

[openstack-dev] [Manila] Concurrent execution of drivers

Hi, What expectations should driver authors have about multiple instances of the driver being instantiated within different instances of manila-share? For example, should I assume that when one instance of a driver is having ensure_share called during startup, another instance of the driver

Re: [openstack-dev] [glance] Remove `run_tests.sh` and `tools/*`

> Hey Folks, > > I'm looking at doing some cleanups in our repo and I would like to start by > deprecating the `run_tests` script and the contents in the `tools/` dir. > > As far as I can tell, no one is using this code - we're not even using it in > the > gate - as it was broken until

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

+1 to maintain example plugins. It is easy enough and really lowering barriers for people who just begin create plugins. On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn wrote: > Igor, > > It seems you are proposing an IKEA approach to plugins. Take Fuel's > example

Re: [openstack-dev] [python-glanceclient][FFE] Return request-id to caller

On 04/03/16 09:14 +, Jethani, Ravishekar wrote: Hi Glance devs, Blueprint [1] related to request-ids is approved for Mitaka and its implementation [2] is up for review for quite a long time. I would like to apply for FFE for this blueprint so that it can be included in Mitaka. For the

Re: [openstack-dev] [all][i18n] Liaisons for I18n

Le 04/03/2016 12:24, Ihar Hrachyshka a écrit : Tony Breeds wrote: On Mon, Feb 29, 2016 at 05:26:44PM +0800, Ying Chun Guo wrote: If you are interested to be a liaison and help translators, input your information here:

Re: [openstack-dev] [oslo] PTL for Newton and beyond

Le 03/03/2016 13:05, Flavio Percoco a écrit : Thanks for all your hard work as an Oslo PTL. You did amazing and I think you'd do an awesome mentor for other folks as well. It was an honor to have you as a PTL and I look forward to keep working with you as an Oslo contributor. I concur with

Re: [openstack-dev] [Manila] Concurrent execution of drivers

What are you facing? On Fri, Mar 4, 2016 at 9:06 PM, John Spray wrote: > Hi, > > What expectations should driver authors have about multiple instances > of the driver being instantiated within different instances of > manila-share? > > For example, should I assume that when

[openstack-dev] [nova] bug reports and stable branches: tags or series?

What's the story behind having the tags "in-stable-liberty" and "liberty-backport-potential" and also having the series target "liberty"? I didn't gave much TCL to the backports in the past but I'd like to change that, that's why I'm asking. Please let me know the history behind it. Regards,

[openstack-dev] [python-glanceclient][FFE] Return request-id to caller

Hi Glance devs, Blueprint [1] related to request-ids is approved for Mitaka and its implementation [2] is up for review for quite a long time. I would like to apply for FFE for this blueprint so that it can be included in Mitaka. Kindly consider the request. Thank you. -- Best Regards, Ravi

Re: [openstack-dev] [nova] config options help text improvement: current status

> I'm looking forward to it :) > Thanks > == > I'd like to thank all the people who are working on this and making > this possible. A special thanks goes to Ed Leafe, Esra Celik and > Stephen Finucane. They put a tremendous amount of work in it. Markus, it was a pleasure for me to work with

Re: [openstack-dev] [Fuel][FFE] Enable UCA repositories for deployment

On 02.03.2016 16:27, Matthew Mosesohn wrote: > Hi all, > > I would like to request a feature freeze exception for "Deploy with > UCA packages" feature. > > I anticipate 2 more days to get tests green and add some depth to the > existing test. I vote to support this as that benefits community

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

Hi, First of all, many delayed thanks to Jay Pipes's benchmarking framework, learnt a lot from it : ) Other comments inline. On Friday, March 4, 2016 8:42 AM Jay Pipes wrote: > Hi again, Yingxin, sorry for the delayed response... been traveling. > Comments inline :) > > On 03/01/2016 12:34

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

Both of you, thanks for your insights. Greatly appreciated. Le 04/03/2016 09:25, Cheng, Yingxin a écrit : Hi, First of all, many delayed thanks to Jay Pipes's benchmarking framework, learnt a lot from it : ) Other comments inline. On Friday, March 4, 2016 8:42 AM Jay Pipes wrote: Hi again,

Re: [openstack-dev] [release][requirements] global requirements update squash for milestone

On 03/04/2016 01:00 PM, Doug Hellmann wrote: > We have a handful of requirements changes for community releases > that we need to land this week before fully freezing the repo. We're > starting to see merge conflicts, so I've combined them all into one > commit to make it easier to land the

[openstack-dev] [python-glanceclient][FFE] Return request-id to caller

Hi Glance devs, Blueprint [1] related to request-ids is approved for Mitaka and its implementation [2] is up for review for quite a long time. I would like to apply for FFE for this blueprint so that it can be included in Mitaka. Kindly consider the request. Thank you. [1]

Re: [openstack-dev] [oslo][all] Documenting configuration optionslifespan

Ronald Bradford wrote on 03/02/2016 07:40:42 PM: > From: Ronald Bradford > To: "OpenStack Development Mailing List (not for usage questions)" > > Date: 03/02/2016 07:41 PM > Subject: [openstack-dev]

Re: [openstack-dev] [oslo] PTL for Newton and beyond

On Thu, Mar 03 2016, Davanum Srinivas wrote: Hey Dims, Thanks for the job you've done since the beginning. You rock. Hope we'll continue to see you around anyway. :) Best, > It has been great working with you all as PTL for Oslo. Looks like the > nominations open up next week for elections and

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

No, this is a wrong road to go. What if in Fuel 10 we drop v1 plugins support? What should we do? Remove v1 example from source tree? That doesn't seem good to me. Example plugins are only examples. The list of supported releases must be maintained on system test side, and system tests must

Re: [openstack-dev] [Fuel] Feature Freeze Exception Request - switching to CentOS-7.2

Dmitry, Aleksandra, thank you for help and support! Regards, Igor Marnat On Fri, Mar 4, 2016 at 1:20 AM, Aleksandra Fedorova wrote: > As we agreed, we have switched ISO builds to latest CentOS 7.2 snapshots. > > You can see now that each ISO build (see for ex. [1])

[openstack-dev] [Heat] Dealing with nonexistent resources during resource-list / stack-delete

Hello, I am currently looking into https://bugs.launchpad.net/heat/+bug/1442121 and not quite sure how to tackle it, since the problematic code is used for lots of things[0]: the root cause of the problem are API clients in resource plugins that do not anticipate a resource with an entry in

Re: [openstack-dev] [Fuel] UI code freeze

Vitaly, As we decided yesterday custom job with fuel-ui and fuel-web refspec parameters could help here. Is it not enough for our case? In general, the case when two PRs depends on each other was deliberately denied to be handled automatically. Please read this thread [1] for details. [1]

Re: [openstack-dev] [cinder] Nested quota -1 limit race condition

On 03/03, Ryan McNair wrote: > Hey all, > > Nested quotas has officially started fighting back - while writing Tempest > tests for the nested quota support [1], I hit a race-condition related to > the nested quota -1 support that has me stumped. I opened a bug for it [2] > with more details, but

[openstack-dev] [Nova] Grant FFE to "Host-state level locking" BP

Hi, The actual BP that links to the approved spec is here: [1] and 2 outstanding patches are [2][3]. Apart from the usual empathy-inspired reasons to allow this (code's been up for a while, yet only had real review on the last day etc.) which are not related to the technical merit of the work,

[openstack-dev] [packstack] Update packstack core list

Hi, [post originally sent on RDO-list but I've been told I should use this channel] I've looked at packstack core-list [1] and I suggest we revisit to keep only active contributors [2] in the core members list. The list seems super big comparing to who is actually active on the project; in a

Re: [openstack-dev] [nova] bug reports and stable branches: tags or series?

On 3/4/2016 6:27 AM, Markus Zoeller wrote: What's the story behind having the tags "in-stable-liberty" and "liberty-backport-potential" and also having the series target "liberty"? I didn't gave much TCL to the backports in the past but I'd like to change that, that's why I'm asking. Please

[openstack-dev] [all] Status of Python 3 in OpenStack Mitaka

Hi, I just wrote an article "Status of Python 3 in OpenStack Mitaka": http://blogs.rdoproject.org/7894/status-of-python-3-in-openstack-mitaka Summary: * 13 services were ported to Python 3 during the Mitaka cycle: Cinder, Glance, Heat, Horizon, etc. * 9 services still need to be ported *

Re: [openstack-dev] When to revert a patch?

On 03/04/2016 08:37 AM, Ruby Loo wrote: Hijacked from ' [openstack-dev] [ironic] Remember to follow RFE process' thread: > Should we revert the patch [1] for now? (Disclaimer. I haven't looked at the > patch itself. But I don't think I should have to, to know what the API

[openstack-dev] [nova] "DocImpact" => bug report

Since 1-2 weeks each merged change which has a "DocImpact" in its commit message will open a new bug report in Nova, for example [1]. Those bug reports will be forwarded to the "manuals" project *IF* they provide enough information for the manuals team to work with. If they do not, they will

Re: [openstack-dev] [Manila] Concurrent execution of drivers

> > Thanks - so if I understand you correctly, each share instance is > uniquely associated with a single instance of the driver at one time, > right? So while I might have two concurrent calls to ensure_share, > they are guaranteed to be for different shares? > Yes. Is this true for the whole

Re: [openstack-dev] [Nova] Grant FFE to "Host-state level locking" BP

tl;dr As on IRC, I don't think this should get an FFE this cycle. On 4 March 2016 at 10:56, Nikola Đipanov wrote: > Hi, > > The actual BP that links to the approved spec is here: [1] and 2 > outstanding patches are [2][3]. > > Apart from the usual empathy-inspired reasons to

Re: [openstack-dev] [ironic] Remember to follow RFE process

> Hi, >> >> > Ironic'ers, please remember to follow the RFE process; especially the >> cores. >> > >> > I noticed that a patch [1] got merged yesterday. The patch was >> associated >> > with an RFE [2] that hadn't been approved yet :-( What caught my eye was >> > that the commit message didn't

Re: [openstack-dev] [sahara][sahara-tests] Sahara-tests release and launchpad project

+ added sahara tag On Fri, Mar 4, 2016 at 12:29 AM, Evgeny Sikachev wrote: > Hi, sahara folks! > > I would like to propose release sahara-tests. All steps from spec > implemented except releases and packaging.[0] > > Release criteria: framework ready for testing a new

Re: [openstack-dev] When to revert a patch?

On Mar 4, 2016 10:16, "Monty Taylor" wrote: > > On 03/04/2016 08:37 AM, Ruby Loo wrote: >> >> Hijacked from ' [openstack-dev] [ironic] Remember to follow RFE process' >> thread: >> >> > Should we revert the patch [1] for now? (Disclaimer. I haven't looked at the >>

[openstack-dev] [puppet] proposal to create puppet-neutron-core and add Sergey Kolekonov

Hi, To scale-up our review process, we created pupept-keystone-core and it worked pretty well until now. I propose that we continue this model and create puppet-neutron-core. I also propose to add Sergey Kolekonov in this group. He's done a great job helping us to bring puppet-neutron

Re: [openstack-dev] [Manila] Concurrent execution of drivers

On Fri, Mar 4, 2016 at 12:11 PM, Shinobu Kinjo wrote: > What are you facing? In this particular instance, I'm dealing with a case where we may add some metadata in ceph that will get updated by the driver, and I need to know how I'm going to be called. I need to know

Re: [openstack-dev] [oslo] PTL for Newton and beyond

Hi, Thanks for all the great work you have done, I have appreciated your leadership on Oslo, and a special thanks to bring in new people in oslo.messaging ;) Le 2016-03-03 11:32, Davanum Srinivas a écrit : Team, It has been great working with you all as PTL for Oslo. Looks like the

Re: [openstack-dev] [Nova] Grant FFE to "Host-state level locking" BP

I'll make sure to deliver the patches if FFE is granted. Regards, -Yingxin On Friday, March 4, 2016 6:56 PM Nikola Đipanov wrote: > > Hi, > > The actual BP that links to the approved spec is here: [1] and 2 outstanding > patches are [2][3]. > > Apart from the usual empathy-inspired reasons to

Re: [openstack-dev] [Fuel] [Openstack] Instalation Problem:VBoxManage: error: Guest not running [ubuntu14.04]

Hi Sames, *VBoxManage: error: Guest not running* looks line the problem with VirtualBox itself or settings for the 'fuel-master' VM, it can't boot it. Open the VirtualBox Manger (GUI), select the 'fuel-master' VM and start it manually - it should show you what is exactly happens. On Fri, Mar

Re: [openstack-dev] [Fuel] [Openstack] Instalation Problem:VBoxManage: error: Guest not running [ubuntu14.04]

Igor, Some information about my system: OS: ubuntu 14.04 LTS Memory: 3,8GiB Samer can't run many guests I think. On Fri, Mar 4, 2016 at 5:12 PM, Igor Marnat wrote: > Samer, Maksim, > I'd rather say that script started fuel-master already (VM "fuel-master" > has been

[openstack-dev] [tripleo] Contributing to TripleO is challenging

That's not the name of any Summit's talk, it's just an e-mail I wanted to write for a long time. It is an attempt to expose facts or things I've heard a lot; and bring constructive thoughts about why it's challenging to contribute in TripleO project. 1/ "I don't review this patch, we don't have

Re: [openstack-dev] [glance] Remove `run_tests.sh` and `tools/*`

On 04/03/16 12:04 +, Bunting, Niall wrote: Hey Folks, I'm looking at doing some cleanups in our repo and I would like to start by deprecating the `run_tests` script and the contents in the `tools/` dir. As far as I can tell, no one is using this code - we're not even using it in the gate -

Re: [openstack-dev] [all][i18n] Liaisons for I18n

hmm... It's true that a core CPL can help to get translation patch merged in time, more conveniently than a non-core CPL. But if there is non-core i18n CPL who can - understand project release schedule very well - understand project i18n status and technologies - manage to get translation

Re: [openstack-dev] [Nova] Grant FFE to "Host-state level locking" BP

On 03/04/2016 02:06 PM, John Garbutt wrote: > tl;dr > As on IRC, I don't think this should get an FFE this cycle. > > On 4 March 2016 at 10:56, Nikola Đipanov wrote: >> Hi, >> >> The actual BP that links to the approved spec is here: [1] and 2 >> outstanding patches are

Re: [openstack-dev] [Fuel] [Openstack] Instalation Problem:VBoxManage: error: Guest not running [ubuntu14.04]

Samer, Maksim, I'd rather say that script started fuel-master already (VM "fuel-master" has been successfully started.), didn't find running guests, (VBoxManage: error: Guest not running) but it can try to start them afterwards. Samer, - how many VMs are there running besides fuel-master? - is it

[openstack-dev] When to revert a patch?

Hijacked from ' [openstack-dev] [ironic] Remember to follow RFE process' thread: > Should we revert the patch [1] for now? (Disclaimer. I haven't looked at >> the >> > patch itself. But I don't think I should have to, to know what the API >> > change is.) >> > >> >> Thanks for calling it out

Re: [openstack-dev] [nova][bugs] Weekly Status Report

The weekly bug report is dead. Long live the 10 minute bug report! At least that's the interval I gave the script to update the data of the Grafana dashboard of this PoC: http://45.55.105.55:3000/dashboard/db/openstack-bugs I'd like to include that PoC to the official OpenStack grafana

[openstack-dev] [kolla][logging] log rotation

Hi Kolla devs So with the Heka work services write their logs into files (in the "kolla_logs" volume). This means that we need log rotation. This was mentioned in the "logging-with-heka" spec [*]. I've just created a change request [**] that adds a "cron" Dockerfile and Ansible tasks/plays to

Re: [openstack-dev] [Manila] Concurrent execution of drivers

John, each instance of manila-share service will perform "ensure_share" operation for each "share instance" that is located at "hostname@driver_config_group_name". So, only one driver is expected to run "ensure_share" for some "share instance", because each instance of a driver will have its own

[openstack-dev] [Fuel] [Openstack] Instalation Problem:VBoxManage: error: Guest not running [ubuntu14.04]

Hello, everyone. I'm new with Fuel. I'm trying to follow the QuickStart Guide ( https://docs.fuel-infra.org/openstack/fuel/fuel-8.0/quickstart-guide.html ), but I have the following Error: Waiting for VM "fuel-master" to power on... VM "fuel-master" has been successfully started.

Re: [openstack-dev] [Manila] Concurrent execution of drivers

On Fri, Mar 4, 2016 at 1:34 PM, Valeriy Ponomaryov wrote: > John, > > each instance of manila-share service will perform "ensure_share" operation > for each "share instance" that is located at > "hostname@driver_config_group_name". > So, only one driver is expected to

Re: [openstack-dev] [puppet] proposal to create puppet-neutron-core and add Sergey Kolekonov

Emilien Macchi wrote: > Hi, > > To scale-up our review process, we created pupept-keystone-core and it > worked pretty well until now. > > I propose that we continue this model and create puppet-neutron-core. > > I also propose to add Sergey Kolekonov in this group. > He's done a great job

Re: [openstack-dev] [sahara][sahara-tests] Sahara-tests release and launchpad project

On Fri, Mar 4, 2016 at 12:29 AM, Evgeny Sikachev > wrote: Hi, sahara folks! I would like to propose release sahara-tests. All steps from spec implemented except releases and packaging.[0] Release criteria: framework ready

Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro

My position on this is simple. Operators are used to using specific distros because that is what they used in the 90s,and the 00s, and the 10s. Yes, 25 years of using a distro, and you learn it inside and out. This means you don't want to relearn a new distro, especially if your an RPM user

Re: [openstack-dev] [puppet] proposal to create puppet-neutron-core and add Sergey Kolekonov

I'm not core, but I would like to say his contributions for Mitaka were invaluable and I've greatly benefited from his efforts :) On Fri, Mar 4, 2016 at 6:49 PM, Cody Herriges wrote: > Emilien Macchi wrote: >> Hi, >> >> To scale-up our review process, we created

Re: [openstack-dev] [release][requirements] global requirements update squash for milestone

Excerpts from Doug Hellmann's message of 2016-03-04 00:00:43 -0500: > We have a handful of requirements changes for community releases > that we need to land this week before fully freezing the repo. We're > starting to see merge conflicts, so I've combined them all into one > commit to make it

Re: [openstack-dev] [Openstack-operators] [glance] Remove `run_tests.sh` and `tools/*`

The keystone team did the same during Liberty while we were moving towards using oslo.* projects instead of oslo-incubator [0]. We also noticed that they were rarely used, and we did not go through a deprecation process since these are developer tools. We're still finding a few spots in our docs

Re: [openstack-dev] [Fuel] [Openstack] Instalation Problem:VBoxManage: error: Guest not running [ubuntu14.04]

Hi, Igor Thanks for answer so quickly. I wait until the following message appears Installation timed out! (3000 seconds) I don't have any virtual machines created. I update to 5.0 VirtualBox version, Now I got the following message VBoxManage: error: Machine 'fuel-master' is not currently

Re: [openstack-dev] [nova] nova hooks - document & test or deprecate?

On 03/03/2016 09:09 AM, Sam Matzek wrote: >> > So, don't deprecate until you have a solution. All you will be doing is >> > putting people in a tight spot where they will have to fork the code base, >> > and that is downright antisocial. >> > >> > Let's plan this out in the Newton Summit and

Re: [openstack-dev] [puppet] proposal to create puppet-neutron-core and add Sergey Kolekonov

+1 2016-03-04 18:40 GMT+03:00 Emilien Macchi : > Hi, > > To scale-up our review process, we created pupept-keystone-core and it > worked pretty well until now. > > I propose that we continue this model and create puppet-neutron-core. > > I also propose to add Sergey Kolekonov

Re: [openstack-dev] [puppet] proposal to create puppet-neutron-core and add Sergey Kolekonov

+1 On Fri, Mar 4, 2016 at 10:07 AM, Matt Fischer wrote: > +1 from me! > > gmail/openstack-dev is doing its thing where I see your email 4 hours > before Emilien's original, so apologies for the reply ordering > > On Fri, Mar 4, 2016 at 8:49 AM, Cody Herriges

Re: [openstack-dev] [Openstack-operators] [glance] Remove `run_tests.sh` and `tools/*`

I meant exactly that if you're not using venv for glance testing and want to use testing tools shipped that have the wrappings of run_test or even tox then asking packagers to write new scripts for doing the same thing seems odd. My question still stands: who is still using run_test towards this

Re: [openstack-dev] {openstack-dev][tc] Leadership training proposal/info

On Tue, Mar 1, 2016 at 4:41 PM, Colette Alexander < colettealexan...@gmail.com> wrote: > Hello Stackers, > > This is the continuation of an ongoing conversation within the TC about > encouraging the growth of leadership skills within the community that began > just after the Mitaka summit last

Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro

Hongbin, To be clear, this pursuit is not about what OS options cloud operators can select. We will be offering a method of choice. It has to do with what we plan to build comprehensive testing for, and the implications that has on our pace of feature development. My guidance here is that we

Re: [openstack-dev] [Openstack-operators] [glance] Remove `run_tests.sh` and `tools/*`

On 04/03/16 14:12 -0500, Nikhil Komawar wrote: Surely you can directly use the standard libraries to test systemwide but I am more curious to know if there are some who are still using run_tests wrappings that exist for to ease the pain a bit. Oh, sorry if I came off wrong. What I meant is

Re: [openstack-dev] [Nova] Live Migration post feature freeze update

On 3/4/2016 10:34 AM, Murray, Paul (HP Cloud) wrote: Hi All, Now that we have passed the feature freeze I thought it was worth giving a quick update on where we are with the live migration priority. The following is a list of work items that have been merged in this cycle ( for the live

Re: [openstack-dev] [Openstack-operators] [glance] Remove `run_tests.sh` and `tools/*`

Surely you can directly use the standard libraries to test systemwide but I am more curious to know if there are some who are still using run_tests wrappings that exist for to ease the pain a bit. On 3/4/16 12:41 PM, Flavio Percoco wrote: > On 04/03/16 11:59 -0500, Nikhil Komawar wrote: >> I

Re: [openstack-dev] [neutron] constrained tox targets

Armando M. wrote: On 4 March 2016 at 08:50, Ihar Hrachyshka wrote: Hi all, currently we have both py27 and py27-constraints tox targets in neutron repos. For some repos (neutron) they are even executed in both master and stable/liberty gates. TC

Re: [openstack-dev] [fuel] Newton PTL and CL elections

On Thu, Mar 03, 2016 at 10:34:30AM +0100, Thierry Carrez wrote: > Dmitry Borodaenko wrote: > >Team, > > > >We're only two weeks away from the beginning of the Newton elections > >period. Based on the Fuel 9.0/Mitaka release schedule [0], I propose the > >following dates for PTL and CL

Re: [openstack-dev] [packstack] Update packstack core list

On 04/03/16 10:09 -0500, Emilien Macchi wrote: Hi, [post originally sent on RDO-list but I've been told I should use this channel] I've looked at packstack core-list [1] and I suggest we revisit to keep only active contributors [2] in the core members list. The list seems super big comparing

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

All patches have been proposed, with the exception of ironic, which implemented its own config generator which does not support defaults. The patch list is available here: https://review.openstack.org/#/q/status:open+branch:master+(topic:bug/1551836) On Tue, Mar 1, 2016 at 8:59 AM Michael

[openstack-dev] OpenStack Developer Mailing List Digest Feb 27 – March 4

HTML version: http://www.openstack.org/blog/2016/03/openstack-developer-mailing-list-digest-20160304/ SuccessBot Says === * Ttx: Mitaka-3 is done. * Odyssey4me: OpenStack-Ansible Liberty 12.0.7 is released [1]. * johnthetubaguy: Nova is down to four pending blueprints for feature

Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro

+1 on the points Adrian makes below. On Mar 4, 2016, at 12:52 PM, Adrian Otto > wrote: Hongbin, To be clear, this pursuit is not about what OS options cloud operators can select. We will be offering a method of choice. It has to do

Re: [openstack-dev] [Fuel] [Openstack] Instalation Problem:VBoxManage: error: Guest not running [ubuntu14.04]

Samer, please address my recommendations. On Fri, Mar 4, 2016 at 7:49 PM, Samer Machara < samer.mach...@telecom-sudparis.eu> wrote: > Hi, Igor > Thanks for answer so quickly. > > I wait until the following message appears > Installation timed out! (3000 seconds) > I don't have any virtual

Re: [openstack-dev] {openstack-dev][tc] Leadership training proposal/info

On Fri, Mar 4, 2016 at 11:22 AM, Sean Dague wrote: > On 03/04/2016 02:00 PM, Anne Gentle wrote: > > > > > > On Tue, Mar 1, 2016 at 4:41 PM, Colette Alexander > > > wrote: > > > tl;dr - If you're a member of the TC

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

We are stoked to announce the release of: oslo.cache 1.5.0: Cache storage for Openstack projects. This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.cache With package available at:

Re: [openstack-dev] [nova] Non-Admin user can show deleted instances using changes-since parameter when calling list API

On 3/3/2016 9:14 PM, Zhenyu Zheng wrote: Hm, I found out the reason: https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L1139-L1145 here we filtered out parameters like "deleted", and that's why the API behavior is like above mentioned. So should we simple add

Re: [openstack-dev] [tripleo] Contributing to TripleO is challenging

On Fri, Mar 04, 2016 at 09:23:19AM -0500, Emilien Macchi wrote: > That's not the name of any Summit's talk, it's just an e-mail I wanted > to write for a long time. > > It is an attempt to expose facts or things I've heard a lot; and bring > constructive thoughts about why it's challenging to

[openstack-dev] [nova] customizing nova scheduler using metrics from ceilometer

Hi I would like to implement my own scheduling algorithm based on the samples collected in ceilometer for a custom meter. I see there is a MetricsFilter but I think they are nova internal metrics and not ceilometer metrics. Please refer me to some documentation and how can I install this plug in

Re: [openstack-dev] [kolla][vote] Proposing Alicja Kwasniewska for core reviewer

+1 Looking forward to more collaboration on Diagnostics and other stuff :) Le 4 mars 2016 17:58, "Steven Dake (stdake)" a écrit : > > Core Reviewers, > > Alicja has been instrumental in our work around jinja2 docker file creation, removing our symlink madness. She has also

Re: [openstack-dev] [ceilometer] Unable to get IPMI meter readings

Yes, I had to look through the source code of the ipmi pollster class to figure out why the error was being raised. Apparently, I don't have Intel node manager installed, so power plugin was not being loaded. I had to write my own plugin to get that data using ipmi-dcmi command which is not

Re: [openstack-dev] [Nova] Live Migration post feature freeze update

On 03/04/2016 02:54 PM, Matt Riedemann wrote: > > > On 3/4/2016 10:34 AM, Murray, Paul (HP Cloud) wrote: >> Hi All, >> >> Now that we have passed the feature freeze I thought it was worth giving >> a quick update >> >> on where we are with the live migration priority. >> >> The following is a

Re: [openstack-dev] [fuel] Fuel 8.0 is released

No, we have no plans for CentOS 7.x on controllers in Fuel 9.0/Mitaka, and our plans for Newton are still under discussion. I strongly suspect that life cycle management related features will consume most of Fuel team's attention, we've found that problems with the numerous LCM use cases cause a

[openstack-dev] [neutron][taas] tap-service-list / tap-flow-list failure when list is empty

Hi, Here is some additional information pertaining to the failures I am seeing when invoking the tap-service-list and tap-flow-list commands. This is on a multi-node DevStack environment (1 controller node, I network node and 2 compute nodes). 1. The tap-service-list command returns

[openstack-dev] [Neutron] Team meeting this Monday at 2100 UTC

Hi neutrinos, A kind reminder for next week's meeting. More on the agenda [1]. Cheers, Armando [1] https://wiki.openstack.org/wiki/Network/Meetings __ OpenStack Development Mailing List (not for usage questions)

[openstack-dev] [all][release] Release countdown for week R-4, Mar 7 - 11

The Mitaka 3 milestone has passed, and we're on our way to preparing release candidates. See Thierry's email [1] for details about the artifacts produced for the milestone. [1] http://lists.openstack.org/pipermail/openstack-announce/2016-March/001002.html Focus - Project teams should be

Re: [openstack-dev] [tripleo] Contributing to TripleO is challenging

On 03/04/2016 03:23 PM, Emilien Macchi wrote: That's not the name of any Summit's talk, it's just an e-mail I wanted to write for a long time. It is an attempt to expose facts or things I've heard a lot; and bring constructive thoughts about why it's challenging to contribute in TripleO

Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro

Steve, On Mar 4, 2016, at 2:41 PM, Steven Dake (stdake) > wrote: From: Adrian Otto > Reply-To: "OpenStack Development Mailing List (not for usage questions)"

Re: [openstack-dev] [magnum][magnum-ui] Liaisons for I18n

Kato, I have confirmed with Shu Muto, who will be assuming our I18n Liaison role for Magnum until further notice. Thanks for raising this important request. Regards, Adrian > On Mar 3, 2016, at 6:53 AM, KATO Tomoyuki wrote: > > I added Magnum to the list... Feel free

Re: [openstack-dev] [fuel] Fuel 9.0/Mitaka is now in Feature Freeze

Based on the list of approved exceptions, we're going to be merging some feature changes until March 24. It doesn't make sense to have Soft Code Freeze until a couple of weeks after that, so I propose to shift the release dates by 3 weeks: 9.0 Soft Code Freeze: April 6 9.0 Release: April 20

Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro

From: Adrian Otto > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > Date: Friday, March 4, 2016 at 12:48 PM To: "OpenStack

Re: [openstack-dev] [Fuel][Fuel-Library] Fuel CI issues

I think we need to address two separate concerns here: 1) smooth integration of puppet-openstack with Fuel master; 2) tests for changes in fuel-library. For 1) we need to build and test Fuel against master of puppet-openstack and treat any integration issues as critical/blocker. And this is

Re: [openstack-dev] [TripleO] IPv4 network isolation testing update

On Thu, 2016-03-03 at 21:38 -0500, Dan Prince wrote: > Some progress today: > > After rebuilding the test-env workers nodes in our CI rack to support > multiple-nics we got a stack to go into CREATE_COMPLETE with network > isolation enabled in CI. > > https://review.openstack.org/#/c/288163/ >

[openstack-dev] [neutron][calico] networking-calico 1.1.3 release

I'm happy to announce the release of networking-calico 1.1.3. networking-calico is a Neutron driver that connects instances using IP routing instead of layer 2 bridging and tunneling. networking-calico's server-side code works with Liberty and previous OpenStack releases back to Icehouse, and

Re: [openstack-dev] [kolla][vote] Proposing Alicja Kwasniewska for core reviewer

On Fri, Mar 4, 2016 at 10:25 PM, Steven Dake (stdake) wrote: > Core Reviewers, > > Alicja has been instrumental in our work around jinja2 docker file creation, > removing our symlink madness. She has also been instrumental in actually > getting Diagnostics implemented in a

Re: [openstack-dev] [kolla][vote] Proposing Alicja Kwasniewska for core reviewer

I've been impressed with Alicja's contributions and had suggested this nomination. So +1 a valuable addition. Cheers, -Paul On 04/03/16 17:27, Swapnil Kulkarni wrote: On Fri, Mar 4, 2016 at 10:25 PM, Steven Dake (stdake) wrote: Core Reviewers, Alicja has been instrumental

Re: [openstack-dev] [keystone][nova] Many same "region_name" configuration really meaingful for Multi-region customers?

On 03/03/2016 11:43 PM, Dolph Mathews wrote: Unless someone on the operations side wants to speak up and defend cross-region nova-cinder or nova-neutron interactions as being a legitimate use case, I'd be in favor of a single region identifier. MOC use case I think depends on this. I'll see

[openstack-dev] [magnum-ui] Proposed Core addition, and removal notice

Magnum UI Cores, I propose the following changes to the magnum-ui core group [1]: + Shu Muto - Dims (Davanum Srinivas), by request - justified by reduced activity level. Please respond with your +1 votes to approve this change or -1 votes to oppose. Thanks, Adrian

  1   2   >