Open Stack

All,

Some more color on (3) our plan was to allow for multiple management nets (and I was advocating strongly for that) but that somehow got lost in the implementation. 

For (2) we are still working on our operator API which will include that functionality once we get there :-)

German



On 2/8/16, 2:17 PM, "Brandon Logan" <brandon.logan at RACKSPACE.COM> wrote:

>Adding my own input:
>
>1. You should be able to add a specific role that the service accounts
>octavia will have.  Then that role can be added to neutron and nova's
>policy.json.  I have not tested this out but that is just a quick off
>the top of my head solution.
>
>2. What johnsom said.  Not ideal for large deployments but for large
>deployers, custom tooling would probably be written for that.
>
>3. Right now in devstack, the mgmt net is a single tenant network owned
>by the octavia service account.  This means that a lot of deployments
>would be limited to ~250 ports on that network (at least from our own
>experience and other's we have talked to).  Deployers can also specify
>that the mgmt network is a provider network which may not have that port
>restriction.
>
>Alternatively, we could create a mgmt net for each load balancer or each
>tenant.  I feel like this would have scaling issues but I haven't
>thought about it enough honestly.  Oh, one reason would be because,
>right now, all controllers would have to be connected to all the mgmt
>nets.  We've actually talked about how to solve this internally, but it
>was more just impromptu whiteboarding sessions.
>
>Thanks,
>Brandon
>
>On Mon, 2016-02-08 at 12:34 -0800, Michael Johnson wrote:
>> 1. Octavia can run under it's own account with the required roles
>> added to that account.
>> 2. Currently the process would be to update the amphora image in
>> glance and trigger a failover of the amphora.
>> 3. It is required.  It is a private network between the Octavia
>> controller and the amphora.  We would like to put the haproxy instance
>> in it's own namespace be we are not there yet.
>> 
>> Michael
>> 
>> On Mon, Feb 8, 2016 at 7:55 AM, Major Hayden <major at mhtx.net> wrote:
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA256
>> >
>> > Hey there,
>> >
>> > I've been doing some work to research how best to implement LBaaSv2 and Octavia within the OpenStack-Ansible project.  During that research, I've come up with a few questions.
>> >
>> > 1) Is it possible for octavia to operate without providing it with admin credentials?
>> >
>> > 2) If a user has amphora LB's deployed and a serious vulnerability is released for OpenSSL/haproxy, what should the user do to patch those load balancers?
>> >
>> > 3) Is a load balancer management network required?  Putting a LB onto an admin tenant network as well as a customer tenant network is challenging and bridging those networks could allow an attacker to gain access to other things on that admin tenant network.
>> >
>> > Thanks in advance for your time.
>> >
>> > - --
>> > Major Hayden
>> > -----BEGIN PGP SIGNATURE-----
>> > Version: GnuPG v2
>> >
>> > iQIcBAEBCAAGBQJWuLpuAAoJEHNwUeDBAR+xSF8P/j/KBH2320xB/dGWmy6xOMuJ
>> > DRQCcpEEljIu3O4pU8sF6yGEZX/CIoI3WXGaOBR2g0phWxEus5lhy0DdkPw4ctAa
>> > +UJ7da/s0C7fDbbl09TvWDe3eBoohIunLOm6ABpMT48YipfM0zJLLDEy9kQpDcFg
>> > qg68S5xgtC9zP9CeK1Gvsq5EwjwyX6Mt0a3+G1NMFbUoARLpDDof06YHrNFw73Td
>> > 25AxqToR09yRRXsJfadrjjP9/lGWNBF5f5Oh5WoPnEAiThqN08Ico3geHKIr9s2r
>> > Ift5NueWovCI5MUzOzqwsazKgnVgQXrgaaQwRotl5WdZbstUfWJLO+2If5/z4z8d
>> > AArWLXwsCgIv+I6ZyJ4R3YzJVP3KBY8+8gDswjdMV4Jfy7YV9aragy96ofCEwjuH
>> > p6QOGAKJZASD3cQpOdqVqQt4BaWBXMqm70sNDjfzKRBwweuOZgpNRInluDMbhngs
>> > Yqdj2LGUhuij50gQLa21cYJ5pcuA6yY7KNoiiPLkNbFDJtQo6cjVt/McVFPxN3mu
>> > RKRXpZNBgzf5UAKtrMIyPbw1wioAhbt7lgevfvCOLxHCmu0VxsLzRmOdiON5Exmg
>> > vopL518GJSUx93GhA0cwnqT/ilcTvDxFxPXQrvQK/XPtEQq4U3wBF/kZALK1/4tu
>> > 7hi/GjugHBcixIZGE5sI
>> > =XI9V
>> > -----END PGP SIGNATURE-----
>> >
>> > __________________________________________________________________________
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev