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 dh...@noironetworks.com
wrote:
Use this webex meeting for Audio streaming:
https://cisco.webex.com/ciscosales/j.php?MTID=m210c77f6f51a6f313a7d130d19ee3e4d
Topic: GBP Design Session
Date
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 mest...@mestery.com wrote:
On Mon, Oct 27, 2014 at 12:15 AM, Sumit Naiksatam
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).
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,
+1
I agree that this is a good idea.
Regards,
Mandeep
On Thu, Aug 28, 2014 at 10:13 AM, Jay Pipes jaypi...@gmail.com wrote:
On 08/28/2014 12:50 PM, Michael Still wrote:
On Thu, Aug 28, 2014 at 6:53 AM, Daniel P. Berrange berra...@redhat.com
wrote:
On Thu, Aug 28, 2014 at
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 mest...@mestery.com wrote:
On Wed, Aug 27,
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 fu...@yuggoth.org wrote:
On 2014-08-27
+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 d...@doughellmann.com
wrote:
On Aug 23, 2014, at 5:36 PM, Maru Newby ma...@redhat.com wrote:
On Aug 23,
.
Regards,
Rudra
On Thu, Jul 31, 2014 at 2:29 PM, Mandeep Dhami dh...@noironetworks.com
wrote:
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
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
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
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
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 l...@snabb.co wrote:
On 25 July 2014 20:05, Stefano Maffulli stef...@openstack.org wrote:
Indeed, communication is key.
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 have put a -1 or -2, and the issues that you have identified have
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
, Kyle Mestery mest...@mestery.com wrote:
On Fri, Jul 25, 2014 at 4:48 PM, Mandeep Dhami dh...@noironetworks.com
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
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
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 pc2...@att.com wrote:
Mohammad Banikazemi wrote:
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)
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
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 for design changes
22, 2014 at 4:03 PM, Maru Newby ma...@redhat.com wrote:
On May 22, 2014, at 1:59 PM, Mandeep Dhami dh...@noironetworks.com
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
OK.
On Thu, May 22, 2014 at 5:13 PM, Maru Newby ma...@redhat.com wrote:
On May 22, 2014, at 4:35 PM, Mandeep Dhami dh...@noironetworks.com
wrote:
each patch needs to receive core reviewer attention and that
subsequent patches incorporate their feedback.
At least two core neutron
represents that side
himself.
Regards,
Mandeep
On Thu, May 22, 2014 at 8:19 PM, Armando M. arma...@gmail.com wrote:
On 22 May 2014 13:59, Mandeep Dhami dh...@noironetworks.com wrote:
Maru's concerns are that:
1. It is large
2. It is complex
And Armando's related concerns are:
3
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 etherpad link. I would
like to get more deeply
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 sorla...@nicira.comwrote:
Some comments inline,
Salvatore
On 21 May 2014 15:23, Mandeep Dhami dh
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 dh...@noironetworks.comwrote:
Thanks for the link, Fawad. I had actually seen the etherpad, but I was
hoping that there was a design document
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
] 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 dh...@noironetworks.comwrote:
Hi:
I am not at the conference this week, but it is my understanding that
there was a proposal for neutron
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 isaku.yamah...@gmail.comwrote:
Hi.
The document is
- public on the web
- anyone can comment
So I don't think it's due to
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 m...@us.ibm.com wrote:
Thanks for the suggestion. That's what I plan to do next (barring other
possible suggestions). While the sharing is
I second the conf.d model.
Regards,
Mandeep
On Sun, May 4, 2014 at 10:13 AM, John Dickinson m...@not.mn wrote:
To add some color, Swift supports both single conf files and conf.d
directory-based configs. See
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
mscherba...@mirantis.comwrote:
:
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 20, 2014 at 11:37 PM, Mandeep Dhami
dh...@noironetworks.comwrote:
Just for clarification. Jenkins link
+1
On Mon, Apr 21, 2014 at 8:54 AM, mar...@redhat.com mandr...@redhat.comwrote:
On 21/04/14 18:29, Kyle Mestery wrote:
On Mon, Apr 21, 2014 at 9:38 AM, mar...@redhat.com mandr...@redhat.com
wrote:
Hi,
I think both PTL candidates mentioned process improvements wrt
contributions and
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,
I would be interested as well (UTC-8).
Regards,
Mandeep
On Wed, Feb 12, 2014 at 8:18 AM, Eugene Nikanorov
enikano...@mirantis.comwrote:
I'd be interested too.
Thanks,
Eugene.
On Wed, Feb 12, 2014 at 7:51 PM, Carl Baldwin c...@ecbaldwin.net wrote:
Paul,
I'm interesting in joining
38 matches
Mail list logo
