On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton blak...@gmail.com wrote:
I believe the referential security group rules solve this problem (unless
I'm not understanding):
I think the disconnect is that you are comparing the way to current mapping
driver implements things for the reference
On Wed, Aug 6, 2014 at 11:07 PM, Stefano Maffulli stef...@openstack.org
wrote:
On 08/06/2014 11:19 AM, Edgar Magana wrote:
That is the beauty of the open source projects, there is always a
smartest
reviewer catching out the facts that you don¹t.
And yet, the specification clearly talks
On Wed, Aug 6, 2014 at 12:45 PM, Ryan Moats rmo...@us.ibm.com wrote:
Aaron Rosen aaronoro...@gmail.com wrote on 08/06/2014 02:12:05 PM:
From: Aaron Rosen aaronoro...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:
On 08/06/2014 04:13 PM, Sumit Naiksatam wrote:
On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton blak...@gmail.com wrote:
I believe the referential security group rules solve this problem (unless
I'm not understanding):
I think the disconnect is that you are comparing the way to current mapping
+1 Eugene,
Still, there's a point in Stefano's thread:
There's a time for discussing merging strategies, models, and naming
conventions... And this time is called BP approval :)
Just saying.
Ivar.
On Wed, Aug 6, 2014 at 10:21 PM, Eugene Nikanorov enikano...@mirantis.com
wrote:
On Wed,
Basically, I am admitting that I did not catch in my review the part of
the endpoint term that Jay was pointing out.
Edgar
On 8/6/14, 11:32 AM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote:
Not sure what you are talking about? You claim now that you had
suggestion which was not considered,
Hi all!
Short version: if you have operational knowledge setting up Ironic
(either the Icehouse release or current trunk), you can help out a lot
right now by sharing that knowledge.
Long version...
I've seen an influx of folks interested in deploying Ironic over the
past few months, which is
Jay Pipes jaypi...@gmail.com wrote on 08/06/2014 04:09:20 PM:
From: Jay Pipes jaypi...@gmail.com
To: openstack-dev@lists.openstack.org
Date: 08/06/2014 04:12 PM
Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy
and the way forward
On 08/06/2014 03:46 PM, Kevin Benton
Vendors swapping out components is only one possibility. Once people use
this declarative model, optimizations can be made on the reference side as
well. ACLs can be placed on L3 agents to reduce the rule count on
individual compute nodes, etc. Everyone benefits from the abstraction, not
just
On Wed, Aug 6, 2014 at 1:27 PM, Jay Pipes jaypi...@gmail.com wrote:
On 08/06/2014 04:13 PM, Sumit Naiksatam wrote:
On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton blak...@gmail.com wrote:
I believe the referential security group rules solve this problem
(unless
I'm not understanding):
I
Hi Edgar,
Actually, I think that other reviewers saw that name clash, and still
thought it was ok to use the same terminology in such a different context.
BP reviews are a community effort right? So of course someones' idea may be
different from yours.
Regards,
Ivar.
On Wed, Aug 6, 2014 at
On Wed 06 Aug 2014 01:21:26 PM PDT, Eugene Nikanorov wrote:
So I don't think it's fair to blame reviewers here.
Just want to be super clear: there is no 'blaming' here. This is a
request to regroup and look at why we are having this conversation about
GBP now, this late in cycle, and about such
On Aug 6, 2014, at 1:27 PM, Jay Pipes jaypi...@gmail.com wrote:
However, it seems to me that the end-goal of the GBP effort is *actually* to
provide a higher-layer API to Neutron that would essentially enable
proprietary vendors to entirely swap out all of Neutron core for a new set of
Jay
Doesnt the current plugin model in neutron work the way you are saying. We
have a a core set of APIs that there is a reference model for and
individual vendors have substituted plugins that enhance and sometimes
replace networking component. GBP in that respect does not change. There is
a
On 08/06/2014 04:36 PM, Sumit Naiksatam wrote:
On Wed, Aug 6, 2014 at 1:27 PM, Jay Pipes jaypi...@gmail.com wrote:
On 08/06/2014 04:13 PM, Sumit Naiksatam wrote:
On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton blak...@gmail.com wrote:
I believe the referential security group rules solve this
Ivar,
Of course and this is why we are having this conversation, in order to merge
our different opinions.
Edgar
From: Ivar Lazzaro ivarlazz...@gmail.commailto:ivarlazz...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
Maybe we should change how we wait?
I get that we don't want to sit around forever, but perhaps we should
specify a total maximum time to wait instead of a number of iterations
of a loop? Something like 15 minutes should be long enough for
anyone!. Eventlet sleeps are also pretty cheap, so having
On Wed, Aug 6, 2014 at 1:52 PM, Jay Pipes jaypi...@gmail.com wrote:
On 08/06/2014 04:36 PM, Sumit Naiksatam wrote:
On Wed, Aug 6, 2014 at 1:27 PM, Jay Pipes jaypi...@gmail.com wrote:
On 08/06/2014 04:13 PM, Sumit Naiksatam wrote:
On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton
On 08/06/2014 04:51 PM, Prasad Vellanki wrote:
Jay
Doesnt the current plugin model in neutron work the way you are saying.
We have a a core set of APIs that there is a reference model for and
individual vendors have substituted plugins that enhance and sometimes
replace networking component. GBP
Yes, indeed.
I do not want to be over dramatic but the discussion on the original Group
Based Policy and the way forward thread is nothing short of heartbreaking.
After months and months of discussions, three presentations at the past
three summits, a design session at the last summit, and (most
On 08/06/2014 01:14 PM, Yuriy Taraday wrote:
On Wed, Aug 6, 2014 at 7:23 PM, Ben Nemec openst...@nemebean.com
mailto:openst...@nemebean.com wrote:
Again, this is why the tests should pass against all of your commits.
If that's the case, you can verify your changes as you rebase
[snipping to save BW]
Aaron Rosen aaronoro...@gmail.com wrote on 08/06/2014 03:26:24 PM:
Note: I'm not going to use the pure group policy API as I have been
a fan of the
2-group approach from day 1, I'm going to use the commands as stated
in the patch set, and I'm going to assume (dangerous
I also am in favor of this. +1
Chris Krelle
On Wed, Aug 6, 2014 at 9:04 AM, Jay Faulkner j...@jvf.cc wrote:
Similarly, I appreciated this idea when we discussed it at the mid-cycle
and doing so here.
+1
-Jay Faulkner
From: Lucas Alvares Gomes
On Wed, Aug 6, 2014 at 2:03 AM, Thierry Carrez thie...@openstack.org wrote:
We seem to be unable to address some key issues in the software we
produce, and part of it is due to strategic contributors (and core
reviewers) being overwhelmed just trying to stay afloat of what's
happening. For
On 08/06/2014 04:51 PM, Pedro Marques wrote:
Neutron allows vendors to speak to proprietary device APIs, it was
designed to do so, AFAIK. It is also possibly to entirely swap out
all of the Neutron core... the proponents of the group based policy
didn't have to go through so much trouble if that
Given how this discussion has gone, I understand Mohammad's despair. But it
seems like people are treating the Stackforge proposal as really nothing more
than a black hole. I'm a relative newcomer to this community, so that's
probably why I took Mark at his word when he presented it as a way
In all seriousness, folks, I'm bringing up points about the proposed API
because I see the current mess of Neutron integration with Nova, I see that
nova-network has been undeprecated due to continuing lack of parity and
HA concerns in Neutron, and I want things to be better, not worse.
Again, I
+1 Mohammad.
On Aug 6, 2014 11:08 PM, Mohammad Banikazemi m...@us.ibm.com wrote:
Yes, indeed.
I do not want to be over dramatic but the discussion on the original Group
Based Policy and the way forward thread is nothing short of heartbreaking.
After months and months of discussions, three
I have to agree with Duncan here. I also don't know if I fully understand
the limit in options. Stress test seems like it could/should be different
(again overlap isn't a horrible thing) and I don't see it as siphoning off
resources so not sure of the issue. We've become quite wrapped up in
+1,
I think in future we should invite the other project(i.e. Nova) core member
to review the blueprint if it is related to that specific project.
On Wed, Aug 6, 2014 at 5:01 PM, Mohammad Banikazemi m...@us.ibm.com wrote:
Yes, indeed.
I do not want to be over dramatic but the discussion
Edgar,
Actually, As Pedro said, I think that the time for discussing these kind of
concerns was the BP approval. The fact that it has been approved after many
proposals and reviews means that a community effort wanted the GBP to be
implemented in this release cycle the way it was presented at
+1 Kevin. I really fail to see how a patch which has been ready for a long
time now is the worst enemy of Nova Parity. This is starting to feel kind
of ad-hoc...
On Aug 6, 2014 11:42 PM, Kevin Benton blak...@gmail.com wrote:
In all seriousness, folks, I'm bringing up points about the proposed
On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton blak...@gmail.com wrote:
I believe the referential security group rules solve this problem
(unless I'm not understanding):
I think the disconnect is that you are comparing the way to current
mapping driver implements things for the reference
I'll start using pictures now, so let's assume M is the latest commit on
the master.
On Wed, Aug 6, 2014 at 9:31 PM, Zane Bitter zbit...@redhat.com wrote:
On 04/08/14 19:18, Yuriy Taraday wrote:
Hello, git-review users!
I'd like to gather feedback on a feature I want to implement that might
Hey LBaaS folks,
This is you friendly reminder to provide any agenda items for tomorrow's weekly
IRC meeting. Please add them to the agenda wiki ==
https://wiki.openstack.org/wiki/Network/LBaaS#Agenda. The agenda currently has
these items:
* Review Updates
Cheers,
--Jorge
P.S. Also,
Action items from today's Octavia meeting:
1. We're going to hold off for a couple days on merging the constitution
and preliminary road map to give people (and in particular Ebay) a chance
to review and comment.
2. Stephen is going to try to get Octavia v0.5 design docs into gerrit
review by
Oh, looks like we got a bit of a race condition in messages. I hope you
don't mind.
On Wed, Aug 6, 2014 at 11:00 PM, Ben Nemec openst...@nemebean.com wrote:
On 08/06/2014 01:42 PM, Yuriy Taraday wrote:
On Wed, Aug 6, 2014 at 6:20 PM, Ben Nemec openst...@nemebean.com
wrote:
On 08/06/2014
By working at the port level you have already eliminated your ability to
implement the filtering at different components of the network. They now
need to be implemented in stateful rules at the port level and the device
has to support security groups.
On Wed, Aug 6, 2014 at 4:03 PM, Aaron Rosen
This thread is moving so fast I can't keep up!
The fact that troubles me is that I am unable to grasp how we move forward,
which was the point of this thread to start with. It seems we have 2
options:
- We make GBP to merge as is, in the Neutron tree, with some minor revision
(e.g. naming?);
-
I think we should merge it and just prefix the API for now with
'/your_application_will_break_after_juno_if_you_use_this/'
On Aug 6, 2014 4:41 PM, Armando M. arma...@gmail.com wrote:
This thread is moving so fast I can't keep up!
The fact that troubles me is that I am unable to grasp how we
I would reword that to:
'/your_application_may_break_after_juno_if_you_use_this/'
in the event of the possibility that it doesn't break. ;-)
On Wed, Aug 6, 2014 at 3:47 PM, Kevin Benton blak...@gmail.com wrote:
I think we should merge it and just prefix the API for now with
Ivar,
You are totally right. I just want to clarify that I haven’t express any
disagreement on the plugin, I actually (as Sumit mentioned) +2 this patch
before. I just pointed our that I have expressed previously that GBP should use
the standard Policy Terminology. I did not push hard enough
On 6 August 2014 15:47, Kevin Benton blak...@gmail.com wrote:
I think we should merge it and just prefix the API for now with
'/your_application_will_break_after_juno_if_you_use_this/'
And you make your call based and what pros and cons exactly, If I am ask?
Let me start:
Option 1:
- pros
On Wed, Aug 6, 2014 at 3:35 PM, Kevin Benton blak...@gmail.com wrote:
By working at the port level you have already eliminated your ability to
implement the filtering at different components of the network. They now
need to be implemented in stateful rules at the port level and the device
has
I was asked beforehand what I mean with
* consider GBP an 'experimental' V3 tenant API (this was mentioned
somewhere in this thread) and treat it accordingly
The group based policies, although implemented as a service plugin, are
quite different from the ones we have now. Things like firewall,
On Aug 6, 2014, at 2:01 PM, Mohammad Banikazemi
m...@us.ibm.commailto:m...@us.ibm.com
wrote:
Yes, indeed.
I do not want to be over dramatic but the discussion on the original Group
Based Policy and the way forward thread is nothing short of heartbreaking.
After months and months of discussions,
Folks,
Just wanted to share with you that Arista CI has been up and running 24x7
since the beginning of this year with no down time.
This morning it posted a vote on 10,000th Neutron patch
cheers..
-Sukhdev
___
OpenStack-dev mailing list
On Aug 5, 2014, at 4:52 PM, Joshua Harlow harlo...@yahoo-inc.com wrote:
I'm pretty sure yahoo is another case, with a large set of clusters on
nova-network still ;)
I believe we have been active in these discussions, although I'm unsure what
was discussed at the meetup (being that I had
Given this information I don't see any reason why the backend system
couldn't do enforcement at the logical router and if it did so neither
parties would know.
With security groups you are specifying that nothing can contact these
devices on those ports unless they come from the allowed IP
On Aug 6, 2014, at 3:56 PM, Armando M. arma...@gmail.com wrote:
On 6 August 2014 15:47, Kevin Benton blak...@gmail.com wrote:
I think we should merge it and just prefix the API for now with
'/your_application_will_break_after_juno_if_you_use_this/'
And you make your call based and what
On Wed, Aug 6, 2014 at 4:18 PM, Kevin Benton blak...@gmail.com wrote:
Given this information I don't see any reason why the backend system
couldn't do enforcement at the logical router and if it did so neither
parties would know.
With security groups you are specifying that nothing can
On 08/06/2014 07:08 PM, CARVER, PAUL wrote:
On Aug 6, 2014, at 2:01 PM, Mohammad Banikazemi
m...@us.ibm.commailto:m...@us.ibm.com
wrote:
Yes, indeed.
I do not want to be over dramatic but the discussion on the original Group
Based Policy and the way forward thread is nothing short of
This is probably not intentional from your part ,but your choice of words
make it seem that you are deriding the efforts of the team behind this
effort. While i may disagree technically here and there with their current
design, it seems to me that the effort in question is rather broad based
On 06/08/14 18:12, Yuriy Taraday wrote:
2. since hacking takes tremendous amount of time (you're doing a Cool
Feature (tm), nothing less) you need to update some code from master, so
you're just merging master in to your branch (i.e. using Git as you'd
use it normally);
This is not how I'd
That's the point. By using security groups, you are forcing a certain kind
of enforcement that must be honored and might not be necessary if the
original intent was just to isolate between groups. In the example you
gave, it cannot be implemented on the router without violating the
constraints of
[Moving my reply to the correct thread as someone changed the subject line.]
On Wed, Aug 6, 2014 at 4:18 PM, Kevin Benton blak...@gmail.com wrote:
Given this information I don't see any reason why the backend system
couldn't do enforcement at the logical router and if it did so neither
I'm curious, how would having Nova reviewers look at this have helped?
On Wed, Aug 6, 2014 at 5:41 PM, Jay Pipes jaypi...@gmail.com wrote:
On 08/06/2014 07:08 PM, CARVER, PAUL wrote:
On Aug 6, 2014, at 2:01 PM, Mohammad Banikazemi m...@us.ibm.commailto:
m...@us.ibm.com
wrote:
Yes,
[Moving my reply to the correct thread as someone changed the subject line.
Attempt 2 :) ]
On Wed, Aug 6, 2014 at 4:18 PM, Kevin Benton blak...@gmail.com wrote:
Given this information I don't see any reason why the backend system
couldn't do enforcement at the logical router and if it did so
[Moving my reply to the correct thread as someone changed the subject line.
Attempt 3 :'( ]
On Wed, Aug 6, 2014 at 4:18 PM, Kevin Benton blak...@gmail.com wrote:
Given this information I don't see any reason why the backend system
couldn't do enforcement at the logical router and if it did
Gah, clearly hitting some kind of gmail bug as i replied to the right
thread all 3 times i believe.
On Wed, Aug 6, 2014 at 4:56 PM, Aaron Rosen aaronoro...@gmail.com wrote:
[Moving my reply to the correct thread as someone changed the subject
line. Attempt 3 :'( ]
On Wed, Aug 6, 2014 at
On 6 August 2014 22:23, Christopher Yeoh cbky...@gmail.com wrote:
On Wed, Aug 6, 2014 at 5:41 PM, Aaron Rosen aaronoro...@gmail.com wrote:
On Wed, Aug 6, 2014 at 12:59 AM, Gary Kotton gkot...@vmware.com wrote:
From: Aaron Rosen aaronoro...@gmail.com
Reply-To: OpenStack List
+1
On Aug 6, 2014 7:07 PM, Salvatore Orlando sorla...@nicira.com wrote:
I was asked beforehand what I mean with
* consider GBP an 'experimental' V3 tenant API (this was mentioned
somewhere in this thread) and treat it accordingly
The group based policies, although implemented as a service
Hi Pedro,
I agree that having as much users/operators as possible using the API is
the winner option.
I think you should move this comment also in the main thread since it looks
that the Subject has been accidentally modified.
Cheers,
Ivar.
On Thu, Aug 7, 2014 at 1:28 AM, Pedro Marques
On Wed 06 Aug 2014 02:10:23 PM PDT, Michael Still wrote:
- we rate limit the total number of blueprints under code review at
any one time to a fixed number of slots. I secretly prefer the term
runway, so I am going to use that for the rest of this email. A
suggested initial number of runways
On Wed, Aug 6, 2014 at 4:46 PM, Kevin Benton blak...@gmail.com wrote:
That's the point. By using security groups, you are forcing a certain kind
of enforcement that must be honored and might not be necessary if the
original intent was just to isolate between groups. In the example you
gave,
I couldn't edit the wiki. Want to add 2 items
1. Separating deployment and operational status.
2. Can driver interface be called for every API request?
Ex. It is not called for create pool.
Sent using
CloudMagichttps://cloudmagic.com/k/d/mailapp?ct=pacv=5.0.32pv=4.2.2
On Thu, Aug 07,
On 08/06/2014 04:57 PM, Aaron Rosen wrote:
Gah, clearly hitting some kind of gmail bug as i replied to the right
thread all 3 times i believe.
gmail is the new Outlook
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
On 08/06/2014 04:54 PM, Kevin Benton wrote:
I'm curious, how would having Nova reviewers look at this have helped?
In general, we should try to involve users in all spec reviews. With
Nova being a (heavy) user of Neutron, I think, in general, having Nova
people involved would help. In general.
You should be able to, if logged into launchpad. I edited it for you.
Doug
On 8/6/14, 6:07 PM, Vijay Venkatachalam vijay.venkatacha...@citrix.com
wrote:
I couldn't edit the wiki. Want to add 2 items
1. Separating deployment and operational status.
2. Can driver interface be called for every
I prefer merged because moving it to a separate project blocks it from
enforcing policy on the current API (including calls between service
plugins).
On Wed, Aug 6, 2014 at 4:56 PM, Armando M. arma...@gmail.com wrote:
On 6 August 2014 15:47, Kevin Benton blak...@gmail.com wrote:
I think we
Hi,
I agree that Option 1 would be best way to make the GBP API available to
operators and to make forward progress with the API.
Regards,
-hemanth
On Wed, Aug 6, 2014 at 5:04 PM, Ivar Lazzaro ivarlazz...@gmail.com wrote:
Hi Pedro,
I agree that having as much users/operators as possible
Web tier can communicate with anything except for the DB.
App tier can only communicate with Web and DB.
DB can communicate with App.
These high-level constraints can then be implemented as security groups
like you showed, or network hardware ACLs like I had shown.
But if you start with the
On 08/06/2014 07:54 PM, Kevin Benton wrote:
I'm curious, how would having Nova reviewers look at this have helped?
As I mentioned on a previous email, Nova is the pre-eminent consumer of
Neutron's API.
Best,
-jay
On Wed, Aug 6, 2014 at 5:41 PM, Jay Pipes jaypi...@gmail.com
On Thu, Aug 7, 2014 at 10:05 AM, Stefano Maffulli stef...@openstack.org wrote:
On Wed 06 Aug 2014 02:10:23 PM PDT, Michael Still wrote:
- we rate limit the total number of blueprints under code review at
any one time to a fixed number of slots. I secretly prefer the term
runway, so I am going
I agreed with Jay. Nova is one of the consumer of Neutron project, someone
from Nova project should participate reviewing related blueprint in neutron
project.
Richard
On Wed, Aug 6, 2014 at 8:28 PM, Jay Pipes jaypi...@gmail.com wrote:
On 08/06/2014 07:54 PM, Kevin Benton wrote:
I'm
I definitely agree that such cross-pollination across projects is ideal.
However, I think (and not to deviate from the general discussion on
making blueprint specs review more effective), Kevin's question was
specifically in the context of the GBP blueprint. It is not clear in
that case that a
Hi,
Thanks to Armando for steering the discussion back to the original
intent.
On Wed, Aug 6, 2014 at 3:56 PM, Armando M. arma...@gmail.com wrote:
On 6 August 2014 15:47, Kevin Benton blak...@gmail.com wrote:
I think we should merge it and just prefix the API for now with
From a user’s aspect i do think Rally is more suitable for a product-ready
cloud, and seems like it is where it focused on. It’s very easy to evaluate
that if the performance of the cloud is better after we adjust some configs or
some other tuning. It also provides SLA which maybe not
so
I think this could be another reason why people associated GBP and
nova-network parity in this thread: the fact that new abstractions are
introduced without solidifying the foundations of the project is a risk to
GBP as well as Neutron itself.
How does a separate project fix this? It seems to me
On Wed, Aug 6, 2014 at 5:27 PM, Kevin Benton blak...@gmail.com wrote:
Web tier can communicate with anything except for the DB.
App tier can only communicate with Web and DB.
DB can communicate with App.
These high-level constraints can then be implemented as security groups
like you
Thanks Salvatore.
I originally started with all tests and then started to back off to come up
with a set of tests which gave good stable results. Otherwise I was getting
65% - 80% pass rates. And, when a test fails, I will go back and triage it
only to realize that running that test did not
Woo~
Really nice work!
On Thu, Aug 7, 2014 at 7:09 AM, Sukhdev Kapur sukhdevka...@gmail.com
wrote:
Folks,
Just wanted to share with you that Arista CI has been up and running 24x7
since the beginning of this year with no down time.
This morning it posted a vote on 10,000th Neutron
+1.
And the review process should be more efficient!
On Thu, Aug 7, 2014 at 3:07 AM, Stefano Maffulli stef...@openstack.org
wrote:
On 08/06/2014 11:19 AM, Edgar Magana wrote:
That is the beauty of the open source projects, there is always a
smartest
reviewer catching out the facts that
On Wed, Aug 6, 2014 at 6:40 PM, Aaron Rosen aaronoro...@gmail.com wrote:
On Wed, Aug 6, 2014 at 5:27 PM, Kevin Benton blak...@gmail.com wrote:
Web tier can communicate with anything except for the DB.
App tier can only communicate with Web and DB.
DB can communicate with App.
These
Nice work Sukhdev, worth commending! Thanks for sharing!!
On Wed, Aug 6, 2014 at 7:06 PM, Baohua Yang yangbao...@gmail.com wrote:
Woo~
Really nice work!
On Thu, Aug 7, 2014 at 7:09 AM, Sukhdev Kapur sukhdevka...@gmail.com
wrote:
Folks,
Just wanted to share with you that Arista CI has
Nice work.
Suggest add some watch points/problem solution/diagnosis in the
installations.
Btw, recently we find both the RDO and devstack are very unstable for
installation, wish there will be more test and improvements soon.
On Wed, Aug 6, 2014 at 3:27 AM, chayma ghribi chaym...@gmail.com
I don't think people are choosing because of the shortest route but rather
these may be two different items that are not completely exclusive but
different enough.
Nova parity addresses the scope to have existing well understood and stable
api currently supported in nova to be supported in neutron
Do you not see a difference between explicitly configuring networks, a
router and FWaaS rules with logging and just stating that two groups of
servers can only communicate via one TCP port with all connections logged?
The first is very prone to errors for someone deploying an application
without a
When is the plan to move the meeting to IRC?
On Wed, 2014-08-06 at 15:30 -0700, Stephen Balukoff wrote:
Action items from today's Octavia meeting:
1. We're going to hold off for a couple days on merging the
constitution and preliminary road map to give people (and in
particular Ebay) a
Its good to see such a lively debate about this topic. With the disclaimer
of someone who has worked on this project, I have a strong preference
towards Option 1 as well (ie. merging it in the tree). We’ve actually
already heard from users on this thread who want to use this([1] and [2]),
others
On Thu, 7 Aug 2014 11:58:43 +1200
Robert Collins robe...@robertcollins.net wrote:
On 6 August 2014 22:23, Christopher Yeoh cbky...@gmail.com wrote:
On Wed, Aug 6, 2014 at 5:41 PM, Aaron Rosen aaronoro...@gmail.com
wrote:
On Wed, Aug 6, 2014 at 12:59 AM, Gary Kotton
+1
I believe Pedro has a very valid point here, and that is the the community to
approve the spec and that decision should be respected. It makes sense to
again clearly denote the process and governance and have this noted on the
thread Stefano started earlier today.
/Alan
-Original
Apologies for the late notice...
The Neutron L3 Subteam will meet tomorrow at the regular time in
#openstack-meeting-3. The agenda [1] is posted, please update as needed.
Carl
[1] https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam#Agenda
___
Hi,
I've submitted Ironic Cisco driver blueprint post proposal freeze date.
This driver is critical for Cisco and few customers to test as part of
their private cloud expansion. The driver implementation is ready along
with unit-tests. Will submit the code for review once blueprint is
accepted.
Agenda items are numbered, and topics, as discussed, are described beneath in
list format.
1) Octavia Constitution and Project Direction Documents (Road map)
a) Constitution and Road map will potentially be adopted after another
couple days; providing those who were busy more time to review
On 08/06/2014 06:10 PM, Michael Still wrote:
We also talked about tweaking the ratio of tech debt runways vs
'feature runways. So, perhaps every second release is focussed on
burning down tech debt and stability, whilst the others are focussed
on adding features. I would suggest if we do
I agree with Duncan and John here, I am not as old contributor in OpneStack
as most of the people commenting here are, but I see we have done this
right throughout the OpenStack lifecycle, at the start we only had Nova and
we could have always said hey lets have everything in Nova but we went
101 - 197 of 197 matches
Mail list logo
