[Openstack-operators] [kolla] Question about how Operators deploy

Joe Topjian joe at topjian.net
Fri Feb 12 15:31:05 UTC 2016


2 VIPs as well.

On Fri, Feb 12, 2016 at 8:27 AM, Matt Fischer <matt at mattfischer.com> wrote:

> We also use 2 VIPs. public and internal, with admin being a CNAME for
> internal.
>
> On Fri, Feb 12, 2016 at 7:28 AM, Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:
>
>> We usually use two vips.
>>
>> Thanks,
>> Kevin
>>
>> ------------------------------
>> *From:* Steven Dake (stdake)
>> *Sent:* Friday, February 12, 2016 6:04:45 AM
>> *To:* openstack-operators at lists.openstack.org
>> *Subject:* [Openstack-operators] [kolla] Question about how Operators
>> deploy
>>
>> Hi folks,
>>
>> Unfortunately I won't be able to make it to the Operator midcycle because
>> of budget constraints or I would find the answer to this question there.
>> The Kolla upstream is busy sorting out external ssl termination and a
>> question arose in the Kolla community around operator requirements for
>> publicURL vs internalURL VIP management.
>>
>> At present, Kolla creates 3 Haproxy containers across 3 HA nodes with one
>> VIP managed by keepalived.  The VIP is used for internal communication
>> only.  Our PUBLIC_URL is set to a DNS name, and we expect the Operator to
>> sort out how to map that DNS name to the internal VIP used by Kolla.  The
>> way I do this in my home lab is to use NAT to NAT my public_URL from the
>> internet (hosted by dyndns) to my internal VIP that haproxies to my 3 HA
>> control nodes.  This is secure assuming someone doesn't bust through my NAT.
>>
>> An alternative has been suggested which is to use TWO vips.  One for
>> internal_url, one for public_url.  Then the operator would only be
>> responsible for selecting where to to allocate the public_url endpoint's
>> VIP.  I think this allows more flexibility without necessarily requiring
>> NAT while still delivering a secure solution.
>>
>> Not having ever run an OpenStack cloud in production, how do the
>> Operators want it?  Our deciding factor here is what Operators want, not
>> what is necessarily currently in the code base.  We still have time to make
>> this work differently for Mitaka, but I need feedback/advice quickly.
>>
>> The security guide seems to imply two VIPs are the way to Operate: (big
>> diagram):
>> http://docs.openstack.org/security-guide/networking/architecture.html
>>
>> The IRC discussion is here for reference:
>>
>> http://eavesdrop.openstack.org/irclogs/%23kolla/%23kolla.2016-02-12.log.html#t2016-02-12T12:09:08
>>
>> Thanks in Advance!
>> -steve
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160212/88099a8a/attachment.html>


More information about the OpenStack-operators mailing list