On Apr 15, 2015, at 10:00 , Miguel Angel Ajo Pelayo
wrote:
>
> Ok,
>
> 1) #openstack-meeting-2 doesn’t exist (-alt is it)
>
> 2) and not only that we’re colliding the TWG meeting,
> but all the meeting rooms starting at UTC 14:30 are busy.
While not preferable, I don’t mind overlapping th
Miguel,
As a telco operator, who is active in the WG, I am absolutely an interested
party for QoS. I’d be willing to hop between the two of them if absolutely
necessary (it’s IRC, after all) but would prefer they not overlap if possible.
Thanks!
-Anthony
On Apr 15, 2015, at 6:39 , Miguel Angel
On Apr 7, 2015, at 11:05 , Veiga, Anthony
mailto:anthony_ve...@cable.comcast.com>> wrote:
On Apr 7, 2015, at 10:50 , Miguel Angel Ajo Pelayo
mailto:majop...@redhat.com>> wrote:
Hi Anthony, nice to hear about it! :)
Is the implementation available somewhere?,
Yes, it’s been post
estion for starting with how to define things in the API first.
Best regards,
Miguel Ángel
On 7/4/2015, at 15:07, Veiga, Anthony
mailto:anthony_ve...@cable.comcast.com>> wrote:
On Apr 6, 2015, at 11:56 , Miguel Ángel Ajo
mailto:majop...@redhat.com>> wrote:
I’d like to co-orga
On Apr 6, 2015, at 11:56 , Miguel Ángel Ajo
mailto:majop...@redhat.com>> wrote:
I’d like to co-organized a QoS weekly meeting with Sean M. Collins,
In the last few years, the interest for QoS support has increased, Sean has
been leading
this effort [1] and we believe we should get into a c
> On Feb 6, 2015, at 8:17 , Jeremy Stanley wrote:
>
> On 2015-02-06 12:11:40 +0100 (+0100), Marc Koderer wrote:
> [...]
>> Therefore I uploaded one of them (Session Border Controller) to
>> the Gerrit system into the sandbox repo:
>>
>>https://review.openstack.org/#/c/152940/1
> [...]
>
>
I’ll +1 this. I think this is going to be relevant to quite a few things,
including NFV and routing (if you want to establish an L2 neighbor for ISIS…).
This seems like a useful feature.
-Anthony
Maruti's talk is, in fact, so interesting that we should probably get together
and talk about thi
On 10/3/14, 14:58 , "Henry Gessau" wrote:
>There are some fixes for IPv6 bugs that unfortunately missed the RC1 cut.
>These bugs are quite important for IPv6 users and therefore I would like
>to
>lobby for getting them into a possible RC2 of Neutron Juno.
>
>These are low-risk fixes that would no
Using the quota system would be a nice option to have.
Can you clarify what you mean by cumulative bandwidth for the tenant? It would
be possible to rate limit at the tenant router, but having a cumulative limit
enforced inside of a tenant would be difficult.
On Wed, Sep 10, 2014 at 1:03 AM,
ndby to work. So far as I know, I think there’s still a bug
out on this since you can only have one gateway per subnet.
http://linux.die.net/man/8/arping
https://review.openstack.org/#/c/114437/2/neutron/agent/l3_agent.py
Thoughts?
Xu Han
On 08/27/2014 10:01 PM, Veiga, Anthony wrote:
Hi Xuh
Hi Xuhan,
What I saw is that GARP is sent to the gateway port and also to the router
ports, from a neutron router. I’m not sure why it’s sent to the router ports
(internal network). My understanding for arping to the gateway port is that it
is needed for proper NAT operation. Since we are not
+1 to this. It would be great to read the compiled spec and have it be
searchable/filtered.
-Anthony
Thank you for the update, Kyle.
I was sceptical about this move at first but hopefully I was wrong. The specs
repository indeed eases a lot of the work from a submitter and reviewer point
of v
This is a discussion that warrants a broader audience, as others are likely to
have a very similar need. It would be good to get something like this
documented, and perhaps bolted on to the operators’ guide or somewhere
similarly appropriate.
-Anthony
Hi Tim,
NTT-docomo and VTJ developed netw
I’ll take this one a step further. I think one of the methods for getting
(non-NAT) floating IPs in IPv6 would be to push a new, extra address to the
same port. Either by crafting an extra, unicast RA to the specific VM or
providing multiple IA_NA fields in the DHCPv6 transaction. This would
Hi,
The only issue I would see with the pod is that not all of us are ATCs, so we
may or may not have access to that area (I am open to correction on that point
- in fact I hope someone does ;) )
I’ll second this. I have an interest in attending and assisting here, but I
don’t have ATC stat
>
>On Wed, 2014-04-09 at 00:02 +0100, Salvatore Orlando wrote:
>> Auditing has been discussed for the firewall extension.
>> However, it is reasonable to expect some form of auditing for security
>> group rules as well.
>>
>>
>> To the best of my knowledge there has never been an explicit decisio
>On Thu, 2014-03-06 at 15:32 +, Jorge Miramontes wrote:
>> I'd like to gauge everyone's interest in a possible mini-summit for
>> Neturon LBaaS. If enough people are interested I'd be happy to try and
>> set something up. The Designate team just had a productive mini-summit
>> in Austin, TX an
This would break IPv6. The gateway address, according to RFC 4861[1] Section
4.2 regarding Router Advertisements: "Source Address MUST be the link-local
address assigned to the interface from which this message is sent". This means
that if you configure a subnet with a Globally Unique Address
Hello Stackers!
It is very nice to watch the OpenStack evolution in IPv6! Great job guys!!
Thanks!
I have another idea:
"Floating IP" for IPv6, or just "Floating IPv6"
With IPv4, as we know, OpenStack have a feature called "Floating IP", which is
basically a 1-to-1 NAT rule (within tenant
During last week's IRC meeting, we ran into a question about validating
the configuration options for ipv6_address_mode[1] and ipv6_ra_mode[1] for
IPv6 networks. This brought up a few issues, but after mulling it over for
a while I think it breaks down into 2 distinct questions.
Question 1) Should
I vote address them (ipv6_). There's no guarantee of forward
compatibility with a new protocol and this way it can't be confused with a
(non-existant) selection method for IPv4, either. Also, future updates of
other protocols would require a new attribute and break the API less.
-Anthony
>OK -
An openstack deployment with an external DHCP server is definetely a possible
scenario; I don't think it can be implemented out-of-the-box with the
components provided by the core openstack services, but it should be doable and
a possibly even a requirement for deployments which integrate opens
-- (rebroadcast to dev community from prior unicast discussion) --
Hi Nir
Sorry if the description is misleading. Didn't want a large title, and hoped
that the description would provide those additional details to clarify the real
goal of what's included and what's not included.
#1. Yes, it's
Keep in mind that this approach is a direct departure from the IPv4 world.
Note that I'm not wholly against that, however there's something to keep in
mind.
Any kind of stack-agnostic interactions in Neutron will have to become stack
aware or have a translator to tell if they need to interact
-Original Message-
From: Kyle Mestery
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Tuesday, December 10, 2013 10:48
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: [openstack-dev] [neutron] Third party Neutron plugin testing
m
As part of the discussion around managing IPv6-addressed hosts both within
neutron itself and other systems that require address information, Sean
Collins and I had had a discussion about the types of addresses that could
be supported. Since IPv6 has many modes of provisioning, we will need to
pro
As an IPv6 engineer interesting in helping Neutron get where it could be,
I'd like to join in on this. I also like the Thursday 21:00 UTC slot.
-Anthony
-Original Message-
From: Shixiong Shang
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Tuesday, Novem
27 matches
Mail list logo
