[Openstack-operators] [neutron] [QoS] Interface/API for review.

2015-05-04 Thread Miguel Ángel Ajo
Hello, we're working [1] on the QoS API definition and we’d like to get some feedback from operators on [2] and [3]. We’re scoping the work we intend to do in Liberty to make sure it will be doable, but we plan to extend it via subsequent iterations: * traffic marking (dscp, VLAN 802.1p,

Re: [Openstack-operators] [neutron] [QoS] Interface/API for review.

2015-05-04 Thread Jesse Keating
Thanks Miguel! The command line reference set looks good, although I'm curious what the openstackclient version of them will be. I've also left a comment on the spec review. - jlk On Mon, May 4, 2015 at 7:29 AM, Miguel Ángel Ajo majop...@redhat.com wrote: Hello, we're working [1] on the

Re: [Openstack-operators] expanding to 2nd location

2015-05-04 Thread Tim Bell
CERN runs two data centres in Geneva (3.5MW) and Budapest (2.7MW), around 1,200 KMs . We have two 100Gb/s links between the two sites and latency of around 22ms. We run this as a single cloud with 13 cells. Each cell is only in one data centre. We wanted a single API endpoint from the user

Re: [Openstack-operators] expanding to 2nd location

2015-05-04 Thread Allamaraju, Subbu
I suggest building a new AZ (“region” in OpenStack parlance) in the new location. In general I would avoid setting up control plane to operate across multiple facilities unless the cloud is very large. On May 4, 2015, at 1:40 PM, Jonathan Proulx j...@jonproulx.com wrote: Hi All, We're

[Openstack-operators] expanding to 2nd location

2015-05-04 Thread Jonathan Proulx
Hi All, We're about to expand our OpenStack Cloud to a second datacenter. Anyone one have opinions they'd like to share as to what I would and should be worrying about or how to structure this? Should I be thinking cells or regions (or maybe both)? Any obvious or not so obvious pitfalls I