Re: [openstack-dev] [Neutron] Flavor framework proposal

all possible.) If >>> Octavia ever splits off and has its own API endpoint, it would need to >>> implement something like the Neutron flavor framework itself-- and in this >>> case, what we decide to do there should not affect the Neutron flavor >>> fram

[openstack-dev] [Neutron] Flavor Framework spec approval deadline exception

Hi folks, I'd like to request an exception for the Flavor Framework spec: https://review.openstack.org/#/c/102723/ It already have more or less complete server-side implementation: https://review.openstack.org/#/c/105982/ CLI will be posted on review soon. Thanks, Eugene. __

Re: [openstack-dev] [neutron] Cross-server locking for neutron server

In fact there are more applications for distributed locking than just accessing data in database. One of such use cases is serializing access to devices. This is what is not yet hardly needed, but will be as we get more service drivers working with appliances. It would be great if some existing li

Re: [openstack-dev] How to improve the specs review process (was Re: [Neutron] Group Based Policy and the way forward)

On Wed, Aug 6, 2014 at 11:07 PM, Stefano Maffulli wrote: > On 08/06/2014 11:19 AM, Edgar Magana wrote: > > That is the beauty of the open source projects, there is always a > smartest > > reviewer catching out the facts that you don¹t. > > And yet, the specification clearly talks about 'endpoints

[openstack-dev] [Neutron] Bug squashing day

Hi neutron folks, Today should have been 'Bug squashing day' where we go over existing bugs filed for the project and triage/prioritize/comment on them. I've created an etherpad with (hopefully) full list of neutron bugs: https://etherpad.openstack.org/p/neutron-bug-squashing-day-2014-08-07 I wa

Re: [openstack-dev] [LBaaS][Horizon] Subnet for VIP?

Hi Fank, That looks like Horizon limitation that is bound to current reference implementation of lbaas service where VIP should be on a subnet where pool's memebers are. So it's not a bug. Expect this to change in Icehouse. Thanks, Eugene. On Tue, Sep 24, 2013 at 9:19 AM, wrote: > Hi, > > Wh

Re: [openstack-dev] [neutron] VPNaaS questions

Hi folks, > I was wondering in general how providers can customize service features, > based on their capabilities (better or worse than reference). I could create > a Summit session topic on this, but wanted to know if this is something that > has already been addressed or if a different architec

[openstack-dev] [Neutron][LBaaS] LBaaS plans for Icehouse

Hi Neutron folks! We're going to have an IRC meeting where we will discuss development plans for LBaaS in Icehouse. Currently I'm proposing to meet on Thursday, 24 at 8:00 PDT on freenode #neutron-lbaas channel. Agenda for the meeting: 1. New features for lbaas in Icehouse Pretty much everything

Re: [openstack-dev] Testing before sending for review

Hi, 1. It's not necessary to abandon your patch if it has failed jenkins tests. 2. Before submitting the new patch for review it's better to run unit tests (tox -epy27) and pep8 check (tox -epep8) Integration testing is being done by check-tempest-devstack-vm-neutron* suites and some of them fail

Re: [openstack-dev] [Neutron][LBaaS] LBaaS plans for Icehouse

gt; > Thanks, > > -Sam. > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > *From:* Eugene Nikanorov [mailto:enikano...@mirantis.com] > *Sent:* Wednesday, October 23, 2013 11:51 AM > *To:* OpenStack Development Mailing List

Re: [openstack-dev] [Neutron][LBaaS] LBaaS plans for Icehouse

So currently it moves to 10AM PDT Thanks, Eugene. On Wed, Oct 23, 2013 at 9:07 PM, Sumit Naiksatam wrote: > So is it at 8 AM PDT, or 10 AM PDT? > > Thanks, > ~Sumit. > > > On Wed, Oct 23, 2013 at 4:18 AM, Eugene Nikanorov > wrote: > >> Hi Sam, >> >>

Re: [openstack-dev] [Neutron]LBaaS] - Questions on IP Allocation Logic for VIP

Hi Pattabi, I'll try to answer: 1) How does neutron/quantum checks if IP address is already used or not? Neutron server know which IPs it has given to ports, so if you try to specify the existing IP, the operation will fail. Although i'm not sure i understand 'data with NULL ID' statement. Could

[openstack-dev] [Neutron][LBaaS] Thursday meeting follow-up

Hi folks, Thanks to everyone who joined the meeting on Thursday. We've discussed desired features and changes in LBaaS service and identified dependencies between them. You can find them on etherpad: https://etherpad.openstack.org/p/neutron-icehouse-lbaas Most of the features are also captured in

[openstack-dev] [Neutron][LBaaS] Object status and admin_state_up

Hi folks, Currently there are two attributes of vips/pools/members that represent a status: 'status' and 'admin_state_up'. The first one is used to represent deployment status and can be PENDING_CREATE, ACTIVE, PENDING_DELETE, ERROR. We also have admin_state_up which could be True or False. I'd

Re: [openstack-dev] [Neutron][LBaaS] Object status and admin_state_up

*** > > So I am not sure we can come to a generic solution in the lbaas core code. > > > Thanks > > Avishay**** > > ** ** > > *From:* Eugene Nikanorov [mailto:enikano...@mirantis.com] > *Sent:* Tuesday, October 29, 2013 11:19 AM > *To:* OpenStack Deve

Re: [openstack-dev] [Neutron][LBaaS] Object status and admin_state_up

with admin status down, the > status should be moved to PENDING_UPDATE, when the driver implements this > than the status with be back to being ACTIVE. > > The Term ACTIVE, might be wrong in that it might be renamed to something > like APPLIED. > > ** ** > > Regards,

Re: [openstack-dev] [Openstack][Neutron] Server restart failes when configured with ML2 (BugID: 1210236)

That kind of error indicates that some ml2 driver or ml2 plugin failed to load. You need to inspect neutron server log prior to the trace you are posting, it should contain specific about the issue. Thanks, Eugene. On Tue, Nov 5, 2013 at 8:31 PM, Ben Nemec wrote: > Please don't cross-post be

Re: [openstack-dev] Bad review patterns

Hi! I would like do disagree with some of the points. First of all, '-1' mark may have a wrong perception especially among new contributors. -1 doesn't mean reviewers don't want your code (which is -2), it means they either not sure it is good enough or they see how you could make it better. > No

[openstack-dev] [Neutron][LBaaS] LBaaS Subteam meeting

Hi neutron and lbaas folks! We have a plenty of work to do for the Icehouse, so I suggest we start having regular weekly meetings to track our progress. Let's meet at #neutron-lbaas on Thursday, 14 at 15-00 UTC The agenda for the meeting is the following: 1. Blueprint list to be proposed for the

Re: [openstack-dev] [Neutron][LBaaS] LBaaS Subteam meeting

ngs#LBaaS_meeting is not > up-to-date. > The time is 1400UTC and the channel is #openstack-meeting. > I saw someone asked "is there LBaaS meeting today?" on > #openstack-meeting channel several times. > > Thanks, > Akihiro > > > On Wed, Nov 13, 2013 a

Re: [openstack-dev] [Neutron][LBaaS] LBaaS Subteam meeting

//wiki.openstack.org/wiki/Meetings as such, so I believe keeping > it in that timeslot should be fine. > > - Stephen > > > On Tue, Nov 12, 2013 at 7:40 AM, Eugene Nikanorov > wrote: > > I agree that it would be better to hold it on a channel with a bot which > > keeps

[openstack-dev] [Neutron][LBaaS] LBaaS subteam meeting Thursday, 14, at 14-00 UTC

Hi folks, LBaaS subteam meeting will be held on Thursday, 14 at 14-00 UTC on #openstack-meeting irc channel on freenode, as specified in https://wiki.openstack.org/wiki/Meetings#LBaaS_meeting The agenda is the following: 1. Blueprint list to be proposed for the icehouse-1 2. QA & third-party test

Re: [openstack-dev] [Neutron][LBaaS] LBaaS subteam meeting Thursday, 14, at 14-00 UTC

, > -Sam. > > On Nov 12, 2013, at 9:30 PM, "Eugene Nikanorov" > wrote: > > Hi folks, > > LBaaS subteam meeting will be held on Thursday, 14 at 14-00 UTC on > #openstack-meeting irc channel on freenode, as specified in > https://wiki.openstack.org

Re: [openstack-dev] [Neturon][Tempest] A test scenario for services

Hi Nachi and folks, Thanks for bringing this up. We started working on basic scenario testing for lbaas using tempest clients. We'll consider using heat for it. However I think we'll get something simple working at first (since we're not yet experts in tempest) then move to more complex topologies

Re: [openstack-dev] [Neutron][LBaaS] LBaaS Subteam meeting

re anyway at http://eavesdrop.openstack.org/meetings/ - but > sending an email will be useful to notify the rest of community about > progress/direction for each subteam. > > Salvatore > > > On 12 November 2013 19:20, Eugene Nikanorov wrote: > >> Ok, I'll repost date and

[openstack-dev] [Neutron][LBaaS] Meeting follow up

Follow up of the Thursdays meeting: Minutes: http://eavesdrop.openstack.org/meetings/neutron_lbaas/2013/neutron_lbaas.2013-11-14-14.00.html Minutes (text): http://eavesdrop.openstack.org/meetings/neutron_lbaas/2013/neutron_lbaas.2013-11-14-14.00.txt Log: http://eavesdrop.openstack.org/meetings/neu

[openstack-dev] [Neutron][LBaaS] Loadbalancer instance design.

Hi folks, I've created a brief description of this feature. You can find it here: https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance I would appreciate any comments/ideas about this. Thanks, Eugene. __

Re: [openstack-dev] [Neutron][LBaaS] Loadbalancer instance design.

r > > What's the plan about this ? > Is an extension for each (eg. add router_id to a loadblancer resource) > necessary ? > > Thanks. > Itsuro Oda > > On Fri, 15 Nov 2013 17:14:47 +0400 > Eugene Nikanorov wrote: > > > Hi folks, > > > > I'v

[openstack-dev] [Neutron][Tempest] Tempest API test for Neutron LBaaS

Hi folks, I'm working on major change to Neutron LBaaS API, obviously it will break existing tempest API tests for LBaaS. What would be the right process to deal with this? I guess I can't just push fixed tests to tempest because they will not pass against existing neutron code, and vice versa. T

Re: [openstack-dev] [Neutron][LBaaS] Loadbalancer instance design.

hen Gran < > stephen.g...@theguardian.com> wrote: > >> On 15/11/13 13:14, Eugene Nikanorov wrote: >> >>> Hi folks, >>> >>> I've created a brief description of this feature. >>> You can find it here: >>> https://wiki.openstack.org/w

[openstack-dev] [Neutron][LBaaS] Subteam meeting on Thursday, 21

Hi folks, Let's meet on #openstack-meeting on Thrsday, 21, at 14-00 UTC We'll discuss current progress and design of some of proposed features. Thanks, Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/c

[openstack-dev] [Quantum][LBaaS] Feedback needed: Healthmonitor workflow.

Hi community, Here's a question. Currently Health monitors in Loadbalancer service are made in such way that health monitor itself is a global shared database object. If user wants to add health monitor to a pool, it adds association between pool and health monitor. In order to update existing hea

[openstack-dev] [devstack][Quantum] Problem with rabbitmq

Hi folks, Recently I've faced strange problem with devstack on Ubuntu LTS 12.04. ./stack.sh script stalls on network creation, quantum net-create never returns response. More detailed investigation showed that quantum-server is stuck on connecting to amqp queue. Moreover, any other quantum agent d

Re: [openstack-dev] [OpenStack][python-quantumclient] unit test question

Hi, Can you post the code if failing test? Eugene. On Wed, Jun 26, 2013 at 2:11 AM, Kuang-Ching Wang wrote: > Hi, > > I am seeing the following error and cannot figure out why it happened and > how to solve it. Any advice would be appreciated. Thanks! > > UnexpectedMethodCallError: Unexpec

Re: [openstack-dev] Work around DB in OpenStack (Oslo, Nova, Cinder, Glance)

Boris, what do you think? Thanks, Eugene. On Tue, Jul 2, 2013 at 9:55 PM, Ben Nemec wrote: > One small addition I would suggest is a step to remove the unused > sqlalchemy-migrate code once this is all done. That's my main concern with > moving it to Oslo right now. > > Also, is this a formal

Re: [openstack-dev] [Neutron][LBaaS] Common agent based driver for LBaaS

I think the design should be documented on the wiki. Major part of such agent should be corresponding RPC API which then is shared between services. That needs to be thought out and discussed. Thanks, Eugene. On Thu, Jul 4, 2013 at 12:27 PM, Oleg Bondarev wrote: > Hi folks, > > While working on

Re: [openstack-dev] [Neutron][LBaaS] Common agent based driver for LBaaS

vices. > Did you mean device drivers rather than services? > > Thanks, > Oleg > > > On Thu, Jul 4, 2013 at 12:42 PM, Eugene Nikanorov > wrote: > >> I think the design should be documented on the wiki. >> Major part of such agent should be corresponding RPC AP

[openstack-dev] [Neutron] Service Type Framework implementation

Hi neutron folks, There has been a discussion around this patch https://review.openstack.org/#/c/29750/ that introduces configuration options and db table for storing service providers. The discussion is about whether we should store configuration in the db or not. The brief of discussion has bee

Re: [openstack-dev] [Neutron] Service Type Framework implementation

API (for admin) will add supports > - Ceate Service Type > - Delete Service Type > - Each driver users will lazy load the library if it is not loaded. > (may be this should be implemented on service side such as FW, > LBaaS,VPN) > > - Remove service type configuration from

Re: [openstack-dev] [Neutron] Service Type Framework implementation

> https://docs.google.com/presentation/d/1v0nLTEsFOwWeYpYjpw4qe3QHB5lLZEE_b0TmmR5b7ic/edit#slide=id.gf14b7b30_00 > > NOTE: I updated the style of doc > > Best > Nachi > > > 2013/7/9 Eugene Nikanorov : > > Hi Nachi, > > > > I agree on the future plan. &g

Re: [openstack-dev] [Neutron] Service Type Framework implementation

Ok, having so much pressure on db implementation, I think I'm just going to post in-memory implementation and we'll decide if it will fit our needs. Thanks, Eugene. On Wed, Jul 10, 2013 at 5:56 AM, Nachi Ueno wrote: > Hi Mark > > > 2013/7/9 Mark McClain : > > > > On Jul 9, 2013, at 5:37 PM, Na

Re: [openstack-dev] [Neutron] Service Type Framework implementation

specific provider to show its detail. > At now a provider has only a couple of visible field (type, name, default) > through API, so list-service-providers does enough and > show-service-provider > does not provide more. (It just provides API consistency with other > resources.) >

Re: [openstack-dev] [Neutron][LBaaS] Appliance support

Hi Ravi, There are plans to support appliances (hardware or virtual) but not for Havana. Regarding vendor contributions - I'd like to know it as well. Thanks, Eugene. On Thu, Jul 11, 2013 at 5:04 AM, Ravi Chunduru wrote: > Hi, > I would like to know if we have any plans/proposal to move fo

Re: [openstack-dev] Havana-2 milestone candidates available

Hi Thierry, Is openstack networking still released under 'quantum'? Thanks, Eugene. On Wed, Jul 17, 2013 at 4:48 PM, Thierry Carrez wrote: > Hi everyone, > > Milestone-proposed branches were created for Keystone, Glance, Nova, > Horizon, Networking, Cinder, Ceilometer and Heat in preparation

Re: [openstack-dev] [Neutron][Requirement] SQLAlchemy raises None, causes TypeError

Hi Nachi, Usually that exception is raised when something goes wrong during transaction commit (__exit__ of with block that we usually use) I do session.flush() manually to see specific exception in such cases. In case exception is potentially unavoidable, explicitly calling flush() seems to be a

Re: [openstack-dev] [Neutron] lbaas installation guide

Hi Quing. The guide on the wiki is a bit outdated and doesn't reflect recent project renaming from quantum to neutron. Currently lbaas can be configured via devstack, the only thing that needs to be done is line "enable_service q-lbaas" added to localrc. Feel free to ask any further questions. T

Re: [openstack-dev] [networking] quantum...oops neutron unit tests

Hi Armando, That happens from time to time. Thanks, Eugene. On Thu, Jul 25, 2013 at 5:22 AM, Jian Wen wrote: > Hello, > > I had trouble with run-tests.sh. > `tox -epy27` works. > > On Fri, Jun 21, 2013 at 12:32 AM, Armando Migliaccio < > amigliac...@nicira.com> wrote: > >> Folks, >> >> Is any

Re: [openstack-dev] Problem with nova add-fixed-ip or quantum port-update

Hi John, Can you take a look at https://bugs.launchpad.net/neutron/+bug/1190613 ? Looks like the exact issue you're talking about and it was fixed just recently. Thanks, Eugene. On Sat, Jul 27, 2013 at 10:22 PM, John Gruber wrote: > > So I got it work, but I need guidance from the OVS iptables

[openstack-dev] [Neutron][LBaaS][VPNaaS][FWaaS] Dealing with logical logical configurations

Hi folks, Recently we've been discussing with Nachi Ueno some specific use case of deployments with multiple providers for particular advanced service. What If admin wants to remove certain provider from configuration file? The following handling was proposed: 1) Before restarting neutron-server

Re: [openstack-dev] [Neutron][LBaaS][VPNaaS][FWaaS] Dealing with logical logical configurations

t; may fail to start up. > It is also nteresting the case when the provider name is not changed, but > the driver is changed. I have reason to believe this might lead to a bit of > mayhem; it *might* be manageable, but probably for Havana it might be just > worth documenting that this

Re: [openstack-dev] [Neutron][LBaaS][VPNaaS][FWaaS] Dealing with logical logical configurations

My comments inline On Wed, Jul 31, 2013 at 1:53 AM, Salvatore Orlando wrote: > > > On 30 July 2013 23:24, Eugene Nikanorov wrote: > >> 2) Resources allocated by the provider must be cleaned up - that is done >> before neutron server is restarted with new configuration.

Re: [openstack-dev] [Neutron][LBaaS][VPNaaS][FWaaS] Dealing with logical logical configurations

re > > > On 31 July 2013 09:23, Eugene Nikanorov wrote: > >> My comments inline >> >> >> On Wed, Jul 31, 2013 at 1:53 AM, Salvatore Orlando >> wrote: >> >>> >>> >>> On 30 July 2013 23:24, Eugene Nikanorov wrote: >>> >

Re: [openstack-dev] [Neutron][LBaaS][VPNaaS][FWaaS] Dealing with logical logical configurations

After this discussion I'm thinking about not adding comprehensive handling for provider removing case at all. Probably we'll need to document desired workflow and postpone cleanup feature until use cases are more clear. I like the idea of leaving resource in ERROR state. However, If we're not impl

Re: [openstack-dev] Devstack + ML2 setup issue

Hi Dmitry, This is known problem. It is being addressed by https://bugs.launchpad.net/neutron/+bug/1209151 https://review.openstack.org/#/c/40636/1 Thanks, Eugene. On Wed, Aug 7, 2013 at 7:59 PM, Dmitriy Andrushko wrote: > Hi, all! > Following request from ML2 team discussed during weekly IRC

Re: [openstack-dev] Request for review - Change Ic98db496: Adding VIF Driver to support Mellanox Plugin

Hi Itzik, Could you please fix your patch such that Jenkins would put +1? Thanks, Eugene. On Thu, Aug 8, 2013 at 1:18 PM, Itzik Brown wrote: > Hi, > > I have a patch waiting for review. > > https://review.openstack.org/#**/c/35189/- > Adding VIF Drive

Re: [openstack-dev] [Neutron] Ceilometer support

Hi Gary, Isn't it something that 'metering support' is going to solve? A couple of patches addressing this are on review. Thanks, Eugene. On Wed, Aug 14, 2013 at 3:47 PM, Gary Kotton wrote: > [image: Description: > https://fbcdn-sphotos-f-a.akamaihd.net/hphotos-ak-prn2/1098074_725247340838055

Re: [openstack-dev] Need of L3-Agent to Router Binding

Hi Rahul, > In which scenario will I have more than one l3agents installed in my setup? You may start l3agent on each of your compute nodes so routers are distributed across nodes. It also would allow to implement failover for l3 agents: when some node with l3 agent fails, router may be reschedule

Re: [openstack-dev] [Neutron] Exceptions in neutron.extension

Exceptions, defined in neutron.extensions are very specific for the code that implements extension. Exceptions defined in neutron.common.exceptions represent common exception classes which are mapped to HTTP error codes. Also, neutron.common.exceptions contain definitions of exceptions specific to

[openstack-dev] [Neutron] Handling provider removal

Hi folks, I'd like to continue the discussion about this. I think we have the following questions to answer: 1) What should be the workflow of provider removal for the admin? 2) Do we allow 'update' operation on provider attribute? 3) Do we allow removing provider for users? My take on these: 1)

Re: [openstack-dev] [Quantum]How to contribute LBaas driver?

Hi Hu Yanrui, Thanks for your interest. The links in previous email are correct, please use them to familiarize yourself with development process. Make sure to use upstream version of neutron when developing your driver. You can post your code to review (you also can post draft version https://wik

Re: [openstack-dev] [Neutron] VIP for LBaaS on same port?

Hi Stephen, Currently it's not possible. But we're planning to change this in near future. There is a blueprint which supposes change in vip-pool relationship (change it from 1:1 to m:n), as part of it's implementation, unconditional l2 port creation will be removed from loadbalancer_db.py Here's

Re: [openstack-dev] [Neutron] VIP for LBaaS on same port?

Itsuro, Stephen, Support for this ability is planned in the scope of the blueprint I've mentioned. Thanks, Eugene. On Thu, Sep 5, 2013 at 11:39 AM, Stephen Gran wrote: > On 05/09/13 08:27, Itsuro ODA wrote: > >> Hi, >> >> Please consider the following use case make abailable too: >> ip address

Re: [openstack-dev] [neutron][ovs] The way we deal with MTU

That's interesting. In our deployments we do something like br-ex (linux bridge, mtu 9000) - OVSIntPort (mtu 65000) - br-floating (ovs bridge, mtu 1500) - br-int (ovs bridge, mtu 1500). qgs then are getting created in br-int, traffic goes all the way and that altogether allows jumbo frames over e

Re: [openstack-dev] [neutron] OVSDB native interface as default in gate jobs

May be you just don't have enough pain, Sean :) I'd agree that these should be coalesced, with a deprecation period then... E. On Mon, Apr 4, 2016 at 2:32 PM, Sean M. Collins wrote: > Inessa Vasilevskaya wrote: > > different configurations of of_interface and ovsdb_interface options > > (dsvm-

Re: [openstack-dev] neutron metadata-agent HA

It is as 'single' as active L3 router that is handling traffic at current point of time. On Sun, Dec 13, 2015 at 11:13 AM, Gary Kotton wrote: > > > > > > On 12/12/15, 10:44 PM, "Assaf Muller" wrote: > > >The neutron metadata agent is stateless. It takes requests from the > >metadata proxies run

Re: [openstack-dev] FW: [vitrage] Gerrit Upgrade 12/16

I'm sorry to say that, but the new front page design is horrible and totally confusing. I hope it'll change soon in the new release. E. On Tue, Dec 15, 2015 at 10:53 AM, AFEK, Ifat (Ifat) < ifat.a...@alcatel-lucent.com> wrote: > Hi, > > Reminder: Gerrit upgrade is scheduled for tomorrow at 17:

Re: [openstack-dev] [fuel] What to do when a controller runs out of space

No pacemaker for os services, please. We'll be moving out neutron agents from pacemaker control in 8.0, other os services don't need it too. E. 5 окт. 2015 г. 12:01 пользователь "Sergii Golovatiuk" < sgolovat...@mirantis.com> написал: > Good morning gentlemen! > > Alex raised very good question.

Re: [openstack-dev] [fuel] What to do when a controller runs out of space

itoring (rabbitmq, galera) But even there, examples when we are better off without pacemaker are all around. Thanks, Eugene. On Mon, Oct 5, 2015 at 1:34 PM, Sergey Vasilenko wrote: > > On Mon, Oct 5, 2015 at 12:22 PM, Eugene Nikanorov > wrote: > >> No pacemaker for os service

Re: [openstack-dev] [fuel] What to do when a controller runs out of space

> that I'm facing and it may not be completely related to disk space. I >> think we might be relying on the expectation that the local rabbitmq >> is always available but I need to look into that. Either way, I >> believe we still should continue to discuss this issue

Re: [openstack-dev] [fuel] What to do when a controller runs out of space

ular haproxy backends. > I think this kind of attribute, although being analyzed by pacemaker/ocf, doesn't need any new OS service to be put under pacemaker control. Thanks, Eugene. > > On Mon, Oct 5, 2015 at 11:57 PM, Eugene Nikanorov > wrote: > >> >>>> >

Re: [openstack-dev] [fuel] What to do when a controller runs out of space

initial point was (to state it clearly), that I will be -2 on any new additions of openstack services to pacemaker kingdom. Thanks, Eugene. > > > On Tue, Oct 6, 2015 at 3:46 PM, Eugene Nikanorov > wrote: > >> >> >>> 2) I think you misunderstand what is the diffe

Re: [openstack-dev] [Neutron] L3 agent rescheduling issue

I doubt it's a server side issue. Usually there are plenty of rpc workers to drain much higher amount of rpc messages going from agents. So the issue could be in 'fairness' on L3 agent side. But from my observations it was more an issue of DHCP agent than L3 agent due to difference in resource proc

Re: [openstack-dev] [Neutron] L3 agent rescheduling issue

Salvatore, By 'fairness' I meant chances for state report greenthread to get the control. In DHCP case, each network processed by a separate greenthread, so the more greenthreads agent has, the less chances that report state greenthread will be able to report in time. Thanks, Eugene. On Sun, Jun

Re: [openstack-dev] [Neutron] L3 agent rescheduling issue

rstand now. So the issue is that the report_state greenthread is > just blocking and yielding whenever it tries to actually send a message? > > On Sun, Jun 7, 2015 at 8:10 PM, Eugene Nikanorov > wrote: > >> Salvatore, >> >> By 'fairness' I meant chances for

Re: [openstack-dev] [Neutron] L3 agent rescheduling issue

; frequently when they make process calls, etc. That's why I assumed that > there must be something actually stopping it from sending the message. > > Do you have a way to reproduce the issue with the DHCP agent? > > On Sun, Jun 7, 2015 at 9:21 PM, Eugene Nikanorov > wrote: >

Re: [openstack-dev] [all][python3] use of six.iteritems()

Huge +1 both for the suggestion and for reasoning. It's better to avoid substituting language features by a library. Eugene. On Tue, Jun 9, 2015 at 5:15 PM, Robert Collins wrote: > I'm very glad folk are working on Python3 ports. > > I'd like to call attention to one little wart in that proces

[openstack-dev] [Neutron] Issue with pymysql

Hi neutrons, I'd like to draw your attention to an issue discovered by rally gate job: http://logs.openstack.org/96/190796/4/check/gate-rally-dsvm-neutron-rally/7a18e43/logs/screen-q-svc.txt.gz?level=TRACE I don't have bandwidth to take a deep look at it, but first impression is that it is some i

Re: [openstack-dev] [Neutron] db-level locks, non-blocking algorithms, active/active DB clusters and IPAM

Thanks for putting this all together, Salvatore. I just want to comment on this suggestion: > 1) Move the allocation logic out of the driver, thus making IPAM an independent service. The API workers will then communicate with the IPAM service through a message bus, where IP allocation requests wil

Re: [openstack-dev] [all][oslo.db] Repeatable Read considered harmful

Hi Matthew, I'll add just 2c: We've tried to move from repeatable-read to read committed in Neutron project. This change actually has caused multiple deadlocks during regular tempest test run. That is a known problem (the issue with eventlet and currect mysql client library), but anyway, at least

[openstack-dev] [Neutron] A10 CI

Hi folks, who is responsible for A10 CI? It keeps spamming with CI results on many patches that are not being updated. Also it spins sometimes, producing tens and hundreds of emails for particular patch. Please repair! Thanks, Eugene. _

Re: [openstack-dev] [all] Replace mysql-python with mysqlclient

> All production Openstack applications today are fully serialized to only be able to emit a single query to the database at a time; True. That's why any deployment configures tons (tens) of workers of any significant service. > When I talk about moving to threads, this is not a "won't help or hu

Re: [openstack-dev] [horizon] Logo

Doge coin http://dogecoin.com/ On Sat, Jul 16, 2016 at 7:22 PM, Timur Sufiev wrote: > Let's take it before anybody else did :)! > > On Sat, Jul 16, 2016 at 6:15 PM Richard Jones > wrote: > >> +2 very appropriate >> >> On 17 July 2016 at 11:01, Diana Whitten wrote: >> >>> Dunno if there have be

Re: [openstack-dev] [Neutron] Stepping down from core

Sad to see you go, Carl. Good luck! Eugene. On Thu, Nov 17, 2016 at 10:42 AM, Carl Baldwin wrote: > Neutron (and Openstack), > > It is with regret that I report that my work situation has changed such > that I'm not able to keep up with my duties as a Neutron core reviewer, L3 > lieutenant, and

<    1   2   3