Re: [Openstack-operators] Liberty cinder ceph architecture

Many thanks for your hints. Ignazio 2015-12-09 9:50 GMT+01:00 Arne Wiebalck : > We had the Cinder services running on our controllers initially, but split > them off > to a separate set of (virtual) machines in order to allow for independent > upgrades. > Performance-wise

Re: [Openstack-operators] [openstack-dev] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

On 12/08/2015 04:09 AM, Dolph Mathews wrote: > In Debian, many services/daemons are run, then their API is used by the > package. In the case of Keystone, for example, it is possible to ask, > via Debconf, that Keystone registers itself in the service catalog. If > we get Keystone

[Openstack-operators] [keystone] RBAC usage at production

Hi, I am wondering whether there are people using RBAC at production. The policy.json file has a structure that requires restart of the service each time you edit the file. Is there and on the fly solution or tips about it? ___

[Openstack-operators] [openstack-ansible] Mid Cycle Sprint

Hi everyone, At the Mitaka design summit in Tokyo we had some corridor discussions about doing a mid-cycle meetup for the purpose of continuing some design discussions and doing some specific sprint work. *** I'd like indications of who would like to attend and what

Re: [Openstack-operators] Nova-network -> Neutron Migration

Thanks, Tom, Sam, and Edgar, that's really good info. If nothing else it'll give me a good blueprint for what to look for and where to start. On 12/8/15, 10:37 PM, "Edgar Magana" wrote: >Awesome code! I just did a small testbed test and it worked nicely! > >Edgar >

Re: [Openstack-operators] Nova-network -> Neutron Migration

Doesn't this script only solve the case of going from flatdhcp networks in nova-network to same dchp/provider networks in neutron. Did anyone test to see if it also works for doing more advanced nova-network configs? ___ Kris

Re: [Openstack-operators] Nova-network -> Neutron Migration

I did not but more advanced could mean a lot of things for Neutron. There are so many possible scenarios that expecting to have a “script” to cover all of them is a whole new project. Not sure we want to explore than. In the past we were recommending to make the migration in multiple steps,

Re: [Openstack-operators] Cinder API with multiple regions not working.

Hi Salman, Someone mentioned this same issue yesterday in relation to Terraform (maybe a colleague of yours?), so given the two occurrences, I thought I'd look into this. I have a Liberty environment readily available, so I created a second set of volume and volumev2 endpoints for a fictional

Re: [Openstack-operators] Nova-network -> Neutron Migration

Yea, I was considering updating the wiki (https://wiki.openstack.org/wiki/Neutron/MigrationFromNovaNetwork/HowTo) to at least make mention of it. If it works (and it sounds like it does, at least for Juno) then I'm all for adding it as a potential resource On 12/9/15, 9:52 AM, "Matt

Re: [Openstack-operators] [keystone] RBAC usage at production

In other projects the policy.json file is read each time of api request. So changes to the file take place immediately. I was 90% sure keystone was the same way? ___ Kris Lindgren Senior Linux Systems Engineer GoDaddy On

Re: [Openstack-operators] [keystone] RBAC usage at production

We use RBAC in production but basically modify networking operations and some compute ones. In our case we don’t need to restart the services if we modify the policy.json file. I am surprise that keystone is not following the same process. Edgar On 12/9/15, 9:06 AM, "Kris G. Lindgren"

Re: [Openstack-operators] [openstack-dev] [keystone] RBAC usage at production

Whether or not a restart is required is actually handled by oslo.policy. Which is only included in Kilo and newer versions of Keystone. The work to avoid restarting the service went in in commit [0] and was further worked on in [1]. Juno and older versions are using the oslo-incubator code to

Re: [Openstack-operators] [openstack-dev] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

On 12/08/2015 06:39 AM, Jamie Lennox wrote: > The main problem I see with running Keystone (or any other service) in a > web server, is that *I* (as a package maintainer) will loose the control > over when the service is started. Let me explain why that is important > for me. > >

[Openstack-operators] OpenStack Liberty automation script release.

Dear stackers, Vietnam OpenStack Community is very eager to announce the release of Liberty automation deploy script: 1. Liberty deploy multi nodes using OVS in Neutron: https://github.com/vietstacker/openstack-liberty-multinode /blob/master/LIBERTY-U14.04-OVS/README-ENGLISH.md 2. Liberty deploy

Re: [Openstack-operators] Nova-network -> Neutron Migration

It's worth pointing out, it looks like this only works in Kilo+, as it's written. Sam pointed out earlier that this was what they'd run it on, but I verified it won't work on earlier versions because, specifically, in the migrate-secgroups.py it inserts into the default_security_group table,