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,

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,

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

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

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

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

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

l start soon. My 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 <enikano...@mirantis.com> > wrote: > >> >> >>> 2) I thi

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

k 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 <enikano...@mirantis.com > > wrote: > >> >>>>

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

gt; 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 as we are >> managing services in multiple ways on a single host. Additiona

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

) 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 <svasile...@mirantis.com> wrote: > > On Mon, Oct 5, 2015 at 12:22 PM, Eugene Nikanorov <enikano...@mirantis.com > > wrote: &g

[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

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 robe...@robertcollins.net wrote: I'm very glad folk are working on Python3 ports. I'd like to call attention to one

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

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 enikano...@mirantis.com wrote: No, I think greenthread itself don't

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,

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

understand 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 enikano...@mirantis.com wrote: Salvatore, By 'fairness' I meant chances for state report greenthread to get

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

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 hurt

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

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

Re: [openstack-dev] [Neutron] Bug day

discourage people from looking into the bug. Thanks everyone for helping with this! Eugene. On Fri, Nov 21, 2014 at 11:03 AM, Eugene Nikanorov enikano...@mirantis.com wrote: Hi neutron folks! Today we've decided to conduct bug triaging day. We have more than one thousand bugs needing

[openstack-dev] [Neutron] Bug day

Hi neutron folks! Today we've decided to conduct bug triaging day. We have more than one thousand bugs needing their state to be checked. So everyone is welcome to participate! The goals of bug triaging day are: 1) Decrease the number of New bugs. Possible 'resolution' would be: - confirm bug.

Re: [openstack-dev] [Neutron] DB: transaction isolation and related questions

Comments inline: On Thu, Nov 20, 2014 at 4:34 AM, Jay Pipes jaypi...@gmail.com wrote: So while the SELECTs may return different data on successive calls when you use the READ COMMITTED isolation level, the UPDATE statements will continue to return 0 rows affected **if they attempt to change

Re: [openstack-dev] [Neutron] DB: transaction isolation and related questions

*You are 100% correct that setting the transaction isolation level to READ COMMITTED works in the retry loop*. I stand corrected, and humbled :) Please accept my apologies. Thanks for letting me know :) One thing I did note, though, is that changing the isolation level of an

Re: [openstack-dev] [Neutron] DB: transaction isolation and related questions

Wow, lots of feedback in a matter of hours. First of all, reading postgres docs I see that READ COMMITTED is the same as for mysql, so it should address the issue we're discussing: *Read Committed* is the default isolation level in PostgreSQL. When a transaction uses this isolation level, a

Re: [openstack-dev] [Neutron] DB: transaction isolation and related questions

But the isolation mode change won’t really help here as pointed out by Jay; discrete transactions have to be used instead. I still think it will, per postgres documentation (which might look confusing, but still...) It actually helps for mysql, that was confirmed. For postgres it appears to be

[openstack-dev] [Neutron] DB: transaction isolation and related questions

Hi neutron folks, There is an ongoing effort to refactor some neutron DB logic to be compatible with galera/mysql which doesn't support locking (with_lockmode('update')). Some code paths that used locking in the past were rewritten to retry the operation if they detect that an object was

[openstack-dev] [Neutron] Let's fix all neutron bugs! (NOT)

Hi folks, I have been supervising bug list for neutron during the last release cycle, trying to do some housekeeping, prioritizing issues and fixing some of them. As you might see, amount of bugs (even staying in New state) doesn't go down. Bugs appear at quite fast pace, and some of them hang

[openstack-dev] [Neutron] Improving dhcp agent scheduling interface

Hi folks, I'd like to raise a discussion kept in irc and in gerrit recently: https://review.openstack.org/#/c/131944/ The intention of the patch is to clean up particular scheduling method/interface: schedule_network. Let me clarify why I think it needs to be done (beside code api consistency

Re: [openstack-dev] [Neutron] Improving dhcp agent scheduling interface

My comments inline: I would argue that it isn't, actually. You may need to know the state of the network to make that placement decision. Yes, I could agree with that - and that's just a particular scheduling implementation, not a requirement for the interface. Just passing the id may

Re: [openstack-dev] [Neutron][LBaaS] Migrations in feature branch

don’t expect this issue to cause many practical problems in this particular case. This is also an issue for the incubator, whenever it rolls around. Thanks, doug On September 23, 2014 at 6:59:44 PM, Eugene Nikanorov (enikano...@mirantis.com) wrote: Hi neutron

[openstack-dev] [Neutron][LBaaS] Migrations in feature branch

Hi neutron and lbaas folks. Recently I briefly looked at one of lbaas proposed into feature branch. I see migration IDs there are lined into a general migration sequence. I think something is definitely wrong with this approach as feature-branch components are optional, and also master branch

Re: [openstack-dev] [Neutron] [LBaaS] Packet flow between instances using a load balancer

If we're talking about default haproxy driver for lbaas, then I'd say that the diagram is not quite correct because one could assume that LB_A and LB_B are kind of routing devices which have networks behind. Since haproxy is layer 4 loadbalancer, so packet received by RHB1 will have source of

[openstack-dev] [Neutron] Allowing specifying object ID in create_* API

Hi neutrons, We've been discussing various ways of doing cloud upgrades. One of the safe and viable solutions seems to be moving existing resources to a new cloud deployed with new version of openstack. By saying 'moving' I mean replication of all resources and wiring everything together in a

Re: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver interface on every API request

Hi folks, That actually going in opposite direction to what flavor framework is trying to do (and for dispatching it's doing the same as providers). REST call dispatching should really go via the root object. I don't quite get the issue with health monitors. If HM is incorrectly configured prior

Re: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver interface on every API request

. The driver errors out not on the LoadBalancer create, but on the health monitor create. I think that's the issue. Thanks, Brandon On Tue, 2014-08-12 at 00:17 +0400, Eugene Nikanorov wrote: Hi folks, That actually going in opposite direction to what flavor framework is trying to do

[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

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 stef...@openstack.org 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

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

[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] Flavor framework proposal

is for. Totally agree on this point. On Tue, Jul 15, 2014 at 2:07 PM, Eugene Nikanorov enikano...@mirantis.com wrote: Hi Stephen, So, as was discussed, existing proposal has some aspects which better to be postponed, like extension list on the flavor (instead of tags). Agreed-- I

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

Hi Stephen, So, as was discussed, existing proposal has some aspects which better to be postponed, like extension list on the flavor (instead of tags). Particularly that idea has several drawbacks: - it makes public API inflexible - turning features on/off is not what flavors should be doing,

Re: [openstack-dev] [neutron] Flavor framework: Conclusion

. Thanks, Eugene. On Mon, Jul 7, 2014 at 8:41 PM, Mark McClain mmccl...@yahoo-inc.com wrote: On Jul 4, 2014, at 1:09 AM, Eugene Nikanorov enikano...@mirantis.com wrote: German, First of all extension list looks lbaas-centric right now. Actually far from it. SSL VPN should be service

Re: [openstack-dev] [neutron] Flavor framework: Conclusion

Hi, Mark and me has spent some time today discussing existing proposals and I think we got to a consensus. Initially I had two concerns about Mark's proposal which are - extension list attribute on the flavor - driver entry point on the service profile The first idea (ext list) need to be

Re: [openstack-dev] [Neutron][LBaaS] Layer7 Switching - L7 Rule - comapre_type values

I also don't think it is fair for certain drivers to hold other drivers hostage For some time there was a policy (openstack-wide) that public API should have a free open source implementation. In this sense open source driver may hold other drivers as hostages. Eugene. On Thu, Jul 3, 2014 at

Re: [openstack-dev] [neutron] Flavor framework: Conclusion

-dev] [neutron] Flavor framework: Conclusion Awesome, thanks for working on this Eugene and Mark! I'll still leave an item on Monday's meeting agenda to discuss this, hopefully it can be brief. Thanks, Kyle On Thu, Jul 3, 2014 at 10:32 AM, Eugene Nikanorov enikano...@mirantis.com wrote: Hi

Re: [openstack-dev] [Neutron][LBaaS] Which entities need status

Hi lbaas folks, IMO a status is really an important part of the API. In some old email threads Sam has proposed the solution for lbaas objects: we need to have several attributes that independently represent different types of statuses: - admin_state_up - operational status - provisioning state

Re: [openstack-dev] [Neutron] One performance issue about VXLAN pool initiation

. If you think that the benefit doesn't worth complexity - please let me know. Thanks, Eugene. On Mon, Jun 9, 2014 at 1:33 AM, Mike Bayer mba...@redhat.com wrote: On Jun 7, 2014, at 4:38 PM, Eugene Nikanorov enikano...@mirantis.com wrote: Hi folks, There was a small discussion about

Re: [openstack-dev] [Neutron] One performance issue about VXLAN pool initiation

the abstraction of an ipam interface merged. That will take some more discussion and work on its own. Carl On May 30, 2014 4:37 PM, Eugene Nikanorov enikano...@mirantis.com wrote: I was thinking it would be a separate process that would communicate over the RPC channel or something

Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas

If a user makes a change to a secret Can we just disable that by making LBaaS a separate user so it would store secrets under LBaaS 'fake' tenant id? Eugene. On Sun, Jun 8, 2014 at 7:29 AM, Jain, Vivek vivekj...@ebay.com wrote: +1 for #2. In addition, I think it would be nice if barbican

Re: [openstack-dev] [Neutron] One performance issue about VXLAN pool initiation

Unit tests use sqlite db backend, so it might be much faster than production environment where DB is on different server. Eugene. On Wed, Jun 4, 2014 at 11:14 AM, Wang, Yalei yalei.w...@intel.com wrote: Hi, Xurong, How do you test it in postgresql? Do you use tox to do a unittest and get

Re: [openstack-dev] Your suggestions in the BP

Hi Sam, Eugene, please comment on the migration process bellow. I think that closing down the status handling should be done in phase 1. I don't mind. If you're talking about provisioning status then such status (if we're still going to maintain it per each kind of object) goes to various

Re: [openstack-dev] [All] Disabling Pushes of new Gerrit Draft Patchsets

Hi, I might be posting a question to a wrong thread, but what would be the option to push a patch that I would like to share only with certain group of people. In other words, is there still an option to push non-public patches? I wouldn't like such patches to affect gerrit stream or trigger CIs,

Re: [openstack-dev] [Neutron] One performance issue about VXLAN pool initiation

Hi Carl, The idea of in-memory storage was discussed for similar problem, but might not work for multiple server deployment. Some hybrid approach though may be used, I think. Thanks, Eugene. On Fri, May 30, 2014 at 8:53 PM, Carl Baldwin c...@ecbaldwin.net wrote: This is very similar to

Re: [openstack-dev] [Neutron] One performance issue about VXLAN pool initiation

implementation is slow. At least going over RPC is greenthread friendly where going to the database doesn't seem to be. Carl On Fri, May 30, 2014 at 2:56 PM, Eugene Nikanorov enikano...@mirantis.com wrote: Hi Carl, The idea of in-memory storage was discussed for similar problem, but might

[openstack-dev] [Neutron][Flavors] Flavor framework implementation questions

Hi, I have two questions that previously were briefly discussed. Both of them still cause discussions within advanced services community, so I'd like to make final clarification in this email thread. 1. Usage of Service Type Framework I think right now there is a consensus that letting user to

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

Hi folks, Let's keep our regular meetings on Thursday, 14-00 UTC The agenda for the meeting: https://wiki.openstack.org/wiki/Network/LBaaS#Agenda Sorry for the short notice, I'm still catching up with everything. Thanks, Eugene. ___ OpenStack-dev

Re: [openstack-dev] [neutron] Supporting retries in neutronclient

In fact, nova should be careful about changing number of retries for neutron client. It's known that under significant load (people test serial VM creation) neutron client may timeout on POST operation which does port creation; retrying this again leads to multiple fixed IPs assigned to a VM

Re: [openstack-dev] [Neutron][LBaaS] Unanswered questions in object model refactor blueprint

Hi folks, From lbaas design session I have an impression that we need to have a kind of merge of existing API and new proposed API. E.g. the blueprint implementation should not be brand new API and DB backend. So I'd say from implementation perspective we may want to minimize amount of changes

Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?

brandon.lo...@rackspace.com wrote: Yeah that’s a good point. Thanks! From: Eugene Nikanorov enikano...@mirantis.com Reply-To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Date: Thursday, May 15, 2014 at 10:38 PM

Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?

Hi Craig, Implementation-specific options are not exposed through the API, or otherwise it would be inconsistent, given that we are moving to a flavor-based approach of specifying service requirements where implementation is completely hidden from the user. Thanks, Eugene. On Thu, May 15, 2014

Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?

Hi Vijay, When you say API is not available, it means this should not be considered like a resource/entity. Correct? But then, there would be API like a bind API, that accepts loadbalancer_id listener_id, which creates this object. And also, there would be an API that will be used

Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?

, Eugene. On Thu, May 15, 2014 at 6:45 PM, IWAMOTO Toshihiro iwam...@valinux.co.jpwrote: It is pity to see enoumous LBaaS efforts have been largely spinning (in a sense of spinlocks) for a while. At Thu, 15 May 2014 14:31:54 +0400, Eugene Nikanorov wrote: [1 multipart/alternative (7bit

Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?

a minor correction is required to indicate the many to many relationship via PoolMonitorAssociation. Thanks, Vijay V. *From:* Eugene Nikanorov [mailto:enikano...@mirantis.com] *Sent:* Thursday, May 15, 2014 7:36 PM *To:* OpenStack Development Mailing List (not for usage questions

Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?

pool. Is this always going to be the same type of health monitor? There’s also ambiguity in the case where one health monitor fails and another doesn’t. Is it an AND or OR that determines whether the member is down or not? Thanks, Brandon Logan From: Eugene Nikanorov enikano

[openstack-dev] [Neutron][LBaaS] Cancelling weekly meeting 15 of May

Hi, Let's skip the meeting this week for obvious reasons :) Also, Oleg and me will not be able to attend the meeting next week (if it will be conducted), because we will be on vocation. Thanks, Eugene. ___ OpenStack-dev mailing list

Re: [openstack-dev] [Neutron][LBaaS] Meetup?

Hi, what time are you suggesting? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Meetup?

I'm going to attend the next nw session @b103, we can meet in between. Im in b103 too. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Multiple VIPs per loadbalancer

Hi Stephen, While in second approach VIP remains a keeper of L2/L3 information, while listeners keep L4+ information. That seems to be more clear. There's a complication though: Pools may also need some L2/L3 information (per the discussion of adding subnet_id as an attribute of the

Re: [openstack-dev] [Neutron][LBaaS] Multiple VIPs per loadbalancer

Hi Carlos, On May 9, 2014, at 3:36 PM, Eugene Nikanorov enikano...@mirantis.com wrote: Also we've heard objection to this approach several times from other core team members (this discussion has been going for more than half a year now), so I would suggest to move forward with single L2

Re: [openstack-dev] [Neutron][LBaaS] API proposal review thoughts

Hi Stephen, Some comments on comments on comments: On Fri, May 9, 2014 at 10:25 PM, Stephen Balukoff sbaluk...@bluebox.netwrote: Hi Eugene, This assumes that 'VIP' is an entity that can contain both an IPv4 address and an IPv6 address. This is how it is in the API proposal and

Re: [openstack-dev] [Neutron][LBaaS] Multiple VIPs per loadbalancer

Hi Brandon, I, too, have not heard clear and concise reasons why the core team members would not like a logical load balancer object, or a load balancer object that maps to many vips, which in turn maps to many listeners. I've been to every LBaaS meeting for months now I think, and I just

Re: [openstack-dev] [Neutron][LBaaS] API proposal review thoughts

Hi Stephen, Well, sure, except the user is going to want to know what the IP address(es) are for obvious reasons, and expect them to be taken from subnet(s) the user specifies. Asking the user to provide a Neutron network_id (ie. where we'll attach the L2 interface) isn't definitive here

Re: [openstack-dev] [Neutron][LBaaS] API proposal review thoughts

:45 PM, Eugene Nikanorov enikano...@mirantis.com wrote: Hi Carlos, Are you saying that we should only have a loadbalancer resource only in the case where we want it to span multiple L2 networks as if it were a router? I don't see how you arrived at that conclusion. Can you explain

Re: [openstack-dev] [Neutron][LBaaS] API proposal review thoughts

Hi Brandon Let me know if I am misunderstanding this,and please explain it further. A single neutron port can have many fixed ips on many subnets. Since this is the case you're saying that there is no need for the API to define multiple VIPs since a single neutron port can represent all the

[openstack-dev] [Neutron][LBaaS] Multiple VIPs per loadbalancer

Hi folks, I'm pulling this question out of another discussion: Is there a need to have multiple VIPs (e.g. multiple L2 ports/IP addresses) per logical loadbalancer? If so, we need the description of such cases to evaluate them. Thanks, Eugene. ___

Re: [openstack-dev] [Neutron][LBaaS] Multiple VIPs per loadbalancer

On Fri, May 9, 2014 at 7:40 PM, Brandon Logan brandon.lo...@rackspace.comwrote: Yes, Rackspace has users that have multiple IPv4 and IPv6 VIPs on a single load balancer. For sure that can be supported by particular physical appliance, but I doubt we need to translate it to logical

Re: [openstack-dev] [Neutron][LBaaS] API proposal review thoughts

Hi Stephen, A couple of inline comments: - BBG proposal just has attributes for both and IPv4 address and an IPv6 address in its VIP object. (Meaning it's slightly different than a VIP as people are likely to assume what that term means.) This is a correct approach.

Re: [openstack-dev] [Neutron][LBaaS] API proposal review thoughts

Hi Adam, My comments inline: 1. We shouldn't be looking at the current model and deciding which object is the root object, or what object to rename as a loadbalancer... That's totally backwards! *We don't define which object is named the loadbalancer by looking for the root object -- we

Re: [openstack-dev] [Neutron][LBaaS] API proposal review thoughts

Hi Carlos, Are you saying that we should only have a loadbalancer resource only in the case where we want it to span multiple L2 networks as if it were a router? I don't see how you arrived at that conclusion. Can you explain further. No, I mean that loadbalancer instance is needed if we

Re: [openstack-dev] [Neutron][LBaaS]L7 conent switching APIs

Hi folks, I think it's ok to include content modification in a general API proposal as long as it would then receive separate spec document in neutron-specs. When it comes to particular feature design and implementation it's better to be more granular. Thanks, Eugene. On Tue, May 6, 2014 at

[openstack-dev] [Neutron][LBaaS] Subteam meeting Thursday, 05/08 14-00 UTC

Hi folks, This will be the last meeting before the summit, so I suggest we will focus on the agenda for two design track slots we have. Per my experience design tracks are not very good for in-depth discussion, so it only make sense to present a road map and some other items that might need core

Re: [openstack-dev] [Neutron][LBaaS] Use-Cases with VPNs Distinction

Agree with Sam here, Moreover, i think it makes sense to leave subnet an attribute of the pool. Which would mean that members reside in that subnet or are available (routable) from this subnet, and LB should have a port on this subnet. Thanks, Eugene. On Fri, May 2, 2014 at 3:51 PM, Samuel

Re: [openstack-dev] [Neutron][LBaaS] Fulfilling Operator Requirements: Driver / Management API

Hi Adam, My comments inline: On Fri, May 2, 2014 at 1:33 AM, Adam Harwell adam.harw...@rackspace.comwrote: I am sending this now to gauge interest and get feedback on what I see as an impending necessity — updating the existing haproxy driver, replacing it, or both. I agree with Stephen's

Re: [openstack-dev] [Neutron][LBaaS]Conforming to Open Stack API style in LBaaS

Hi, My opinion is that keeping neutron API style is very important but it doesn't prevent single call API from being implemented. Flat fine-grained API is obviously the most flexible, but that doesn't mean we can't support single call API as well. By the way, looking at the implementation I see

Re: [openstack-dev] [Neutron][LBaaS] Thoughts on current process

Hi Jorge, A couple of inline comments: Now that we have a set of requirements the next question to ask is, How doe we prioritize requirements so that we can start designing and implementing them? Prioritization basically means that we want to support everything and only choose what is more

Re: [openstack-dev] [Neutron][LBaaS] Thoughts on current process

Sorry, missed the phrase ending: It's not because developers of lbaas have not thought about it, it's because we were limited in dev and core reviewing resources, so implement so implementing some of the operators requirements was always in our plans. Eugene.

Re: [openstack-dev] [Neutron][LBaaS] Thoughts on current process

Hi, On Thu, May 1, 2014 at 10:46 PM, Jorge Miramontes jorge.miramon...@rackspace.com wrote: Hey Eugene, I think there is a misunderstanding on what iterative development means to you and me and I want to make sure we are on the same page. First of all, I'll try not to use the term

Re: [openstack-dev] [Neutron][LBaaS] Thoughts on current process

We wanted a discussion to happen on whether the existing object model would work with both API proposals. That blueprint being pushed to gerrit the same time as Stephen mailing out his proposal made it seem like this was not going to happen. I'm sorry about that. In fact I was just

Re: [openstack-dev] [Nova][Neutron] Nova-network to Neutron migration: issues with libvirt

I think it's better to test with some tcp connection (ssh session?) rather then with ping. Eugene. On Wed, Apr 30, 2014 at 5:28 PM, Oleg Bondarev obonda...@mirantis.comwrote: So by running ping while instance interface update we can see ~10-20 sec of connectivity downtime. Here is a tcp

[openstack-dev] [Neutron][LBaaS] Subteam meeting Thursday 14-00 UTC

Hi, The agenda for the next meeting (Thursday, 1st of May, 14-00 UTC) is the following: 1) Stephen's API proposal: https://docs.google.com/document/d/129Da7zEk5p437_88_IKiQnNuWXzWaS_CpQVm4JBeQnc/edit#heading=h.hgpfh6kl7j7a The document proposes the API that covers pretty much of the features

Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

On Fri, Apr 25, 2014 at 4:03 AM, Eugene Nikanorov enikano...@mirantis.com wrote: Hi Stephen, Thanks for the great document. As I promised, I'll try to make a few action items out if it. First of all, I'd like to say that the API you have proposed is very close to what is proposed

Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

Hi, You knew from the action items that came out of the IRC meeting of April 17 that my team would be working on an API revision proposal. You also knew that this proposal was to be accompanied by an object model diagram and glossary, in order to clear up confusion. You were in that meeting,

Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

Hi Stephen, Thanks for the great document. As I promised, I'll try to make a few action items out if it. First of all, I'd like to say that the API you have proposed is very close to what is proposed in the blueprint https://review.openstack.org/#/c/89903/with several differences I'd like to

Re: [openstack-dev] [Neutron] Flavor(?) Framework

/multi_backend.html Thanks, Akihiro (2014/04/24 0:05), Eugene Nikanorov wrote: Hi neutrons, A quick question of the ^^^ I heard from many of you that a term 'flavor' is undesirable, but so far there were no suggestions for the notion that we are going to introduce. So please, suggest you name

Re: [openstack-dev] [Neutron] Flavor(?) Framework

-cloud/content/multi_backend.html Thanks, Akihiro (2014/04/24 0:05), Eugene Nikanorov wrote: Hi neutrons, A quick question of the ^^^ I heard from many of you that a term 'flavor' is undesirable, but so far there were no suggestions for the notion that we

Re: [openstack-dev] [Neutron] Flavor(?) Framework

Marrios, I'm working on that right now. Expect the BP to be on gerrit later today. Thanks, Eugene. On Thu, Apr 24, 2014 at 3:40 PM, mar...@redhat.com mandr...@redhat.comwrote: On 24/04/14 13:54, Eugene Nikanorov wrote: Marios, here's the link with proposal description: https

[openstack-dev] [Neutron] Flavor(?) Framework

Hi neutrons, A quick question of the ^^^ I heard from many of you that a term 'flavor' is undesirable, but so far there were no suggestions for the notion that we are going to introduce. So please, suggest you name for the resource. Names that I've been thinking of: - Capability group - Service

Re: [openstack-dev] [Neutron] Flavor(?) Framework

Thanks, that can be an option. Just wondering, can we find a single name? Thanks, Eugene. On Wed, Apr 23, 2014 at 7:19 PM, Jay Pipes jaypi...@gmail.com wrote: On Wed, 2014-04-23 at 19:05 +0400, Eugene Nikanorov wrote: Hi neutrons, A quick question of the ^^^ I heard from many

  1   2   3   >