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
On Apr 15, 2015, at 10:00 , Miguel Angel Ajo Pelayo mangel...@redhat.com
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
On Apr 6, 2015, at 11:56 , Miguel Ángel Ajo
majop...@redhat.commailto: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
in Salvatore’s
suggestion for starting with how to define things in the API first.
Best regards,
Miguel Ángel
On 7/4/2015, at 15:07, Veiga, Anthony
anthony_ve...@cable.comcast.commailto:anthony_ve...@cable.comcast.com wrote:
On Apr 6, 2015, at 11:56 , Miguel Ángel Ajo
majop...@redhat.commailto:majop
On Apr 7, 2015, at 11:05 , Veiga, Anthony
anthony_ve...@cable.comcast.commailto:anthony_ve...@cable.comcast.com wrote:
On Apr 7, 2015, at 10:50 , Miguel Angel Ajo Pelayo
majop...@redhat.commailto:majop...@redhat.com wrote:
Hi Anthony, nice to hear about it! :)
Is the implementation
On Feb 6, 2015, at 8:17 , Jeremy Stanley fu...@yuggoth.org 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
On 10/3/14, 14:58 , Henry Gessau ges...@cisco.com 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
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,
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 Xuhan,
What I saw is that GARP is sent to the gateway port and also
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
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
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
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
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 decision
to not
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 and it was
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's
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)
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
-- (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,
-Original Message-
From: Kyle Mestery mest...@siliconloons.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: Tuesday, December 10, 2013 10:48
To: OpenStack Development Mailing List (not for usage questions)
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
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 sparkofwisdom.cl...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage
26 matches
Mail list logo
