Re: [openstack-dev] [neutron] Changes to the core team

On Wed, Dec 3, 2014 at 9:07 PM, Adam Young wrote: > On 12/03/2014 06:24 PM, Sukhdev Kapur wrote: > > Congratulations Henry and Kevin. It has always been pleasure working with > you guys. > > > If I may express my opinion, Bob's contribution to ML2 has been quite > substantial. The kind of stab

Re: [openstack-dev] [Neutron] [Devstack] Devstack quantun-agent vlan error

What do you have for tunnel_types in ml2_conf.ini? On Wed, Dec 3, 2014 at 12:31 PM, Daniel Nobusada wrote: > Hi guys, > > I'm using Devstack with vlan on the parameter Q_ML2_TENANT_NETWORK_TYPE > and while stacking, the quantun-agent (q-agt) breaks. I'm running it on an > Ubuntu Server 14.04. >

Re: [openstack-dev] [Heat] Convergence proof-of-concept showdown

On 01/12/14 02:02, Anant Patil wrote: On GitHub:https://github.com/anantpatil/heat-convergence-poc I'm trying to review this code at the moment, and finding some stuff I don't understand: https://github.com/anantpatil/heat-convergence-poc/blob/master/heat/engine/stack.py#L911-L916 This appe

Re: [openstack-dev] [neutron] Changes to the core team

On 12/03/2014 06:24 PM, Sukhdev Kapur wrote: Congratulations Henry and Kevin. It has always been pleasure working with you guys. If I may express my opinion, Bob's contribution to ML2 has been quite substantial. The kind of stability ML2 has achieved makes a statement of his dedication t

[openstack-dev] [nova] global or per-project specific ssl config options, or both?

I've posted this to the 12/4 nova meeting agenda but figured I'd socialize it here also. SSL options - do we make them per-project or global, or both? Neutron and Cinder have config-group specific SSL options in nova, Glance is using oslo sslutils global options since Juno which was contentiou

[openstack-dev] [TripleO] Do we want to remove Nova-bm support?

Hi all, I'm becoming increasingly concerned about all of the code paths in tripleo-incubator that check $USE_IRONIC -eq 0 -- that is, use nova-baremetal rather than Ironic. We do not check nova-bm support in CI, haven't for at least a month, and I'm concerned that parts of it may be slowly

[openstack-dev] [nova] NUMA Cells

Hi, so just having read a bunch of the libvirt driver numa code, I have a concern. At first I thought it was a little thing, but I am starting to think its more of a big deal... We use the term "cells" to describe numa cells. However, that term has a specific meaning in nova, and I worry that ove

Re: [openstack-dev] [Ceilometer]Unit test failed on branch stable/icehouse

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dina, As you say, it is caused by legacy .pyc files. I remove them all and all tests are passed. Thanks Sam On 12/03/2014 05:47 PM, Dina Belova wrote: > have unit tests failing in the new just cloned reposi -BEGIN PGP SIGNATURE- Version: Gnu

Re: [openstack-dev] [glance] Deprecating osprofiler option 'enabled' in favour of 'profiler_enabled'

Don't care either way, let's be consistent with other projects and raise this concern in next weekly cross-project meeting [1] to see what "all" of the projects mutually agree on. If there is no consensus, let's stick to what we have. @Louis: Can you please add that to the agenda of the cross-p

Re: [openstack-dev] [tripleo] Managing no-mergepy template duplication

Excerpts from Dan Prince's message of 2014-12-03 18:35:15 -0800: > On Wed, 2014-12-03 at 10:11 +, Steven Hardy wrote: > > Hi all, > > > > Lately I've been spending more time looking at tripleo and doing some > > reviews. I'm particularly interested in helping the no-mergepy and > > subsequent

Re: [openstack-dev] [tripleo] Managing no-mergepy template duplication

On Wed, 2014-12-03 at 10:11 +, Steven Hardy wrote: > Hi all, > > Lately I've been spending more time looking at tripleo and doing some > reviews. I'm particularly interested in helping the no-mergepy and > subsequent puppet-software-config implementations mature (as well as > improving overclo

Re: [openstack-dev] How to get openstack bugs data for research?

You can download a database dump with (hopefully) information for all Launchpad tickets corresponding to OpenStack, already organized and ready to be queried: http://activity.openstack.org/dash/browser/data/db/tickets.mysql.7z (linked from http://activity.openstack.org/dash/browser/data_sources.h

Re: [openstack-dev] [OpenStack-Dev] Config Options and OSLO libs

On Wed, Dec 3, 2014 at 2:18 PM, Sean Dague wrote: > On 12/03/2014 03:58 PM, Morgan Fainberg wrote: >> Hi John, >> >> Let me say first off that I 100% agree with the value of the sample config >> being in-tree. Keystone has not removed it due to similar feedback I’ve >> received. However, the iss

Re: [openstack-dev] [neutron] Changes to the core team

Congratulations Henry and Kevin. It has always been pleasure working with you guys. If I may express my opinion, Bob's contribution to ML2 has been quite substantial. The kind of stability ML2 has achieved makes a statement of his dedication to this work. I have worked very closely with Bob o

Re: [openstack-dev] [Compute][Nova] Mid-cycle meetup details for kilo

Sigh, sorry. It is of course the Kilo meetup: https://www.eventbrite.com.au/e/openstack-nova-kilo-mid-cycle-developer-meetup-tickets-14767182039 Michael On Thu, Dec 4, 2014 at 10:16 AM, Michael Still wrote: > I've just created the signup page for this event. Its here: > > https://www.eventbrite

Re: [openstack-dev] [Compute][Nova] Mid-cycle meetup details for kilo

I've just created the signup page for this event. Its here: https://www.eventbrite.com.au/e/openstack-nova-juno-mid-cycle-developer-meetup-tickets-14767182039 Cheers, Michael On Wed, Oct 15, 2014 at 3:45 PM, Michael Still wrote: > Hi. > > I am pleased to announce details for the Kilo Compute mi

[openstack-dev] [Neutron] [RFC] Floating IP idea solicitation and collaboration

Hi, At Rackspace, we have a need to create a higher level networking service primarily for the purpose of creating a Floating IP solution in our environment. The current solutions for Floating IPs, being tied to plugin implementations, does not meet our needs at scale for the following reasons:

Re: [openstack-dev] [neutron] alembic 0.7.1 will break neutron's "heal" feature which assumes a fixed set of potential autogenerate types

Thanks Mike, I already gave your patch a +2. when the gate is broken there's no time for nitpicking - those can come with a followup patch. The patch is now spinning again against jenkins checks. As soon as it's done we'll send it through the gate - and hopefully get a promotion for it. Salvatore

Re: [openstack-dev] [nova][neutron] Boundary between Nova and Neutron involvement in network setup?

What you are proposing sounds very reasonable. If I understand correctly, the idea is to make Nova just create the TAP device and get it attached to the VM and leave it 'unplugged'. This would work well and might eliminate the need for some drivers. I see no reason to block adding a VIF type that d

Re: [openstack-dev] [horizon] [ux] Changing how the modals are closed in Horizon

I would be happy with either the two proposed solutions (both improvements over the what we have now). Any thoughts on combining them? Only close if esc or 'x' is clicked, but also warn them if data was entered. On 12/3/2014 7:21 AM, Rob Cresswell (rcresswe) wrote: +1 to changing the behavi

Re: [openstack-dev] [OpenStack-Infra] [third-party]Time for Additional Meeting for third-party

Whoops too many mailing lists. Forwarded Message Subject: Re: [OpenStack-Infra] [openstack-dev] [third-party]Time for Additional Meeting for third-party Date: Wed, 03 Dec 2014 17:25:05 -0500 From: Anita Kuno To: openstack-in...@lists.openstack.org On 12/03/2014 03:15 AM, Omri

Re: [openstack-dev] [oslo] oslo.messaging config option deprecation

Ben Nemec wrote: On 12/03/2014 02:45 PM, Sean Dague wrote: So this - https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586 was clearly a violation of our 1 cycle for deprecation of config options. I think that should be reverted, an oops release put out to

Re: [openstack-dev] [neutron] alembic 0.7.1 will break neutron's "heal" feature which assumes a fixed set of potential autogenerate types

So folks, I had to put Alembic 0.7.1 out as I realized that the “batch” mode was being turned on for autogenerate across the board in 0.7.0, and that was not the plan. So it is now out, and the builds are failing due to https://launchpad.net/bugs/1397796 . T

Re: [openstack-dev] [OpenStack-Dev] Config Options and OSLO libs

> On Dec 3, 2014, at 1:18 PM, Sean Dague wrote: > > On 12/03/2014 03:58 PM, Morgan Fainberg wrote: >> Hi John, >> >> Let me say first off that I 100% agree with the value of the sample config >> being in-tree. Keystone has not removed it due to similar feedback I’ve >> received. However, the

Re: [openstack-dev] [OpenStack-Dev] Config Options and OSLO libs

On 12/03/2014 03:58 PM, Morgan Fainberg wrote: > Hi John, > > Let me say first off that I 100% agree with the value of the sample config > being in-tree. Keystone has not removed it due to similar feedback I’ve > received. However, the issue is that *gating* on config changes for all > librarie

Re: [openstack-dev] [oslo] oslo.messaging config option deprecation

On 12/03/2014 02:45 PM, Sean Dague wrote: > So this - > https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586 > was clearly a violation of our 1 cycle for deprecation of config options. > > I think that should be reverted, an oops release put out to fix it, an

Re: [openstack-dev] [Manila] Manila project use-cases

Reply to Valeriy below and to Marc further below... On 12/03/2014 02:39 AM, Valeriy Ponomaryov wrote: According to (2) - yes, analog of Cinder's "manage/unmanage" is not implemented in Manila yet. Manage/unmanage is a feature I'm very interested in seeing in Manila. I suspect it will be hard

Re: [openstack-dev] [OpenStack-Dev] Config Options and OSLO libs

Hi John, Let me say first off that I 100% agree with the value of the sample config being in-tree. Keystone has not removed it due to similar feedback I’ve received. However, the issue is that *gating* on config changes for all libraries that are included in the sample config is just a process

[openstack-dev] [third-party] Third-party CI account creation is now self-serve

As of now third-party CI account creation is now self-serve. I think this makes everybody happy. What does this mean? Well for a new third-party account this means you follow the new process, outlined here: http://ci.openstack.org/third_party.html#creating-a-service-account If you don't have eno

[openstack-dev] [oslo] oslo.messaging config option deprecation

So this - https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586 was clearly a violation of our 1 cycle for deprecation of config options. I think that should be reverted, an oops release put out to fix it, and then deprecate for 1.6. If oslo libraries are goi

[openstack-dev] [OpenStack-Dev] Config Options and OSLO libs

Hey, So this is a long running topic, but I want to bring it up again. First, YES Cinder is still running a sample.conf. A lot of Operators spoke up and provided feedback that this was valuable and they objected strongly to taking it away. That being said we're going to go the route of removing

[openstack-dev] [Neutron] [Devstack] Devstack quantun-agent vlan error

Hi guys, I'm using Devstack with vlan on the parameter Q_ML2_TENANT_NETWORK_TYPE and while stacking, the quantun-agent (q-agt) breaks. I'm running it on an Ubuntu Server 14.04. For more details, here's my local.conf: http://pastebin.com/4scBGtpf. The error that I recieve is the following: http://

Re: [openstack-dev] [diskimage-builder] Tracing levels for scripts (119023)

Hi > On 3 Dec 2014, at 18:41, Clint Byrum wrote: > > What if the patch is reworked to leave the current trace-all-the-time > mode in place, and we iterate on each script to make tracing conditional > as we add proper logging? +1 Cheers, -- Chris Jones _

Re: [openstack-dev] [stable] Exception proposals for 2014.2.1

On 03/12/14 20:22, Alan Pevec wrote: >> Horizon >> standing-after-freeze translation update, coming on Dec 3 > > This is now posted https://review.openstack.org/138798 > David, Matthias, I'd appreciate one of you to have a quick look before > approving. > > Cheers, > Alan > Alan, thanks for the

Re: [openstack-dev] [neutron] Changes to the core team

I give +2 to Henry and Kevin. So, Congratulations Folks! I have been working with both of them and great quality reviews are always coming out from them. Many thanks to Nachi and Bob for their hard work! Edgar On 12/2/14, 7:59 AM, "Kyle Mestery" wrote: >Now that we're in the thick of working h

Re: [openstack-dev] [stable] Exception proposals for 2014.2.1

>> Neutron >> https://review.openstack.org/136294 - default SNAT, see review for >> details, I cannot distil 1liner :) > -1: I would rather fix the doc to match behavior, than change behavior > to match the doc and lose people that were relying on it. Consensus is not to merge this and keep behavi

Re: [openstack-dev] [Ironic] A mascot for Ironic

Hi, Poll is closed! Everyone please welcome: Pixie Boots, the new Ironic mascot! Thanks for everyone that voted! Cheers, Lucas On Mon, Dec 1, 2014 at 4:47 PM, Lucas Alvares Gomes wrote: > Ah forgot to say, > > Please add your launchpad ID on the Name Field. And I will close the poll > on Wedn

Re: [openstack-dev] [stable] Exception proposals for 2014.2.1

> Horizon > standing-after-freeze translation update, coming on Dec 3 This is now posted https://review.openstack.org/138798 David, Matthias, I'd appreciate one of you to have a quick look before approving. Cheers, Alan ___ OpenStack-dev mailing list O

Re: [openstack-dev] [stable] Exception proposals for 2014.2.1

2014-12-02 17:15 GMT+01:00 Jay S. Bryant : >> Cinder >> https://review.openstack.org/137537 - small change and limited to the >> VMWare driver > > +1 I think this is fine to make an exception for. one more Cinder exception proposal was added in StableJuno etherpad * https://review.openstack.org/#/

Re: [openstack-dev] [nova] [libvirt] enabling per node filtering of mempage sizes

Hi Daniel thanks for your feedback. After reading up a little more http://docs.openstack.org/openstack-ops/content/scaling.html#segragation_methods I now understand your original suggestion. I believe that if the operator associates the aggregate directly to the flavor As you suggested that yes

Re: [openstack-dev] [diskimage-builder] Tracing levels for scripts (119023)

Excerpts from Chris Jones's message of 2014-12-03 02:47:30 -0800: > Hi > > I am very sympathetic to this view. We have a patch in hand that improves the > situation. We also have disagreement about the ideal situation. > > I +2'd Ian's patch because it makes things work better than they do now.

Re: [openstack-dev] [nova] Can the Kilo nova controller conduct the Juno compute nodes

On 12/3/2014 3:49 AM, Li Junhong wrote: Hi Joe, Thank you for your confirmative answer and the wonderful gate testing pipeline. On Wed, Dec 3, 2014 at 5:38 PM, Joe Gordon mailto:joe.gord...@gmail.com>> wrote: On Wed, Dec 3, 2014 at 11:09 AM, Li Junhong mailto:lijh.h...@gmail.com>> wrot

Re: [openstack-dev] [Fuel][Nailgun] Web framework

Choosing the right instrument for the job in an open source community involves choosing technologies that the community is familiar/comfortable with as well, as it will allow you access to a greater pool of developers. With that in mind then, I'd add: Pro Pecan, blessed by the OpenStack communit

Re: [openstack-dev] [neutron] Changes to the core team

+1 for Kevin and Henry. Thanks for your continuous efforts so far and it would be great additions to our community. I also would like to say great thanks to Bob and Nachi. It would be really nice if we see their activities in reviews soon. We already understand your contributions and skills, so I

Re: [openstack-dev] [Fuel][Nailgun] Web framework

I've left some comments/corrections in this document re: pecan and what is supports. On 12/03/14 07:58 PM, Nikolay Markov wrote: > A month or two ago I started gathering differencies between Flask and > Pecan, let's take a look at technical details. Maybe there are some > things that are already f

Re: [openstack-dev] [Fuel][Nailgun] Web framework

+1. Well said. I second the applauding of the Fuel's development team's for their changing of their communications patterns (that's never easy) and also the desire for closer integration with the rest of the OpenStack community. From: Jay Pipes [jaypi...@g

Re: [openstack-dev] [Fuel][Nailgun] Web framework

I didn't participate in that discussion, but here are topics on Flask cons from your link. I added some comments. - Cons - db transactions a little trickier to manage, but possible # what is trickier? Flask uses pure SQLalchemy or a very thin wrapper - JSON built-in but not XML # the only

Re: [openstack-dev] [Fuel][Nailgun] Web framework

On 12/03/2014 10:53 AM, Nikolay Markov wrote: However, the OpenStack community is also about a shared set of tools, development methodologies, and common perspectives. I completely agree with you, Jay, but the same principle may be applied much wider. Why Openstack Community decided to use its

Re: [openstack-dev] [Infra] Infra-manual documentation Sprint, December 1-2

On Fri, Nov 7, 2014 at 5:57 AM, Elizabeth K. Joseph wrote: > The OpenStack Infrastructure team will be hosting a virtual sprint in > the Freenode IRC channel #openstack-sprint for the Infrastructure User > Manual on December 1st starting at 15:00 UTC and going for 48 hours. Thanks to everyone who

Re: [openstack-dev] [all] bugs with paste pipelines and multiple projects and upgrading

On 12/03/2014 10:57 AM, Lance Bragstad wrote: > > > On Wed, Dec 3, 2014 at 9:18 AM, Sean Dague > wrote: > > We've hit two interesting issues this week around multiple projects > installing into the paste pipeline of a server. > > 1) the pkg_resources explosio

[openstack-dev] [nova][neutron] Boundary between Nova and Neutron involvement in network setup?

Hi there. I've been looking into a tricky point, and hope I can succeed in expressing it clearly here... I believe it is the case, even when using a committedly Neutron-based networking implementation, that Nova is still involved a little bit in the networking setup logic. Specifically I mean th

Re: [openstack-dev] [Fuel][Nailgun] Web framework

A month or two ago I started gathering differencies between Flask and Pecan, let's take a look at technical details. Maybe there are some things that are already fixed in current versions of Pecan, feel free to comment. https://docs.google.com/document/d/1QR7YphyfN64m-e9b5rKC_U8bMtx4zjfW943BfLTqTa

Re: [openstack-dev] [all] bugs with paste pipelines and multiple projects and upgrading

On Wed, Dec 3, 2014 at 9:18 AM, Sean Dague wrote: > We've hit two interesting issues this week around multiple projects > installing into the paste pipeline of a server. > > 1) the pkg_resources explosion in grenade. Basically ceilometer modified > swift paste.ini to add it's own code into swift

[openstack-dev] [QA] Meeting Thursday December 4th at 17:00 UTC

Hi everyone, Just a quick reminder that the weekly OpenStack QA team IRC meeting will be tomorrow Thursday, December 4th at 17:00 UTC in the #openstack-meeting channel. The agenda for tomorrow's meeting can be found here: https://wiki.openstack.org/wiki/Meetings/QATeamMeeting Anyone is welcome to

Re: [openstack-dev] [Fuel][Nailgun] Web framework

> However, the OpenStack community is also about a shared set of tools, > development methodologies, and common perspectives. I completely agree with you, Jay, but the same principle may be applied much wider. Why Openstack Community decided to use its own unstable project instead of existing solu

[openstack-dev] [NFV][Telco] Use case discussion

Hello all Unfortunately, my complete inability to process daylight savings time changes meant I was one hour late for today's TelcoWG meeting so couldn't participate in the discussion of use cases, including the one I submitted on Session Border Control. Thanks to eavesdrop.openstack.org I've bee

Re: [openstack-dev] [qa] branchless tempest and the use of 'all' for extensions in tempest.conf

On Wed, Dec 03, 2014 at 09:43:41AM -0500, David Kranz wrote: > A recent proposed test to tempest was making explicit calls to the nova > extension discovery api rather than using test.requires_ext. The reason was > because we configure tempest.conf in the gate as 'all' for extensions, and > the tes

Re: [openstack-dev] [Fuel][Nailgun] Web framework

On 12/03/2014 10:16 AM, Nikolay Markov wrote: It would be great to look at some obvious points where Pecan is better than Flask despite of the fact that it's used by the community. I still don't see a single and I don't think the principle "jump from the cliff if everyone does" works well in such

[openstack-dev] [all] bugs with paste pipelines and multiple projects and upgrading

We've hit two interesting issues this week around multiple projects installing into the paste pipeline of a server. 1) the pkg_resources explosion in grenade. Basically ceilometer modified swift paste.ini to add it's own code into swift (that's part of normal ceilometer install in devstack - https

Re: [openstack-dev] [Fuel][Nailgun] Web framework

Being able to make some impact on Pecan is an advantage for sure. But there are other aspects in choosing a web framework and I’d rather discuss them. Let’s not think about what is used in other OpenStack projects for a moment and discuss technical details. > On 03 Dec 2014, at 15:53, Jay Pipes

Re: [openstack-dev] [Fuel][Nailgun] Web framework

It would be great to look at some obvious points where Pecan is better than Flask despite of the fact that it's used by the community. I still don't see a single and I don't think the principle "jump from the cliff if everyone does" works well in such cases. On Wed, Dec 3, 2014 at 5:53 PM, Jay Pip

Re: [openstack-dev] [Fuel][Nailgun] Web framework

On 12/03/2014 09:35 AM, Sebastian Kalinowski wrote: I think that as a part of OpenStack community we should stick with Pecan and because of the same reason we can have a bigger impact how future versions of Pecan will look. Yes, this. ++ -jay ___ Op

[openstack-dev] [qa] branchless tempest and the use of 'all' for extensions in tempest.conf

A recent proposed test to tempest was making explicit calls to the nova extension discovery api rather than using test.requires_ext. The reason was because we configure tempest.conf in the gate as 'all' for extensions, and the test involved an extension that was new in Juno. So the icehouse run

[openstack-dev] oslo.db 1.2.0 released

Hello Folks The Oslo team is pleased to announce the release of oslo.db 1.2.0. This release includes several bug fixes as well as many other changes: $ git log --abbrev-commit --pretty=oneline --no-merges 1.1.0..1.2.0 f740e3b Imported Translations from Transifex ca1ad56 Make test_models pass on

Re: [openstack-dev] [Fuel][Nailgun] Web framework

I don’t have an opinion for now but do have some thoughts instead. We use Pecan in Ironic. I could say that it’s pretty nice when one needs to make something simple but requires some manual job to be done in more or less sophisticated cases. On the other hand we have that the Pecan team is quire

Re: [openstack-dev] [Fuel][Nailgun] Web framework

I never used Flask and Pecan personally so I can only rely from what I saw in this thread and in both projects docs. I don't have strong opinion, just want to share some thoughts. I think that as a part of OpenStack community we should stick with Pecan and because of the same reason we can have a

Re: [openstack-dev] oslo.concurrency 0.3.0 released

On Dec 2, 2014, at 7:48 PM, Matt Riedemann wrote: > > > On 12/2/2014 12:33 PM, Ben Nemec wrote: >> We've discovered a couple of problems as a result of this release. pep8 >> in most/all of the projects using oslo.concurrency is failing due to the >> move out of the oslo namespace package and

Re: [openstack-dev] [neutron] Changes to the core team

Mathieu: The peer review proposal was NOT about removing core reviewers, that is very clear in the proposal. The peer review proposal was about deciding as a team what it means to be a core reviewer, and ensuring core reviewers are doing that. I still plan to do try out the peer review process in

Re: [openstack-dev] [Nova][Cinder] Operations: adding new nodes in "disabled" state, allowed for test tenant only

Hi Mike, We've got the similar option in Cinder too: https://github.com/openstack/cinder/blob/master/cinder/db/api.py#L58 Regards, Ivan Kolodyazhny On Wed, Dec 3, 2014 at 3:31 PM, Mike Scherbakov wrote: > Hi all, > enable_new_services in nova.conf seems to allow add new compute nodes in > dis

Re: [openstack-dev] [nova] [libvirt] enabling per node filtering of mempage sizes

On Wed, Dec 03, 2014 at 01:28:36PM +, Mooney, Sean K wrote: > Hi > > Unfortunately a flavor + aggregate is not enough for our use case as it is > still possible for the tenant to misconfigure a vm. > > The edge case not covered by flavor + aggregate that we are trying to prevent > is as fo

Re: [openstack-dev] [tripleo] Managing no-mergepy template duplication

On 12/03/2014 11:11 AM, Steven Hardy wrote: Hi all, Lately I've been spending more time looking at tripleo and doing some reviews. I'm particularly interested in helping the no-mergepy and subsequent puppet-software-config implementations mature (as well as improving overcloud updates via heat).

[openstack-dev] [Nova][Cinder] Operations: adding new nodes in "disabled" state, allowed for test tenant only

Hi all, enable_new_services in nova.conf seems to allow add new compute nodes in disabled state: https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L507-L508, so it would allow to check everything first, before allowing production workloads host a VM on it. I've filed a bug to

Re: [openstack-dev] [nova] [libvirt] enabling per node filtering of mempage sizes

Hi Unfortunately a flavor + aggregate is not enough for our use case as it is still possible for the tenant to misconfigure a vm. The edge case not covered by flavor + aggregate that we are trying to prevent is as follows. The operator creates an aggregate containing the nodes that require a

Re: [openstack-dev] [Fuel][Nailgun] Web framework

Dear colleagues, We surely may take into account the beauty of the code in both cases (as for me, Pecan loses here, too) and argue about global objects and stuff, but I'm trying to look at amount of men and time we need to move to one of these frameworks. I wouldn't say our API is badly designed,

Re: [openstack-dev] How to get openstack bugs data for research?

Hi, you could take a look at Stackalytics and how this website communicates with launchpad. https://wiki.openstack.org/wiki/Stackalytics/HowToRun Best, Angelo On 03/12/2014 13:41, Louis Taylor wrote: On Wed, Dec 03, 2014 at 08:20:45PM +0800, zfx0...@gmail.com wrote: Hi, all I am a graduate

Re: [openstack-dev] [horizon] [ux] Changing how the modals are closed in Horizon

+1 to changing the behaviour to ‘static'. Modal inside a modal is potentially slightly more useful, but looks messy and inconsistent, which I think outweighs the functionality. Rob On 2 Dec 2014, at 12:21, Timur Sufiev mailto:tsuf...@mirantis.com>> wrote: Hello, Horizoneers and UX-ers! The

Re: [openstack-dev] [Fuel][Nailgun] Web framework

Yeah, didn't notice that. Honestly, I'd prefer both to be accessible as instance attributes just like in [1] but it's more of taste I guess. [1] http://tornado.readthedocs.org/en/latest/web.html#tornado.web.RequestHandler.request P. On 12/03/2014 02:03 PM, Sebastian Kalinowski wrote: 2014-

Re: [openstack-dev] [Fuel][Nailgun] Web framework

2014-12-03 13:47 GMT+01:00 Igor Kalnitsky : > > I don't like that Flask uses a global request object [3]. > > Przemyslaw, actually Pecan does use global objects too. BTW, what's > wrong with global objects? They are thread-safe in both Pecan and > Flask. > To be fair, Pecan could also pass reques

Re: [openstack-dev] [Fuel][Nailgun] Web framework

> I don't like that Flask uses a global request object [3]. Przemyslaw, actually Pecan does use global objects too. BTW, what's wrong with global objects? They are thread-safe in both Pecan and Flask. > IMHO documentation is better written, and described a lot of possibilities of > modification

Re: [openstack-dev] How to get openstack bugs data for research?

On Wed, Dec 03, 2014 at 08:20:45PM +0800, zfx0...@gmail.com wrote: > Hi, all > > I am a graduate student in Peking University, our lab do some research on > open source projects. > This is our introduction: https://passion-lab.org/ > > Now we need openstack issues data for research, I found the

[openstack-dev] [python-novaclient] Status of novaclient V3

Thank for answers. I sent a patch to novaclient : https://review.openstack.org/#/c/138694/ On Wed, Dec 3, 2014 at 1:59 PM, Christopher Yeoh > wrote: > > > > On 3 Dec 2014, at 10:00 pm, Joe Gordon > wrote: > > > > On Tue, Dec 2, 2014 at 5:21 PM, Andrey Kurilin > wrote: > >> Hi! >> >> While worki

Re: [openstack-dev] [Fuel][Nailgun] Web framework

Additionaly to what Przemek wrote, also Pecan is released more often, IMHO documentation is better written, and described a lot of possibilities of modification, also as Lukasz wrote in previous thread that Pecan is used in openstack. So I'm also for Pecan Best regards, Kamil S. On Wed, Dec 3,

[openstack-dev] How to get openstack bugs data for research?

Hi, all I am a graduate student in Peking University, our lab do some research on open source projects. This is our introduction: https://passion-lab.org/ Now we need openstack issues data for research, I found the issues list: https://bugs.launchpad.net/openstack/ I want to download the opens

[openstack-dev] [Neutron] DVR Slides from Paris Summit

Hi, is there a way to get access to the slides from the DVR session of the Paris summit? Unfortunately the slides in the video are not readable. Speakers were Swaminathan Vasudevan, Jack McCann, Vivekanandan, Narasimhan, Rajeev Grover, Michael Smith. So maybe one of you can post them on slidesha

Re: [openstack-dev] [python-novaclient] Status of novaclient V3

> On 3 Dec 2014, at 10:00 pm, Joe Gordon wrote: > > > >> On Tue, Dec 2, 2014 at 5:21 PM, Andrey Kurilin wrote: >> Hi! >> >> While working on fixing wrong import in novaclient v3 shell, I have found >> that a lot of commands, which are listed in V3 shell(novaclient.v3.shell), >> are broke

Re: [openstack-dev] [Fuel][Nailgun] Web framework

The only useful paradigm to write in Flask is MethodView's for me [1] because decorators seem hard to refactor for large projects. Please look at adding URLs -- one has to additionally specify methods to match those from the MethodView -- this is code duplication and looks ugly. It seems thoug

Re: [openstack-dev] [python-novaclient] Status of novaclient V3

On Tue, Dec 2, 2014 at 5:21 PM, Andrey Kurilin wrote: > Hi! > > While working on fixing wrong import in novaclient v3 shell, I have found > that a lot of commands, which are listed in V3 shell(novaclient.v3.shell), > are broken, because appropriate managers are missed from V3 > client(novaclient.

Re: [openstack-dev] [stable] Exception proposals for 2014.2.1

On 03/12/14 11:02 +0100, Thierry Carrez wrote: Doug Hellmann wrote: On Dec 2, 2014, at 5:41 PM, Alan Pevec wrote: General: cap Oslo and client library versions - sync from openstack/requirements stable/juno, would be good to include in the release. https://review.openstack.org/#/q/status:ope

Re: [openstack-dev] [stable] Exception proposals for 2014.2.1

On 02/12/14 14:22 +0100, Alan Pevec wrote: Hi all, here are exception proposal I have collected when preparing for the 2014.2.1 release, stable-maint members please have a look! General: cap Oslo and client library versions - sync from openstack/requirements stable/juno, would be good to inclu

Re: [openstack-dev] [neutron] force_gateway_on_subnet, please don't deprecate

I will spend some time on it during tonight/weekend to make sure it’s removed and that we have reference implementation working at once. I propose following the bug fix way, as it’s a tiny change. https://bugs.launchpad.net/neutron/+bug/1398768 @amuller, I’m not sure I understand why does it nee

Re: [openstack-dev] [diskimage-builder] Tracing levels for scripts (119023)

Hi I am very sympathetic to this view. We have a patch in hand that improves the situation. We also have disagreement about the ideal situation. I +2'd Ian's patch because it makes things work better than they do now. If we can arrive at an ideal solution later, great, but the more I think abou

Re: [openstack-dev] [neutron] Changes to the core team

Hi all, It seems that a process with a survey for neutron core election/removal was about to take place [1]. Has it been applied for this proposal? This proposal has been hardly discussed during neutron meetings [2][3]. Many cores agree that the number of reviews shouldn't be the only metrics. And

Re: [openstack-dev] [Fuel][Nailgun] Web framework

Well, I think if the general direction is to make Fuel using OpenStack tools and libraries as much as it's possible, that makes sense to use Pecan. Otherwise I'd prefer to swap web.py with Flask. Sincerely yours, Ivan Kliuk On 12/2/14 16:55, Igor Kalnitsky wrote: Hi, Sebastian, Thank you for

Re: [openstack-dev] [nova] Can the Kilo nova controller conduct the Juno compute nodes

On Wed, Dec 3, 2014 at 11:53 AM, Li Junhong wrote: > Hi Joe, > > Just want to confirm one more question, in the gate testing, is the > neutron/cinder/glance Kilo or Juno. Or in another word, is the controller > in gate testing an all-in-one controller? > Great question. In our current test neutr

Re: [openstack-dev] [neutron] Changes to the core team

Congratulations to Henry and Kevin, very well deserved!, keep up the good work! :) Miguel Ángel Ajo On Wednesday, 3 de December de 2014 at 09:44, Oleg Bondarev wrote: > +1! Congrats, Henry and Kevin! > > On Tue, Dec 2, 2014 at 6:59 PM, Kyle Mestery (mailto:mest...@mestery.com)> wrote: > > N

Re: [openstack-dev] [nova] [libvirt] enabling per node filtering of mempage sizes

On Wed, Dec 03, 2014 at 10:03:06AM +0100, Sahid Orentino Ferdjaoui wrote: > On Tue, Dec 02, 2014 at 07:44:23PM +, Mooney, Sean K wrote: > > Hi all > > > > I have submitted a small blueprint to allow filtering of available memory > > pages > > Reported by libvirt. > > Can you address this wi

[openstack-dev] [tripleo] Managing no-mergepy template duplication

Hi all, Lately I've been spending more time looking at tripleo and doing some reviews. I'm particularly interested in helping the no-mergepy and subsequent puppet-software-config implementations mature (as well as improving overcloud updates via heat). Since Tomas's patch landed[1] to enable --no

Re: [openstack-dev] [neutron] Private external network

There is a current blueprint under discussion[1] which would have covered the external network access control as well, however it looks like the scope is going to have to be reduced for this cycle so it will be limited to shared networks if it's accepted at all. 1. https://review.openstack.org/#/c

Re: [openstack-dev] [stable] Exception proposals for 2014.2.1

Doug Hellmann wrote: > > On Dec 2, 2014, at 5:41 PM, Alan Pevec wrote: > General: cap Oslo and client library versions - sync from openstack/requirements stable/juno, would be good to include in the release. https://review.openstack.org/#/q/status:open+branch:stable/juno+topi

Re: [openstack-dev] [neutron] Private external network

Hi, I'm picking up this thread from a few months ago, as I have a requirement for a private external network and after doing some testing today came to the conclusion that this isn't currently possible. Rats. On Tue, 2014-10-14 at 17:42 +, A, Keshava wrote: > Hi, > > Across these private Ext

  1   2   >