[Openstack-operators] Downgrade in Trove

Hello all, we from Trove, want to remove the downgrade fuctionality from our SQL Schema. This was a TC approved spec for all projects across OpenStack[1] and we need to follow this process as well. We would like to know if are there anyone using this functionality and that removing it would be a

[Openstack-operators] Service Catalog TNG urls

For folks that don't know, we've got an effort under way to look at some of what's happened with the service catalog, how it's organically grown, and do some pruning and tuning to make sure it's going to support what we want to do with OpenStack for the next 5 years (wiki page to dive deeper here

Re: [Openstack-operators] Cinder V1 endpoints

Yes, that appears to be a documentation error. - jlk On Thu, Dec 3, 2015 at 7:33 AM, Salman Toor wrote: > Hi, > > In the following link of Kilo document the cinder V1 endpoints have v2 in > it. > > >

[Openstack-operators] Cinder V1 endpoints

Hi, In the following link of Kilo document the cinder V1 endpoints have v2 in it. http://docs.openstack.org/kilo/install-guide/install/yum/content/cinder-install-controller-node.html openstack endpoint create \ --publicurl http://controller:8776/v2/%\(tenant_id\)s \ --internalurl

Re: [Openstack-operators] Cinder V1 endpoints

Thanks! /Salman. PhD, Scientific Computing Researcher, IT Department, Uppsala University. Senior Cloud Architect, SNIC. Cloud Application Expert, UPPMAX. Visiting Researcher, Helsinki Institute of Physics (HIP). salman.t...@it.uu.se

Re: [Openstack-operators] Service Catalog TNG urls

We make use of http urls internally for services to talk to each other, but not for human users. All our human users should be using https public url. We don't actually utilize the internalURL framework, instead we use /etc/hosts entries to change the domain resolution of our publicURL entries,

Re: [Openstack-operators] Better error messages for API policy enforcements

On 12/02/15 at 03:24pm, Robert Starmer wrote: I can't think of a case where better error response and log messages are not useful/desired. I agree with this, but I don't think that custom error messages defined in policy.json are the way to go. The API response should be standard across

Re: [Openstack-operators] [keystone] Request for Feedback: Online database migrations

These steps seem reasonable, and will help Operators. Thanks for going through this! - jlk On Wed, Dec 2, 2015 at 12:06 PM, Lance Bragstad wrote: > Hey all, > > I wanted to send out a follow up on this. Yesterday in the keystone > meeting we voted on Mitaka specs that we

Re: [Openstack-operators] Service Catalog TNG urls

Excerpts from Dan Sneddon's message of 2015-12-03 09:43:59 -0800: > On 12/03/2015 06:14 AM, Sean Dague wrote: > > For folks that don't know, we've got an effort under way to look at some > > of what's happened with the service catalog, how it's organically grown, > > and do some pruning and tuning

Re: [Openstack-operators] Service Catalog TNG urls

On 12/03/2015 12:01 PM, Clint Byrum wrote: > Excerpts from Dan Sneddon's message of 2015-12-03 09:43:59 -0800: >> On 12/03/2015 06:14 AM, Sean Dague wrote: >>> For folks that don't know, we've got an effort under way to look at some >>> of what's happened with the service catalog, how it's

Re: [Openstack-operators] Service Catalog TNG urls

On 12/03/2015 09:46 AM, Fox, Kevin M wrote: > We use internal to be a private network between the controllers and the > compute nodes that no one else has access to. Without that, we'd be stuck. > > An OpenStack network that's where all the public services go, that > isn't external to the cloud

Re: [Openstack-operators] Service Catalog TNG urls

Yeah, switching them that way makes a lot of sense. Thanks, Kevin From: Dan Sneddon Sent: Thursday, December 03, 2015 12:39:25 PM To: Fox, Kevin M; Jesse Keating; Sean Dague Cc: openstack-operators Subject: Re: [Openstack-operators] Service Catalog TNG urls On

Re: [Openstack-operators] OpenStack Puppet module Keystone Juno

Hi Emilien, I decided I'd give up on Juno. So I am trying to set up a Kilo cloud now. I am still having trouble getting keystone to work. I have a detailed question on ask.openstack.com here:

Re: [Openstack-operators] Two regions and so two metadata servers sharing the same VLAN

Hum, I don't think so. Things like hostname must be only known by the neutron instance of one region... Le 03/12/2015 00:01, Kevin Benton a écrit : Are both metadata servers able to provide metadata for all instances of both sides? If so, why not disable isolated metadata on one of the sides

Re: [Openstack-operators] Two regions and so two metadata servers sharing the same VLAN

Not sure what you can do on your vmware backed boxes, but on the kvm compute nodes you can run nova-api-metadata locally. We do this by binding 169.254.169.254 to loopback (technically an non-arping interface would work) on each hypervisor. If I recall correctly, setting the metadata_server

Re: [Openstack-operators] Service Catalog TNG urls

On 12/03/2015 06:14 AM, Sean Dague wrote: > For folks that don't know, we've got an effort under way to look at some > of what's happened with the service catalog, how it's organically grown, > and do some pruning and tuning to make sure it's going to support what > we want to do with OpenStack

Re: [Openstack-operators] Service Catalog TNG urls

We use internal to be a private network between the controllers and the compute nodes that no one else has access to. Without that, we'd be stuck. An OpenStack network that's where all the public services go, that isn't external to the cloud for billing purposes does make sense too though.

[Openstack-operators] [app-catalog] App Catalog IRC meeting minutes - 12/3/2015

This morning we had a brief meeting but did have a chance to touch on a little bit of the Glare back-end work for the App Catalog. Additionally I mentioned we're going to start working to include TOSCA elements in the catalog soon. We could still really use a volunteer to chair a meeting time