Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

2016-05-15 Thread Xav Paice
On 14 May 2016 at 00:27, Major Hayden wrote: > > For what it's worth, I have a (somewhat dated) branch with Octavia support > in Github[1]. > > > Great stuff! - that's covered everything I've been looking at so far, except that we're not wanting to run neutron-server (and

Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

2016-05-12 Thread Xav Paice
for our deployments my ability to test/run things would be quite limited. Maybe this is the push I need to knuckle down and migrate. On 12 May 2016 at 00:33, Major Hayden <ma...@mhtx.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 05/10/2016 11:58 P

Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

2016-05-10 Thread Xav Paice
Sorry to dig up an ancient thread. I see the spec has been implemented, and in the os_neutron repo I see configs for the Haproxy driver for LOADBALANCERV2 - but not Octavia. Am I missing something here? On 29 January 2016 at 10:03, Major Hayden wrote: > -BEGIN PGP SIGNED

Re: [openstack-dev] [all][zaqar][cloudkitty] Default ports list

2016-03-10 Thread Xav Paice
On 11 March 2016 at 10:45, Morgan Fainberg <morgan.fainb...@gmail.com> wrote: > > > On Thu, Mar 10, 2016 at 1:29 PM, Xav Paice <xavpa...@gmail.com> wrote: > >> >> >> A simple list is probably enough for a quick ref - it's not a massive >> block

Re: [openstack-dev] [all][zaqar][cloudkitty] Default ports list

2016-03-10 Thread Xav Paice
On 10 March 2016 at 10:35, Fei Long Wang wrote: > The only link I can find is > http://docs.openstack.org/liberty/config-reference/content/firewalls-default-ports.html. > So my question is should we document the default ports list on an official > place given the big

Re: [openstack-dev] [all][zaqar][cloudkitty] Default ports list

2016-03-10 Thread Xav Paice
Remember that we're talking here about all the projects, not just keystone. I can't see that we'll move everything to subpaths at any time soon, and until that point we still need to at least make an informal agreement as to which 'default' port to expect services to live on. Even if that's just

Re: [openstack-dev] [all][zaqar][cloudkitty] Default ports list

2016-03-09 Thread Xav Paice
>From an ops point of view, this would be extremely helpful information to share with various teams around an organization. Even a simple wiki page would be great. On 10 March 2016 at 10:35, Fei Long Wang wrote: > Hi all, > > Yesterday I just found cloudkitty is using

Re: [openstack-dev] [neutron] - Changing the Neutron default security group rules

2016-03-02 Thread Xav Paice
On 3 March 2016 at 07:52, Sean Dague wrote: > On 03/02/2016 01:46 PM, Armando M. wrote: > > > IMO, I think that's a loophole that should be closed. We should all > > strive to make OpenStack clouds behave alike. > > It might be a loophole. But it's also data. People are doing

Re: [openstack-dev] [neutron] - Changing the Neutron default security group rules

2016-03-02 Thread Xav Paice
>From one operator's standpoint, some comments below. I can't imagine having to tell my customer base that we've just changed the 'default' security group from not allowing anything inbound, to allowing everything. That would mean they would all have to strip the default group from all their

Re: [openstack-dev] [nova] python-novaclient region setting

2016-02-25 Thread Xav Paice
pad.net/python-novaclient/+bug/1494116 > On Wed, Feb 24, 2016 at 8:42 AM, Xav Paice <xavpa...@gmail.com> wrote: > >> fwiw, the second part of Monty's message is in the docs, sans region - it >> would be a fairly swift change to add that and I'll probably submit a >>

Re: [openstack-dev] [nova] python-novaclient region setting

2016-02-23 Thread Xav Paice
novaclient sets it, so it's safe to omit in most cases >> # endpoint_override - if you want to tell it to use a different URL >> # than what the keystone catalog returns >> # endpoint_type - if you need to specify admin or internal >> #

Re: [openstack-dev] [nova] python-novaclient region setting

2016-02-22 Thread Xav Paice
t; # Note that in glance and barbican, this key is called > # 'interface' > client = nova_client.Client( > version='2.0', # or set the specific microversion you want > session=session, region_name=OS_REGION_NAME) > > It might be clear why I

[openstack-dev] [nova] python-novaclient region setting

2016-02-21 Thread Xav Paice
Hi, In http://docs.openstack.org/developer/python-novaclient/api.html it's got some pretty clear instructions not to use novaclient.v2.client.Client but I can't see another way to specify the region - there's more than one in my installation, and no param for region in novaclient.client.Client

Re: [openstack-dev] [All] Use of self signed certs in endpoints

2015-11-18 Thread Xav Paice
Setting an env var seems like a very straightforward way to do this, and means the deployer can easily control the specifics of what they want without any code changes - that suits me perfectly. Adding some documentation somewhere to that effect might be handy but this is indeed a bit of an edge

Re: [openstack-dev] [All] Use of self signed certs in endpoints

2015-11-15 Thread Xav Paice
in. On 16 November 2015 at 04:26, Adam Young <ayo...@redhat.com> wrote: > On 11/14/2015 03:09 AM, Xav Paice wrote: > > Hi, > > I'm sure I'm not the only one that likes to use SSL everywhere possible, > and doesn't like to pay for 'real' ssl certs for dev environments. > Figu

Re: [openstack-dev] [All] Use of self signed certs in endpoints

2015-11-15 Thread Xav Paice
the consensus here is to discuss using the system CAs with the requests devs rather than add a config item to OpenStack? On 16 November 2015 at 05:14, Monty Taylor <mord...@inaugust.com> wrote: > On 11/15/2015 10:26 AM, Adam Young wrote: > >> On 11/14/2015 03:09 AM, Xav Paic

[openstack-dev] [All] Use of self signed certs in endpoints

2015-11-14 Thread Xav Paice
Hi, I'm sure I'm not the only one that likes to use SSL everywhere possible, and doesn't like to pay for 'real' ssl certs for dev environments. Figuring out how to get requests to allow connection to the self signed cert would have paid for a real cert many times over. When I use an SSL cert

Re: [openstack-dev] PLEASE READ: VPNaaS API Change - not backward compatible

2015-08-24 Thread Xav Paice
feature. I do think we need to be able to support our customers in the transition, and extra pain for them results in lower uptake of the services we provide. On 25 August 2015 at 09:27, Xav Paice xavpa...@gmail.com wrote: Also: http://lists.openstack.org/pipermail/openstack-operators/2015

Re: [openstack-dev] PLEASE READ: VPNaaS API Change - not backward compatible

2015-08-24 Thread Xav Paice
On 25/08/15 06:32, Paul Michali wrote: As part of the effort to provide support for multiple local subnets for VPNaaS IPSec connections, there are three API changes planned [1]. One is to add a new endpoint groups API that will describe what is being connected. This is the place were local

Re: [openstack-dev] PLEASE READ: VPNaaS API Change - not backward compatible

2015-08-24 Thread Xav Paice
, 2015 at 3:50 PM Xav Paice xavpa...@gmail.com wrote: On 25/08/15 06:32, Paul Michali wrote: As part of the effort to provide support for multiple local subnets for VPNaaS IPSec connections, there are three API changes planned [1]. One is to add a new endpoint groups API that will describe

Re: [openstack-dev] [Nova][libvirt] Understand why we lookup libvirt domains by instance name

2015-05-21 Thread Xav Paice
On 21/05/15 21:23, Daniel P. Berrange wrote: On Wed, May 20, 2015 at 03:01:50PM -0700, Michael Still wrote: I note that we use instance.name to lookup the libvirt domain a bunch in the driver. I'm wondering why we don't just use instance.uuid all the time -- the code for that already exists.