Re: [Openstack-operators] [Telco][NFV][infra] Review process of TelcoWG use cases

2015-02-17 Thread Marc Koderer
Hello everyone, We already got good feedback on my sandbox test review. So I would like to move forward. With review [1] we will get a stackforge repo called „telcowg-usecases“. Submitting a usecase will then follow the process of OpenStack development (see [2]). The is one thing currently open

Re: [Openstack-operators] State of Juno in Production

2015-02-17 Thread Joe Topjian
Cool, thanks, Jon. I've been following the thread on your scheduling issue on the OpenStack list. I can't see our users hitting that issue, but it's always good to keep in mind. :) On Tue, Feb 17, 2015 at 1:17 PM, Jonathan Proulx wrote: > Recently (4 weeks?) moved from Icehouse to Juno. It was p

Re: [Openstack-operators] [openstack-dev] [Product] [all][log] Openstack HTTP error codes

2015-02-17 Thread Rochelle Grober
What I see in this conversation is that we are talking about multiple different user classes. Infra-operator needs as much info as possible, so if it is a vendor driver that is erring out, the dev-ops can see it in the log. Tenant-operator is a totally different class of user. These guys need

[Openstack-operators] [Large Deployments] Meeting Reminder: February, 19th 16:00 UTC #openstack-meeting-4

2015-02-17 Thread Matt Van Winkle
Hey folks, This is just a quick reminder that our meeting this month goes back to the 16:00UTC time slot. I've updated the agenda here: https://etherpad.openstack.org/p/Large-Deployment-Team-Meetings Two big items of discussion are: 1. Update on Cells V2: A bit of discussion around it last m

Re: [Openstack-operators] State of Juno in Production

2015-02-17 Thread Jonathan Proulx
Recently (4 weeks?) moved from Icehouse to Juno. It was pretty smooth (neutron has been much more well behaved though I know that's not relevant to you). One negative difference I noticed, but haven't really dug into yet since it's not a common pattern here: If I schedule >20 instances in one API

Re: [Openstack-operators] How to force Heat to use v2.0 Keystone

2015-02-17 Thread Chris Buccella
For Icehouse and Juno, you'll want to use the Keystone v2 plugin for heat: https://git.openstack.org/cgit/openstack/heat/tree/contrib/heat_keystoneclient_v2 -Chris On Tue, Feb 17, 2015 at 10:51 AM, Alvise Dorigo wrote: > Hi Christian; here the info you've requested: > > [root@controller-01 ~]

Re: [Openstack-operators] State of Juno in Production

2015-02-17 Thread Joe Topjian
Nice - thanks, Jesse. :) On Tue, Feb 17, 2015 at 10:35 AM, Jesse Keating wrote: > On 2/17/15 8:46 AM, Joe Topjian wrote: > >> >> The only issue I'm aware of is that live snapshotting is disabled. Has >> anyone re-enabled this and seen issues? What was the procedure to >> re-enable? >> > > We've

Re: [Openstack-operators] State of Juno in Production

2015-02-17 Thread Jesse Keating
On 2/17/15 8:46 AM, Joe Topjian wrote: The only issue I'm aware of is that live snapshotting is disabled. Has anyone re-enabled this and seen issues? What was the procedure to re-enable? We've re-enabled it. Live snapshots take more system resources, which meant I had to dial back down my Ral

[Openstack-operators] State of Juno in Production

2015-02-17 Thread Joe Topjian
Hello, I'm beginning to plan for a Juno upgrade and wanted to get some feedback from anyone else who has gone through the upgrade and has been running Juno in production. The environment that will be upgraded is pretty basic: nova-network, no cells, Keystone v2. We run a RabbitMQ cluster, though,

Re: [Openstack-operators] How to force Heat to use v2.0 Keystone

2015-02-17 Thread Alvise Dorigo
Hi Christian; here the info you've requested: [root@controller-01 ~]# grep auth_uri /etc/heat/heat.conf /etc/glance/glance-api.conf /etc/heat/heat.conf:# Allowed keystone endpoints for auth_uri when multi_cloud is /etc/heat/heat.conf:#allowed_auth_uris= /etc/heat/heat.conf:auth_uri = https://

Re: [Openstack-operators] How to force Heat to use v2.0 Keystone

2015-02-17 Thread Christian Berendt
On 02/17/2015 04:11 PM, Alvise Dorigo wrote: > [dorigoa@lxadorigo ~]$ heat -k stack-create -f test-stack.yml -P > "ImageID=cirros;NetID=$NET_ID" testStac > ERROR: Property error : server1: image Authorization failed: SSL > exception connecting to > https://cloud-areapd-test.pd.infn.it:5000/v3

[Openstack-operators] How to force Heat to use v2.0 Keystone

2015-02-17 Thread Alvise Dorigo
Hi, I've an IceHouse installation with v2.0 Keystone. All services run correctly but Heat, which wants authenticate to the non-existing endpoint https://cloud-areapd-test.pd.infn.it:5000/v3/auth/tokens. In fact only v2 is configured (and we cannot reconfigure all the openstack installation in