Re: [Openstack-operators] [nova] Can we bump MIN_LIBVIRT_VERSION to 1.2.2 in Liberty?

What are the benefits of upping the minimum libvirt ? We've got 3,200 hypervisors still running v6 with a plan to gradually migrate to 7 but this does take some time. We'll see with RDO this week as to how/if we can get something going with SCL on v6. Tim > -Original Message- > From:

Re: [Openstack-operators] [openstack-dev] Who is using nova-docker? (Re: [nova-docker] Status update)

Again, a conversation that should include the ops list. On Wed, May 13, 2015 at 6:28 AM, Adrian Otto wrote: > Solum uses it in our Vagrant setup. It makes the dev environment perform > very nicely, and is compatible with the Docker containers Solum generates. > > > > Sent from my Verizon Wirel

[Openstack-operators] [summit] Puppet session at OPS meetup

Operators, As a reminder, please have a look at Puppet agenda coming for our OPS meetup: Wednesday - 9am to 9.40am Moderators: Richard Raseley; Colleen Murphy; Emilien Macchi Etherpad: https://etherpad.openstack.org/p/YVR-ops-puppet Feel free to bring up any topic, we will be pleased to discuss

Re: [Openstack-operators] Neutron/DVR scalability of one giant single tenant VS multiple tenants

Yes, correct. Tenants basically are just used as a tag to filter and restrict API operations. On May 14, 2015 4:35 PM, "Gustavo Randich" wrote: > Thanks Kevin, > > If I understood you well, scalability isn't impacted by number of tenants, > but rather by number of ports by network / security grou

Re: [Openstack-operators] [nova] Can we bump MIN_LIBVIRT_VERSION to 1.2.2 in Liberty?

I'm +1 on this. If people want to run Liberty on an old platform, the onus is on them to figure out how to install the relevant deps on that platform. - jlk On Thu, May 14, 2015 at 2:33 PM, Matt Riedemann wrote: > > > On 5/14/2015 3:35 PM, Matt Riedemann wrote: > >> >> >> On 5/14/2015 2:59 PM,

Re: [Openstack-operators] Neutron/DVR scalability of one giant single tenant VS multiple tenants

Thanks Kevin, If I understood you well, scalability isn't impacted by number of tenants, but rather by number of ports by network / security group / tenant router; so, if I have a single giant tenant network with several thousands ports, perhaps I'll have a problem. Partitioning the load into var

Re: [Openstack-operators] [openstack-dev] [all] Technical Committee Highlights May 13, 2015

On Thu, May 14, 2015 at 2:32 PM, Robert Collins wrote: > On 15 May 2015 at 07:15, Anne Gentle > wrote: > > In response to the feedback during elections, the Technical Committee now > > has a subteam dedicated to communications. Below is a link to the first > post > > in our revitalized series. A

Re: [Openstack-operators] Neutron/DVR scalability of one giant single tenant VS multiple tenants

Neutron scalability isn't impacted directly by the number of tenants so that shouldn't matter too much. The following are a few things to consider. Number of ports per security group: Every time a member of a security group (a port) is removed/added or has it's IP changed, a notification goes out

Re: [Openstack-operators] [openstack-dev] [all] Technical Committee Highlights May 13, 2015

On Thu, 14 May 2015, Anne Gentle wrote: In response to the feedback during elections, the Technical Committee now has a subteam dedicated to communications. Below is a link to the first post in our revitalized series. As always, we're here for you and listening and adjusting. Awesome, thanks v

Re: [Openstack-operators] Venom vulnerability

Hello, Ok, thx for explanations :) Yep, I know that best is to restart qemu process but this makes that I can now sleep littlebit more peacefully :) -- Best regards / Pozdrawiam Sławek Kapłoński sla...@kaplonski.pl On Thu, May 14, 2015 at 05:38:56PM -0400, Favyen Bastani wrote: > On 05/14/2015

Re: [Openstack-operators] Venom vulnerability

On 05/14/2015 05:23 PM, Sławek Kapłoński wrote: > Hello, > > So if I understand You correct, it is not so dangeorus if I'm using > ibvirt with apparmor and this libvirt is adding apparmor rules for > every qemu process, yes? > > You should certainly verify that apparmor rules are enabled for th

Re: [Openstack-operators] [nova] Can we bump MIN_LIBVIRT_VERSION to 1.2.2 in Liberty?

On 5/14/2015 3:35 PM, Matt Riedemann wrote: On 5/14/2015 2:59 PM, Kris G. Lindgren wrote: How would this impact someone running juno nova-compute on rhel 6 boxes? Or installing the python2.7 from SCL and running kilo+ code on rhel6? For [3] it couldn't we get the exact same information from

Re: [Openstack-operators] Venom vulnerability

Hello, So if I understand You correct, it is not so dangeorus if I'm using ibvirt with apparmor and this libvirt is adding apparmor rules for every qemu process, yes? -- Best regards / Pozdrawiam Sławek Kapłoński sla...@kaplonski.pl On Wed, May 13, 2015 at 04:01:05PM +0100, Daniel P. Berrange w

[Openstack-operators] OpenStack 2015.1.0 for Debian Sid and Jessie

Hi, I am pleased to announce the general availability of OpenStack 2015.1.0 (aka Kilo) in Debian unstable (aka Sid) and through the official Debian backports repository for Debian 8.0 (aka Sid). Debian 8.0 Jessie just released === As you may know, Debian 8.0 was re

Re: [Openstack-operators] [nova] Can we bump MIN_LIBVIRT_VERSION to 1.2.2 in Liberty?

On 5/14/2015 2:59 PM, Kris G. Lindgren wrote: How would this impact someone running juno nova-compute on rhel 6 boxes? Or installing the python2.7 from SCL and running kilo+ code on rhel6? For [3] it couldn't we get the exact same information from /proc/cpuinfo? ___

Re: [Openstack-operators] chef

> On May 14, 2015, at 1:21 AM, aishwarya.adyanth...@accenture.com wrote: > > Hi J, > > I ran the command 'knife node list' and found the list to be empty while the > 'knife client list' command displays chef-validator and chef-webui. It seems > like when I was creating the node through knife

[Openstack-operators] [Telco][NFV] OpenStack Telco Working Group Vancouver session

Hi all, I am very pleased to be facilitating the OpenStack Telco Working Group session at the Vancouver summit. The session is scheduled as a working session on Wednesday, May 20th @ 9:00 AM in East Building, Room 2/3 More details can be found on the Liberty Design Summit schedule[0]. Please no

Re: [Openstack-operators] [nova] Can we bump MIN_LIBVIRT_VERSION to 1.2.2 in Liberty?

How would this impact someone running juno nova-compute on rhel 6 boxes? Or installing the python2.7 from SCL and running kilo+ code on rhel6? For [3] it couldn't we get the exact same information from /proc/cpuinfo? Kris Lindgren Senior Linux Systems

Re: [Openstack-operators] [openstack-dev] [all] Technical Committee Highlights May 13, 2015

On 15 May 2015 at 07:15, Anne Gentle wrote: > In response to the feedback during elections, the Technical Committee now > has a subteam dedicated to communications. Below is a link to the first post > in our revitalized series. As always, we're here for you and listening and > adjusting. > > http:

[Openstack-operators] [nova] Can we bump MIN_LIBVIRT_VERSION to 1.2.2 in Liberty?

The minimum required version of libvirt in the driver is 0.9.11 still [1]. We've been gating against 1.2.2 in Ubuntu Trusty 14.04 since Juno. The libvirt distro support matrix is here: [2] Can we safely assume the people aren't going to be running Libvirt compute nodes on RHEL < 7.1 or Ubuntu

Re: [Openstack-operators] how to filter outgoing VM traffic in icehouse

On Thu, 14 May 2015 10:19:53 -0700 Abel Lopez wrote: > I heard lots of talk in Paris about having nova-network reach feature > parity with neutron. With neutron, you can specify egress/ingress > rules in Horizon, so if nova-network ever got feature parity, it > should work *someday* I think It's

[Openstack-operators] [all] Technical Committee Highlights May 13, 2015

In response to the feedback during elections, the Technical Committee now has a subteam dedicated to communications. Below is a link to the first post in our revitalized series. As always, we're here for you and listening and adjusting. http://www.openstack.org/blog/2015/05/technical-committee-hig

Re: [Openstack-operators] [nova] Backlog Specs: a way to send requirements to the developer community

On 05/14/15 21:04, Boris Pavlovic wrote: John, I believe that backlog should be different much simpler then specs. Imho Operators don't have time / don't want to write long long specs and analyze how they are aligned with specs or moreover how they should be implemented and how they impact pe

[Openstack-operators] [openstack-operators][chef] OpenStack-Chef Official Ops Meetup

> On May 12, 2015, at 3:00 PM, JJ Asghar wrote: > > I’d like to announce the OpenStack-Chef Ops Meetup in Vancouver. We have an > etherpad[1] going with topics people would like to discuss. I haven’t found a > room or space for us yet, but when I do I’ll comment back on this thread and > add i

Re: [Openstack-operators] [nova] Backlog Specs: a way to send requirements to the developer community

Kyle Mestery recently merged a governance change in Neutron that introduces the idea of request for enhancement bug. Anyone can file a bug against Neutron and tag it with 'rfe'. The bug should include the problem statement and use cases, and any developer can later come in write a spec should it r

Re: [Openstack-operators] [nova] Backlog Specs: a way to send requirements to the developer community

John, I believe that backlog should be different much simpler then specs. Imho Operators don't have time / don't want to write long long specs and analyze how they are aligned with specs or moreover how they should be implemented and how they impact performance/security/scalability. They want jus

[Openstack-operators] [nova] Backlog Specs: a way to send requirements to the developer community

Hi, I was talking with Matt (VW) about how best some large deployment working sessions could send their requirements to Nova. As an operator, if you have a problem that needs fixing or use case that needs addressing, a great way of raising that issue with the developer community is a "Backlog" no

Re: [Openstack-operators] how to filter outgoing VM traffic in icehouse

I heard lots of talk in Paris about having nova-network reach feature parity with neutron. With neutron, you can specify egress/ingress rules in Horizon, so if nova-network ever got feature parity, it should work *someday* > On May 14, 2015, at 10:10 AM, Stephen Cousins wrote: > > Is there any

Re: [Openstack-operators] how to filter outgoing VM traffic in icehouse

Is there any plan for egress rules to be managed in Horizon? On Wed, May 13, 2015 at 5:47 PM, Kevin Bringard (kevinbri) < kevin...@cisco.com> wrote: > Ah, I don't believe nova-network supports EGRESS rules. > > On 5/13/15, 3:41 PM, "Gustavo Randich" wrote: > > >Hi, sorry, I forgot to mention:

[Openstack-operators] Neutron/DVR scalability of one giant single tenant VS multiple tenants

Hi! We are evaluating the migration of our private cloud of several thousand VMs from multi-host nova-network to neutron/DVR. For historical reasons, we currently use a single tenant because group administration is made outside openstack (users don't talk to OS API). The number of compute nodes we

Re: [Openstack-operators] Packaging, Deployment CI/CD - Moderators Needed (Vancouver)

that makes more sense to me. On Thu, May 14, 2015 at 12:13 PM, Matt Kassawara wrote: > Wouldn't this replace the database session... not the packaging session? > > On Thu, May 14, 2015 at 11:10 AM, matt wrote: > >> A worthwhile discussion. But are we talking about this as it relates to >> pack

Re: [Openstack-operators] Packaging, Deployment CI/CD - Moderators Needed (Vancouver)

Wouldn't this replace the database session... not the packaging session? On Thu, May 14, 2015 at 11:10 AM, matt wrote: > A worthwhile discussion. But are we talking about this as it relates to > packaging or as a separate track related to the architectural and > procedural challenges? > > -matt

Re: [Openstack-operators] Packaging, Deployment CI/CD - Moderators Needed (Vancouver)

A worthwhile discussion. But are we talking about this as it relates to packaging or as a separate track related to the architectural and procedural challenges? -matt On Thu, May 14, 2015 at 12:06 PM, Matt Kassawara wrote: > I propose that we spend more time discussing how to improve the netwo

Re: [Openstack-operators] Packaging, Deployment CI/CD - Moderators Needed (Vancouver)

I propose that we spend more time discussing how to improve the networking guide for operators. Can we enhance the structure/content of existing deployment scenarios to appeal to more operators, particularly those looking to jump from nova-net to neutron? Can we get more operators to help contribut

[Openstack-operators] OpenStack 2015.1.0 for Ubuntu 14.04 LTS and Ubuntu 15.04

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi All The Ubuntu OpenStack team is pleased to announce the general availability of OpenStack 2015.1.0 (Kilo) release in Ubuntu 15.04 and for Ubuntu 14.04 LTS via the Ubuntu Cloud Archive. Ubuntu 14.04 LTS - You can enable the Ubu

Re: [Openstack-operators] Venom vulnerability

Hi Basil, et al, Canonical/Ubuntu support page for Ubuntu Cloud Archive shows Precise/Havana EOLife last year sometime. Refer to this chart: https://wiki.ubuntu.com/ServerTeam/CloudArchive?action=AttachFile&do=get&target=plan.png from this page: https://wiki.ubuntu.com/ServerTeam/CloudArchive

Re: [Openstack-operators] ha queues Juno periodic rabbitmq errors

On 5/14/15, 9:45 AM, "Pedro Sousa" wrote: >Hi Kevin, > > >thank you for reply, I'm using rabbitmqctl set_policy HA '^(?!amq\.).*' >'{"ha-mode": "all"}' > > >I will test with "ha-sync-mode":"automatic"' and net.ipv4.tcp_retries2=5 I don't know that you need to ha-sync-mode to automatic (I was j

Re: [Openstack-operators] Venom vulnerability

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Basil On 14/05/15 16:04, Basil Baby wrote: > I can see the patch for CVE-2015-3456 updated to qemu-kvm package > on Precise - Icehouse branch. > https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/icehouse-s taging/+build/7425816 > >

Re: [Openstack-operators] ha queues Juno periodic rabbitmq errors

Hi Kevin, thank you for reply, I'm using rabbitmqctl set_policy HA '^(?!amq\.).*' '{"ha-mode": "all"}' I will test with "ha-sync-mode":"automatic"' and net.ipv4.tcp_retries2=5 Regards, Pedro Sousa On Thu, May 14, 2015 at 4:29 PM, Kevin Bringard (kevinbri) < kevin...@cisco.com> wrote: > If

[Openstack-operators] Vancouver Summit - Customer On-boarding/Off-boarding

Hi, I will be moderating the Customer On-Boarding/Off-Boarding[1] session at the summit, and wanted to make sure we get as much feedback into the etherpad[2] as possible. Both adding and removing users seems like a pretty simple idea, but it gets complicated pretty quickly. So any suggestions, re

Re: [Openstack-operators] ha queues Juno periodic rabbitmq errors

If you're using Rabbit 3.x you need to enable HA queues via policy on the rabbit server side. Something like this: rabbitmqctl set_policy ha-all "" '{"ha-mode":"all","ha-sync-mode":"automatic"}' Obviously, tailor it to your own needs :-) We've also seen issues with TCP_RETRIES2 needing to be t

[Openstack-operators] ha queues Juno periodic rabbitmq errors

Hi all, I'm using Juno and ocasionally see this kind of errors when I reboot one of my rabbit nodes: *"MessagingTimeout: Timed out waiting for a reply to message ID e95d4245da064c779be2648afca8cdc0"* I use ha queues in my openstack services: *rabbit_hosts=192.168.113.206:5672

Re: [Openstack-operators] Venom vulnerability

If anyone from Canonical here who maintains ubuntu-cloud.archive.canonical, I can see the patch for CVE-2015-3456 updated to qemu-kvm package on Precise - Icehouse branch. https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/icehouse-staging/+build/7425816 But, on precise-havana it is not

[Openstack-operators] [openstack-dev][openstack-operators][Rally][announce] What's new in Rally v0.0.4

Hi everyone, Rally team is happy to announce that we have just cut the new release 0.0.4! *Release stats:* - Commits: *87* - Bug fixes: *21* - New scenarios: *14* - New contexts: *2* - New SLA: *1* - Dev cycle: *30 days* - Release date: *14/May/2015* *New features:* - *

Re: [Openstack-operators] Multiple vlan ranges on same physical interface [ml2]

On 05/11/2015 11:23 AM, Kevin Benton wrote: I apologize but I didn't quite follow what the issue was with tenants allocating networks in your use case, can you elaborate a bit there? From what it sounded like, it seems like you could define the vlan range you want the tenants' internal netwo