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

ve heard enough negative opinions on the idea of 'container' to at least postpone this discussion to the point when we'll get some important use cases that could not be addressed by 'VIP as loadbalancer' Eugene. On Fri, May 9, 2014 at 8:33 AM, Carlos Garza wrote: > >

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

[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. ___ Open

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

On Fri, May 9, 2014 at 7:40 PM, Brandon Logan wrote: > 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 loadbalancer. > However, I don't thi

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

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

Hi Carlos, > On May 9, 2014, at 3:36 PM, Eugene Nikanorov > 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

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 wrote: > 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 > corresponding object model th

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 jus

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 > b

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

[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 OpenStack-dev@lists.

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 wi

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

hanks, Eugene. On Thu, May 15, 2014 at 6:45 PM, IWAMOTO Toshihiro wrote: > 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: > > > >

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

> Now, the model is indicating a pool can have only one monitor. So a minor > correction is required to indicate the many to many relationship via > PoolMonitorAssociation. > > > > Thanks, > > Vijay V. > > > > > > *From:* Eugene Nikanorov [mailto:enika

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

> 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

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

! fantastic to meeting you all in person. > >> > >> > >> We now have agreement on the Object model. How do we turn that into > >> blueprints and also how do we start making progress on the rest of the > >> items we agree upon at the summit? > >>

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 Thank

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 fo

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

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 wrote: > This is very similar to IPAM... There is a spa

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

on which would be slow. But the current > 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 > wrote: > > Hi Carl, > > > > The idea

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] 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] [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 wrote: > Hi, Xurong, > > > > How do you test it in postgresql? Do you use tox to do a unittest and get > the result(1h

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

ssion and work on its own. > > Carl > On May 30, 2014 4:37 PM, "Eugene Nikanorov" > wrote: > >> > I was thinking it would be a separate process that would communicate over >> the RPC channel or something. >> memcached? >> >> Eugene. >

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

> great. > I will do more test base on Eugene Nikanorov's modification. > > *Thanks,* > > > 2014-06-05 11:01 GMT+08:00 Isaku Yamahata : > > Wow great. >> I think the same applies to gre type driver. >> so we should create similar one after vxlan case is resolved. &g

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 wrote: > +1 for #2. > > In addition, I think it would be nice if barbican maintains versi

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

ked version that is on review now. 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 wrote: > > On Jun 7, 2014, at 4:38 PM, Eugene Nikanorov > wrote: > > Hi folks, > > There w

[openstack-dev] [Neutron][LBaaS] Weekly meeting & object model discussion IMPORTANT

Hi neutron & lbaas folks, Let's meet tomorrow, Thursday, 06 at 14-00 on #openstack-meeting to continue discussing the object model. We had discussed with Samuel Bercovici proposals at hand and currently there are two main proposals that we are evaluating. Both of them allow to add two major featu

[openstack-dev] [Neutron][LBaaS] Health monitoring and statistics for complex LB configurations.

Hi community, Another interesting questions were raised during object model discussion about how pool statistics and health monitoring should be used in case of multiple vips sharing one pool. Right now we can query statistics for the pool, and some data like in/out bytes and request count will b

Re: [openstack-dev] [Neutron][LBaaS] Mini-summit Interest?

If this happens, it might make sense to keep it before, not after the summit. Basically, on the summit we need to come up with a plan/design/roadmap that everyone agrees on and just present it to the core team. Thanks, Eugene. On Thu, Mar 6, 2014 at 9:08 PM, John Dewey wrote: > I am interest

Re: [openstack-dev] [Neutron][LBaaS] Mini-summit Interest?

I think mini summit is no worse than the summit itself. Everyone who wants to participate can join. In fact what we really need is a certain time span of focused work. ML, meetings are ok, it's just that dedicated in person meetings (design sessions) could be more productive. I'm thinking what if s

Re: [openstack-dev] [Neutron][LBaaS] Mini-summit Interest?

Hi Edgar, I'm neutral to the suggestion of mini summit at this point. Why do you think it will exclude developers? If we keep it 1-3 days prior to OS Summit in Atlanta (e.g. in the same city) that would allow anyone who joins OS Summit to save on extra travelling. OS Summit itself is too distracti

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

Hi neutron and lbaas folks, Let's keep our regular meeting on Thursday, at 14-00 UTC at #openstack-meeting We'll update on current status and continue object model discussion. We have many new folks that are recently showed the interest in lbaas project asking for mini summit. I think it would be

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

miss anything? > > Will look for the meeting summary > > > > Regards, > > -Sam. > > > > > > *From:* Eugene Nikanorov [mailto:enikano...@mirantis.com] > *Sent:* Wednesday, March 12, 2014 10:21 PM > *To:* OpenStack Development Mailing Lis

Re: [openstack-dev] [Neutron] Advanced Services Common requirements IRC meeting

or tenant, it's always a result of scheduling, e.g. readonly. Thanks, Eugene. On Sat, Mar 15, 2014 at 12:25 AM, Sumit Naiksatam wrote: > Here is a summary from yesterday's meeting: > > ** Flavors (topic lead: Eugene Nikanorov) > * Hide the provider implementation detai

[openstack-dev] [Neutron][LBaaS][FWaaS][VPN] Admin status vs operational status

Hi folks, We've been discussing a patch that fixes https://bugs.launchpad.net/neutron/+bug/1242351 and came to a conclusion that what we have right now as an operational status ("status" attribute of the resource) may be confusing for a user. This attribute is used to show deployment status and r

Re: [openstack-dev] [Neutron][LBaaS][FWaaS][VPN] Admin status vs operational status

Hi Kyle, >> It's a typical use case for network devices to have both admin and > operational > state. In the case of having admin_state=DOWN and operational_state=ACTIVE, > this just means the port/link is active but has been configured down. > Isn't this > the same for LBaaS here? Even readi

Re: [openstack-dev] [Neutron][LBaaS][FWaaS][VPN] Admin status vs operational status

those bugs. Thanks, Eugene. On Mon, Mar 17, 2014 at 5:38 PM, Paul Michali wrote: > > > On Mar 17, 2014, at 8:26 AM, Eugene Nikanorov > wrote: > > Hi folks, > > We've been discussing a patch that fixes > https://bugs.launchpad.net/neutron/+bug/1242351 > and cam

Re: [openstack-dev] [Neutron][LBaaS][FWaaS][VPN] Admin status vs operational status

merely change "ACTIVE" into "DEPLOYED" instead? We can't just rename the ACTIVE to DEPLOYED, and may be the latter is not the best name, but yes, that's the intent. Thanks, Eugene. On Mon, Mar 17, 2014 at 7:31 PM, Kyle Mestery wrote: > On Mon, Mar 17, 20

Re: [openstack-dev] [Neutron][LBaaS][FWaaS][VPN] Admin status vs operational status

e bear in mind that my opinion is wrong in most cases, or at > least is different from that of the majority! > [3] https://cloudstack.apache.org/docs/api/apidocs-4.2/TOC_Root_Admin.html > [4] http://archives.opennebula.org/documentation:archives:rel2.0:api > [5] > http://docs.aws.amazon.c

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

Hi neutron and lbaas folks, Let's keep our regular meeting on Thursday, at 14-00 UTC at #openstack-meeting Jorge Miramontes has made a nice wiki page capturing service requirements: https://wiki.openstack.org/wiki/Neutron/LBaaS/requirements Please check it out as this will help us to get on the s

Re: [openstack-dev] [Neutron][LBaaS] Requirements Wiki

Hi Jorge, Thanks for taking care of the page. I've added priorities, although I'm not sure we need precise priority weights. Those features that still have '?' need further clarification. Thanks, Eugene. On Wed, Mar 19, 2014 at 11:18 AM, Oleg Bondarev wrote: > Hi Jorge, > > Thanks for taking

Re: [openstack-dev] [Neutron][LBaaS] Requirements Wiki

ike, especially when > setting up DNS. AWS for example, gives you an A record which you CNAME > to. > > >- Active/Passive Failover > > > - I think this is solved with multiple pools. > > > - IP Access Control > > > - Our current CLB off

Re: [openstack-dev] [Neutron][LBaaS] Requirements Wiki

> >>>- Active/Passive Failover >>> - I think this is solved with multiple pools. >>> >>> The multiple pools support that is coming with L7 rules is to support >>> content-switching based on L7 HTTP information (URL, headers, etc.). There >>> is no support today for an active vs. passive p

Re: [openstack-dev] [Neutron][LBaaS] Requirements Wiki

> and secondary nodes. If all primary nodes go down then secondary nodes > become active. > > Cheers, > --Jorge > > From: Eugene Nikanorov > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack

[openstack-dev] [Neutron][LBaaS] Glossary

Hi, Here's the wiki page with a list of terms we're usually operate when discussing lbaas object model: https://wiki.openstack.org/wiki/Neutron/LBaaS/Glossary Feel free to add/modify/ask questions. Thanks, Eugene. ___ OpenStack-dev mailing list OpenSta

Re: [openstack-dev] [Neutron][LBaaS] Neutron LBaaS, Libra and "managed services"

Hi Susanne, a couple of comments inline: > > We would like to discuss adding the concept of "managed services" to the > Neutron LBaaS either directly or via a Neutron LBaaS plug-in to Libra/HA > proxy. The latter could be a second approach for some of the software > load-balancers e.g. HA prox

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

Hi, HAProxy driver has not removed from the trunk, instead it became a base for agent-based driver, so the only haproxy-specific thing in the plugin driver is device driver name. Namespace driver is a device driver on the agent side and it was there from the beginning. The reason for the change is

Re: [openstack-dev] [Neutron][LBaaS] Neutron LBaaS, Libra and "managed services"

> > One example where the managed service approach for the HA proxy load >>> balancer is different from the current Neutron LBaaS roadmap is around HA >>> and resiliency. The 2 LB HA setup proposed ( >>> https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-haproxy) isn't >>> appropriate for serv

Re: [openstack-dev] [Neutron][LBaaS] Neutron LBaaS, Libra and "managed services"

e Balle [sleipnir...@gmail.com] > *Sent:* Monday, March 24, 2014 4:59 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Neutron LBaaS, Libra and > "managed services" > > Eugene, > > Thanks for

Re: [openstack-dev] [Neutron][LBaaS] Neutron LBaaS, Libra and "managed services"

Hi John, On Tue, Mar 25, 2014 at 7:26 AM, John Dewey wrote: > I have a similar concern. The underlying driver may support different > functionality, but the differentiators need exposed through the top level > API. > Not really, whole point of the service is to abstract the user from specific

Re: [openstack-dev] [Neutron][LBaaS] Neutron LBaaS, Libra and "managed services"

worrying too much about it because hopefully most cloud operators will use >>> the same driver that addresses those basic needs, but worst case scenarios >>> we have a ton of drivers that do a lot of similar things but are just >>> different enough to warrant a separate drive

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

Hi folks, Lets keep our regular meetings. Th next one on Thursday, 27, at 14-00 UTC. The agenda for the meeting: 1) Object model discussion update 2) Requirements & glossary Q&A 3) Open discussion Thanks, Eugene. ___ OpenStack-dev mailing list OpenSta

[openstack-dev] [Neutron] Flavor framework PoC code

Hi folks, I've made a small patch set to illustrate the idea and usage of flavors as I see it. https://review.openstack.org/#/c/83055/ I think gerrit can be a good place to discuss important implementation details on a given example service plugin, take a look at test_flavors.py file where it is

Re: [openstack-dev] [qa] [neutron] Neutron Full Parallel job - Last 4 days failures

Bug 1294603 has the root cause in LBaaS, which should be fixed by https://review.openstack.org/#/c/81537/ Thanks, Eugene. On Fri, Mar 28, 2014 at 7:29 PM, Matt Riedemann wrote: > > > On 3/27/2014 8:00 AM, Salvatore Orlando wrote: > >> >> On 26 March 2014 19:19, James E. Blair >

[openstack-dev] [Neutron][LBaaS] Load balancing use cases. Data from Operators needed.

Hi folks, On the last meeting we decided to collect usage data so we could prioritize features and see what is demanded most. Here's the blank page to do that (in a free form). I'll structure it once we have some data. https://wiki.openstack.org/wiki/Neutron/LBaaS/Usecases Please fill with the d

Re: [openstack-dev] [Neutron][LBaaS] Load balancing use cases. Data from Operators needed.

the weekly meeting tomorrow! >>> >>> Cheers, >>> --Jorge >>> >>> From: Susanne Balle >>> Reply-To: "OpenStack Development Mailing List (not for usage >>> questions)" >>> Date: Tuesday, April 1, 2014 4:09 PM >&g

[openstack-dev] [Neutron][Nova][Tempest][Devstack] Change in default security group settings?

Hi devs, While working of one of tempest scenario tests I've found out that the code that spawns VM and access it on 80 port stopped working due security group rule allowing ingress for 80 port is not there. I'm saying 'stopped working' because previously it worked fine without any additional con

[openstack-dev] [Neutron][LBaaS] Weekly lbaas meeting at 14-00UTC

Hi, Let's continue keeping our regular meetings. Today we're going to discuss requirements/usage data we decided to collect. I've created a google spreadsheet to gather the data as it seems that wiki is not a best way of collecting it: https://docs.google.com/a/mirantis.com/spreadsheet/ccc?key=0

Re: [openstack-dev] [Neutron][Nova][Tempest][Devstack] Change in default security group settings?

/c/83280/ > https://review.openstack.org/#/c/83190/ > > -- > Kevin Benton > > > On Wed, Apr 2, 2014 at 11:34 PM, Eugene Nikanorov > wrote: > >> Hi devs, >> >> While working of one of tempest scenario tests I've found out that the >> code that spawns VM and

Re: [openstack-dev] [Neutron][LBaaS] Load balancing use cases and web ui screen captures

Hi Sam, I find google doc a little bit too heavy for ML discussion. So I'd like to extract the gist of the overall use case that we want to use when discussing an API (for ex, single-call API). Here it is as I see it (Sam, correct me if I'm wrong): User wants to setup web application that is avai

[openstack-dev] [Neutron][LBaaS] Weekly subteam meeting April 10 14-00 UTC

Hi folks, Our next meeting is as usual on Thursday, 14-00 UTC >From the last meeting there was basically two major action items: 1) contribute to deployment scenarios statistics: https://docs.google.com/a/mirantis.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc 2) Make propo

Re: [openstack-dev] [Neutron][LBaaS] Weekly subteam meeting April 10 14-00 UTC

e API" discussion on ML 2. outline issues of existing LBaaS API 3. Jorge to create API proposal based off of Atlas API spec. 4. Add "least common denominator" requirements to wiki Thanks, Eugene. On Wed, Apr 9, 2014 at 7:20 PM, Eugene Nikanorov wrote: > Hi folks, > > Ou

Re: [openstack-dev] [Neutron] API list operations are not fast as they could because they're dumb

Hi Salvatore, > For this reason I am thinking we should what technically is a simple change: use policy checks determine the list of attributes to show only once for list response, and then re-use that list for the whole response. I'm +1 to this idea. Also, would it be too difficult to have some

Re: [openstack-dev] Neutron Migrations, service plugins and Grenade jobs

Hi Salvatore, The described problem could be even worse if vendor drivers are considered. Doesn't #1 require that all DB tables are named differently? Otherwise it seems that user can't be sure in DB schema even if all tables are present. I think the big part of the problem is that we need to sup

Re: [openstack-dev] [Neutron][LBaaS] Requirements and API revision progress

Hi Stephen, Thanks for a good summary. Some comments inline. On Tue, Apr 15, 2014 at 5:20 AM, Stephen Balukoff wrote: > > > So! On this front: > > 1. Does is make sense to keep filling out use cases in Samuel's document > above? I can think of several more use cases that our customers actually >

Re: [openstack-dev] [Neutron][LBaaS] Load balancing use cases. Data from Operators needed.

t;> *SSL Offloading* >>> >>> 1 >>> >>> *High Availability* >>> >>> 0 >>> >>> *IP4 & IPV6 Address Support* >>> >>> 6 >>> >>> *Server Name Indication (SNI) Support* >>> >>> 3 >&g

[openstack-dev] [Neutron] Provider Framework and Flavor Framework

Hi folks, In Icehouse there were attempts to apply Provider Framework ('Service Type Framework') approach to VPN and Firewall services. Initially Provider Framework was created as a simplistic approach of allowing user to choose service implementation. That approach definitely didn't account for p

Re: [openstack-dev] [neutron] Neutron BP review process for Juno

I would prefer not to be strict on the requirements for diagrams. If it looks ok in ascii - that's fine, nwdiag is fine as well. I think both of tools worth mentioning in bp template. Thanks, Eugene. On Thu, Apr 17, 2014 at 12:06 AM, Alan Kavanagh wrote: > Tend to agree Nachi, that would be my

Re: [openstack-dev] [Neutron][LBaaS] Requirements and API revision progress

> > https://docs.google.com/document/d/1mTfkkdnPAd4tWOMZAdwHEx7IuFZDULjG9bTmWyXe-zo/edit > > Thanks, > Brandon Logan > > From: Eugene Nikanorov > Reply-To: "openstack-dev@lists.openstack.org" < > openstack-dev@lists.openstack.org> > Date: Tu

Re: [openstack-dev] [Neutron][LBaaS] Requirements and API revision progress

aS/LoadbalancerInstance/Discussion Thanks, Eugene. On Thu, Apr 17, 2014 at 12:59 AM, Brandon Logan wrote: > Sorry about that. It should be readable now. > -- > *From:* Eugene Nikanorov [enikano...@mirantis.com] > *Sent:* Wednesday, April 16, 2014

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

Hi folks, Our regular meeting is going to be on Thursday, 17, at 14-00 UTC We have some data and requirements to discuss. Also, we'll discuss the API proposal by Jorge & Brandon Thanks, Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.opensta

Re: [openstack-dev] [barbican] Barbican 2014.1 ("Icehouse") is released

Hi Douglas, could you please point to the project docs? Thanks, Eugene. On Thu, Apr 17, 2014 at 1:48 AM, Douglas Mendizabal < douglas.mendiza...@rackspace.com> wrote: > Hi everybody! > > It is my pleasure to announce the final release of Barbican for Icehouse > 2014.1 > > Information on the m

Re: [openstack-dev] [Neutron] Provider Framework and Flavor Framework

Hi Zang, 1. > so the tags is totally useless, and I suggest replace tags by provider > name/uuid. It is much more straightforward and easier. Funny thing is that the goal of flavor framework is directly opposite. We need to hide provider/vendor name. Ssl vpn or ipsec could be implemented by differ

Re: [openstack-dev] [Neutron][LBaaS] Requirements and API revision progress

the pits of it for our roadmap. The general issue with a single-call API is that you end up creating Heat-like template language to address the use cases that we're planning, and yet you'll have to have per-object operations... Thanks, Eugene. -- > *From:* Euge

Re: [openstack-dev] [Neutron][LBaaS] Requirements and API revision progress

Folks, As we're discussing single-call approach, I think it would be helpful to actually implement such API (e,g. practically, in the code) and see how it works, how compatibility is maintained and such. I think you could start with basic features available for single call - e.g. single vip and si

Re: [openstack-dev] [Neutron][LBaas] "Single call" API discussion

> > 3. Could you describe the most complicated use case that your single-call >> API supports? Again, please be very specific here. >> >> Same data can be derived from the link above. >> >> > Ok, I'm actually not seeing and complicated examples, but I'm guessing > that any attributes at the top of

Re: [openstack-dev] [Neutron][LBaas] "Single call" API discussion

> > > There's certainly something to be said for having a less-disruptive user > experience. And after all, what we've been discussing is so radical a > change that it's close to starting over from scratch in many ways. > > Yes, we assumed that starting from scratch would be the case at least as >

Re: [openstack-dev] [Neutron][LBaas] "Single call" API discussion

e not > supported right now. > > Maybe there's some way to allow the extensions to define their own > validation for their own resources and objects. That's probably another > topic for another day, though. > Yes, I think most extensions provide both additional resou

[openstack-dev] [Neutron][LBaaS] API discussion

Hi folks, I've added some API examples illustrating API/object model proposals on the wiki https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion Here's the link (also, at the bottom of the wiki page): https://etherpad.openstack.org/p/neutron-lbaas-api-proposals Thanks, E

[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 wrote: > On Wed, 2014-04-23 at 19:05 +0400, Eugene Nikanorov wrote: > > Hi neutrons, > > > > > > A quick question of the ^^^ > &

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

erhaps: "Network Service Type" > > /Alan > > -Original Message- > From: Jay Pipes [mailto:jaypi...@gmail.com] > Sent: April-23-14 11:29 AM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [Neutron] Flavor(?) Framework > > O

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 LB_B

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

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

;> >> merge time, if needed. Feature branches aren’t meant to be optional >> >> add-on components (I think), nor are they meant to live that long. >> >> Just a place to collaborate and work on a large chunk of code until >> >> it’s ready to merge. Though

[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

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

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

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 N

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 clarifi

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

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

r usage questions) > Subject: Re: [openstack-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 > &

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

e basis of what is defined on the flavor - it is a complex solution giving no benefits over existing dispatching method. Thanks, Eugene. On Mon, Jul 7, 2014 at 8:41 PM, Mark McClain wrote: > > On Jul 4, 2014, at 1:09 AM, Eugene Nikanorov > wrote: > > German, > > Fir

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, it

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

Some comments inline: > Agreed-- I think we need to more fully flesh out how extension list / tags > should work here before we implement it. But this doesn't prevent us from > rolling forward with a "version 1" of flavors so that we can start to use > some of the benefits of having flavors (like

<    1   2   3   >