Re: [openstack-dev] [neutron][QoS] service-plugin or not discussion

[Miguel Angel Ajo Pelayo]

> On 24/4/2015, at 19:42, Armando M.  wrote:
> 
> 
> 
> On 24 April 2015 at 01:47, Miguel Angel Ajo Pelayo  > wrote:
> Hi Armando & Salvatore,
> 
>> On 23/4/2015, at 9:30, Salvatore Orlando > > wrote:
>> 
>> 
>> 
>> On 23 April 2015 at 01:30, Armando M. > > wrote:
>> 
>> On 22 April 2015 at 06:02, Miguel Angel Ajo Pelayo > > wrote:
>> 
>> Hi everybody,
>> 
>>In the latest QoS meeting, one of the topics was a discussion about how 
>> to implement
>> QoS [1] either as in core, or as a service plugin, in, or out-tree.
>> 
>> It is really promising that after only two meetings the team is already 
>> split! I cannot wait for the API discussion to start ;)
> 
> We seem to be relatively on the same page about how to model the API, but we 
> need yet to loop
> in users/operators who have an interest in QoS to make sure they find it 
> usable. [1]
> 
>>  
>> 
>> My apologies if I was unable to join, the meeting clashed with another one I 
>> was supposed to attend.
> 
> My bad, sorry ;-/
> 
>>  
>> 
>>It’s my feeling, and Mathieu’s that it looks more like a core feature, as 
>> we’re talking of
>> port properties that we define at high level, and most plugins (QoS capable) 
>> may want
>> to implement at dataplane/controlplane level, and also that it’s something 
>> requiring a good
>> amount of review.
>> 
>> "Core" is a term which is recently being abused in Neutron... However, I 
>> think you mean that it is a feature fairly entangled with the L2 mechanisms,
> 
> Not only the L2 mechanisms, but the description of ports themselves, in the 
> basic cases we’re just defining
> how “small” or “big” your port is.  In the future we could be saying “UDP 
> ports 5000-6000” have the highest
> priority on this port, or a minimum bandwidth of 50Mbps…, it’s marked with a 
> IPv6 flow label for hi-prio…
> or whatever policy we support.
> 
>> that deserves being integrated in what is today the "core" plugin and in the 
>> OVS/LB agents. To this aim I think it's good to make a distinction between 
>> the management plane and the control plane implementation.
>> 
>> At the management plane you have a few choices:
>> - yet another mixin, so that any plugin can add it and quickly support the 
>> API extension at the mgmt layer. I believe we're fairly certain everybody 
>> understands mixins are not sustainable anymore and I'm hopeful you are not 
>> considering this route.
> 
> Are you specifically referring to this on every plugin? 
> 
> class Ml2Plugin(db_base_plugin_v2.NeutronDbPluginV2, <---
> dvr_mac_db.DVRDbMixin, <---
> external_net_db.External_net_db_mixin, <---
> sg_db_rpc.SecurityGroupServerRpcMixin,   <---
> agentschedulers_db.DhcpAgentSchedulerDbMixin,  <---
> addr_pair_db.AllowedAddressPairsMixin,  <
> 
> I’m quite allergic to mixings, I must admit, but, if it’s not the desired 
> way, why don’t we refactor the way we compose plugins !? (yet more refactors 
> probably would slow us down, …) but… I feel like we’re pushing to 
> overcomplicate the design for a case which is similar to everything else we 
> had before (security groups, port security, allowed address pairs).
> 
> It feels wrong to have every similar feature done in a different way, even if 
> the current way is not the best one I admit.
> 
> 
> This attitude led us to the pain we are in now, I think we can no longer 
> afford to keep doing that. Bold goals require bold actions. If we don't step 
> back and figure out a way to extend the existing components without hijacking 
> the current codebase, it would be very difficult to give this effort the 
> priority it deserves.

I agree with you, please note my point of “let’s refactor it all into something 
better”, but refactoring the world and forgetting about new features is not 
sustainable, so, as you say we may start with new features as we explore better 
ways to do it. But I believe old extensions should also be equally addressed in 
the future.

I also lack the perspective yet to propose better approaches, I hope I will be 
able to do it in the future when I explore those areas of neutron.

Let’s focus in the API, and the lowest levels of what we’re going to do, and 
lets resolve everything else at a later time when that’s clear. I start to lean 
towards a service-plugin implementation as it’s going to be technically much 
more clean and decoupled.

>> - a service plugin - as suggested by some proposers. The service plugin is 
>> fairly easy to implement, and now Armando has provided you with a mechanism 
>> to register for callbacks for events in other plugins. This should make the 
>> implementation fairly straightforward. This also enables other plugins to 
>> implement QoS support.
>> - a ML2 mechanism driver + a ML2 extension driver. From an architectural 
>> perspective this would be the pr

Re: [openstack-dev] [neutron][QoS] service-plugin or not discussion

[Armando M.]

On 24 April 2015 at 01:47, Miguel Angel Ajo Pelayo 
wrote:

> Hi Armando & Salvatore,
>
> On 23/4/2015, at 9:30, Salvatore Orlando  wrote:
>
>
>
> On 23 April 2015 at 01:30, Armando M.  wrote:
>
>>
>> On 22 April 2015 at 06:02, Miguel Angel Ajo Pelayo 
>>  wrote:
>>
>>>
>>> Hi everybody,
>>>
>>>In the latest QoS meeting, one of the topics was a discussion about
>>> how to implement
>>> QoS [1] either as in core, or as a service plugin, in, or out-tree.
>>>
>>
> It is really promising that after only two meetings the team is already
> split! I cannot wait for the API discussion to start ;)
>
>
> We seem to be relatively on the same page about how to model the API, but
> we need yet to loop
> in users/operators who have an interest in QoS to make sure they find it
> usable. [1]
>
>
>
>>
>> My apologies if I was unable to join, the meeting clashed with another
>> one I was supposed to attend.
>>
>
> My bad, sorry ;-/
>
>
>>
>>>
>>>It’s my feeling, and Mathieu’s that it looks more like a core
>>> feature, as we’re talking of
>>> port properties that we define at high level, and most plugins (QoS
>>> capable) may want
>>> to implement at dataplane/controlplane level, and also that it’s
>>> something requiring a good
>>> amount of review.
>>>
>>
> "Core" is a term which is recently being abused in Neutron... However, I
> think you mean that it is a feature fairly entangled with the L2 mechanisms,
>
>
> Not only the L2 mechanisms, but the description of ports themselves, in
> the basic cases we’re just defining
> how “small” or “big” your port is.  In the future we could be saying “UDP
> ports 5000-6000” have the highest
> priority on this port, or a minimum bandwidth of 50Mbps…, it’s marked with
> a IPv6 flow label for hi-prio…
> or whatever policy we support.
>
> that deserves being integrated in what is today the "core" plugin and in
> the OVS/LB agents. To this aim I think it's good to make a distinction
> between the management plane and the control plane implementation.
>
> At the management plane you have a few choices:
> - yet another mixin, so that any plugin can add it and quickly support the
> API extension at the mgmt layer. I believe we're fairly certain everybody
> understands mixins are not sustainable anymore and I'm hopeful you are not
> considering this route.
>
>
> Are you specifically referring to this on every plugin?
>
> class Ml2Plugin(db_base_plugin_v2.NeutronDbPluginV2, <---
> dvr_mac_db.DVRDbMixin, <---
> external_net_db.External_net_db_mixin, <---
> sg_db_rpc.SecurityGroupServerRpcMixin,   <---
> agentschedulers_db.DhcpAgentSchedulerDbMixin,  <---
> addr_pair_db.AllowedAddressPairsMixin,  <
>
> I’m quite allergic to mixings, I must admit, but, if it’s not the desired
> way, why don’t we refactor the way we compose plugins !? (yet more
> refactors probably would slow us down, …) but… I feel like we’re pushing to
> overcomplicate the design for a case which is similar to everything else we
> had before (security groups, port security, allowed address pairs).
>
> It feels wrong to have every similar feature done in a different way, even
> if the current way is not the best one I admit.
>
>
This attitude led us to the pain we are in now, I think we can no longer
afford to keep doing that. Bold goals require bold actions. If we don't
step back and figure out a way to extend the existing components without
hijacking the current codebase, it would be very difficult to give this
effort the priority it deserves.

> - a service plugin - as suggested by some proposers. The service plugin is
> fairly easy to implement, and now Armando has provided you with a mechanism
> to register for callbacks for events in other plugins. This should make the
> implementation fairly straightforward. This also enables other plugins to
> implement QoS support.
> - a ML2 mechanism driver + a ML2 extension driver. From an architectural
> perspective this would be the preferred solution for a ML2 implementation,
> but at the same time will not provide management level support for non-ML2
> plugins.
>
>
> I’m a bit lost of why a a plugin (apart from ML2) could not just declare
> that it’s implementing the extension,  or it’s just that the only way we
> have to do it right now it’s mixings? why would ML2 avoid it?.
>
>
>
>
>>
>>>
>>>In the other hand Irena and Sean were more concerned about having a
>>> good separation
>>> of concerns (I agree actually with that part), and being able to do
>>> quicker iterations on a
>>> separate stackforge repo.
>>>
>>
>> Perhaps we're trying to address the issue at the wrong time. Once a
>> reasonable agreement has been reached on the data model, and the API,
>> whether we're going with a service plugin or core etc should be an
>> implementation detail. I think the crux of the matter is the data plane
>> integration. From a management and control standpoint it should be fairly
>> trivial to

Re: [openstack-dev] [neutron][QoS] service-plugin or not discussion

[Miguel Angel Ajo Pelayo]

Hi Armando & Salvatore,

> On 23/4/2015, at 9:30, Salvatore Orlando  wrote:
> 
> 
> 
> On 23 April 2015 at 01:30, Armando M.  > wrote:
> 
> On 22 April 2015 at 06:02, Miguel Angel Ajo Pelayo  > wrote:
> 
> Hi everybody,
> 
>In the latest QoS meeting, one of the topics was a discussion about how to 
> implement
> QoS [1] either as in core, or as a service plugin, in, or out-tree.
> 
> It is really promising that after only two meetings the team is already 
> split! I cannot wait for the API discussion to start ;)

We seem to be relatively on the same page about how to model the API, but we 
need yet to loop
in users/operators who have an interest in QoS to make sure they find it 
usable. [1]

>  
> 
> My apologies if I was unable to join, the meeting clashed with another one I 
> was supposed to attend.

My bad, sorry ;-/

>  
> 
>It’s my feeling, and Mathieu’s that it looks more like a core feature, as 
> we’re talking of
> port properties that we define at high level, and most plugins (QoS capable) 
> may want
> to implement at dataplane/controlplane level, and also that it’s something 
> requiring a good
> amount of review.
> 
> "Core" is a term which is recently being abused in Neutron... However, I 
> think you mean that it is a feature fairly entangled with the L2 mechanisms,

Not only the L2 mechanisms, but the description of ports themselves, in the 
basic cases we’re just defining
how “small” or “big” your port is.  In the future we could be saying “UDP ports 
5000-6000” have the highest
priority on this port, or a minimum bandwidth of 50Mbps…, it’s marked with a 
IPv6 flow label for hi-prio…
or whatever policy we support.

> that deserves being integrated in what is today the "core" plugin and in the 
> OVS/LB agents. To this aim I think it's good to make a distinction between 
> the management plane and the control plane implementation.
> 
> At the management plane you have a few choices:
> - yet another mixin, so that any plugin can add it and quickly support the 
> API extension at the mgmt layer. I believe we're fairly certain everybody 
> understands mixins are not sustainable anymore and I'm hopeful you are not 
> considering this route.

Are you specifically referring to this on every plugin? 

class Ml2Plugin(db_base_plugin_v2.NeutronDbPluginV2, <---
dvr_mac_db.DVRDbMixin, <---
external_net_db.External_net_db_mixin, <---
sg_db_rpc.SecurityGroupServerRpcMixin,   <---
agentschedulers_db.DhcpAgentSchedulerDbMixin,  <---
addr_pair_db.AllowedAddressPairsMixin,  <

I’m quite allergic to mixings, I must admit, but, if it’s not the desired way, 
why don’t we refactor the way we compose plugins !? (yet more refactors 
probably would slow us down, …) but… I feel like we’re pushing to 
overcomplicate the design for a case which is similar to everything else we had 
before (security groups, port security, allowed address pairs).

It feels wrong to have every similar feature done in a different way, even if 
the current way is not the best one I admit.

> - a service plugin - as suggested by some proposers. The service plugin is 
> fairly easy to implement, and now Armando has provided you with a mechanism 
> to register for callbacks for events in other plugins. This should make the 
> implementation fairly straightforward. This also enables other plugins to 
> implement QoS support.
> - a ML2 mechanism driver + a ML2 extension driver. From an architectural 
> perspective this would be the preferred solution for a ML2 implementation, 
> but at the same time will not provide management level support for non-ML2 
> plugins.

I’m a bit lost of why a a plugin (apart from ML2) could not just declare that 
it’s implementing the extension,  or it’s just that the only way we have to do 
it right now it’s mixings? why would ML2 avoid it?.


>  
> 
> 
>In the other hand Irena and Sean were more concerned about having a good 
> separation
> of concerns (I agree actually with that part), and being able to do quicker 
> iterations on a
> separate stackforge repo.
> 
> Perhaps we're trying to address the issue at the wrong time. Once a 
> reasonable agreement has been reached on the data model, and the API, whether 
> we're going with a service plugin or core etc should be an implementation 
> detail. I think the crux of the matter is the data plane integration. From a 
> management and control standpoint it should be fairly trivial to 
> expose/implement the API and business logic via a service plugin and, and 
> some of you suggested, integrate with the core via callbacks.

We have an update to the data model to be reviewed if you can have an eye on 
the last update [1], I’ll correct based on the last comments we received during 
this week.
I’m going to share it broadly on the mail list + operator list, probably with a 
brief description of how the api / cmdline wo

Re: [openstack-dev] [neutron][QoS] service-plugin or not discussion

[Salvatore Orlando]

On 23 April 2015 at 01:30, Armando M.  wrote:

>
> On 22 April 2015 at 06:02, Miguel Angel Ajo Pelayo 
> wrote:
>
>>
>> Hi everybody,
>>
>>In the latest QoS meeting, one of the topics was a discussion about
>> how to implement
>> QoS [1] either as in core, or as a service plugin, in, or out-tree.
>>
>
It is really promising that after only two meetings the team is already
split! I cannot wait for the API discussion to start ;)


>
> My apologies if I was unable to join, the meeting clashed with another one
> I was supposed to attend.
>
>
>>
>>It’s my feeling, and Mathieu’s that it looks more like a core feature,
>> as we’re talking of
>> port properties that we define at high level, and most plugins (QoS
>> capable) may want
>> to implement at dataplane/controlplane level, and also that it’s
>> something requiring a good
>> amount of review.
>>
>
"Core" is a term which is recently being abused in Neutron... However, I
think you mean that it is a feature fairly entangled with the L2 mechanisms
that deserves being integrated in what is today the "core" plugin and in
the OVS/LB agents. To this aim I think it's good to make a distinction
between the management plane and the control plane implementation.

At the management plane you have a few choices:
- yet another mixin, so that any plugin can add it and quickly support the
API extension at the mgmt layer. I believe we're fairly certain everybody
understands mixins are not sustainable anymore and I'm hopeful you are not
considering this route.
- a service plugin - as suggested by some proposers. The service plugin is
fairly easy to implement, and now Armando has provided you with a mechanism
to register for callbacks for events in other plugins. This should make the
implementation fairly straightforward. This also enables other plugins to
implement QoS support.
- a ML2 mechanism driver + a ML2 extension driver. From an architectural
perspective this would be the preferred solution for a ML2 implementation,
but at the same time will not provide management level support for non-ML2
plugins.


>
>>
>>In the other hand Irena and Sean were more concerned about having a
>> good separation
>> of concerns (I agree actually with that part), and being able to do
>> quicker iterations on a
>> separate stackforge repo.
>>
>
> Perhaps we're trying to address the issue at the wrong time. Once a
> reasonable agreement has been reached on the data model, and the API,
> whether we're going with a service plugin or core etc should be an
> implementation detail. I think the crux of the matter is the data plane
> integration. From a management and control standpoint it should be fairly
> trivial to expose/implement the API and business logic via a service plugin
> and, and some of you suggested, integrate with the core via callbacks.
>
> However, I am pretty sure there will be preliminary work necessary to
> integrate the server with the agent fabric (when there is one) so that is
> no longer a pain. Extending what the agent can do the way we did so far
> (e.g. by adding extra payloads/messages, mixin etc) is not sustainable, and
> incredibly brittle.
>

In my opinion the interesting part for an architectural decision here is
the control plane support for the reference implementation.
Adding more stuff to the OVS/LB agents might lead to an increase in
technical debt. On the other hand, adding a new QoS agent might lead to
further complexity - another loose bit to keep in sync with the rest, and
operators usually are not happy about having to manage the lifecycle of
another independent component. And as Armando say, you also need to
consider what changes you need to the RPC interface.

Without that information it is hard to make a call, and therefore I agree
with Armando that there are not yet enough elements to make a decision -
let's wait at least for a high level view of system architecture.


>
>>Since we didn’t seem to find an agreement, and I’m probably missing
>> some details,
>> I’d like to loop in our core developers and PTL to provide an opinion on
>> this.
>>
>
Core developers and the PTL do not necessarily have a better opinion...
instead in many cases they have a worse one!
By the way, if you go the stackforge route, then you can apply for becoming
an openstack project and one of you can become PTL! Isn't that wonderful?
Who doesn't want to be PTL these days?



>
>>
>> [1]
>> http://eavesdrop.openstack.org/meetings/neutron_qos/2015/neutron_qos.2015-04-21-14.03.log.html#l-192
>>
>>
>> Thanks for your patience,
>> Miguel Angel Ajo
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not

Re: [openstack-dev] [neutron][QoS] service-plugin or not discussion

[Armando M.]

On 22 April 2015 at 06:02, Miguel Angel Ajo Pelayo 
wrote:

>
> Hi everybody,
>
>In the latest QoS meeting, one of the topics was a discussion about how
> to implement
> QoS [1] either as in core, or as a service plugin, in, or out-tree.
>

My apologies if I was unable to join, the meeting clashed with another one
I was supposed to attend.


>
>It’s my feeling, and Mathieu’s that it looks more like a core feature,
> as we’re talking of
> port properties that we define at high level, and most plugins (QoS
> capable) may want
> to implement at dataplane/controlplane level, and also that it’s something
> requiring a good
> amount of review.
>
>
>In the other hand Irena and Sean were more concerned about having a
> good separation
> of concerns (I agree actually with that part), and being able to do
> quicker iterations on a
> separate stackforge repo.
>

Perhaps we're trying to address the issue at the wrong time. Once a
reasonable agreement has been reached on the data model, and the API,
whether we're going with a service plugin or core etc should be an
implementation detail. I think the crux of the matter is the data plane
integration. From a management and control standpoint it should be fairly
trivial to expose/implement the API and business logic via a service plugin
and, and some of you suggested, integrate with the core via callbacks.

However, I am pretty sure there will be preliminary work necessary to
integrate the server with the agent fabric (when there is one) so that is
no longer a pain. Extending what the agent can do the way we did so far
(e.g. by adding extra payloads/messages, mixin etc) is not sustainable, and
incredibly brittle.


>Since we didn’t seem to find an agreement, and I’m probably missing
> some details,
> I’d like to loop in our core developers and PTL to provide an opinion on
> this.
>
>
> [1]
> http://eavesdrop.openstack.org/meetings/neutron_qos/2015/neutron_qos.2015-04-21-14.03.log.html#l-192
>
>
> Thanks for your patience,
> Miguel Angel Ajo
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][QoS] service-plugin or not discussion

[Miguel Angel Ajo Pelayo]

Hi everybody,

   In the latest QoS meeting, one of the topics was a discussion about how to 
implement
QoS [1] either as in core, or as a service plugin, in, or out-tree.

   It’s my feeling, and Mathieu’s that it looks more like a core feature, as 
we’re talking of
port properties that we define at high level, and most plugins (QoS capable) 
may want
to implement at dataplane/controlplane level, and also that it’s something 
requiring a good
amount of review.


   In the other hand Irena and Sean were more concerned about having a good 
separation
of concerns (I agree actually with that part), and being able to do quicker 
iterations on a
separate stackforge repo.

   Since we didn’t seem to find an agreement, and I’m probably missing some 
details, 
I’d like to loop in our core developers and PTL to provide an opinion on this.


[1] 
http://eavesdrop.openstack.org/meetings/neutron_qos/2015/neutron_qos.2015-04-21-14.03.log.html#l-192


Thanks for your patience,
Miguel Angel Ajo




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev