Path MTU discovery works on a path - something with an L3 router in the way
- where the outbound interface has a smaller MTU than the inbound one.
You're transmitting across an L2 network - no L3 routers present. You send
a 1500 byte packet, the network fabric (which is not L3, has no address,
The problem is that it is not at the begining to transmit large file. It is
after some packets trasmited, then the connection is choked.
After the connection choked, from the bridge in compute host we can see the
sender send packets, and the receiver can not get the packets.
If it is the pmtud,
Hello everyone,
I want to raise concerns about progress bar, and its usability.
In my opinion current approach has several downsides:
1. No valuable information
2. Very fragile, you need to change code in several places not to break it
3. Will not work with plugable code
Log parsing works under
lan, you are right, the receiver only receive packet that small than 1450.
Because the sender does not send large packets at the begining, so
tcpdump can catch some small packets.
Another question about the mtu, what if we clear the DF in the ip packets?
Then l2 can split packets into
On 23-Oct-14 23:40, Zane Bitter wrote:
Hi folks,
I've been looking at the convergence stuff, and become a bit concerned
that we're more or less flying blind (or at least I have been) in trying
to figure out the design, and also that some of the first implementation
efforts seem to be
This all appears to be referring to trunking ports, rather than anything
else, so I've addressed the points in that respect.
On 28 October 2014 00:03, A, Keshava keshav...@hp.com wrote:
Hi,
1. How many Trunk ports can be created ?
Why would there be a limit?
Will there be any
Hi,
Current Open-stack was built as flat network.
With the introduction of the L3 lookup (by inserting the routing table in
forwarding path) and separate 'VIF Route Type' interface:
At what point of time in the packet processing decision will be made to lookup
FIB during ? For each packet
On 28 October 2014 00:18, A, Keshava keshav...@hp.com wrote:
Hi,
Currently OpenStack have any framework to notify the Tennant/Service-VM
for such kind of notification based on VM’s interest ?
It's possible to use DHCP or RA to notify a VM of the MTU but there are
limitations (RAs don't
Let's do the same for Fuel. Frankly, I'd say we could take OpenStack
standards as is and use them for Fuel. But maybe there are other opinions.
Let's discuss this and decide what to do. Do we actually need those
standards at all?
Agree that we can take openstack standarts as example, but
Hi wei,
the agent will be re-worked with modular l2 agent [1]
your proposal could be handle during this work.
[1]https://review.openstack.org/#/c/106189/
Mathieu
On Tue, Oct 28, 2014 at 4:01 AM, Damon Wang damon.dev...@gmail.com wrote:
Hi all,
We have suffered a long down time when we
Daniel Comnea comnea.d...@gmail.com wrote on 10/27/2014 07:16:32 AM:
Yes i did but if you look at this example
https://github.com/openstack/heat-templates/blob/master/hot/autoscaling.yaml
the flow is simple:
CPU alarm in Ceilometer triggers the type: OS::Heat::ScalingPolicy
which
One more question.
Vxlan use udp, how can vxlan promise reliability.
在 2014-10-28 15:51:02，Ian Wells ijw.ubu...@cack.org.uk 写道：
On 28 October 2014 00:30, Li Tianqing jaze...@163.com wrote:
lan, you are right, the receiver only receive packet that small than 1450.
Because the sender does not
Hi,
Pl find my reply .
Regards,
keshava
From: Ian Wells [mailto:ijw.ubu...@cack.org.uk]
Sent: Tuesday, October 28, 2014 1:19 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] vm can not transport large file under
neutron ml2 + linux
Hi,
Pl fine the reply for the same.
Regards,
keshava
From: Ian Wells [mailto:ijw.ubu...@cack.org.uk]
Sent: Tuesday, October 28, 2014 1:11 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints
This all
On Tue, Oct 28, 2014 at 08:32:11, Li Tianqing wrote:
One more question.
Vxlan use udp, how can vxlan promise reliability.
It can't, but that doesn't matter.
VXLAN emulates a single layer 2 broadcast domain: conceptually, a series of
machines all plugged into the same Ethernet switch. This
On Tue, Oct 28, 2014 at 03:22:36PM +1300, Robert Collins wrote:
So this should work and I think its generally good.
But - I'm curious, you only need a single image for devtest to
experiment with tuskar - the seed - which should be about the same
speed (or faster, if you have hot caches) than
Hi,
we're preparing to add a new platform, libvirt-kvm on system z
(https://blueprints.launchpad.net/nova/+spec/libvirt-kvm-systemz), to
the HypervisorSupportMatrix
https://wiki.openstack.org/wiki/HypervisorSupportMatrix .
This matrix also lists a number of networking features (e.g. vlan
Hi
Please find some additions to Ian and responses below.
/Alan
From: A, Keshava [mailto:keshav...@hp.com]
Sent: October-28-14 9:57 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints
Hi,
Pl fine the
On 28 October 2014 22:51, Steven Hardy sha...@redhat.com wrote:
On Tue, Oct 28, 2014 at 03:22:36PM +1300, Robert Collins wrote:
So this should work and I think its generally good.
But - I'm curious, you only need a single image for devtest to
experiment with tuskar - the seed - which should
Hi,
Pl find my reply ..
Regards,
keshava
From: Alan Kavanagh [mailto:alan.kavan...@ericsson.com]
Sent: Tuesday, October 28, 2014 3:35 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints
Hi
Please
Dear Sylvain,
as you suggested me few weeks ago, I created the blueprint
(https://blueprints.launchpad.net/blazar/+spec/fair-share-lease) and I'd
like to start a discussion.
I will be in Paris the next week at the OpenStack Summit, so it would be
nice to talk with you and the BLAZAR team
On Tue, Oct 28, 2014 at 11:08:05PM +1300, Robert Collins wrote:
On 28 October 2014 22:51, Steven Hardy sha...@redhat.com wrote:
On Tue, Oct 28, 2014 at 03:22:36PM +1300, Robert Collins wrote:
So this should work and I think its generally good.
But - I'm curious, you only need a single
We're dealing with some issues on devstack pass through with really
complicated config option types, the fixes are breaking other things.
The issue at hand is the fact that the pci pass through device listing
is an olso MultiStrOpt in which each option value is fully valid json
document, which
Keshava,
I think the thread is not going a bit off its stated topic - which is to
discuss the various proposed approaches to vlan trunking.
Regarding your last post, I'm not sure I saw either spec implying that at
the data plane level every instance attached to a trunk will be implemented
as a
On Tue, Oct 28, 2014 at 07:34:11AM -0400, Sean Dague wrote:
We're dealing with some issues on devstack pass through with really
complicated config option types, the fixes are breaking other things.
The issue at hand is the fact that the pci pass through device listing
is an olso MultiStrOpt
On 10/28/2014 07:44 AM, Daniel P. Berrange wrote:
On Tue, Oct 28, 2014 at 07:34:11AM -0400, Sean Dague wrote:
We're dealing with some issues on devstack pass through with really
complicated config option types, the fixes are breaking other things.
The issue at hand is the fact that the pci
At the beginning of the month we moved through a set of patches for oslo
libs that decoupled them from the integrated gate by testing server
projects with released versions of oslo libraries.
The way it works is that in the base devstack case all the oslo
libraries are pulled from pypi instead of
On Tue, Oct 28, 2014 at 08:07:14AM -0400, Sean Dague wrote:
On 10/28/2014 07:44 AM, Daniel P. Berrange wrote:
On Tue, Oct 28, 2014 at 07:34:11AM -0400, Sean Dague wrote:
We're dealing with some issues on devstack pass through with really
complicated config option types, the fixes are
Sean,
Are you talking about this one: https://review.openstack.org/#/c/128805/?
is it still breaking something after fixing the incompatible awk syntax?
Originally https://review.openstack.org/#/c/123599/ proposed a simple
patch to support that config. But it was abandoned in favor of the
On Mon, Oct 27, 2014 at 10:01 PM, Damon Wang damon.dev...@gmail.com wrote:
Hi all,
We have suffered a long down time when we upgrade our public cloud's neutron
into the latest version (close to Juno RC2), for ovs-agent cleaned all flows
in br-tun when it start.
This is likely due to this bug
On 10/28/2014 08:31 AM, Daniel P. Berrange wrote:
On Tue, Oct 28, 2014 at 08:07:14AM -0400, Sean Dague wrote:
On 10/28/2014 07:44 AM, Daniel P. Berrange wrote:
On Tue, Oct 28, 2014 at 07:34:11AM -0400, Sean Dague wrote:
We're dealing with some issues on devstack pass through with really
Hi Salvatore
Inline below.
From: Salvatore Orlando [mailto:sorla...@nicira.com]
Sent: October-28-14 12:37 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints
Keshava,
I think the thread is not going
On Tue, Oct 28, 2014 at 4:53 AM, Andreas Scheuring
scheu...@linux.vnet.ibm.com wrote:
Hi,
we're preparing to add a new platform, libvirt-kvm on system z
(https://blueprints.launchpad.net/nova/+spec/libvirt-kvm-systemz), to
the HypervisorSupportMatrix
Sean,
Please correct me if I'm wrong, but I think this needs to happen on RCs not on
CI tests.
Couple of possible problems I personally see with this approach:
1) Extensive pressure to push new client releases (perhaps the released client
is not as good as intended for just to provide someone
Hi,
really interesting, thanks corry.
during l3 meeting we spoke about planning a POD session around bgp use cases.
at least 2 spec have bgp use cases :
https://review.openstack.org/#/c/125401/
https://review.openstack.org/#/c/93329/
It would be interesting that you join this POD, to share your
If we really need that level of arbitrary complexity and future name
values we should then just:
pci_passthrough_cfg = /etc/nova/pci_pass.yaml
I hate to have to introduce a new thing like that, but I also think that
JSON-encoded config variable strings are a nightmare. They lead to bugs
like
On Oct 28, 2014, at 7:34 AM, Sean Dague s...@dague.net wrote:
We're dealing with some issues on devstack pass through with really
complicated config option types, the fixes are breaking other things.
The issue at hand is the fact that the pci pass through device listing
is an olso
Are current nova CI platforms configured with nova-networking or with
neutron networking? Or is networking in general not even a part of the
nova CI approach?
I think we have several that only run on Neutron, so I think it's fine
to just do that.
--Dan
signature.asc
Description: OpenPGP
On 10/28/2014 09:36 AM, Kuvaja, Erno wrote:
Sean,
Please correct me if I'm wrong, but I think this needs to happen on RCs not
on CI tests.
Couple of possible problems I personally see with this approach:
1) Extensive pressure to push new client releases (perhaps the released
client is
On Tue, Oct 28, 2014 at 11:08:05PM +1300, Robert Collins wrote:
On 28 October 2014 22:51, Steven Hardy sha...@redhat.com wrote:
On Tue, Oct 28, 2014 at 03:22:36PM +1300, Robert Collins wrote:
snip
3. Log onto seed VM to debug the issue. Discover there are no logs.
We should fix that - is
The API provides an endpoint for querying the serial console of an
instance ('os-getSerialConsole'). The nova-client interacts with this
API endpoint via the command `get-serial-console`.
nova get-serial-console myInstance
It returns a string like:
On 10/28/2014 07:44 AM, Daniel P. Berrange wrote:
One option would be a more CSV like syntax eg
pci_passthrough_whitelist = address=*0a:00.*,physical_network=physnet1
pci_passthrough_whitelist = vendor_id=1137,product_id=0071
But this gets confusing if we want to specifying multiple
Duncan, I don't think it's possible to have multiple volume groups using
the same physical volume[1]. In fact, counter-intuitively (at least to
me) the nesting actually goes the other way with multiple physical
volumes comprising a single volume group. The LVM naming scheme actually
makes more
Hi,
On 28/10/2014 10:39 AM, Sean Dague wrote:
On 10/28/2014 08:31 AM, Daniel P. Berrange wrote:
snip
I don't think that is really very extensible for the future to drop the
key name. We've already extended the info we record here at least once,
and I expect we'd want to add more fields
On Tue, Oct 28, 2014 at 10:18:37AM -0400, Jay Pipes wrote:
On 10/28/2014 07:44 AM, Daniel P. Berrange wrote:
One option would be a more CSV like syntax eg
pci_passthrough_whitelist = address=*0a:00.*,physical_network=physnet1
pci_passthrough_whitelist =
Due to last minute preparation for the summit I'll be cancelling the meeting
for this week. We'll resume activity post summit.
p
Peter J. Pouliot CISSP
Sr. SDET OpenStack
Microsoft
New England Research Development Center
1 Memorial Drive
Cambridge, MA 02142
P: 1.(857).4536436
E:
Hi
On 9 October 2014 23:56, James Polley j...@jamezpolley.com wrote:
Assuming it's in the US or Europe, Mon-Fri gives me about 3 useful days,
once you take out the time I lose to jet lag. That's barely worth the 48
hours or so I spent in transit last time.
It may well be
On Tue, Oct 28, 2014 at 9:27 AM, Dan Genin daniel.ge...@jhuapl.edu wrote:
So this brings us back to the original proposal of having separate
backing files for Cinder and Nova which Dean thought might take too much
space.
Between Cinder, Nova and Swift (and Ceph, etc) everybody wants some
Hi everyone,
with recent disruption in our CI process I'd like to discuss again the
issues in our merge workflow.
See the summary at the end.
As a starting point, here is the list of patches which were merged
into fuel-library repository without Verified +1 label from Fuel CI:
5. API: You can't create or modify roles via the API, or even view the
content of the role after creating it
None of that is in place yet, mostly due to time. The tuskar-load-roles
was a short-term solution to getting a base set of roles in.
Conceptually you're on target with I want to see in
Thanks for the reply Angus,
DDoS attacks are definitely a concern we are trying to address here. My
assumptions are based on a solution that is engineered for this type of
thing. Are you more concerned with network I/O during a DoS attack or
storing the logs? Under the idea I had, I wanted to
Hi Dan
You're quite right, the nesting isn't as I thought it was, sorry to mislead you.
It isn't a show stopper, it just makes testing some proposed useful
functionality slightly harder. If nova were to namespace its volumes
(e.g. start all the volume names with nova-*) then that would allow
the
On Tue, Oct 28, 2014 at 07:44:48, A, Keshava wrote:
Hi,
Current Open-stack was built as flat network.
With the introduction of the L3 lookup (by inserting the routing table
in forwarding path) and separate 'VIF Route Type' interface:
At what point of time in the packet processing
Aleksandra,
As you may know, there is a randomly failing nailgun unit test in fuel-web
repo, which fails for the major part of review requests. It's been
happening for a few days. But I need to merge some stuff and cannot wait
for the fix of this well known issue. So for every request with -1
Hi Cory,
Yes that is the basic question I have.
OpenStack cloud is ready to move away from Flat L2 network ?
1. Every packet L3 FIB Lookup : Radix Tree Search, instead of current L2
Hash/Index Lookup ?
2. Will there be Hierarchical network ? How much of the Routes will be
imported
Thanks all for reply.
I have spoke with Qiming and @Shardy (IRC nickname) and they confirmed this
is not possible as of today. Someone else - sorry i forgot his nicname on
IRC suggested to write a Ceilometer query to count the number of instances
but what @ZhiQiang said is true and this is what
Hi all,
So I've been investigating bug #1383709, which has caused me to run into a
bad update pattern involving OS::Neutron::Port
http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::Port
I'm not quite clear on the history, but for some reason, we have a
On 10/28/2014 11:56 AM, Dean Troyer wrote:
On Tue, Oct 28, 2014 at 9:27 AM, Dan Genin daniel.ge...@jhuapl.edu
mailto:daniel.ge...@jhuapl.edu wrote:
So this brings us back to the original proposal of having separate
backing files for Cinder and Nova which Dean thought might take
too
On 10/28/2014 12:47 PM, Duncan Thomas wrote:
Hi Dan
You're quite right, the nesting isn't as I thought it was, sorry to mislead you.
It isn't a show stopper, it just makes testing some proposed useful
functionality slightly harder. If nova were to namespace its volumes
(e.g. start all the
Sorry for jumping into this thread late...there's lots of details to
process, and I needed time to digest!
Having said that, I'd like to recap before moving the discussion forward,
at the Summit and beyond.
As it's being pointed out, there are a few efforts targeting this area; I
think that is
On Tue, Oct 28, 2014 at 6:44 AM, Dan Smith d...@danplanet.com wrote:
Are current nova CI platforms configured with nova-networking or with
neutron networking? Or is networking in general not even a part of the
nova CI approach?
I think we have several that only run on Neutron, so I think
Cinder volumes are always (unless you go change the default) in the
form: volume-uuid, and since the string 'volume-' is never a valid
uuid, then I think we can work around nova volumes fine when we come
to write our tests.
Sorry for the repeated circling on this, but I think I'm now happy.
On 10/28/2014 06:18 AM, Steven Hardy wrote:
On Tue, Oct 28, 2014 at 11:08:05PM +1300, Robert Collins wrote:
On 28 October 2014 22:51, Steven Hardy sha...@redhat.com wrote:
On Tue, Oct 28, 2014 at 03:22:36PM +1300, Robert Collins wrote:
So this should work and I think its generally good.
But
Vitaly,
though comments like this are definitely better than nothing, I think
we should address these issues in a more formal way.
For random failures we have to retrigger the build until it passes.
Yes, it could take some time (two-three rebuilds?), but it is the only
reliable way which shows
Hi,
Like Atlanta, I will be at the summit. If there is interest, I can
schedule a time to talk about the QoS API extension.
--
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
You should be able to connect like a normal WebSocket, assuming you're running
the serial console websocketproxy (it's a different command from the VNC web
socket proxy). If you want, you can ping
on IRC and I can help you debug your JS code.
Best Regards,
Solly Ross
(directxman12 on freenode
Excerpts from Ben Nemec's message of 2014-10-28 11:13:22 -0700:
On 10/28/2014 06:18 AM, Steven Hardy wrote:
On Tue, Oct 28, 2014 at 11:08:05PM +1300, Robert Collins wrote:
On 28 October 2014 22:51, Steven Hardy sha...@redhat.com wrote:
On Tue, Oct 28, 2014 at 03:22:36PM +1300, Robert
On 28 October 2014 18:01, Dan Genin daniel.ge...@jhuapl.edu wrote:
Changing Nova disk names is a lng shot. It's likely I will be doing
something else by the time that gets merged:) So we are left with the two
options of 1) using a shared volume group and, thus, complicating life for
Great, thank you, Duncan. I will then proceed with the shared volume group.
Dan
On 10/28/2014 02:06 PM, Duncan Thomas wrote:
Cinder volumes are always (unless you go change the default) in the
form: volume-uuid, and since the string 'volume-' is never a valid
uuid, then I think we can work
In certmonger 0.75.13 you can use local-getcert and it will have a
signing cert (selfsigned CA cert). This allows us to replace the
keystone-manage ssl_swetup and pki_setup with certmonger calls.
This should be the plan moving forward, with Certmonger/Barbican
integration a short term
On Tue, Oct 28, 2014 at 12:37 PM, Dan Genin daniel.ge...@jhuapl.edu wrote:
Great, thank you, Duncan. I will then proceed with the shared volume group.
Dan
On 10/28/2014 02:06 PM, Duncan Thomas wrote:
Cinder volumes are always (unless you go change the default) in the
form: volume-uuid,
From: Clint Byrum [cl...@fewbar.com]
Sent: Tuesday, October 28, 2014 11:34 AM
To: openstack-dev
Subject: Re: [openstack-dev] [tuskar][tripleo] Tuskar/TripleO on Devstack
*SNIP*
I think we should actually just rip the git repos out of the images in
Could we specify that all Fuel configuration files should include all
allowable
parameters. The optional parameters can be commented out but being able
to uncomment and populate a parameter is a lot easier than having to find
the
exact name and order.
For bonus points, we could include
On 10/28/2014 01:34 PM, Clint Byrum wrote:
Excerpts from Ben Nemec's message of 2014-10-28 11:13:22 -0700:
On 10/28/2014 06:18 AM, Steven Hardy wrote:
On Tue, Oct 28, 2014 at 11:08:05PM +1300, Robert Collins wrote:
On 28 October 2014 22:51, Steven Hardy sha...@redhat.com wrote:
On Tue, Oct
1. Every packet L3 FIB Lookup : Radix Tree Search, instead of current L2
Hash/Index Lookup ?
2. Will there be Hierarchical network ? How much of the Routes will
be imported from external world ?
3. Will there be Separate routing domain for overlay network ? Or it
will be mixed with
Hi all,
In preparation of the OpenStack Summit in Paris next week, I'm hoping to
speak to some people in the OpenStack foundation about the benefits of a
partnership with Hashicorp, who make fantastic tools like Vagrant and
Packer (and others).
As a n00b aspiring to become an OpenStack
On 29/10/14 06:51, Steven Hardy wrote:
Hi all,
So I've been investigating bug #1383709, which has caused me to run into a
bad update pattern involving OS::Neutron::Port
http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::Port
I'm not quite clear on the history,
On 29/10/14 09:28, Steve Baker wrote:
On 29/10/14 06:51, Steven Hardy wrote:
Hi all,
So I've been investigating bug #1383709, which has caused me to run into a
bad update pattern involving OS::Neutron::Port
There isn't a mechanism for us to get a BoF scheduled in advance. So,
let's gather at the Neutron contributors meetup on Friday.
Hopefully, some of us would have already met each other at the Neutron
design sessions before Friday and we can figure out a good time slot that
works for everyone
Agreed. The way I'm thinking about this is that tenants shouldn't care what the
underlying implementation is - L2 or L3. As long as the connectivity
requirements are met using the model/API, end users should be fine.
The data center network design should be an administrators decision based on
On 10/23/2014 07:57 PM, Elzur, Uri wrote:
We’d like to bring it up in the coming design summit. Where do you think
it needs to be discussed: cross project tack? Scheduler discussion? Other?
I’ve just added a proposed item 17.1 to the
A draft schedule has been posted for the cross-project design summit track:
http://kilodesignsummit.sched.org/overview/type/cross-project+workshops#.VFAFFXVGjUa
If you have any schedule changes to propose for really bad conflicts,
please let me know. We really tried to minimize conflicts, but
On Tue, Oct 28, 2014 at 2:01 PM, Kevin Benton blak...@gmail.com wrote:
I think the simplest use case is just that a provider doesn't want to deal
with extending L2 domains all over their datacenter.
This is similar to a goal behind [1] and [2]. I'm trying to figure
out where the commonalities
On Tue, Oct 28, 2014 at 3:07 PM, Rohit Agarwalla (roagarwa)
roaga...@cisco.com wrote:
Agreed. The way I'm thinking about this is that tenants shouldn't care what
the underlying implementation is - L2 or L3. As long as the connectivity
requirements are met using the model/API, end users should
Hi folks,
we have sahara client 0.7.5 released today with following changes:
* AZ support for Nova and Cinder
* Volume type support for Cinder
More info: https://launchpad.net/python-saharaclient/0.7.x/0.7.5
We need this changes to update Horizon and Heat Sahara bindings.
Thanks.
--
Hi,
I was looking at deploying Tuskar API with Puppet and I was wondering if
you guys have already worked on a Puppet module.
If not, I think we could start something in stackforge like we already
did for other OpenStack components.
Thanks,
--
Emilien Macchi
signature.asc
Description:
Excerpts from Cory Benfield's message of 2014-10-24 06:38:44 -0700:
All,
Project Calico [1] is an open source approach to virtual networking based on
L3 routing as opposed to L2 bridging. In order to accommodate this approach
within OpenStack, we've just submitted 3 blueprints that cover
On 10/27/14, 6:08 PM, Jay Pipes jaypi...@gmail.com wrote:
On 10/27/2014 06:18 PM, Jesse Cook wrote:
In the glance mini-summit there was a request for some documentation on
the architecture ideas I was discussing relating to: 1) removing data
consistency as a concern for glance 2)
On Tue, 28 Oct 2014 09:07:03 PM Rohit Agarwalla wrote:
Agreed. The way I'm thinking about this is that tenants shouldn't care what
the underlying implementation is - L2 or L3. As long as the connectivity
requirements are met using the model/API, end users should be fine. The
data center
On Oct 28, 2014, at 4:59 PM, Angus Lees g...@inodes.org wrote:
On Tue, 28 Oct 2014 09:07:03 PM Rohit Agarwalla wrote:
Agreed. The way I'm thinking about this is that tenants shouldn't care what
the underlying implementation is - L2 or L3. As long as the connectivity
requirements are met
On Tue, 28 Oct 2014 04:42:27 PM Jorge Miramontes wrote:
Thanks for the reply Angus,
DDoS attacks are definitely a concern we are trying to address here. My
assumptions are based on a solution that is engineered for this type of
thing. Are you more concerned with network I/O during a DoS
Dear all,
We proposed a new blueprint (at https://review.openstack.org/128814)
for adding a common cache mechanism for block device storage.
All requirements, suggestions and comments are welcome.
Thank you!
___
OpenStack-dev mailing list
L3 routed network can support
1. broadcast/multicast
2. VRRP virtual MAC like technology
For example OpenContrail does support both of these in fully L3 routed
networks.
Regards
-Harshad
On Tue, Oct 28, 2014 at 4:59 PM, Angus Lees g...@inodes.org wrote:
On Tue, 28 Oct 2014 09:07:03 PM Rohit
On 29 October 2014 11:18, Jesse Cook jesse.c...@rackspace.com wrote:
At the risk of having something thrown at me, what I am suggesting is a
move away from Glance as a service to Glance as a purely functional API.
At some point caching would need to be discussed, but I am intentionally
On 10/14/2014 04:03 PM, Ian Wienand wrote:
Maybe it is time for a release? One thing; does the pre-release check
run over TOT devstack and ensure there are no errors? We don't want
to release and then 10 minutes later gate jobs start failing.
Just to loop back on this ...
Our main goal here
Hello, Russell,
Is the cascading included in the session Approaches for scaling out [1] ?
From the selected topics listed in [2], the selected topic is
plans for scaling out OpenStack using cells
* Session Lead: John Garbutt
* Session Description:
But according
On Wed, 29 Oct 2014 12:21:10 AM Fred Baker wrote:
On Oct 28, 2014, at 4:59 PM, Angus Lees g...@inodes.org wrote:
On Tue, 28 Oct 2014 09:07:03 PM Rohit Agarwalla wrote:
Agreed. The way I'm thinking about this is that tenants shouldn't care
what
the underlying implementation is - L2 or L3.
Hi, Kyle
This is likely due to this bug [1] which was fixed in Juno. On agent
restart, all flows are reprogrammed. We do this to ensure that
everything is reprogrammed correctly and no stale flows are left.
If the neutron-openvswitch-agent restarts , the exist flows should not be
Hi,
The patch setting the time for the API Working Group meeting has
merged:
https://review.openstack.org/#/c/128332/
The time for the meeting is Thursday UTC
In other timezones the meeting is at:
EST 20:00 (Wed)
Japan 09:00 (Thu)
China 08:00 (Thu)
ACDT 10:30 (Thu)
The meeting details
Hi,
Currently migration/rebuild/evacuate didn't support pass
scheduler-hints, that means any migration
can't use schedule-hints that passed when creating instance.
Can we add scheduler-hints support when migration/rebuild/evacuate? That
also can enable user
move in/out instance to/from an
1 - 100 of 103 matches
Mail list logo
