On Tue, Jun 21, 2016 at 12:47 AM, Armando M. wrote:
> It seems it may potentially limit the ability to describe ownership.
> Virtually all Neutron models have it. Not sure I see the value in its
> absence.
I'm just saying that I don't see value in its presence. The value
that I see in its absenc
On Tue, Jun 28, 2016 at 9:42 AM, Andreas Scheuring
wrote:
> I'm currently working on solving Nova-Neutron issues during Live
> Migration. This mail is intended to raise awareness cross project and
> get things kicked off.
Thanks for sending this.
> The issues
> ==
>
> #1 When portbinding
On Mon, Jun 20, 2016 at 8:42 AM, Neil Jerram wrote:
> Calling everyone interested in networking-calico ...! networking-calico has
> been around in the Neutron stadium for a while now, and it's way past time
> that we had a proper forum for discussing and evolving it - so I'm happy to
> be finally
Sorry I missed it. I will plan to listen in on the 12th. It will be
nice to have the ICS available by then. You should probably check
with the @openstack-infra channel to see what the issue is.
Carl
On Fri, Jul 1, 2016 at 5:31 AM, Neil Jerram wrote:
> The first networking-calico IRC meeting w
On Fri, Jul 1, 2016 at 8:34 AM, Murray, Paul (HP Cloud) wrote:
>> -Original Message-
>> From: Carl Baldwin [mailto:c...@ecbaldwin.net]
>> Sent: 29 June 2016 22:20
>> To: OpenStack Development Mailing List (not for usage questions)
>>
>> Subject: Re:
On Fri, Mar 11, 2016 at 10:04 PM, Salvatore Orlando
wrote:
> On 11 March 2016 at 23:15, Carl Baldwin wrote:
> I wonder if we could satisfy this requirement with tags - as it seems these
> subnets are anyway operator-owned you should probably not worry about
> regular tenants fiddli
On Mon, Mar 21, 2016 at 12:52 PM, John Belamaric
wrote:
> Sorry for the slow reply.
And, sorry for mine. I was distracted with dotting I's and crossing
T's on some other things. I'm now back to playing around with this.
> I think that both of these can be solved with the existing interface, by
On Mon, Mar 28, 2016 at 7:25 PM, Wang, Yalei wrote:
> Someone is working on full distributed SNAT, like this:
>
> https://www.openstack.org/summit/tokyo-2015/videos/presentation/network-node-is-not-needed-anymore-completed-distributed-virtual-router
>
> From: Zhi Chang [mailto:chang...@unitedstack
uch and making it complicated?
What are some alternatives?
Are there other compelling use cases that I haven't considered yet?
Carl
[1] https://review.openstack.org/#/c/288774
On Fri, Mar 11, 2016 at 4:15 PM, Carl Baldwin wrote:
> Hi,
>
> I have started to get into coding [1] fo
On Tue, Mar 29, 2016 at 12:12 PM, Carl Baldwin wrote:
> I've been playing with this a bit on this patch set [1]. I haven't
> gotten very far yet but it has me thinking.
>
> Calico has a similar use case in mind as I do. Essentially, we both
> want to group subnets to
On Tue, Mar 29, 2016 at 1:38 PM, Miguel Lavalle wrote:
> I am writing a patchset to build a mapping between hosts and network
> segments. The goal of this mapping is to be able to say whether a host has
> access to a given network segment. I am building this mapping assuming that
> if a host A has
On Wed, Mar 30, 2016 at 9:03 AM, Pavel Bondar wrote:
> Kevin Benton commented on review page for current migration to pluggable
> approach [1]:
>
> IMO this cannot be optional. It's going to be a nightmare to try to support
> two IPAM systems that people may have switched between at various points
On Fri, Apr 1, 2016 at 2:24 AM, Ihar Hrachyshka wrote:
> We could play words, like Quantron or Neutrum. Actually, it makes perfect
> sense to me, since the change to rename all project name references will be
> half the size of the proposed solution, and may even save us some git
> conflicts, assu
Welcome, Assaf!
On Thu, Mar 31, 2016 at 6:48 PM, Armando M. wrote:
> Hi folks,
>
> Assaf's tenacity is a great asset for the Neutron team at large. I believe
> that the drivers team would benefit from that tenacity, and therefore I
> would like to announce him to be a new member of the Neutron Dr
On Mon, Apr 4, 2016 at 3:22 PM, Doug Wiegley
wrote:
> I don’t know, -1 really means, “there is something wrong, the submitter
> should fix it and clear the slate.” Whereas -2 has two meanings. The first
> is “procedural block”, and the second is “f*** you.”
>
> I really don’t see a reason not to
I think the only thing standing in our way is this bug [1]. Ryan
Tidwell and I are working on this.
Carl
[1] https://bugs.launchpad.net/neutron/+bug/1543094
On Mon, Apr 4, 2016 at 3:48 PM, John Belamaric wrote:
> I was on vacation last week so I am just seeing this now. I agree that now
> tha
+1 (whether my vote counts or note for this area)
On Thu, Apr 7, 2016 at 10:34 PM, Akihiro Motoki wrote:
> Hi Neutrinos,
>
> As the API Lieutenant of Neutron team,
> I would like to propose Hirofumi Ichihara (irc: hichihara) as a member of
> Neutron core reviewer team mainly focuing on the API/DB
xist. Add the URL
I am looking forward to a well organized and productive discussion at
the summit and I'm eager to see you all there.
Carl Baldwin
[1] https://www.openstack.org/summit/austin-2016/summit-schedule/events/9103
[2]
http://docs.openstack.org/developer/neutron/policies/bugs.htm
+1
On Apr 25, 2016 10:57 AM, "Kyle Mestery" wrote:
> Ihar, Henry and I were talking and we thought Thursday night makes sense
> for a Neutron social in Austin. If others agree, reply on this thread and
> we'll find a place.
>
> Thanks!
> Kyle
>
> __
Neutron Mitaka release [5] with this fix [6] is in the works.
- Consume service plugins queues in RPC workers was merged [8].
If there is something that I missed, please let me know.
Carl Baldwin
[1] https://www.openstack.org/summit/austin-2016/summit-schedule/events/9103
[2] https://bugs.launch
On Sun, May 1, 2016 at 7:01 PM, Matt Riedemann
wrote:
> On Wednesday morning the Nova and Neutron teams got together for a design
> summit session. The full etherpad is here [1].
>
> We talked through three major items.
>
> 1. Neutron routed networks.
>
> Carl Baldwin
something to the docs
generation to clean up stale pages?
Carl Baldwin
[1]
http://docs.openstack.org/developer/neutron/devref/sub_project_guidelines.html
[2]
http://docs.openstack.org/developer/neutron/stadium/sub_project_guidelines.html
Thank you.
Carl
On Wed, May 11, 2016 at 11:44 AM, Andreas Jaeger wrote:
> On 05/11/2016 07:15 PM, Carl Baldwin wrote:
>> Greetings all,
>>
>> This document [1] was superseded by this one [2] a while ago. It
>> looks like the source for [1] no longer exists but th
t thinking about?
Carl Baldwin
[1] https://review.openstack.org/#/c/296603/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
nt: Friday, December 11, 2015 3:12 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron][DVR]
>
>
>
>
>
>
>
> On 3 December 2015 at 10:46, Carl Baldwin wrote:
>
> I was going to bring this up in the meeting thi
On Mon, Dec 14, 2015 at 12:41 PM, Rossella Sblendido
wrote:
> On 11/25/2015 11:05 PM, Assaf Muller wrote:
>> We could then consider running the script automatically on a daily
>> basis and publishing the
>> resulting URL in a nice bookmarkable place.
>
> An update on this. The easiest bookmarkable
On Wed, Dec 16, 2015 at 10:04 AM, Mike Bayer wrote:
>> Instead of just breaking the world, and burning 10s to 100 engineer
>> hours in redo tests and investigating and addressing the break after the
>> fact.
We shouldn't let this happen in the first place. I think this is our fault.
We need to
On Wed, Dec 16, 2015 at 11:32 AM, Jeremy Stanley wrote:
[...]
> Yes, it's progressing nicely. DevStack-based jobs are already
> covered this way for master and stable/liberty, and Neutron is
> piloting the same solution for its other non-DevStack-based jobs. If
Is someone from Neutron actively he
On Thu, Dec 17, 2015 at 5:12 AM, Ihar Hrachyshka wrote:
> I believe that we should always unconditionally update filters with new
> versions when doing upgrades. Filters should not actually be considered
> configuration files in the first place since they are tightly coupled with
> the code that t
On Thu, Dec 17, 2015 at 5:29 AM, Ihar Hrachyshka wrote:
> I will update on Neutron side of things since it seems I have some knowledge
> from the fields.
>
> So first, on resources: we have Sachi and lifeless from infra side + Ihar
> and pc_m looking into expanding constrained jobs in Neutron worl
On Thu, Dec 17, 2015 at 1:30 PM, Vladimir Eremin wrote:
> Hi
>
> For now, when end user is creating IPv6-enabled tenant network and attaching
> it to the virtual router, there is only way to set up external infrastructure
> to put traffic back to the router is using DHCPv6 PD[1], unfortunately,
On Thu, Dec 17, 2015 at 4:09 PM, Vladimir Eremin wrote:
> Hi Carl,
>
> I’ll fil RFE for sure, thank you for the link to the process )
>
> So actually, we should announce all SUBNETS we’ve attached to router.
> Otherwise is will not work, because external network router will have no
> idea, where
On Fri, Dec 18, 2015 at 12:54 PM, Vladimir Eremin wrote:
> Hi Carl,
>
> As far as I understand Address Scopes, end user’s algorithm will be next:
> 1. Administrator creates an address scope and associate an IPv6 subnet pool
> with it.
> 2. Administrator creates Public shared network’s subnet from
I noticed a couple of things today while reviewing a largish page [1].
First, when I search for something using the browser's builtin search
(Chrome, Mac OSX Yosemite), it doesn't seem to find occurrences that
are not in the visible portion of the page. For example, when I
search for DNSDOMAIN, I
I also really miss being able to pull up the list of files in diff
view with the 'f' key. Any equivalent?
Carl
On Mon, Dec 21, 2015 at 4:07 PM, Carl Baldwin wrote:
> I noticed a couple of things today while reviewing a largish page [1].
> First, when I search for something usi
On Mon, Dec 21, 2015 at 6:21 PM, Zaro wrote:
> Hit '?' and it says '/' is find, give that a try.
'/' isn't really much better. It seems to highlight all of the
occurrences but I can't find a way to navigate to the next/previous
occurence with the keyboard. I see that the scroll bar shows a smal
ng toward filling out bug reports against gerrit. What should
we do? Should we individually go file bugs against gerrit? Or,
should we funnel it through someone working on gerrit in openstack?
[1] https://review.openstack.org/#/c/192032/37
[2] https://review.openstack.org/#/c/212669/4
On Mon, Dec
On Wed, Dec 23, 2015 at 1:16 AM, Michał Dulko wrote:
> n goes to next occurrence and N (shift+n) to a previous one. These are
> same keybindings as in Vim. Actually a lot of Vim-like movements are
> functional in new Gerrit and I really like that fact.
Thanks. Looking again, I see that the help
On Wed, Dec 23, 2015 at 1:57 PM, Elizabeth K. Joseph
wrote:
> On Wed, Dec 23, 2015 at 10:11 AM, Carl Baldwin wrote:
>> I do see that a lot of vim movement does work. I was hoping that
>> holding down a movement command like 'j' would rapidly move down but
>> it
On Wed, Dec 23, 2015 at 3:40 PM, Zaro wrote:
> On Tue, Dec 22, 2015 at 4:51 PM, Carl Baldwin wrote:
>> I noticed another thing. I'm working with a chain of three patches.
>> I just updated the patch in the middle [1] to patch set 37. I noticed
>> that the list of
On Wed, Dec 23, 2015 at 1:16 AM, Michał Dulko wrote:
> n goes to next occurrence and N (shift+n) to a previous one. These are
> same keybindings as in Vim. Actually a lot of Vim-like movements are
> functional in new Gerrit and I really like that fact.
I'll admit that I started to get excited abo
On Wed, Dec 23, 2015 at 5:54 PM, Clark Boylan wrote:
> I got curious and this is an odd situation. I can't find where 212669
> has a patchset with a parent of the commit for 192032,37 (b7151e4). Git
> represents the tree as a DAG with each child commit pointing at its
> parent(s). Parents do not k
I attended the Nova scheduler meeting yesterday morning in hopes to
set the stage for a discussion about Neutron's routed networks work
and how that affects Nova [1]. John suggested that I write up a
backlog spec to start the discussion (as he has suggested to me
before). I did so today and poste
What do we do? My calendar was set up with the sane bi-weekly thing
and it shows the meeting for tomorrow. The last word from our
fearless leader is that we'll have it today. So, I'll be there today
unless instructed otherwise.
The ics file now seems to reset the cadence beginning today at 2100
Hi,
I was looking at the most recent gate breakage in Neutron [1], fixed
by [2]. This gate breakage was held off for some time by the
upper-constraints.txt file. This is great progress and I applaud it.
I'll continue to cheer on this effort.
Now to the next problem. If my assessment of this
On Jan 14, 2016 3:43 PM, "Anita Kuno" wrote:
>
> On 01/14/2016 12:38 PM, Murray, Paul (HP Cloud) wrote:
> > I have created a list of attendees for the Nova midcycle here:
https://wiki.openstack.org/wiki/Sprints/NovaMitakaSprintAttendees
> >
> > Obviously I can't put anyone's name on it for privacy
spec and record any thoughts or conclusions that
I might have missed or mis-understood.
Thanks,
Carl Baldwin
[1] https://review.openstack.org/#/c/263898/
__
OpenStack Development Mailing List (not for usage questions
I almost missed this because [Neutron] was missing from the subject.
I'm replying now to add it in case someone else missed it.
On Sat, Jan 30, 2016 at 2:27 PM, Armando M. wrote:
> Hi neutrinos,
>
> According to [1], this is a kind reminder for next week's meeting: please do
> not get caught by t
On Tue, Feb 2, 2016 at 4:07 AM, John Garbutt wrote:
> Scheduler:
> Discussed jay's blueprints. For mitaka we agreed to focus on:
> http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/resource-classes.html,
> http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/re
On Thu, Feb 4, 2016 at 7:23 AM, Pavel Bondar wrote:
> I am trying to bring more attention to [1] to make final decision on
> approach to use.
> There are a few point that are not 100% clear for me at this point.
>
> 1) Do we plan to switch all current clouds to pluggable ipam
> implementation in M
On Tue, Feb 9, 2016 at 1:21 PM, Kevin Benton wrote:
> If you see any issues, either propose a patch directly or file a bug against
> https://bugs.launchpad.net/openstack-manuals/+filebug with the tag
> 'seg-guide'
Did you want 'sec-guide'? That would seem more intuitive to me.
Carl
___
On Mon, Feb 8, 2016 at 9:40 AM, Assaf Muller wrote:
> As for DVR, I'm searching for someone to pick up the gauntlet and
> contribute some L3 fullstack tests. I'd be more than happy to review
> it! I even have an abandoned patch that gets the ball rolling (The
> idea is to test L3 east/west, north/
Jim,
I've had this reply queued up for a week now. Sorry for the delay.
The problem that I run in to when I work with multiple dependent
changes doesn't seem to be covered by your description.
For me, the trouble with this workflow comes when there is more than
one contributor working on a chain
On Thu, Feb 4, 2016 at 8:12 PM, Armando M. wrote:
> as for c) I think it's a little late to make pluggable ipam default in
> Mitaka; I'd rather switch defaults early in the cycle (depending on the
> entity of the config) and this one seems serious enough that I'd rather have
> enough exercising in
On Thu, Feb 4, 2016 at 8:12 PM, Armando M. wrote:
> Technically we can make this as sophisticated and seamless as we want, but
> this is a one-off, once it's done the pain goes away, and we won't be doing
> another migration like this ever again. So I wouldn't over engineer it.
Frankly, I was wor
On Thu, Feb 11, 2016 at 3:20 AM, Salvatore Orlando
wrote:
> The difference lies in the process in my opinion.
> If the switch is added into the migration path then we will tell operators
> when to switch.
> I was suggesting doing it manual because we just don't know if every
> operator is happy ab
On Thu, Feb 11, 2016 at 3:32 AM, Ihar Hrachyshka wrote:
> Salvatore Orlando wrote:
>
>> The difference lies in the process in my opinion.
>> If the switch is added into the migration path then we will tell operators
>> when to switch.
>> I was suggesting doing it manual because we just don't know
On Thu, Feb 11, 2016 at 10:04 AM, Armando M. wrote:
> On 11 February 2016 at 07:01, John Belamaric
> wrote:
>> It is only internal implementation changes.
>
> That's not entirely true, is it? There are config variables to change and it
> opens up the possibility of a scenario that the operator ma
these areas of focus, please vote
+1/-1 for the addition of Cedric to the team.
Thanks!
Carl Baldwin
[1] https://review.openstack.org/#/q/reviewer:zzelle%2540gmail.com,n,z
[2] http://stackalytics.com/report/contribution/neutron-gro
nant subnet behind a Neutron router in the
same address scope as the external network. I'm not convinced that
IPAM and routing really belong together like this.
If you made it this far in this email, you must have some feedback.
Please help us out.
Carl Baldwin
[1] https://bugs.launchp
n based blocks which could host floating ips from the other blocks.
> On 20 July 2015 at 10:33, Carl Baldwin wrote:
>>
>> When creating a
>> port, the binding information would be sent to the IPAM system and the
>> system would choose an appropriate address block for th
On Tue, Jul 21, 2015 at 1:11 PM, John Belamaric wrote:
> Wow, a lot to digest in these threads. If I can summarize my understanding
> of the two proposals. Let me know whether I get this right. There are a
> couple problems that need to be solved:
>
> a. Scheduling based on host reachability to t
It has been a week since this nomination. I'm pleased to confirm
Cedric as a core reviewer for these areas of focus. We look forward
to your continued contribution to the project!
Carl
On Wed, Jul 15, 2015 at 12:47 PM, Carl Baldwin wrote:
> As the Neutron L3 Lieutenant along with Kevi
On Wed, Jul 22, 2015 at 3:00 PM, Kevin Benton wrote:
>>It seems to me that the existence of the multiprovider extension is an
>> important point for this discussion. Multiprovider, as I understand it,
>> allows describing a network composed of multiple L2 segments with implicit
>> east-west routi
On Thu, Jul 23, 2015 at 8:51 AM, Kevin Benton wrote:
>>Or, migration scheduling would need to respect the constraint that a
> port may be confined to a set of hosts. How can be assign a port to a
> different network? The VM would wake up and what? How would it know
> to reconfigure its network
On Wed, Jul 22, 2015 at 3:21 PM, Kevin Benton wrote:
> The issue with the availability zone solution is that we now force
> availability zones in Nova to be constrained to network configuration. In
> the L3 ToR/no overlay configuration, this means every rack is its own
> availability zone. This is
On Wed, Jul 22, 2015 at 3:00 PM, Kevin Benton wrote:
> I proposed the port scheduling RFE to deal with the part about selecting a
> network that is appropriate for the port based on provided hints and
> host_id. [1]
Thanks for the pointer. I hadn't paid much attention to this RFE yet.
>>the neu
On Tue, Jul 21, 2015 at 8:41 AM, Salvatore Orlando
wrote:
> It is however important to ensure services like DHCP keep working as usual.
> Treating segments as logical networks in their own right is the simples
> solution to achieve this imho.
Agreed.
> While the logical model and workflow you de
On Thu, Jul 23, 2015 at 1:45 PM, Kevin Benton wrote:
>>We ran in to this long ago.
>
> What are some other examples? We've be good about keeping the network L2
> only. Segments, VLAN transparency, and other properties of the network are
> all L2.
Another thing is that we create floating IPs from
On Jul 23, 2015 6:04 PM, "Kevin Benton" wrote:
>
> > IOW, I don't think what I
> proposed in adding L3 stuff to the network that wasn't already here.
>
> The point I'm trying to make is that there isn't any L3 stuff on the
network itself. There are L3 things that depend on the network because an
L
On Jul 23, 2015 8:39 PM, "Paul Carver" wrote:
> I think Kevin is right here. Network is fundamentally a layer 2
construct, it represents direct reachability. A network could in principle
support non-IP traffic (though in practice that may or may not work
depending on underlying implementation.) Su
Kevin, sorry for the delay in response. Keeping up on this thread was
getting difficult while on vacation.
tl;dr: I think it is worth it to talk through the idea of inserting
some sort of a "subnet group thing" in the model to which floating ips
(and router external gateways) will associate. It
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
On Mon, Aug 3, 2015 at 9:07 PM, Mike Dorman wrote:
> I hope we can move this idea moving forward. I was disappointed to see
> the spec abandoned.
While I think the ship has sailed for Liberty, this is going to be my
top priority for for Mitaka. Abandoning the spec may have sent the
wrong messag
Kevin,
This is just a final top-post to say that I'm going to spend the next
week noodling over this discussion in more detail and trying to flesh
it out into a proposal. I think we're pretty much in agreement about
where the problems are in the model. It feels like we'll just be
beating a dead
Hi,
It has been a long catch-up day for me. I have looked through the
patches. I have some feedback for them but I don't see why we can't
shoot for Liberty-3.
Carl
On Sun, Aug 23, 2015 at 7:11 PM, Kyle Mestery wrote:
> Thanks Neil, we'll review this during the drivers meeting this week. It's
I was under the impression that we had a plan to stop allowing these
external updates break our gate jobs. It seems extremely unwise to
allow these forces outside of our control to disrupt us so much
especially in such a large project as Neutron. We lose a lot of
valuable time to these. I though
Hi,
I did take the opportunity to read through your etherpad today. Many
of the solutions that you propose have been discussed in the past but
there just hasn't been a traction on the problem. You did a fine job
of writing this up and I think we should use your etherpad as a
central point for di
On Mon, Aug 31, 2015 at 10:50 AM, Armando M. wrote:
> You missed 'weekends' :)
I did miss weekends! While I went about my life last night blissfully
unaware of the problems that were brewing, you were on top of things
and came to our rescue. I thank you for your efforts and time, truly.
> Not
On Mon, Aug 31, 2015 at 11:02 AM, Armando M. wrote:
>
>
> On 31 August 2015 at 09:53, Jeremy Stanley wrote:
>>
>> On 2015-08-31 10:33:07 -0600 (-0600), Carl Baldwin wrote:
>> > I was under the impression that we had a plan to stop allowing these
>> &g
Thanks, I learned a thing or two from the document that you linked.
Thanks for reminding us of that.
Carl
On Tue, Sep 1, 2015 at 3:14 AM, Ihar Hrachyshka wrote:
> Hi reviewers,
>
> several days ago, a semantically expand-only migration script was merged into
> contract branch [1]. This is not a
This sounds like a good candidate for a "git bisect" operation [1]
since we already have a pretty tight window where things changed.
Carl
[1] http://git-scm.com/docs/git-bisect
On Thu, Sep 3, 2015 at 7:07 AM, Assaf Muller wrote:
>
>
> On Thu, Sep 3, 2015 at 8:43 AM, Andrey Pavlov wrote:
>>
>>
On Tue, Sep 1, 2015 at 11:59 PM, Gal Sagie wrote:
> Hello All,
>
> I have searched and found many past efforts to implement port forwarding in
> Neutron.
I have heard a few express a desire for this use case a few times in
the past without gaining much traction. Your summary here seems to
show t
e bugs out, and making the enhancements
needed to make this feature what it should be.
Carl
[1] https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam
On Mon, Sep 14, 2015 at 4:01 PM, Sean M. Collins wrote:
> Hi,
>
> Carl Baldwin, Doug Wiegley, Matt Kassawara, Ryan Moats, and mys
On Tue, Sep 15, 2015 at 3:09 PM, Fox, Kevin M wrote:
> DNS is preferable, since humans don't remember ip's very well. IPv6 is much
> harder to remember then v4 too.
>
> DNS has its own issues, mostly, its usually not very quick to get a DNS entry
> updated. At our site (and I'm sure, others), I
On Thu, Sep 17, 2015 at 10:26 AM, Kevin Benton wrote:
> Yes, the L2 semantics apply to the external network as well (at least with
> ML2).
This is true and should remain so. I think we've come to the
agreement that a neutron Network, external, shared, or not, should be
an L2 broadcast domain and
On Thu, Sep 17, 2015 at 12:35 PM, Kevin Benton wrote:
>>Also I believe that (c) is already true for Neutron external networks -
>> i.e. it doesn't make sense to assign a floating IP to an instance that is
>> directly on an external network. Is that correct?
>
> Well not floating IPs from the same
On Fri, Sep 18, 2015 at 4:55 AM, Clark, Robert Graham
wrote:
> Is it possible to have separate floating-IP pools and grant a tenant access
> to only some of them?
It is possible to have multiple floating IP pools by creating multiple
external networks. However, it is not currently possible to ha
On Tue, Sep 15, 2015 at 8:40 PM, shihanzhang wrote:
> [1] https://bugs.launchpad.net/neutron/+bug/1486795
> [2] https://bugs.launchpad.net/neutron/+bug/1486828
> [3] https://bugs.launchpad.net/neutron/+bug/1496201
> [4] https://bugs.launchpad.net/neutron/+bug/1496204
> [5] https://bugs.launchpad.n
On Mon, Sep 21, 2015 at 2:47 PM, Sisir Chowdhury wrote:
> Hi All -
>
> I have some proposal regarding ovn-networking project within Open-Stack.
>
> #1. Making Neutron-DVR feature intelligent enough so that we can
> completely remove Network Node(NN).
>
> Right now even with DVR, the
Interesting, I'll have a look. We should get this on the neutron drivers'
agenda. The drivers team has been dormant for a couple of weeks but I'm
sure it will pick up again very soon.
Carl
On Sep 20, 2015 12:28 AM, "Gal Sagie" wrote:
> Hello All,
>
> I have sent a spec [1] to resume the work o
On Sep 21, 2015 9:21 AM, "Venkata Anil" wrote:
>
> Hi All
>
> I need your opinion on selecting router for floatingip when subnet is
connected to multiple routers.
>
> When multiple routers connected to a subnet, vm on that subnet will only
send packets destined for external network to the router w
On Tue, Sep 22, 2015 at 10:42 AM, Russell Bryant wrote:
> The Neutron L3 agent is only used with networking-ovn temporarily while
> we work through the L3 design and implementation in OVN itself. OVN
> will not use the L3 agent (or DVR) quite soon. Some initial L3 design
> notes are being discus
(Cross-posting to the operators list for feedback)
Thank you Ihar for starting this up. In the absence of any kind of
blog or other outlet of my own to disseminate this, let me share my
plans here...
Routed Networks:
My plans for Mitaka (and beyond) are around routed networks. During
Liberty,
+1 Great idea!
On Fri, Oct 9, 2015 at 3:42 AM, Thierry Carrez wrote:
> Hello everyone,
>
> OpenStack has become quite big, and it's easier than ever to feel lost,
> to feel like nothing is really happening. It's more difficult than ever
> to feel part of a single community, and to celebrate littl
Great work Calico!
Count me in when you have project meetings, I'd like to keep up.
Carl
On Oct 16, 2015 6:21 AM, "Neil Jerram" wrote:
> I'm happy to announce the first release of networking-calico. As it
> says at http://docs.openstack.org/developer/networking-calico/:
>
> networking-calico
@Gal, your proposal sounds like packet or flow rate limiting of data
through a port. What Ryan is proposing is rate limiting of api requests to
the server. They are separate topics, each may be a valid need on its own
but should be considered separately.
@Ryan, I tend to agree that rate limiting
On May 21, 2015 9:06 AM, "Kyle Mestery" wrote:
>
> On Thu, May 21, 2015 at 8:58 AM, Salvatore Orlando
wrote:
>>
>> After putting the whole OpenStack networking contributors community
through almost 8 cycles of pedant comments and annoying "what if"
questions, it is probably time for me to relieve
On Tue, May 26, 2015 at 11:05 AM, Brian Haley wrote:
> On 05/26/2015 01:12 PM, Salvatore Orlando wrote:
>>
>> From the bug Kevin reported it seems multiple dhcp agents per network
>> have been
>> completely broken by the fix for bug #1345947, so a revert of patch [1]
>> (and
>> stable backports)
+1
On Thu, May 28, 2015 at 6:42 AM, Kyle Mestery wrote:
> Folks, I'd like to propose Assaf Muller to be a member of the Neutron core
> reviewer team. Assaf has been a long time contributor in Neutron, and he's
> also recently become my testing Lieutenant. His influence and knowledge in
> testing
201 - 300 of 400 matches
Mail list logo
