Re: [openstack-dev] [stable] [horizon] Horizon stable and fast increasing Django releases

On Mon, Jan 11, 2016 at 10:44:11AM +0100, Thierry Carrez wrote: > Thomas Goirand wrote: > >[...] > >Best would be if this kind of cap was only a temporary solution until we > >really fix the issues. If possible (I perfectly know that in some case > >this may be difficult), I'd like to have Horizon

Re: [openstack-dev] How to get the current stable release

On 01/12/2016 08:55 AM, Christian Berendt wrote: Sorry if this is a stupid question and I waste your time. I am looking for a file that speicifes the name and version number of the latest stable release. As a use case the following example: We have a sitemap generator that builds a sitemap.xml

Re: [openstack-dev] [nova][bugs] help needed: volunteers for bug skimming (1 week)

On Mon, Jan 11, 2016 at 11:21:29AM +0100, Markus Zoeller wrote: > Augustina Ragwitz wrote on 01/08/2016 07:50:23 PM: > > > From: Augustina Ragwitz > > To: "OpenStack Development Mailing List (not for usage questions)" > > > > Date: 01/08/2016 08:00 PM > > Subject: Re: [openstack-dev] [nova][bu

[openstack-dev] [tricircle] weekly meeting of Jan.13

Hello, As the L3 E-W patch and Cinder volume CRUD patch submitted for review, it’s time for us to discuss the movement of the experiment branch to master branch. The weekly meeting will be held at the UTC1300 at #openstack-meeting on Jan.6. Agenda: l Branch movement l Progress of To-do list

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

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

Re: [openstack-dev] [Openstack-dev][Manila] status=NONE when share is created

Hi All, Could you please reply to below mail... Thanks Nidhi From: Nidhi Mittal Hada (WT01 - Product Engineering Service) Sent: Thursday, January 07, 2016 12:42 PM To: 'OpenStack Development Mailing List (not for usage questions)' Subject: RE: [Openstack-dev][Manila] status=NONE when share is

Re: [openstack-dev] [Nova] notification subteam meeting

Hi, The next meeting of the nova notification subteam will happen 2016-01-12 Tuesday 20:00 UTC [1] on #openstack-meeting-alt on freenode Agenda: - Status of the outstanding specs and code reviews - AOB See you there. Cheers, Gibi [1] https://www.timeanddate.com/worldclock/fixedtime.html?iso

[openstack-dev] [Smaug] IRC Meeting today (01/12) - 1400 UTC

We will have our second IRC meeting today (Tuesday, 01/12) at 1400 UTC in #openstack-meeting Please review the proposed meeting agenda here: https://wiki.openstack.org/wiki/Meetings/smaug Please add to the agenda any subject you would like to discuss. Project brief: Smaug is a new OpenStack pr

Re: [openstack-dev] [ironic][tests] approach to functional/integration tests

On 01/11/2016 03:49 PM, Serge Kovaleff wrote: Hi All, Last week I had a noble goal to write "one-more" functional test in Ironic. I did find a folder "func" but it was empty. Friends helped me to find a WIP patch https://review.openstack.org/#/c/235612/ and here comes the question of this emai

Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break

> Doug Wiegley wrote: > > > > > >> On Jan 11, 2016, at 2:42 AM, Ihar Hrachyshka > wrote: > >> > >> Sean M. Collins wrote: > >> > On Fri, Jan 08, 2016 at 07:50:47AM PST, Chris Dent wrote: > > On Fri, 8 Jan 2016, Gary Kotton wrote: > > > > The commit > > https://github.com/o

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

On 01/11/2016 11:09 PM, Tzu-Mainn Chen wrote: - Original Message - Background info: We've got a problem in TripleO at the moment where many of our workflows can be driven by the command line only. This causes some problems for those trying to build a UI around the workflows in that they

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

> On 2016/01/12 7:14, Armando M. wrote: > On 11 January 2016 at 13:54, Hirofumi Ichihara > mailto:[email protected]> > > wrote: > On 2016/01/12 5:14, Armando M. wrote: > On 11 January 2016 at 12:04, Carl Baldwin < >

Re: [openstack-dev] [release][ironic] ironic-python-agent release 1.1.0 (mitaka)

Gate is not working right now, as we still use preversioning in setup.cfg, and we have a version mismatch, e.g. http://logs.openstack.org/74/264274/1/check/gate-ironic-python-agent-pep8/8d6ef18/console.html. Patch to remove the version from setup.cfg: https://review.openstack.org/#/c/266267/ Wi

Re: [openstack-dev] How to get the current stable release

Christian Berendt wrote: Sorry if this is a stupid question and I waste your time. I am looking for a file that speicifes the name and version number of the latest stable release. I have not found this information in the governance repository (I only found a hard coded variable called latest_sta

Re: [openstack-dev] [Horizon] Routing in Horizon

On 12/01/16 03:33, Richard Jones wrote: > The tag addition has had to be reverted as it broke other parts > of the application (notably lazy loaded tabs like Instance Details), sadly. > > Regarding which router to use - I've used the built-in router in the > past quite successfully. I think I'd w

[openstack-dev] [Fuel] Diagnostic snapshot generation is broken due to lack of disk space

Hi! I need some advice on how to tackle this issue. There is a bug [1] describing the problem with creating a diagnostic snapshot. The issue is that /var/log has 100GB available, while /var (where diagnostic snapshot is being generated - /var/www/nailgun/dump/fuel-snapshot according to [2]) has 10

Re: [openstack-dev] [Horizon] Routing in Horizon

> El 12 ene 2016, a las 11:22, Matthias Runge escribió: > > On 12/01/16 03:33, Richard Jones wrote: >> The tag addition has had to be reverted as it broke other parts >> of the application (notably lazy loaded tabs like Instance Details), sadly. >> >> Regarding which router to use - I've used

Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break

Hi, At the moment private methods are used all over the place. Examples for this are the address pairs and the security groups. If you do a grep of the ML2 plugin you will see these innocent private methods being used. The end goal would be for us to have these as public methods. Thanks Gary

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

Hi, I personally liked that fact that there were two times. It was reasonable to make an effort to stay up very late to attend the one and then have the privileged of the other being at a reasonable time. Now it is back to the crazy hours. Thanks Gary From: Hirofumi Ichihara mailto:ichihara.hi

Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break

> > Hi, > At the moment private methods are used all over the place. Examples for > this are the address pairs and the security groups. If you do a grep of the > ML2 > plugin you will see these innocent private methods being used. > The end goal would be for us to have these as public methods. >

Re: [openstack-dev] [Fuel] Diagnostic snapshot generation is broken due to lack of disk space

Hi, doesn't matter how /var partition is big, diagnostic snapshot still could occupy all its space if there are lots of logs on slave nodes. Although, we can try to control disk space usage by snapshot in shotgun, but IMHO it's much safer to keep all related to logs staff away from critical s

Re: [openstack-dev] [Fuel] Diagnostic snapshot generation is broken due to lack of disk space

Hi, > b) Make the snapshot location share the diskspace of /var/log? +1 for that. And +1 for using hard links to save space during snapshot creation. Regards, Alex On Tue, Jan 12, 2016 at 12:12 PM, Artem Panchenko wrote: > Hi, > > doesn't matter how /var partition is big, diagnostic snapshot

[openstack-dev] [Fuel] new branch stable/2.9 for fuel-devops

Hi all! Framework QA team is going to merge a lot of changes to the fuel-devops repository [0] , to complete support for template-based creation of virtual environments [1]. Current fuel-devops data object model will be modified to support additional data, that will be required for more flexib

Re: [openstack-dev] [Fuel] new branch stable/2.9 for fuel-devops

+ mos-dev & mos-qa 12.01.2016 13:26, Dennis Dmitriev пишет: > Hi all! > > Framework QA team is going to merge a lot of changes to the > fuel-devops repository [0] , to complete support for template-based > creation of virtual environments [1]. > Current fuel-devops data object model will be mo

[openstack-dev] [Monasca] Enabling Graphana GUI from Horizon

Hello, We're using the following fullsetup to install Monasca (python): https://github.com/openstack/monasca-api/tree/master/devstack Most likely we need to do something more to see the "Monitoring" tab in left hand side that takes us to Monasca graphana GUI. Can anyone please point me? W

Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break

Hi, I have drafted https://blueprints.launchpad.net/neutron/+spec/better-defined-apis and have up as an example (https://review.openstack.org/266304) for people to chew on... Thanks Gary On 1/12/16, 1:08 PM, "Smigiel, Dariusz" wrote: >> >> Hi, >> At the moment private methods are used all

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

On Sun, Jan 10, 2016 at 06:07:33PM +0800, Luo Gangyi wrote: > Hi devs, > > > Do you test the difference between within and without > VIR_MIGRATE_NON_SHARED_INC ? > > > When I add VIR_MIGRATE_NON_SHARED_INC in block_migration_flags in > nova, nova block migration behaves more like a full copy of

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

On 01/11/2016 04:51 PM, Dan Prince wrote: Background info: We've got a problem in TripleO at the moment where many of our workflows can be driven by the command line only. This causes some problems for those trying to build a UI around the workflows in that they have to duplicate deployment logi

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

- Orijinal Mesaj - > Kimden: "Markus Zoeller" > Kime: "OpenStack Development Mailing List" > > Gönderilenler: 12 Ocak Salı 2016 10:58:28 > Konu: Re: [openstack-dev] [nova] config options: IRC meeting at Jan. 11th > Esra Celik wrote on 01/12/2016 08:21:34 AM: > > From: Esra Celik > >

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade

Clark Boylan wrote: On Mon, Jan 11, 2016, at 12:35 PM, Sean M. Collins wrote: Nice find. I actually pushed a patch recently that we should be advertising the MTU by default. I think this really shows that it should be enabled by default. https://review.openstack.org/263486l ++ Neutron should

Re: [openstack-dev] [Fuel] new branch stable/2.9 for fuel-devops

Good news :) Thank you! On Tue, Jan 12, 2016 at 2:28 PM, Dennis Dmitriev wrote: > + mos-dev & mos-qa > > 12.01.2016 13:26, Dennis Dmitriev пишет: > > Hi all! > > > > Framework QA team is going to merge a lot of changes to the > > fuel-devops repository [0] , to complete support for template-b

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

Unfortunately I do not have any experience in working or testing Heka, so it’s hard for me to compare its performance vs Logstash performance. However I’ve read that Heka possess a lot advantages over Logstash in this scope. But which version of Logstash did you test? One guy from the Logstash

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

Agreed with Gary on behalf of my European compatriots. (Note that I *personally* +1’d the patch because I don’t mind, doing late hours anyway; but it’s sad it was ninja merged without giving any chance for those from affected timezones to express their concerns). Ihar Gary Kotton wrote:

Re: [openstack-dev] [Horizon] Routing in Horizon

On 12/01/16 11:22, Matthias Runge wrote: > > https://launchpad.net/bugs/1532759 > > Unfortunately, that even hasn't been detected by tests. > https://github.com/openstack/horizon/commit/871505c130cf1fd02aae41aeb8f6062af4a5fe88 fixes this issue (another revert). Matthias

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

I agree with Gary here, The 21:00 UTC time here is a difficult time for me, because it's exactly the time of getting kids to sleep at home. It's generally very unpredictable for me. I missed last meeting exactly because of that, laptop was ready, I was ready, kids didn't cooperate.

Re: [openstack-dev] [Fuel] Diagnostic snapshot generation is broken due to lack of disk space

I think we need to find a way to: 1) verify the size of snapshot without actually making it and compare to the available disk space beforehand. 2) refuse to create snapshot if space is insufficient and notify user (otherwise it breaks Admin node as we have seen) 3) provide a way to prioritize elem

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

Hello Alicja, Comments inline. On Tue, Jan 12, 2016 at 1:19 PM, Kwasniewska, Alicja < [email protected]> wrote: > Unfortunately I do not have any experience in working or testing Heka, so > it’s hard for me to compare its performance vs Logstash performance. > However I’ve read that H

[openstack-dev] [Keystone][Neutron][Nova] Keystone v3 with "old" clients

Hello, I'm trying to gather all the info necessary to migrate to keystone v3 in Neutron. When I've started to looking through possible problems with clients, it occurred that 'neutron' and 'nova' clients do not want to operate with Keystone v3. For keystone client, it's explicit written, that th

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

On Tue, 2016-01-12 at 12:52 +0100, Jiri Tomasek wrote: > On 01/11/2016 04:51 PM, Dan Prince wrote: > > Background info: > > > > We've got a problem in TripleO at the moment where many of our > > workflows can be driven by the command line only. This causes some > > problems for those trying to bui

Re: [openstack-dev] [neutron] InvalidRequestError: This session is in 'prepared' state; no further SQL can be emitted within this transaction.

I tried rollback but still it didn't work. This issue is reproduced sometimes only when 1. neutron port created 2. enable fixed looping in conf, stop neutron and start 3. delete neutron port and looping interval is very lesss say 20 secs. source code where it fails: ---

[openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

I've tagged this message with the projects impacted by a series of change sets: [trove] https://review.openstack.org/#/c/266220/ [neutron] https://review.openstack.org/#/c/266156/1 [cinder] https://review.openstack.org/#/c/266099/2 [swift] https://review.openstack.o

Re: [openstack-dev] [release][ironic] ironic-python-agent release 1.1.0 (mitaka)

On 01/12/2016 10:56 AM, Dmitry Tantsur wrote: Gate is not working right now, as we still use preversioning in setup.cfg, and we have a version mismatch, e.g. http://logs.openstack.org/74/264274/1/check/gate-ironic-python-agent-pep8/8d6ef18/console.html. Patch to remove the version from setup.cf

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

Amrith Kumar wrote: I've tagged this message with the projects impacted by a series of change sets: [trove] https://review.openstack.org/#/c/266220/ [neutron] https://review.openstack.org/#/c/266156/1 [cinder] https://review.openstack.org/#/c/266099/2 [swift]

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

On Tue, 12 Jan 2016, Amrith Kumar wrote: if var > 0: ... something ... To if var: ... something ... I may be missing something but the above is not a stylistic change if var can ever be negative. In one of the ceilometer changes[1] for example, this change will change the flo

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

21:00 UTC is too difficult for me to attend. It's early morning (2:30 AM) ;( On Tue, Jan 12, 2016 at 6:17 PM, Miguel Angel Ajo wrote: > I agree with Gary here, > >The 21:00 UTC time here is a difficult time for me, because it's > exactly the time of getting kids to sleep > at home. It's gene

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

Hi, IMO if you want to do the stylistic changes - make the hacking rule for it first. Not all of this particular changes are useful and even correct. The explicit comparison with zero in Python where we have number of implicit casts to bool is much better in such cases. Thanks. On Tue, Jan 12, 2

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

On 01/12/2016 03:02 PM, Chris Dent wrote: > On Tue, 12 Jan 2016, Amrith Kumar wrote: > >> if var > 0: >> ... something ... >> >> To >> >> if var: >> ... something ... > > I may be missing something but the above is not a stylistic change > if var can ever be negative. In one of the ceilomet

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

not a fan of these changes since it messes up git blame and it becomes harder to track down author if you have questions relating to bug/code. that said, "if var > 0" is not the same as "if var". in the latter, var can be any number (negative or positive) or any other datatype and it'll evalua

[openstack-dev] [Neutron]{l2-gateway] is this project alive

Its like a desert out here trying to get a review… __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/ma

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

On Tue, Jan 12, 2016 at 8:51 AM, Amrith Kumar wrote: > I've tagged this message with the projects impacted by a series of change > sets: > > [trove] https://review.openstack.org/#/c/266220/ > [neutron] https://review.openstack.org/#/c/266156/1 > [cinder] https://review.ope

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

I agree too. Neutron community is scattered all over the world, it makes sense for me to have two different times. If attendance is not big enough that's something that we should try to address. It's a problem that we should try to fix, not a condition that we should accept. Moving to one time

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

Chris, Ihar, I assumed that this was stylistic based on the fact that in the places where I was seeing it, it seemed to be the case that the LHS was intuitively positive (a length, for example). I did not exhaustively verify this but yes, you are correct, the construct If var is the

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

On Tue, Jan 12, 2016 at 9:13 AM, Amrith Kumar wrote: > Chris, Ihar, > > I assumed that this was stylistic based on the fact that in the places > where I was seeing it, it seemed to be the case that the LHS was > intuitively positive (a length, for example). I did not exhaustively verify > this bu

[openstack-dev] Spam of patches (was: [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?)

On Tue, Jan 12 2016, Amrith Kumar wrote: > My question to the ML is this, should stylistic changes of this kind be > handled > in a consistent way across all projects, maybe with a hacking rule and some > discussion on the ML first? After all, if this change is worthwhile, it is > worth ensuring

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

On 12/01/16 15:01 +0100, Ihar Hrachyshka wrote: Amrith Kumar wrote: I've tagged this message with the projects impacted by a series of change sets: [trove] https://review.openstack.org/#/c/266220/ [neutron] https://review.openstack.org/#/c/266156/1 [cinder] https://re

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

On 01/12/2016 08:51 AM, Amrith Kumar wrote: My question to the ML is this, should stylistic changes of this kind be handled in a consistent way across all projects, maybe with a hacking rule and some discussion on the ML first? After all, if this change is worthwhile, it is worth ensuring that

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

On 08/01/16 08:36 -0430, Flavio Percoco wrote: Greetings, As some of you know already, google code is going to be shutdown. Some projects we're using are hosted and, unfortunately, some of them are unmaintained and perhaps going away. One of these projects is PrettyTable. This point was raised

Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break

Hi Gary, Thanks for filing. Take a look at http://specs.openstack.org/openstack/neutron-specs/specs/liberty/neutron-lib.html , which is work in progress to address the same issue. At the end of that, no one should be importing directly from neutron. Thanks, doug > On Jan 12, 2016, at 5:31 A

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

One issue to be aware of is the use of this as a Denial of Service vector. Basically an attacker can use this to lock out key accounts by continuously sending invalid passwords. Doing this might have unexpected and undesirable results, particularly in automated tasks. I think this feature has so

Re: [openstack-dev] Spam of patches

On 01/12/2016 09:32 AM, Julien Danjou wrote: > On Tue, Jan 12 2016, Amrith Kumar wrote: > >> My question to the ML is this, should stylistic changes of this kind be >> handled >> in a consistent way across all projects, maybe with a hacking rule and some >> discussion on the ML first? After all,

Re: [openstack-dev] Spam of patches

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/12/2016 09:32 AM, Julien Danjou wrote: > On Tue, Jan 12 2016, Amrith Kumar wrote: > >> My question to the ML is this, should stylistic changes of this >> kind be handled in a consistent way across all projects, maybe >> with a hacking rule and s

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

So far myself & Jay Pipes have been working on the initial os-vif prototype and setting up infrastructure for the project. Obviously we need more then just 2 people on a core team, and after looking at those who've expressed interest in os-vif, we came up with a cross-section of contributors across

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

On 01/12/2016 06:52 AM, Jiri Tomasek wrote: On 01/11/2016 04:51 PM, Dan Prince wrote: Background info: We've got a problem in TripleO at the moment where many of our workflows can be driven by the command line only. This causes some problems for those trying to build a UI around the workflows i

Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break

So Doug are you planning on moving all of the extensions and mixins to the Neutron lib? My understanding was that was not part of the scope, but maybe I missed that with all of the moving parts. Thanks Gary On 1/12/16, 4:46 PM, "Doug Wiegley" wrote: >Hi Gary, > >Thanks for filing. Take a lo

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

On 01/12/2016 10:15 AM, Daniel P. Berrange wrote: > So far myself & Jay Pipes have been working on the initial os-vif > prototype and setting up infrastructure for the project. Obviously > we need more then just 2 people on a core team, and after looking > at those who've expressed interest in os-v

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

On 01/12/2016 08:24 AM, Dan Prince wrote: On Tue, 2016-01-12 at 12:52 +0100, Jiri Tomasek wrote: On 01/11/2016 04:51 PM, Dan Prince wrote: Background info: [snip] In similar manner, is Mistral able to provide a way to get workflow in progress data? E.g. We have a Mistral workflow for nodes

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

On 01/12/2016 04:22 PM, Ryan Brown wrote: On 01/12/2016 06:52 AM, Jiri Tomasek wrote: On 01/11/2016 04:51 PM, Dan Prince wrote: Background info: We've got a problem in TripleO at the moment where many of our workflows can be driven by the command line only. This causes some problems for those

Re: [openstack-dev] [puppet] weekly meeting #66

On 01/11/2016 08:20 AM, Emilien Macchi wrote: > Hi folks! > > Tomorrow we will have our weekly meeting at UTC 1500. > Here is our agenda: > https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160112 > > Feel free to add more topics, reviews, bugs, as usua

Re: [openstack-dev] [Neutron]{l2-gateway] is this project alive

Hi Gary, I think it is still active. What are your concerns, I can talk to the team. Thanks Swami From: Gary Kotton [mailto:[email protected]] Sent: Tuesday, January 12, 2016 6:14 AM To: OpenStack List Subject: [openstack-dev] [Neutron]{l2-gateway] is this project alive Its like a desert out her

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

I wanted to float two ideas related to the neutron callback mechanism that is being moved to neutron-lib. 1) API The current API uses kwargs as a way for the notifier to pass information to the subscribers listening (callbacks). One issue with this, is that the actual keyword arguments used, could

Re: [openstack-dev] [Monasca] Enabling Graphana GUI from Horizon

You would need to propose the new feature in the monasca-ui [1], which is the horizon plugin for displaying monasca dashboard. -Lin [1] https://github.com/openstack/monasca-ui/ On Tue, Jan 12, 2016 at 3:32 AM, Pradip Mukhopadhyay < [email protected]> wrote: > Hello, > > > We're using the

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

> -Original Message- > From: Russell Bryant [mailto:[email protected]] > Sent: Tuesday, January 12, 2016 5:24 PM > To: Daniel P. Berrange ; openstack- > [email protected] > Cc: Jay Pipes ; Sean Mooney > ; Moshe Levi ; Sahid > Orentino Ferdjaoui ; Maxime Leroy > > Subject: Re: [no

Re: [openstack-dev] [trove] Spam of patches

I see that https://review.openstack.org/264253 merged in Trove. Do you feel that the exposure is sufficient that we should go and revert these kind(s) of changes wholesale across the projects? -amrith > -Original Message- > From: Eric Harney [mailto:[email protected]] > Sent: Tuesday,

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

So tracebacks sort of works, they're there just ugly. That's why I'm also happy if we change rsyslog to heka. Eric, I hope I wont ask too much, but could you please prepare PoC of kolla+heka, for what I care heka can log to local log file same as rsyslog for now. Would that be big problem? On 11

Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break

Move, refactor, or remove and code around, yes. If it’s meant to be a stable internal neutron api, some form of it will move and be versioned. Thanks, doug > On Jan 12, 2016, at 9:20 AM, Gary Kotton wrote: > > So Doug are you planning on moving all of the extensions and mixins to the > Neutr

Re: [openstack-dev] [Neutron]{l2-gateway] is this project alive

On 12 January 2016 at 06:14, Gary Kotton wrote: > Its like a desert out here trying to get a review… > There was a patch that was meant to unwedge a few things. I wouldn't say it's a desert, things are still slow after the holidays. > > _

Re: [openstack-dev] [Monasca] Enabling Graphana GUI from Horizon

Thanks! So I can temporarily follow the step to enable it in my setup. --pradip On Tue, Jan 12, 2016 at 9:45 PM, Lin Hua Cheng wrote: > > You would need to propose the new feature in the monasca-ui [1], which is > the horizon plugin for displaying monasca dashboard. > > -Lin > > [1] https://g

Re: [openstack-dev] [Neutron]{l2-gateway] is this project alive

Here is an example of a patch that was posted 5 weeks ago. - https://review.openstack.org/#/c/254816/ That is a pretty long time for something that is trivial From: "Vasudevan, Swaminathan (PNB Roseville)" mailto:[email protected]>> Reply-To: OpenStack List mailto:openstack-dev@list

Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break

Not sure how the database will be versioned. The spec does not deal with stuff like this. On 1/12/16, 6:38 PM, "Doug Wiegley" wrote: >Move, refactor, or remove and code around, yes. If it¹s meant to be a >stable internal neutron api, some form of it will move and be versioned. > >Thanks, >doug >

Re: [openstack-dev] [nova][bugs] help needed: volunteers for bug skimming (1 week)

Fahri Cihan Demirci wrote on 01/12/2016 09:58:10 AM: > From: Fahri Cihan Demirci > To: "OpenStack Development Mailing List (not for usage questions)" > > Date: 01/12/2016 10:01 AM > Subject: Re: [openstack-dev] [nova][bugs] help needed: volunteers for > bug skimming (1 week) > > On Mon, Jan

[openstack-dev] [kolla] Status of python-kollaclient

Ok folks, this is a bit of bad news, but I'll come out with it. Because of the addition of Mesos at the Mitaka design summit, the main engineers working on the CLI decided they want to wait to provide a unified experience with Mesos and Ansible. Nobody is beating us up for a CLI or ReST API, a

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

On 01/12/2016 06:13 AM, Amrith Kumar wrote: [...] > I did not exhaustively verify this but [...] A fair question to ask then is, why are you proposing these patches? > I created a quick poll to tally results oh no, not another survey! :) Sometimes I feel that survey-itis[1] is a consequence of

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

On 01/12/2016 10:50 AM, Jiri Tomasek wrote: On 01/12/2016 04:22 PM, Ryan Brown wrote: On 01/12/2016 06:52 AM, Jiri Tomasek wrote: On 01/11/2016 04:51 PM, Dan Prince wrote: Background info: We've got a problem in TripleO at the moment where many of our workflows can be driven by the command li

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

Hi, For the last several weeks I've been working on algorithm (and prototype) for dynamic allocation of volumes on disks. I have some results [0] and would like to ask you to review it and provide some feedback. Our plan is to implement it as an external driver for Bareon [1]. Thanks, [0] http

Re: [openstack-dev] [nova][bugs] help needed: volunteers for bug skimming (1 week)

On Tue, Jan 12, 2016 at 06:39:22PM +0100, Markus Zoeller wrote: > Fahri Cihan Demirci wrote on 01/12/2016 09:58:10 AM: > > > From: Fahri Cihan Demirci > > To: "OpenStack Development Mailing List (not for usage questions)" > > > > Date: 01/12/2016 10:01 AM > > Subject: Re: [openstack-dev] [nova

Re: [openstack-dev] [Neutron]{l2-gateway] is this project alive

On 12 January 2016 at 09:21, Gary Kotton wrote: > Here is an example of a patch that was posted 5 weeks ago. - > https://review.openstack.org/#/c/254816/ > That is a pretty long time for something that is trivial > 5 weeks is bad but not the end of the world. We all have patches sitting idle in

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

Stefano, I didn't propose the changes. They are largely -1'ed or -2'ed now. Fair point on the survey! -amrith > -Original Message- > From: Stefano Maffulli [mailto:[email protected]] > Sent: Tuesday, January 12, 2016 1:00 PM > To: [email protected] > Subject: Re: [o

[openstack-dev] [release][stable][keystone] python-keystoneclient release 1.7.3 (liberty)

We are delighted to announce the release of: python-keystoneclient 1.7.3: Client Library for OpenStack Identity This release is part of the liberty stable release series. With source available at: https://git.openstack.org/cgit/openstack/python-keystoneclient With package available at:

[openstack-dev] [release][stable][keystone] keystoneauth release 1.1.1 (liberty)

We are chuffed to announce the release of: keystoneauth 1.1.1: Authentication Library for OpenStack Identity This release is part of the liberty stable release series. With source available at: http://git.openstack.org/cgit/openstack/keystoneauth With package available at: https://pyp

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

On Tue, 2016-01-12 at 13:24 -0500, Ryan Brown wrote: > On 01/12/2016 10:50 AM, Jiri Tomasek wrote: > > On 01/12/2016 04:22 PM, Ryan Brown wrote: > > > On 01/12/2016 06:52 AM, Jiri Tomasek wrote: > > > > On 01/11/2016 04:51 PM, Dan Prince wrote: > > > > > Background info: > > > > > > > > > > We've

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

Eric, Thanks for using the mailing list for this discussion. I like to see more mailing list conversations on big changes related to kolla, which this one is :) Responses inline. Please put document #3 (the design document) in gerrit rather than google docs in the main kolla repo as a spec using

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

Hi all, I've noticed that we have a fairly large number of unused parameters in t-h-t, some of which are marked deprecated, some aren't. Since we moved tripleoclient to use parameter_defaults everywhere, I think it should be safe to remove these unused parameters, even in overcloud.yaml. See: h

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

On Tue, Jan 12, 2016, at 04:19 AM, Kwasniewska, Alicja wrote: > Unfortunately I do not have any experience in working or testing Heka, so > it’s hard for me to compare its performance vs Logstash performance. > However I’ve read that Heka possess a lot advantages over Logstash in > this scope. > >

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

> On 01/11/2016 11:09 PM, Tzu-Mainn Chen wrote: > > - Original Message - > >> Background info: > >> > >> We've got a problem in TripleO at the moment where many of our > >> workflows can be driven by the command line only. This causes some > >> problems for those trying to build a UI around

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

> -Original Message- > From: Moshe Levi [mailto:[email protected]] > Sent: Tuesday, January 12, 2016 4:23 PM > To: Russell Bryant; Daniel P. Berrange; openstack- > [email protected] > Cc: Jay Pipes; Mooney, Sean K; Sahid Orentino Ferdjaoui; Maxime Leroy > Subject: RE: [nova][neutr

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

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

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

I don’t think it ninja merged. It had plenty of reviews, and was open during international hours. I don’t have any issue there. I don’t like the crazy early meeting, so I set out to prove it didn’t matter: Average attendance before rotating: 20.7 people Average attendance on Monday afternoons (U

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

Subject changed from [neutorn] to [neutron] so that it reaches correct folders via rules ;) -Abhishek Raut From: Paul Michali mailto:[email protected]>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:[email protected]>> Date: Tuesday, January 12,

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

Hello, As more and more OpenStack release are deployed in the production cloud, multiple releases of OpenStack co-located in a cloud is a very common situation. For example, "Juno" and "Liberty" releases co-exist in the same cloud. Then the cloud management software has to be aware of the API

[openstack-dev] [all] Python 3.5 is now the default Py3 in Debian Sid

Hi, Just a quick notice for those not following developments in Debian. Python 3.5 is now the default Python 3 interpreter in Debian Unstable, and when the transition will be finished [1], it's going to be the one in Testing (aka: Stretch) as well. The current plan is to have Python 3.5 only in St

  1   2   >