Re: [openstack-dev] [Neutron] Proposing Cedric Brandily to Neutron Core Reviewer Team

Congratulations Cedric. ☺ From: Miguel Lavalle [mailto:mig...@mlavalle.com] Sent: Wednesday, July 22, 2015 10:32 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] Proposing Cedric Brandily to Neutron Core Reviewer Team Congrats Cedric! On

[openstack-dev] [Congress] Need reviews of bp rpc-for-dse

Hi all, I have some thoughts about congress dse improvement after having read the code for several days. Please refer to bp/rpc-for-dse, its idea is to implement RPC in deepsix. Congress can benefit from lower-coupling between dse

Re: [openstack-dev] [CI] Jenkins jobs are not executed when setting up a new CI system.

Hi, all The Jenkins jobs submitted by zuul are always "pending—Waiting for next available executor" . And Jenkins log shows the following: Jul 24, 2015 11:09:04 AM hudson.plugins.gearman.MyGearmanWorkerImpl submitFunction WARNING: Worker _exec-0 exception while executing function hudso

Re: [openstack-dev] [TripleO] Moving instack upstream

See below On 21/07/15 20:29, Derek Higgins wrote: Hi All, Something we discussed at the summit was to switch the focus of tripleo's deployment method to deploy using instack using images built with tripleo-puppet-elements. Up to now all the instack work has been done downstream of tripleo as

[openstack-dev] [mistral] BPMN support

Hi, We had a question from our OSS team about the level of support of BPMN in Mistral, Is there any plan to include that support? Did you heard from other people on the community around the need for that? Thanks, Noy __ Open

Re: [openstack-dev] [Congress] Need reviews of bp rpc-for-dse

Hi Yingxin, I think moving Congress from dse to rpc is a good idea. Congress team will discuss its scalability in mid cycle sprint[1], [2]. I guess using rpc is one of key item for congress to get the ability. Why don't you join the meetup? [1] https://wiki.openstack.org/wiki/Sprints/Congres

Re: [openstack-dev] [designate] The designate API service is stopped

Interesting, It would be great to know what causes the crash if you can identify it. What was previously between the designate components and qpid? Simple router? Stateful firewall? Something else? Thanks, Kiall On 22/07/15 10:53, Jaime Fernández wrote: I moved the virtual machine where desi

[openstack-dev] [Tricircle] open design of tricircle, the first BP

Hello, all, Welcome to review and comment on the open design of tricircle, the first BP https://blueprints.launchpad.net/tricircle/+spec/new-design Detailed discussion can also be found on the weekly meeting log: https://wiki.openstack.org/wiki/Meetings/Tricircle Best Regards Chaoyi Huang ( Jo

[openstack-dev] [Fuel][python-fuelclient] Implementing new commands

Hi folks, For a some time in python-fuelclient we have two CLI apps: `fuel` and `fuel2`. It was done as an implementation of blueprint [1]. Right now there is a situation where some new features are added just to old `fuel`, some to just `fuel2`, some to both. We cannot simply switch completely to

Re: [openstack-dev] [oslo.serialization] Security or convenience?

Angus, yes, oslo.serialization should "remain suitable for security-sensitive purposes". i don't believe we use either of the features today and no intention to add it the future. -- dims On Thu, Jul 23, 2015 at 12:56 AM, Angus Lees wrote: > I'm working on a draft spec[1] for a new privilege se

[openstack-dev] [Fuel] Get rid of fuelmenu

Dear colleagues, What do you think of getting rid of fuelmenu and substituting it with thoroughly commented text file + some validation + vim? The major pro of this is that text file is easier to extend and edit. Many people prefer vim UX instead of wandering through the semi-graphical interface.

Re: [openstack-dev] [Fuel] Get rid of fuelmenu

We had that before and had very poor validation. Removing fuelmenu would make the experience quite manual and prone to errors. This topic comes up once a year only from Fuel Python developers because they rarely use it and no dev cycles have been invested in improving it. The actual Fuel deployer

Re: [openstack-dev] [nova] Exposing provider networks in network_data.json

On Thu, Jul 16, 2015 at 04:23:29PM -0400, Mathieu Gagné wrote: > Hi, > > I stubble on this review [1] which proposes adding info about provider > networks in network_data.json. > > > > [1] https://review.openstack.org/#/c/152703/5 > Just to loop back on this - we talked about it a bit at the

Re: [openstack-dev] [Ironic] NoFreeConductorWorker going away with move to Futurist?

On Wed, Jul 22, 2015 at 02:40:47PM +0200, Dmitry Tantsur wrote: > Hi all! > > Currently _spawn_worker in the conductor manager raises > NoFreeConductorWorker if pool is already full. That's not very user friendly > (potential source of retries in client) and does not map well on common > async wor

[openstack-dev] [Ironic] [Oslo] Question about Futurist executors (was: NoFreeConductorWorker going away with move to Futurist?)

Jim, I'm redirecting your question to oslo folks, as I'm afraid my answer can be wrong. On 07/23/2015 01:55 PM, Jim Rollenhagen wrote: On Wed, Jul 22, 2015 at 02:40:47PM +0200, Dmitry Tantsur wrote: Hi all! Currently _spawn_worker in the conductor manager raises NoFreeConductorWorker if poo

[openstack-dev] [neutron] why do we gate tempest using q-vpn not q-l3?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all, I've stumbled on this one. It turns out we gate neutron against openstack installation that runs vpn-agent instead of l3-agent [1]. Is it really what we want to do? I would expect that gate validates l3 agent as is, as is usually found on us

Re: [openstack-dev] [Fuel] Get rid of fuelmenu

Hello, Here's my 2 cents on it. I think the effort we put to support fuelmenu doesn't worth it. I used to deploy fuel too often in previous release, and I never used features of fuelmenu? Why? Because I prefer to apply changes on already deployed node. Moreover, I don't like that users are prompt

[openstack-dev] [Manila] Midcycle meetup next week

This is just a reminder that the Manila midcycle meetup is next week (July 29-30). Please add your name to the etherpad if you intend to join! If you have a topic to discuss it's not too late to suggest it. https://etherpad.openstack.org/p/manila-liberty-midcycle-meetup -Ben Swartzlander ___

[openstack-dev] [Log] Log Working Group weekly meeting

Hi all, Log Working Group has been running weekly meetings Wednesdays at 20:00 UTC. There were queries while back to adjust the meeting time to facilitate EMEA/APJ folks bit better. Current regular participants are fine with the time we're having the meeting now, but we wanted to probe the com

Re: [openstack-dev] [Fuel] Get rid of fuelmenu

How much effort are we spending? I'm not so sure it's a major development drain. Since Fuel 6.0 dev cycle (Sept 2014) until now there have been 34 commits into Fuelmenu: * New features/functionality: 12 * Bugfix: 15 * Other: 7 (version bumps, and commits without bug ID) Across 3 releases, that's

Re: [openstack-dev] [neutron] why do we gate tempest using q-vpn not q-l3?

It's a remnant of pre-*aaS split times - We have to reexamine our testing strategy post-split. - Original Message - > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi all, > > I've stumbled on this one. It turns out we gate neutron against > openstack installation that runs vpn-a

[openstack-dev] [Rally][Meeting][Agenda]

Hi, its a friendly reminder that if you what to discuss some topics at Rally meetings, please add you topic to our Meeting agenda https://wiki.openstack.org/wiki/Meetings/Rally#Agenda. Don't forget to specify by whom led this topic. Add some information about topic(links, etc.) Thank you for your a

Re: [openstack-dev] [Congress] Need reviews of bp rpc-for-dse

Hi Yingxin, +1 to joining the sprint. If you can't make the mid-cycle sprint in person, we're planning to have a remote option. Keep in mind though that it will be harder to engage with everyone if you're remote. We'll review your spec and get you feedback, but the purpose of the sprint (Aug 6-

Re: [openstack-dev] [Neutron][Kuryr] - Bringing Dockers networking to Neutron

Gal, I vote for Monday 1600UTC. Thanks, Yapeng From: Mohammad Banikazemi [mailto:m...@us.ibm.com] Sent: Thursday, July 23, 2015 1:30 AM To: OpenStack Development Mailing List (not for usage questions) Cc: Eran Gampel; Irena Berezovsky; Antoni Segura Puimedon Subject: Re: [openstack-dev] [Neutron

Re: [openstack-dev] [nova] Status of identity v3 support

On 7/22/2015 10:18 PM, Adam Young wrote: On 07/15/2015 06:38 PM, melanie witt wrote: Hi Everyone, Recently I have started reviewing the patch series about nested quotas in nova [1] and I'm having trouble understanding where we currently are with identity v3 support in nova. From what I read

Re: [openstack-dev] [nova] Status of identity v3 support

On 07/23/2015 10:08 AM, Matt Riedemann wrote: On 7/22/2015 10:18 PM, Adam Young wrote: On 07/15/2015 06:38 PM, melanie witt wrote: Hi Everyone, Recently I have started reviewing the patch series about nested quotas in nova [1] and I'm having trouble understanding where we currently are wit

Re: [openstack-dev] [Fuel][python-fuelclient] Implementing new commands

Hi, The best option is to add new functionality to fuel2 only, but I don't think that we can do that if there is not enough functionality in fuel2, we should not ask user to switch between fuel and fuel2 to get some specific functionality. Do we have some list of commands which is not covered in f

Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

On Wed, Jul 22, 2015 at 3:00 PM, Kevin Benton wrote: >>It seems to me that the existence of the multiprovider extension is an >> important point for this discussion. Multiprovider, as I understand it, >> allows describing a network composed of multiple L2 segments with implicit >> east-west routi

Re: [openstack-dev] [Fuel] Get rid of fuelmenu

Unless I am mistaken, it is possible to set most of the parameters supported by Fuel menu as kernel boot parameters. Isn't it sufficient replacement for fuelmenu for dev's purposes? -Oleg On Thu, Jul 23, 2015 at 4:05 PM, Matthew Mosesohn wrote: > How much effort are we spending? I'm not so sure

[openstack-dev] [cross-project] "Admin" ness not properly scoped

I a user has an admin role anywhere, they have it everywhere. This is bug https://bugs.launchpad.net/keystone/+bug/968696 and, in order to fix it we are going to have to adjust our thinking on policy checks. Here is the theory: A user is assigned a role on a project. Policy uses the roles ass

Re: [openstack-dev] [Congress] Need reviews of bp rpc-for-dse

Tim and Masa, Thanks very much for your invitation. I really wish I could come, but there is a visa problem. I’m interested in Congress implementation and will join the sprint in remote. Hope that my idea is helpful. Yingxin From: Tim Hinrichs [mailto:t...@styra.com] Sent: Thursday, July 2

Re: [openstack-dev] [keystone] token revocation woes

On Wed, Jul 22, 2015 at 10:06 PM, Adam Young wrote: > On 07/22/2015 05:39 PM, Adam Young wrote: > > On 07/22/2015 03:41 PM, Morgan Fainberg wrote: > > This is an indicator that the bottleneck is not the db strictly speaking, > but also related to the way we match. This means we need to spend som

Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

>Or, migration scheduling would need to respect the constraint that a port may be confined to a set of hosts. How can be assign a port to a different network? The VM would wake up and what? How would it know to reconfigure its network stack? Right, that's a big mess. Once a network is picked fo

[openstack-dev] [nova] Create a network filter

Hi all, I'm using OpenStack together with OpenDaylight to add a network awareness feature to the scheduler. I have 3 compute nodes (one of these is also the Openstack Controller) connected by a openvswitch controlled by OpenDaylight. What I would like to do is to write a filter to check if a link

Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

On Thu, Jul 23, 2015 at 8:51 AM, Kevin Benton wrote: >>Or, migration scheduling would need to respect the constraint that a > port may be confined to a set of hosts. How can be assign a port to a > different network? The VM would wake up and what? How would it know > to reconfigure its network

Re: [openstack-dev] [Fuel] Get rid of fuelmenu

Hi, > Am I alone in thinking it's not the best use of our development > resources to throw it away and replace it with a text file that is > edited by hand? Nope. I'm with you :) > Many people prefer vim UX instead of wandering through the semi-graphical interface. Are those ppl developers or e

[openstack-dev] [openstack][nova] Streamlining of config options in nova

Hi all, During development process in nova I faced with an issue related with config options. Now we have lists of config options and registering options mixed with source code in regular files. From one side it can be convenient: to have module-encapsulated config options. But problems appear wh

[openstack-dev] [Fuel] Nominating Vladimir Kozhukalov to core reviewers of fuel-main

At the moment we have several core reviewers for the fuel-main project. Roman Vyalov is responsible for merging of infrastructure-related variables and for the lists of packages. I am responsible for merges in make system. And I have not so much time for digging into makefiles. Vladimir Kozhukalo

Re: [openstack-dev] [Fuel] Get rid of fuelmenu

Oleg, those parameters are no longer documented (because there was no validation) and are absent from the Fuel User Guide. They are, however, still used by fuel-qa scripts. On Thu, Jul 23, 2015 at 5:26 PM, Oleg Gelbukh wrote: > Unless I am mistaken, it is possible to set most of the parameters su

Re: [openstack-dev] [Congress] Need reviews of bp rpc-for-dse

Hi Yingxin, We definitely want details for what you have in mind. In case you haven't done this before, we write a 'spec' to explain the details. Here's some info on how to do that. https://wiki.openstack.org/wiki/Congress#How_To_Propose_a_New_Feature Tim On Thu, Jul 23, 2015 at 12:13 AM Ch

Re: [openstack-dev] [Fuel] Get rid of fuelmenu

On Thu, Jul 23, 2015 at 4:05 PM, Matthew Mosesohn mailto:mmoses...@mirantis.com>> wrote: Here's a relic of what users used to have to configure by hand: https://github.com/stackforge/fuel-library/blob/b015ed975b58dddff3b8da0ce34d9a638c22d032/deployment/puppet/openstack/examples/s

Re: [openstack-dev] [Neutron][Kuryr][kolla] - Bringing Dockers networking to Neutron

Gal, I’m not clear exactly what you plan to do with regards to building docker containers for Neutron, but the Kolla project has developed both linuxbridge and ovs agents as well as a complete running Neutron system inside container technology. We can launch it AIO with docker-compose, or alte

Re: [openstack-dev] [Fuel] Nominating Vladimir Kozhukalov to core reviewers of fuel-main

+1. On Thu, Jul 23, 2015 at 6:14 PM, Dmitry Pyzhov wrote: > At the moment we have several core reviewers for the fuel-main project. > > Roman Vyalov is responsible for merging of infrastructure-related variables > and for the lists of packages. > I am responsible for merges in make system. And I

Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

On Wed, Jul 22, 2015 at 3:21 PM, Kevin Benton wrote: > The issue with the availability zone solution is that we now force > availability zones in Nova to be constrained to network configuration. In > the L3 ToR/no overlay configuration, this means every rack is its own > availability zone. This is

Re: [openstack-dev] [Fuel] Nominating Vladimir Kozhukalov to core reviewers of fuel-main

+1 On Thu, Jul 23, 2015 at 6:14 PM, Dmitry Pyzhov wrote: > At the moment we have several core reviewers for the fuel-main project. > > Roman Vyalov is responsible for merging of infrastructure-related > variables and for the lists of packages. > I am responsible for merges in make system. And I

Re: [openstack-dev] [openstack][nova] Streamlining of config options in nova

On Thu, 2015-07-23 at 17:55 +0300, mhorban wrote: > During development process in nova I faced with an issue related with config > options. Now we have lists of config options and registering options mixed > with source code in regular files. > From one side it can be convenient: to have module-en

Re: [openstack-dev] [CI] Jenkins jobs are not executed when setting up a new CI system.

Are you running on 'master' nodes? I remember seeing an issue where with a recent version of Jenkins or a plugin where it doesn't execute jobs on the master node. But when run on non-master jenkins slaves, it works fine. -Original Message- From: Tang Chen [mailto:tangc...@cn.fujitsu.com]

Re: [openstack-dev] [neutron] why do we gate tempest using q-vpn not q-l3?

On 23 July 2015 at 05:25, Ihar Hrachyshka wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi all, > > I've stumbled on this one. It turns out we gate neutron against > openstack installation that runs vpn-agent instead of l3-agent [1]. Is > it really what we want to do? I would exp

[openstack-dev] [glance][api] Response when a illegal body is sent

Hi, Currently when a body is passed to an API operation that explicitly does not allow bodies Glance throws a 500. Such as in this bug report: https://bugs.launchpad.net/glance/+bug/1475647 This is an example of a GET however this also applies to other requests. What should Glance do rather th

[openstack-dev] [Magnum] Retirement of heat-coe-templates

Hello, After a discussion in our weekly meeting[1] and in a ML thread[2] we have decided to retire the heat-coe-templates[3] repository and move it to openstack-attic[4]. Initially this repository was intended to replace heat-kubernetes[5] and the templates in the Magnum repo. However the object

Re: [openstack-dev] [glance][api] Response when a illegal body is sent

On 07/23/2015 10:53 AM, Bunting, Niall wrote: Hi, Currently when a body is passed to an API operation that explicitly does not allow bodies Glance throws a 500. Such as in this bug report: https://bugs.launchpad.net/glance/+bug/1475647 This is an example of a GET however this also applies to ot

Re: [openstack-dev] [Fuel][python-fuelclient] Implementing new commands

Hi, can we just add all needed functionality from old fuel client that fuel2 needs, then say that old fuel-client is deprecated now and will not support some new features, then add new features to fuel2 only? It seems like best way for me, cause with this approach: 1. Clients will can use only one

Re: [openstack-dev] [Fuel] Nominating Vladimir Kozhukalov to core reviewers of fuel-main

+1 On Thu, Jul 23, 2015 at 10:43 AM, Roman Vyalov wrote: > +1 > > On Thu, Jul 23, 2015 at 6:14 PM, Dmitry Pyzhov > wrote: > >> At the moment we have several core reviewers for the fuel-main project. >> >> Roman Vyalov is responsible for merging of infrastructure-related >> variables and for the

Re: [openstack-dev] [Ironic] [Oslo] Question about Futurist executors

Dmitry Tantsur wrote: Jim, I'm redirecting your question to oslo folks, as I'm afraid my answer can be wrong. On 07/23/2015 01:55 PM, Jim Rollenhagen wrote: On Wed, Jul 22, 2015 at 02:40:47PM +0200, Dmitry Tantsur wrote: Hi all! Currently _spawn_worker in the conductor manager raises NoFreeC

Re: [openstack-dev] [openstack][nova] Streamlining of config options in nova

Hi all, FWIW, this is exactly what we have in oslo libs, e.g. in oslo.db [0] Putting all Nova options into one big file is probably not a good idea, still we could consider storing those per-package (per backend, per driver, etc), rather than per Python module to reduce the number of possible cir

Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

On Wed, Jul 22, 2015 at 3:00 PM, Kevin Benton wrote: > I proposed the port scheduling RFE to deal with the part about selecting a > network that is appropriate for the port based on provided hints and > host_id. [1] Thanks for the pointer. I hadn't paid much attention to this RFE yet. >>the neu

Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

On Tue, Jul 21, 2015 at 8:41 AM, Salvatore Orlando wrote: > It is however important to ensure services like DHCP keep working as usual. > Treating segments as logical networks in their own right is the simples > solution to achieve this imho. Agreed. > While the logical model and workflow you de

Re: [openstack-dev] [openstack][nova] Streamlining of config options in nova

On 07/23/2015 11:23 AM, Roman Podoliaka wrote: > Hi all, > > FWIW, this is exactly what we have in oslo libs, e.g. in oslo.db [0] > > Putting all Nova options into one big file is probably not a good > idea, still we could consider storing those per-package (per backend, > per driver, etc), rathe

Re: [openstack-dev] [glance][api] Response when a illegal body is sent

On 07/23/2015 12:13 PM, Jay Pipes wrote: > On 07/23/2015 10:53 AM, Bunting, Niall wrote: >> Hi, >> >> Currently when a body is passed to an API operation that explicitly >> does not allow bodies Glance throws a 500. >> >> Such as in this bug report: >> https://bugs.launchpad.net/glance/+bug/1475647

Re: [openstack-dev] [Fuel] Get rid of fuelmenu

The topic is NOT 'get rid of validation' but rather 'get rid of semi-graphical ncurses based interface'. It is not so hard to adopt every piece of validation we currently have in fuelmenu and implement even more including syntax validation using, for example, PLY and logic validation. My idea is to

[openstack-dev] [fuel] [FFE] FF Exception request for Custom node attributes feature

Team, I would like to request an exception from the Feature Freeze for CLI changes of working with custom node labels added to fuelclient (fuel2) [1]. UI and Nailgun parts of the story are already merged [2]. There CLI request is being actively reviewed, the base flow is accepted. There are minim

Re: [openstack-dev] [Fuel] Get rid of fuelmenu

-1 for using kernel parameters for configuring the whole master node installation. User should be able to edit configuration and then re-deploy the master node. I have no idea what would UX look like if we used kernel paramenters. Vladimir Kozhukalov On Thu, Jul 23, 2015 at 7:49 PM, Vladimir Kozh

Re: [openstack-dev] [openstack][nova] Streamlining of config options in nova

In fact, I did an example of what I thought it would look like already: https://review.openstack.org/#/c/205154/ I welcome discussion on this, especially from people who couldn't make it to the mid-cycle. Its up to y'all if you do that on this thread or in that review. Michael On Thu, Jul 2

Re: [openstack-dev] [openstack][nova] Streamlining of config options in nova

On 07/23/2015 11:41 AM, Sean Dague wrote: On 07/23/2015 11:23 AM, Roman Podoliaka wrote: Hi all, FWIW, this is exactly what we have in oslo libs, e.g. in oslo.db [0] Putting all Nova options into one big file is probably not a good idea, still we could consider storing those per-package (per b

[openstack-dev] [requirements][all] stop merging requirements changes

Because of a faulty test, we've been merging some bad requirements changes. Please do not approve any more changes until the fixes for the tests have been merged: https://review.openstack.org/#/c/204181 https://review.openstack.org/#/c/204198 Thanks, Doug

Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

" John Belamaric made a good point that the closest thing that we have to representing an L3 domain right now is a subnet pool." This is actually a really good point. If you take the example of a L3 network that spans segments, you could put something like a /16 into a subnet pool. That /16 c

Re: [openstack-dev] [Fuel] Get rid of fuelmenu

For this to be consumable by end-users, a config file and editor (vim seriously?) is terrible UX. We need to remember who we are targeting to consume this functionality as it may not be an expert or even someone absolutely familiar with the linux tool set. While the existing thing may be awkward,

Re: [openstack-dev] [cross-project] "Admin" ness not properly scoped

On Jul 23, 2015, at 7:35, Adam Young wrote: > What this means is the if a user is assigned "admin" on any project, they are > assigned admin for everything. > > Fixing this is going to require a change to how we write policy. > > Each policy rule needs to have two parts: > > 1. Match the sco

Re: [openstack-dev] [horizon] Minimum Unit Test Coverage

+1 on coverage of any kind. >From a tooling perspective, are you thinking istanbul? >From an infra perspective, are you thinking a separate job, or to have it integrated in with npm run test? FYI- istanbul wraps the unit test invocation, e.g. 'istanbul karma start ./karma.config.js' or something

Re: [openstack-dev] [Fuel] Nominating Vladimir Kozhukalov to core reviewers of fuel-main

+1 On Thu, Jul 23, 2015, 09:32 Stanislaw Bogatkin wrote: > +1 > > On Thu, Jul 23, 2015 at 10:43 AM, Roman Vyalov > wrote: > >> +1 >> >> On Thu, Jul 23, 2015 at 6:14 PM, Dmitry Pyzhov >> wrote: >> >>> At the moment we have several core reviewers for the fuel-main project. >>> >>> Roman Vyalov i

Re: [openstack-dev] [keystone] token revocation woes

On 07/23/2015 10:45 AM, Lance Bragstad wrote: On Wed, Jul 22, 2015 at 10:06 PM, Adam Young > wrote: On 07/22/2015 05:39 PM, Adam Young wrote: On 07/22/2015 03:41 PM, Morgan Fainberg wrote: This is an indicator that the bottleneck is not the db strictly

Re: [openstack-dev] [Fuel] Get rid of fuelmenu

I'm against getting rid of fuelmenu. As Alex wrote - we need to remember who are the people that we are targeting. We are adding multiple dialog windows with confirmations, warnings and special way to do dangerous actions (like environment deletion or reset), but in the same time we want to force u

Re: [openstack-dev] [Fuel] Nominating Vladimir Kozhukalov to core reviewers of fuel-main

+1 2015-07-23 19:23 GMT+02:00 Dmitry Borodaenko : > +1 > > On Thu, Jul 23, 2015, 09:32 Stanislaw Bogatkin > wrote: > >> +1 >> >> On Thu, Jul 23, 2015 at 10:43 AM, Roman Vyalov >> wrote: >> >>> +1 >>> >>> On Thu, Jul 23, 2015 at 6:14 PM, Dmitry Pyzhov >>> wrote: >>> At the moment we have s

Re: [openstack-dev] [Neutron][Kuryr][kolla] - Bringing Dockers networking to Neutron

I let the creators of the project speak for themselves but here is my take on project Kuryr. The goal is not to containerize Neutron or other OpenStack services. The main objective is to use Neutron as a networking backend option for Docker. The original proposal was to do so in the context of usi

Re: [openstack-dev] [horizon] Minimum Unit Test Coverage

I was referring to the HTML reports that the karma-coverage plugin creates for now. From my experience with it, it’s fairly relaxed about what counts as something being tested, hence the 100% aim. For example, often just checking that a value is defined is enough for it to be “tested”, and this

Re: [openstack-dev] [fuel] [FFE] FF Exception request for Custom node attributes feature

Hi Julia, I'm ok with FF exception for CLI part. I don't think it can somehow decrease product quality, so as a core I'll help to land it. Thanks, Igor On Thu, Jul 23, 2015 at 7:50 PM, Julia Aranovich wrote: > Team, > > I would like to request an exception from the Feature Freeze for CLI change

[openstack-dev] Fwd: [MOS] [fuel-library] [keystone] [FFE] FF Exception request for Fernet tokens support.

-- Forwarded message -- From: Alexander Makarov Date: Thu, Jul 23, 2015 at 5:30 PM Subject: [MOS] [fuel-library] [keystone] [FFE] FF Exception request for Fernet tokens support. To: Vitaly Sedelnik , Eugene Bogdanov < ebogda...@mirantis.com>, Igor Marnat , Ilya Elterman < ielter...

Re: [openstack-dev] [Fuel] Nominating Vladimir Kozhukalov to core reviewers of fuel-main

+1 On Thu, Jul 23, 2015 at 6:14 PM, Dmitry Pyzhov wrote: > At the moment we have several core reviewers for the fuel-main project. > > Roman Vyalov is responsible for merging of infrastructure-related > variables and for the lists of packages. > I am responsible for merges in make system. And I

Re: [openstack-dev] [fuel] [FFE] FF Exception request for Custom node attributes feature

+1 for this FFE as it's important to have this functionality covered in CLI 2015-07-23 19:46 GMT+02:00 Igor Kalnitsky : > Hi Julia, > > I'm ok with FF exception for CLI part. I don't think it can somehow > decrease product quality, so as a core I'll help to land it. > > Thanks, > Igor > > On Thu,

Re: [openstack-dev] [Fuel][python-fuelclient] Implementing new commands

2015-07-23 18:28 GMT+02:00 Stanislaw Bogatkin : > Hi, > > can we just add all needed functionality from old fuel client that fuel2 > needs, then say that old fuel-client is deprecated now and will not support > some new features, then add new features to fuel2 only? It seems like best > way for me

Re: [openstack-dev] [fuel] [FFE] FF Exception request for Env Upgrade feature

Hi, The patch into Nailgun requires additional work to do, but as far as I can see it doesn't affect any other parts of the system, also it's implemented as an extension, which means if the feature will introduce bugs which we won't be able to fix in a required time, it can be easily disabled with

Re: [openstack-dev] [keystone] token revocation woes

Morgan asked me to post some of my numbers here. From my staging environment: With 0 revocations: Requests per second:104.67 [#/sec] (mean) Time per request: 191.071 [ms] (mean) With 500 revocations: Requests per second:52.48 [#/sec] (mean) Time per request: 381.103 [ms] (mean

Re: [openstack-dev] [openstack][nova] Streamlining of config options in nova

On Thu, 2015-07-23 at 11:41 -0500, Sean Dague wrote: > On 07/23/2015 11:23 AM, Roman Podoliaka wrote: > > Hi all, > > > > FWIW, this is exactly what we have in oslo libs, e.g. in oslo.db [0] > > > > Putting all Nova options into one big file is probably not a good > > idea, still we could conside

Re: [openstack-dev] [cross-project] "Admin" ness not properly scoped

On 07/23/2015 01:11 PM, melanie witt wrote: On Jul 23, 2015, at 7:35, Adam Young wrote: What this means is the if a user is assigned "admin" on any project, they are assigned admin for everything. Fixing this is going to require a change to how we write policy. Each policy rule needs to hav

Re: [openstack-dev] [Neutron][Kuryr][kolla] - Bringing Dockers networking to Neutron

For my low-orbit perspective (I would have lied if I said 10,000 or 30,000 ft!) Kuryr's ultimate goal is to provide: 1) a container-oriented set of neutron plugins and drivers (you know the ML2 driver, a l3 svc plugin, a lbaas driver, etc. etc.) 2) possibly (I'm not sure if that's the case) control

Re: [openstack-dev] [fuel] [FFE] FF Exception request for Env Upgrade feature

Oleg, considering that your feature is essential for the release, sounds like there is no way we can't give an exception. I'm glad that it's perceived by low risk by core reviewer from Nailgun team (Evgeny). If there are no concerns from other, then we are giving FF exception. However, I'd like to

[openstack-dev] [fuel] Meeting 7/23

Today's meeting was a little hectic, if you have a topic on the agenda, ensure you are present and ready to speak, or move your topic lower in the agenda. When possible, pre-type you main points of discussion and copy and paste it into the channel when your topic comes up. This tends to save a bit

Re: [openstack-dev] [Neutron][Kuryr] - Bringing Dockers networking to Neutron

+1 for Monday On Wed, Jul 22, 2015 at 10:29 PM, Mohammad Banikazemi wrote: > Gal, This time conflicts with the Neutron ML2 weekly meeting time [1]. I > realize there are several networking related weekly meetings, but I would > like to see if we can find a different time. I suggest the same time

Re: [openstack-dev] [Neutron][Kuryr][kolla] - Bringing Dockers networking to Neutron

On Thu, Jul 23, 2015 at 7:35 PM, Mohammad Banikazemi wrote: > I let the creators of the project speak for themselves but here is my take > on project Kuryr. > > The goal is not to containerize Neutron or other OpenStack services. The > main objective is to use Neutron as a networking backend opti

Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature

Looks like the only CLI part left: https://review.openstack.org/#/c/204321/, and you guys did a great job finishing the other two. Looks like we'd need to give FF exception, as this is essential feature. It's glad that we merged all other thousands lines of code. This is the most complex feature,

Re: [openstack-dev] [fuel] Meeting 7/23

Yep, forgot to include the topics i referred to Topics not covered in todays meeting, but requested in the agenda * ubuntu based bootstrap has been merged, needs thorough testing (kozhukalov) * Let's switch keystone under Apache right after FF (adidenko) * Separate services from controller status

Re: [openstack-dev] [kolla][magnum] Removal of Daneyon Hansen from the Core Reviewer team for Kolla

Agreed, everyone should do what they love - so I wish you the best of luck with the Magnum crew Daneyon! Op 22-07-15 om 22:47 schreef Steven Dake (stdake): Fellow Kolla developers, Daneyon has been instrumental in getting Kolla rolling and keeping our project alive. He even found me a new jo

Re: [openstack-dev] [Neutron][Kuryr][kolla] - Bringing Dockers networking to Neutron

This is great news! I can see our two projects working close together since we have aligned but not entirely overlapping goals. Antoni, please reach out on IRC at any time. #kolla is active almost 24/7 due to all of our different timezones. There is usually two cores talking at any given time. I w

Re: [openstack-dev] [fuel] [FFE] FF Exception request for Custom node attributes feature

-1 My concerns are the following: 1. This feature is of a High priority, not Essential [1] 2. We already had to give exception for flexible networking CLI part [2], as it is essential one. So basically that means we have a conflict of focus for SMEs in the area. 3. Just by working o

Re: [openstack-dev] Fwd: [MOS] [fuel-library] [keystone] [FFE] FF Exception request for Fernet tokens support.

Alexander, as this is purely Fuel related thing, please send a new one with right subject. It has to be [fuel] in subject, and that's it. No MOS, fuel-library, FFE please, we don't use any of those tags. No need to spam Keystone team too, as it's configuration related to Fuel only at this point of

[openstack-dev] [Neutron][SFC] Wiki update - deleting old SFC API

As a courtesy to anyone who may have worked on it, I wanted to notify the list that I'm going to delete [1] from wiki page [2]. I may actually delete [2] completely. I'm going to update the content on [3] to reference the new SFC API spec that has just been merged. Currently [3] links to [2] wh

Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

>We ran in to this long ago. What are some other examples? We've be good about keeping the network L2 only. Segments, VLAN transparency, and other properties of the network are all L2. The example you gave about needing the network to see the grouping of subnets isn't the network leaking into L3,

Re: [openstack-dev] [Fuel] Nominating Vladimir Kozhukalov to core reviewers of fuel-main

+1 On Thu, Jul 23, 2015 at 10:50 AM Evgeniy L wrote: > +1 > > On Thu, Jul 23, 2015 at 6:14 PM, Dmitry Pyzhov > wrote: > >> At the moment we have several core reviewers for the fuel-main project. >> >> Roman Vyalov is responsible for merging of infrastructure-related >> variables and for the lis

[openstack-dev] [fuel] FF Exception request for Fernet tokens support.

Colleagues, I would like to request an exception from the Feature Freeze for Fernet tokens support added to the fuel-library in the following CR: https://review.openstack.org/#/c/201029/ Keystone part of the feature is implemented in the upstream and the change impacts setup configuration only.

Re: [openstack-dev] Fwd: [MOS] [fuel-library] [keystone] [FFE] FF Exception request for Fernet tokens support.

That's my fault, I asked him to send it as I thought it also required review for FFE. On Jul 23, 2015 1:45 PM, "Mike Scherbakov" wrote: > Alexander, > as this is purely Fuel related thing, please send a new one with right > subject. It has to be [fuel] in subject, and that's it. No MOS, > fuel-li

  1   2   >