At the summit session last week for group-based policy, there were many
concerns voiced about the approach being undertaken. I think those concerns
deserve a wider audience, and I'm going to highlight some of them here.
The primary concern seemed to be related to the complexity of the approach
On May 22, 2014, at 11:03 AM, Maru Newby wrote:
> At the summit session last week for group-based policy, there were many
> concerns voiced about the approach being undertaken. I think those concerns
> deserve a wider audience, and I'm going to highlight some of them here.
>
> The primary co
I would second Maru's concerns, and I would also like to add the following:
We need to acknowledge the fact that there are certain architectural
aspects of Neutron as a project that need to be addressed; at the
summit we talked about the core refactoring, a task oriented API, etc.
To me these item
Maru's concerns are that:
1. It is large
2. It is complex
And Armando's related concerns are:
3. Could dev/review cycles be better spent on refactoring
4. If refactored neutron was available, would a simpler option become more
viable
Let me address them in that order.
1. Re: It is large
Group po
On May 22, 2014, at 1:59 PM, Mandeep Dhami wrote:
>
> Maru's concerns are that:
> 1. It is large
> 2. It is complex
As per the discussion in the irc meeting today, I hope it is clear now that
eventual size and complexity are not real issue. Rather, I am concerned at how
we get there.
I ke
On 05/22/2014 07:03 PM, Maru Newby wrote:
On May 22, 2014, at 1:59 PM, Mandeep Dhami wrote:
Maru's concerns are that:
1. It is large
2. It is complex
As per the discussion in the irc meeting today, I hope it is clear now that
eventual size and complexity are not real issue. Rather, I am con
> each patch needs to receive core reviewer attention and that subsequent
patches incorporate their feedback.
At least two core neutron members were involved in creating the PoC, and at
least two more cores were involved in reviews at various times. In addition
to them, senior developers from at l
On May 22, 2014, at 4:35 PM, Mandeep Dhami wrote:
> > each patch needs to receive core reviewer attention and that subsequent
> > patches incorporate their feedback.
>
> At least two core neutron members were involved in creating the PoC, and at
> least two more cores were involved in reviews
OK.
On Thu, May 22, 2014 at 5:13 PM, Maru Newby wrote:
>
> On May 22, 2014, at 4:35 PM, Mandeep Dhami
> wrote:
>
> > > each patch needs to receive core reviewer attention and that
> subsequent patches incorporate their feedback.
> >
> > At least two core neutron members were involved in creati
On 22 May 2014 13:59, Mandeep Dhami wrote:
>
> Maru's concerns are that:
> 1. It is large
> 2. It is complex
>
> And Armando's related concerns are:
> 3. Could dev/review cycles be better spent on refactoring
> 4. If refactored neutron was available, would a simpler option become more
> viable
Th
g/wiki/Meetings/Neutron_Group_Policy
From: "Armando M."
To: "OpenStack Development Mailing List (not for usage questions)"
,
Date: 05/22/2014 11:24 PM
Subject: Re: [openstack-dev] [neutron][group-based-policy] Should we
revisit the priority of group
Hi Armando:
Those are good points. I will let Bob Kukura chime in on the specifics of
how we intend to do that integration. But if what you see in the
prototype/PoC was our final design for integration with Neutron core, I
would be worried about that too. That specific part of the code
(events/not
;OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>,
> Date: 05/22/2014 11:24 PM
> Subject: Re: [openstack-dev] [neutron][group-based-policy] Should we
> revisit the priority of group-based policy?
>
do continue the discussion on the mailing list.
>>
>> Best,
>>
>> Mohammad
>>
>> [1] https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy
>>
>> [image: Inactive hide details for "Armando M." ---05/22/2014 11:24:35
>> PM---On
Mohammad Banikazemi wrote:
>in Atlanta the support was overwhelmingly positive in my opinion. I just
>wanted to make sure this does not get >lost in our discussions.
Absolutely. I hadn't been following the group policy discussions prior to the
summit but I was very impressed with what I saw a
Thanks Paul. Feedback like this, from actual users of neutron in large
deployments, is the very reason why I feel so strongly that we need to keep
this a high priority work item.
Regards,
Mandeep
On Fri, May 23, 2014 at 9:28 AM, CARVER, PAUL wrote:
> Mohammad Banikazemi wrote:
>
> >in Atlant
Paul good points, and I am very happy to read that your expectations
are very closely aligned with the direction we have taken (in terms of
decoupling of the group policy layer from the underlying building
blocks).
Thanks also Kyle for your earlier email. I believe the team has always
been aligned
ing list.
>>
>> Best,
>>
>> Mohammad
>>
>> [1] https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy
>>
>> [image: Inactive hide details for "Armando M." ---05/22/2014 11:24:35
>> PM---On 22 May 2014 13:59, Mandeep
On 5/23/14, 12:46 AM, Mandeep Dhami wrote:
Hi Armando:
Those are good points. I will let Bob Kukura chime in on the specifics
of how we intend to do that integration. But if what you see in the
prototype/PoC was our final design for integration with Neutron core,
I would be worried about tha
Hi Bob, The approach towards having the neutron.manager.NeutronManager
provide access to the Controller classes seems like something worth
exploring for the shorter term.
Thanks,
~Sumit.
On Fri, May 23, 2014 at 12:31 PM, Robert Kukura
wrote:
>
> On 5/23/14, 12:46 AM, Mandeep Dhami wrote:
>
> Hi
On 23 May 2014 12:31, Robert Kukura wrote:
>
> On 5/23/14, 12:46 AM, Mandeep Dhami wrote:
>
> Hi Armando:
>
> Those are good points. I will let Bob Kukura chime in on the specifics of
> how we intend to do that integration. But if what you see in the
> prototype/PoC was our final design for integr
On 05/23/2014 03:31 PM, Robert Kukura wrote:
The core refactoring effort may eventually provide a nice solution, but
we can't wait for this. It seems we'll need to either use
python-neutronclient or get access to the Controller classes in the
meantime.
Using python-neutronclient will be the cle
22 matches
Mail list logo
