On Mon, Jun 8, 2015 at 8:19 AM, Paul Carver wrote:
> What is the status of the flavor framework? Is this the right spec?
> https://blueprints.launchpad.net/neutron/+spec/neutron-flavor-framework
>
>
Yes, that's the correct spec. The status is that we've committed to
delivering Flavors in Liberty.
What is the status of the flavor framework? Is this the right spec?
https://blueprints.launchpad.net/neutron/+spec/neutron-flavor-framework
I'm trying to sort through how the ML3 proposal
https://review.openstack.org/#/c/105078/ fits in with requirements for
high performance (high throughput,
I am wholly in favor of this sentiment!
On Tue, Jul 22, 2014 at 8:16 AM, Kyle Mestery wrote:
> On Tue, Jul 22, 2014 at 10:10 AM, Eugene Nikanorov
> wrote:
> > Hi folks,
> >
> > I'd like to request an exception for the Flavor Framework spec:
> > https://review.openstack.org/#/c/102723/
> >
> >
On Tue, Jul 22, 2014 at 10:10 AM, Eugene Nikanorov
wrote:
> 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/
>
>
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.
__
Folks,
Initial implementation is here: https://review.openstack.org/#/c/105982/
It's pretty much complete (in terms of code parts) but may require some
adjustments and of course fixes.
I'm working on the client to test this end-to-end.
Thanks,
Eugene.
P.S. Almost got it under 1k lines!
On Th
Hi Salvatore!
Thank you for reading through my book-length e-mail and responding to all
my points!
Unfortunately, I have more responses for you, inline:
On Wed, Jul 16, 2014 at 4:22 PM, Salvatore Orlando
wrote:
> Hi Stephen,
>
> Thanks for your exhaustive comments!
>
I'm always happy to exhau
Hi Stephen,
Thanks for your exhaustive comments!
Some more replies from me inline.
Have a good evening,
Salvatore
On 16 July 2014 00:05, Stephen Balukoff wrote:
> Hi Salvatore and Eugene,
>
> Responses inline:
>
> On Tue, Jul 15, 2014 at 12:59 PM, Salvatore Orlando
> wrote:
>
>> I think I've
To the earlier question on whether we had defined what we wanted to
solve with the flavors framework, a high level requirement was
captured in the following approved spec for advanced services:
https://review.openstack.org/#/c/92200
On Wed, Jul 16, 2014 at 5:18 AM, Eugene Nikanorov
wrote:
> Some
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
.
Thanks,
German
From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Tuesday, July 15, 2014 3:06 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Flavor framework proposal
Hi Salvatore and Eugene,
Responses inline:
On Tue, Jul 15
: Eugene Nikanorov [mailto:enikano...@mirantis.com]
Sent: Tuesday, July 15, 2014 2:07 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Flavor framework proposal
Hi Stephen,
So, as was discussed, existing proposal has some aspects which better to
Hi Salvatore and Eugene,
Responses inline:
On Tue, Jul 15, 2014 at 12:59 PM, Salvatore Orlando
wrote:
> I think I've provided some examples in the review.
>
I was hoping for specific examples. The discussion I've seen so far has
been vague enough that it's difficult to see what people mean. It
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
I think I've provided some examples in the review.
However, the point is mostly to simplify usage from a user perspective -
allowing consumers of the neutron API to use the same flavour object for
multiple services.
There are other considerations which could be made, but since they're
dependent on
Hi folks!
I've noticed progress on the flavor framework discussion slowing down over
the last week. We would really like to see this happen for Juno because
it's critical for many of the features we'd also like to get into Juno for
LBaaS. I understand there are other Neutron extensions which will
tponed. In LBaaS we are
>> working hard on L7 and TLS extensions which we (the operators) like to
>> switch on and off with different flavors...
>>
>> German
>>
>> -Original Message-
>> From: Kyle Mestery [mailto:mest...@noironetworks.com]
>> Sent:
operators) like to switch
on and off with different flavors...
German
-Original Message-
From: Kyle Mestery
[mailto:mest...@noironetworks.com<mailto:mest...@noironetworks.com>]
Sent: Thursday, July 03, 2014 2:00 PM
To: OpenStack Development Mailing List (not for usage questio
.
Thanks,
German
From: Eugene Nikanorov [mailto:enikano...@mirantis.com]
Sent: Thursday, July 03, 2014 10:10 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Flavor framework: Conclusion
German,
First of all extension list looks lbaas
extensions which we (the operators) like to
> switch on and off with different flavors...
>
> German
>
> -Original Message-
> From: Kyle Mestery [mailto:mest...@noironetworks.com]
> Sent: Thursday, July 03, 2014 2:00 PM
> To: OpenStack Development Mailing List (not fo
, July 03, 2014 2:00 PM
To: OpenStack Development Mailing List (not for 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
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
wrote:
> Hi,
>
> Mark and me has spent some time today discussing existing proposals
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
+1
On Wed, Jul 2, 2014 at 10:12 PM, Kyle Mestery
wrote:
> We're coming down to the wire here with regards to Neutron BPs in
> Juno, and I wanted to bring up the topic of the flavor framework BP.
> This is a critical BP for things like LBaaS, FWaaS, etc. We need this
> work to land in Juno, as t
We're coming down to the wire here with regards to Neutron BPs in
Juno, and I wanted to bring up the topic of the flavor framework BP.
This is a critical BP for things like LBaaS, FWaaS, etc. We need this
work to land in Juno, as these other work items are dependent on it.
There are still two propo
the public API side of things.
>
> Best,
> -jay
>
> > Inactive hide details for Jay Pipes ---04/25/2014 12:09:43 PM---On
> > Fri, 2014-04-25 at 13:41 +, Akihiro Motoki wrote: > Hi,Jay Pipes
> > ---04/25/2014 12:09:43 PM---On Fri, 2014-04-25 at 13:41 +0000, Akih
Akihiro
> Motoki wrote: > Hi,
>
> From: Jay Pipes
> To: openstack-dev@lists.openstack.org,
> Date: 04/25/2014 12:09 PM
> Subject: Re: [openstack-dev] [Neutron] Flavor(?) Framework
>
>
>
> __
>
>
t set of capabilities within a
given defined service type.
Mohammad
From: Jay Pipes
To: openstack-dev@lists.openstack.org,
Date: 04/25/2014 12:09 PM
Subject: Re: [openstack-dev] [Neutron] Flavor(?) Framework
On Fri, 2014-04-25 at 13:41 +, Akihiro Motoki wrote:
> Hi,
>
On Fri, Apr 25, 2014 at 11:01 AM, Jay Pipes wrote:
> On Fri, 2014-04-25 at 13:41 +, Akihiro Motoki wrote:
> > Hi,
> >
> > I have a same question from Mark. Why is "flavor" not desired?
> > My first vote is "flavor" first, and then "type".
>
> Some reasons:
>
> First, flavor, in English, can a
On Fri, 2014-04-25 at 13:41 +, Akihiro Motoki wrote:
> Hi,
>
> I have a same question from Mark. Why is "flavor" not desired?
> My first vote is "flavor" first, and then "type".
Some reasons:
First, flavor, in English, can and often is spelled differently
depending on where you live in the w
> In addition, I prefer to managing flavor/type through API and decoupling
> flavor/type definition from provider definitions in configuration files
> as Cinder and Nova do.
Yes, that's the current proposal.
Thanks,
Eugene.
On Fri, Apr 25, 2014 at 5:41 PM, Akihiro Motoki wrote:
> Hi,
>
> I ha
Hi,
I have a same question from Mark. Why is "flavor" not desired?
My first vote is "flavor" first, and then "type".
There is similar cases in other OpenStack projects.
Nova uses "flavor" and Cinder uses "(volume) type" for similar cases.
Both cases are similar to our use cases and I think it is
The BP spec has been posted (thanks Eugene):
https://review.openstack.org/#/c/90070/1
The topic of "flavors" is also discussed in the weekly Neutron
advanced services' meeting:
https://wiki.openstack.org/wiki/Meetings/AdvancedServices
~Sumit.
On Thu, Apr 24, 2014 at 5:13 AM, Eugene Nikanorov
w
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 wrote:
> On 24/04/14 13:54, Eugene Nikanorov wrote:
> > Marios,
> >
> > here's the link with proposal description:
> > https://wiki.openstack.org
On 24/04/14 13:54, Eugene Nikanorov wrote:
> Marios,
>
> here's the link with proposal description:
> https://wiki.openstack.org/wiki/Neutron/FlavorFramework
thanks very much (sorry should have found that easily); I'm wondering if
the existing blueprint @[1] and (information from) wiki can be com
Marios,
here's the link with proposal description:
https://wiki.openstack.org/wiki/Neutron/FlavorFramework
Mark: personally I find name 'flavor' suitable because it's the same
concept as nova flavor.
So I'll use it in BP/code unless something better come up.
Thanks,
Eugene.
On Thu, Apr 24, 20
On 23/04/14 18: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 for the resource.
> Names th
On Apr 23, 2014, at 11:05 AM, 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.
Why is flavor undesirable? The terminolog
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
Think that's a good idea Jay
A slight twist perhaps: "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
Suggest “service-type” Eugene.
/Alan
From: Eugene Nikanorov [mailto:enikano...@mirantis.com]
Sent: April-23-14 11:05 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Neutron] Flavor(?) Framework
Hi neutrons,
A quick question of the ^^^
I heard from many of you that a term
On Wed, 2014-04-23 at 19:24 +0400, Eugene Nikanorov wrote:
> Thanks, that can be an option.
> Just wondering, can we find a single name?
service type? :)
Oh, I guess that's taken. Well, we could always rename the existing
service type to "service class" or "service family".
Best,
-jay
__
On Wed, Apr 23, 2014 at 10:19 AM, Jay Pipes wrote:
> On Wed, 2014-04-23 at 19:05 +0400, 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 g
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 ^^^
> > I heard from many of you that a
On Wed, 2014-04-23 at 19:05 +0400, 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 for the
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
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
ybe even the tenant might group such capabilities (ha, L7,
>> SSL) and name them advanced-adc and another group of capabilities (no-ha,
>> L7, SSL) and name them adc-for-testing.
>>
>>
>>
>> This leads to an abbreviation of:
>>
>> · Tenant create
creates a vip the requires adc-for-testing.
>
>
>
> Regards,
>
> -Sam.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:* Eugene Nikanorov [mailto:enikano...@mirantis.com]
> *Sent:* Thursday, February 27, 2014 12:12 AM
> *To:*
ant creates a vip the requires adc-for-testing.
Regards,
-Sam.
From: Eugene Nikanorov [mailto:enikano...@mirantis.com]
Sent: Thursday, February 27, 2014 12:12 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Neutron] Flavor Framework
Hi neutron folks,
I
On Fri, 2014-02-28 at 01:31 -0800, Gary Duan wrote:
> What are the parameters that will be part of flavor definition? As I
> am thinking of it now, the parameter could be performance and capacity
> related, for example, throughput, max. session number and so on; or
> capability related, for example
On Fri, 2014-02-28 at 10:19 +0400, Eugene Nikanorov wrote:
>
> 1) I'm not entirely sure that a provider attribute is even
> necessary to
> expose in any API. What is important is for a scheduler to
> know which
> drivers are capable of servicing a se
HI Gary,
My initial plan was to let cloud admin decide which parameters should
flavor have.
As an alternative, we can have specific set of parameters for each service
and cloud admin will only specify their values for particular flavor.
Another option could be to have a set of tags in the flavor,
Hi, Eugene,
What are the parameters that will be part of flavor definition? As I am
thinking of it now, the parameter could be performance and capacity
related, for example, throughput, max. session number and so on; or
capability related, for example, HA, L7 switching.
Compared to # of CPU and m
Hi Jay,
Thanks for looking into this.
> 1) I'm not entirely sure that a provider attribute is even necessary to
> expose in any API. What is important is for a scheduler to know which
> drivers are capable of servicing a set of attributes that are grouped
> into a "flavor".
>
Well, provider beco
On Thu, 2014-02-27 at 17:23 -0800, Joe Gordon wrote:
> On Thu, Feb 27, 2014 at 5:05 PM, Jay Pipes wrote:
> > On Thu, 2014-02-27 at 15:12 -0800, Joe Gordon wrote:
> >> On Thu, Feb 27, 2014 at 2:37 PM, Jay Pipes wrote:
> >> > On Thu, 2014-02-27 at 02:11 +0400, Eugene Nikanorov wrote:
> >> >> Hi neu
On Thu, Feb 27, 2014 at 5:05 PM, Jay Pipes wrote:
> On Thu, 2014-02-27 at 15:12 -0800, Joe Gordon wrote:
>> On Thu, Feb 27, 2014 at 2:37 PM, Jay Pipes wrote:
>> > On Thu, 2014-02-27 at 02:11 +0400, Eugene Nikanorov wrote:
>> >> Hi neutron folks,
>> >>
>> >> I know that there are patches on gerrit
On Thu, 2014-02-27 at 15:12 -0800, Joe Gordon wrote:
> On Thu, Feb 27, 2014 at 2:37 PM, Jay Pipes wrote:
> > On Thu, 2014-02-27 at 02:11 +0400, Eugene Nikanorov wrote:
> >> Hi neutron folks,
> >>
> >> I know that there are patches on gerrit for VPN, FWaaS and L3 services
> >> that are leveraging P
On Thu, Feb 27, 2014 at 2:37 PM, Jay Pipes wrote:
> On Thu, 2014-02-27 at 02:11 +0400, Eugene Nikanorov wrote:
>> Hi neutron folks,
>>
>> I know that there are patches on gerrit for VPN, FWaaS and L3 services
>> that are leveraging Provider Framework.
>> Recently we've been discussing more compreh
On Thu, 2014-02-27 at 02:11 +0400, Eugene Nikanorov wrote:
> Hi neutron folks,
>
> I know that there are patches on gerrit for VPN, FWaaS and L3 services
> that are leveraging Provider Framework.
> Recently we've been discussing more comprehensive approach that will
> allow user to choose service
Hi neutron folks,
I know that there are patches on gerrit for VPN, FWaaS and L3 services that
are leveraging Provider Framework.
Recently we've been discussing more comprehensive approach that will allow
user to choose service capabilities rather than vendor or provider.
I've started creating des
61 matches
Mail list logo
