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 y

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

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 changes

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

[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] https://blueprints

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

[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 Heat'

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 b

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] http://

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] [oslo][all] Documenting configuration options lifespan > > After evaluation of oslo-config-ge

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 injec

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]) produces several > *_id.txt a

[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, th

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 m

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 https://wiki.openstack.org/wiki/CrossProjectLiaisons#I18n

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 cl

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: https://wiki.openstack.org/wiki/CrossProjectLiaisons#I18n . So https:/

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

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

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

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 one instance of a driv

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 plugin, add in the current Fu

[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, Mar

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

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 patc

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 whether e.g. I can expect th

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

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 u

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 nominatio

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

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 run "ensure_share" for some "

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

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 dr

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 allow this (code's be

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

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

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 successfully started.), di

[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] [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 [2][3]. >> >> Apart from t

[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 Ruby,

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 desc

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 release of Sahara. > > Next

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

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

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

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 >> > patch itself.

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 le

[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 rock-solid

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 in this group. > He'

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 helpi

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 pupept-keystone-core and it >> wor

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 eas

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

On Fri, Mar 4, 2016 at 12:29 AM, Evgeny Sikachev mailto:esikac...@mirantis.com>> 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 release o

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 g

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 t

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 have

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

I don't think anyone is saying that code should somehow block support for multiple distros. The discussion at midcycle was about what the we should gate on and ensure feature parity for as a team. Ideally, we'd like to get support for every distro, I think, but no one wants to have that many gates.

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

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 migration sub-team's working page see https://etherpad.open

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

+1 from me. I am all for standardizing this. Personally when I started looking at OpenStack code as new contributor this was very confusing with the online docs that listed run_tests.sh but the first project I looked at, this didn't exist and it was all tox based. I went on to blog about my fir

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

Also, new Launchpad adds ability to create blueprints for the sahara-tests project and this is good for release notes. On Fri, Mar 4, 2016 at 7:14 PM, michael mccune wrote: > On Fri, Mar 4, 2016 at 12:29 AM, Evgeny Sikachev > > wrote: >> >> Hi, sahara folks! >>

[openstack-dev] [release] mitaka-3 development milestone

Hello everyone, The last milestone of the Mitaka development cycle, "mitaka-3", is now reached. Some OpenStack projects following the milestone-based release schedule took the opportunity to publish a development artifact, which contains all the new features and bugfixes that have been added s

[openstack-dev] [neutron] constrained tox targets

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 lately decided that instead of having separate targets for constrained requirements, we want to have constraints

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

[openstack-dev] [openstack-ansible][security] Security hardening backport to Liberty desirable?

Hey folks, I have proposed a review[1] which adds the openstack-ansible-security[2] role to OpenStack-Ansible's Liberty release. I would really appreciate some feedback from deployers on whether this change is desirable in Liberty. The role applies cleanly to Liberty on Ubuntu 14.04 and the ro

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

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 sanitary fashion. She has also done a bunch of other work that folks in the community alre

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

+1! congrats Ala! I'm super proud! For others, I had pleasure to be in same team with Ala and I vouch for her with all the credibility I have:) she will be wonderful addition to core team! On 4 March 2016 at 10:55, Steven Dake (stdake) wrote: > Core Reviewers, > > Alicja has been instrumental in

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

I think the hard question to me here is: Do people care about testing code on system installs vs. virtual env? run_tests does that and for some cases when you want to be extra sure about your CICD nodes, packaging and upgrades, the problem is solved. Are packagers using tox to this purpose? On 3

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

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 lately decided that instead of having separate > targets fo

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

+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 wrote: > Emilien Macchi wrote: > > Hi, > > > > To scale-up our review process, we created pupept-keyston

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

I don’t think there is any consensus on supporting single distro. There are multiple disagreements on this thread, including several senior team members and a project co-founder. This topic should be re-discussed (possibly at the design summit). Best regards, Hongbin From: Corey O'Brien [mailt

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

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 sanitary fashion. She

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 in our work around

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 i

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

On 04/03/16 11:59 -0500, Nikhil Komawar wrote: I think the hard question to me here is: Do people care about testing code on system installs vs. virtual env? run_tests does that and for some cases when you want to be extra sure about your CICD nodes, packaging and upgrades, the problem is solved

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

On 04/03/16 10:24 -0500, Morgan Fainberg wrote: 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 loo

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 wrote: > >> Emilien Macchi wrote: >>

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 t

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 Krotsc

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 yea

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 lately decided that instead of having sep

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 think

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

On 4 March 2016 at 11:12, Ihar Hrachyshka wrote: > 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 >

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

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

On 03/04/2016 02:00 PM, Anne Gentle wrote: > > > On Tue, Mar 1, 2016 at 4:41 PM, Colette Alexander > mailto:colettealexan...@gmail.com>> wrote: > > Hello Stackers, > > This is the continuation of an ongoing conversation within the TC > about encouraging the growth of leadership skil

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 that

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

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 p

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 migr

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

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 lis

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

[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: https://pypi.python.org/pypi/osl

  1   2   >