I haven't had a chance to review this patch in detail yet, but am
wondering if this is being integrated with ML2 as an extension driver?
If so, that should clearly address how dictionaries are extended and
input values are validated. If not, why?
-Bob
On 7/13/15 10:50 PM, Miguel Angel Ajo wrote:
Inline reply (I've added to CC relevant people for ml2/plugin.py
port_update extension
handing -via git blame-) as they probably have an opinion here
(specially the last
two options).
Kevin Benton wrote:
This sounds like a lot of overlap with the dict extend functions. Why
weren't they adequate for the QoS use case?
Let me explain, I believe Mike exceeded the proposal with AFTER_READ,
that's not the plan,
even if we could do as he proposed,
AFTER_READ dict extension is just a temporary workaround until we have
a separate explicit
api @armax is working on. Making explicit that your service is going
to extend resources,
and handled that in an ordered way is a good thing.
Afterwards, the source of this review has came from ML2 implementation of
AFTER_CREATE/AFTER_UPDATE notification for ports/nets.
Let me explain:
As a decoupled, "mixinless" service extending core resources, we
need to do two things:
1) Extending the core resources as other extensions would do, adding
stuff to the port/network
dicts, here's where it comes the current AFTER_READ dict extension,
and future API making
that more explicit and more controlled.
2) Verifying the extended values we receive on core resources, by
registering to BEFORE_*
callbacks. For example, if a tenant is trying to use a qos_profile_id
he doesn't have access to,
or that doesn't exist, we can cancel the operation by throwing an
exception.
We need to extend the notifications for ports and networks, as
that's not notified currently.
Mike will work on that too in a separate patch.
3) Taking the finally extended values and store associations in database
(AFTER_UPDATE/AFTER_CREATE) so any later reads of the
port/network will get the right
qos_profile_later in "after read".
We have found that AFTER_CREATE/AFTER_UPDATE happens at plugin level
(neutron/plugins/ml2/plugin.py / update_port) and that information
passed down is
very brief to our case (basically a "None" port if no ml2-know
attribute is changed), and
ml2 has to be aware of every single extension.
Here there are two options:
a) we make ml2 also aware of qos_profile_id changes, complicating
the business logic down
there, or...
b) we send the AFTER_CREATE/UPDATE events, and we listen to the
callback
listeners to such notification, and they will tell us if there's any
relevant field which must
be propagated down to agents. Then it's up to the agents to use such
field or not.
Mike's patch proposal is in the direction of (b), he's a long term
thinker, I was proposing him
to just go (a) for now, but let's discuss and find what's more right.
On Mon, Jul 13, 2015 at 7:58 AM, Mike Kolesnik<mkole...@redhat.com>
wrote:
Hi,
I sent a simple patch to check the possibility to add results to
callbacks:
https://review.openstack.org/#/c/201127/
This will allow us to decouple the callback logic from the ML2
plugin in
the QoS scenario where we need to update the agents in case the
profile_id
on a port/network changes.
It will also allow for a cleaner way to extend resource attributes as
AFTER_READ callbacks can return a dict of fields to add to the original
resource instead of mutating it directly.
Please let me know what you think of this idea.
Regards,
Mike
__________________________________________________________________________
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 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
