Well we can always develop the new framework and wait until the start of
the next cycle to swap over the existing agents if it doesn't look stable
enough.
On Wed, Aug 5, 2015 at 1:36 PM, Sukhdev Kapur
wrote:
> Hey Kyle,
>
> A concern was raised that this may create issue of breakages/instability
Hey Kyle,
A concern was raised that this may create issue of breakages/instability in
other agents at the late stage of the release cycle - hence I proposed a
separate repo. But, if a proper due-diligence is done and the core team has
a plan to deal with this, sounds like a good plan to me.
regar
Sounds good. As long as proper due-diligence is done and there are is no
duplication of effort, it make sense.
Thanks
-Sukhdev
On Wed, Aug 5, 2015 at 12:42 AM, Andreas Scheuring <
scheu...@linux.vnet.ibm.com> wrote:
> Sukhdev,
> last week I spent some time to figure out the current state of mod
I definitely don't think this work should start in a new repository. As
Sean and Andreas have said, I think the changes should be done in-tree
rather than creating another repository for this work.
On Wed, Aug 5, 2015 at 2:42 AM, Andreas Scheuring <
scheu...@linux.vnet.ibm.com> wrote:
> Sukhdev,
Sukhdev,
last week I spent some time to figure out the current state of modular
l2 agent design and discussion. I got the impression it's not in a good
shape! So I personally don't think that it makes any sense to start with
a modular l2 agent prototype and in the worst case throw it all away, as
On Wed, Aug 05, 2015 at 01:42:20AM EDT, Sukhdev Kapur wrote:
> We discussed this in ML2 sub-team meeting last week and felt the best
> approach is to implement this agent in a separate repo.
>
> There is already an on-going effort/plan for modular L2 agent. This agent
> would be a perfect candidat
We discussed this in ML2 sub-team meeting last week and felt the best
approach is to implement this agent in a separate repo.
There is already an on-going effort/plan for modular L2 agent. This agent
would be a perfect candidate to take on that effort and implement it for
macvtap agent. Once done,
I hacked up the LB agent and the OVS agent over some coffee - to see if
there are pieces that overlap. I believe there are - I'm hoping to
extract some code from each agent, into a common class. It's very WIP
but I'm hopeful that I'll be able to share some promising results soon.
https://review.op
I see this as two tasks: 1) A refactoring to share common code and 2)
the addition of another agent following the pattern of the others.
I'd prefer that the two tasks not be mixed in the same review because
it makes it more difficult to review as I think Kevin eluded to. For
me, either could be d
I would just de-dup anything that is obvious into a common class to inherit
from. Don't go through any major re-factorings because that will just take
longer to review and will probably need to be reworked anyway when we spend
more time on the modular agent stuff later in the cycle.
On Mon, Aug 3,
Hi,
I'm planning to add a new ml2 driver and agent to neutron supporting
macvtap attachments [1]. Kyle already decided, that this code should
land in the neutron tree [2]. The normal approach till now was to copy
an existing agent code and modify accordingly, which lead to a lot of
duplicated code
11 matches
Mail list logo
