+1
I agree with Pradeep and Doug that a new namespace makes for a better
structure for packaging and usage.
Regards,
Mandeep
-
On Mon, Aug 25, 2014 at 11:30 AM, Doug Hellmann
wrote:
>
> On Aug 23, 2014, at 5:36 PM, Maru Newby wrote:
>
> >
> > On Aug 23, 2014, at 4:06 AM, Sumit Naiksatam
T hese should all be comment changes, so there "should be" no impact. While
I agree that it is late for J3, IMO this is the type of change
(minor/comment only) that should be OK J4 rather than wait for Kilo.
On Wed, Aug 27, 2014 at 7:25 AM, Kyle Mestery wrote:
> On Wed, Aug 27, 2014 at 8:24 AM,
Also note that one of the "features" of the incubator is that it can be
packaged/released independently (like python-neutronclient) and a feature
branch is not designed for that workflow.
Regards,
Mandeep
On Wed, Aug 27, 2014 at 4:55 PM, Jeremy Stanley wrote:
> On 2014-08-27 16:05:36 -0700 (-
+1
I agree that this is a good idea.
Regards,
Mandeep
On Thu, Aug 28, 2014 at 10:13 AM, Jay Pipes wrote:
> On 08/28/2014 12:50 PM, Michael Still wrote:
>
>> On Thu, Aug 28, 2014 at 6:53 AM, Daniel P. Berrange
>> wrote:
>>
>>> On Thu, Aug 28, 2014 at 11:51:32AM +, Alan Kavanagh wro
I agree. Also, as this does not preclude using the incubator when it is
ready, this is a good way to start iterating on implementation in parallel
with those issues being addressed by the community.
In my view, the issues raised around the incubator were significant enough
(around packaging, handl
I agree with Kevin. Any option in-tree or in-incubator would need core
review time, and they are already oversubscribed with nova parity issues
(for Juno). So the only option to continue collaboration on experimenting
with policy based networking on current openstack is on stackforge (option
5).
S
I would be interested as well (UTC-8).
Regards,
Mandeep
On Wed, Feb 12, 2014 at 8:18 AM, Eugene Nikanorov
wrote:
> I'd be interested too.
>
> Thanks,
> Eugene.
>
>
> On Wed, Feb 12, 2014 at 7:51 PM, Carl Baldwin wrote:
>
>> Paul,
>>
>> I'm interesting in joining the discussion. UTC-7. Any w
I second the conf.d model.
Regards,
Mandeep
On Sun, May 4, 2014 at 10:13 AM, John Dickinson wrote:
> To add some color, Swift supports both single conf files and conf.d
> directory-based configs. See
> http://docs.openstack.org/developer/swift/deployment_guide.html#general-service-configuratio
Thanks Mohammad, this is sorely needed. I will update ether pad for our
"needs".
Regards,
Mandeep
On Tue, May 6, 2014 at 7:01 PM, Mohammad Banikazemi wrote:
> Thanks for the suggestion. That's what I plan to do next (barring other
> possible suggestions). While the sharing is limited in some c
I think that might an issue of access to google docs from China (in
general, not an issue specific to this document).
On Wed, May 7, 2014 at 8:05 PM, Isaku Yamahata wrote:
> Hi.
>
> The document is
> - public on the web
> - anyone can comment
> So I don't think it's due to setting of google-doc.
Hi:
I am not at the conference this week, but it is my understanding that there
was a proposal for neutron core API refactoring discussed yesterday. I am
trying to catch up with that discussion, is there a formal design
description or blueprint that I can review?
Thanks,
Mandeep
-
___
> [1] https://etherpad.openstack.org/p/refactoring-the-neutron-core
>
> Thanks,
>
> Fawad Khaliq
> (m) +1 408.966.2214
>
>
> On Thu, May 15, 2014 at 9:40 AM, Mandeep Dhami wrote:
>
>> Hi:
>>
>> I am not at the conference this week, but it is my und
> On a side note, I'm rather ignorant on python frameworks for distributed
coordination... concoord?
> Is zookeper something that should be ruled out because of language
restrictions?
I have not used zookeeper, so there might be reasons to use it where we
have to write java code,
but as long as zo
summit is going to be a significant barrier to participation in this
critical effort.
Regards,
Mandeep
On Thu, May 15, 2014 at 10:48 AM, Mandeep Dhami wrote:
>
> Thanks for the link, Fawad. I had actually seen the etherpad, but I was
> hoping that there was a design document back
6:52 AM, Collins, Sean <
sean_colli...@cable.comcast.com> wrote:
> On Tue, May 20, 2014 at 05:18:57PM EDT, Mandeep Dhami wrote:
> > Renewing the thread, is there a blueprint for this refactoring effort?
> >
> > In the email thread till now, we have just had an etherp
te task manager solution there. But
from what I gathered this was
>
orthogonal to the Pecan effort, which is merely a replacement of the
home-grown wsgi framework neutron is
>
running today.
I understand.
Regards,
Mandeep
On Wed, May 21, 2014 at 4:02 PM, Salvatore Orlando wr
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
OK
On Thu, May 22, 2014 at 7:36 AM, Collins, Sean <
sean_colli...@cable.comcast.com> wrote:
> On Wed, May 21, 2014 at 10:47:16PM EDT, Mandeep Dhami wrote:
> > The update from Sean seem to suggest to me that we needed blueprints only
> > if the public API changes, and not fo
ign and code.
On Thu, May 22, 2014 at 4: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 ho
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 c
represents that side
himself.
Regards,
Mandeep
On Thu, May 22, 2014 at 8:19 PM, Armando M. wrote:
> 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 rel
Hi Artem:
Can you provide reference to that network tomography work? I would be
interested in a follow up.
In a vendor specific plugin, I have used LLDPs for link discovery using
LLDPs (and by transitivity, the ToR discovery), but I did not build a more
complete topology view since neutron does n
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
My preferences:
For where, I'd go with Gary's recommendation (A) for two reasons (1)
Consistency and (2) I don't think it will create any boilerplate
requirements since the abstract class provides the default implementation.
For naming, I'd prefer to go with ML2 terminology for two reasons (1) Ag
Just for clarification. Jenkins link in the description puts the generated
HTML in the section "Juno approved specs" even tho' the blueprint is still
being reviewed. Am I looking at the right link?
Regards,
Mandeep
On Sun, Apr 20, 2014 at 10:54 PM, Mike Scherbakov
wrote:
> Yes, thanks, that's e
n Benton wrote:
>
>> Yes. It shows up in the approved section since it's just a build of the
>> patch as-is.
>>
>> The link is titled gate-neutron-specs-docs in the message from Jenkins.
>>
>> --
>> Kevin Benton
>>
>>
>> On Sun, Apr 2
+1
On Mon, Apr 21, 2014 at 8:54 AM, mar...@redhat.com wrote:
> On 21/04/14 18:29, Kyle Mestery wrote:
> > On Mon, Apr 21, 2014 at 9:38 AM, mar...@redhat.com
> wrote:
> >> Hi,
> >>
> >> I think both PTL candidates mentioned process improvements wrt
> >> contributions and reviews in their candida
If scaling becomes the issue, you can always do review at sub-team level
with at least two cores in each review meeting (say neutron-parity, ML2,
Services, LBaaS, etc). But probably best to start with one meeting and hit
that scale issue first.
Regards,
Mandeep
On Mon, Apr 21, 2014 at 9:20 AM, A
Hi Kyle:
Are you scheduling an on-demand meeting, or are you proposing that the
agenda for next neutron meeting include this as an on-demand item?
Regards,
Mandeep
On Mon, Oct 27, 2014 at 6:56 AM, Kyle Mestery wrote:
> On Mon, Oct 27, 2014 at 12:15 AM, Sumit Naiksatam
> wrote:
> > Several pe
Got it. So we will be discussing this in the 2PM meeting today. Correct?
Regards,
Mandeep
On Mon, Oct 27, 2014 at 10:02 AM, Kyle Mestery wrote:
> On Mon, Oct 27, 2014 at 11:48 AM, Mandeep Dhami
> wrote:
> > Hi Kyle:
> >
> > Are you scheduling an on-demand meeting, o
Use this webex meeting for Audio streaming:
https://cisco.webex.com/ciscosales/j.php?MTID=m210c77f6f51a6f313a7d130d19ee3e4d
Topic: GBP Design Session
Date: Tuesday, November 4, 2014
Time: 12:15 pm, Europe Time (Amsterdam, GMT+01:00)
Meeting Number: 205 658 563
Meeting Password: gbp
On Mon,
As no one was online, I closed the webex session.
On Tue, Nov 4, 2014 at 10:07 AM, Mandeep Dhami
wrote:
> Use this webex meeting for Audio streaming:
>
> https://cisco.webex.com/ciscosales/j.php?MTID=m210c77f6f51a6f313a7d130d19ee3e4d
>
>
> Topic: GBP Design Session
>
> D
Thanks for the deck Jay, that is very helpful.
Also, would it help the process by having some clear
guidelines/expectations around review time as well? In particular, if you
have put a -1 or -2, and the issues that you have identified have been
addressed by an update (or at least the original auth
at 3:14 PM, Kyle Mestery wrote:
> On Fri, Jul 25, 2014 at 4:48 PM, Mandeep Dhami
> wrote:
> >
> > Thanks for the deck Jay, that is very helpful.
> >
> > Also, would it help the process by having some clear
> guidelines/expectations
> > around review time a
Wow! These are the exact questions that I have struggled with. Thanks for
stating them so clearly.
Regards,
Mandeep
-
On Sat, Jul 26, 2014 at 11:02 AM, Luke Gorrie wrote:
> On 25 July 2014 20:05, Stefano Maffulli wrote:
>
>> Indeed, communication is key. I'm not sure how you envision to
AM, Jay Pipes wrote:
> On 07/25/2014 05:48 PM, Mandeep Dhami wrote:
>
>> Thanks for the deck Jay, that is very helpful.
>>
>> Also, would it help the process by having some clear
>> guidelines/expectations around review time as well? In particular, if
>> you
Hi Ryan:
As I stated in the patch review, the suggestion to use a "profiled API"
like IETF/CCITT is indeed very interesting. As a "profiled API" has not
been tried with any neutron model before, and as there is no existing
design pattern/best practices for how best to structure that, my
recommenda
Also, can I recommend that to avoid last minute rush of all the code in
Juno-3 (and then clogging up the gate at that time), we work as a team to
re-review patches that have addressed all previously identified issues?
For example, the for the GBP plugin, the first series of patches have been
updat
Hi Kyle:
As -2 is sticky, and as there exists a possibility that the original core
might not get time to get back to re-reviewing his, do you think that there
should be clearer guidelines on it's usage (to avoid what you identified as
"dropping of the balls")?
Salvatore had a good guidance in a r
xperience also a sticky -2 detracts other reviewers from reviewing an
>> updated patch.
>>
>> Either a time-frame or a possible override by PTL (move to -1) would help
>> make progress on the review.
>>
>> Regards,
>> Rudra
>>
>>
>> On Thu
40 matches
Mail list logo
